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

From: "Qi, Emily H" <[email-masked]>
Date: Fri, 20 Sep 2002 13:23:33 -0700

Bernard,

How is this randomly chosen pre-shared key (MN-AAAH) distributed? What kind
of out-of-band mechanism do you recommend? Should we have a draft to address
this issue? Or is it a deployment issue?

Regards,
Emily Qi

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Friday, September 20, 2002 6:35 AM
To: [email-masked]
Subject: [AAA-WG]: Issue 368: Security issues with MIP-12

Issue 368: Security issues with MIP-12
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September 17, 2002
Reference:
Document: MIP-12
Comment type: T
Priority: S
Section: 5.2, 10
Rationale/Explanation of issue:

There is a potential weakness in the generation of MN session keys.
The size of the MN-HA long term shared secret is not specified.. Recommend
requiring this to be randomly chosen and at least 96-bits.
There is also no requirement that the session keys be temporally and
globally unique, and since they are only dependent on a 64-bit nonce, the
MN IP address, and the long-term secret, they could repeat.

While the keys are all encrypted, I'd suggest a larger nonce (128-bits),
and some additional mixing (such as by adding the FA IP address to the
hash).

Specific suggested changes below:

Section 5.2:

"5.2  Key Material vs. Session Key

   As described in section 1.6, each mobile IP security association that
  is generated by the AAAH will be propagated to the mobility agents
   and the mobile node in two different ways. All security associations
   destined for the home and foreign agents are sent as session keys,
   protected by IPSec or TLS as defined in the [DIAMBASE]. If strong
   authentication and confidentiality of the session keys is required
   due to involvement of intermediate Diameter agents, it is recommended
   that the CMS security application [CMS] be used.

   Since the security associations for the mobile node are propagated
   through the mobile IPv4 protocol, the security associations are
   always sent in the form of key material, which the AAAH computes by
   generating a random [RANDOM] value of at least 64 bits. The mobile
   node will then use the key material to derive the session key to be
   used for the security associations.

   The following is an example of a session creation procedure, which
   the mobile node has to comply with, using HMAC-MD5 as the hashing
   algorithm to derive the key (of course the same session creation
   procedure must also be used by the AAAH for the opposite key sent to
   the home agent and foreign agent). Additional algorithms are
   supported, and listed in [MIPKEYS], where also the HMAC-SHA1
   algorithm is recommended to be used.

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

      Where:

         - AAA-Key is the long term secret shared between the mobile
           node and the AAAH.
         - Key material 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."

Some references to CMS need to be cleaned up, and
a 64-bit nonce is probably not enough. Reword to:

"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 generates
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.

The session key creation procedure is described below in more
detail. HMAC-MD5 is used as the hashing algorithm 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. Additional supported algorithms are
listed in [MIPKEYS], where the HMAC-SHA1 algorithm is recommended. (so why
is HMAC-MD5 used in the examples?)

key = HMAC-MD5(AAA-key,{Nonce | MN-address | FA-address})

Where:

- AAA-Key is the pre-shared key between the mobile
  node and the AAAH.
- Nonce is a random [RANDOM] value of at least 128 bits.
- FA-address is the address of the foreign agent.
- MN-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."

Section 10, security considerations:

"   This specification describes the Diameter Application necessary to
   authenticate and authorize a Mobile IP mobile node. The
   authentication algorithm used is dependent upon the transforms
   available by the Mobile IP protocol, and [MIPCHAL]. This
   specification also defines a method by which the home Diameter server
   can create and distribute session keys to be used to authenticate
   Mobile IP registration messages [MOBILEIP]. The key distribution is
   asymmetric due to the fact the keys to the mobile node have to be
   propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the
   mobility agent keys are propagated via the Diameter protocol. This
   means that the keys destined to the mobility agents are always
   protected by IPSec or TLS as defined in [DIAMBASE], when deployed
   without any Diameter agents, or protected using the methods defined
   in [CMS], when deployed in an environment that includes Diameter
   agents. The keys destined for the mobile node are always sent as key
   material, which is used to derive the actual keys, which means that
   it does not expose any data that could be used in an attack aimed at
   recovering the long term key shared between the mobile node and the
   home Diameter server.

   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. Therefore, must the long-term
   shared secret between the mobile node and the home Diameter server
   also be periodically refreshed, by utilizing some out-of-band
   mechanism, since this shared secret cannot be refreshed by any in-
   band mechanism.

   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 vulnerability of the system."

Clarification of vulnerabilities and keying terminology needed. Reword as
follows:

"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 of at least 128 bits is REQUIRED.
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."

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Sep 2002 17:13:37 -0700 (PDT)

> this issue? Or is it a deployment issue?

It's a deployment issue.