Subject: RE: [mobile-ip] 2002bis change to Authenticator Spec

From: Phil Roberts <[email-masked]>
Date: Fri, 13 Jul 2001 13:32:27 -0400

> 
> Recommending that both be implemented will take care of the 
> future and the 
> past. Sometime later when HMAC is implemented by every one,
> we can change the recommendation.
> 
> -Gopal

But isn't that what this is saying?  MUST do HMAC, SHOULD do MD5 if there
is a need for backward compatibility?

> 
> PS: on a lighter side, Security Algos are secure till some 
> known weakness 
> and it is a matter of time that a weakness is found.
> 
> 
> > >
> > > -Gopal
> > >
> > >
> > > >Another thing to note is that this will probably come up 
> again when
> > > >we try to move MIPv4 to Draft Standard, the new 
> functionality causing
> > > >a recycle at Proposed.
> > > >
> > > >Feedback requested, please.
> > > >
> > > >Here's the proposed new text:
> > > >
> > > >-----------------------------
> > > >3.5.1. Computing Authentication Extension Values
> > > >
> > > >    The default authentication algorithm uses HMAC-MD5 [22]
> > > to compute
> > > >    a 128-bit "message digest" of the registration 
> message.  The key
> > > >    used in the HMAC computation is the 128-bit shared 
> secret defined
> > > >    by the mobility security association between the 
> communicating
> > > >    nodes.  The data over which the HMAC is computed is 
> defined as:
> > > >
> > > >     -  the UDP payload (that is, the Registration Request or
> > > >        Registration Reply data),
> > > >
> > > >     -  all prior Extensions in their entirety, and
> > > >
> > > >     -  the Type, Length, and SPI of this Extension.
> > > >
> > > >    Note that the Authenticator field itself and the UDP
> > > header are NOT
> > > >    included in the computation of the default 
> Authenticator value.
> > > >    See Section 5.1 for information about support 
> requirements for
> > > >    message authentication codes, which are to be used with
> > > the various
> > > >    authentication Extensions.
> > > >
> > > >    The Security Parameter Index (SPI) within any of the
> > > authentication
> > > >    Extensions defines the security context which is 
> used to compute
> > > >    the Authenticator value and which MUST be used by 
> the receiver to
> > > >    check that value.  In particular, the SPI selects the
> > > authentication
> > > >    algorithm and mode (Section 5.1) and secret (a shared key, or
> > > >    appropriate public/private key pair) used in computing the
> > > >    Authenticator.  In order to ensure interoperability
> > > between different
> > > >    implementations of the Mobile IP protocol, an
> > > implementation MUST be
> > > >    able to associate any SPI value with any 
> authentication algorithm
> > > >    and mode which it implements.  In addition, all 
> implementations
> > > >    of Mobile IP MUST implement the default 
> authentication algorithm
> > > >    (HMAC-MD5) defined above.
> > > >
> > > >
> > > >
> > > >
> > > >5.1. Message Authentication Codes
> > > >
> > > >    Home agents and mobile nodes MUST be able to perform
> > > authentication.
> > > >    The default algorithm is HMAC-MD5 [22], with a key 
> size of 128
> > > >    bits.  The foreign agent MUST also support
> > > authentication using HMAC-MD5
> > > >    and key sizes of 128 bits or greater, with manual key
> > > distribution.  Keys
> > > >    with arbitrary binary values MUST be supported.
> > > >
> > > >    The "prefix+suffix" use of MD5 to protect data and a
> > > shared secret is
> > > >considered
> > > >    vulnerable to attack by the cryptographic community.
> > > Where backward
> > > >compatibility
> > > >    with existing Mobile IP implementations that use this
> > > mode is needed,
> > > >    new implementations SHOULD include keyed MD5 [39] as 
> one of the
> > > >additional
> > > >    authentication algorithms for use when producing and
> > > verifying the
> > > >    authentication data that is supplied with Mobile IP 
> registration
> > > >    messages, for instance in the extensions specified in
> > > sections 3.5.2,
> > > >    3.5.3, and 3.5.4.
> > > >
> > > >    The previously specified operation uses keyed-MD5 [39] in
> > > >    "prefix+suffix" mode to compute a 128-bit "message 
> digest" of the
> > > >    registration message.  The default authenticator is a
> > > 128-bit value
> > > >    computed as the MD5 checksum over the the following
> > > stream of bytes:
> > > >
> > > >     -  the shared secret defined by the mobility security
> > > association
> > > >        between the nodes and by the SPI value specified in the
> > > >        authentication Extension, followed by
> > > >
> > > >     -  the protected fields from the registration message,
> > > in the order
> > > >        specified above, followed by
> > > >
> > > >     -  the shared secret again.
> > > >
> > > >    More authentication algorithms, algorithm modes, key 
> distribution
> > > >methods,
> > > >    and key sizes MAY also be supported for all of these 
> extensions.
> > >
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 14:00:52 -0700

All,

There is always a risk in shipping products based on an RFC that
is Proposed Standard. Time and time again I've seen needed
changes as a spec progresses towards full standards, and manufacturers
are left up the proverbial creek (btw, I've been there, and wasn't 
happy about it either).

In this particular instance, I happen to agree that a MUST for
HMAC-MD5, and a SHOULD for MD5 is the correct approach. For products
that are labelled as "RFC 2002" compliant, customers will know that
they can only support MD5. These same customers buying products compliant
with RFC nnnn (whatever RFC 2002bis ends up being), if they have 
an existing base, they'll make sure that it also supports native 
prefix/suffix MD5.

The fact that it is a SHOULD, as opposed to a MUST, will lead designers
towards an on/off switch, and this is really what's needed. If you are
comfortable with prefix/suffix, then leave the switch turned on, but
don't complain if someone steals the lightbulb.

That said, if the WG feels differently (and we are allowed to ignore
IESG concerns), I won't stand in the way of keeping things as they 
are.

My 2 cents,

PatC