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

From: [email-masked]
Date: Wed, 24 Oct 2001 09:54:49 -0400

Hi,
 
I originally sent this message a couple days ago, but I'm not sure if it got
thru:
 
I believe that any potential vulnerability associated with repeating the
high order challenge byte is de minimus.  In fact, repeating the high order
byte may improve the security.
 
Depending on how often the MN-AAA Authenticator is used, the likely
Challenge (FAC) size (at least in 3GPP2 networks) will be between 4 bytes
(32-bits) and 16 bytes (128-bits).  For this reason, the high order byte
will always be repeated.  However, assuming that MD5 is a cryptographically
strong one-way function, repeating the high order byte is somewhat
irrelevant.  In fact, an argument is possible that repeating the high order
byte improves the MAC's security.  I have often seen algorithm registers
(typically encryption algorithms) loaded repeatedly with keys or randomness
- primarily to provide a value other than fixed 1s or 0s in unfilled
registers.
 
According to RFC 1321, a message MACed by MD5 must be a multiple of 512
bits.  Actually, the message must be 448-bits long (64-bits is reserved to
specify the message length).  If a message is less than 448-bits long, a "1"
and string of "0" is padded to the message to extend its length to 448-bits.
Let us assume the following:
 
MN-AAA key = 16 bytes (128-bits)
MD5 hash = 16 bytes (128-bits)
FAC = 16 bytes (128-bits)
 
Therefore, the total message (in RFC 3012) to MAC (including 1 high order
byte) is 49 bytes (392 bits).  448-bits - 392 bits = 56-bits.  Thus, every
MN-AAA authenticator will be computed with the least 120-bits always known
(56-bit padding and 64-bits message length field).  Without the high order
byte repeated, then 128-bits are always known to the cryptanalyst (at least
before he sees the FAC).  
 
One way of looking at the authentication process is that the security
strength resides in the length of the secret authentication key and strength
of the cryptographic algorithm.  The challenge randomness ensures that each
authenticator is unique (no replay).  If portions of the randomness are
copied into unused registers, you still retain the uniqueness of the
original randomness.
 
If we assume that MD5 is a secure one-way function, then this authenticator
calculation is acceptable.  If you're concerned about MD5, then I suggest
SHA-1, HMAC-MD5, or HMAC-SHA-1.
 
Regards,
 
Chris

**********************************************************
Christopher Carroll
Verizon Wireless
Advanced Technology Strategy and Standards
Chair TIA TR-45 AHAG
Ph: 508-330-3401
[email-masked]
<mailto:[email-masked]> 
**********************************************************

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 31 Oct 2001 13:09:00 -0600

Hi All;
 
I thought that I have posted this but apparently not.
Concerning the STALE_CHALLENGE issue, the following is what I think is the
issue and a suggested fix.
I believe after reading section 3.2., RFC3012, anyone can come up with the
following concepts which has been highlighted and addressed directly or
indirectly:

1.	The term of unused challenge. Paragraph 1 section 3.2.

          "Foreign Agent MUST check that the MN-FA Challenge extension
exists, and that it contains a challenge value previously unused by the
Mobile Node. "

2.	The term of previously used challenge. Paragraph 3, section 3.2

          "If a mobile node retransmits a Registration Request with the same
Identification field and the same Challenge extension, and the Foreign Agent
still has 
            a pending Registration Request record in effect for the mobile
node, then the Foreign Agent forwards the Registration Request to the Home
Agent again.  
            In all other circumstances, if the Foreign Agent receives a
Registration Request with a Challenge extension containing a Challenge value
previously 
           used by that mobile node, the Foreign Agent SHOULD send a
Registration Reply to the mobile node containing the Code value
STALE_CHALLENGE."

3.	The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.

          "The Foreign Agent MUST NOT accept any Challenge in the
Registration Request unless it was offered in last successful Registration
Reply issued to the 
            Mobile Node, or else advertised as one of the last
CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
immediately preceding 
            Agent advertisements.  If the Challenge is not one of the
recently advertised values, the foreign Agent SHOULD send a Registration
Reply with Code 
            UNKNOWN_CHALLENGE (see section 10)."
As per paragraph 4, section 3.2, it is clear that any CHALLENGE value which
is not one of the last advertised in the Agent Advertisement message
"CHALLENGE_WINDOW" nor the one received in the last Registration Reply
Message is considered UNKNOWN_CHALLENGE. 
This contradicts with paragraph 1 and 3 which suggest that there are USED
CHALLENGES.
I believe the RFC needs to identify the following:<?xml:namespace prefix = o
ns = "urn:schemas-microsoft-com:office:office" />
1.      USED_CHALLENGE_WINDOW with a default value of 2 just like the
CHALLENGE_WINDOW.
2.      The meaning of the USED Challenge is any challenge that has been
used in a RRQ message and accepted by the PDSN as a valid CHALLENGE and PDSN

       relayed/generated a RRP in response to that RRQ message.
3.      "In all other circumstances" in paragraph 3 is very vague. We may
need to elaborate a little bit to explicitly say that STALE_CHALLENGE will
be generated 
      whenever a USED CHALLENGE is sent in a RRQ message. 
 
NOW the UNKNOWN CHALLENGE becomes any Challenge value other than the one
which was offered in last (NO Successful is mentioned) Registration Reply
issued to the Mobile Node, or else advertised as one of the last
CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
immediately preceding Agent advertisements, or else has previously been used
as one of the last USED_CHALLENGE_WINDOW (to be added to section 9).
 
I hope this would help in clarifying this issue.

Regards; 

Ahmad Muhanna 

 -----Original Message-----
From: Muhanna, Ahmad [RICH1:2Q23:EXCH] 
Sent: Monday, October 22, 2001 9:02 AM
To: [email-masked]'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

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]
<mailto:[email-masked]> ] 
Sent: Monday, October 22, 2001 4:18 AM 
To: [email-masked] 
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question 

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? 

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]
<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: 

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. 

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