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

From: [email-masked]
Date: Wed, 25 Sep 2002 20:32:20 -0400

Bernard Aboba <[email-masked]> wrote:
...
>
>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.
>

Okay, so with hashing / nonce processing as of today in [MIPKEYS]....
How about the following (based on your previous text proposal)?

"5.2  Key Material vs. Session Key

As described in section 1.6, session keys and nonces are generated
by the AAAH and are transmitted to the home agent, foreign agent
and mobile node. Security associations destined for the home and
foreign agents are established via transmission of session keys and SPIs, protected by transmission-level security as defined in [DIAMBASE]. Where it is necessary to protect the nonces, session keys and SPIs from untrusted Diameter agents, end-to-end security mechanisms are required, such as the CMS application [CMS], a work in progress.

The mobile node security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 64 bits [MIPKEYS], however it is strongly recommended to generate a random [RANDOM] value of at least 128 bits. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys.

More details of the MN-HA and the MN-FA session key creation procedure are found in [MIPKEYS]. Recommended hashing algorithms to be use are HMAC-MD5 and HMAC-SHA1, where HMAC-MD5 MUST be supported [MIPKEYS]. Below follows an example, copied from [MIPKEYS], of the key creation procedure using the HMAC-MD5 hashing algorithm. The hashing algorithm is used to enable session keys to be derived from the long term shared secret and the nonce. The same procedure is used by the AAAH for creation of the session keys sent to the home and foreign agent. 

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

Where:

- AAA-Key is the pre-shared key between the mobile
 node and the AAAH.
- Key material (nonce) is a random [RANDOM] value of at least 64 bits.
- node-address is the mobile node's identity. This is the
 contents of the MIP-Mobile-Node-Address AVP, unless the value
 of the AVP is all zero or ones, in which case of value of the
 User-Name AVP is used instead."

and Section 10, security considerations:

"This specification describes a Mobile IPv4 Diameter Application for
authenticating and authorizing a Mobile IPv4 mobile node. The
authentication algorithm used is dependent upon the transforms
used within the Mobile IP protocol, and [MIPCHAL]. This
specification also defines a method by which the home Diameter server
can create and distribute session keys and nonces for use in
authenticating and integrity-protecting Mobile IP registration messages
[MOBILEIP]. The key distribution is asymmetric since communication with
the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP],
while communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS) MUST be used between Diameter nodes. Where untrusted Diameter agents are present, end-to-end security MUST be used, via mechanisms such as the CMS application [CMS], a work in progress.

Nonces are sent to the mobile node, which are used to generate
the session keys via the HMAC-MD5 one-way function. If the nonces
are compromised, then the pre-shared key between the
mobile node and the home Diameter server would be vulnerable to
an offline dictionary attack. To prevent this, the pre-shared
key between the mobile node and the home Diameter server SHOULD
be a randomly chosen quantity of at least 96 bits.

Since the session key is determined by the long-term secret and
the nonce, the nonce SHOULD be temporally and globally unique;
if the nonce were to repeat, then so would the session key.
To prevent this, a nonce is strongly recommended to be random [RANDOM] value of at least 128 bits. The long-term secret between the MN and HA MUST be periodically refreshed, to guard against recovery of the long-term
secret due to nonce reuse or other factors. This is accomplished
using out-of-band mechanisms, which are not specified in this document.

It should also be noted that it is not recommended to set the MIP-
Session-Key AVP value equal to zero, since keeping session keys for a
long time (no refresh) increases the level of vulnerability."

/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 17:46:15 -0700 (PDT)

> How about the following (based on your previous text proposal)?

Looks fine.