Nico Williams writes: > On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen <kivi...@iki.fi> wrote: > > 1) Add new notification to the IKE_SA_INIT telling which SPAM > > algorithms are supported. This will notification will include tuple > > of 8-bit integers containing the 8-bit SPAM algorith number and > > 8-bit password preprosessing technique number. The initiator sends > > all supported algorithms and responder will pick one algorithm > > which is to be used. The other option here is that reponder lists > > which algorithms which it supports and initiator can then use any > > of them. > > 8-bit?! BTW, sending SASL mechanism names, or EAP method names, or > GSS-API mechnism OIDs wouldn't be that different from sending 8-bit > mechanism numbers.
We currently have 4 different methods, and I do think we are going to be loose one (hopefully two) before they are published as RFCs. I do not really think there are going to be more in next 5 years. > But it'd be way better, because you'd be using an > off-the-shelf framework. Off the shelf is good, for all the reasons I > gave earlier and then some (more mechanisms exist, the frameworks have > a better chance of being pluggable as implemented, code reuse, > specification reuse, ...) More is bad. We do not want more. We want less. We would like to have exactly ONE method, but we could not agree on one, and as document authors wanted to publish their methods we are now getting four incompatible, non-interoperable methods which are hard to put in same implementation as they do not have common method of agreeing which method to use etc. Every single one of those methods DO require changes to the IKEv2 library. Most likely you cannot make them really pluggable as they do change the fundamental parts of the IKEv2, or at least the API between them and the IKEv2 library is going to be quite complex. Most likely the API will change a bit depending which method is used, for example the AUTH calculation do require lots of stuff from the IKEv2 library, but also lots of stuff from the auth mehtod which means most likely the easiest way is to give all data IKEv2 has to the method specific function which will then do the AUTH calculation. This is not going to be anything generic, but data from IKEv2 that needs to be given to the method might differ from method to method. Note, that this changes the IKE_SA_INIT payload, which MUST be kept as small as possible so it will not get fragmented. > > 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the > > extra payloads in them depend on the SPAM algorithm used, and the > > SPAM algorithm used also affects the AUTH payload generation. The > > exchange will similar to EAP, i.e.: > > AUTH payloads should be where channel binding is done, yes. We should > definitely think in terms of CB here, and if you were to use SASL or > the GSS-API then you'd get the necessary CB functionality right off > the bat. There is no CB there, as the IKEv2 AUTH payload calculation does all the authentication and the AUTH payload calculation done by all of those methods MUST meet exactly same security properties that IKEv2 AUTH payload calculation has, i.e. provide same security than what is explained in the section 2.15 in RFC5996. This is not really external authentication framework, this is integral part of the IKEv2 authentication where we just create generic framework for transmitting those payloads needed by the authentication method. The authentication method is still doing all the AUTH payload calculations using the internal data from the IKEv2 (including InitiatorSignedOctects and ResponderSignedOctects etc). > (Incidentally, your design also reminds me of SSHv2.) The design comes directly from those four different drafts, i.e. I just checked out what is common with them and created the common payload format based on that. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
