Subject: RE: [mobile-ip] AAA keys security review

From: Phil Roberts <[email-masked]>
Date: Wed, 13 Mar 2002 13:01:38 -0500

I'm inclined to agree unless there are surprise comments
from the IESG review.  We'll have to make sure there is a
clear recommendation to use HMAC-MD5 (I haven't looked at the
text for -09 either ....).

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, March 13, 2002 12:25 PM
> To: Phil Roberts; Pat R. Calhoun
> Cc: [email-masked]
> Subject: Re: [mobile-ip] AAA keys security review
> 
> 
> 
> Hello Phil,
> 
> The relevant material from gen-key has been merged into 
> version ...-09 I can carry out the other two recommendations 
> in a newly revised draft produced after the upcoming IETF.  
> However, I should think that these are relatively small 
> things, and should not require a new working group last call. 
>  In other words, either version ...-09 or the newly revised 
> document could conceivably go directly for IESG consideration.
> 
> I can describe the nature of the (mobile node<-->AAA) 
> security association, but I would appreciate any help that 
> someone might offer (including, as always, actual text).
> 
> What do you think?
> 
> Regards,
> Charlie P.
> 
> 
> 
> Phil Roberts wrote:
> > 
> > Hi folks,
> > 
> >    I asked Luis Sanchez (chair of ipsp WG) to review this 
> doc for us 
> > and he did.  We're very grateful.  Here's the note he sent with his 
> > review embedded.  Please note, this was done on
> > version -08 before Charlie produced version -09.
> > 
> > Phil
> > ------------------------------
> > 
> > Hi Phil,
> > 
> > Enclose you will find a security review of 
> > draft-ietf-mobileip-aaa-key-08.txt. The findings have input 
> from the 
> > following individuals listed in alphabetical order:
> > 
> > - S. Bitan
> > - S. Kent
> > - H. Orman
> > 
> > Any mistakes are solely mine. Thanks!
> > 
> > Luis
> > 
> > -------------------------------------------
> > 
> > General Observation: Overall the document is in reasonable shape. I 
> > would merge this document with  draft-ietf-mobileip-gen-key-01.txt. 
> > The document should however, undergo editorial review. One major 
> > concern is the lack of a succinct security goal statement. Such 
> > statement would be beneficial to the reader and would avoid 
> confusion 
> > "why isn't this protected, why is this protected, should this be 
> > protected, etc."
> > 
> > In the IPsec context, security associations are simplex and 
> uniquely 
> > identified by the triple (IP address, SPI, protocol). It is 
> not clear 
> > if there is a 1to1 mapping between IPsec security 
> associations and the 
> > "security associations" between mobile nodes and AAA 
> servers. Perhaps 
> > this is discussed in some other document.
> > 
> > **Recommendation: Add text to explain the nature of the AAA 
> server to 
> > Mobile Node security association.
> > 
> > - The mobile node calculates a key by hashing a 
> concatenation of bits 
> > that include the AAA-key. How does the mobile get this key? Does it 
> > arrive on the wire? If it arrives on the wire it better be 
> encrypted 
> > as a result of using yet some other protocol exchange to 
> provide: peer 
> > authentication, data integrity and confidentiality. Are we 
> assuming a 
> > security association using IKE between the MN and its home 
> AAA server 
> > and that is how this AAA-key is generated? Otherwise, if 
> > pre-configured (manually? )how is this different from 
> pre-configuring 
> > an MN-HA key. I might be asking the obvious here by not 
> understanding 
> > the protocol exchanges.
> > 
> > **Recommendation: Add text to explain how the AAA-Key is 
> generated and 
> > configured in the MN and other peers.
> > 
> > - For key derivation, the document recommends using one of the 
> > algorithms listed in the following table
> > 
> >       Algorithm Identifier   Name                Reference
> >       ---------------------  ------------------  ------------
> >       1                      MD5/prefix+suffix   RFC 2002 [11]
> >       2                      HMAC MD5            RFC 2104 [6]
> >       3                      SHA-1               FIPS 180-1 [10]
> > 
> > Back in 1996 Bellare, Canetti and Krawczyk published a 
> paper on crypto 
> > discussing how a keyed hash function used in 
> append/pre-append mode is 
> > more susceptible to the "divide and conquer" attack, although 
> > impractical, than a keyed-hashed function using a keyed-IV instead. 
> > They also proved that cryptographically HMAC is as strong 
> as the hash 
> > function used with it. One can no make such a statement of a 
> > keyed-hash function used in prefix+suffix mode. As such, 
> IPsec dropped 
> > RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 the latter one 
> truncated to 
> > 90bits. Another potential problem with MD5/prefix+suffix 
> could come in 
> > if the nonsecret component of the key is variable length.  In that 
> > case, if you were using MD5(secret, nonsecret) = newkey, 
> then someone 
> > might be able to see newkey and later observe an exchange where 
> > nonsecret' =
> > nonsecret|1. Then the key would be MD5(newkey, 1) = 
> newkey'.  You have
> > to analyze the protocol very carefully to assure that this doesn't 
> > happen, but if you use HMAC, you don't have to worry about it.
> > 
> > **Recommendation: Advise reader to derive keys using: key = 
> > HMAC-MD5(AAA-key, {Key Material | node-addres})
> > 
> > or HMAC-SHA1. Do not recommend using MD5/prefix+suffix or 
> just SHA-1.
> > 
> > - The AAA key need to be chosen at random (or using a 
> > cryptographically strong pseudo-random generator seeded 
> with a random 
> > seed), and periodically refreshed.  The document makes reference to 
> > RFC1750 and this is appropriate however, it does not mention 
> > refreshing. It is not clear that we can recommended a specific 
> > frequency for key changes as the attacks refered to above may seem 
> > practically infeasible.  However, periodic key refreshment is a 
> > fundamental security practice that helps against potential 
> weaknesses 
> > of the function and keys, and limits the damage of an exposed key.
> > 
> > **Recommendation: Add a statement to indicate that both the Mobile 
> > Node and the AAA server MUST refresh their shared AAA-key. 
> This could 
> > be done via the AAA protocol or some other out-of-band 
> mechanism. For 
> > in-band refreshing the new key MUST be encrypted, authenticated and 
> > its integrity MUST be protected while on transit.
>

---

From: [email-masked]
Date: Sat, 16 Mar 2002 00:20:49 +0200

Hi Charlie,

> This is fixed in revision -09.

Great - just wanted to make sure nothing got dropped.

John