Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
28 January 2001 Pat R. Calhoun
Sun Microsystems Laboratories
AAA Registration Keys for Mobile IP
draft-ietf-mobileip-aaa-key-03.txt
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
AAA servers, such as RADIUS and DIAMETER, are in use within the
Internet today to provide authentication and authorization services
for dial-up computers. Mobile IP requires strong authentication
between the mobile node and its home agent. When the mobile node
shares a security association with its home AAA server, however, it
is possible to use that security association to create derivative
security associations between the mobile node and its home agent,
and again between the mobile node and the foreign agent currently
offering a care-of address to the mobile node. This document
specifies extensions to the Mobile IP Registration Reply packet that
can be used to distribute such security information to the mobile
node.
Perkins, Calhoun Expires 28 July 2001 [Page 1]
Internet Draft AAA Keys for Mobile IP 28 January 2001
1. Introduction
AAA servers, such as RADIUS [9] and DIAMETER [3], are in use within
the Internet today to provide authentication and authorization
services for dial-up computers. Such services are likely to be
equally valuable for mobile nodes using Mobile IP when the nodes are
attempting to connect to foreign domains with AAA servers. Mobile
IP [7] requires strong authentication between the mobile node and its
home agent. When the mobile node shares a security association with
its home AAA server, however, it is possible to use that security
association to create derivative security associations between the
mobile node and its home agent, and again between the mobile node
and the foreign agent currently offering a care-of address to the
mobile node. This document specifies extensions to the Mobile
IP Registration Reply packet that can be used to distribute such
security information to the mobile node.
AAA servers typically use the Network Access Identifier (NAI) [1] to
uniquely identify the mobile node; the mobile node's home address
is not always necessary to provide that function. Thus, it is
possible for a mobile node to authenticate itself, and be authorized
for connection to the foreign domain, without even having a home
address. However, for Mobile IP to work, the mobile node is required
to have a security association with its home agent. When the
Mobile IP Registration Reply packet is authenticated by the MN-AAA
Authentication Extension [2], the mobile node can verify that the
keys contained in the extensions were produced by the AAA server, and
thus may be reliably used to create security associations with the
home agent, or alternatively with the foreign agent.
The following operations are envisioned between the mobile node, AAA
server, home agent, and foreign agent.
1. When a mobile node travels away from home, it may not have a
security association with its home agent, perhaps because it does
not yet have a home address.
2. When the mobile node first registers away from home, it includes
a MN-AAA Authentication extension if it does not yet have a
Mobility Security Association with a home agent.
3. At the time the information within the MN-AAA Authentication
extension is verified by the AAA server, the AAA server also
generates keys for the mobile node, encodes the keys according
to its own security association with the mobile node, and causes
insertion of the new key or keys along with the Registration
Reply.
Perkins, Calhoun Expires 28 July 2001 [Page 2]
Internet Draft AAA Keys for Mobile IP 28 January 2001
4. If the Reply passes authentication and contains the Unsolicited
MN-HA Key From AAA extension (see section 6), the mobile node
decodes the key according to its security association with
the AAA. The resulting key is used to establish the mobile
node's security association with its home agent, and is used to
authenticate the MN-HA authentication extension.
5. Similarly, if the Reply passes authentication and contains the
Unsolicited MN-FA Key From AAA extension (see section 4), the
mobile node decodes the key according to its security association
with the AAA. The resulting key is used to establish the mobile
node's security association with its new foreign agent, and
is used to compute the authentication data used in the MN-FA
authentication extension.
Any registration reply containing the Unsolicited MN-HA Key
From AAA extension MUST also contain a subsequent Mobile Home
Authentication Extension, created using the decrypted version of the
MN-HA key. Similarly, a reply containing the Unsolicited MN-FA Key
From AAA extension MUST also contain a subsequent Mobile Foreign
Authentication Extension, created using the decrypted version of the
MN-FA key.
2. Security Algorithms
Mobility Security Associations between Mobile IP entities
(mobile nodes, home agents, foreign agents) contain both the
necessary cryptographic key information, and a way to identify
the cryptographic algorithm which uses the key to produce the
authentication information typically included in the Mobile Home
Authentication extension or the Mobile Foreign Authentication
extension. In order for the mobile node to make use of key
information sent to it by the AAA server, the mobile node also has to
be able to select the appropriate cryptographic algorithm that uses
the key to produce the authentication.
For use with the key extensions specified in this document, the
supported security algorithms are also specified. In order for a
mobile node to be able to decode the keys defined in this document,
it MUST share a security association with its' Home AAA server.
The security association is the one by which the mobile node is
instructed to decode the keying material in the the Unsolicited MN-FA
or MN-HA Key From AAA extensions.
Reserved SPI number Name Reference
--------------------- ------------------ ------------
3 MD5/prefix+suffix RFC 2002 [7]
4 HMAC MD5 RFC 2104 [4]
Perkins, Calhoun Expires 28 July 2001 [Page 3]
Internet Draft AAA Keys for Mobile IP 28 January 2001
New algorithms will be allocated as indicated by practical experience
using the extensions defined in this document. See section 3 for
specific information about using Algorithm MD5/prefix+suffix. The
HMAC MD5 algorithm is used in exactly the same way, except that the
specific computation used with MD5 follows RFC 2104 instead of RFC
2002.
3. Using the MD5/prefix+suffix Algorithm
As with Mobile IP, all mobile nodes MUST be able to verify the
authenticator within a MN-HA Authentication extension by using MD5 in
prefix+suffix mode, signified by selection at a SPI of any arbitrary
32-bit value. Therefore, it is economical to use the MD5 algorithm
in prefix+suffix mode to encode the key within the particular key
extension, as follows.
1. The AAA server identifies the mobile node's IP address, call it
``node-address''.
2. The AAA server calculates
(key XOR (MD5(AAA-key | node-address | AAA-key)))
3. The AAA server inserts this result into the Key extension in the
``Encoded Key'' field.
4. The mobile node calculates
temp = MD5(AAA-key | node-address | AAA-key)
5. The mobile node extracts the Security_Information of the key
extension and calculates
key = Encoded Key XOR temp
Perkins, Calhoun Expires 28 July 2001 [Page 4]
Internet Draft AAA Keys for Mobile IP 28 January 2001
4. Unsolicited MN-FA Key From AAA Subtype
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Encoded Key data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Unsolicited MN-FA Key From AAA
Subtype-Specific Data
AAA SPI A 32-bit opaque value, indicating the SPI that the
mobile node must use to determine the algorithm to use
for recovering the FA security information.
FA SPI A 32-bit opaque value, which the mobile node MUST use
to index all the necessary information recovered from
the FA security information after it is decoded.
MN-FA Encoded Key data
The necessary information (including the key) required
by the mobile node to create a Mobility Security
Assocation between itself and the foreign agent.
The Unsolicited MN-FA Key From AAA extension, shown in figure 1, uses
subtype 7 of the Generalized MN-FA Key Reply Extension [8]. The key
is encoded by the home domain AAA server (AAAH) for use by the mobile
node to secure future Mobile IP registrations with the same foreign
agent. The Unsolicited MN-FA Key From AAA extension MUST appear in
the Registration Reply before the MN-FA Authentication extension.
Once the mobile node decodes the FA Security Information, by using
the algorithm indexed by the AAA SPI, it stores the FA Security
Information indexed by the FA SPI in its list of Mobile Security
Associations.
If the foreign agent receives a Registration Reply that does not
have a Unsolicited MN-FA Key From AAA extension, and thus does not
have a way to establish a Mobility Security Association with the
mobile node, the foreign agent SHOULD change the Code value of the
Registration Reply to MISSING_MN_FA (see section 7), effectively
causing the registration to fail.
Perkins, Calhoun Expires 28 July 2001 [Page 5]
Internet Draft AAA Keys for Mobile IP 28 January 2001
5. Generalized MN-HA Key Reply Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Key Distribution Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP MN-HA Key Reply Extension
Type 42 (not skippable) (see [7])
Subtype a number assigned to identify the way in which the
Encoded Registration Key Data is to be decrypted
to obtain the registration key
Length The 16-bit Length field indicates the length of
the extension. It is equal to 4 plus the number
of bytes in the Encoded Registration Key Data.
Lifetime This field indicates the duration of time (in
seconds) for which the MH-HA key is valid.
Registration Key Distribution Data
An encrypted copy of the registration key, along
with any other information needed by the mobile
node to create the designated Mobility Security
Association with the home agent.
Perkins, Calhoun Expires 28 July 2001 [Page 6]
Internet Draft AAA Keys for Mobile IP 28 January 2001
6. Unsolicited MN-HA Key From AAA Subtype
The Unsolicited MN-HA Key From AAA is subtype 1 of the Generalized
MN-HA Key Reply Extension (see section 5).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Encoded Key data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Unsolicited MN-HA Key From AAA
Subtype-Specific Data
AAA SPI A 32-bit opaque value, indicating the SPI that the
mobile node must use to determine the algorithm to use
for recovering the HA security information.
HA SPI A 32-bit opaque value, which the mobile node MUST use
to index all the necessary information recovered from
the HA security information after it is decoded.
MN-HA Encoded Key data
The necessary information (including the key) required
by the mobile node to create a Mobility Security
Assocation between itself and the home agent.
The Unsolicited MN-HA Key From AAA subtype-specific data is shown
in figure 3. The Mobile Node Encoded Key data is to be decoded
according to the given SPI between the mobile node and the home
domain AAA server (AAAH). The key is intended for use the mobile node
to secure future Mobile IP registrations with its home agent. The
MN-HA Key Reply MUST appear in the Registration Reply before the
MN-HA Authentication extension.
Once the mobile node decodes the MN-HA Encoded Key data, by using
the algorithm indexed by the AAA SPI, it stores the HA Security
Information indexed by the HA SPI in its list of Mobile Security
Associations. The mobile node uses the Identification field data
from the Registration Request as its initial synchronization data
with the home agent.
Perkins, Calhoun Expires 28 July 2001 [Page 7]
Internet Draft AAA Keys for Mobile IP 28 January 2001
7. Error Values
Each entry in the following table contains the name of Code [7] to
be returned in a Registration Reply, the value for the Code, and the
section in which the error is first mentioned in this specification.
Error Name Value Section
---------------------- ----- ---------
MISSING_MN_FA 107 4
8. IANA Considerations
The number for the Generalized MN-HA Key Reply Extension is
taken from the numbering space defined for Mobile IP registration
extensions defined in RFC 2002 [7] as extended in RFC 2356 [6].
The subtype address space for the Generalized MN-HA Key Reply
extension is defined in this document. From this space, subtype
value 1 is assigned to the Unsolicited MN-HA Key From AAA Subtype
extension.
The number assigned to the Unsolicited MN-FA Key From AAA Subtype
extension was taken from the numbering space defined for the
Generalized MN-FA Key Reply Extension, defined in [8].
The Code values specified for errors, listed in section 7, MUST NOT
conflict with any other code values listed in RFC 2002, RFC 2344 [5],
or RFC 2356 [6]. They are to be taken from the space of error values
conventionally associated with rejection by the foreign agent (i.e.,
64-127).
SPI values 3 and 4 are taken from the reserved space of SPI numbers
(0-255) created for special Mobile IP algorithm identifiers.
9. Security Considerations
The extensions in this document are intended to provide the
appropriate level of security for Mobile IP entities (mobile node,
foreign agent, and home agent) to operate Mobile IP registration
protocol. The security associations resulting from use of these
extensions do not offer any higher level of security than what is
already implicit in use of the security association between the
mobile node and the AAA.
Perkins, Calhoun Expires 28 July 2001 [Page 8]
Internet Draft AAA Keys for Mobile IP 28 January 2001
References
[1] B. Aboba and M. Beadles. The Network Access Identifier. Request
for Comments (Proposed Standard) 2486, Internet Engineering Task
Force, January 1999.
[2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension.
draft-ietf-mobileip-challenge-08.txt, January 2000. (work in
progress).
[3] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base
Protocol. Internet Draft, Internet Engineering Task Force.
draft-calhoun-diameter-12.txt, December 1999. Work in progress.
[4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for
Message Authentication. Request for Comments (Informational)
2104, Internet Engineering Task Force, February 1997.
[5] G. Montenegro. Reverse Tunneling for Mobile IP. Request for
Comments (Proposed Standard) 2344, Internet Engineering Task
Force, May 1998.
[6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. Request for Comments (Informational) 2356, Internet
Engineering Task Force, June 1998.
[7] C. Perkins. IP Mobility Support. Request for Comments (Proposed
Standard) 2002, Internet Engineering Task Force, October 1996.
[8] C. Perkins and D. Johnson. Registration Keys for Route
Optimization. Internet Draft, Internet Engineering Task Force,
December 1997. Work in progress.
[9] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
Authentication Dial In User Service (RADIUS). Request for
Comments (Proposed Standard) 2138, Internet Engineering Task
Force, April 1997.
Perkins, Calhoun Expires 28 July 2001 [Page 9]
Internet Draft AAA Keys for Mobile IP 28 January 2001
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nortel Networks Inc. Motorola
2201 Lakeside Blvd. 1501 West Shure Drive
Richardson, TX. 75082-4399 Arlington Heights, IL 60004
USA USA
Phone: +1 972-684-1489 Phone: +1 847-632-3148
EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com
Questions about this memo can also be directed to the authors:
Charles E. Perkins Pat R. Calhoun
Communications Systems Lab Network & Security Center
Nokia Research Center Sun Microsystems Laboratories
313 Fairchild Drive 15 Network Circle
Mountain View, California 94043 Menlo Park, California 94025
USA USA
Phone: +1-650 625-2986 Phone: +1 650-786-7733
EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com
Fax: +1 650 625-2502 Fax: +1 650-786-6445
Perkins, Calhoun Expires 28 July 2001 [Page 10]
