Subject: [mobile-ip] FWD: I-D ACTION:draft-bellovin-mandate-keymgmt-00.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Apr 2003 11:10:32 -0400

This document has bearing on the MIPv6 spec.

Note that Steve Bellovin has a discuss on the MIPv6 document with the
comment:

> 5.1 In my opinion, IKE support should be a SHOULD, not a MAY. I
>     have problems with the replay protection (see below).

Thomas

from http://www.ietf.org/IESG/EVALUATIONS/draft-ietf-mobileip-ipv6.bal

> Steve: 
> For a spec of this length, complexity, and security sensitivity, I'm
> remarkably happy with it. I have some issues, but I suspect that most
> can be resolved pretty easily. It was a delight to be able to delete
> some of my notes as I progressed through the document. Furthermore,
> given the length and complexity of the spec, I could easily be wrong
> about many of these points. I'd be delighted if that were the case.
> 
> 5.1 In my opinion, IKE support should be a SHOULD, not a MAY. I
>     have problems with the replay protection (see below).
> 
> 5.2.5 The figure shows the Home Test Init message going from the
>       mobile->home agent->correspondent. The text says that
>       it goes from the mobile->correspondent. Which is it?
> 
>       There are a number of HMAC'd fields floating around. Some, at
>       least, seem to have a distinguishing type value, such as 0 in
>       the home keygen token. The Binding Update takes a parameter
>       with a BU in the last byte. Is that intended to serve the same
>       purpose? I don't see a value for BU defined anywhere -- is that
>       the '5' in Section 14? If so, the 0 and 1 shouldn't overlap
>       that type space, and there should be an explicit statement about
>       the reserved values in Section 14, so that no future IANA
>       assignments conflict with them. I'd also like the authors to
>       verify that all HMAC'd fields have such such type code that is
>       never used elsewhere.
> 
> 6.1.7 The text here (and in 6.1.8 and 6.1.9) should note that the
>       authorization option is mandatory. It says so later, but not
>       that clearly.
> 
> 6.2.6 Should Mobility Data include the home address? The option
>       doesn't seem to protect other data, including things like
>       lifetime, sequence #, etc.
> 
> 7.5 Those advertisement frequencies scare me -- they're quite high.
>     Worse yet, the most likely place they're needed -- microcells --
>     have limited bandwidth.
> 
> 7.6 Which link is this link-local local to? The home network?
> 
> 9.5.1 If there's no IPsec-level replay protection, this sequence number
>       just won't do the trick. A wireless mobile node could very
>       easily generate enough binding updates per day that an enemy
>       could replay old ones that appeared to be in the window.
> 
> 10.3.1 Has the IPsec wg verified that K=1 really works? I'm not
>        convinced of it, since some cookies are address-dependent.
>        Beyond that, the SPD and the SADB will need to change as the
>        source and destination IP addresses change.
> 
> 10.4.5 In the absence of ESP -- and why would it be omitted? --
>        how can the home agent reliably verify that the source address
>        in the tunnel IP header is legitimate? I'd say that reverse-
>        tunneled packets MUST be discard unless ESP-protected. (I'm
>        astonished that it isn't even a SHOULD.)
> 
> 11.3.5 Should some sort of timeout be associated with the fact that
>        a certain destination address can't accept Mobility Headers?
> 
> 11.7.2 Same comment about sequence number processing

------- Forwarded Message

From: [email-masked]
To: IETF-Announce: ;
Date: Thu, 10 Apr 2003 07:53:24 -0400
Subject: I-D ACTION:draft-bellovin-mandate-keymgmt-00.txt
Reply-to: [email-masked]

--NextPart
To
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Guidelines for Mandating Automated Key Management
	Author(s)	: S. Bellovin
	Filename	: draft-bellovin-mandate-keymgmt-00.txt
	Pages		: 4
	Date		: 2003-4-9
	
The question often arises of whether or not a given security system
requires some form of automated key management, or whether manual
keying would suffice.  This memo proposes guidelines for making such
decisions; the presumption is that automated key management is
generally but not always needed; if manual keying is proposed, the
burden of proof is on the proposer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bellovin-mandate-keymgmt-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-bellovin-mandate-keymgmt-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-bellovin-mandate-keymgmt-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-bellovin-mandate-keymgmt-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-bellovin-mandate-keymgmt-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

------- End of Forwarded Message