Re: [IPsec] Last Call: <draft-kivinen-ipsecme-secure-password-framework-01.txt> (Secure Password Framework for IKEv2) to Informational RFC

[Tero Kivinen <[e-mail]>]

Yaron Sheffer writes:
> it doesn't matter exactly what negotiation is used, as long as two peers 
> can offer multiple methods in IKE_SA_INIT, and find out which auth 
> methods they have in common, if any. This is true for PACE, and also for 
> version -04 of SPSK, i.e. before it adopted your framework.

Yes all drafts now have negotiation method happening in the
IKE_SA_INIT, which is good. 

> Regarding IANA allocation, I would like to quote from RFC 5226:
> 
> "The designated expert is responsible for initiating and coordinating 
> the appropriate review of an assignment request.  The review may be wide 
> or narrow, depending on the situation and the judgment of the designated 
> expert.  This may involve consultation with a set of technology experts, 
> discussion on a public mailing list, consultation with a working group 
> (or its mailing list if the working group has disbanded), etc.  [...] 
> Designated experts are expected to be able to defend their decisions to 
> the IETF community, and the evaluation process is not intended to be 
> secretive or bestow unquestioned power on the expert."
> 
> I certainly do not want to turn the IANA allocation into a "fight". I do 
> think the community needs to be consulted.

As we have seen from the ipsec list the community does not seem to
care too much, but I myself as a member of the community and also the
person responsible for the IANA registries do care.

I have stated my reasons why I consider allocating multiple payload
numbers etc for exactly same thing a bad thing.

As it seems that IKEv2 might be used with other things than IPsec too
in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in
the IKEv2 IANA registries.

Even if those use cases are not IPsec they most likely will reuse most
of the registries from the IPsec. We could overlap their numbers with
each other, but on the other hand that can cause confusion, so it
might be better to make sure they do not have overlapping numbers,
i.e. use of unique numbers for different things and mark those as
reserved in the registries which do not use them.

This is bit what IKEv1 and IKEv2 did, for example we are not using
payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1
used them. Same way our exchange numbers 0-33 are reserved etc.

I am not sure whether we are doing that in the future or not. I want
to think more about this and see the actual protocols before deciding.

But on the other hand I want to keep our options open, which means I
do not want to fill our registries with multiple registrations for the
exactly same thing.

Can you explain me what problems will it cause if the
draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the
draft-kivinen-ipsecme-secure-password-framework framework just like
other secure password method drafts have already done?

In my understanding there will be 2 extra bytes in the IKE_SA_INIT
notification phase to indicate the PACE inside
N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two
depending how you do it) in the ENONCE and PKEi/PKEr payloads.

So in total the technical differences will be 7 extra bytes. Is there
anything else?
-- 
[e-mail]