[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).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
