Last Call Review of draft-kivinen-ipsecme-secure-password-framework-

Request Review of draft-kivinen-ipsecme-secure-password-framework
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-08-24
Requested 2011-08-01
Authors Tero Kivinen
Draft last updated 2011-08-26
Completed reviews Secdir Last Call review of -?? by David McGrew
Assignment Reviewer David McGrew 
State Completed
Review review-kivinen-ipsecme-secure-password-framework-secdir-lc-mcgrew-2011-08-26
Review completed: 2011-08-26


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:


"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. "


"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"

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