Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12

From: [email-masked]
Date: Wed, 25 Sep 2002 19:28:00 -0400

Bernard Aboba <[email-masked]> wrote:

>> To change functionality given in the HMAC-MD5 example (section 5.2), means
>> changes to the draft-ietf-mobileip-aaa-key-09.txt in which the 64-bit
>> nonce (or key material as it is called) and the mixing are
>> defined. So, this would be more than editorial changes. May be a recommendation
>> of using a nonce of 128-bits instead of a 64-bits would be enough?
>
>The main thing is to make sure the session key is globally and temporally
>unique. If the nonce can be guaranteed to be globally and temporally
>unique, then this is sufficient. If not, then additional "mixing" is
>needed.
>
>Creating a globally and temporally unique nonce is not always so easy. It
>needs to be unique across AAA server reboots; across MNs; across FAs. On
>average, a nonce of N bits will repeat within 2^(N/2) tries, just due to
>probability.
>

key = HMAC-MD5(AAA-key,{Key material | node-address})

As defined in [MIPKEY] - the node-address is iether the mobile node's NAI (if no IP address have been specified) or the mobile node's IP address (if IP address have  been specified). Isn't this enough?

/Tony

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Sep 2002 15:53:07 -0700 (PDT)

> As defined in [MIPKEY] - the node-address is iether the mobile node's NAI
> (if no IP address have been specified) or the mobile node's IP address
> (if IP address have  been specified). Isn't this enough?

The NAI is  invariant, so this implies that the session key will repeat if
the Nonce ("Key material") repeats anywhere that the MN attaches. If the
Nonce is globally and temporally unique, this won't happen -- but it helps
to specify how this might be accomplished. For example, one could combine
a random quantity with a counter, or NTP time, or a combination of
addresses that varies with the attachment point (e.g. CoA, FA address).

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Sep 2002 16:11:49 -0700 (PDT)

> As defined in [MIPKEY] - the node-address is either the mobile node's
>NAI (if no IP address have been specified) or the mobile node's IP
>address (if IP address have  been specified). Isn't this enough?

To be clear, the "Key Material" (e.g. Nonce) is encrypted, so that even if
it were to repeat, the attacker would not know this unless they had gained
control of one of the endpoints (assuming CMS is used).

However, since we *are* talking about a Nonce here (not a true key), it's
questionable whether encrypting it is required at any level, especially
CMS. As noted in the security considerations section, even if the Nonce is
compromised, you can't obtain the Session Key or the Pre-shared key
between MN and HA.

So I think that is an argument for not getting too wrapped around the CMS
axle, at least with respect to Nonces (session keys are another issue).

Assuming that the Nonces may be exposed to untrusted proxies, there is
value in making sure they are globally and temporally unique. You
shouldn't feel bound to explain how implementors will make that happen;
after all, RFC 2865 requires that the RADIUS Request Authenticator (128
bits) be globally and temporally unique, yet provides no guidance.

But judging by results (most RADIUS clients don't satisfy the
requirement), it seems to help to give guidance on how that can be
accomplished. This isn't a particularly major issue, so we can probably
wait until IETF last call (or longer) to figure it out. In the meantime,
let's get a corrected version of -12 on the archive so that we can start
the IETF last call process.