Mobile IP Working Group                               Charles E. Perkins
INTERNET DRAFT                                     Nokia Research Center
26 February 2002                                          Pat R. Calhoun
                                                     Black Storm Systems

                  AAA Registration Keys for Mobile IP
                   draft-ietf-mobileip-aaa-key-09.txt


Status of This Memo

   This document is a submission by the mobile-ip Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@sunroof.eng.sun.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.


Abstract

   AAA servers, such as RADIUS and DIAMETER, are in use within the
   Internet today to provide authentication and authorization services
   for dial-up computers.  Mobile IP requires strong authentication
   between the mobile node and its home agent.  When the mobile node
   shares a security association with its home AAA server, however, it
   is possible to use that security association to create derivative
   security associations between the mobile node and its home agent,
   and again between the mobile node and the foreign agent currently
   offering connectivity to the mobile node.  This document specifies
   extensions to the Mobile IP Registration Reply packet that can be
   used to create such security information at the mobile node.








Perkins, Calhoun             Expires 26 August 2002             [Page 1]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


1. Introduction

   AAA servers, such as RADIUS [13] and DIAMETER [4], are in use within
   the Internet today to provide authentication and authorization
   services for dial-up computers.  Such services are likely to be
   equally valuable for mobile nodes using Mobile IP [12] when the
   nodes are attempting to connect to foreign domains with AAA servers.
   Requirements for interactions between AAA and Mobile IP are outlined
   in RFC 2977 [6]; that document describes an infrastructure which
   enables AAA servers to authenticate and authorize network access
   requests from mobile nodes.  See also appendix B.  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 architected 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 for
   further details.

   Mobile IP requires strong authentication between the mobile node and
   its home agent.  When the mobile node shares a security association
   with its home AAA server, however, it is possible to use that
   security association to create derivative security associations
   between the mobile node and its home agent, and again between the
   mobile node and the foreign agent currently offering connectivity to
   the mobile node.  This document specifies extensions to the Mobile
   IP Registration messages that can be used to create those security
   associations at the mobile node.

   AAA servers typically use the Network Access Identifier (NAI) [1]
   to uniquely identify the mobile node; the mobile node's home
   address is not always necessary to provide that function.  Thus,
   it is possible for a mobile node to authenticate itself, and be
   authorized for connection to the foreign domain, without having any
   home address.  However, for Mobile IP to work, the mobile node is
   required to have a security association with its home agent.  When
   the Mobile IP Registration Reply packet is authenticated by the
   MN-AAA Authentication Extension [3], the mobile node can verify that
   the keys contained in the extensions were produced by the AAA server,
   and thus may be reliably used to create security associations with
   the home agent, or alternatively with the foreign agent.

   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.



Perkins, Calhoun             Expires 26 August 2002             [Page 2]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


2. Terminology

      security association
                    The information shared by two network nodes that
                    enables them to carry out the operations needed for
                    some security protocol that the nodes intend to
                    operate.  For the purposes of this document, all
                    security associations will contain the following
                    information:

                       key a number, kept secret.  Only nodes in
                           possession of the key have any hope of
                           using the security algorithm to obtain
                           correct results.
                       SPI Security Parameters Index.  This number
                           enables selection of one security
                           association in case that several exist
                           between the two nodes operaing a security
                           procedure.

                    Also for the purposes of this document, a mobile
                    node is allowed to have a security association with
                    another node even though it does not necessarily
                    know the IP address of that node.  It is only
                    required that the mobile node use the security
                    association for purpose in accordance with the
                    expectations of the other node.

      security algorithm
                    A set of rules for using input data and a secret key
                    for producing data for use in security protocols.
                    For example, HMAC-MD5 [8] is the security algorithm
                    that all nodes using Mobile IP must implement
                    for the purposes of producing and verifying
                    authentication data.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this document are to be interpreted as described in [2].
   Other terminology is used as defined in the base Mobile IP
   specification [12].

   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
   Unsolicited MN-FA Key Material From AAA Subtype of the Generalized
   MN-FA Key Reply Extension", we would instead use the phrase "The
   Unsolicited MN-FA Key Material From AAA Extension".




