Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key

From: [email-masked]
Date: Thu, 27 Sep 2001 11:21:51 -0400

Hi Erik,

I have the following comments regarding your concerns with the current
aaa-keys procedure:

1) Keying material is used between the MN and FA (or MN and HA) because a
Key Agreement Protocol is used as opposed to simply encrypting and
distributing the MN-HA or MN-FA key.  The reason for using a key agreement
protocol is that the MN-FA link and/or MN-HA link may be over-the-air which
is inherently more vulnerable to eavesdropping and cryptanalysis.  Please
review the attached comments, originally sent to Charlie Perkins and Pat
Calhoun, regarding the vulnerabilities associated with their original
proposal to simply encrypt the MN-HA and/or MN-FA key for transmission to
the MN.

Key Agreement Protocols are well understood and have been used for many
years in GSM and North American cellular/PCS networks to enable secure
session key generation (in a symmetric/secret key system).

Note: It is assumed that AAA links to other MIP entities (AAA, HA and FA)
will be protected.

2)  With regard the AAA-to-AAA, AAA-to-HA and AAA-to-FA links, 3G Wireless
providers intend to protect these links using one of several techniques: 1)
IPsec, 2) Linked encryption boxes, or 3) private commication links.
Distribution of AAA keys is NOT OUR ONLY CONCERN on these links.  We intend
to encrypt all data between the AAA and HA/FA for subscriber privacy reasons
and other security concerns.  Assuming we intend to protect these links
using techniques outside the scope of MIP, it is inefficient from our
perspective to utilize a more elaborate key distribution scheme between the
AAA and other network infrastructure components (which are controlled by the
service providers).  In other words, we'll already have an SA established
between these entities and don't need to deal with bootstrapping even
another SA!

I do recognize that other implementations of MIPv4 will require more
inherent security compliance (architecturally built-in SA establishment
schemes) because most users/system operators will not have the security
expertise/resources of large service providers.  I recommend that a separate
procedure/protocol be developed to satisfy this requirement without delaying
the implementation of the existing scheme.

thanks,

chris

