[secdir] secdir review of kivinen-ipsecme-secure-password-framework-01

[Tero Kivinen <[e-mail]>]

David McGrew writes:
> The intended status of this document is Informational, but in some  
> sense it is performing actions with implications for standards.

I think all of those 3 drafts are listed as for Experimental status
not for standards track. Also it is meant to be so that each of those
drafts would be not need to make normative reference to this document,
i.e. they will copy all the text they need to make documents
self-standing. This document will mostly just include background
information.

> It implies, but does not state, that IANA should not allocate the
> "IKEv2 Authentication Method" numbers requested by three
> experimental drafts ([1], [2], [3]). The motivation for this draft
> is that "each of ([1], [2], [3]) used different method to negotiate"
> the use of the method, but it does not clarify where the difficulty
> arises - each of those three documents defines its own IKEv2
> Authentication Method.

The IKEv2 Authentication Method is indicated way too late to be used
for negotiation of the method. It is sent along the AUTH payload
inside the last IKE_AUTH exchange, which means the implementations
need to know the method to be used earlier (i.e. before they start the
IKE_AUTH).

> The Security Considerations section punts to [1], [2], and [3], but  
> this document would be more useful if it provided a comparison of the  
> existing methods.

For my point of view all of the documents are mostly same, I do not
think there is any major differences in them. Because of this I think
it is not possible for me to provide such comparison. 

> There are some signficiant differences (for instance, [2] has
> special considerations for RFC5282, but [1] and [3] do not),

As far as I know the [2] is the only one which have special issues
with RFC5282, and even with that it is just that the method reuses the
same encryption method than IKEv2 SA uses for some other uses, and in
that other use the authenticated encryption cipher is not suitable.

> and the absence of a securty analysis puts a burden on the user of
> the framework.

My hope is that this framework is not needed anymore in the future,
i.e. that there would not be 4th version of the secure password method
using this framework. Unfortunately that might not be so, and that is
the main reason of putting out this document.

As this document will be something that is not really needed for
implementing any of [1], [2], or [3] (each of those documents will be
self-sufficient) the only reason to publish this is to provide generic
text in case we have one more of those methods in the future, so it
can follow the same rules than those 3 existing ones. This document
is also useful for someone implementing multiple of those existing
protocols, so the implementor can know which rules were used, without
the need to compare actual protocols exactly. 

> The document has many nits, and needs an editorial pass.  Some  
> suggested changes below:
> 
> Abstract:
> "This document specifies a common way so those methods can agree on  
> which method is to be used in current connection." -> "This document  
> specifies a way to agree on which method is to be used in current  
> connection. "
> Introduction:
> "As each of those documents used different method to negotiate the use  
> of the method ..." -> "As each of those documents used a different  
> technique to negotiate the use of the method ..."
> I suggest removing "This document does not create new protocol or even  
> define a protocol which could be used to do anything."
> Section 2.
> "The proposed negotiation exchange would be:" -> "The secure password  
> negotiation exchange is:"
> IANA Considerations:
> "TBD Secure Password Authentication Method" -> " TBD Generic Secure  
> Password Authentication Method"

Done. 
-- 
[e-mail]