Perkins, Calhoun             Expires 26 August 2002             [Page 3]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


3. Overview of Operations with Key Extensions

   When a mobile node depends on an AAA infrastructure to obtain
   authorization for network connectivity and Mobile IP registration,
   it may not have any pre-existing security relationships 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
   agent to supply key material to mobile nodes to be used as the basis
   of its security association with mobile agents (foreign agents and
   home agents).  The AAA agent 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 B).

   The key material is requested by the mobile node in new extensions to
   Mobile IP Registration Request messages, and supplied to the mobile
   node in extensions to the Mobile IP Registration Reply messages.
   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 B).  For
   the purposes of this document, we assume that there is a suitable AAA
   infrastructure available to the foreign agents, and that the mobile
   node does have a security association with at least one AAA server in
   its home domain.

   The protocol and messages in this document are intended to facilitate
   the following operations which may occur between the mobile node, AAA
   server, home agent, and foreign agent.  However, 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.

    1. When a mobile node travels away from home, it may not have a
       security association with its home agent, perhaps because it does
       not yet have a home address.

    2. If the mobile node does not have a Mobility Security Association
       with the foreign agent, it SHOULD include an MN-FA Key Request
       extension (see Section  10) as part of its Registration Request
       that it sends to the Foreign Agent.

    3. Similarly, if the mobile node does not have a Mobility Security
       Association with the home agent, it MUST add an MN-HA Key Request
       extension (see Section  11) as part of its Registration Request
       that it sends to the Foreign Agent.






Perkins, Calhoun             Expires 26 August 2002             [Page 4]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


    4. If one or more Key Request extensions were added, the mobile
       node adds the MN-AAA Authentication extension is added to its
       Registration Request.

    5. By action of the foreign agent, which is presumed to be also
       a participant in some AAA protocol, the mobile node's key
       requests and authentication data are transferred, typically after
       reformatting to fit into the appropriate AAA messages, which are
       out of scope for this document.

    6. At the time the information within the MN-AAA Authentication
       extension is verified by the AAA server, the AAA server also
       generates Key Material, if it has been requested by the mobile
       node.

    7. The respective AAA keys are distributed to the Home and Foreign
       Agent via the AAA protocol.

    8. The mobile node first generates the key using the Key Material
       provided, according to its security association with the AAA.
       Using that key, the mobile node authenticates the Reply message.
       If the Reply passes authentication and contains the Unsolicited
       MN-HA Key Material From AAA extension (see section 9), the
       generated key is then used to establish the mobile node's
       security association with its home agent, and is used to
       authenticate the MN-HA authentication extension.

    9. Similarly, if the Reply passes authentication and contains
       the Unsolicited MN-FA Key Material From AAA extension (see
       section 8), the mobile node generates the key using the Key
       Material provided, according to its security association with the
       AAA. The resulting key is used to establish the mobile node's
       security association with its new foreign agent, and is used
       to compute the authentication data used in the Mobile-Foreign
       authentication extension.

   Any registration reply containing the Unsolicited MN-HA Key Material
   From AAA extension MUST also contain a subsequent Mobile Home
   Authentication Extension, created using the generated MN-HA key.
   Similarly, a reply containing the Unsolicited MN-FA Key Material
   From AAA extension MUST also contain a subsequent Mobile Foreign
   Authentication Extension, created using the the MN-FA 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



