Subject: [Mip4] Question regarding 3012bis

From: Alpesh Patel <[email-masked]>
Date: Tue, 19 Oct 2004 18:26:56 -0700

Hi -

I have a basic concern regarding the use of HMAC_MD5 in 3012bis
(I have had a few email exchanges with authors and WG chairs in
this regards and am posting on WG chair suggestion)

3012bis defines GENAE (MN-AAA authenticator to be precise).
The MN-AAA authenticator (MAAE) aids in AAA authentication by
mapping the RRQ extensions to AAA attributes at FA or HA.

With CHAP_SPI (value  2), the RRQ extensions are mapped to
Radius chap attributes for chap authentication. The details are
as follows:

chap challenge = md5(RRQ data till the SPI field of MAAE)
chap challenge = authenticator field from MAAE

The authenticator calculation is specified in 3012bis and no issue
with that in regards to MD5.

This works and is widely deployed today.

As a summary, the chap challenge above aids to compress the message.

Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap 
challenge above is calculated using HMAC_MD5 and that the authenticator 
is calculated using HMAC_MD5. I have a concern with both these claims:

1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is
required between MN and FA/HA. One basic assumption is that in some
domains/deployments this can be manually provisioned. One issue is how 
to decide on which :key: to use for challenge generation? No means to
specify that. (one applicability of this draft is to leverage on a 
single MN/AAA secret and so, I cannot clearly see the reason for such a 
provisoned key).

2. second and primary concern is that there are no radius attributes 
(standard /VSAs), which can be used to authenticate a challenge response
generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of
that new attributes need to be defined and processing at Radius needs to 
be specified.

In light of these two issues, I am wondering how HMAC_MD5 can be 
realistically used for authenticating MAAE today?

Can someone demystify the usage of HMAC_MD5?

Thanks
Alpesh

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Pete McCann <[email-masked]>
Date: Wed, 20 Oct 2004 04:48:55 -0500

Hi, Alpesh,

I tend to agree that the usage of HMAC_CHAP_SPI is a bit
under-specified.

The usage of the "inner" MD5 for CHAP_SPI is as a compression
function, to help solve the problem of limited space in RADIUS
attributes.

The problem is the text right now says:

   To compute the authenticator, apply MD5 [RFC1321] computed on the
   following data, in the order shown:

      High-order byte from Challenge || Key ||
      MD5(Preceding Mobile IP data ||
      Type, Subtype (if present), Length, SPI) ||
      Least-order 237 bytes from Challenge

   where the Type, Length, SPI, and possibly Subtype, are the fields of
   the authentication extension in use.  For instance, all four of these
   fields would be in use when SPI == (CHAP_SPI or HMAC_CHAP_SPI) is
   used with the Generalized Authentication extension.  The use of SPI
   number HMAC_CHAP_SPI indicates the use of HMAC_MD5 instead of MD5 in
   the above procedure. 

It seems to say that HMAC_MD5 replaces both the "inner" and "outer"
occurences of MD5, but fails to specify the Key used for the "inner"
HMAC_MD5.

Because the purpose of this "inner" hash is to provide compression,
not authentication, I think it is not reasonable to require a secret
pre-shared key between the MN and FA.

I think we have two realistic options at this point:

1) specify a fixed key for usage in the inner HMAC_MD5, or one that
   is derived from information in the RRQ;

2) revert back to MD5 for the inner hash for both CHAP_SPI and
   HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function

Opinions?

As for your second problem (RADIUS AVPs) I think that is not a problem
that should be addressed with this document.  If people want to
support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs
to carry an indication of the fact that HMAC_CHAP_SPI is being used.
Also the home RADIUS server needs to be upgraded to support HMAC_MD5.
It is not in the scope of 3012bis or the mip4 WG to do RADIUS
extensions so I think we just have to understand that HMAC_CHAP_SPI
cannot be supported by existing standard RADIUS servers until
additional specification work has been done.

