On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen <[email protected]> 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. 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, ...) > 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. (Incidentally, your design also reminds me of SSHv2.) Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
