Mipshop V. Narayanan Internet-Draft Qualcomm Expires: August 28, 2006 N. Venkitaraman Motorola M. Khalil H. Akhtar Nortel February 24, 2006 Optimized Derivation of AAA-based Handover Keys draft-vidya-mipshop-hk-opt-aaa-00.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 August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract AAA-HK [1] provides a method for a MN and an AR to establish a shared key using a AAA server. To ensure that the round trip to the AAA server does not delay handoff, the handover key must be derived independent of and well ahead of the actual handoff, preferably Narayanan, et al. Expires August 28, 2006 [Page 1] Internet-Draft HK Optimized February 2006 immediately after moving to a new access router. This document describes one such method of optimizing the handover key derivation by using an AR as an authenticating server, once the MN and AR have established a security association. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Authenticating Server ID Mobility Option . . . . . . . . . 4 4.2. Handover Nonce Mobility Option . . . . . . . . . . . . . . 5 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 6 5.2. pAR Considerations . . . . . . . . . . . . . . . . . . . . 6 5.3. nAR Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Using FMIPv6 Signaling to Carry Handover Key Signaling . . . . 7 6.1. FMIPv6 Predictive Mode . . . . . . . . . . . . . . . . . . 7 6.2. FMIPv6 Reactive Mode . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Narayanan, et al. Expires August 28, 2006 [Page 2] Internet-Draft HK Optimized February 2006 1. Introduction AAA-HK [1] provides a method for a MN and an AR to establish a shared key using a AAA server. When a mobile node is handing off rapidly from one AR to another, the round trips to the AAA server can increase handoff. This document describes a method of optimizing the handover key derivation between a MN and a NAR by using a PAR as an authenticating server, once the MN and PAR have established a security association. Additionally this document also describes a method to piggyback the key derivation requests with the FMIP messages. The method provided in this document will be applicable in deployment scenarios where the nAR and pAR share a secure trust relationship, and , based on domain policies, the pAR can broker a trust relationship between a mobile node and the nAR, once the MN and pAR have a security association. A salient feature of the proposed method is that the pAR does not get to know the actual key that MN and nAR will share, but only enables them to establish trust. 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 [2]. In addition, this document uses the following terms: Handover Key (HK): Key used by a mobile node to establish its authorization to perform routing changes and possibly other handover-related operations (such as context transfer) on a particular care of address on the mobile node's old access router. 3. Overview When the mobile node first enters that domain it would utilize the AAA server to establish a shared key with its AR using the procedure in AAA-HK [1]. Once that key has been established, the pAR and MN share a key and so do pAR and nAR (the latter may be preconfigured or established by other means and is outside the scope of this document). The nAR and MN can now establish a shared key by exchanging public part of DH key value that is authenticated by the pAR. Thus in this process, the pAR the pAR does not get to know the actual key that MN and nAR will share, but only enables them to Narayanan, et al. Expires August 28, 2006 [Page 3] Internet-Draft HK Optimized February 2006 establish trust. 4. Message Formats The protocol uses the same messages as described in X. In addition, the following options are defined. 4.1. Authenticating Server ID Mobility Option This option is used to carry the IP address or name of the entity that the mobile node wishes to use as the authenticating server. For instance, the IP address of the pAR may be provided in this option contained in the HKReq message to the nAR, to indicate that the MN wishes to use th pAR as the authenticating entity. The AR may suggest an alternate authenticating server in the HKResp if the one provided by the MN was not acceptable. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + AS IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Authenticating Server ID Mobility Option Option Fields Option Type AS ID (to be assigned by IANA) Option Length 8-bit unsigned integer, representing the length in octets of the IP address. Value is 16. Narayanan, et al. Expires August 28, 2006 [Page 4] Internet-Draft HK Optimized February 2006 AS IP Address IP Address of the entity that the MN opts to use as the authenticating server. Typically, this is the IP Address of the pAR. If this option is included in the HKResp, it may contain a different AS IP address suggested by the AR. 4.2. Handover Nonce Mobility Option This option has already been defined in AAA-HK [1]. Two additional sub-types are introduced in this document. A subtype of '3' indicates a DH Public Value generated by the nAR with which the MN attempts to establish a handover key. A subtype of '4' indicates a DH Public Value generated by the MN. All other fields are as described in AAA-HK [1]. 5. Protocol Details Upon first entering a domain (administratively defined), the mobile node establishes a handover key with the AR as described in AAA-HK [1]. When the MN hands off to a nAR in the same domain, it establishes a handover key with the NAR using the following procedure. The MN sends a HKReq message to the nAR, including the pAR IP address in the Authenticating Server ID mobility option and its Diffie- Hellman public value in the Handover Nonce Mobility Option (with subtype 4). The MN includes the MN-AR authentication option described in MN-AR Auth [3] in the HKReq, creating the authentication data using the MN-pAR handover key. The nAR then sends the HKReq to the pAR for authentication. The nAR also includes its DH public value in another Handover Nonce Mobility Option (with sub-type 3). This message from the nAR to the pAR is protected by some means that is outside the scope of this document. The pAR sends a HKResp in response to the HKReq. If the MN was authenticated successfully by the pAR, the pAR includes both the DH public values (of the MN and the nAR) in the HKResp, along with the other appropriate fields as described in AAA-HK [1]. The HKResp must contain the MN-AR Authentication Option described in MN-AR Auth Option [3], with the authentication data created by the pAR using the MN-pAR handover key. This message is also protected by some means between the nAR and the pAR. As stated earlier, the method of protection between the pAR and the nAR is outside the scope of this document. The nAR, upon receiving an authenticated HKResp from the pAR, notes Narayanan, et al. Expires August 28, 2006 [Page 5] Internet-Draft HK Optimized February 2006 the DH public value of the MN from the Handover Nonce mobility option of sub-type 4 in the message. The nAR then sends the HKResp to the MN. The MN notes the DH public value of the nAR from the Handover Nonce mobility option of sub-type 3 in the message. Both the nAR and the MN now can compute, using DH, the new handover key that is to be shared between them. 5.1. Mobile Node Considerations This section describes additional mobile node considerations while using a pAR as the authenticating server for obtaining a handover key with a nAR. In general, the mobile node considerations specified in AAA-HK [1] apply in this document as well. The mobile node, while using a pAR as the authenticating server, MUST include the Authenticating Server ID Mobility Option in the HKReq. The pAR IP address MUST be provided in that option. Also, the MN MUST include the MN-AR Authentication Option, with the authentication data created using the MN-pAR key. Further, the MN MUST include its Diffie-Hellman public value in the Handover Nonce mobility option of sub-type 4. 5.2. pAR Considerations This section describes additional considerations for a pAR in this document. In general, the AAA server considerations specified in AAA-HK [1] apply to the pAR processing the HKReq in this document. The pAR, upon receiving a HKReq from an MN (either directly or through a nAR), MUST verify that the message contains its IP address in the AS ID Mobility option. Further, the pAR MUST check that the MN-AR Authentication option is present and that the authentication data in it is valid. The pAR MUST also verify that the MN has included a Handover Key Nonce option with a sub-type of 4. Further, the pAR MUST also verify that the nAR has included a Handover Key Nonce option with a sub-type of 3, proctected with an existing pAR- nAR security association. If the pAR is unable to process the HKReq - for instance, due to the pAR and nAR not sharing a security association or the pAR not having a valid handover key for the MN, the pAR MUST send a HKResp with the status code set to INVALID_AS_ID. Otherwise, if the pAR successfully authenticated the MN, the pAR sends back a HKResp, including the MN-AR authentication option. 5.3. nAR Considerations This section describes additional considerations for a nAR in this Narayanan, et al. Expires August 28, 2006 [Page 6] Internet-Draft HK Optimized February 2006 document. In general, the access router considerations specified in AAA-HK [1] apply to the nAR in this document. When a nAR receives a HKReq from an MN, it SHOULD verify that it shares a security association with the pAR whose IP address is included in the AS ID mobility option. If the nAR does not have an SA with the pAR specified, it SHOULD silently drop the HKReq. If the nAR does have an SA with the pAR, it MUST send the HKReq to the pAR, protected by the SA. It MUST include a Handover Nonce mobility option of sub-type 3, specifying its DH public value. When the nAR receives the HKResp from the pAR, it MUST note the DH public value of the MN specified in the Handover Nonce mobility option of sub-type 4, provided the HKResp shows a status code of 0. It MUST then send the HKResp to the MN. 6. Using FMIPv6 Signaling to Carry Handover Key Signaling While the messaging for establishing handover keys may happen independently, it can also be done along with the FMIP signaling without adding latency to the critical path. This section describes that process. This is only feasible when all the FMIP messages are used for FMIP signaling (i.e., FBU, HI, HAck and FBAck are all supported and used). This method of riding on top of FMIP signaling can be used only when the pAR is being used as the authenticating server and when the MN already shares a security association with the pAR. An MN initiates this process by including the HKReq mobility header in the FBU. This header must follow the binding update mobility header. If the pAR and nAR are provisioned to enable the pAR broker a trust relationship between the MN and nAR, the following procedure is performed. 6.1. FMIPv6 Predictive Mode Narayanan, et al. Expires August 28, 2006 [Page 7] Internet-Draft HK Optimized February 2006 MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | FBU | | |-------------------->| | | | | | FBU[HKReq (MN-AR auth,ID,MN PK)] | |-------------------->| | | | | | |HI(HKReq,MN PK) | | |-------------------> | | |FBack (HKResp,NAR PK)| | |<------------------- | | FBack (HKResp,MN-AR auth,ID, NAR PK) | |<------FBack---------|----FBack----------> | | | | disconnect forward | | packets===============> | | | | | | | connect | | | | | |--------- FNA ---------------------------> | |<=================================== deliver packets Figure 2: FMIPv6 Predictive Mode with Handover Key Signaling In this case, the MN sends an FBU to the pAR just before handover to nAR. As with any other FBU, the destination IP address in this message must be the pAR. The HKReq that follows the BU mobility option must include the MN-AR authentication option created using the MN-pAR key. The MN must also include the public part of the DH key in the HKReq. Once the pAR has authenticated the FBU, it must also authenticate the HKReq. If successful, the pAR must forward the HKReq to the nAR in the HI message. When the nAR receives this message it creates its own DH key and SPI. It saves the MNs DH public value and sends back a HKresp along with the HAck message and includes the SPI and nAR's public DH part in the HKResp. The nAR should not delay sending HKResp for calculating the DH key itself. That computation be done after sending the HKResp. The nAR must however verify that the address specified in the HKReq is not being used by any other mobile node (just as it would on receiving HI with a proposed CoA or FNA). The pAR must then send the FBack and HKResp to the MN . The HKResp will have the DH public part of the key from nAR. This will be Narayanan, et al. Expires August 28, 2006 [Page 8] Internet-Draft HK Optimized February 2006 authenticated by the pAR with which the MN already shares a key. (the same key is used to authenticate the FBU). On successfully authenticating the HKResp using MN-pAR key, the MN obtains the public DH key of nAR and can compute the shared key. If the MN did receive the key at the pAR it should send a FNA to nAR authenticated with the MN-nAR key. If the MN did not receive the HKResp at pAR, it must send the same HKReq (along with the FBU) in the FNA. In that case if the nAR has already received the FBAck and HKResp the nAR will verify that the FNA uses the same IP and MAC address that was in the HI message received from pAR (MAC address will be in LLA option in HI) and responds with FBAck+HKRsp that was received from pAR. Note that even though the HKResp was originally created by the nAR, it needs to have been authenticated by the pAR using the pAR-MN key. 6.2. FMIPv6 Reactive Mode MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | | | disconnect | | | | | | | | connect | | |------FNA[FBU,HReq(MN-AR Auth,ID, MN PK)]->| | |<-[FBU,HReq,NAR PK]--| | | | | |FBack(HKResp,MN-AR Auth,ID) | |-------------------->| | HKResp(MN-AR Auth,ID, NAR PK] | |<------------------------------------------| | forward | | packets================>| | | | |<==================================== deliver packets | | Figure 3: FMIPv6 Reactive Mode with Handover Key Signaling In this case, the MN sends an FBU to the pAR from the nAR. Here the FNA includes the FBU and HKReq and will be authenticated (independently) using the MN-pAR key. This will be sent from nAR to Narayanan, et al. Expires August 28, 2006 [Page 9] Internet-Draft HK Optimized February 2006 pAR along with the DH public part of nAR inside the HI message). The FNA can also be authenticated using MN-pAR key if authentication of FNA is required. In that case, the FNA will also need to be sent to nAR. On receiving FBAck+HKResp, if authentication/authorization has succeeded, the nAR notes the public part of DH key corresponding to the MN and forwards FBack+HKRsp to MN. The HKResp will have the public part of DH from nAR authenticated by pAR. So the MN can also create the shared handover key. 7. Security Considerations In general, the security considerations documented in AAA-HK [1] apply to this protocol as well. In addition, this document relies on the presence of a trust relationship between the nAR and pAR to enable a pAR broker trust between MN and nAR. A security association between pAR and nAR is also required to enable the pAR establish a shared key between the nAR and MN. However the pAR does not get access to the shared key itself. The protocol assumes that the ARs belong to a secure network and have security associations with each other. Hence, the compromise of a pAR is considered rather rare and it is assumed that the network will have mechanisms to quickly detect such a compromise. This section, however, explains the security implications in the unlikely event of a pAR being compromised. If the pAR is compromised, the following cases exist: (a) the pAR may erroneously indicate that the mobile node is not authenticated. In this case, the MN may use the AAA server to authenticate to the nAR. (b) the nAR may provide different DH parameters to the mobile and the AR, resulting in the MN and nAR not having a shared key, but instead the pAR and nAR (and the pAR and the MN) having a shared key. In this case, a pAR would be able to send an FBU to the nAR as if the mobile generated this FBU, thereby redirecting traffic destined to the MN from the nAR to itself. In cases where the HKResp is sent from the nAR directly to the MN, it is possible for the nAR to sign the HKResp with the HK it shares with the MN so that the MN can verify that it indeed shares a key with the nAR. In the case where the HKResp is carried in the FBAck via the pAR to the MN, this is not reliable enough, as the pAR may still replace the nAR's signature in the HKResp with the key it just generated with the MN. In this case, if the FNA is protected using the HK shared between the nAR and MN, the nAR would realize that it has the wrong HK upon receiving the FNA. Alternately, the HKResp can be delayed and sent directly to the MN from the nAR, after the MN attaches to the nAR. Narayanan, et al. Expires August 28, 2006 [Page 10] Internet-Draft HK Optimized February 2006 The next version of this draft will attempt to provide clarifications to protocol behavior to address some of the concerns mentioned in this section. 8. IANA Considerations TBD 9. Acknowledgments 10. Normative References [1] Narayanan, V., "Handover Keys Using AAA", draft-vidya-mipshop-handover-keys-aaa-01 (work in progress), October 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Venkitaraman, N., "Mobile Node-Access Router Authentication Option", draft-narayanan-mipshop-mn-ar-auth-option-00 (work in progress), October 2005. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [6] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Narayanan, et al. Expires August 28, 2006 [Page 11] Internet-Draft HK Optimized February 2006 Authors' Addresses Vidya Narayanan Qualcomm 5775 Morehouse Dr San Diego, CA 92121 US Email: vidyan@qualcomm.com Narayanan Venkitaraman Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: narayanan.venkitaraman@motorola.com Mohamed Khalil Nortel Networks 2221 Lakeside Blvd Richardson, TX 75082 US Email: mkhalil@nortelnetworks.com Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd Richardson, TX 75082 US Email: haseebak@nortelnetworks.com Narayanan, et al. Expires August 28, 2006 [Page 12] Internet-Draft HK Optimized February 2006 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 (2006). 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 August 28, 2006 [Page 13]