Subject: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01

From: Yaron Sheffer <[email-masked]>
Date: Sat, 25 Apr 2009 00:00:43 +0300

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Apr 2009 14:16:33 -0700

Hi Yaron,

> negotiation protocol is RECOMMENDED."

I don't see this as being applicable to security associations setup 
between two access routers in the same domain. Note that the access 
routers need just one security association for protecting the HI and 
HACK messages for all the mobile nodes. Recommending the use of a key 
negotiation protocol in this case would be over specification, IMO.

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 28 Apr 2009 10:42:51 +0300

Hi Vijay,

Actually you are proving my point :-) The cost of setting up a security
association (e.g. an IKE exchange) will be amortized over many HI/HACK uses.

And automatic key management is a BCP for some very good reasons, including:
- Limiting the lifetime of keys.
- Facilitating algorithm agility.
- Enabling the use of shorter shared secrets and/or certificates.
- Mitigating the harmful effect of using "widely shared" secrets (where all
group members see the same shared secret).
- Improving the entropy of encryption keys compared to human generated
"random" values.

I'm sure there are a few other reasons I've forgotten.

Thanks,
	Yaron

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 0:17
> To: Yaron Sheffer
> Cc: [email-masked]; [email-masked]; draft-ietf-mipshop-
> [email-masked]
> Subject: Re: Secdir review of draft-ietf-mipshop-rfc5268bis-01
> 
> Hi Yaron,
> 
> Yaron Sheffer wrote:
> Scanned by Check Point Total Security Gateway.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Apr 2009 11:21:37 +0300

Yaron, Vijay,

First, thank you for the review!

I wanted to highlight a historical point, however. I'm not necessarily 
opposed to the new text (in fact, it seems quite reasonable), but I'll 
note that RFC 5268 is just 10 months old, and we had all these 
discussions back then, and the RFC was the result. The purpose of the 
bis is to change one aspect (ICMP to MH) of the RFC.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Apr 2009 08:50:34 -0700

Hi Yaron,

On 4/28/09 12:42 AM, "Yaron Sheffer" wrote:

> Hi Vijay,
> 
> Actually you are proving my point :-)

No it doesn't.

> The cost of setting up a security

The cost of implementing and configuring a key negotiation protocol is not
worth it when we are looking at just one IPsec SA for all FMIPv6 related
signaling between the access routers. So I don't think having some text that
says "a key negotiation protocols is RECOMMENDED" is justified.

If deployments don't want to deal with manual IPsec keying (because it is a
hassle), they will start using IKEv2 automatically.
 
> I'm sure there are a few other reasons I've forgotten.

Almost all of these are not a concern when we talk about access routers in
an FMIPv6 domain, IMO.

Vijay