-Pete

---

From: Alpesh <[email-masked]>
Date: Wed, 20 Oct 2004 06:51:35 -0700

Pete -

regarding the first point, I have no strong preference. Either way is 
fine with me -
use MD5 or HMAC_MD5 for compression to derive the challenge
(don't see a benefit for the later from cryptographic point though).

Regarding the 2nd point, my point is that it is really not usable - 
unless the attributes
are available and there is some spec. which says how Radius should 
interpret it.

I think we are doing a forward reference here. Atleast the text should 
clearly state
this fact, IMO.

-a

---

From: "Charles E.Perkins" <[email-masked]>
Date: Wed, 20 Oct 2004 11:22:05 -0700

Hello Pete,

After looking over the document, I think I'm pretty
much in line with your suggestions...

Pete McCann wrote:

> The problem is the text right   ........ 
>                    <specific text omitted>
> seems to say that HMAC_MD5 replaces both the "inner" and "outer"

I agree that this should be fixed, and probably to say
that HMAC_MD5 only replaces the "enclosing" MD5, not the
inner MD5 as in option (2) below.

> pre-shared key between the MN and FA.

A key is going to be needed by the outer HMAC_MD5, though.

>    HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function

I'm in favor of (2).

> additional specification work has been done.

I agree with this also.

I have some other concerns which I'll put into another e-mail.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Wed, 20 Oct 2004 14:47:53 -0700

>    is derived from information in the RRQ;

Either fixed key or derivation of cleartext data seem to lose the security
potency of HMAC_MD5.

>    HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function

Is this scheme stronger than just using MD5? I think the key question is
how does not having a shared key affect the security strength? And is there
value to use this method of authentication given it's not the designed
HMAC_MD5 algorithm?

>Opinions?

Unless there's some worthwhile security gain using HMAC_MD5 in the
suggested adapted method above, *and* some standardized way to
even accomplish outer authentication function, wondering why should we
proceed with this method?

Maybe this is something we can add later when the details are worked
out?

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 IOS Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

---

From: Pete McCann <[email-masked]>
Date: Wed, 20 Oct 2004 19:35:18 -0500

Hi, Kent,

 > Either fixed key or derivation of cleartext data seem to lose the security

The inner hash is not for authentication, it is for compression.  So,
I am not so worried about "security potency."  What you are saying is
that it might be somewhat easier for someone to find a different RRQ
that hashes to the same value; but, we still have the challenge value
as input to the outer HMAC_MD5, which is still secured with a key.

 > value to use this method of authentication given it's not the designed

We probably don't have the expertise in this group to answer this
question.

I do not recall the input from the security review that led to the
addition of HMAC_MD5.  Did it ask for HMAC_MD5 to be added to both the
main default algorithm and the RADIUS SPIs, or just the main default
algorithm?  Does anyone have a pointer to the original input?

If there was no request from security folks to add HMAC_MD5 to the
RADIUS SPIs I would not mind deleting it.

 > proceed with this method?

I do not think there is a requirement to synchronize our draft with
RADIUS extensions.

 > Maybe this is something we can add later when the details are worked

This is certainly one possible way to resolve the issue.

-Pete

---

From: Alpesh <[email-masked]>
Date: Thu, 21 Oct 2004 16:47:01 -0700

Kent -

In general HMAC based auth. provide better security than just MD5.

Also, I agree with the group assessment that the inner algorithm can be
just MD5 as it is just compressing the message.

I would agree with Pete regarding point #2 and we can proceed from here.

Would really like to see text which mentions that nce AAA attributes which
use HMAC_MD5 are not defined today. That will help people avoid confusion.

Beyond that, I think there is no other reason that this draft should be 
delayed
any further.

Rgds
-a

---

From: Kent Leung <[email-masked]>
Date: Thu, 21 Oct 2004 17:13:31 -0700

Option #2 seems reasonable to me then..

Kent