Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Sun Microsystems Laboratories
15 June 1999 Pat R. Calhoun
Sun Microsystems Laboratories
AAA Registration Keys for Mobile IP
draft-ietf-mobileip-aaa-key-00.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 15 December 1999 [Page 1]
Internet Draft AAA Keys for Mobile IP 15 June 1999
1. Introduction
AAA servers, such as RADIUS [8] and DIAMETER [2], 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 [?], 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 15 December 1999 [Page 2]
Internet Draft AAA Keys for Mobile IP 15 June 1999
4. When the mobile node receives the Registration Reply message, it
verifies the authenticity (and integrity) of the reply message
by using information provided in the MN-AAA Authentication
extension.
5. If the Reply passes authentication and contains the MN-HA Key
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 home agent.
6. Similarly, if the Reply passes authentication and contains the
MN-FA Key extension (see section 5), 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.
Any message containing the MN-HA Key extension or the MN-FA Key
extension MUST also contain a subsequent MN-AAA Authentication
Extension. If a Registration Reply message contains both a MN-HA
Key extension and a Mobile-Home Authentication extension, the
former extension MUST come first. Likewise, if a Registration Reply
message contains both a MN-FA Key extension and a Mobile-Foreign
Authentication extension, the former extension MUST come first.
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, a table
of security algorithm identifiers is also specified. This table is
intended to conform to the table of reserved SPIs from RFC 2002, and
to allocate some of the currently unused reserved numbers to identify
certain common algorithm identifiers.
Algorithm identifier 0 is taken to mean that the mobile node
and the AAA server share only one security association, and that
unique security association is the one by which the mobile node is
Perkins, Calhoun Expires 15 December 1999 [Page 3]
Internet Draft AAA Keys for Mobile IP 15 June 1999
instructed to decode the key information in the MN-HA or the MN-FA
Key extension.
Other numbers are defined as follows:
Algorithm Identifier Name Reference
--------------------- ------------------ ------------
2 MD5/prefix+suffix RFC 2002 [7]
3 HMAC MD5 RFC 2104 [3]
New identifiers will be allocated as indicated by practical
experience using the extensions defined in this document. See
section 3 for specific information about using Algorithm Identifier
2. Algorithm Identifier 3 is used in exactly the same way, except
that the specific computation used with MD5 follows RFC 2104 instead
of RFC 2002.
3. Using Algorithm Identifier 2: MD5/prefix+suffix
The AAA indicates that the mobile node must use MD5 in prefix+suffix
mode to recover the key information, by inserting the value 2 into
the Algorithm Identifier field of the Key extension.
As with Mobile IP, all mobile nodes MUST be able to verify the
authenticator within a MN-AAA 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
``Security Information'' 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 = Security_Information XOR temp
Perkins, Calhoun Expires 15 December 1999 [Page 4]
Internet Draft AAA Keys for Mobile IP 15 June 1999
4. MN-HA Key Extension
The MN-HA Key extension, shown in figure 1, contains the key for use
by the mobile node to secure future Mobile IP registrations with its
home agent. The MN-HA Key extension MUST appear in the Registration
Request before the MN-AAA Authentication 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 | Length | Security Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA security information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The MN-HA Key Extension
Type 126 (not skippable) [7]
Length 10 plus the length in bytes of the HA security
information field
Security Algorithm A value in the table defined in section 2.
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.
HA Security Information The necessary information (including the
key) required by the mobile node to create a Mobility
Security Assocation between itself and the home agent.
Once the mobile node decodes the HA Security Information, by
using the algorithm indexed by the AAA SPI, it stores the Security
Algorithm field, and the HA Security Information indexed by the HA
SPI in its list of Mobile Security Associations.
Perkins, Calhoun Expires 15 December 1999 [Page 5]
Internet Draft AAA Keys for Mobile IP 15 June 1999
5. MN-FA Key Extension
The MN-FA Key extension, shown in figure 1, contains the key for use
by the mobile node to secure future Mobile IP registrations with
the same foreign agent. The MN-FA Key extension MUST appear in the
Registration Request before the MN-AAA Authentication 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 | Length | Security Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA security information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The MN-FA Key Extension
Type 133 (skippable) [7]
Length 10 plus the length in bytes of the FA security
information field
Security Algorithm A value in the table defined in section 2.
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.
HA Security Information The necessary information (including the
key) required by the mobile node to create a Mobility
Security Assocation between itself and the foreign
agent.
Once the mobile node decodes the FA Security Information, by
using the algorithm indexed by the AAA SPI, it stores the Security
Algorithm field, and the FA Security Information indexed by the FA
SPI in its list of Mobile Security Associations.
Perkins, Calhoun Expires 15 December 1999 [Page 6]
Internet Draft AAA Keys for Mobile IP 15 June 1999
If the foreign agent receives a Registration Reply that does not have
a MN-FA Key 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 6), effectively causing the registration
to fail.
6. 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 106 5
7. IANA Considerations
The number for the MN-HA Key and MN-FA Key extensions are taken from
the numbering space defined for Mobile IP registration extensions
defined in RFC 2002 [7] as extended in RFC 2356 [5]. The numbering
for the extension also SHOULD NOT conflict with values specified in
the Internet Draft for Route Optimization [6] Mobile Node NAI ??, or
Foreign Agent Challenge extensions [?]. The Code values specified
for errors, listed in section 6, MUST NOT conflict with any other
code values listed in RFC 2002, RFC 2344 [4], or RFC 2356 [5].
They are to be taken from the space of error values conventionally
associated with rejection by the foreign agent (i.e., 64-127).
8. 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 associated with the security association between the mobile
node and the AAA. The security association with the AAA is the one
from which both the Mobile IP described in this draft are derived.
Perkins, Calhoun Expires 15 December 1999 [Page 7]
Internet Draft AAA Keys for Mobile IP 15 June 1999
References
[1] B. Aboba and M. Beadles. RFC 2486: The Network Access
Identifier, January 1999. Status: PROPOSED STANDARD.
[2] P. Calhoun and A. Rubens. DIAMETER Base Protocol.
draft-calhoun-diameter-07.txt, November 1998. (work in
progress).
[3] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997.
[4] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May
1998.
[5] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. RFC 2356, June 1998.
[6] Charles E. Perkins and David B. Johnson. Route Optimization in
Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999.
(work in progress).
[7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[8] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
Authentication Dial In User Service (RADIUS). RFC 2138, April
1997.
Perkins, Calhoun Expires 15 December 1999 [Page 8]
Internet Draft AAA Keys for Mobile IP 15 June 1999
Addresses
The working group can be contacted via the current chairs:
Erik Nordmark Basavaraj Patil
Sun Microsystems, Inc. Nortel Networks Inc.
17 Network Circle 2201 Lakeside Blvd.
Menlo Park, California 94025 Richardson, TX. 75082-4399
USA USA
Phone: +1 650 786-5166 +1 972-684-1489
Fax: +1 650 786-5896
E-mail: nordmark@sun.com bpatil@nortelnetworks.com
Questions about this memo can be directed to:
Charles E. Perkins Pat R. Calhoun
Sun Microsystems Laboratories Sun Microsystems Laboratories
15 Network Circle 15 Network Circle
Menlo Park, California 94025 Menlo Park, California 94025
USA USA
Phone: +1-650 786-6464 Phone: +1 650-786-7733
EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com
Fax: +1 650 786-6445
Perkins, Calhoun Expires 15 December 1999 [Page 9]
