Last Call Review of draft-kivinen-ipsecme-secure-password-framework-
review-kivinen-ipsecme-secure-password-framework-secdir-lc-mcgrew-2011-08-26-00

I have reviewed this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the


IESG.  These comments were written primarily for the benefit of the  


security area directors.  Document editors and WG chairs should treat  


these comments just like any other last call comments.






The intended status of this document is Informational, but in some  


sense it is performing actions with implications for standards.  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 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.  There are some signficiant differences (for  


instance, [2] has special considerations for RFC5282, but [1] and [3]  


do not), and the absence of a securty analysis puts a burden on the  


user of the framework.






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"



notes:
[1] harkins-ipsecme-spsk-auth
[2] kuegler-ipsecme-pace-ikev2
[3] shin-augmented-pake