Subject: [mobile-ip] RFC2002bis

From: Charlie Perkins <[email-masked]>
Date: Fri, 10 Aug 2001 18:00:08 -0700

Hello folks,

A new version of RFC2002bis has been prepared.  According
to the most recent guidance given by the IESG, a change in
the mandated authentication algorithm has been strongly
suggested.  Unfortunately, this will have the effect of
causing almost all previous implementations of Mobile IP
for IPv4 to become incompatible with the new specification.

The working group chairs recently asked the working group,
by way of the mailing list, whether this incompatible
change would be acceptable.  The discussion was quite
limited, somewhat to my surprise.  This has been taken
as evidence that going with HMAC_MD5 is more-or-less
O.K.  Thus, it has been decided to go ahead with the
change.  On the other hand, it is conceivable that not
all interested parties have been notified of the possible
change, or have had time to reply.  If there are dissenters
to this change, now would be the time to express that
opinion.

That is the most important point of this note.

Another factor in the discussion concerns the acceptability
of RFC2002bis as a basis for moving Mobile IPv4 to Draft
Standard.  I have been told that, contrary to my previous
understanding, a version of RFC2002bis could be promoted
to Draft Standard even if it is first published with
the several options which have not been tested for
interoperability. These options are:
1. 'R' bit to the Agent Advertisement
2. 'S' bit to Registration Request
3. Prefix Lengths Extension to Agent Advertisement
4. Possibly other options that may come under discussion
   (I don't know of any in this class).
I'll call these the "unpromotable options"

On the other hand, it is likely that the IESG will not
promote Mobile IPv4 to Draft Standard unless the authentication
algorithm has been changed to HMAC_MD5.

Consideration of all these factors leads me to believe that
one of the following scenarios will happen.

1. New RFC2002bis goes to Proposed Standard with HMAC_MD5,
   and is promoted to Draft Standard after the ordained amount
   of time after the unpromotable options are excised.  These
   would then properly be re-published in another document
   which would cycle at Proposed Standard.

2. New RFC2002bis goes to Proposed Standard with HMAC_MD5,
   and activity occurs to exhibit interoperability for the
   unpromotable options.  Then, since the options would
   become promotable, RFC2002bis could go to Draft Standard
   without substantial revision.

3. (combination of 1 and 2): some of the unpromotable options,
   but not all of them, are tested for interoperability.
   Then fewer of the options would be excised, and the other
   new document would be thinner.

4. The working group could decide that moving to HMAC_MD5
   was premature.  Then RFC2002bis might possibly be published
   with "envelope-mode" specified (as it is now).  Then another
   version of Mobile IPv4 would be published later with
   HMAC_MD5 mandated instead of "envelope-mode" mandated.
   The advantage of this approach is that it would be possible
   to create correct and interoperable implementations of
   Mobile IPv4.  Up until now, all interoperable implementations
   have had to handle the SPI field as part of the computation
   of the authentication data in a way that was not clear from
   RFC 2002.  Fixing this problem was the most important
   reason for embarking on RFC2002bis in the first place.

I think that basically accounts for the most likely
possibilities, but maybe there are others that could happen.
However, it seems likely that HMAC_MD5 will be required by
the IESG as the mandated default algorithm in the Draft
Standard version of Mobile IPv4, because there has been
published work showing that envelope mode is vulnerable to
an attack that reduces its cryptographic strength.

Following strategies 1-3 will mean that there is no RFC
which can be read to create new implementations of
Mobile IPv4 which are interoperable with existing versions
of Mobile IPv4.  On the other hand, following 1-3 will
mean that RFC2002bis is a more likely candidate for
promotion to Draft Standard, avoiding the need for one
more revision to accomplish that purpose.

Quick action is expected on the HMAC_MD5 version of RFC200bis,
so it is possible that any discussion about backwards
incompatibility will happen as part of IETF Last Call.

Whatever people decide on these issues is fine with me.
As draft editor, I'll happily produce whatever documents
are indicated by near-term and Last Call discussions over
the next weeks.

Regards,
Charlie P.

---

From: Marcello Lioy <[email-masked]>
Date: Sun, 12 Aug 2001 18:38:37 +0200

>to this change, now would be the time to express that

This could be an issue.  TIA/EIA IS-835 (the packet data standard for 
CDMA2000) is going to be deployed in North America this fall.  It specifies 
the user of RFC 2002.  There are two major areas of incompatibilty in RFC 
2002bis:
1) the inclusion of the SPI in the auth calculation
2) HMAC_MD5 if that is decided on.

Both of these things break 2002 - which means that the mobiles and 
infrastructure that are 835 compliant will be obsoleted when RFC 2002 is 
obsoleted.

I think that both of these fixes are good (the SPI was a bug that slipped 
through in 2002, and HMAC sounds like it is less vulnerable than vanila 
MD5) but they could cause issues in these planned network deployments.
-----------------------------------
Marcello (Wandering through France)

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Mon, 13 Aug 2001 04:13:01 +0900

Hello Charlie,

 Thank you for your so-far enormous efforts on MIPv4.
 I have two comments embedded in the following:

>1. 'R' bit to the Agent Advertisement

 From my memory, we had checked 'R' bit at the Testathon,
 thanks to Steve.

>3. Prefix Lengths Extension to Agent Advertisement

 Also, about Prefix Length Extension, we had tested it
 at the 3rd bakeoff at Sun, thanks to Pat.
 But, I agree it is the best&last time to sum up tested or
 not-tested functions, and recycle untested bits. 

>algorithm has been changed to HMAC_MD5.

 This might affect 3GPP2 process, I'm afraid.  I believe
 Tom Hiller has received your email, so he can reply
 if the above may affect 3GPP2 or not.

Thanks so many.
-Yoshi

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 13 Aug 2001 14:46:01 -0400

Charlie,

> to this change, now would be the time to express that

A quick question...when this was discussed on the mailing list last
month, Kent and Gopal raised the issue of making MD5 also a MUST
in RFC2002bis.  Discussion followed whether MD5 should be a MUST
or a SHOULD for backwards compatibility...with the understanding that 
HMAC_MD5 would be a MUST.  So, is the idea now not to even mention this 
use of MD5?  Please clarify.

Thanks,
Madhavi