Network Working Group K. Chowdhury Internet-Draft T. Mortsolf Intended status: Standards Track Starent Networks Expires: August 29, 2007 February 25, 2007 Additional Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol draft-chowdhury-ikev2-additional-auth-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 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Chowdhury & Mortsolf Expires August 29, 2007 [Page 1] Internet-Draft February 2007 Abstract The Internet Key Exchange (IKEv2) protocol defines a way to establish IPsec security association between two end points. Normally the protocol requires a single authentication step to complete the exchange and establish IPsec security association between the end points. However, there are situations were more than one authentication exchange is required potentially with different authenticating domains. It is also possible that multiple authentication steps are performed to authenticate the endpoints for different services with different traffic selectors. This document proposes an extension to IKEv2 protocol to achieve this goal with a single IKE SA. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Illustration of the Scenario . . . . . . . . . . . . . . . . . 5 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 5. Payload Formats for Additional Auth . . . . . . . . . . . . . 9 5.1. ADDITIONAL_AUTH_SUPPORTED notify payload . . . . . . . . . 9 5.2. ADDITIONAL_AUTH notify payload . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Chowdhury & Mortsolf Expires August 29, 2007 [Page 2] Internet-Draft February 2007 1. Introduction and Scope The IKEv2 protocol [RFC4306] defines a way to establish IPsec security association between two end points. The IKEv2 protocol assumes that the IKE_AUTH phase is complete as soon as the authentication method indicates successful authentication. At the end of IKE_AUTH phase, the default CHILD SA is established with the appropriate traffic selectors. However, if there is a requirement for more than one round of authentication within the same IKE SA, it won't be possible using the base IKEv2 spec [RFC4306]. IKEv2 Multiple Authentication Exchanges [RFC4739] attempts to address this scenario by allowing the IKE_AUTH exchange to continue after the first authentication has successfully completed. This solution makes use of the notification payload called "ANOTHER_AUTH_FOLLOWS". The end points continue the IKE_AUTH exchange until the ANOTHER_AUTH_FOLLOWS notification payload is not sent after an authentication completion. This solution however falls short when the additional authentication needs to happen anytime after the first authentication has finished i.e. after the IKE_AUTH phase is over. For example, after completion of the IPsec/IKEv2 exchange, the end user may decide to launch a service that needs separate authentication and separate CHILD_SA. This additional authentication may even be done with a separate entity than the one involved with the first authentication. In this document we define a solution that will allow scenarios where additional authentication is required with IKEv2. Chowdhury & Mortsolf Expires August 29, 2007 [Page 3] Internet-Draft February 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Chowdhury & Mortsolf Expires August 29, 2007 [Page 4] Internet-Draft February 2007 3. Illustration of the Scenario There may be several reasons for additional authentication with IKEv2. In this section we describe one such scenario. +-----------+ +------------+ | VAAA | AAA | HAAA | | in NAP |--------------| Entity-1 | +-----------+\ +------------+ | \ | \ AAA | \ AAA +------------+ | \_________| HAAA | | | Entity-2 | Host | +------------+ +----------+ +----------+ | | IPsec/IKEv2 | | |Protected |-------------| Tunnel | |end point | | end point| +----------+ +----------+ Illustration of the Scenario Figure 1. Illustration of the Scenario: Multiple Authenticating Entity In the above scenario, the Host is running IKEv2 to connect to the Tunnel Endpoint in the network to gain access to IP services. The Host (user) has subscription relationship with two Entities, Entity-1 for IP Service-1 and Entity-2 for IP Service-2. Both the entities require the Host to authenticate and authorize it for IP services. The host is connecting to a Tunnel end point provided by an Network Access Provider (NAP). The NAP has a visited AAA which proxies AAA transactions between the Tunnel Endpoint (IPsec gateway) and the AAA servers in Entity-1 and Entity-2. The Tunnel endpoint in the NAP is configured to support multiple IPsec SAs (CHILD SAs) with a single IKE SA. If the Host wants to use IP Service-1, it will indicate that via the IDr field in IKEv2 and run the authentication method that the Entity-1 dictates. However, after the Host establishes the IPsec session with the Tunnel Endpoint, if it desires to use IP Service-2, Chowdhury & Mortsolf Expires August 29, 2007 [Page 5] Internet-Draft February 2007 it needs to authenticate with Entity-2. At this point, the Host cannot just establish a CHILD SA using base IKEv2 [RFC4306] since the CREATE_CHILD_SA message does not include authentication payload. The extension defined in Multiple Authentication RFC [RFC4306] is not useful either since, it does not allow the host to run secondary authentications after the IKE_AUTH phase is over. It also does not let the host and the Tunnel Endpoint to establish traffic selectors for different service (e.g. IP Service-2) that are tied to the secondary authentication only. In order for the host to get services offered by both the entities simultaneouly, the host needs to perform two sets of authentications with the entities providing services but use the same IKE SA. The proposed solution in this document allows the host to do this. Chowdhury & Mortsolf Expires August 29, 2007 [Page 6] Internet-Draft February 2007 4. Solution Overview We propose to define two new notification payloads to let the host perform secondary IKE_AUTH exchanges with the tunnel end point at any time after the initial IKE_AUTH exchange has completed. The first notification payload is to convey that the endpoints support additional authentication. The second notification payload is used by the host when it initiates the additional authentication anytime after the initial IKEv2 authentication. Here is an example call flow using EAP as the authentication method for both the initial (default) and the secondary authentications: Chowdhury & Mortsolf Expires August 29, 2007 [Page 7] Internet-Draft February 2007 Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] N(ADDITIONAL_AUTH_SUPPORTED) HDR, SK {IDi-1, [CERTREQ,] [IDr-1,] SAi2, TSi-1, TSr-1, N(ADDITIONAL_AUTH_SUPPORTED)} --> <-- HDR, SK {[CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi-1, TSr-1 } . . . some time elapses . initiate second auth HDR, SK {IDi-2, [CERTREQ,] [IDr-2,] SAi2, TSi-2, TSr-2, N(ADDITIONAL_AUTH} --> <-- HDR, SK {[CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi-2, TSr-2 } Illustration of the Scenario Chowdhury & Mortsolf Expires August 29, 2007 [Page 8] Internet-Draft February 2007 5. Payload Formats for Additional Auth 5.1. ADDITIONAL_AUTH_SUPPORTED notify payload The ADDITIONAL_AUTH_SUPPORTED notification is included in the IKE_SA_INIT response and optionally in the first IKE_AUTH request to indicate that the peer supports this specification. The Notify Message Type is ADDITIONAL_AUTH_SUPPORTED (IANA: TBD-1). The Protocol ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type. 5.2. ADDITIONAL_AUTH notify payload The ADDITIONAL_AUTH notification is included in the IKE_AUTH message to indicate that the peer (host) wants to perform secondary authentications. The Notify Message Type is ADDITIONAL_AUTH (IANA: TBD-2). Chowdhury & Mortsolf Expires August 29, 2007 [Page 9] Internet-Draft February 2007 6. IANA Considerations The following notify message numbers MUST be assigned by IANA: ADDITIONAL_AUTH_SUPPORTED: TBD-1. ADDITIONAL_AUTH: TBD-2. Chowdhury & Mortsolf Expires August 29, 2007 [Page 10] Internet-Draft February 2007 7. Security Considerations The additional authentication mechanism proposed in this document uses the same authentication procedure that is part of the baseline IKEv2 protocol. Any security considerations that apply to the IKE_AUTH mechanism, such as predictability of preshared keys, have identical security consequences when an additional authentication is performed. Chowdhury & Mortsolf Expires August 29, 2007 [Page 11] Internet-Draft February 2007 8. Acknowledgements TBD. Chowdhury & Mortsolf Expires August 29, 2007 [Page 12] Internet-Draft February 2007 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006. Chowdhury & Mortsolf Expires August 29, 2007 [Page 13] Internet-Draft February 2007 Authors' Addresses Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Phone: +1 214-550-1416 Email: kchowdhury@starentnetworks.com Tim Mortsolf Starent Networks 30 International Place Tewksbury, MA 01876 US Phone: +1 978-851-1125 Email: tmortsolf@starentnetworks.com Chowdhury & Mortsolf Expires August 29, 2007 [Page 14] Internet-Draft February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chowdhury & Mortsolf Expires August 29, 2007 [Page 15]