Perkins, Calhoun             Expires 26 August 2002             [Page 5]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   the cryptographic algorithm which uses the key to produce the
   authentication information typically included in the Mobile Home
   Authentication extension or the Mobile Foreign Authentication
   extension.  In order for the mobile node to make use of key material
   created by the AAA server, the mobile node also has to be able to
   identify and select the appropriate cryptographic algorithm that uses
   the key to produce the authentication.

   The algorithm identifiers are tabulated in the list of Authentication
   Algorithms allowable as values for the "Attribute Type" (5)
   (i.e., "Authentication Algorithm"), one of the classifications
   in the tabulated Attribute Types for "IPSEC Security Association
   Attributes".  See http://www.iana.org/assignments/isakmp-registry
   for the full listing of all Attribute Types and other Attributes for
   IPSEC Security Associations.

   Mobility Security Associations shared between mobile nodes and home
   agents also require a replay protection method.  The following table
   contains the supported replay methods.

      Replay Method     Name           Reference
      --------------    ------------   --------------
      1                 None           RFC 3220 [12]
      2                 Timestamps     RFC 3220 [12]
      3                 Nonces         RFC 3220 [12]




5. Key Material Creation and Derivation

   This section contains the procedures followed in the creation of the
   Key Material by AAA servers, and the key derivation procedures used
   by mobile nodes.  Note that the AAA servers will also make use of the
   derivation procedures to deliver the keys via the AAA protocol.  AAA
   servers that follow these procedures will produce results that can
   be understood by mobile nodes.  Mobility agents (home agent, foreign
   agent) will faithfully transcribe the results into the appropriate
   Mobile IP extensions.

   The example that follows makes use of HMAC-MD5 [7].  All mobile nodes
   and mobility agents implementing Mobile IP, and implementing the
   extensions specified in this document, MUST implement HMAC-MD5 [12].
   Other cryptographic functions MAY also be used.

   The following steps are performed on the AAA server:

    1. The AAA server identifies the mobile node.  If the Home Address
       field of the Registration Request is either zero (0), or all ones



Perkins, Calhoun             Expires 26 August 2002             [Page 6]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


       (1), then the Mobile Node's NAI is used instead of the mobile
       node's home address.

    2. The AAA server generates a random [5] value of at least 64 bits
       to be used as the Key Material.

    3. The AAA server provides the random value for later insertion into
       the Key extension, in the ``Key Material'' field.

   The following steps are performed on the mobile node:

    1. The mobile node calculates

          key = HMAC-MD5 (Key Material | home address)

    2. The mobile node creates the security association, using the key
       and the other relevant information in the Key Extension.

   The secret key used within the HMAC-MD5 computation is the AAA-key
   pointed to by the AAA SPI, which has been previously configured as
   the basis for a security assocation between the mobile node and the
   AAA server creating the key.


6. Generalized Key Request/Reply Extensions

   The extensions in this section are Generalized Extensions, and have
   subtypes as specified in section 7.


6.1. Generalized MN-FA Key Request Extension

   Figure 1 illustrates the Generalized MN-FA Key Request Extension.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Subtype    |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Mobile Node SPI                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                MN-FA Key Request Subtype Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 1: The Generalized Mobile IP MN-FA Key Request Extension





Perkins, Calhoun             Expires 26 August 2002             [Page 7]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


      Type             TBD (not skippable) (see [12] and section 13)

      Subtype          a number assigned to identify the way in
                       which the Key Request 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 Request Subtype Data plus
                       4 (for the Mobile Node SPI field), and SHOULD be
                       at least 20.

      Mobile Node SPI  The Security Parameters Index that the mobile
                       node will assign for the security association
                       created for use with the registration key.

      MN-FA Key Request Subtype Data
                       Data needed to carry out the creation of the
                       registration key on behalf of the mobile node.

   The Generalized MN-FA Key Request Extension defines a set of
   extensions, identified by subtype, which may be used by a mobile node
   in a Mobile IP Registration Request message to request that some
   other entity create a key for use by the mobile node with the mobile
   node's new foreign agent.


6.2. Generalized MN-FA Key Reply Extension

   The Generalized MN-FA Key Reply extension supplies a registration key
   requested by using one of the subtypes of the Generalized MN-FA Key
   Request extension.  Figure 2 illustrates the format Generalized MN-FA
   Key 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 Reply Subtype Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension


      Type       TBD (not skippable) (see [12] and section 13)




