Nico Williams writes:
> 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?
You really need to ask that from the authors of the methods, I just
took all of the methods and created common structure over them. All of
them do normal IKEv2 IKE_SA_INIT before they start do anything else.
They all do normal IKEv2 Diffie-Hellman and create (unauthenticated)
encrypted channel between the nodes and then create AUTH paload using
the SignedOctets from the IKEv2 in addition to their own stuff to
authenticate that channel.
The good think is that they do it that way, as it means there is very
little actual changes to the IKEv2 because of that. If they would
create keying material needed to encrypt and mac the IKE_AUTH
payloads, then those changes would be much bigger to the generic IKEv2
code than what now seems to be needed.
> > 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.
You have to remember that we do NOT want to change the standard IKEv2
parts of the protocol, i.e. SAi1, KEi, Ni, SAr1, KEr, Nr, IDi, IDr,
SAi2, TSi, or TSr payloads in any way.
We just want to make sure the methods can transmit their stuff with as
little coding as possible. Also all of the methods use different way
how to calculate the AUTH payload.
> Also, I'd want to very cleanly separate
> the "SPAM" negotiation from the "SPAM" messages. (Did I mention that
> SPAM is a trademark? :)
I know, and most likely will put something else in the draft if we
ever get that far...
I should have realized that any solution proposal to the spam problem
is like opening can of worms, so I should have used some other term
:-)
> I'll think about this some more.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
