Subject: RE: [mobile-ip] rfc3012 interpretation question

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 23 Oct 2001 03:53:29 -0500

A close look at the payload used to calculate the MN-AAA Authenticator shows
the following:
1. The CHALLENGE value is used ONCE as the High-Order byte being byte 0 of
the payload and the Least-Order 237 bytes of challenge being the last bytes
of the payload.
2. The fact that the MN-FA challenge extension was passed to the INNER MD5
as part of the preceding MIP data is irrelevant since what is passed to the
OUTER MD5, used in calculating the MN-AAA authenticator, is JUST a digital
signature or in other words a RANDOM NUMBER.

Regards;

Ahmad Muhanna

-----Original Message-----
From: Pete McCann [mailto:[email-masked]]
Sent: Monday, October 22, 2001 11:40 AM
To: Nish Abrol
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [mobile-ip] rfc3012 interpretation question

Hi, Nish,

I think the language should be taken literally - you should include as 
much of the Challenge as is available, up to 237 bytes, even if that
includes data that was already used.

I don't know enough about the literature on MD5 to say whether
including a given byte twice weakens the security of the digest, but
offhand I don't see why this is necessarily so.  Note that the
"preceding Mobile IP data" is likely to include the Challenge itself
yet again, which is included as an extension to the Mobile IP message.
In any case, I don't think there is a good argument for going against
the plain wording of the document.

-Pete

Nish Abrol writes:
 > Pat/Charlie and other RFC3012 cognizant folks,
 > 
 > A question regarding the  interpretation of section 8 of rfc3012. This 
 > section specifies how to calculate the MN-AAA authenticator. It says:
 > 
 > " To compute the authenticator, apply MD5 [11] 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 "
 > 
 > The question is - if the challenge has less than 237 bytes - should the 
 > high order byte which was already used in the MD5 calculation  be
included 
 > again as part of the  "least-order 237 bytes from Challenge"?
 > 
 > e.g. if the challenge is 50 bytes in length - should the authenticator be

 > calculated  as:
 >      (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)
 > 
 > or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).
 > 
 >        where byte0 is the most significant byte of the challenge.
 > 
 > A strict reading of the RFC seems to suggest (b). However, it seems  that

 > calculating the MD5 authenticator with the same information(high order 
 > byte) at different locations of the payload weakens the authenticator.
 > 
 > So, what was the intention of the RFC and how should it be implemented? 
 > Also, do you know if RFC3012 implementations have participated in any 
 > bakeoffs/interops. If so, how have they interpreted this section?
 > 
 > Your help will be really appreciated.
 > 
 > Thanks
 > Nish Abrol
 > Qualcomm, Inc.
 > 
 > 
 > 
 > 
 > <html>
 > Pat/Charlie and other RFC3012 cognizant folks,<br>
 > <br>
 > A question regarding the&nbsp; interpretation of section 8 of rfc3012.
 > This section specifies how to calculate the MN-AAA authenticator. It
 > says:<br>
 > <br>
 > &quot; To compute the authenticator, apply MD5 [11] computed on the<br>
 > following data, in the order shown:<br>
 > <br>
 > High-order byte from Challenge || Key ||<br>
 > MD5(Preceding Mobile IP data ||<br>
 > Type, Subtype (if present), Length, SPI) ||<br>
 > Least-order 237 bytes from Challenge &quot;<br>
 > <br>
 > The question is - if the challenge has less than 237 bytes - should the
 > high order byte which was already used in the MD5 calculation&nbsp; be
 > included again as part of the&nbsp; &quot;least-order 237 bytes from
 > Challenge&quot;?<br>
 > <br>
 > e.g. if the challenge is 50 bytes in length - should the authenticator be
 > calculated&nbsp; as:<br>
 > &nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator = md5(byte0 || key.......||
 > byte1 through byte49)<br>
 > <br>
 > or (b) authenticator = md5(byte0 || key ......|| <u>byte0 </u>through
 > byte49).<br>
 > <br>
 > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the most significant byte
 > of the challenge.<br>
 > <br>
 > A strict reading of the RFC seems to suggest (b). However, it seems&nbsp;
 > that calculating the MD5 authenticator with the same information(high
 > order byte) at different locations of the payload weakens the
 > authenticator.<br>
 > <br>
 > So, what was the intention of the RFC and how should it be implemented?
 > Also, do you know if RFC3012 implementations have participated in any
 > bakeoffs/interops. If so, how have they interpreted this section?<br>
 > <br>
 > Your help will be really appreciated.<br>
 > <br>
 > Thanks<br>
 > Nish Abrol<br>
 > Qualcomm, Inc.<br>
 > <br>
 > <br>
 > <br>
 > <br>
 > </html>