GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3957

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:
  1. The AAAH must establish strong, fresh session keys.
  1. The mechanism must maintain algorithm independence, allowing for

the distribution of authentication algorithm identification along

    with the keys.
  1. The mechanism must include replay detection.
  1. The mechanism must authenticate all parties, including the AAA

servers and the FA and HA.

  1. The mechanism must provide for authorization of the client, FA,

and HA.

  1. The mechanism must not rely on plaintext passwords.
  1. The mechanism must maintain confidentiality of session keys.
  1. The mechanism must uniquely name session keys.
  1. 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
  1. The mechanism must bind key(s) to an appropriate context
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3957.txt · Last modified: 2005/03/04 00:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki