On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen <kivi...@iki.fi> wrote:
> 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.:
>
> Initiator Responder
> -------------------------------------------------------------------
> HDR, SAi1, KEi, Ni,
> N(SPAM_METHODS) -->
> <-- HDR, SAr1, KEr, Nr, [CERTREQ],
> N(SPAM_METHODS)
If the "SPAMs" are ZKPPs, they surely output key material, so why
bother with KEi/KEr here? Is it for privacy protection of the ID
payloads below?
> HDR, SK {IDi, [CERTREQ,]
> SPAM_PAYLOAD,
> SPAM_PAYLOAD, ...
> [IDr,] SAi2,
> TSi, TSr} -->
> <-- HDR, SK {IDr, [CERT,]
> SPAM_PAYLOAD,
> SPAM_PAYLOAD, ... }
> HDR, SK {SPAM_PAYLOAD, ...} -->
> <-- HDR, SK {SPAM_PAYLOAD, ...}
> HDR, SK {[SPAM_PAYLOAD, ...],
> AUTH} -->
> <-- HDR, SK {[SPAM_PAYLOAD, ...],
> AUTH, SAr2, TSi, TSr }
Studying this more carefully, I think this is close to fully
generalizable -- in a way where I could borrow the spec to make GSS
mechs out of this instead of the other way around. The only things
missing (channel binding, generic ID payloads, GSS flags conveyance)
could be added separately. Also, I'd want to very cleanly separate
the "SPAM" negotiation from the "SPAM" messages. (Did I mention that
SPAM is a trademark? :)
I'll think about this some more.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
