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

From: David McGrew <[email-masked]>
Date: Tue, 23 Aug 2011 07:52:17 -0700

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Aug 2011 15:15:36 +0300

David McGrew writes:
> 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).

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

> Password Authentication Method"

Done. 
-- 
[email-masked]