Perkins, Calhoun             Expires 26 August 2002             [Page 8]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


      Subtype    a number assigned to identify the way in which the
                 MN-FA Key Reply Subtype Data is to be decrypted to
                 obtain the registration key

      Length     The 16-bit Length field is equal to the number of bytes
                 in the MN-FA Key Reply Subtype Data.

      MN-FA Key Reply Subtype Data
                 An encoded copy of the key to be used between the
                 mobile node and the foreign agent, 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 Reply Subtype Data has
   to be separately defined according to the particular method required
   to set up the security association.

   In some cases, the MN-FA Key supplied in the data for a subtype of
   this extension comes by a request which was sent using a subtype of
   the Generalized MN-FA Key Request Extension.  In that case, the SPI
   to be used when employing the security association defined by the
   registration key is the same as given in the original request.


6.3. Generalized MN-HA Key Request Extension

   Figure 3 illustrates the Generalized MN-HA Key Request Extension.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Subtype    |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Mobile Node SPI                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                MN-HA Key Request Subtype Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 3: The Generalized Mobile IP MN-HA Key Request Extension


      Type             TBD (not skippable) (see [12] and section 13)

      Subtype          a number assigned to identify the way in
                       which the Key Request Data is to be used when
                       generating the registration key




Perkins, Calhoun             Expires 26 August 2002             [Page 9]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


      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 Request Subtype Data plus
                       4 (for the Mobile Node SPI field), and SHOULD be
                       at least 20.

      Mobile Node SPI  The Security Parameters Index that the mobile
                       node will assign for the security association
                       created for use with the registration key.

      MN-HA Key Request Subtype Data
                       Data needed to carry out the creation of the
                       registration key on behalf of the mobile node.

   The Generalized MN-HA Key Request Extension defines a set of
   extensions, identified by subtype, which may be used by a mobile node
   in a Mobile IP Registration Request message to request that some
   other entity create a key for use by the mobile node with the mobile
   node's new home agent.


6.4. Generalized MN-HA Key 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 Reply Subtype Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension


      Type       TBD (not skippable) (see [12] and section 13)

      Subtype    a number assigned to identify the way in which the
                 MN-HA Key Reply Subtype Data is to be decrypted to
                 obtain 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 Reply Subtype Data plus 4 (for the Lifetime
                 field).




Perkins, Calhoun            Expires 26 August 2002             [Page 10]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


      Lifetime   This field indicates the duration of time (in seconds)
                 for which the MN-HA key is valid.

      MN-HA Key Reply Subtype Data
                 An encrypted copy of the key to be used between the
                 mobile node and its home agent, 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 Reply Subtype Data has
   to be separately defined according to the particular method required
   to set up the security association.


7. Key Request/Reply Subtypes

   The extension subtypes in this section are subtypes of the
   Generalized Extensions specified in section 6.


8. Unsolicited MN-FA Key Material From AAA Subtype

   The Unsolicited MN-FA Key Material From AAA extension, shown in
   figure 5, uses subtype 7 of the Generalized MN-FA Key Reply Extension
   (see section 6.2).


       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 Material ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         Figure 5: The Unsolicited MN-FA Key Material From AAA
                         Subtype-Specific Data









Perkins, Calhoun            Expires 26 August 2002             [Page 11]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


      lifetime   This field indicates the duration of time (in seconds)
                 for which the MN-FA key is valid.

      AAA SPI    A 32-bit opaque value, indicating the SPI that the
                 mobile node must use to determine the algorithm to use
                 for establishing the FA security information.

      FA SPI     The SPI for the Security Association to the FA that the
                 MN creates as a result of processing this extension

      Algorithm Identifier
                 This field indicates the algorithm to be used (selected
                 from among the values in the "Authentication Algorithm"
                 table cited in section 4).  for future computations of
                 the Mobile-Foreign Authentication Extension.

      Key Material
                 A random [5] value of at least 64 bits.

   The Key Material is added by the AAA server for use by the mobile
   node in creating the MN-FA key, which is used to secure future Mobile
   IP registrations with the same foreign agent.  The Unsolicited MN-FA
   Key Material From AAA extension MUST appear in the Registration Reply
   before the Mobile-Foreign Authentication extension.

   Once the mobile node creates the FA Security Information, by using
   the algorithm indexed by the AAA SPI, it stores the FA Security
   Information indexed by the FA SPI in its list of Mobile Security
   Associations.

   If the foreign agent receives a Registration Reply that has no
   Unsolicited MN-FA Key Material From AAA extension, and thus cannot
   establish a 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 12), effectively causing the registration
   to fail.


