On Wed, Apr 13, 2011 at 5:53 AM, Tero Kivinen <[email protected]> wrote: > Nico Williams writes: >> b) there are reserved numbers for using the GSS-API in IKEv1, and we >> could make it usable in IKEv2, > > If I remember right GSS-API is also asymmetric meaning only there is > clear separation of client and server side, and usually you cannot > assume that if I can act as GSS-API client side and connect to the > server the implementation can also act as GSS-API server side. > > I might be wrong on that issue, as I do not know GSS-API that well.
I believe you are wrong about that. Evidence: SCRAM (RFC5802). If you look at SCRAM you'll see that it's exceedingly simple -- it's a pre-shared password type mechanism, loosely resembling DIGEST-MD5. All the GSS aspects of SCRAM are segregated into a small, clean section. You'd mostly not have to concern yourself with it because I volunteer to write that for you :) > Also getting all those 4 secure password authentication methods > convereted to GSS-API methods is going to require quite a lot of work, Not at all (see above). I volunteer to do the GSS bits so you don't have to. The only change I need you to make for this is to agree to let the mechanism's sub-messages carry the initiator and responder names. I can even give up on how you name the mechanisms (8-bits? fine, so you'll have an IANA registry). > and also binding GSS-API authentication to the IKEv2 authentication > also requires work. For strong mechanisms you just key the IKE_SA from output of the mechanism. All we need is for the mechanism to output key material and a PRF (which can be effectively the same as IKE's PRF, so nothing new for you). For weaker mechanisms (like SCRAM) we'd want to do a KE before running the mechanism and channel binding to the KE. This is quite simple to do: just derive a nonce-like value from the KE output (i.e., use the PRF) and then use that in the mechanism as an input on both sides -- it only needs to match on both sides. You don't even have to think of this as channel binding if you don't want to. The reason I want this is so I can reuse your mechanisms outside IKE. I'm particularly interested in using them in SSHv2 and Kerberos pre-authentication. If your mechanisms' specification is easily reusable and we can make it cheap for them to be easily reusable, we all win. That's the bargain I'm offering you. I do the work you don't want to do and I make it so you don't even have to notice that your mechanisms are actually GSS mechanisms. :) All I need is for the mechanism messages to carry the initiator and responder names, for strong mechanisms to output a PRF and seed, and for weak mechanisms to do channel binding (which is trivial). Deal? Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
