Request for Comments: 3957 Nokia Research Center
Category: Standards Track P. Calhoun
Airespace
March 2005
Authentication, Authorization, and Accounting (AAA)
Registration Keys for Mobile IPv4
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Authentication, Authorization, and Accounting (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 for IPv4 requires strong authentication between the mobile
node and its home agent. When the mobile node shares an AAA Security
Association with its home AAA server, however, it is possible to use
that AAA Security Association to create derived Mobility Security
Associations between the mobile node and its home agent, and again
between the mobile node and the foreign agent currently offering
connectivity to the mobile node. This document specifies extensions
to Mobile IP registration messages that can be used to create
Mobility Security Associations between the mobile node and its home
agent, and/or between the mobile node and a foreign agent.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operations with Key Generation Nonce Extensions. . 5
4. Mobility Security Associations . . . . . . . . . . . . . . . . 7
5. Key Generation Nonce Creation and Key Derivation . . . . . . . 8
6. Key Generation Extensions. . . . . . . . . . . . . . . . . . . 9
6.1. Generalized MN-FA Key Generation Nonce Request Extension 10
6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 11
6.3. Generalized MN-HA Key Generation Nonce Request Extension 13
6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 14
7. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20
B. Message Flow for Requesting and Receiving Registration Keys 24
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
AAA servers, such as RADIUS [11] and DIAMETER [12], are in use within
the Internet today to provide authentication and authorization
services for dial-up computers. Such services are likely to be
valuable for mobile nodes using Mobile IP for IPv4 [1], when the
nodes are attempting to connect to foreign domains with AAA servers.
In this document Mobile IP for IPv4 is called "Mobile IPv4" or just
"Mobile IP" for short, since no confusion with other versions is
expected. Requirements for interactions between AAA and Mobile IP
are outlined in RFC 2977 [13]; that document describes an
infrastructure which enables AAA servers to authenticate and
authorize network access requests from mobile nodes. See also
appendix A. The Mobile IP Registration Request is considered to be a
request for network access. It is then possible to augment the
functionality of the Mobile IP mobility agents so that they can
translate between Mobile IP registration messages and the messages
used within the AAA infrastructure, as described in RFC 2977.
Mobility agents and AAA servers that conform to the requirements of
RFC 2977 can be considered as appropriate network entities to support
the message types specified in this document. Please consult RFC
2977 [13] for further details.
This specification makes use of a single AAA Security Association to
create derivative Mobility Security Associations. A Mobility
Security Association in this specification is a simplex connection
that serves to authenticate MIPv4 control traffic between a MN and HA
and/or a MN and FA. A Mobility Security Association is identified by
the two end points, such as a MN IP address and a HA IP address, and
a SPI. Two nodes may have one or more Mobility Security Associations
established between each other; however, typically there is no reason
to have more than one Mobility Security Association between two
nodes.
This document specifies extensions to Mobile IP registration messages
that can be used to create Mobility Security Associations between the
MN and FA and/or MN and HA based on the AAA Security Association
between the MN and AAA server. These new Mobility Security
Associations may then be used to calculate the Authentication Data
needed by authentication extensions used in Mobile IP control
messages.
It is assumed that the security association between the mobile node
and its AAA server has been appropriately configured so that the AAA
server can provide key material to be used as the basis for the
necessary Mobility Security Association(s) between the mobile node
and its prospective mobility agents.
AAA servers typically use the Network Access Identifier (NAI) [2] 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 having any home address.
However, for Mobile IP to work, the mobile node is required to have a
home address and a Mobility Security Association [1] with its home
agent. When the Mobile IP Registration Reply packet is authenticated
by the MN-AAA Authentication Extension [3], the mobile node can
verify that the key material contained in the extensions were
produced by the AAA server, and thus may be reliably used to create
Mobility Security Associations with the home agent and/or the foreign
agent.
It is also assumed that the AAA entities involved (i.e., the AAAH,
AAAL, and the AAA interface features of the foreign agents and home
agents) all have means outside of the scope of this document for
exchanging keys. The extensions within this document are intended to
work with any AAA protocol suite that allows for such key exchange,
as long as it satisfies the requirements specified in RFC 2977 [13].
One such AAA protocol is defined within the Diameter framework [14].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [4].
AAA Authentication, Authorization, and Accounting (see
[10]).
AAA entity A network node processing AAA messages according to the
requirements for AAA protocols (see [10]).
AAA Security Association
A security association between a AAA entity and another
node needing the services of that AAA entity. In this
document all AAA Security Associations are between a
mobile node and its home AAA server (AAAH). A mobile
node’s AAA Security Association with its home AAA
server (AAAH) may be based either on the mobile node’s
IP address or on its NAI [2]. The key is referred to
as "AAA-key" in this specification.
Key A number, kept secret. Only nodes in possession of the
key have any hope of using the security transform to
obtain correct results.
Key Generation Nonce
Nonce data used for the purpose of creating a key.
Mobility Security Association
A Mobility Security Association is a simplex connection
that applies security services to RFC 3344 MIPv4
control traffic between a MN and HA (or MN and FA)
using RFC 3344 Authentication Extensions. A Mobility
Security Association is uniquely identified by the peer
source and destination IP addresses and an SPI. Two
nodes may have one or more Mobility Security
Associations; however, typically there is no reason to
have more than one Mobility Security Association
between two nodes, except as a transient condition
during re-keying events.
Registration Key
A key used in the MN-FA or MN-HA Mobility Security
Association. A registration key is typically only used
once or a very few times, and only for the purposes of
verifying a small volume of Authentication data.
Security Algorithm
A set of rules for using input data and a secret key
for producing data for use in security protocols.
SPI Security Parameters Index. The SPI is an arbitrary
32-bit value that assists in the identification of an
AAA, IP, or Mobility Security Association.
Other terminology is used as defined in the base Mobile IP
specification [1]. Furthermore, in order to simplify the discussion,
we have used the word "Extension" instead of "Subtype of the
Generalized Extension" in many cases. So, for instance, instead of
using the phrase "The MN-FA Key Generation Nonce From AAA Subtype of
the Generalized MN-FA Key Generation Nonce Reply Extension", we would
instead use the phrase "The MN-FA Key Generation Nonce From AAA
Extension".
3. Overview of Operations with Key Generation Nonce Extensions
When a mobile node depends on an AAA infrastructure to obtain
authorization for network connectivity and Mobile IP registration, it
may lack any pre-existing Mobility Security Associations with either
its home agent, or the foreign agent controlling the access to the
foreign network. The extensions defined in this document allow a AAA
entity to supply key material to mobile nodes to be used as the basis
of its Mobility Security Association with mobile agents. The AAA
entity that will act on these extensions is part of the AAA
infrastructure, and is typically identified within the foreign domain
by methods outside the scope of this specification (see appendix A).
The key material may be requested by the mobile node in new
extensions (defined below) to Mobile IP Registration Request
messages, and supplied to the mobile node in extensions to the Mobile
IP Registration Reply messages. Alternatively, the AAA server MAY
provide unsolicited key material via mobility agents to mobile nodes;
the mobile node MUST then calculate new keys and update or create its
relevant Mobility Security Association. The method by which key
material is supplied to the mobility agents themselves is out of
scope for this document, and would depend on the particular details
of the security architecture for the AAA servers in the foreign and
home domains (see RFC 2977 and appendix A). For the purposes of this
document, we assume that there is a suitable AAA infrastructure
available to the home and foreign agents, and that the mobile node
does have an AAA Security Association with at least one AAA server in
its home domain.
When a mobile node travels away from home, it may not have a Mobility
Security Association with its home agent, perhaps because it does not
yet have a home address [5]. The protocol and messages in this
document are intended to facilitate the following operations which
may occur between the mobile node, foreign agent, home agent, and AAA
servers in the visited (local) domain (Authentication, Authorization
and Accounting Local or AAAL) and in the home domain (Authentication,
Authorization, and Accounting Home or AAAH). In the following
sequence of messages, the only message flows specified in this
document are the Registration Request between the mobile node and the
foreign agent, and Registration Reply between the foreign agent and
the mobile node. The other messages described here result from the
presumed action of the AAA entities as described in RFC 2977. See
also appendix B.
1. If the mobile node does not have a Mobility Security Association
with the foreign agent, it SHOULD include an MN-FA Key Generation
Nonce Request extension (see Section 6.1) as part of its
Registration Request that it sends to the Foreign Agent.
2. If the mobile node does not have a Mobility Security Association
with the home agent, it MUST add an MN-HA Key Generation Nonce
Request extension (see Section 6.3) as part of its Registration
Request that it sends to the Foreign Agent.
3. If one or more AAA Key Generation Nonce Request extensions were
added, the mobile node MUST add the MN-AAA Authentication
extension to its Registration Request.
4. By action of the foreign agent, which is presumed to be also a
AAA entity, the mobile node’s key requests and authentication
data are transferred to the local AAA server (AAAL), typically
after reformatting to fit into the appropriate AAA messages,
which are out of scope for this document.
5. After the information within the MN-AAA Authentication extension
is verified by the AAA server in the home domain (AAAH), it then
also generates the key material that has been requested by the
mobile node, for the necessary Mobility Security Associations.
6. The respective keys for the Mobility Security Associations are
distributed to the Home Agent and Foreign Agent via the AAA
protocol.
7. The mobile node receives the Registration Reply message from the
Foreign Agent.
8. If a MN-HA Key Generation Nonce Request From AAA extension is
present in the Registration Request message, then the mobile node
MUST create or update its Mobility Security Association with the
Home Agent indicated in the corresponding Registration Reply,
using the key computed from the key material in the MN-HA Key
Generation Nonce From AAA extension. In this case, if no MN-HA
Key Generation Nonce Reply extension is present, the mobile node
MUST discard the Registration Reply.
9. Using its (perhaps newly created) Mobility Security Association
with the home agent, the mobile node authenticates the
Registration Reply message by checking the Authentication Data in
the Mobile-Home Authentication extension. If the check fails,
the MN MUST discard the Registration Reply and the new Mobility
Security Association, reverting to the old Mobility Security
Association with the home agent, if any.
10. If the Registration Reply passes authentication and contains a
MN-FA Key Generation Nonce From AAA extension (see section 6.2),
the mobile node generates the registration key using the Key
Generation Nonce provided, according to its AAA Security
Association with the AAA. The resulting registration key is used
to establish the mobile node’s Mobility Security Association with
its foreign agent, and is used to compute the authentication data
used in the Mobile-Foreign authentication extension.
If verification of the Mobile-Foreign authentication extension
fails, and if the MN-FA Key Generation Nonce Reply extension was
not protected by another, valid authentication extension, the MN
MUST discard the new Mobility Security Association, reverting to
the old Mobility Security Association with the foreign agent, if
any.
Any registration reply containing the MN-HA Key Generation Nonce From
AAA extension MUST also contain a subsequent Mobile Home
Authentication extension, created using the generated MN-HA key.
Similarly, a reply containing the MN-FA Key Generation Nonce From AAA
extension MUST also contain a subsequent Mobile Foreign
Authentication extension, created using the registration key.
4. Mobility Security Associations
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
transform that uses the key to produce the authentication information
that is present in the Mobile-Home Authentication extension or the
Mobile-Foreign Authentication extension. In order for the mobile
node to make use of key material created by the AAA server, the
mobile node also has to be able to identify and select the
appropriate cryptographic transform that uses the key to produce the
authentication.
The transform identifiers are the same as those used in IPsec. They
are tabulated in the list of Authentication Algorithms allowable as
values for the "Attribute Type" (5) (i.e., "Authentication
Algorithm"), one of the classifications in the tabulated Attribute
Types for "IPsec Security Association Attributes". See
http://www.iana.org/assignments/isakmp-registry for the full listing
of all Attribute Types and other Attributes for IPsec Security
Associations.
Mobility Security Associations shared between mobile nodes and home
agents also require a replay protection method. The following table
contains the supported replay detection methods.
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [1]
3 Nonces RFC 3344 [1]
4-65535 Unallocated
5. Key Generation Nonce Creation and Key Derivation
This section contains the procedures followed in the creation of the
Key Generation Nonce by AAA servers, and the key derivation
procedures used by mobile nodes. Note that the AAA servers will also
deliver the keys to the mobility agents (home agent, foreign agent)
via the AAA protocol. AAA servers that follow these procedures will
produce results that can be understood by mobile nodes. The mobility
agents will faithfully transcribe the results into the appropriate
Mobile IP extensions.
The following example uses HMAC-SHA1 [6]. All mobile nodes and
mobility agents implementing Mobile IP [1] and implementing the
extensions specified in this document MUST implement HMAC-SHA1 [1].
Other message authentication codes or keyed hash functions MAY also
be used. The particular algorithm used is configured as part of the
AAA Security Association between the MN and the AAAH server, which is
in turn indexed by the AAA SPI.
The following steps are performed on the AAAH server:
1. The AAA server identifies the mobile node. If the NAI field is
present in the Registration Request, then the NAI is used as the
mobile node identifier. Otherwise, the Home Address field of the
Registration Request is used.
2. The AAA server generates a random [7] value of at least 128 bits
to be used as the Key Generation Nonce.
3. The AAA server inserts the random value into the Key Generation
Nonce Reply extension in the "Key Generation Nonce" field.
The following steps are performed by the mobile node (here ||
represents concatenation):
1. The mobile node calculates
key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node
identifier})
Here the Key Generation Nonce is from the extension in the
Registration Reply, and the mobile node identifier is the MN’s
NAI, if present in the Registration Request, or the Home Address
from the Registration Request otherwise.
2. The mobile node creates the Mobility Security Association(s),
using the resulting key and the other relevant information in the
Key Generation Nonce Extension.
The secret key used within the HMAC-SHA1 computation is indicated by
the AAA Security Association indexed by the AAA SPI, which has been
previously configured as the basis for the AAA Security Association
between the mobile node and the AAA server creating the key material.
6. Key Generation Extensions
This section defines new Extensions to Mobile IP Registration
Requests and Replies [1].
6.1. Generalized MN-FA Key Generation Nonce Request Extension
Figure 1 illustrates the Generalized MN-FA Key Generation Nonce
Request Extension (MN-FA KeyGen Request for short).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Generalized Mobile IP MN-FA Key Generation
Nonce Request Extension