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

From: Phil Roberts <[email-masked]>
Date: Thu, 12 Jul 2001 17:13:02 -0400

> -----Original Message-----
> From: Gopal Dommety [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 4:41 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] 2002bis change to Authenticator Spec
> 
> 
> At 04:21 PM 7/12/2001 -0400, you wrote:
> >The IESG notes that MD5 as used in 2002 has known weaknesses and
> >there are better methods recommended now (e.g., HMAC). In order to
> >transition Mobile IP implementations to the stronger method, we
> >recommend that HMAC become mandatory, with the currently implemented
> >MD5 a SHOULD, with text noting that it should be implemented in cases
> >where backwards compatability is necessary. This will allow new and
> >updated implementations to interoperate with implementations of RFC
> >2002, but provides a clear path for moving away from MD5 as
> >implementations are upgraded to the revised specification.
> 
> 
> Why not have MD5 also a MUST?

has known weaknesses.

> 
> -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: "Kent K. Leung" <[email-masked]>
Date: Thu, 12 Jul 2001 16:14:03 -0700

I agree with the need to transition to stronger authentication.  But
concern
with backward compatibility of current deployment.  Though this issue
is noted in update and SHOULD is used, for implementations with only
HMAC, this will cause interoperability problem since existing
implementations
cannot be configured with HMAC (obviously).

Would using a MUST for MD5 be harmful since the strongly recommended
method is HMAC anyways.  For implementations that just can't do HMAC
for whatever reasons, they can still interop with others (though knowingly
using a weaker method).

As stated in update, it's up to user to select which authentication method
by the SPI.  So mandating support of both methods allows users to
interoperate
with RFC 2002 and 2002bis implementations seamlessly.  Of course, HMAC
is preferred method.

Kent

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 13 Jul 2001 10:24:18 -0700

> > Why not have MD5 also a MUST?

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

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.