diff options
Diffstat (limited to 'doc/rfc/rfc3957.txt')
| -rw-r--r-- | doc/rfc/rfc3957.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc3957.txt b/doc/rfc/rfc3957.txt new file mode 100644 index 0000000..746868f --- /dev/null +++ b/doc/rfc/rfc3957.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group C. Perkins +Request for Comments: 3957 Nokia Research Center +Category: Standards Track P. Calhoun + Airespace + March 2005 + + + Authentication, Authorization, and Accounting (AAA) + Registration Keys for Mobile IPv4 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Authentication, Authorization, and Accounting (AAA) servers, such as + RADIUS and DIAMETER, are in use within the Internet today to provide + authentication and authorization services for dial-up computers. + Mobile IP for IPv4 requires strong authentication between the mobile + node and its home agent. When the mobile node shares an AAA Security + Association with its home AAA server, however, it is possible to use + that AAA Security Association to create derived Mobility Security + Associations between the mobile node and its home agent, and again + between the mobile node and the foreign agent currently offering + connectivity to the mobile node. This document specifies extensions + to Mobile IP registration messages that can be used to create + Mobility Security Associations between the mobile node and its home + agent, and/or between the mobile node and a foreign agent. + + + + + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 1] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Overview of Operations with Key Generation Nonce Extensions. . 5 + 4. Mobility Security Associations . . . . . . . . . . . . . . . . 7 + 5. Key Generation Nonce Creation and Key Derivation . . . . . . . 8 + 6. Key Generation Extensions. . . . . . . . . . . . . . . . . . . 9 + 6.1. Generalized MN-FA Key Generation Nonce Request Extension 10 + 6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 11 + 6.3. Generalized MN-HA Key Generation Nonce Request Extension 13 + 6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 14 + 7. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16 + 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 11.2. Informative References . . . . . . . . . . . . . . . . . 19 + Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20 + B. Message Flow for Requesting and Receiving Registration Keys 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27 + +1. Introduction + + AAA servers, such as RADIUS [11] and DIAMETER [12], are in use within + the Internet today to provide authentication and authorization + services for dial-up computers. Such services are likely to be + valuable for mobile nodes using Mobile IP for IPv4 [1], when the + nodes are attempting to connect to foreign domains with AAA servers. + In this document Mobile IP for IPv4 is called "Mobile IPv4" or just + "Mobile IP" for short, since no confusion with other versions is + expected. Requirements for interactions between AAA and Mobile IP + are outlined in RFC 2977 [13]; that document describes an + infrastructure which enables AAA servers to authenticate and + authorize network access requests from mobile nodes. See also + appendix A. The Mobile IP Registration Request is considered to be a + request for network access. It is then possible to augment the + functionality of the Mobile IP mobility agents so that they can + translate between Mobile IP registration messages and the messages + used within the AAA infrastructure, as described in RFC 2977. + Mobility agents and AAA servers that conform to the requirements of + RFC 2977 can be considered as appropriate network entities to support + the message types specified in this document. Please consult RFC + 2977 [13] for further details. + + + + +Perkins & Calhoun Standards Track [Page 2] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + This specification makes use of a single AAA Security Association to + create derivative Mobility Security Associations. A Mobility + Security Association in this specification is a simplex connection + that serves to authenticate MIPv4 control traffic between a MN and HA + and/or a MN and FA. A Mobility Security Association is identified by + the two end points, such as a MN IP address and a HA IP address, and + a SPI. Two nodes may have one or more Mobility Security Associations + established between each other; however, typically there is no reason + to have more than one Mobility Security Association between two + nodes. + + This document specifies extensions to Mobile IP registration messages + that can be used to create Mobility Security Associations between the + MN and FA and/or MN and HA based on the AAA Security Association + between the MN and AAA server. These new Mobility Security + Associations may then be used to calculate the Authentication Data + needed by authentication extensions used in Mobile IP control + messages. + + It is assumed that the security association between the mobile node + and its AAA server has been appropriately configured so that the AAA + server can provide key material to be used as the basis for the + necessary Mobility Security Association(s) between the mobile node + and its prospective mobility agents. + + AAA servers typically use the Network Access Identifier (NAI) [2] to + uniquely identify the mobile node; the mobile node's home address is + not always necessary to provide that function. Thus, it is possible + for a mobile node to authenticate itself, and be authorized for + connection to the foreign domain, without having any home address. + However, for Mobile IP to work, the mobile node is required to have a + home address and a Mobility Security Association [1] with its home + agent. When the Mobile IP Registration Reply packet is authenticated + by the MN-AAA Authentication Extension [3], the mobile node can + verify that the key material contained in the extensions were + produced by the AAA server, and thus may be reliably used to create + Mobility Security Associations with the home agent and/or the foreign + agent. + + It is also assumed that the AAA entities involved (i.e., the AAAH, + AAAL, and the AAA interface features of the foreign agents and home + agents) all have means outside of the scope of this document for + exchanging keys. The extensions within this document are intended to + work with any AAA protocol suite that allows for such key exchange, + as long as it satisfies the requirements specified in RFC 2977 [13]. + One such AAA protocol is defined within the Diameter framework [14]. + + + + + +Perkins & Calhoun Standards Track [Page 3] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [4]. + + AAA Authentication, Authorization, and Accounting (see + [10]). + + AAA entity A network node processing AAA messages according to the + requirements for AAA protocols (see [10]). + + AAA Security Association + A security association between a AAA entity and another + node needing the services of that AAA entity. In this + document all AAA Security Associations are between a + mobile node and its home AAA server (AAAH). A mobile + node's AAA Security Association with its home AAA + server (AAAH) may be based either on the mobile node's + IP address or on its NAI [2]. The key is referred to + as "AAA-key" in this specification. + + Key A number, kept secret. Only nodes in possession of the + key have any hope of using the security transform to + obtain correct results. + + Key Generation Nonce + Nonce data used for the purpose of creating a key. + + Mobility Security Association + A Mobility Security Association is a simplex connection + that applies security services to RFC 3344 MIPv4 + control traffic between a MN and HA (or MN and FA) + using RFC 3344 Authentication Extensions. A Mobility + Security Association is uniquely identified by the peer + source and destination IP addresses and an SPI. Two + nodes may have one or more Mobility Security + Associations; however, typically there is no reason to + have more than one Mobility Security Association + between two nodes, except as a transient condition + during re-keying events. + + Registration Key + A key used in the MN-FA or MN-HA Mobility Security + Association. A registration key is typically only used + once or a very few times, and only for the purposes of + verifying a small volume of Authentication data. + + + + +Perkins & Calhoun Standards Track [Page 4] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Security Algorithm + A set of rules for using input data and a secret key + for producing data for use in security protocols. + + SPI Security Parameters Index. The SPI is an arbitrary + 32-bit value that assists in the identification of an + AAA, IP, or Mobility Security Association. + + Other terminology is used as defined in the base Mobile IP + specification [1]. Furthermore, in order to simplify the discussion, + we have used the word "Extension" instead of "Subtype of the + Generalized Extension" in many cases. So, for instance, instead of + using the phrase "The MN-FA Key Generation Nonce From AAA Subtype of + the Generalized MN-FA Key Generation Nonce Reply Extension", we would + instead use the phrase "The MN-FA Key Generation Nonce From AAA + Extension". + +3. Overview of Operations with Key Generation Nonce Extensions + + When a mobile node depends on an AAA infrastructure to obtain + authorization for network connectivity and Mobile IP registration, it + may lack any pre-existing Mobility Security Associations with either + its home agent, or the foreign agent controlling the access to the + foreign network. The extensions defined in this document allow a AAA + entity to supply key material to mobile nodes to be used as the basis + of its Mobility Security Association with mobile agents. The AAA + entity that will act on these extensions is part of the AAA + infrastructure, and is typically identified within the foreign domain + by methods outside the scope of this specification (see appendix A). + + The key material may be requested by the mobile node in new + extensions (defined below) to Mobile IP Registration Request + messages, and supplied to the mobile node in extensions to the Mobile + IP Registration Reply messages. Alternatively, the AAA server MAY + provide unsolicited key material via mobility agents to mobile nodes; + the mobile node MUST then calculate new keys and update or create its + relevant Mobility Security Association. The method by which key + material is supplied to the mobility agents themselves is out of + scope for this document, and would depend on the particular details + of the security architecture for the AAA servers in the foreign and + home domains (see RFC 2977 and appendix A). For the purposes of this + document, we assume that there is a suitable AAA infrastructure + available to the home and foreign agents, and that the mobile node + does have an AAA Security Association with at least one AAA server in + its home domain. + + + + + + +Perkins & Calhoun Standards Track [Page 5] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + When a mobile node travels away from home, it may not have a Mobility + Security Association with its home agent, perhaps because it does not + yet have a home address [5]. The protocol and messages in this + document are intended to facilitate the following operations which + may occur between the mobile node, foreign agent, home agent, and AAA + servers in the visited (local) domain (Authentication, Authorization + and Accounting Local or AAAL) and in the home domain (Authentication, + Authorization, and Accounting Home or AAAH). In the following + sequence of messages, the only message flows specified in this + document are the Registration Request between the mobile node and the + foreign agent, and Registration Reply between the foreign agent and + the mobile node. The other messages described here result from the + presumed action of the AAA entities as described in RFC 2977. See + also appendix B. + + 1. If the mobile node does not have a Mobility Security Association + with the foreign agent, it SHOULD include an MN-FA Key Generation + Nonce Request extension (see Section 6.1) as part of its + Registration Request that it sends to the Foreign Agent. + + 2. If the mobile node does not have a Mobility Security Association + with the home agent, it MUST add an MN-HA Key Generation Nonce + Request extension (see Section 6.3) as part of its Registration + Request that it sends to the Foreign Agent. + + 3. If one or more AAA Key Generation Nonce Request extensions were + added, the mobile node MUST add the MN-AAA Authentication + extension to its Registration Request. + + 4. By action of the foreign agent, which is presumed to be also a + AAA entity, the mobile node's key requests and authentication + data are transferred to the local AAA server (AAAL), typically + after reformatting to fit into the appropriate AAA messages, + which are out of scope for this document. + + 5. After the information within the MN-AAA Authentication extension + is verified by the AAA server in the home domain (AAAH), it then + also generates the key material that has been requested by the + mobile node, for the necessary Mobility Security Associations. + + 6. The respective keys for the Mobility Security Associations are + distributed to the Home Agent and Foreign Agent via the AAA + protocol. + + 7. The mobile node receives the Registration Reply message from the + Foreign Agent. + + + + + +Perkins & Calhoun Standards Track [Page 6] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + 8. If a MN-HA Key Generation Nonce Request From AAA extension is + present in the Registration Request message, then the mobile node + MUST create or update its Mobility Security Association with the + Home Agent indicated in the corresponding Registration Reply, + using the key computed from the key material in the MN-HA Key + Generation Nonce From AAA extension. In this case, if no MN-HA + Key Generation Nonce Reply extension is present, the mobile node + MUST discard the Registration Reply. + + 9. Using its (perhaps newly created) Mobility Security Association + with the home agent, the mobile node authenticates the + Registration Reply message by checking the Authentication Data in + the Mobile-Home Authentication extension. If the check fails, + the MN MUST discard the Registration Reply and the new Mobility + Security Association, reverting to the old Mobility Security + Association with the home agent, if any. + + 10. If the Registration Reply passes authentication and contains a + MN-FA Key Generation Nonce From AAA extension (see section 6.2), + the mobile node generates the registration key using the Key + Generation Nonce provided, according to its AAA Security + Association with the AAA. The resulting registration key is used + to establish the mobile node's Mobility Security Association with + its foreign agent, and is used to compute the authentication data + used in the Mobile-Foreign authentication extension. + + If verification of the Mobile-Foreign authentication extension + fails, and if the MN-FA Key Generation Nonce Reply extension was + not protected by another, valid authentication extension, the MN + MUST discard the new Mobility Security Association, reverting to + the old Mobility Security Association with the foreign agent, if + any. + + Any registration reply containing the MN-HA Key Generation Nonce From + AAA extension MUST also contain a subsequent Mobile Home + Authentication extension, created using the generated MN-HA key. + Similarly, a reply containing the MN-FA Key Generation Nonce From AAA + extension MUST also contain a subsequent Mobile Foreign + Authentication extension, created using the registration key. + +4. Mobility Security Associations + + Mobility Security Associations between Mobile IP entities (mobile + nodes, home agents, foreign agents) contain both the necessary + cryptographic key information and a way to identify the cryptographic + transform that uses the key to produce the authentication information + that is present in the Mobile-Home Authentication extension or the + Mobile-Foreign Authentication extension. In order for the mobile + + + +Perkins & Calhoun Standards Track [Page 7] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + node to make use of key material created by the AAA server, the + mobile node also has to be able to identify and select the + appropriate cryptographic transform that uses the key to produce the + authentication. + + The transform identifiers are the same as those used in IPsec. They + are tabulated in the list of Authentication Algorithms allowable as + values for the "Attribute Type" (5) (i.e., "Authentication + Algorithm"), one of the classifications in the tabulated Attribute + Types for "IPsec Security Association Attributes". See + http://www.iana.org/assignments/isakmp-registry for the full listing + of all Attribute Types and other Attributes for IPsec Security + Associations. + + Mobility Security Associations shared between mobile nodes and home + agents also require a replay protection method. The following table + contains the supported replay detection methods. + + Replay Method Name Reference + -------------- ------------ -------------- + 0,1 Reserved + 2 Timestamps RFC 3344 [1] + 3 Nonces RFC 3344 [1] + 4-65535 Unallocated + +5. Key Generation Nonce Creation and Key Derivation + + This section contains the procedures followed in the creation of the + Key Generation Nonce by AAA servers, and the key derivation + procedures used by mobile nodes. Note that the AAA servers will also + deliver the keys to the mobility agents (home agent, foreign agent) + via the AAA protocol. AAA servers that follow these procedures will + produce results that can be understood by mobile nodes. The mobility + agents will faithfully transcribe the results into the appropriate + Mobile IP extensions. + + The following example uses HMAC-SHA1 [6]. All mobile nodes and + mobility agents implementing Mobile IP [1] and implementing the + extensions specified in this document MUST implement HMAC-SHA1 [1]. + Other message authentication codes or keyed hash functions MAY also + be used. The particular algorithm used is configured as part of the + AAA Security Association between the MN and the AAAH server, which is + in turn indexed by the AAA SPI. + + + + + + + + +Perkins & Calhoun Standards Track [Page 8] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + The following steps are performed on the AAAH server: + + 1. The AAA server identifies the mobile node. If the NAI field is + present in the Registration Request, then the NAI is used as the + mobile node identifier. Otherwise, the Home Address field of the + Registration Request is used. + + 2. The AAA server generates a random [7] value of at least 128 bits + to be used as the Key Generation Nonce. + + 3. The AAA server inserts the random value into the Key Generation + Nonce Reply extension in the "Key Generation Nonce" field. + + The following steps are performed by the mobile node (here || + represents concatenation): + + 1. The mobile node calculates + + key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node + identifier}) + + Here the Key Generation Nonce is from the extension in the + Registration Reply, and the mobile node identifier is the MN's + NAI, if present in the Registration Request, or the Home Address + from the Registration Request otherwise. + + 2. The mobile node creates the Mobility Security Association(s), + using the resulting key and the other relevant information in the + Key Generation Nonce Extension. + + The secret key used within the HMAC-SHA1 computation is indicated by + the AAA Security Association indexed by the AAA SPI, which has been + previously configured as the basis for the AAA Security Association + between the mobile node and the AAA server creating the key material. + +6. Key Generation Extensions + + This section defines new Extensions to Mobile IP Registration + Requests and Replies [1]. + + + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 9] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +6.1. Generalized MN-FA Key Generation Nonce Request Extension + + Figure 1 illustrates the Generalized MN-FA Key Generation Nonce + Request Extension (MN-FA KeyGen Request for short). + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mobile Node SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MN-FA Key Generation Nonce Request Subtype Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Figure 1: The Generalized Mobile IP MN-FA Key Generation + Nonce Request Extension + + Type 40 (not skippable) (see [1] and section 8) + + Subtype A number assigned to identify the way in which the + MN-FA Key Generation Nonce Request Subtype Data is + to be used when generating the registration key. + + Length The 16-bit Length field indicates the length of the + extension. It is equal to the number of bytes in + the MN-FA Key Generation Nonce Request Subtype Data + plus 4 (for the Mobile Node SPI field). + + Mobile Node SPI The Security Parameters Index that the mobile node + will assign for the Mobility Security Association + created for use with the registration key. + + MN-FA Key Generation Nonce Request Subtype Data + Data needed to carry out the creation of the + registration key on behalf of the mobile node. + + The MN-FA KeyGen Request defines a set of extensions, identified by + subtype, which may be used by a mobile node in a Mobile IP + Registration Request message to request that some other entity create + a Registration Key for use by the mobile node with the mobile node's + new foreign agent. + + + + + + + + +Perkins & Calhoun Standards Track [Page 10] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + This document defines the subtype 1 for the MN-FA Key Generation + Nonce >From AAA Request (MN-FA AAA KeyGen Request for short). The + MN-FA AAA KeyGen Request has a zero-length Subtype Data field and + MUST appear in the Registration Request before the MN-AAA + Authentication extension. + +6.2. Generalized MN-FA Key Generation Nonce Reply Extension + + The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA + KeyGen Reply for short) supplies keying material requested by the + MN-FA KeyGen Request extension. Figure 2 illustrates the format of + the Generalized MN-FA Key Generation Nonce Reply Extension. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MN-FA Key Generation Nonce Reply Subtype Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: The Generalized Mobile IP MN-FA Key + Generation Nonce Reply Extension + + Type 41 (not skippable) (see [1] and section 8) + + Subtype A number assigned to identify the way in which the MN-FA + Key Generation Nonce Reply Subtype Data is to be used to + obtain the registration key. + + Length The 16-bit Length field is equal to the number of bytes in + the MN-FA Key Generation Nonce Reply Subtype Data. + + MN-FA Key Generation Nonce Reply Subtype Data + An encoded copy of the keying material, along with any + other information needed by the recipient to create the + designated Mobility Security Association. + + For each subtype, the format of the MN-FA Key Generation Nonce Reply + Subtype Data has to be separately defined according to the particular + method required to set up the Mobility Security Association. + + For the subtype defined in this document, the MN-FA Key Generation + Nonce supplied in the data for a subtype of this extension may come + as a result of a request which was sent using a subtype of the + Generalized MN-FA Key Generation Nonce Request Extension. In such + + + + + +Perkins & Calhoun Standards Track [Page 11] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + cases, the SPI to be used when employing the Mobility Security + Association defined by the registration key is the same as given in + the original request. + + Once the mobile node creates the Mobility Security Association with + the foreign agent, by using the transform indexed by the AAA SPI, it + stores that Mobility Security Association indexed by the FA SPI in + its list of Mobile Security Associations. + + If the foreign agent receives a Registration Reply that has no MN-FA + Key Generation Nonce Reply extension, and if it has no existing + Mobility Security Association with the mobile node, the foreign agent + MAY change the Code value of the Registration Reply to MISSING_MN_FA + (see section 7), effectively causing the registration to fail. + + This document defines subtype 1 of the MN-FA KeyGen Reply for the + MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply + for short), shown in figure 3. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AAA SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FA SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm Identifier | Key Generation Nonce ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: The MN-FA Key Generation Nonce From AAA + Subtype-Specific Data + + lifetime This field indicates the duration of time (in seconds) for + which the keying material used to create the registration + key is valid. + + AAA SPI A 32-bit opaque value, indicating the SPI that the mobile + node must use to determine the transform to use for + establishing the Mobility Security Association between the + mobile node and its prospective foreign agent. + + FA SPI The SPI for the Mobility Security Association to the FA + that the mobile node creates using the Key Generation + Nonce. + + + + + +Perkins & Calhoun Standards Track [Page 12] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Algorithm Identifier + This field indicates the transform to be used (stored as + part of the Mobility Security Association with the foreign + agent, and selected from among the values in the + "Authentication Algorithm" table cited in section 4), for + future computations of the Mobile-Foreign Authentication + Extension. + + Key Generation Nonce + A random [7] value of at least 128 bits. + + The MN-FA AAA KeyGen Reply extension MUST appear in the Registration + Reply before the Mobile-Foreign Authentication extension. + + The Key Generation Nonce is provided by the AAA server for use by the + mobile node in creating the registration key, which is used to secure + future Mobile IP registrations with the same foreign agent. + +6.3. Generalized MN-HA Key Generation Nonce Request Extension + + Figure 4 illustrates the Generalized MN-HA Key Generation Nonce + Request Extension (MN-HA KeyGen Request for short). + + Type 42 (not skippable) (see [1] and section 8) + + Subtype a number assigned to identify the way in which the + MN-HA Key Generation Nonce Request Subtype Data is + to be used when generating the registration key. + + Length The 16-bit Length field indicates the length of the + extension. It is equal to the number of bytes in + the MN-HA Key Generation Nonce Request. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mobile Node SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MN-HA Key Generation Nonce Request Subtype Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: The Generalized Mobile IP MN-HA Key Generation + Nonce Request Extension + + Subtype Data plus 4 (for the Mobile Node SPI field). + + + + +Perkins & Calhoun Standards Track [Page 13] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Mobile Node SPI The Security Parameters Index that the mobile node + will assign for the Mobility Security Association + created for use with the registration key. + + MN-HA Key Generation Nonce Request Subtype Data + Data needed to carry out the creation of the MN-HA + key on behalf of the mobile node. + + The MN-HA KeyGen Request Extension defines a set of extensions, + identified by subtype, which may be used by a mobile node in a Mobile + IP Registration Request message to request that some other entity + create an MN-HA key for use by the mobile node with the mobile node's + new home agent. + + This document defines the subtype 1 for the MN-HA Key Generation + Nonce from AAA Request (MN-HA AAA KeyGen Request for short). The + MN-HA AAA KeyGen Request has a zero-length Subtype Data field and + MUST appear in the Registration Request before the MN-AAA + Authentication extension. + +6.4. Generalized MN-HA Key Generation Nonce Reply Extension + + The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA + KeyGen Reply for short) supplies keying material requested by the + MN-HA KeyGen Request extension. Figure 5 illustrates the format of + the Generalized MN-HA Key Generation Nonce Reply Extension. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MN-HA Key Generation Nonce Reply Subtype Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: The Generalized Mobile IP MN-HA Key + Generation Nonce Reply Extension + + Type 43 (not skippable) (see [1] and section 8) + + Subtype a number assigned to identify the way in which the MN-HA + Key Generation Nonce Reply Subtype Data is to be used to + obtain the MN-HA key. + + + + + + +Perkins & Calhoun Standards Track [Page 14] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Length The 16-bit Length field indicates the length of the + extension. It is equal to the number of bytes in the MN- + HA Key Generation Nonce Reply Subtype Data plus 4 (for the + Lifetime field). + + Lifetime This field indicates the duration of time (in seconds) for + which the MN-HA key is valid. + + MN-HA Key Generation Nonce Reply Subtype Data + Data used to derive the MN-HA key, along with any other + information needed by the mobile node to create the + designated Mobility Security Association with the home + agent. + + For each subtype, the format of the MN-HA Key Generation Nonce Reply + Subtype Data has to be separately defined according to the particular + method required to set up the Mobility Security Association. + + This document defines subtype 1 of the MN-HA KeyGen Reply for the + MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply + for short), shown in figure 6. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AAA SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HA SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm Identifier | Replay Method | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Generation Nonce ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: The MN-HA Key Generation Nonce From AAA + Subtype-Specific Data + + AAA SPI A 32-bit opaque value, indicating the SPI that the mobile + node must use to determine the transform to use for + establishing the Mobility Security Association between the + mobile node and its home agent. + + HA SPI The SPI for the Mobility Security Association to the HA + that the mobile node creates using the Key Generation + Nonce. + + + + + + +Perkins & Calhoun Standards Track [Page 15] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Algorithm Identifier + This field indicates the transform to be used for future + computations of the Mobile-Home Authentication Extension + (see section 4). + + Replay Method + This field contains the replay method to be used for + future Registration messages (see section 4). + + Key Generation Nonce + A random [7] value of at least 128 bits. + + The MN-HA AAA KeyGen Reply subtype-specific data is shown in figure + 6. The Mobile Node calculates the MN-HA key using the Key Generation + Nonce provided by the AAA server. The calculation proceeds by using + the key shared between the mobile node and the AAA server that has + previously been configured for securing all such communication + requirements with the AAA server which will be contacted within the + AAA infrastructure (see appendix A). The MN-HA key is intended for + use by the mobile node to secure future Mobile IP registrations with + its home agent. The MN-HA AAA KeyGen Reply extension MUST appear in + the Registration Reply before the MN-HA Authentication extension. + + Once the mobile node creates the MN-HA Key, by using the transform + specified in the AAA SPI, it stores the HA Security Information + indexed by the HA SPI in its list of Mobile Security Associations. + The mobile node uses the Identification field data from the + Registration Reply as its initial synchronization data with the home + agent. + +7. Error Values + + Each entry in the following table contains the name of the Code [1] + value to be returned in a Registration Reply, the value for that + Code, and the section in which the error is first mentioned in this + specification. + + Error Name Value Section + ---------------------- ----- --------- + MISSING_MN_FA 107 6.2 + +8. IANA Considerations + + This document defines 4 new extensions (see Section 6) taken from the + (non-skippable) numbering space defined for Mobile IP registration + extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The + values for these extensions are: + + + + +Perkins & Calhoun Standards Track [Page 16] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Name Value Section + --------------------- ------- --------- + MN-FA-KeyGen Request 40 6.1 + MN-FA-KeyGen Reply 41 6.2 + MN-HA-KeyGen Request 42 6.3 + MN-HA-KeyGen Reply 43 6.4 + + IANA has created and will maintain a new registry for the KeyGen + Request/Reply subtypes. The initial contents of the registry is a + single entry for the subtypes defined in this document: + + Name Value Section + ----------------------------- ------- --------- + KeyGen Request/Reply from AAA 1 6 + + New subtypes for these two registries are assigned through Standards + Action as defined in [9]. + + IANA has assigned a code value for error MISSING_MN_FA, listed in + section 7. This value has been taken from the space of error values + conventionally associated with rejection by the foreign agent (i.e., + 64-127). + + IANA has created and will maintain a namespace for the Replay Method + Identifier. This specification makes use of 2 and 3; all other + values other than zero (0) and (1) are available for assignment, + pending review and approval by a Designated Expert [9]. + +9. Security Considerations + + The extensions in this document are intended to provide the + appropriate level of security for Mobile IP entities (mobile node, + foreign agent, and home agent) to calculate the Authentication Data + needed by authentication extensions used with Mobile IP registration + messages. The Mobility Security Associations resulting from use of + these extensions do not offer any higher level of security than what + is already implicit in use of the AAA Security Association between + the mobile node and the AAAH. In order to deny any adversary the + luxury of unbounded time to analyze and break the secrecy of the AAA + Security Association between the mobile node and the AAA server, that + AAA Security Association MUST be refreshed periodically. + + The provisioning and refreshing of the AAA key in the MN and AAA + server is outside the scope of this document. + + Since the Reply extensions defined in this specification only carry + Key Generation Nonces, which are used to derive keys, they do not + expose any data that could be used in an attack aimed at recovering + + + +Perkins & Calhoun Standards Track [Page 17] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + the key shared between the mobile node and the AAA. The authors do + not believe this specification introduces any new security + vulnerability. + +10. Acknowledgements + + Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG + for their useful comments. Thanks especially to Tom Hiller who has + contributed many textual improvements to later revisions of this + document. + +11. References + +11.1. Normative References + + [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, + August 2002. + + [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC + 2486, January 1999. + + [3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response + Extension", RFC 3012, November 2000. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier + Extension for IPv4", RFC 2794, March 2000. + + [6] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for + Mobile IP", RFC 2356, June 1998. + + [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 18] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +11.2. Informative References + + [10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., + Stevens, M., and B. Wolff, "Authentication, Authorization, and + Accounting: Protocol Evaluation", RFC 3127, June 2001. + + [11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, + "Diameter Base Protocol", RFC 3588, September 2003. + + [13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP + Authentication, Authorization, and Accounting Requirements", RFC + 2977, October 2000. + + [14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions", + Work in Progress, February 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 19] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +Appendix A. AAA Infrastructure + + In this appendix, we attempt to capture the main features of a basic + model for operation of AAA servers that is assumed for understanding + of the use of the Mobile IP registration extensions described in this + document. This information has been adapted from the discussion in + RFC 2977 [13]. + + Within the Internet, a mobile node belonging to one administrative + domain (called the home domain) often needs to use resources provided + by another administrative domain (called the foreign domain). A + foreign agent that handles the mobile node's Registration Request is + likely to require that the mobile node provide some credentials that + can be authenticated before access to the resources is permitted. + These credentials may be provided as part of the Mobile-AAA + Authentication extension [3], relying on the existence of an AAA + infrastructure such as is described in this section, and also + described in RFC 2977 and RFC 3012 [3]. Such credentials are + typically managed by entities within the mobile node's home domain. + They may be also used for setting up secure communications with the + mobile node and the foreign agent, or between the mobile node and its + home agent if necessary. + + Local Domain Home Domain + +--------------+ +----------------------+ + | +------+ | | +------+ | + | | | | | | | | + | | AAAL | | | | AAAH | | + | | +-------------------+ | | + | +---+--+ | | +------+ | + | | | | | + | | | +----------------------+ + +------+ | +---+--+ | + | | | | | | MN = mobile node + | MN |- -|- -| FA | | FA = foreign agent + | | | | | | AAAL = local authority + +------+ | +------+ | AAAH = home authority + | | + +--------------+ + + Figure 7: AAA Servers in Home and Local Domains + + The foreign agent often does not have direct access to the data + needed to verify the credentials. Instead, the foreign agent is + expected to consult an authority (typically in the same foreign + domain) in order to request proof that the mobile node has acceptable + credentials. Since the foreign agent and the local authority (AAAL) + are part of the same administrative domain, they are expected to have + + + +Perkins & Calhoun Standards Track [Page 20] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + established, or be able to establish for the necessary lifetime, a + secure channel for the purposes of exchanging sensitive (access) + information, and keeping it private from (at least) the visiting + mobile node. + + The local authority (AAAL) itself may not have enough information + stored locally to carry out the verification for the credentials of + the mobile node. In contrast to the foreign agent, however, the AAAL + is expected to be configured with enough information to negotiate the + verification of mobile node credentials with its home domain. The + home and foreign domains should be configured with sufficient IP + Security Associations (i.e., IPsec) and access controls so that they + can negotiate the authorization, and also enable the mobile node to + acquire Mobility Security Associations with the mobility agents + within the foreign domain. For the purposes of the key exchanges + specified within this document, the authorization is expected to + depend only upon secure authentication of the mobile node's + credentials. + + Once the authorization has been obtained by the local authority, and + the authority has notified the foreign agent about the successful + negotiation, the foreign agent can deliver the Registration Reply to + the mobile node along with the key material. + + In figure 7, there might be many mobile nodes from many different + Home Domains. Each Home Domain provides a AAAH that can check + credentials originating from mobile nodes administered by that Home + Domain. There is a security model implicit in figure 7, and it is + crucial to identify the specific security associations assumed in the + security model. These IP Security Associations are illustrated in + figure 8, and are considered to be relatively long-lived security + associations. + + First, it is natural to assume that the mobile node has an AAA + Security Association with the AAAH, since that is roughly what it + means for the mobile node to belong to the home domain. + + Second, from the model illustrated in figure 7 it is clear that AAAL + and AAAH have to share an IP Security Association, because otherwise + they could not rely on the authentication results, authorizations, + nor even the accounting data which might be transacted between them. + Requiring such bilateral IP Security Associations is, however, in the + end not scalable; the AAA framework must provide for more scalable + mechanisms, but the methods by which such a broker model is to be + created are out of scope for this document. See RFC 2977 for more + details. + + + + + +Perkins & Calhoun Standards Track [Page 21] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + Finally, from figure 7, it is clear that the foreign agent can + naturally share an IP Security Association with the AAAL. This is + necessary in order for the model to work because the foreign agent + has to have a way to find out that it is permissible to allocate the + local resources to the mobile node, and further to transmit any + successful Registration Reply to the mobile node. + + Figure 8 illustrates the IP Security Associations we understand from + our proposed model. Note that there may be, by mutual agreement + between AAAL and AAAH, a third party inserted between AAAL and AAAH + to help them arbitrate secure transactions in a more scalable + fashion. The broker model which has been designed to enable such + third-party processing should not have any effect on the Mobile IP + extensions specified in this document, and so no description is + provided here; see RFC 2977 [13] for more details. + + +------+ +------+ + | | | | + | AAAL +--------------+ AAAH | + | | | | + +---+--+ +--+---+ + | | + | | + +---+--+ +--+---+ + MN = mobile node | | | | + FA = foreign agent | FA | | MN | + AAAL = local authority | | | | + AAAH = home authority +------+ +------+ + + Figure 8: IP Security Associations + + Nodes in two separate administrative domains (for instance, AAAH and + AAAL) often must take additional steps to verify the identity of + their communication partners, or alternatively to guarantee the + privacy of the data making up the communication. While these + considerations lead to important security requirements, as mentioned + above in the context of security between servers, we consider the + exact choice of IP Security Associations between the AAA servers to + be beyond the scope of this document. The choices are unlikely to + depend upon Mobile IP, or any specific features of the general model + illustrated in figure 7. On the other hand, the Mobility Security + Associations needed between Mobile IP entities are of central + importance in the design of the key derivation extensions in this + document. + + + + + + + +Perkins & Calhoun Standards Track [Page 22] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + One further detail deserves mention. The Mobility Security + Association to be established between the mobile node and the foreign + agent has to be communicated to the foreign agent as well as to the + mobile node. The following requirements are placed on the mechanism + used by the AAA infrastructure to effect key distribution: + + - The AAAH must establish strong, fresh session keys. + + - The mechanism must maintain algorithm independence, allowing for + the distribution of authentication algorithm identification along + with the keys. + + - The mechanism must include replay detection. + + - The mechanism must authenticate all parties, including the AAA + servers and the FA and HA. + + - The mechanism must provide for authorization of the client, FA, + and HA. + + - The mechanism must not rely on plaintext passwords. + + - The mechanism must maintain confidentiality of session keys. + + - The mechanism must uniquely name session keys. + + - The mechanism must be such that the compromise of a single FA and + HA cannot compromise any other part of the system, including + session keys and long-term keys + + - The mechanism must bind key(s) to an appropriate context + + - The mechanism must not expose the keys to entities other than the + AAAH and FA (or HA in the case of key distribution to the HA). + + The way that the key is distributed to the foreign agent (or home + agent) is expected to be handled as part of the AAA protocol + processing between the AAAH and AAAL, and the further AAA protocol + processing between the AAAL and the foreign agent. Such processing + is outside the scope of this document, but must satisfy the above + requirements. + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 23] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +Appendix B. Message Flow for Requesting and Receiving Registration Keys + + In this section, we show message flows for requesting and receiving a + registration key from the AAA infrastructure, described in section A. + Challenge values, as specified in [3], might be added to the + Advertisement and Registration messages for additional replay + protection, but are not illustrated here. + + Diagram 9 illustrates the message flow for the case when the mobile + node explicitly requests keying material to create registration keys. + + MN FA AAA Infrastructure + | | | + |<--- Advertisement-----| | + | (if needed) | | + | | | + |-- RReq+AAA Key Req.-->| | + | |--- RReq + AAA Key Req.--->| + | | | + | |<--- RRep + AAA Key Rep.---| + |<-- RRep+AAA Key Rep.--| | + | | | + + Figure 9: Message Flows for Requesting and + Receiving Key Generation Nonce + + In diagram 9, the following message flow is illustrated: + + 1. The foreign agent disseminates an Agent Advertisement. This + advertisement MAY have been produced after receiving an Agent + Solicitation from the mobile node (not shown in the diagram). + + 2. The mobile node creates a Registration Request including the MN-HA + AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed, + along with an authorization-enabling authentication extension as + required by Mobile IP [1]. + + 3. The foreign agent relays the Registration Request and/or Key + Request(s) to its locally configured AAA Infrastructure (see + appendix A), according to local policy. + + 4. The foreign agent receives a AAA Response with the appropriate + indications for authorizing connectivity for the mobile node. + Along with this AAA Response, the foreign agent may also receive + key material by some secure method appropriate for communications + between it and its local AAA infrastructure. At this point if the + + + + + +Perkins & Calhoun Standards Track [Page 24] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + foreign agent has not relayed the Registration Request, it + forwards it directly to the Home Agent and waits for a + Registration Reply (not shown in the figure). + + 5. The foreign agent relays the Registration Reply to the mobile + node, along with the new AAA KeyGen Reply extensions to be used by + the mobile node to establish Mobility Security Associations with + the relevant mobility agents (foreign agent and/or home agent). + + Diagram 10 illustrates the message flow for the case when the mobile + node receives unsolicited keying material from the AAA + Infrastructure. + + MN FA AAA Infrastructure + | | | + |<--- Advertisement-----| | + | (if needed) | | + | | | + | ------ RReq --------->| | + | |------- RReq ------------->| + | | | + | |<--- RRep + AAA Key Rep.---| + |<-- RRep+AAA Key Rep.--| | + | | | + + Figure 10: Message Flow for Receiving Unsolicited + Key Generation Nonce + + In diagram 10, the following message flow is illustrated: + + 1. The foreign agent disseminates an Agent Advertisement. This + advertisement MAY have been produced after receiving an Agent + Solicitation from the mobile node (not shown in the diagram). + + 2. The mobile node creates a Registration Request including an + authorization-enabling authentication extension as required by + Mobile IP [1]. + + 3. The foreign agent sends a AAA Request (possibly containing the + Registration Request) to its locally configured AAA Infrastructure + (see appendix A), according to local policy. + + 4. The foreign agent receives a AAA Response with the appropriate + indications for authorizing connectivity for the mobile node. + Along with this AAA Response, the foreign agent may also receive + key material by some secure method appropriate for communications + between it and its local AAA infrastructure. At this point, if + the foreign agent has not relayed the Registration Request, it + + + +Perkins & Calhoun Standards Track [Page 25] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + + forwards it directly to the Home Agent and waits for a + Registration Reply (not shown in the figure). + + 5. The foreign agent relays the Registration Reply to the mobile + node, along with the new KeyGen Reply extensions to be used by the + mobile node to establish Mobility Security Associations with the + relevant mobility agents (foreign agent and/or home agent). + +Authors' Addresses + + Charles E. Perkins + Nokia Research Center + 313 Fairchild Drive + Mountain View, California 94043 + USA + + Phone: +1 650 625-2986 + Fax: +1 650 625-2502 + EMail: charles.perkins@nokia.com + + + Pat R. Calhoun + Airespace, Inc. + 110 Nortech Parkway + San Jose, CA 95134 + USA + + Phone: +1 408 635 2000 + Fax: +1 408 635 2020 + EMail: pcalhoun@airespace.com + + + + + + + + + + + + + + + + + + + + + +Perkins & Calhoun Standards Track [Page 26] + +RFC 3957 AAA Keys for Mobile IPv4 March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Perkins & Calhoun Standards Track [Page 27] + |