Subject: RE: [Mip4] Question regarding 3012bis

From: "Jayshree Bharatia" <[email-masked]>
Date: Mon, 25 Oct 2004 12:19:25 -0400

Hi Pete,

I am fine with your suggestions. If we don't receive any further comments on
this topic by next Monday (Nov 1, 2004), I will update mip4-02 version to
remove hooks for HMAC-MD5 and add risk statement as a part of security
considerations. 

Thanks,
Jayshree

-----Original Message-----
From: Pete McCann [mailto:[email-masked]] 
Sent: Thursday, October 21, 2004 8:02 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'Kent Leung'; [email-masked]'; 'Henrik Levkowetz'; 'Alpesh Patel'
Subject: RE: [Mip4] Question regarding 3012bis

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

Jayshree Bharatia writes:
 > 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: Alpesh <[email-masked]>
Date: Mon, 25 Oct 2004 16:14:54 -0700

Jayshree -

I am fine with Pete's comment. Do you still need any text from me now?

-a

Jayshree Bharatia wrote:

> Hi Pete,
>
> I am fine with your suggestions. If we don't receive any further 
> comments on this topic by next Monday (Nov 1, 2004), I will update 
> mip4-02 version to remove hooks for HMAC-MD5 and add risk statement as 
> a part of security considerations.
>
> Thanks,
> Jayshree
>
> 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
>
>
>  > 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:  >
>
> 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
>  >
>  > 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:
>  >  >
>  >  > >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
>
>  >  > 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.  >
>
>  >  > 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?  >
>
> 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?  >
>
>  >  > Maybe this is something we can add later when the details are 
> worked  >  > out?  >
> 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  > >  > 
> 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  >
>
>  >
>  > --