Mipshop V. Narayanan Internet-Draft Motorola Expires: April 24, 2006 N. Venkitaraman Motorola Labs H. Tschofenig Siemens G. Giaretta TILab J. Bournelle GET/INT October 21, 2005 Handover Keys Using AAA draft-vidya-mipshop-handover-keys-aaa-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a AAA-assisted key management protocol to Narayanan, et al. Expires April 24, 2006 [Page 1] Internet-Draft Handover Keys Using AAA October 2005 generate session keys between a mobile node (MN) and an access router (AR) for the purpose of securing handoff signaling messages. As such, it specifies a message exchange between the MN and the AR and assumptions that must hold in order for this protocol to work. The idea is that the key derived between a mobile node and an access router through this protocol can be used in fast handovers. The protocol is loosely based on the Mobile IP-AAA model [11] where the MN-HA security association is derived using a AAA server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals and Assumptions . . . . . . . . . . . . . . . . . . 3 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Mobility Header Types . . . . . . . . . . . . . . . . . . 7 4.1.1. Handover Key Request (HKReq) . . . . . . . . . . . . . 7 4.1.2. Handover Key Response (HKResp) . . . . . . . . . . . . 9 4.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 11 4.2.1. Handover Nonce Mobility Sub-Option . . . . . . . . . . 11 4.3. New Neighbor Discovery Options . . . . . . . . . . . . . . 12 4.3.1. Handover Key NS Option . . . . . . . . . . . . . . . . 12 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Mobile Node Considerations . . . . . . . . . . . . . . 13 5.1.2. Access Router Considerations . . . . . . . . . . . . . 15 5.1.3. AAA Server Considerations . . . . . . . . . . . . . . 17 5.2. Indirect MN-AR Handover Key Exchange . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Deriving the Handover Master Key . . . . . . . . . . 22 A.1. Identity Derivation for the Mobile Node . . . . . . . . . 24 Appendix B. RADIUS Handover Key Attributes . . . . . . . . . . . 24 Appendix C. Diameter Handover Key Application . . . . . . . . . . 27 C.1. New Messages . . . . . . . . . . . . . . . . . . . . . . . 27 C.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 C.3. Diameter Flow of Messages . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Narayanan, et al. Expires April 24, 2006 [Page 2] Internet-Draft Handover Keys Using AAA October 2005 1. Introduction Fast Mobile IPv6 [1] specifies a fast handoff protocol for IPv6 mobile nodes. It requires tunneling of packets from an old access router to the mobile node. For this purpose, the FMIPv6 signaling messages between the mobile node and the access router must be secured to ensure FMIPv6 support for a legitimate mobile node that has been authorized to obtain such services. The FMIPv6 protocol itself does not provide a method to establish a session key and the corresponding parameters between the mobile node and the access router required for this purpose. This document describes a AAA-assisted key management protocol to generate session keys between a mobile node and an access router for usage in the context of FMIPv6. As such, it specifies: o A message exchange between the MN and the AR o Payloads to carry keying material and parameters in the AAA infrastructure o Derivation of a new session key for handoff purposes based on a shared secret 1.1. Goals and Assumptions This document has been written with the following goals and assumptions in mind. o The protocol is designed to leverage the existence of AAA infrastructure to establish session keys for securing Fast MIPv6 signaling messages. AAA is widely deployed today due to the usage of AAA-based network access authentication infrastructure. The AAA server is used to authenticate and authorize the MN for fast handovers prior to generation of the handover key. The solution presented in this document relies on the AAA infrastructure components to derive and distribute keying material keys for handover support. o A Handover Master Key (HMK) between the MN and the home AAA server (AAAH ) is required for this protocol to be able to derive handover keys between the MN and AR. The exact method of establishing or deriving this HMK is outside the scope of this document. No particular method is mandated for this protocol to work but we illustrate an example approach using the Application Master Session Key (AMSK), as defined in EAP, in Appendix A. Due to deployment considerations, it may be practical to use the method to derive the HMK. Narayanan, et al. Expires April 24, 2006 [Page 3] Internet-Draft Handover Keys Using AAA October 2005 o Key naming of the HMK is provided using the Network Access Identifier (NAI). In order to provide identity protection, it may be undesirable to reuse the same NAI as used for network access authentication. For sake of identity protection, it may be desirable to have the AAA server to derive an ephemeral identity at the time of HMK creation that can be used in subsequent creation of handover keys. o It is further assumed that a security association exists between each AR and the AAA server. If a AAAL or other proxies are used (as it is typical in a roaming environment) then the AR will likely share a security association only with its local AAA server (AAAL) instead of the user's home AAA server (AAAH). The AAAL in this case acts as a AAA proxy between the AR and the AAAH server. These security associations protect the signaling message exchange including the transport of keying material and other security sensitive parameters. o The protocol does not introduce any new required steps at the time of handover. Any new messages introduced for deriving handover keys can be exchanged prior to the handover process. o The protocol has been designed such that the compromise of one AR does not lead to the compromise of any other AR. No AR is able to view the key of another AR - keys are transferred securely from the AAA server directly to the AR requesting it. 1.2. Applicability Although this document is focused on FMIPv6, it is applicable to other protocols as well. In the context of FMIPv6, the key derived using this protocol can be used to secure the Fast Binding Update (FBU) sent from the MN to the PAR as specified in [1]. Other protocols may also use this mechanism as noted below. For instance, CxTP [12] can also use this protocol to derive keys between the AR and MN to secure the CTAR message. Additionally, keys between an MN and a MAP can be derived using this protocol for HMIPv6 [13] operation. This draft, however, does not address any details on how the protocol described in this draft may be used for CxTP or HMIPv6. The document is organized as follows. Section 2 describes the terminology used in this document. Section 3 provides a general protocol overview. Section 4 details the message formats. Section 5 provides protocol details on mobile node and access router operation. Section 6 describes the security considerations for this protocol. Appendix A provides a method of deriving the handover master key using EAP. Appendices B and C describe the AAA messages and attributes necessary for this protocol in RADIUS [2] and Diameter [3] Narayanan, et al. Expires April 24, 2006 [Page 4] Internet-Draft Handover Keys Using AAA October 2005 respectively. 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 RFC- 2119 RFC2119 [4]. In addition, this document uses the following terms: MN-AAA Handover Master Key (HMK): A key that is shared between the Mobile Node and the AAAH server, hereby referred to simply as the Handover Master Key. Handover Key (HK): Session key used to secure messages between the Mobile Node and Access Router. A given HK between an MN and ARn is termed as HKn. 3. Protocol Overview This section provides a description of the procedure to obtain the Handover Key (HK). We assume that the MN shares a session key, called Handover Master Key (HMK), with the AAA (AAAH) server. This key, for instance, may be the derived from the EAP key hierarchy. Appendix A describes a method of deriving the HMK and an identity for the MN from the EAP Application Master Session Key (AMSK). This method can be used whenever possible. For the purpose of the protocol itself, the HMK may simply be a handover specific master key pre-shared between the MN and the AAA server. Figure 1 depicts the high-level protocol interaction. MN AR AAAH Server | HKReq. | | | ---------> | | | | AAA Request | | | ----------------------> | | | AAA Response | | | <----------------------- | | HKResp. | (Keying material) | | <--------- | | Figure 1: Protocol Operation Narayanan, et al. Expires April 24, 2006 [Page 5] Internet-Draft Handover Keys Using AAA October 2005 The MN, upon attaching to an AR (say AR1) in a given administrative domain, sends a Handover Key Request (HKReq) message to the AR. The MN creates a HKReq message including a NAI-like identifier (that was derived possibly during the time of HMK derivation), a message ID, a sequence number, care-of-address (CoA) and a keyed message digest of these fields by using the HMK. Upon receiving the HKReq from the MN, AR1 verifies the validity and uniqueness of the CoA claimed by the MN. AR1 must first ensure that it has a valid neighbor cache entry for the CoA claimed by the MN. AR1 must also ensure that no other mobile node on that link claims the same CoA specified in the HKReq. Details of these operations are described in section Section 5. After verifying the validity and uniqueness of the CoA of the MN, AR1 forwards the HKReq message to the AAA Server via the AAA infrastructure. The keyed message digest allows the home AAA server to authenticate the MN and to perform authorization for fast handoffs before deriving a unique and fresh session key, the Handover Key (HK1). HK1 will subsequently be used between the MN and the AR1 after a successful protocol execution. The key derivation procedure for the Handover Key is defined as follows: HK1 = PRF(HMK, AAA-MN Nonce | AR1 ID | MN ID, "Handover Key"), where | indicates concatenation The AR1 ID is the IP address of AR1 as seen by the MN. The MN ID is the NAI of the MN that is sent by the MN in the HKReq message. The AAA-MN Nonce is a nonce generated by the AAA server for the purpose of HK1 derivation. After successful authentication and authorization, the AAA Server then sends two different parameters to AR1 - one of the parameters includes the session key HK1 and the lifetime associated with it. The other parameter, to be sent to the MN, includes the AAA-MN Nonce. A keyed message digest computed based on the HMK is included with this parameter to the MN. The message is protected with the AR1-AAA SA when forwarded to AR1. AR1 sends a Handover Key Response (HKResp) to the MN, including the material (nonce) sent by the AAA server and also the key lifetime it received from the AAA server. Using this keying material, the MN derives HK1. When the MN is ready to send an FBU to AR1 (in accordance with [1], it uses HK1 to secure the FBU message. Narayanan, et al. Expires April 24, 2006 [Page 6] Internet-Draft Handover Keys Using AAA October 2005 4. Message Formats This protocol defines new Mobility Header types for carrying the Handover Key Request (HKReq) and Handover Key Response (HKResp) messages. This protocol also defines a new Mobility Option called Handover Nonce Mobility Option and a new Neighbor Discovery option called Handover Key NS Option. This section presents the description of the HKReq and HKResp messages and the Handover Nonce Mobility option and the Handover Key NS Option that this protocol uses. The description of AAA attributes that are needed for this protocol are described in Appendices B and C. Appendix B provides the attributes for RADIUS and Appendix C describes a Diameter handover application. 4.1. Mobility Header Types 4.1.1. Handover Key Request (HKReq) A Handover Key Request (HKReq) message MUST be sent from the MN to the AR to request the derivation of a handover key. The MN sends this message some time after selecting the AR as its default router but prior to the need to hand over to a different AR. The detailed processing rules for this message are described in the Protocols Details section. The HKReq message uses the MH Type value TBA1. The length in the mobility header is set to include the mobility suboptions. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |v| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Care of Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Suboptions (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Narayanan, et al. Expires April 24, 2006 [Page 7] Internet-Draft Handover Keys Using AAA October 2005 Figure 2: Handover Key Request HKReq Fields Message Type A one octet field indicating the handover key exchange mechanism encoded in the mobility options, the value of which is taken from the IANA Handover Key Exchange Mechanism Type registry. A value of '1' (to be assigned by IANA) indicates AAA-assisted handover key exchange. Other key exchange protocols defined in future may define additional values. v Verify flag. This is set by the MN to indicate that it may already share a key with the AR. Reserved Set to 0; ignored on reception. Message ID A two octet random value used to uniquely match requests and responses and identify retransmissions. Sequence # A two octet unsigned integer used by the AR to sequence HKReq messages and by the MN to match a returned HKResp with this HKReq. Key Care of Address Sixteen octet field containing the IPv6 CoA for which the key is requested. Mobility Suboptions Variable length field of such length that the complete Mobility Header is an integer multiple of 8 octets. This field contains zero or more TLV-encoded mobility suboptions. Valid mobility sub-options for this message include the following: Narayanan, et al. Expires April 24, 2006 [Page 8] Internet-Draft Handover Keys Using AAA October 2005 Mobile Node Identifier Mobility Sub-option, as defined in [5] MN-AAA Auth Option as defined in [6] MN-AR Auth Option as defined in [7] 4.1.2. Handover Key Response (HKResp) A handover key response (HKResp) message MUST be sent from the AR to the MN in response to a HKReq message. HKResp MUST carry suboptions appropriate to the key agreement mechanism requested in the HKReq, which the MN can use to configure itself with a handover key for the requested CoA. The HKResp message uses the MH Type value TBA2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |v| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Handover Key Response HKResp Fields Message Type A one octet field indicating the key exchange mechanism encoded in the mobility options, the value of which is taken from the IANA Handover Key Agreement Mechanism Type registry. A value of '1' (to be assigned by IANA) indicates AAA-assisted handover Narayanan, et al. Expires April 24, 2006 [Page 9] Internet-Draft Handover Keys Using AAA October 2005 key exchange. Other key exchange protocols defined in future may define additional values. Verified flag. Set by the AR in response to a HKReq with the V bit set, if it verified the request. Reserved Set to 0; ignored on reception. Message ID A two octet random value used to uniquely match requests and responses and identify retransmissions. This value is copied from the corresponding HKReq. Sequence # A two octet unsigned integer from the matching HKReq that triggered this message. Status Code One octet status code indicating the status of the request. 0 - Success. 129 - Requested handover key exchange mechanism is not supported. 130 - Care of address authorization denied. 131 - Administratively prohibited. 132 - Unable to verify handover key 133 - MN-AAA Authentication Option Required 134 - MN-AR Authentication Option Required 135 - Invalid MN-AAA Authenticator Value (Sent by the AAA server) Narayanan, et al. Expires April 24, 2006 [Page 10] Internet-Draft Handover Keys Using AAA October 2005 136 - Invalid MN-AR Authenticator Value Lifetime Lifetime of the handover key, in seconds. SPI Four octet Security Parameter Index for the handover key at the AR. The SPI is used by the MN and the AR to identify the key when the key is used. Mobility Suboptions Variable length field of such length that the complete Mobility Header is an integer multiple of 8 octets. This field contains zero or more TLV-encoded mobility suboptions. Valid mobility sub-options for this message include the following: Nonce Mobility Sub-option (new option defined in section Section 4.2.1 below) MN-AAA Auth Option as defined in [6] MN-AR Auth Option as defined in [7] 4.2. New Mobility Options 4.2.1. Handover Nonce Mobility Sub-Option This new mobility option is defined to carry the nonce in the HKResp to the MN. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Handover Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Handover Nonce Mobility Option Narayanan, et al. Expires April 24, 2006 [Page 11] Internet-Draft Handover Keys Using AAA October 2005 Option Fields Option Type Handover Nonce (to be assigned by IANA) Option Length 8-bit unsigned integer, representing the length in octets of the Sub-type, and the handover nonce fields. Sub-type '1' - AAA-Nonce (nonce generated by the AAA Server) Set to 0 and ignored on reception. A variable length nonce generated by the AAA server. 4.3. New Neighbor Discovery Options 4.3.1. Handover Key NS Option This option is used in the neighbor solicitation sent by the AR in response to a HKReq received from a mobile node. 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 | Length | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Handover Key NS Option Option Fields Option Type Handover Message ID (to be assigned by IANA) Narayanan, et al. Expires April 24, 2006 [Page 12] Internet-Draft Handover Keys Using AAA October 2005 Option Length 8-bit unsigned integer, representing the length in octets of the message ID field. Message ID Copied from the Message ID field in the HKReq that triggered the neighbor solicitation. 5. Protocol Details 5.1. Basic Protocol The proposed protocol enables a MN to derive session keys (HKs) with an access router. This section describes the processing rules for the mobile node, the access router and the AAA server. 5.1.1. Mobile Node Considerations After completing MIPv6 signaling the mobile node SHOULD immediately proceed to obtain a session key between itself and its current AR. 5.1.1.1. Sending Handover Key Request Messages In order to derive a shared key with the AR, the MN MUST create a HKReq with a unique, random Message ID with the sequence number starting at 0. For subsequent retransmissions, the sequence number MUST be incremented by 1 and the Message ID MUST remain the same. The HKReq sent by the MN MUST include the MN-AAA Authentication Option. The authentication data in the MN-AAA authentication option shall be calculated as follows: Authentication data = hash_fn(MN-AAA Shared key, MH Data) hash_fn() is decided by the value of mobility SPI field in the authentication option. If the mobility SPI indicates HMAC_SHA1, then hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the HKReq is authenticated by AAA using HMAC_SHA1 authentication. MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The MN should send a new HKReq before the expiry of lifetime of the Narayanan, et al. Expires April 24, 2006 [Page 13] Internet-Draft Handover Keys Using AAA October 2005 key obtained via the pervious HKReq. Once a MN obtains a new key, it MUST discard the old key and use the new key for authenticating the FBU. If the MN does not receive a response after a configured timeout (HKEY_REQ_TOUT), it SHOULD retransmit the request for a maximum of N HO_KEYTRIES. In each of the retry attempts, the MN MUST use the same message ID. The default value of N_HO_KEYTRIES is 3. 5.1.1.2. Receiving and Processing Neighbor Solicitation Message with Handover Key Option When the MN receives a neighbor solicitation from the AR with the Handover Key Option corresponding to the HKReq sent by it, it MUST NOT respond with a neighbor advertisement. 5.1.1.3. Receiving and Processing Handover Key Response Messages Upon receiving a successful HKResp message from the AR, the MN MUST compute the handover key using the keying material contained in the HKResp message. The key is computed as follows: HK = PRF(HMK, AAA-MN Nonce | AR ID | MN ID, "Handover Key"), where | indicates concatenation The AR ID is the IP address of the AR. The MN ID is the NAI of the MN that is sent by the MN in the HKReq message. The AAA-MN Nonce is a nonce generated by the AAA server and included in the HKResp received by the MN. Additionally, the MN MUST store the SPI and lifetime associated with the key, as sent in the HKResp. 5.1.1.3.1. Error Processing If the MN receives a HKResp with the Code set to HKE_NOT_SUPPORTED, it SHOULD use a different key exchange protocol to derive the handover key. If the code is set to COA_UNAUTHORIZED, it MAY retransmit the HKReq after a random time greater than HK_RETRY_INTERVAL. However, the MN MUST NOT retransmit the HKReq more than N HO_KEYTRIES. If the code is set to MN_AAA_AUTH_REQD, the MN MUST send a new HKReq with the MN AAA Authentication Option included. If the code is set to INVALID_MN_AAA_AUTH, the MN MUST NOT send any more HKReq messages to the AR. 5.1.1.4. Returning to an Access Router When a MN attaches to an AR with which the MN believes it has a Narayanan, et al. Expires April 24, 2006 [Page 14] Internet-Draft Handover Keys Using AAA October 2005 shared Key (for example the MN has an unexpired key it obtained when it was Previously associated with the access router), the MN MAY request that the AR utilize the Key as long as the key has not expired. The MN MAY do so only after verifying that by sending a HKReq with the verify flag set. The MN MUST include a MN-AR Authentication option in HKReq with verify flag set. The MN-AR Authentication Option MUST be the last option included in the HKReq. The verify procedure serves two purposes: (1) It is used to verify that the AR still has the key and allows use of the key until the lifetime of the key and (2)It enables the MN CoA to be bound to the key. If the verify request is not successful the MN SHOULD create a new MN-AR key by sending a HKReq with the MN-AAA Auth option . 5.1.2. Access Router Considerations If the HKReq does not have the verify bit set, the AR does the following. The AR MUST first determine if it has a pending request from the MN with the same message id. If so and if the AR has already received the HKResp, the AR SHOULD retransmit the response to the MN. If the received message has the same message ID and the sequence number as before, the AR MUST drop the packet. For further protection from replays, the rate of retransmissions of responses to MN MUST not be more than a preconfigured RETRANS_RATE. If the AR already forwarded this message to the home AAA Server but has not yet received a response from AAA server, the AR MUST silently discard the retransmitted request from the MN. Note that the AAA protocol should independently perform its own retransmission. If this is a new HKReq, the AR MUST check to determine if the MN-AAA Authentication Option has been included in this message by the MN. If it has been included, then the AR MUST forward the request to the home AAA Server. If it has not been included, the AR MUST drop the message and return a HKResp to the MN with the error code set to "MN-AAA Authentication Option Required". If it is a new HKReq, the AR MUST validate the CoA in the HKReq using the procedure in section Section 5.1.2.1. The AR SHOULD send a request to the AAA server only after successful validation of the CoA. The AAA message is constructed using the appropriately defined attributes (defined in Appendix B for RADIUS and Appendix C for Diameter). While creating the AAA request message, the AR MUST include the NAS-IP-Address AVP in the AAA message (e.g. RADIUS Access Request) sent to the AAA server. The AR MUST use its IP address as seen by the MN in this AVP. This will be used as the AR ID in deriving the handover key. Narayanan, et al. Expires April 24, 2006 [Page 15] Internet-Draft Handover Keys Using AAA October 2005 The domain name in the NAI is used to determine the AAA server to be contacted. Note that if there is a local AAA server that is different from the MNs AAA server, then the AR may send the message via the AAA protocol to the Local AAA server which in turn would forward the request. The AAAL will act as a AAA proxy in this case. If the AR receives a RADIUS Access Accept message from the AAA server, it MUST store the handover key received from the AAA server along with the CoA and MN ID and index it with an SPI. The AR MUST send the SPI, AAA-MN Nonce, lifetime and the MN-AAA authentication value in the RADIUS message in the HKResp message to the MN. If the AR receives a RADIUS Access Reject message from the AAA server, the AR MUST send an appropriate error code to the MN in the HKResp message. The AR SHOULD buffer the packet for a maximum value of HKEY_REQ_TOUT, so that it can be retransmitted upon receiving a HKReq with the same Message ID and incremented sequence number. If an AR receives a RADIUS Access Accept or Reject corresponding to a MN that is no longer connected to it, the AR SHOULD silently discard it. When the neighbor cache entry for the CoA expires, the AR MUST disassociate the key and the corresponding CoA. When the lifetime of the key expires, the AR should remove the SPI. 5.1.2.1. MN Care-of-address Validation The objective of validating the CoA provided by the MN in the HKReq is to ensure that the same CoA is not being claimed by another MN. This is essential to ensure that a node cannot redirect traffic meant for another mobile node to some other location. For this purpose, the AR must perform address validation as explained here. While this procedure ensures that an authenticated node cannot send a FBU corresponding to some other mobile node's CoA, it does not eliminate the known threats generally introduced by the Neighbor Discovery Protocol [8] in the absence of SEND [9]. As a first step, the AR, upon receiving a HKReq from a mobile node, MUST verify that the CoA is not already associated with a key. It SHOULD also verify that the link layer address associated with the CoA in the neighbor cache is the same as the respective addresses in the HKReq. If these test pass, the AR MUST then send a Neighbor Solicitation message for the CoA claimed by the MN in the HKReq, including the Handover Option in the NS. If the AR receives at least one NA corresponding to the NS, it MUST reject the HKReq with the Narayanan, et al. Expires April 24, 2006 [Page 16] Internet-Draft Handover Keys Using AAA October 2005 code in HKResp set to "Care of address authorization denied". If the AR does not receive any NAs corresponding to the NS, it MUST proceed with normal processing of the HKReq. 5.1.2.2. Returning Mobile Node If a mobile node believes that it shares a handover key with a valid lifetime with the AR, it may send a HKReq with the 'V' bit set. If so, the AR MUST use the included SPI (from the MN-AR Authentication option) to lookup the MN and obtain the key. If a key is present and the computed keyed message digest matches the values included in the HKReq message, the AR MUST verify that the IP address is valid and is not claimed by any other node as described in Section 5.1.2.1. If that procedure succeeds the AR MUST send a response with the verified bit set including the hash of the response. Also, the AR MUST record the CoA of the MN as the IP address associated with the handover key for that MN, in addition to the MN ID (NAI). If the MN-AR Authentication Option is not present in the HKReq in this case, the AR MUST drop the message and return a HKResp with the error code set to "MN-AR Authentication Option Required". Also, if the MN-AR Authentication Option was included but the AR was unable to verify the keyed message digest, it MUST drop the message and return a HKResp with the error code set to "Invalid MN-AR Authenticator Value". If the AR does not have the key and if the HKReq does not have the MN-AAA Authentication Option, it MUST drop the message and return a HKResp with the error code set to "Invalid MN-AR Authenticator Value". If the AR does not have the key and the HKReq included the MN-AAA Authentication Option, the AR MAY process the HKReq as though the 'V' bit was not set. 5.1.3. AAA Server Considerations A description of the actual AAA attributes is included in Appendices B and C. This section provides a brief description of the operation of the AAA server for this protocol. Upon receiving a handover key request, the AAA server MUST verify that the MN-AAA Authentiation Option is present in the message. If it is absent, the AAA server MUST silently discard the message. Otherwise, the AAA server MUST verify the keyed message digest included in the option. If it is invalid, the AAA server MUST silently discard the message. If the hash is valid, the AAA server must proceed with the handover key generation as follows. HK = PRF(HMK, AAA-MN Nonce | AR ID | MN ID, "Handover Key"), where | indicates concatenation Narayanan, et al. Expires April 24, 2006 [Page 17] Internet-Draft Handover Keys Using AAA October 2005 The AR ID is the IP address of the AR included in the NAS-IP-Address AVP in the request. The MN ID is obtained from the HK-MN-NAI attribute included in the RADIUS Access Request. The AAA-MN Nonce is generated by the AAA Server. The Handover Master Key (HMK) is shared between the MN and the AAA server. If the NAS-IP-Address AVP was not included in the request, the AAA server MUST return an error to the AR, indicating "NAS-IP-Address Required". The AAA server MUST send a response back to the AR, including the AAA-MN Nonce as well as the derived HK in encrypted form. Note that the AAA protocol is expected to provide its own security between the AR and the AAA server for purposes of encrypting the HK. The AAA server SHOULD include a lifetime for the HK in the RADIUS Access Accept message. The AAA server is, however, not required to store the key or the lifetime. The MN-AAA Authentication Option MUST be calculated as a hash of the AAA-MN-Nonce using the HMK that the AAA Server shares with the MN and MUST be included in the RADIUS Access Accept message. 5.2. Indirect MN-AR Handover Key Exchange The MN may wish to derive a handover key with an AR when it is not directly attached to that AR. This may happen for two reasons. In one case, the MN may be using FMIPv6 service from a pAR and its handover key with the pAR may be about to expire. So, it may need to refresh the key via the nAR it is attached to. In the second case, the MN may wish to pre-authenticate with a target AR before it attaches to it. In the latter case, the MN may learn about the neighboring ARs while it is attached to AR1 by exchanging the RtSolPr and PrRtAdv messages as defined in [1] or via layer 2 mechanisms. To generate a handover key with the neighboring AR, the MN sends HKReq message to those ARs. Assuming that AR2 is a neighbor of AR1, the MN sends a HKReq to AR2 through AR1, while still attached to AR1. The HKReq is sent and processed in the same manner as in the direct case, with only one exception. The MN, in this indirect case, may not have a valid CoA on the link of the AR (say, AR2) with which it tries to establish this handover key. Note that this is true only for the pre-authentication case. If such is the case, the MN MAY send the HKReq with a NULL CoA. AR2, in this case, contacts the AAA server and establishes the handover key without performing the step of CoA validation as explained in section Section 5.1.2.1. In this case, if the MN roams to AR2, it MUST send another HKReq with the "V" bit set, including the valid CoA. AR2 MUST process this as described in section Section 5.1.2.2 and establish the binding between the CoA Narayanan, et al. Expires April 24, 2006 [Page 18] Internet-Draft Handover Keys Using AAA October 2005 and the handover key. AR2 MUST NOT allow the use of the handover key prior to the establishment of this binding between the key and the CoA of the MN. If the MN hands off prior to receiving the HKResp from AR2, it re- sends the HKReq message with the same message ID, to AR2, upon attaching to it. AR2 re-sends the HKResp sent earlier via AR1 to the MN directly in this case. This does not add to the handoff delay, since HK2 is required to authenticate the FBU sent only when the MN is performing a handoff from AR2 to a third AR. The MN sends a new HKReq to any new neighbors it receives information about, while attached to AR2. 6. Security Considerations This section describes the security considerations for the base protocol for establishing handover keys specified in this document itself. The messages described in this document are intended to allow the establishment of a security association between the mobile node and access router for fast handoff purposes. The protocol is loosely based on the Mobile IP-AAA model [11] where the MN-HA security association is derived using a AAA server. The protocol relies on existing shared security association between the mobile node and the AAA server. It also relies on the security of the AAA protocol (RADIUS or Diameter) used between the AR and the AAA server. The Security Associations resulting from use of this protocol 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. The handover key protocol described in this document transports the nonce from the AAA server to the MN and the MN derives its own handover key using the nonce and other parameters. The proposed protocol uses an NAI-like identity of the MN as the identity to derive the handover keys between the MN and AR. This protocol does not provide active or passive user identity confidentiality. If such confidentiality is desired, a service specific identity must be derived as part of the HMK bootstrapping procedure. Narayanan, et al. Expires April 24, 2006 [Page 19] Internet-Draft Handover Keys Using AAA October 2005 The proposed protocol uses a sequence number in combination with a message ID to detect retransmissions and replays. It must be noted that this provides limited replay protection. Replay protection is provided as long as there is state corresponding to an MN at the AR. An attacker may, however, cache a HKReq message sent on the link between an MN and AR and replay it at a sufficiently later time when the AR has no state for that MN. In this case, the AR will end up sending a AAA request to the AAA server. The HKReq will be successfully processed by the AAA server in this case, since the authentication data will be valid (as the attacker has not modified anything in the message). The AAA server will create a HK corresponding to this message and will provide it to the AR. However, it must be noted that the MN cannot obtain the HK, because, without the HMK, it cannot derive the key from the nonce. Hence, this scenario does not lead to an adversary using FMIP services on the AR. But, it does result in some minimal resource consumption at the AAA server (for computing the handover key). The assumption from an accounting perspective here is that accounting at the AAA server will not be triggered until the MN actually starts using the FMIP service (in other words, until the MN sends an FBU to the AR). If accounting for FMIPv6 is started based on when the handover key is derived, this issue could result in an MN getting charged for FMIP service due to an adversary. If this model is adopted for accounting, this issue must be revisited and a timestamp-based replay protection for the handover keys protocol may then be more appropriate. A timestamp- based mechanism is not considered for the moment, as the added complexity has not been viewed as necessary. For FMIPv6 operation, the access router must ensure that a mobile node cannot redirect traffic belonging to any other node. For this purpose, the access router must bind the hanodver key of a mobile node to its care-of-address. The AR must ensure that the CoA claimed by the MN is does not belong to any other node. The handover key protocol described in this draft proposes extensions to ND messages to accomplish this. It must be noted that this protocol is not attempting to solve the general threats (documented in X) of ND itself. While an unauthorized node cannot obtain FMIPv6 service or redirect traffic from another subnet, it is possible for a node to prevent legitimate nodes from obtaining FMIPv6 service by simply responding to the NS messages from the AR. To protect from all the known threats of ND, it is recommended that SEND be used in conjunction with this protocol. 7. IANA Considerations TBD: Details will be provided in a future draft version. Narayanan, et al. Expires April 24, 2006 [Page 20] Internet-Draft Handover Keys Using AAA October 2005 8. Acknowledgments The authors would like to thank James Kempf for helping with the design of the Mobility Header messages and for his help in several discussions that helped the design of the protocol itself. The authors would like to thank, in alphabetical order of last names, Mike Korus, Madjid Nakhjiri and George Popovich for their discussions, reviews and comments on the early versions of this document. 9. References 9.1. Normative References [1] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [2] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Patel, A., "Mobile Node Identifier Option for MIPv6", draft-ietf-mip6-mn-ident-option-03 (work in progress), September 2005. [6] Patel, A., "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-07 (work in progress), September 2005. [7] Venkitaraman, N., "Mobile Node-Access Router Authentication Option", draft-narayanan-mipshop-mn-ar-auth-option-00 (work in progress), October 2005. [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Narayanan, et al. Expires April 24, 2006 [Page 21] Internet-Draft Handover Keys Using AAA October 2005 9.2. Informative References [11] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005. [12] Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-11 (work in progress), August 2004. [13] Soliman, H., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. [14] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-06 (work in progress), April 2005. [15] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-aaa-key-mgmt-00 (work in progress), June 2005. Appendix A. Deriving the Handover Master Key A Handover Master Key (HMK) between the MN and AAAH server is required for this protocol to be able to derive handover keys between the MN and AR. As mentioned earlier in the document, the exact method of derivation of this HMK is outside the scope of this document. One method of HMK derivation is presented in this Appendix and it is based on the Application Master Session Key (AMSK) defined in EAP EAPKEY [14]. The basic idea is that during the authentication for network access, the MN and the AAA server derive an AMSK and subsequently an HMK from the EAP method derived keying material. The procedure requires that the authentication for network access is based on an EAP method capable of exporting session keys. Deriving the Handover Master Key (HMK) involves requires the following steps: 1. The MN and the AAA server of the home domain undertake the EAP exchange for network access authentication. 2. At the end of the EAP exchange the EAP peers derive the Master Session Key (MSK) and the Extended Master Session Key (EMSK). As such, the EAP method MUST be capable of deriving these session keys. 3. The MN and the AAA server derive an AMSK from the EMSK to be used as HMK. The key derivation function is described below. The lifetime of the HMK is managed as a system parameter and must not Narayanan, et al. Expires April 24, 2006 [Page 22] Internet-Draft Handover Keys Using AAA October 2005 be higher than the lifetime of the EMSK (as stated in EAPKEY [14]). As a default choice the two lifetimes should be equal. Figure 6 shows how the AMSK and the HMK-AMSK is derived. EAP Peer EAP Server (MN) (AAA Server) +--------------------------------+ /-------------------------\ / EAP \ MSK \ exchange / MSK \-------------------------/ +------+ +------+ | EMSK | | EMSK | +------+ +------+ +------------+ +------------+ | HMK-AMSK | | HMK-AMSK | +------------+ +------------+ Figure 6: Key Hierarchy The HMK is derived through the key derivation function specified for AMSK in EAPKEY [14] and shown below for the sake of clarity. KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) prf = HMAC-SHA1 K = EMSK L = key label D = application data Narayanan, et al. Expires April 24, 2006 [Page 23] Internet-Draft Handover Keys Using AAA October 2005 O = OutputLength (2 bytes) S = L | " " | D | O The application specific parameters are set as follows: o key label = "Handover Master Key" o application data = o output length = 128 bits A.1. Identity Derivation for the Mobile Node Based on the protocol defined in this document, the MN provides its identity in the HKReq message. As this message is not encrypted, the identity used by the MN in this exchange can be seen by other, possible malicious, nodes. This should be avoided since it exposes the identity of the MN implying identity privacy concerns. To solve this issue, several EAP methods provide user identity confidentiality. Thus, an exchange of HKReq/HKResp messages that carries the MN identity in clear, will destroy the security properties of the EAP method used for network authentication. One possible approach to solve this issue is to use in the HKReq/HKResp exchange a derived identity based on a pseudonym - during the EAP method used for network access authentication and based on the cryptographic material exported by the EAP method itself, the AAA server can send to the MN an identity that the MN can use for subsequent HKReq/HKResp exchanges. Moreover, different MN identities can be derived so that the MN can use different entities in different exchanges of the protocol, in order that malicious nodes are unable to trace its movements based on the same pseudonym. Alternatively, the capability of certain EAP to establish an encrypted channel to securely exchange parameters can be exploited to secure provisioning a temporal identity. Appendix B. RADIUS Handover Key Attributes This section provides an overview of the protocol interaction between the access router and the RADIUS server to request a key for FMIPv6. The proposal assumes that the AAA exchange is authenticated, replay protected, integrity protected and encrypted. For RADIUS, the usage of IPsec between the AR and the AAAH server is recommended. The AR acts as a AAA client in order to get a Handover Key in order to secure FMIPv6 signaling messages. A more detailed version of this section will be provided in the near Narayanan, et al. Expires April 24, 2006 [Page 24] Internet-Draft Handover Keys Using AAA October 2005 future. MN AR AAAH Server | HKReq. | | | ---------> | | | | Access Request | | | ----------------------> | | | Access Accept (key mtrl)| | | <----------------------- | | HKResp. | | | <--------- | | Figure 7: RADIUS Messages As shown in Figure 7 the MN sends a HKReq to the AR. This message contains an NAI of the Mobile node and the MN-AAA Authenticator. This authenticator is the keyed message digest computed with the HMK (see Appendix A). The access router extracts the necessary information to from the attributes to be included in a RADIUS Access Request messages. This message is sent to the AAA infrastructure. The AR includes at least the IP address used with the MN in the NAS-IP attributes. The message is the following: RADIUS-Access-Request { HK-MN-MSGID-SEQ (Message ID | Sequence number from HKReq) HK-MN-NAI NAS-IP (IP Address of the AR) HK-MN-AAA Authenticator Message Authenticator(80)} The home RADIUS server receives the message and checks the validity of the HK-MN-AAA Authenticator. This authenticator value is calculated on the HK-MN-MSGID-SEQ and HK-MN-NAI. The RADIUS server generates a Nonce of at least 128 bits (AAA-MN Nonce) and computes the Handover Key (HK1) as follows: HK1 = PRF(HMK, AAA-MN Nonce, AR1 ID, MN ID, "Handover Key") where, AR1 ID is extracted from the NAS-IP Attribute, MN ID is Narayanan, et al. Expires April 24, 2006 [Page 25] Internet-Draft Handover Keys Using AAA October 2005 extracted from the NAI, and the HMK is the shared key between MN and its RADIUS server. The RADIUS server answers to the AR by sending a RADIUS-Access- Accept message. RADIUS-Access-Accept{ HK-MN-AR-Key (HK1) HK-MN-AR-Key-Lifetime (HK1's lifetime) HK-AAA-MN-Nonce (Nonce generated by AAAH) HK-MN-AAA-SHASH (PRF(HMK, Nonce || Lifetime HK1) Message Authenticator(80)} If the authentication failed (wrong MN-AAA MAC), the AAAH generates a RADIUS Access-Reject message. The AR receives the message, extracts the HK1 and its associated lifetime and creates the HKResp containing the Nonce AAA-MN, the HK1's lifetime and the signed hash. Thus, this proposal needs the following attributes to be defined: o HK-MN-NAI o HK-MN-MSGID-SEQ o HK-MN-AAA Authenticator o HK-MN-AR-Key (HK1) o HK-MN-AR-Key-Lifetime (HK1's lifetime) o HK-AAA-MN-Nonce (Nonce generated by AAAH) o HK-MN-AR-SHASH (PRF(HMK, Nonce || Lifetime HK1) It may be possible to reuse some attributes defined for Mobile IPv4 here - such as the MIP-MN-NAI or the MIP-MN-AAA-Authenticator attribute - this possibility will be explored in later revisions of this document. Narayanan, et al. Expires April 24, 2006 [Page 26] Internet-Draft Handover Keys Using AAA October 2005 Appendix C. Diameter Handover Key Application To support this proposal a new Diameter application may need to be defined. It needs to be determined if a re-use of the Diameter NASREQ application is feasible with new attributes defined. The intent of this section is to provide an overview of what is needed to support the proposal. Note that the proposal assumes that AAA exchanges between AR and the AAAH server is protected. Use of IPsec or TLS is recommended for this purpose. In this section, we describe needed Diameter messages and AVPs. A more detailed version of this section will be provided in the near future. C.1. New Messages As for RADIUS, the AR will act as a AAA client and thus as a Diameter client. However, new Diameter command could be defined for this proposal: o HK-Mobile-Node-Request (HMR) - Command Code (TBD) and 'R' bit set in Command Flags field. This message is sent by AR acting as a Diameter client to a AAAH in order to request the handover key for the mobile node. The AR uses the information provided in the HKreq to construct the needed AVPs. o HK-Mobile-Node-Answer (HMA) - The HK-Mobile-Node-Answer (HMA) indicated by the Command-Code field set to TBD and 'R' bit cleared in Command Flags field is sent by the AAAH in response to a HMR message. C.2. AVPs For backward compatibility, attributes defined for RADIUS can be reused within this new Diameter Application. C.3. Diameter Flow of Messages The AAA exchanges between AR and its home AAA server is basically the same as for RADIUS. However, the Diameter application will benefit from all of the advantages that Diameter provides. Narayanan, et al. Expires April 24, 2006 [Page 27] Internet-Draft Handover Keys Using AAA October 2005 MN AR AAAH Server | HKReq. | | | ---------> | | | | HMR | | | ----------------------> | | | HMA | | | <----------------------- | | HKResp. | | | <--------- | | Figure 8: Diameter Handover Key Messaging Narayanan, et al. Expires April 24, 2006 [Page 28] Internet-Draft Handover Keys Using AAA October 2005 Authors' Addresses Vidya Narayanan Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: vidya@motorola.com Narayanan Venkitaraman Motorola Labs 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: narayanan.venkitaraman@motorola.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Gerardo Giaretta TILab via G. Reiss Romoli, 274 TORINO 10148 Italy Email: gerardo.giaretta@telecomitalia.it Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Narayanan, et al. Expires April 24, 2006 [Page 29] Internet-Draft Handover Keys Using AAA October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires April 24, 2006 [Page 30]