Subject: [mobile-ip] AAA keys security review

From: Phil Roberts <[email-masked]>
Date: Wed, 13 Mar 2002 09:45:10 -0500

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: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Mar 2002 09:25:26 -0800

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.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 19 Mar 2002 18:09:08 +0100

Hi Charlie,

Here's my suggestion for text describing the nature of the Mn<->AAA security
association.

Mobile Node - AAA Security Association
The security association shared between the Mobile Node and the AAA home
server is used for mutual authentication. It is also used when deriving
Mobility Security Associations from the key material distributed via the AAA
and Mobile IP protocols. The Security Association consists of at least one
(potentially more) Security Context. Each Security Context is uniquley
identified by a SPI, and consits of an algorithm identifier, a key, and a
lifetime. Distribution of the Security Association is outside the scope of
this document, one example is that it can be manually configured. When
deriving Mobility Security Associations one calculates a value for the key
using the algorithm and key pointed to by the AAA SPI in the key
distribution extension toghether with the received key material. The
calculated key is then stored in the new Mobility Security Context toghether
with the other necessary data recieved in the key distribution extension.

/Fredrik

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Charles E.
>Perkins
>Sent: den 13 mars 2002 18:25
>To: Phil Roberts; Pat R. Calhoun
>Cc: [email-masked]
>Subject: Re: [mobile-ip] AAA keys security review
>
>
>Hello Phil,
>