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

From: "Lipford, Mark" <[email-masked]>
Date: Thu, 18 Oct 2001 10:17:23 -0500

We would like to hear a response to this question.  We are in the process of
interop testing and have run into a probllem and would also like to hear the
groups thoughts on this.

-----Original Message-----
From: Nish Abrol [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 12:14 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [mobile-ip] URGENT - rfc3012 interpretation question

Pat/Charlie,

Really appreciate any insights into this really important interop issue for
cdma2000:

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.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 19 Oct 2001 16:20:30 -0500

I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike

"Robert J Marks" <[email-masked]> on 10/18/2001 04:27:49 PM

Please respond to [email-masked]

Sent by:  "Robert J Marks" <[email-masked]>

To:   [email-masked], [email-masked],
      [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question

Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [mobile-ip] URGENT - rfc3012 interpretation question

Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

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)

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.

Thanks
Nish Abrol
Qualcomm, Inc.

---

From: [email-masked]
Date: Fri, 19 Oct 2001 16:26:18 -0500

Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security issue
is null and void.

Mike

"Ahmad Muhanna" <[email-masked]> on 10/19/2001 04:20:30 PM

Sent by:  "Ahmad Muhanna" <[email-masked]>

To:   "'mobile-ip @sunroof.eng.sun.com'" <[email-masked]>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 21 Oct 2001 22:04:15 -0500

I hope that this discussion is for the purpose of ensuring a secure and
robust Mobile IP protocol rather than defending certain implementation.

Having said that, I would like to confess that, at the moment, I can not
provide a reference for the reduced security or the introduced weakness,
because of using the High-Order byte of the Challenge at two fixed different
locations of the payload in calculating the MN-AAA authenticator.

However, as most of us know, MD5 is not very strong in calculating digital
signature. In other words the MD5 collision resistance is not impossibly
immune as per the following references.

RFC1321 says in conclusion:
"The MD5 message-digest algorithm is simple to implement, and provides a
"fingerprint" or message digest of a message of arbitrary length. It is
conjectured that the difficulty of coming up with two messages having the
same message digest is on the order of 2^64 operations, and that the
difficulty of coming up with any message having a given message digest is on
the order of 2^128 operations. The MD5 algorithm has been carefully
scrutinized for weaknesses. ...."

Please, let us remember this RFC was written on April 1992, at the age of 35
MHZ PC's.

ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf (1996)

"... customers should note that while the continued suitability of MD5 for
applications requiring collision-resistance is in question, the use of MD5
in other roles, for example as part of a mechanism for random number
generation, is still considered safe. ..."

http://www.math.fu-berlin.de/~guckes/md5/

".... In 1996, MD5 was all but broken by a German cryptographer, Hans
Dobbertin. Although MD5 was not completely broken at that time, it was
discovered to have such serious weaknesses that no one should keep using it
to generate signatures..."

It may need a special investigation to find out the weakness introduced by
the literal implementation of section 8 in RFC3012. However, we know for
fact that the other interpretation does not introduce any new form of
weakness or patterns.

Therefore, taking all of this and the fact that the (Least-order 237 bytes
from Challenge) mentioned in section 8 of RFC 3012 was there to make sure
that no more than 253 bytes can be sent by PDSN/FA to RADIUS in a RADIUS
attribute, I strongly believe that any wise implementation should not
intentionally aid the Crypto analytical attacker and make his/her job a
little easier by introducing a pattern in the hashed payload.

Regards;

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 4:26 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security
issue
is null and void.

Mike

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.

 << File: Internet HTML >>

---

From: [email-masked]
Date: Mon, 22 Oct 2001 08:03:04 -0500

Agreed, however we have to consider legacy code exists and two different
code bases may already be in the field.

We'll be able to provide more feedback once we get beyond this issue.
AFAIK, this is the only RFC3012 problem so far.

Mike

Erik Nordmark <[email-masked]> on 10/22/2001 04:18:09 AM

Sent by:  Erik Nordmark <[email-masked]>

Whatever the best interpretation will be, the fact that this is subject
to interpretation tells me that RFC 3012 needs to be revised ASAP
with a description which is clear on this point.

Are there other issues that aren't (or weren't) clear to implementors
of RFC 3012? Any issues that required sending a question on a mailing
list or to the authors would seem like a good reason to get the
spec clarified.

  Erik

>----- Begin Included Message -----<

Date: Fri, 19 Oct 2001 15:47:24 -0500
From: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
To: [email-masked]

I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.

>----- End Included Message -----<

---

From: [email-masked]
Date: Mon, 22 Oct 2001 07:58:43 -0500

And I hope that you are not spreading FUD to protect an implementation.
When you claim that there is a security problem in a protocol or algorithm,
you need to back it up with solid evidence, which no one has done yet.

If there is a genuine security problem with my interpretation, I would like to
know and
will make the appropriate apologies then.

However I do agree that concensus in the crypto community is that using MD5
is risky.  That is another problem.  If MD5 has such issues we should be using
a better hash, such a SHA-1, I suppose.

Mike

"Ahmad Muhanna" <[email-masked]> on 10/21/2001 10:04:15 PM

Regards;

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 4:26 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Mike

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 22 Oct 2001 09:01:34 -0500

I agree. 
I believe there is a couple of issues need to be clarified.
One regarding Stale Challenge.
The other regarding MN using the CHALLENGE received in the RRP with error
code and the meaning of successful Registration Request.

I will provide details at later time. 

Regards;

Ahmad Muhanna

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, October 22, 2001 4:18 AM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

  Erik

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 22 Oct 2001 09:03:18 -0500

I am definitely not trying to protect a certain implementation here. 
Those who are familiar with this issue's implementation know that it is less
than one or two lines of code change. 
Unless certain implementation needs a huge change!

Regards;

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 22, 2001 7:59 AM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

If there is a genuine security problem with my interpretation, I would like
to
know and
will make the appropriate apologies then.

However I do agree that concensus in the crypto community is that using MD5
is risky.  That is another problem.  If MD5 has such issues we should be
using
a better hash, such a SHA-1, I suppose.

Mike

Regards;

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 4:26 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Mike

Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

-Mike

Bob

-----Original Message-----

Pat/Charlie,

Thanks
Nish Abrol
Qualcomm, Inc.