Subject: RE: [Mip4] Question regarding 3012bis

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 22 Oct 2004 11:35:34 -0400

Alpesh,

Can you suggest the exact text you like to see in RFC3012bis? 

Thanks,
Jayshree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alpesh
Sent: Thursday, October 21, 2004 6:47 PM
To: Kent Leung
Cc: Pete McCann; [email-masked]; Henrik Levkowetz
Subject: Re: [Mip4] Question regarding 3012bis

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

Kent Leung wrote:

>
> 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.
>
>
>
>> 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?
>
>
>> 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
>
>
>
>> 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/
>
>
> -- 
>      |           |                   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]
>
>

-- 
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: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 26 Oct 2004 11:26:07 -0400

Alpesh,

I don't think I will be needing any text unless you like to have any
additional clarification. BTW, we already have suggested text in the
security considerations section of RFC3012bis draft.

Regards,
Jayshree

-----Original Message-----
From: Alpesh [mailto:[email-masked]] 
Sent: Monday, October 25, 2004 6:15 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'Pete McCann'; 'Kent Leung'; [email-masked]'; 'Henrik Levkowetz'
Subject: Re: [Mip4] Question regarding 3012bis

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