On Tue, Apr 12, 2011 at 3:13 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> I'd like to skip through the architectural bits in a hurry, and then come
> back to Tero's proposal. All while rapidly flipping hats :-)
:)
> In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 5998)
> [EAP pain elided -Nico]
Undcerstood. And from the discussion with Dan I think I've come to
see that there's actually very little difference between what Tero
proposes and what I would consider ideal, which, if I may, would be:
- Initiator<->Responder: KE payload exchange
- Initiator->Responder: {SASL/GS2 mechanism name list, [initial
context token for optimistic mechanism choice, with channel binding to
KE]}
- Responder->Initiator: {Server's SASL/GS2 mechanism name list} |
reply context token for optimistic mechanism choice, with channel
binding to KE
- Initiator<->Responder: variable number of round-trips, according to
the selected mechanism
- done
And what do the mechanisms look like? Easy: look at SCRAM (RFC5802).
SCRAM is a simple successor to DIGEST-MD5. IKE would need other
mechanisms too, but all of those could be patterned after SCRAM in
terms of specification simplicity.
If you do it this way you needn't even be too aware that you're
actually using the GSS-API framework -- you can ignore it almost
completely. But the rest of us will get working SASL and GSS
mechanisms out of your IKE mechanisms. Win-win for all of us. And if
anyone ever needs AAA? Point them to ABFAB.
Nico
--
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
