Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
3 February 2004 Pat R. Calhoun
Airespace
AAA Registration Keys for Mobile IPv4
draft-ietf-mip4-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@sunroof.eng.sun.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 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.
Perkins, Calhoun Expires 3 August 2004 [Page i]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. Overview of Operations with Key Generation Nonce Extensions 5
4. Mobility Security Associations 7
5. Key Generation Nonce Creation and Derivation 8
6. Generalized Key Request/Reply Extensions 9
6.1. Generalized MN-FA Key Generation Nonce Request Extension 9
6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 10
6.3. Generalized MN-HA Key Generation Nonce Request Extension 11
6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 12
7. Key Request/Reply Subtypes 13
7.1. MN-FA Key Generation Nonce From AAA Request Subtype . . . 13
7.2. MN-FA Key Generation Nonce From AAA Subtype . . . . . . . 13
7.3. MN-HA Key Generation Nonce From AAA Request Subtype . . . 15
7.4. MN-HA Key Generation Nonce From AAA Subtype . . . . . . . 15
8. Error Values 16
9. IANA Considerations 17
10. Security Considerations 18
11. Acknowledgements 18
A. Changes Since Previous Revision 20
B. Older Changes 20
C. AAA Infrastructure 21
D. Message Flow for Requesting and Receiving Registration Keys 25
Intellectual Property Statement 28
Perkins, Calhoun Expires 3 August 2004 [Page ii]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Full Copyright Statement 28
Addresses 29
1. Introduction
AAA servers, such as RADIUS [14] and DIAMETER [5], 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 [13], 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 [7]; that document describes
an infrastructure which enables AAA servers to authenticate and
authorize network access requests from mobile nodes. See also
appendix C. 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 [7] 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 Mobiity Security Associations between the
MN and FA and/or MN and HA based on the AAA Security Association
between the MN and HAAA. These additional Mobility Security
Associations may then be used in Mobile IP extensions to calculate
the Authentication Data need by authentication extensions used in
Mobile IP control messages. It is assumed that the AAA Security
Association between the MN and its HAAA has been appropriately
configured so that the AAA server has the authorization to provide
key material to be used as the basis for the necessary Mobility
Perkins, Calhoun Expires 3 August 2004 [Page 1]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Security Assocation between the MN and its prospective mobility
agents.
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 calculate the Authentication Data
needed by authentication extensions used with Mobile IP registration
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 has authorization to 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) [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 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 [13] with
its home agent. When the Mobile IP Registration Reply packet is
authenticated by the MN-AAA Authentication Extension [4], 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 [7].
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 [2].
AAA Authentication, Authorization, and Accounting
(see [9]).
AAA entity A network node processing AAA messages according to
the requirements for AAA protocols (see [9]).
AAA Security Association
A security association between a AAA entity
Perkins, Calhoun Expires 3 August 2004 [Page 2]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
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 [1]. 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.
Registration Key
A key used in the Mobility Security Association
between a mobile node and a foreign agent. 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 [13]. 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
Perkins, Calhoun Expires 3 August 2004 [Page 3]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
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 C).
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 C). 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 [3]. 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 D.
Perkins, Calhoun Expires 3 August 2004 [Page 4]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
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 7.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 7.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 From AAA extension is present
in the Registration Reply message, then the mobile node MUST
create or update its Mobility Security Association with the Home
Agent indicated in the 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.
Perkins, Calhoun Expires 3 August 2004 [Page 5]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
10. If the Registration Reply passes authentication and contains a
MN-FA Key Generation Nonce From AAA extension (see section 7.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 methods.
Perkins, Calhoun Expires 3 August 2004 [Page 6]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [13]
3 Nonces RFC 3344 [13]
4-65535 Unallocated
5. Key Generation Nonce Creation and 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 example that follows makes use of HMAC-MD5 [8]. All mobile nodes
and mobility agents implementing Mobile IP [13] and implementing the
extensions specified in this document MUST implement HMAC-MD5 [13].
Other cryptographic functions MAY also be used.
The following steps are performed on the AAAH server:
1. The AAA server identifies the mobile node. If the Home Address
field of the Registration Request is either zero (0), or all ones
(0xffffffff), then the Mobile Node's NAI is used instead of the
mobile node's home address.
2. The AAA server generates a random [6] 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. Using the Key Generation Nonce from the extension, the mobile
node calculates
key = HMAC-MD5 (AAA-key, {Key Generation Nonce || home
address})
Perkins, Calhoun Expires 3 August 2004 [Page 7]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
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-MD5 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. Generalized Key Request/Reply Extensions
The extensions in this section are Generalized Extensions [13], and
have subtypes as specified in section 7.
6.1. Generalized MN-FA Key Generation Nonce Request Extension
Figure 1 illustrates the Generalized MN-FA Key Generation Nonce
Request 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Generalized Mobile IP MN-FA Key Generation
Nonce Request Extension
Type TBD (not skippable) (see [13] and section 9)
Subtype a number assigned to identify the way in
which the MN-FA Key Generation Nonce Request
Subtype Data is to be used when generating the
registration key
Length The 16-bit Length field indicates the length of
the extension. It is equal to the number of
bytes in the MN-FA Key Generation Nonce Request
Subtype Data plus 4 (for the Mobile Node SPI
field).
Perkins, Calhoun Expires 3 August 2004 [Page 8]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Mobile Node SPI The Security Parameters Index that the mobile
node will assign for the Mobility Security
Association created for use with the registration
key.
MN-FA Key Generation Nonce Request Subtype Data
Data needed to carry out the creation of the
registration key on behalf of the mobile node.
The Generalized MN-FA Key Generation Nonce Request Extension defines
a set of extensions, identified by subtype, which may be used by a
mobile node in a Mobile IP Registration Request message to request
that some other entity create a Registration Key for use by the
mobile node with the mobile node's new foreign agent.
6.2. Generalized MN-FA Key Generation Nonce Reply Extension
The Generalized MN-FA Key Generation Nonce Reply extension supplies
keying material requested by using one of the subtypes of the
Generalized MN-FA Key Generation Nonce Request extension. Figure 2
illustrates the format of the Generalized MN-FA Key Generation Nonce
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP MN-FA Key
Generation Nonce Reply Extension
Type TBD (not skippable) (see [13] and section 9)
Subtype a number assigned to identify the way in which the
MN-FA Key Generation Nonce Reply Subtype Data is to be
used to obtain the registration key.
Length The 16-bit Length field is equal to the number of bytes
in the MN-FA Key Generation Nonce Reply Subtype Data.
MN-FA Key Generation Nonce Reply Subtype Data
An encoded copy of the keying material, along with any
Perkins, Calhoun Expires 3 August 2004 [Page 9]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
other information needed by the recipient to create the
designated Mobility Security Association.
For each subtype, the format of the MN-FA Key Generation Nonce Reply
Subtype Data has to be separately defined according to the particular
method required to set up the Mobility Security Association.
For the subtypes defined in this document, the MN-FA Key Generation
Nonce supplied in the data for a subtype of this extension may
come as a result of a request which was sent using a subtype of
the Generalized MN-FA Key Generation Nonce Request Extension. In
such cases, the SPI to be used when employing the Mobility Security
Association defined by the registration key is the same as given in
the original request.
Once the mobile node creates the Mobility Security Association with
the foreign agent, by using the transform indexed by the AAA SPI, it
stores that Mobility Security Association indexed by the FA SPI in
its list of Mobile Security Associations.
If the foreign agent receives a Registration Reply that has no MN-FA
Key Generation Nonce Reply extension, and if it has no existing
Mobility Security Association with the mobile node, the foreign agent
MAY change the Code value of the Registration Reply to MISSING_MN_FA
(see section 8), effectively causing the registration to fail.
6.3. Generalized MN-HA Key Generation Nonce Request Extension
Figure 3 illustrates the Generalized MN-HA Key Generation Nonce
Request 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Generalized Mobile IP MN-HA Key Generation
Nonce Request Extension
Type TBD (not skippable) (see [13] and section 9)
Perkins, Calhoun Expires 3 August 2004 [Page 10]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Subtype a number assigned to identify the way in
which the MN-HA Key Generation Nonce Request
Subtype Data is to be used when generating the
registration key
Length The 16-bit Length field indicates the length of
the extension. It is equal to the number of
bytes in the MN-HA Key Generation Nonce Request
Subtype Data plus 4 (for the Mobile Node SPI
field).
Mobile Node SPI The Security Parameters Index that the mobile
node will assign for the Mobility Security
Association created for use with the registration
key.
MN-HA Key Generation Nonce Request Subtype Data
Data needed to carry out the creation of the
MN-HA key on behalf of the mobile node.
The Generalized MN-HA Key Generation Nonce Request Extension defines
a set of extensions, identified by subtype, which may be used by a
mobile node in a Mobile IP Registration Request message to request
that some other entity create an MN-HA key for use by the mobile node
with the mobile node's new home agent.
6.4. Generalized MN-HA Key Generation Nonce 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Generalized Mobile IP MN-HA Key
Generation Nonce Reply Extension
Type TBD (not skippable) (see [13] and section 9)
Perkins, Calhoun Expires 3 August 2004 [Page 11]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Subtype a number assigned to identify the way in which the
MN-HA Key Generation Nonce Reply Subtype Data is to be
used to obtain the MN-HA key
Length The 16-bit Length field indicates the length of the
extension. It is equal to the number of bytes in the
MN-HA Key Generation Nonce Reply Subtype Data plus 4
(for the Lifetime field).
Lifetime This field indicates the duration of time (in seconds)
for which the MN-HA key is valid.
MN-HA Key Generation Nonce Reply Subtype Data
Data used to derive the MN-HA key, along with any other
information needed by the mobile node to create the
designated Mobility Security Association with the home
agent.
For each subtype, the format of the MN-HA Key Generation Nonce Reply
Subtype Data has to be separately defined according to the particular
method required to set up the Mobility Security Association.
7. Key Request/Reply Subtypes
The extension subtypes in this section are subtypes of the
Generalized Extensions specified in section 6.
7.1. MN-FA Key Generation Nonce From AAA Request Subtype
The MN-FA Key Generation Nonce From AAA Request subtype data uses
subtype 7 of the Generalized MN-FA Key Generation Nonce Request
Extension (see section 6.1). The MN-FA Key Generation Nonce From AAA
Request extension MUST appear in the Registration Request before the
MN-AAA Authentication extension. The subtype data field is zero in
length.
7.2. MN-FA Key Generation Nonce From AAA Subtype
The MN-FA Key Generation Nonce From AAA extension, shown in figure 5,
uses subtype 7 of the Generalized MN-FA Key Generation Nonce Reply
Extension (see section 6.2).
Perkins, Calhoun Expires 3 August 2004 [Page 12]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The MN-FA Key Generation Nonce From AAA
Subtype-Specific Data
lifetime This field indicates the duration of time (in seconds)
for which the keying material used to create the
registration key is valid.
AAA SPI A 32-bit opaque value, indicating the SPI that the
mobile node must use to determine the transform to use
for establishing the Mobility Security Association
between the mobile node and its prospective foreign
agent.
FA SPI The SPI for the Mobility Security Association to the FA
that the mobile node creates using the Key Generation
Nonce
Algorithm Identifier
This field indicates the transform to be used (stored
as part of the Mobility Security Association with
the foreign agent, and selected from among the
values in the "Authentication Algorithm" table
cited in section 4), for future computations of the
Mobile-Foreign Authentication Extension.
Key Generation Nonce
A random [6] value of at least 128 bits.
The MN-FA Key Generation Nonce From AAA extension MUST appear in
the Registration Reply before the Mobile-Foreign Authentication
extension.
Perkins, Calhoun Expires 3 August 2004 [Page 13]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
The Key Generation Nonce is provided by the AAA server for use by the
mobile node in creating the registration key, which is used to secure
future Mobile IP registrations with the same foreign agent.
7.3. MN-HA Key Generation Nonce From AAA Request Subtype
The MN-HA Key Generation Nonce From AAA Request subtype data uses
subtype 7 of the Generalized MN-HA Key Generation Nonce Request
Extension (see section 6.3). The MN-HA Key Generation Nonce From AAA
Request extension MUST appear in the Registration Request before the
MN-AAA Authentication extension. The subtype data field is zero in
length.
7.4. MN-HA Key Generation Nonce From AAA Subtype
The MN-HA Key Generation Nonce From AAA is subtype 7 of the
Generalized MN-HA Key Generation Nonce Reply Extension (see
section 6.4).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Replay Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The MN-HA Key Generation Nonce From AAA
Subtype-Specific Data
Perkins, Calhoun Expires 3 August 2004 [Page 14]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
AAA SPI A 32-bit opaque value, indicating the SPI that the
mobile node must use to determine the transform to use
for establishing the Mobility Security Association
between the mobile node and its home agent.
HA SPI The SPI for the Mobility Security Association to the HA
that the mobile node creates using the Key Generation
Nonce
Algorithm Identifier
This field indicates the transform to be used for
future computations of the Mobile-Home Authentication
Extension (see section 4)
Replay Method
This field contains the replay method to be used for
future Registration messages (see section 4).
Key Generation Nonce
A random [6] value of at least 128 bits.
The MN-HA Key Generation Nonce From AAA subtype-specific data is
shown in figure 6. The Mobile Node calculates the MN-HA key using
the Key Generation Nonce provided by the AAA server. The calculation
proceeds by using the key shared between the mobile node and the
AAA server that has previously been configured for securing all
such communication requirements with the AAA server which will be
contacted within the AAA infrastructure (see appendix C). The MN-HA
key is intended for use by the mobile node to secure future Mobile IP
registrations with its home agent. The MN-HA Key Generation Nonce
extension MUST appear in the Registration Reply before the MN-HA
Authentication extension.
Once the mobile node creates the MN-HA Key, by using the transform
specified in 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.
8. Error Values
Each entry in the following table contains the name of the Code [13]
value to be returned in a Registration Reply, the value for that
Code, and the section in which the error is first mentioned in this
specification.
Error Name Value Section
Perkins, Calhoun Expires 3 August 2004 [Page 15]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
---------------------- ----- ---------
MISSING_MN_FA 107 7.2
9. IANA Considerations
The numbers for the Generalized Extensions in section 6 are
taken from the numbering space defined for Mobile IP registration
extensions defined in RFC 3344 [13] as extended in RFC 2356 [11].
IANA will create and maintain a namespace for the subtypes associated
with each Generalized Key Generation Nonce Request/Reply Extension.
The numbers suggested in this section are already in use by
implementations which have been tested for interoperability.
The number 7, assigned to the MN-FA Key Generation Nonce From AAA
Request Subtype extension, is taken from the numbering space defined
for the Generalized MN-FA Key Generation Nonce Request Extension (see
section 6.1).
The number 1, assigned to the MN-FA Key Generation Nonce From AAA
Subtype extension, is taken from the numbering space defined for
the Generalized MN-FA Key Generation Nonce Reply Extension (see
section 6.2).
The number 7, assigned to the MN-HA Key Generation Nonce From AAA
Request Subtype extension, is taken from the numbering space defined
for the Generalized MN-HA Key Generation Nonce Request Extension (see
section 6.3).
The number 7, assigned to the MN-HA Key Generation Nonce From AAA
Subtype extension, is taken from the numbering space defined for
the Generalized MN-HA Key Generation Nonce Reply Extension (see
section 6.4).
IANA will assign a code value for error MISSING_MN_FA, listed in
section 8. This value is to be taken from the space of error values
conventionally associated with rejection by the foreign agent (i.e.,
64-127).
IANA will create and maintain a namespace for the Replay Method
Identifier. This specification makes use of 2 and 3; all other
values other than zero (0) and (1) are available for assignment,
pending review and approval by a Designated Expert [12].
Perkins, Calhoun Expires 3 August 2004 [Page 16]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
10. 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 calculate the Authentication Data
needed by authentication extensions used with Mobile IP registration
messages. The Mobility 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 AAA Security Association between
the mobile node and the AAAH. In order to deny any adversary the
luxury of unbounded time to analyze and break the secrecy of the AAA
Security Association between the mobile node and the AAA server, that
AAA Security Association MUST be refreshed periodically.
The provisioning and refreshing of the AAA key in the MN and AAA
server is outside the scope of this document.
Since the extensions defined in this specification only carries Key
Generation Nonce, which is used to derive keys, it does not expose
any data that could be used in an attack aimed at recovering the
key shared between the mobile node and the AAA. The authors do not
believe this specification introduces any new security vulnerability.
11. Acknowledgements
Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG
for their useful comments. Thanks especially to Tom Hiller who has
contributed many textual improvements to later revisions of this
document.
Perkins, Calhoun Expires 3 August 2004 [Page 17]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
References
[1] B. Aboba and M. Beadles. The Network Access Identifier.
Request for Comments (Proposed Standard) 2486, Internet
Engineering Task Force, January 1999.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier
Extension for IPv4. Request for Comments (Proposed Standard)
2794, Internet Engineering Task Force, January 2000.
[4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension. Request for Comments (Proposed
Standard) 3012, Internet Engineering Task Force, December 2000.
[5] Pat R. Calhoun, John Loughney, E. Guttman, Glen Zorn,
and Jari Arkko. DIAMETER Base Protocol (work in
progress). Internet Draft, Internet Engineering Task
Force. draft-ietf-aaa-diameter-15.txt, October 2002.
[6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness
Recommendations for Security. Request for Comments
(Informational) 1750, Internet Engineering Task Force, December
1994.
[7] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP
Authentication, Authorization, and Accounting Requirements.
Request for Comments (Proposed Standard) 2977, Internet
Engineering Task Force, October 2000.
[8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.
[9] D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil,
M. Stevens, and B. Wolff. Authentication, Authorization,
and Accounting: Protocol Evaluation. Request for Comments
(Informational) 3127, Internet Engineering Task Force, June
2001.
[10] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised.
Request for Comments (Proposed Standard) 3024, Internet
Engineering Task Force, January 2001.
Perkins, Calhoun Expires 3 August 2004 [Page 18]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
[11] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. Request for Comments (Informational) 2356, Internet
Engineering Task Force, June 1998.
[12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October
1998.
[13] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 3344, Internet Engineering Task Force,
August 2002.
[14] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
Authentication Dial In User Service (RADIUS). Request for
Comments (Proposed Standard) 2865, Internet Engineering Task
Force, June 2000.
A. Changes Since Previous Revision
- Cleaned up terminology:
* Changed "Key Material" to "Key Generation Nonce".
B. Older Changes
In this revision of the document, there have been several major
changes as a result of suggestions received during Last Call.
- Generalized Key Extensions previously specified in another
document have been instead specified in this document in order
that this document can be self-contained and not dependent on the
standardization status of the other document.
- Additional explanation has been included for the purposes of
clarifying the problem space and solution approach.
- An appendix has been added to describe the expected AAA
infrastructure that will produce the keys that are to be
distributed within the extensions specified in this document.
- Ladder diagrams have been included to illustrate the expected
message flows containing the extensions defined in this document.
- HMAC-MD5 has been mandated for implementation by the mobile node,
for compatibility with RFC 3344 [13]. The example text has been
modified accordingly (see section 5).
Perkins, Calhoun Expires 3 August 2004 [Page 19]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
- A table of Algorithm Identifiers has been identified as the
numbering space for transform selection when establishing the
Mobility Security Association using the keys distributed with the
extensions in this document. See section 4.
- A terminology section has been added.
- This appendix has been added.
* New terminology entries for "Registration Key", "AAA", "AAA
entity", "Mobility Security Association", "AAA Security
Association",
* All instances of MN-FA key are now called "registration key"
* All instances of the key between mobile node and home agent
are called "MN-HA" key.
- Removed extraneous IANA considerations paragraph for HMAC_MD5
- Removed "Unsolicited" from subtype names
- Changed minimum Key Material length from 64 bits to 128 bits
- Cleaned up terminology:
* Clarified the use of "Security Association" throughout the
document as either "IPSec" or "Mobility" or "AAA".
C. AAA Infrastructure
In this appendix, we attempt to capture the main features of a basic
model for operation of AAA servers that is assumed for understanding
of the use of the Mobile IP registration extensions described in this
document. This information has been adapted from the discussion in
RFC 2977 [7].
Within the Internet, a mobile node belonging to one administrative
domain (called the home domain) often needs to use resources
provided by another administrative domain (called the foreign
domain). A foreign agent that handles the mobile node's Registration
Request is likely to require that the mobile node provide some
credentials that can be authenticated before access to the resources
is permitted. These credentials may be provided as part of the
Mobile-AAA Authentication extension [4], relying on the existence
of an AAA infrastructure such as is described in this section, and
also described in RFC 2977 and RFC 3012 [4]. Such credentials are
typically managed by entities within the mobile node's home domain.
Perkins, Calhoun Expires 3 August 2004 [Page 20]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
They may be also used for setting up secure communications with the
mobile node and the foreign agent, or between the mobile node and its
home agent if necessary.
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 7: AAA Servers in Home and Local Domains
The foreign agent often does not have direct access to the data
needed to verify the credentials. Instead, the foreign agent is
expected to consult an authority (typically in the same foreign
domain) in order to request proof that the mobile node has acceptable
credentials. Since the foreign agent and the local authority (AAAL)
are part of the same administrative domain, they are expected to have
established, or be able to establish for the necessary lifetime, a
secure channel for the purposes of exchanging sensitive (access)
information, and keeping it private from (at least) the visiting
mobile node.
The local authority (AAAL) itself may not have enough information
stored locally to carry out the verification for the credentials
of the mobile node. In contrast to the foreign agent, however,
the AAAL is expected to be configured with enough information to
negotiate the verification of mobile node credentials with its home
domain. The home and foreign domains should be configured with
sufficient IP Security Associations (i.e., IPSec) and access controls
so that they can negotiate the authorization, and also enable the
mobile node to acquire Mobility Security Associations with the
mobility agents within the foreign domain. For the purposes of the
key exchanges specified within this document, the authorization is
Perkins, Calhoun Expires 3 August 2004 [Page 21]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
expected to depend only upon secure authentication of the mobile
node's credentials.
Once the authorization has been obtained by the local authority, and
the authority has notified the foreign agent about the successful
negotiation, the foreign agent can deliver the Registration Reply to
the mobile node along with the key material.
In figure 7, there might be many mobile nodes from many different
Home Domains. Each Home Domain provides a AAAH that can check
credentials originating from mobile nodes administered by that Home
Domain. There is a security model implicit in figure 7, and it is
crucial to identify the specific security associations assumed in
the security model. These IP Security Associations are illustrated
in figure 8, and are considered to be relatively long-lived security
associations.
First, it is natural to assume that the mobile node has an AAA
Security Association with the AAAH, since that is roughly what it
means for the mobile node to belong to the home domain.
Second, from the model illustrated in figure 7 it is clear that AAAL
and AAAH have to share an IP Security Association, because otherwise
they could not rely on the authentication results, authorizations,
nor even the accounting data which might be transacted between them.
Requiring such bilateral IP Security Associations is, however, in the
end not scalable; the AAA framework must provide for more scalable
mechanisms, but the methods by which such a broker model is to be
created are out of scope for this document. See RFC 2977 for more
details.
Finally, from figure 7, it is clear that the foreign agent can
naturally share an IP Security Association with the AAAL. This is
necessary in order for the model to work because the foreign agent
has to have a way to find out that it is permissible to allocate
the local resources to the mobile node, and further to transmit any
successful Registration Reply to the mobile node.
Figure 8 illustrates the IP Security Associations we understand from
our proposed model. Note that there may be, by mutual agreement
between AAAL and AAAH, a third party inserted between AAAL and
AAAH to help them arbitrate secure transactions in a more scalable
fashion. The broker model which has been designed to enable such
third-party processing should not have any effect on the Mobile IP
extensions specified in this document, and so no description is
provided here; see RFC 2977 [7] for more details.
Nodes in two separate administrative domains (for instance, AAAH
and AAAL) often must take additional steps to verify the identity
Perkins, Calhoun Expires 3 August 2004 [Page 22]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
Figure 8: IP Security Associations
of their communication partners, or alternatively to guarantee
the privacy of the data making up the communication. While these
considerations lead to important security requirements, as mentioned
above in the context of security between servers, we consider the
exact choice of IP Security Associations between the AAA servers to
be beyond the scope of this document. The choices are unlikely to
depend upon Mobile IP, or any specific features of the general model
illustrated in figure 7. On the other hand, the Mobility Security
Associations needed between Mobile IP entities are of central
importance in the design of the key derivation extensions in this
document.
One further detail deserves mention. The Mobility Security
Association to be established between the mobile node and the foreign
agent has to be communicated to the foreign agent as well as to the
mobile node. The following requirements are placed on the mechanism
used by the AAA infrastructure to effect key distribution:
- The AAAH must establish strong, fresh session keys.
- The mechanism must maintain algorithm independence, allowing for
the distribution of authentication algorithm identification along
with the keys.
- The mechanism must include replay detection.
- The mechanism must authenticate all parties, including the AAA
servers and the FA and HA.
- The mechanism must provide for authorization of the client, FA,
and HA.
Perkins, Calhoun Expires 3 August 2004 [Page 23]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
- The mechanism must not rely on plaintext passwords.
- The mechanism must maintain confidentiality of session keys.
- The mechanism must uniquely name session keys.
- The mechanism must be such that the compromise of a single FA
and HA cannot compromise any other part of the system, including
session keys and long-term keys
- The mechanism must bind key(s) to an appropriate context
- The mechanism must not expose the keys to entities other than the
AAAH and FA (or HA in the case of key distribution to the HA).
The way that the key is distributed to the foreign agent (or
home agent) is expected to be handled as part of the AAA protocol
processing between the AAAH and AAAL, and the further AAA protocol
processing between the AAAL and the foreign agent. Such processing
is outside the scope of this document, but must satisfy the above
requirements.
D. Message Flow for Requesting and Receiving Registration Keys
In this section, we show message flows for requesting and receiving
a registration key from the AAA infrastructure, described in
section C. Challenge values, as specified in [4], might be added to
the Advertisement and Registration messages for additional replay
protection, but are not illustrated here.
Diagram 9 illustrates the message flow for the case when the mobile
node explicitly requests keying material to create registration keys.
In diagram 9, the following message flow is illustrated:
1. The foreign agent disseminates an Agent Advertisement. This
advertisement MAY have been produced after receiving an Agent
Solicitation from the mobile node (not shown in the diagram).
2. The mobile node creates a Registration Request including the
MN-HA Key Generation Nonce Request and/or MN-FA Key Generation
Nonce Request, as needed, along with an authorization-enabling
authentication extension as required by Mobile IP [13].
3. The foreign agent relays the Registration Request and/or Key
Request(s) to its locally configured AAA Infrastructure (see
appendix C), according to local policy.
Perkins, Calhoun Expires 3 August 2004 [Page 24]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
|-- RReq+AAA Key Req.-->| |
| |--- RReq + AAA Key Req.--->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 9: Message Flows for Requesting and
Receiving Key Generation Nonce
4. The foreign agent receives a AAA Response with the appropriate
indications for authorizing connectivity for the mobile node.
Along with this AAA Response, the foreign agent may also receive
key material by some secure method appropriate for communications
between it and its local AAA infrastructure. At this point if
the foreign agent has not relayed the Registration Request,
it forwards it directly to the Home Agent and waits for a
Registration Reply (not shown in the figure).
5. The foreign agent relays the Registration Reply to the mobile
node, along with the new Key Generation Nonce extensions to
be used by the mobile node to establish Mobility Security
Associations with the relevant mobility agents (foreign agent
and/or home agent).
Diagram 10 illustrates the message flow for the case when the
mobile node receives an unsolicited keying matereial from the AAA
Infrastructure.
In diagram 10, the following message flow is illustrated:
1. The foreign agent disseminates an Agent Advertisement. This
advertisement MAY have been produced after receiving an Agent
Solicitation from the mobile node (not shown in the diagram).
2. The mobile node creates a Registration Request including an
authorization-enabling authentication extension as required by
Mobile IP [13].
Perkins, Calhoun Expires 3 August 2004 [Page 25]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 10: Message Flow for Receiving Unsolicited
Key Generation Nonce
3. The foreign agent sends a AAA Request (possibly containing
the Registration Request) to its locally configured AAA
Infrastructure (see appendix C), according to local policy.
4. The foreign agent receives a AAA Response with the appropriate
indications for authorizing connectivity for the mobile node.
Along with this AAA Response, the foreign agent may also receive
key material by some secure method appropriate for communications
between it and its local AAA infrastructure. At this point,
if the foreign agent has not relayed the Registration Request,
it forwards it directly to the Home Agent and waits for a
Registration Reply (not shown in the figure).
5. The foreign agent relays the Registration Reply to the mobile
node, along with the new Key Generation Nonce extensions to
be used by the mobile node to establish Mobility Security
Associations with the relevant mobility agents (foreign agent
and/or home agent).
Perkins, Calhoun Expires 3 August 2004 [Page 26]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Perkins, Calhoun Expires 3 August 2004 [Page 27]
Internet Draft AAA Keys for Mobile IPv4 3 February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Addresses
The working group can be contacted via the current chairs:
Pete McCann Henrik Levkowetz
Lucent Technologies ipUnplugged AB
Rm 9C-226R Arenavagen 27
1960 Lucent Lane Stockholm S-121 28
Naperville, IL 60563 Sweden
USA
Phone: +1 630 369 9693 Phone: +46 708 32 16 08
Email: mccap@lucent.com Email: henrik@levkowetz.com
Questions about this memo can also be directed to the authors:
Charles E. Perkins Pat R. Calhoun
Communications Systems Lab
Nokia Research Center Airespace Networks
313 Fairchild Drive 110 Nortech Parkway
Mountain View, California 94043 San Jose, CA 95134
USA USA
Phone: +1-650 625-2986 Phone: +1 408 635 2000
EMail: charles.perkins@nokia.com Email: pcalhoun@diameter.org
Fax: +1 650 625-2502 Fax: +1 720-293-7501
Perkins, Calhoun Expires 3 August 2004 [Page 28]