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

[Yaron Sheffer <[e-mail]>]

[Removing the main IETF list]

Hi Tero,

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.

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.

Thanks,
     Yaron

On 07/28/2011 05:27 PM, Tero Kivinen wrote:
> Yaron Sheffer writes:
>> Back to the matter at hand: I am opposed to
>> draft-kivinen-ipsecme-secure-password-framework. It has served its
>> purpose when two of the proposals were changed to add method
>> negotiation, and thus enable IKE peers to implement none, one or more of
>> these methods.
> Actually there is currently only one draft, draft-shin-augmented-pake,
> which follows my negotiation process. The
> draft-harkins-ipsecme-spsk-auth author did say he is going to change
> his draft, but the draft is not yet there, and then there is
> draft-kuegler-ipsecme-pace-ikev2 (which you are co-author) which is
> doing negotiation differently and I do not know whether that is going
> to change to use same way than others.
>
>> I believe the other justifications for this draft, including the
>> preservation of IANA IKEv2 namespaces, are bogus.
> As an IANA Expert for the registries in question I strongly disagree.
>
> If you want to delay this fight to the IANA allocation time, that is
> fine by me, but I will point it out already now that I will be against
> allocating separate code points for each protocol as there is no need
> for that.
>
>> Adopting the rest of the framework would be a useless exercise.
> Keeping the IANA registries clean is important for me, in addition to
> make it easy to implement multiple methods in the same implementation.
> I do not consider them as useless resons. Especially as it only causes
> very small changes to the actual protocol drafts (I would expect less
> than an one hour of work).