9. Unsolicited MN-HA Key Material From AAA Subtype

   The Unsolicited MN-HA Key Material From AAA is subtype 1 of the
   Generalized MN-HA Key Reply Extension (see section 6.4).










Perkins, Calhoun            Expires 26 August 2002             [Page 12]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


       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 Material ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         Figure 6: The Unsolicited MN-HA Key Material From AAA
                         Subtype-Specific Data



      AAA SPI    A 32-bit opaque value, indicating the SPI that the
                 mobile node must use to determine the algorithm to use
                 for establishing the HA security information.

      HA SPI     The SPI for the Security Association to the HA that the
                 MN creates as a result of processing this extension

      Algorithm Identifier
                 This field indicates the algorithm to be used for
                 future computations of the MN-HA Authentication
                 Extension (see section 4)

      Replay Method
                 This field contains the replay method to be used for
                 future Registration messages (see section 4).

      Key Material
                 A random [5] value of at least 64 bits.

   The Unsolicited MN-HA Material Key From AAA subtype-specific data is
   shown in figure 6.  The Mobile Node creates the MN-HA key using the
   Key Material 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 B).  The key
   is intended for use by the mobile node to secure future Mobile IP
   registrations with its home agent.  The MN-HA Key Reply MUST appear
   in the Registration Reply before the MN-HA Authentication extension.

   Once the mobile node creates the MN-HA Key, by using the algorithm
   specified in the AAA SPI, it stores the HA Security Information
   indexed by the HA SPI in its list of Mobile Security Associations.



Perkins, Calhoun            Expires 26 August 2002             [Page 13]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   The mobile node uses the Identification field data from the
   Registration Request as its initial synchronization data with the
   home agent.


10. MN-FA Key Request From AAA Subtype

   The MN-FA Key Request From AAA subtype data uses subtype 7 of the
   Generalized MN-FA Key Request Extension (see section 6.1).  The
   MN-FA Key Request From AAA extension MUST appear in the Registration
   Request before the MN-AAA Authentication extension.  The subtype data
   field is zero in length.


11. MN-HA Key Request From AAA Subtype

   The MN-HA Key Request From AAA subtype data uses subtype 7 of the
   Generalized MN-HA Key Request Extension (see section 6.3).  The
   MN-HA Key Request From AAA extension MUST appear in the Registration
   Request before the MN-AAA Authentication extension.  The subtype data
   field is zero in length.


12. Error Values

   Each entry in the following table contains the name of Code [12] to
   be returned in a Registration Reply, the value for the Code, and the
   section in which the error is first mentioned in this specification.

      Error Name               Value   Section
      ----------------------   -----   ---------
      MISSING_MN_FA            107     8



13. IANA Considerations

   The numbers for the Generalized Extensions in section 6 are
   taken from the numbering space defined for Mobile IP registration
   extensions defined in RFC 3220 [12] as extended in RFC 2356 [10].
   The numbers suggested in this section are already in use by
   implementations which have been tested for interoperability.

   The number 7, assigned to the Unsolicited MN-HA Key Material From AAA
   Subtype extension, was taken from the numbering space defined for the
   Generalized MN-HA Key Reply Extension (see section 6.4).