>Hi Pat,
>
>Thanks for taking to time out to talk about security issues.  Verizon
>Wireless has reviewed your AAA Registration Keys for Mobile IP draft and we
>are concerned about how the MN-FA and MN-HA key are encrypted.  Feel free
to
>distribute these comments to any interested party.
>
>The scheme employs a fixed encryption pad (or mask) which may expose the
>MN-FA and MN-HA key to an attacker.  We assume that the mask is fixed
>because it is generated using the following formula:
>
>mask = MD5 (AAA-key || node-address || AAA-key)
>
>If the AAA-key is the shared secret between the MN and Home AAA server, it
>will likely not change for the life of the MN user's subscription because
it
>is expensive for the Mobile IP provider to distribute the AAA-key (we
define
>it as the MN-AAAh key) to the MN.  Also, if the "node-address" is the MN's
>NAI, the mask will remain constant for the life to the subscription.  In
GSM
>and TIA cellular networks, the root key (shared secret between the Mobile
>Station and Authentication Center) is never changed, i.e., MS retains the
>same root key for years (note: other session security keys are continously
>generated from the root to ensure security).  Note: your draft proposes
>using the MN's home IP address as the "node-address", however, based on the
>last TSG-P meeting, I believe you were planning on changing it to the MN's
>NAI.
>
>Fixed Mask Problems:
>
>1)  If the encryption mask remains fixed, any FA that interacts with a
>particular MN will have the ability to recover the encryption mask for both
>MN-FA and MN-HA key distribution.  This may not be significant for Verizon
>Wireless initially because all the FAs will be controled by us.  But
>eventually we may allow our subscribers to interact with Mobile IP networks
>controlled by other companies, the government, or individuals.  Anyone with
>access to these FAs with be able to recover the fixed encryption mask and
>subsequently recover the MN-FA and/or MN-HA key by eavesdropping on the
>MN-to-FA air interface.  The attack works as follows:
>
>The FA normally sends the MN-FA key update in an Unsolicited MN-FA key From
>AAA Subtype message (included in the Registration Reply).  The MN-FA is
>encoded as follows:
>
>Encoded MN-FA key = MN-FA key XOR Fixed Encryption Mask
>
>Fixed Encryption Mask = MD5 (MN-AAAh key || MN NAI || MN-AAAh key)
>
>The FA also recieves the MN-FA key via its AAA server.
>
>The FA recovers the Fixed Encryption Mask using the following:
>
>Fixed Encryption Mask = MN-FA key XOR (MN-FA key XOR Fixed Encryption Mask)
>
>By eavesdropping on any future MN-FA or MN-HA key updates on the air
>interface, an attacker with access to any FA that interacts with the MN
will
>have the ability to recover either key.
>
>Imagine the scenarion in which Verizon Wireless allows the FBI to set up
its
>own Mobile IP network that interacts with our service.  Whenever a Verizon
>Wireless subscriber accesses thier network, they save the Fixed Mask
>associated with that subscriber.  The same thing could happen on a
>University campus in which hackers are actually running the Mobile IP
>network.  An individual, out of the goodness in his heart, could offer free
>service to subscribers while they happen to be within the vacinity of his
>network (while stealing MN-FA/MN-HA masks).
>
>Finally, the MN-FA key may be more important than intended for Mobile IP
>alone.  The MN-FA key, as a shared secret between the MN and FA, can enable
>other security services such as Radio Access Layer Encryption and Message
>Authentication.
>
>2)  Because the mask is fixed, an eavesdropper on the air interface is able
>to track changes made to the MN-FA or MN-HA key whenever the keys are
>updated.  Consider the following:
>
>Encoded MN-FA key #1 = MN-FA key #1 XOR Fixed Encryption Mask
>
>Encoded MN-FA key #2 = MN-FA key #2 XOR Fixed Encryption Mask
>
>Delta MN-FA key = Encoded MN-FA key #1 XOR Encoded MN-FA key #2
>
>As long as the MN-FA key is a cryptographically strong secret key (randomly
>or pseudo-randomly generated), you have the situation in which the MN-FA
key
>is acting as a One-time Pad for the fixed Mask!  I don't believe this was
>your original intent.
>
>Because MD5 is a one-way function, I don't believe that an attacker can
>actually recovery the MN-FA (or MN-HA) key.  However, you are leaking
>information about the key.  A real cryptographer (not me) might be able to
>exploit this.
>
>We propose the following enhancements to draft-ietf-mobileip-aaa-key-04.txt
>to eliminate this vulnerability:
>
>Instead of distributing an encrypted key, we recommend that the procedure
>utilize a key agreement scheme.  The procedure works as follows when
>generating the MN-HA key:
>
>1.  The AAA server determines the "node-address" of the MN with
node-address
>= NAI.
>
>2.  The AAA server generates RAND (64 bits recommended).  RAND should be
>randomly or pseudo-randomly generated based on RFC 1750.
>
>3.  The AAA server computes the following:  MN-HA key = MD5 (MN-AAAh key ||
>MN NAI || HA IP address || RAND).
>
>4.  The AAA server inserts the RAND (instead of the encoded MN-HA key) into
>the Key extension in the "RAND" field (which replaces the MN-HA Encoded Key
>data field).  Note: the AAA server must independently delivery the MN-HA
key
>to the HA.
>
>5.  The MN computes the following:  MN-HA key = MD5 (MN-AAAh key || MN NAI
>|| HA IP address || RAND).
>
>The procedure for MN-FA key generation is:
>
>1.  The AAA server determines the "node-address" of the MN with
node-address
>= NAI.
>
>2.  The AAA server generates RAND (64 bits recommended).
>
>3.  The AAA server computes the following:  MN-fA key = MD5 (MN-AAAh key ||
>MN NAI || FA IP address || RAND).
>
>4.  The AAA server inserts the RAND (instead of the encoded MN-FA key) into
>the Key extension in the "RAND" field (which replaces the MN-FA Encoded Key
>data field).  Note: the AAA server must independently delivery the MN-FA
key
>to the FA.
>
>5.  The MN computes the following:  MN-FA key = MD5 (MN-AAAh key || MN NAI
>|| FA IP address || RAND).
>
>We do not alter the structure of the Unsolicited Key extension.  We only
>replace the Encoded key with RAND.  While RAND is only 64-bits (or even
only
>32-bits), the MN and Home AAA server still generate a 128-bit key.  Thus,
we
>reduce air interface overhead while increasing security at the same time.
>
>Security Considerations:
>
>Under our proposal, the MN-HA and MN-FA key are derived from the root
>MN-AAAh key.  If the keys are derived based on a cryptographically secure
>one-way function (e.g. MD5 or SHA-1), compromise of the MN-HA or MN-FA key
>will not compromise the root MN-AAAh key.  If the root MN-AAAh key is
>compromised, the current MN-HA or MN-FA key will be compromised only if the
>attacker observed the RAND transmitted during the Update.  However, this is
>also true for the existing scheme, because the MN-AAAh key is used to
>encrypt the MN-FA or MN-HA key during the Update.
>
>Key agreement is not a new or unproven key distribution method.  It has
been
>used successfully used for years by GSM and TIA for cellular telephone
>security.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 21:16:26 -0700

Christopher,

Thank you very much for your response. I hope it helps Erik understand
that a security review has been done.

PatC