Subject: RE: [Mip4] Question regarding 3012bis

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 21 Oct 2004 11:27:21 -0400

Hi Pete,

Regarding your inquiry on the security review that led to the addition of
HMAC-MD5, the following was the issue brought up by AD for RFC3012bis
(mobile IP ver 3) document:

Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of computing
the Generalized Mobile IP Authentication Extension's authenticator field
using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in
the method described in Section 8 is less secure than HMAC-MD5 [6], and
should be avoided whenever possible."

Regards,
Jayshree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete
McCann
Sent: Wednesday, October 20, 2004 7:35 PM
To: Kent Leung
Cc: [email-masked]; Henrik Levkowetz; Alpesh Patel
Subject: Re: [Mip4] Question regarding 3012bis

Hi, Kent,

Kent Leung writes:
 > 
 > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote:
 > 
 > 
 > >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;
 > 
 > Either fixed key or derivation of cleartext data seem to lose the
security  > potency of HMAC_MD5.

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.

 > >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
 > 
 > 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?

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.

 > >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?

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  >
out?

This is certainly one possible way to resolve the issue.

-Pete

 > Kent
 > 
 > 
 > 
 > >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  > >  > >  >
>Alpesh Patel writes:  > >  > 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/

-- 
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: Thu, 21 Oct 2004 20:01:42 -0500

Jayshree,

Thanks very much.

This text doesn't seem to explicitly ask for the HMAC_MD5 method to be
added to Section 8.  Maybe it is just a statement about Section 8
compared to the new default method.  One way to go is to cut-and-paste
this text into the security considerations and delete the HMAC_MD5
RADIUS method from Section 8.

Opinions?

-Pete