Perkins, Calhoun            Expires 26 August 2002             [Page 14]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   The number 7, assigned to the MN-FA Key Request From AAA Subtype
   extension, was taken from the numbering space defined for the
   Generalized MN-FA Key Request Extension (see section 6.1).

   The number 1, assigned to the Unsolicited MN-FA Key Material From AAA
   Subtype extension, was taken from the numbering space defined for the
   Generalized MN-FA Key Reply Extension (see section 6.2).

   The number 7, assigned to the MN-HA Key Request From AAA Subtype
   extension, was taken from the numbering space defined for the
   Generalized MN-HA Key Request Extension (see section 6.3).

   The Code values specified for errors, listed in section 12, MUST NOT
   conflict with any other code values listed in RFC 3220, RFC 3024 [9],
   or RFC 2356 [10].  They are to be taken from the space of error
   values conventionally associated with rejection by the foreign agent
   (i.e., 64-127).

   Section 4 introduces the Algorithm Identifier namespace that requires
   IANA management.  This specification makes use of 1-3; all other
   values other than zero (0) are available for assignment, pending
   review and approval by a Designated Expert [11].

   Section 4 introduces the Replay Method Identifier namespace that
   requires IANA management.  This specification makes use of 1-3;
   all other values other than zero (0) are available for assignment,
   pending review and approval by a Designated Expert [11].


14. Security Considerations

   The extensions in this document are intended to provide the
   appropriate level of security for Mobile IP entities (mobile node,
   foreign agent, and home agent) to operate Mobile IP registration
   protocol.  The security associations resulting from use of these
   extensions do not offer any higher level of security than what is
   already implicit in use of the security association between the
   mobile node and the AAA.

   Since the extensions defined in this specification only carries Key
   Material, which is used to derive keys, it does not expose any data
   that could be used in an attack aimed at recovering the key shared
   between the mobile node and the AAA. The authors do not believe this
   specification introduces new security risks.








Perkins, Calhoun            Expires 26 August 2002             [Page 15]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


15. Acknowledgements

   Thanks to Fredrik Johansson and the members of the IESG for their
   useful comments on this document.
















































Perkins, Calhoun            Expires 26 August 2002             [Page 16]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


