Last Call Review of draft-ietf-mipshop-rfc5268bis-
review-ietf-mipshop-rfc5268bis-secdir-lc-sheffer-2009-05-02-00

Request Review of draft-ietf-mipshop-rfc5268bis
Requested rev. no specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-05
Requested 2009-04-16
Authors Rajeev Koodli
Draft last updated 2009-05-02
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer 
State Completed
Review review-ietf-mipshop-rfc5268bis-secdir-lc-sheffer-2009-05-02
Review completed: 2009-05-02

Review
review-ietf-mipshop-rfc5268bis-secdir-lc-sheffer-2009-05-02

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 document updates RFC 5268 (itself quite recent) by changing some ICMP
messages into more modern mobility header-carrying messages. I don't believe
this has any security implications. In fact the document includes very
thorough Security Considerations, inherited from RFC 5268 and slightly
adapted for the new message formats.

One issue that came up before the original RFC was published is the
protocol's liberality regarding (1) manual keying vs. key management
protocols, and (2) the choice of authentication method. The second issue was
rectified by adding the text: "If IKEv2 is used [...] to ensure a baseline
interoperability, the implementations MUST support shared secrets for mutual
authentication." But this leaves the first issue open: manual keying remains
an option. So I propose to add to:

"The security associations can be created by using either manual IPsec
configuration or a dynamic key negotiation protocol such as IKEv2
[rfc4306]."

This new text:

"Following the recommendations of RFC 5406 (Sec. 3.3), the use of a key
negotiation protocol is RECOMMENDED."

Thanks,
	Yaron


Attachment:


smime.p7s




Description:

 S/MIME cryptographic signature