doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3957.txt b/doc/rfc/rfc3957.txt
new file mode 100644
index 0000000..746868f
--- /dev/null
+++ b/doc/rfc/rfc3957.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                         C. Perkins
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 1]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+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.
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 2]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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].
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 3]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+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.
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 4]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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.
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 5]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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.
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 6]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 7]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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.
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 8]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                     [Page 9]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+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
+
+   Type             40 (not skippable) (see [1] and section 8)
+
+   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).
+
+   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 MN-FA KeyGen Request 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.
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 10]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   This document defines the subtype 1 for the MN-FA Key Generation
+   Nonce >From AAA Request (MN-FA AAA KeyGen Request for short).  The
+   MN-FA AAA KeyGen Request has a zero-length Subtype Data field and
+   MUST appear in the Registration Request before the MN-AAA
+   Authentication extension.
+
+6.2.  Generalized MN-FA Key Generation Nonce Reply Extension
+
+   The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA
+   KeyGen Reply for short) supplies keying material requested by the
+   MN-FA KeyGen 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       41 (not skippable) (see [1] and section 8)
+
+   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
+              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 subtype 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
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 11]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 7), effectively causing the registration to fail.
+
+   This document defines subtype 1 of the MN-FA KeyGen Reply for the
+   MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply
+   for short), shown in figure 3.
+
+    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 3: 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.
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 12]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 [7] value of at least 128 bits.
+
+   The MN-FA AAA KeyGen Reply extension MUST appear in the Registration
+   Reply before the Mobile-Foreign Authentication extension.
+
+   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.
+
+6.3.  Generalized MN-HA Key Generation Nonce Request Extension
+
+   Figure 4 illustrates the Generalized MN-HA Key Generation Nonce
+   Request Extension (MN-HA KeyGen Request for short).
+
+   Type             42 (not skippable) (see [1] and section 8)
+
+   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.
+
+    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 4: The Generalized Mobile IP MN-HA Key Generation
+               Nonce Request Extension
+
+   Subtype Data plus 4 (for the Mobile Node SPI field).
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 13]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 MN-HA KeyGen 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.
+
+   This document defines the subtype 1 for the MN-HA Key Generation
+   Nonce from AAA Request (MN-HA AAA KeyGen Request for short).  The
+   MN-HA AAA KeyGen Request has a zero-length Subtype Data field and
+   MUST appear in the Registration Request before the MN-AAA
+   Authentication extension.
+
+6.4.  Generalized MN-HA Key Generation Nonce Reply Extension
+
+   The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA
+   KeyGen Reply for short) supplies keying material requested by the
+   MN-HA KeyGen Request extension.  Figure 5 illustrates the format of
+   the 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 5: The Generalized Mobile IP MN-HA Key
+                    Generation Nonce Reply Extension
+
+   Type       43 (not skippable) (see [1] and section 8)
+
+   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.
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 14]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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.
+
+   This document defines subtype 1 of the MN-HA KeyGen Reply for the
+   MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply
+   for short), shown in figure 6.
+
+    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
+
+   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.
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 15]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 [7] value of at least 128 bits.
+
+   The MN-HA AAA KeyGen Reply 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 A).  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 AAA KeyGen Reply 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 Reply as its initial synchronization data with the home
+   agent.
+
+7.  Error Values
+
+   Each entry in the following table contains the name of the Code [1]
+   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
+      ----------------------   -----   ---------
+      MISSING_MN_FA             107      6.2
+
+8.  IANA Considerations
+
+   This document defines 4 new extensions (see Section 6) taken from the
+   (non-skippable) numbering space defined for Mobile IP registration
+   extensions defined in RFC 3344 [1] as extended in RFC 2356 [8].  The
+   values for these extensions are:
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 16]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+      Name                   Value   Section
+      --------------------- ------- ---------
+      MN-FA-KeyGen Request    40      6.1
+      MN-FA-KeyGen Reply      41      6.2
+      MN-HA-KeyGen Request    42      6.3
+      MN-HA-KeyGen Reply      43      6.4
+
+   IANA has created and will maintain a new registry for the KeyGen
+   Request/Reply subtypes.  The initial contents of the registry is a
+   single entry for the subtypes defined in this document:
+
+      Name                           Value   Section
+      ----------------------------- ------- ---------
+      KeyGen Request/Reply from AAA    1        6
+
+   New subtypes for these two registries are assigned through Standards
+   Action as defined in [9].
+
+   IANA has assigned a code value for error MISSING_MN_FA, listed in
+   section 7.  This value has been taken from the space of error values
+   conventionally associated with rejection by the foreign agent (i.e.,
+   64-127).
+
+   IANA has created and will 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 [9].
+
+9.  Security Considerations
+
+   The extensions in this document are intended to provide the
+   appropriate level of security for Mobile IP entities (mobile node,
+   foreign agent, and home agent) to 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 Reply extensions defined in this specification only carry
+   Key Generation Nonces, which are used to derive keys, they do not
+   expose any data that could be used in an attack aimed at recovering
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 17]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   the key shared between the mobile node and the AAA.  The authors do
+   not believe this specification introduces any new security
+   vulnerability.
+
+10.  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.
+
+11.  References
+
+11.1.  Normative References
+
+   [1]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
+        August 2002.
+
+   [2]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
+        2486, January 1999.
+
+   [3]  Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
+        Extension", RFC 3012, November 2000.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
+        Extension for IPv4", RFC 2794, March 2000.
+
+   [6]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+        for Message Authentication", RFC 2104, February 1997.
+
+   [7]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+        Recommendations for Security", RFC 1750, December 1994.
+
+   [8]  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
+        Mobile IP", RFC 2356, June 1998.
+
+   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 18]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+11.2.  Informative References
+
+   [10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B.,
+        Stevens, M., and B. Wolff, "Authentication, Authorization, and
+        Accounting: Protocol Evaluation", RFC 3127, June 2001.
+
+   [11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
+        "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP
+        Authentication, Authorization, and Accounting Requirements", RFC
+        2977, October 2000.
+
+   [14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions",
+        Work in Progress, February 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 19]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+Appendix A.  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 [13].
+
+   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 [3], relying on the existence of an AAA
+   infrastructure such as is described in this section, and also
+   described in RFC 2977 and RFC 3012 [3].  Such credentials are
+   typically managed by entities within the mobile node's home domain.
+   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
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 20]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 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.
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 21]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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 [13] for more details.
+
+                               +------+              +------+
+                               |      |              |      |
+                               | AAAL +--------------+ AAAH |
+                               |      |              |      |
+                               +---+--+              +--+---+
+                                   |                    |
+                                   |                    |
+                               +---+--+              +--+---+
+   MN   =  mobile node         |      |              |      |
+   FA   =  foreign agent       |  FA  |              |  MN  |
+   AAAL =  local authority     |      |              |      |
+   AAAH =  home authority      +------+              +------+
+
+                   Figure 8: IP Security Associations
+
+   Nodes in two separate administrative domains (for instance, AAAH and
+   AAAL) often must take additional steps to verify the identity 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.
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 22]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+   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.
+
+   -  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.
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 23]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+Appendix B.  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 A.
+   Challenge values, as specified in [3], 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.
+
+   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
+
+   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
+      AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed,
+      along with an authorization-enabling authentication extension as
+      required by Mobile IP [1].
+
+   3. The foreign agent relays the Registration Request and/or Key
+      Request(s) to its locally configured AAA Infrastructure (see
+      appendix A), 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
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 24]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+      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 AAA KeyGen Reply 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 unsolicited keying material from the AAA
+   Infrastructure.
+
+   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
+
+   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 [1].
+
+   3. The foreign agent sends a AAA Request (possibly containing the
+      Registration Request) to its locally configured AAA Infrastructure
+      (see appendix A), 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
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 25]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+      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 KeyGen Reply extensions to be used by the
+      mobile node to establish Mobility Security Associations with the
+      relevant mobility agents (foreign agent and/or home agent).
+
+Authors' Addresses
+
+   Charles E. Perkins
+   Nokia Research Center
+   313 Fairchild Drive
+   Mountain View, California 94043
+   USA
+
+   Phone:  +1 650 625-2986
+   Fax:    +1 650 625-2502
+   EMail:  charles.perkins@nokia.com
+
+
+   Pat R. Calhoun
+   Airespace, Inc.
+   110 Nortech Parkway
+   San Jose, CA 95134
+   USA
+
+   Phone:  +1 408 635 2000
+   Fax:    +1 408 635 2020
+   EMail:  pcalhoun@airespace.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 26]
+
+RFC 3957                AAA Keys for Mobile IPv4              March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Perkins & Calhoun           Standards Track                    [Page 27]
+