References

    [1] B. Aboba and M. Beadles.  The Network Access Identifier.
        Request for Comments (Proposed Standard) 2486, Internet
        Engineering Task Force, January 1999.

    [2] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [3] P. Calhoun and C. E. Perkins.  Mobile IP Foreign Agent
        Challenge/Response Extension.  Request for Comments (Proposed
        Standard) 3012, Internet Engineering Task Force, December 2000.

    [4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman.  DIAMETER
        Base Protocol (work in progress).  Internet Draft, Internet
        Engineering Task Force.  draft-ietf-aaa-diameter-07.txt, July
        2001.

    [5] D. Eastlake, 3rd, S. Crocker, and J. Schiller.  Randomness
        Recommendations for Security.  Request for Comments
        (Informational) 1750, Internet Engineering Task Force, December
        1994.

    [6] S. Glass, T. Hiller, S. Jacobs, and C. Perkins.  Mobile IP
        Authentication, Authorization, and Accounting Requirements.
        Request for Comments (Proposed Standard) 2977, Internet
        Engineering Task Force, October 2000.

    [7] H. Krawczyk, M. Bellare, and R. Canetti.  HMAC: Keyed-Hashing
        for Message Authentication.  Request for Comments
        (Informational) 2104, Internet Engineering Task Force,
        February 1997.

    [8] D. Kristol and L. Montulli.  HTTP State Management Mechanism.
        Request for Comments (Proposed Standard) 2109, Internet
        Engineering Task Force, February 1997.

    [9] Editor G. Montenegro.  Reverse Tunneling for Mobile IP, revised.
        Request for Comments (Proposed Standard) 3024, Internet
        Engineering Task Force, January 2001.

   [10] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
        Mobile IP.  Request for Comments (Informational) 2356, Internet
        Engineering Task Force, June 1998.

   [11] T. Narten and H. Alvestrand.  Guidelines for Writing an IANA
        Considerations Section in RFCs.  Request for Comments (Best




Perkins, Calhoun            Expires 26 August 2002             [Page 17]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


        Current Practice) 2434, Internet Engineering Task Force, October
        1998.

   [12] C. Perkins.  IP Mobility Support.  Request for Comments
        (Proposed Standard) 3220, Internet Engineering Task Force,
        December 2001.

   [13] C. Rigney, A. Rubens, W. Simpson, and S. Willens.  Remote
        Authentication Dial In User Service (RADIUS).  Request for
        Comments (Proposed Standard) 2865, Internet Engineering Task
        Force, June 2000.


A. Changes Since Previous Revision

   In this revision of the document, there have been several major
   changes as a result of suggestions received during Last Call.

    -  Generalized Key Extensions previously specified in another
       document have been instead specified in this document in order
       that this document can be self-contained and not dependent on the
       standardization status of the other document.

    -  Additional explanation has been included for the purposes of
       clarifying the problem space and solution approach.

    -  An appendix has been added to describe the expected AAA
       infrastructure that will produce the keys that are to be
       distributed within the extensions specified in this document.

    -  Ladder diagrams have been included to illustrate the expected
       message flows containing the extensions defined in this document.

    -  HMAC-MD5 has been mandated for implementation by the mobile node,
       for compatibility with RFC 3220 [12].  The example text has been
       modified accordingly (see section 5).

    -  A table of Algorithm Identifiers has been identified as the
       numbering space for algorithm selection when establishing
       the security association using the keys distributed with the
       extensions in this document.  See section 4.

    -  A terminology section has been added.

    -  This appendix has been added.







Perkins, Calhoun            Expires 26 August 2002             [Page 18]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


B. 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 [6].

   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).
   An 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.


                  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)



Perkins, Calhoun            Expires 26 August 2002             [Page 19]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   are part of the same administrative domain, they are expected to have
   established, or be able to establish for the necessary lifetime, a
   secure channel for the purposes of exchanging sensitive (access)
   information, and keeping it private from (at least) the visiting
   mobile node.

   The local authority (AAAL) itself may not have enough information
   stored locally to carry out the verification for the credentials
   of the mobile node.  In contrast to the foreign agent, however,
   the AAAL is expected to be configured with enough information to
   negotiate the verification of mobile node credentials with its home
   domain.  The home and foreign domains should be configured with
   sufficient security relationships and access controls so that they
   can negotiate the authorization, and also enable the mobile node to
   acquire security associations with the foreign domain.  requested
   resources.  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 desired 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 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 a 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 a 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 security relationships is, however, in the
   end not scalable; the AAA framework MUST provide for more scalable
   mechanisms, but the methods by which such a broker model is to be
   created are out of scope for this document.  See RFC 2977 for more
   details.

   Finally, from figure 7, it is clear that the foreign agent can
   naturally share a security association with the AAAL. This is



Perkins, Calhoun            Expires 26 August 2002             [Page 20]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   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 natural 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 [6] for more details.


                               +------+              +------+
                               |      |              |      |
                               | AAAL +--------------+ AAAH |
                               |      |              |      |
                               +---+--+              +--+---+
                                   |                    |
                                   |                    |
                               +---+--+              +--+---+
   MN   =  mobile node         |      |              |      |
   FA   =  foreign agent       |  FA  |              |  MN  |
   AAAL =  local authority     |      |              |      |
   AAAH =  home authority      +------+              +------+


                    Figure 8: 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 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 security
   associations needed between Mobile IP entities are of central
   importance in the design of the key exchange extensions in this
   document.

   One further detail deserves mention.  The key associations to be
   established between the mobile node and the foreign agent have



