Last Call Review of draft-ietf-ipsecme-ikev2-resumption-

Request Review of draft-ietf-ipsecme-ikev2-resumption
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-14
Requested 2009-09-10
Authors Yaron Sheffer, Hannes Tschofenig
Draft last updated 2009-09-18
Completed reviews Secdir Last Call review of -?? by Sean Turner
Assignment Reviewer Sean Turner
State Completed
Review review-ietf-ipsecme-ikev2-resumption-secdir-lc-turner-2009-09-18
Review completed: 2009-09-18


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.

This ID is intended for the Standards Track.  It defines an efficient 

way to resume an IKE/IPsec session using a previous established IKE SA 

without the need to re-run the key exchange protocol from the beginning. 

 The approach is similar to that used by TLS session resumption, but 

modified for IKEv2.

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Technical comments:

4.3.1 does not require gateways to reject reused tickets (it's a 

SHOULD).  Shouldn't there be some text in the security considerations 

about gateways accepting reused tickets or text to say it's not a 

security consideration because of x, y, and z?  It's different than the 

considerations put forth in 9.8 because it addresses why the client must 

not present reused tickets.

4.3.2 states: "The client SHOULD NOT use this exchange type unless it 

knows that the gateway supports it."  What is the mechanism to determine 

whether the gateways support these new exchanges?  What happens when the 

client sends a request and the gateway doesn't support the response? 

What error message is returned from the gateway?  This might all be 

defined elsewhere in the IKE suite of specs, but this ID should probably 

point to that text wherever it is.

Editorial comments:

4.3.2: Should the may be MAY in the following: The first message may be 

rejected in?

4.3.2:  r/value ./value.

5: Note 6 is missing a ")"

6.1: r/MUST be protected so that only unauthorized access is not 

allowed/MUST be protected so that only authorized access is allowed

9.3: r/as possible. and/as possible, and