Perkins, Calhoun            Expires 26 August 2002             [Page 21]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


   to be communicated to the foreign agent as well as to the mobile
   node.  The way that the key is distributed to the foreign agent
   is not relevant to any material in this document, and 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.  Any method by which the key can be
   securely transmitted to the AAAL and then relayed (possibly with
   re-encryption) to the foreign agent, is expected to be outside the
   jurisdiction of any Mobile IP specification, and thus compatible ( by
   reason of non-interference) with the protocol extensions specified in
   this document.


C. Message Flow for Requesting and Receiving Registration Keys

   In this section, we show message flows for requesting and receiving
   a reqistration key from the AAA infrastructure, described in
   section B.  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 a registration key.


        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 Registration Keys


   In diagram 9, the following message flow is illustrated:

    1. The foreign agent disseminates an Agent Advertisement.  This
       advertisement MAY have been produced after receiving an Agent
       Solicitation from the mobile node (not shown in the diagram).





Perkins, Calhoun            Expires 26 August 2002             [Page 22]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


    2. The mobile node creates a Registration Request including the
       MN-HA Key Request and/ore MN-FA Key Request, as needed, along
       with an authorization-enabling authentication extension as
       required by Mobile IP [12].

    3. The foreign agent relays the Registration Request either to its
       locally configured AAA Infrastructure (see appendix B), according
       to local policy.

    4. The foreign agent receives a Registration Reply with the
       appropriate indications for authorizing connectvity for the
       mobile node, which also includes the necessary AAA Key Reply
       extensions.  Along with this Registration Reply, the foreign
       agent may also receive key material by some other secure method
       appropriate for communications between it and its local AAA
       infrastructure.

    5. The foreign agent relays the Registration Reply to the mobile
       node, along with the new Key Reply extensions to be used by the
       mobile node to establish security associations with the relevant
       mobility agents (foreign agent and/or home agent).

   Diagram 10 illustrates the message flow for the case when the
   mobile node receives an unsolicited registration key 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 Registration Keys


   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).



Perkins, Calhoun            Expires 26 August 2002             [Page 23]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


    2. The mobile node creates a Registration Request including an
       authorization-enabling authentication extension as required by
       Mobile IP [12].

    3. The foreign agent relays the Registration Request either to its
       locally configured AAA Infrastructure (see appendix B), according
       to local policy.

    4. The foreign agent receives a Registration Reply with the
       appropriate indications for authorizing connectvity for the
       mobile node, which also includes the necessary AAA Key Reply
       extensions.  Along with this Registration Reply, the foreign
       agent may also receive key material by some other secure method
       appropriate for communications between it and its local AAA
       infrastructure.

    5. The foreign agent relays the Registration Reply to the mobile
       node, along with the new Key Reply extensions to be used by the
       mobile node to establish security associations with the relevant
       mobility agents (foreign agent and/or home agent).






Addresses

   The working group can be contacted via the current chairs:

      Basavaraj Patil                      Phil Roberts
      Nokia                                Megisto Corp.
      6000 Connection Dr.                  Suite 120
                                           20251 Century Blvd
      Irving, TX. 75039                    Germantown MD 20874
      USA                                  USA
      Phone:  +1 972-894-6709              Phone:  +1 847-202-9314
      Email:  Basavaraj.Patil@nokia.com    Email:  PRoberts@MEGISTO.com



   Questions about this memo can also be directed to the authors:










Perkins, Calhoun            Expires 26 August 2002             [Page 24]


Internet Draft          AAA Keys for Mobile IP          26 February 2002


        Charles E. Perkins                Pat R. Calhoun
        Communications Systems Lab
        Nokia Research Center             Black Storm Networks
        313 Fairchild Drive               250 Cambridge Avenue, Suite 200
        Mountain View, California 94043   Palo Alto, California, 94306
        USA                               USA
        Phone:  +1-650 625-2986           Phone:  +1 650-617-2932
        EMail:  charliep@iprg.nokia.com   Email:  pcalhoun@diameter.org
        Fax:  +1 650 625-2502             Fax:  +1 650-786-6445











































Perkins, Calhoun            Expires 26 August 2002             [Page 25]