Network Working Group P. Eronen Internet-Draft Nokia Expires: September 7, 2006 J. Korhonen TeliaSonera March 6, 2006 Multiple Authentication Exchanges in IKEv2 draft-eronen-ipsec-ikev2-multiple-auth-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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IKEv2 supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, either using different mechanisms or the same mechanism. This extension allows, for Eronen & Korhonen Expires September 7, 2006 [Page 1] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 6 2.2. Example 1: Multiple EAP Authentications . . . . . . . . . 6 2.3. Example 2: Mixed EAP and Certificate Authentications . . . 7 2.4. Example 3: Multiple Initiator Certificates . . . . . . . . 8 2.5. Example 4: Multiple Responder Certificates . . . . . . . . 8 3. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload . . . . . . . . . . 9 3.2. ANOTHER_AUTH_FOLLOWS Notify Payload . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Eronen & Korhonen Expires September 7, 2006 [Page 2] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 1. Introduction IKEv2 [IKEv2] supports several mechanisms for parties involved in the IKE_SA. These include signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. However, there are scenarios where making the authorization decision in IKEv2 (whether to allow access or not) would benefit from using several of these methods. For instance, it may be necessary to authenticate both the host (machine) requesting access, and the user currently using the host. These two authentications would use two separate sets of credentials (such as certificates and associated private keys), or even different authentication mechanisms. To take an another example, when an operator is hosting a VPN gateway service for a third party, it may be necessary to authenticate the client both to the operator (for billing purposes) and the third party's AAA server (for authorizing access to the third party's internal network). This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, either using different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. Each authentication exchange requiring communication with backend AAA servers may be directed to different backend AAA servers, located even in different administrative domains. However, details of the communication between the IKEv2 gateway and the backend authentication servers are beyond the scope of this document. In particular, this document does not specify any changes to existing AAA protocols, and does not require the use of any particular AAA protocol. In case of several EAP authentications, it is important to notice that they are not a "sequence" (as described in Section 2.1 of [EAP]), but separate EAP conversations independent of each other. Usually, they are also terminated in different EAP servers. This is similar to the separate Network Access Provider (NAP) and Internet Service Provider (ISP) authentication exchanges in [PANA]. The discovery of the appropriate EAP server for each EAP authentication conversation is based on AAA routing. Eronen & Korhonen Expires September 7, 2006 [Page 3] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 1.1. Usage Scenarios Figure 1 shows an example architecture of an operator hosted VPN scenario that could benefit from a two phase authentication within the IKEv2 exchange. First the client authenticates towards the Network Access Provider (NAP) and gets access to the NAP-hosted VPN gateway. The first phase authentication involves the backend AAA server of the NAP. After the first authentication, the client initiates the second authentication round that also involves Third Party's backend AAA server. If both authentications succeed, the required IPsec tunnels are set up and the client can access protected networks behind the Third Party. Client *Network Access Provider* +---------+ +---------+ +-----+ | | | NAP's | | NAP | |Protected| IPsec SAs | Tunnel | AAA Protocol | AAA | |Endpoint |<------------------>|Endpoint |<------------>|Serv/| | | | | |Proxy| +---------+ +---------+ +-----+ ^ ^ IPsec or / AAA | Leased Line / Protocol | / | v | +---------+ *Third Party* v |3rd Party| +-----+ Protected | Tunnel | | 3rd | Subnet <----|Endpoint | |Party| | | | AAA | +---------+ +-----+ Figure 1: Two phase authentication used to gain access to the Third Party network via Network Access Provider. AAA traffic goes through NAP's AAA server. The NAP's AAA server can be used to proxy the AAA traffic to the Third Party's backend AAA server. Alternatively, the AAA traffic from the NAP's tunnel endpoint could go directly to the Third Party's backend AAA servers. However, this is more or less an AAA routing issue. 1.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 [KEYWORDS]. Eronen & Korhonen Expires September 7, 2006 [Page 4] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", and "Silently Discard" in this document are to be interpreted as described in [EAP]. Eronen & Korhonen Expires September 7, 2006 [Page 5] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 2. Solution 2.1. Solution Overview The peers announce support for this IKEv2 extension by including a MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response (responder) and the first IKE_AUTH request (initiator). If both peers support this extension, either of them can announce that it wishes to have a second authentication by including an ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that contains an AUTH payload. This indicates that the peer sending the ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of credentials to the other peer. The next IKE_AUTH message sent by this peer will contain a second identity payload (IDi) and starts another authentication exchange. It is assumed that both peers know what credentials they want to present; there is no negotiation about, for instance, what type of authentication is to be done. As in IKEv2, EAP-based authentication is always requested by the initiator (by omitting the AUTH payload). The AUTH payloads are calculated as specified in [IKEv2] Section 2.15 and 2.16. If EAP methods that do not generated shared keys are used, it is possible that several AUTH payloads with identical contents are sent. With this kind of EAP methods, the purpose of the AUTH payload is simply to delimit the authentication exchanges, and ensure that the IKE_SA_INIT request/response messages were not modified. 2.2. Example 1: Multiple EAP Authentications Figure 2 shows certificate-based authentication of the responder followed by an EAP authentication exchange (messages 1-10). When the first EAP exchange is ending (the initiator is sending its AUTH payload), the initiator announces that it wishes to have a second authentication exchange by including an ANOTHER_AUTH_FOLLOWS notification (message 9). After this, a second authentication exchange begins. The initiator sends a new IDi payload but no AUTH payload (message 11), indicating that EAP will be used. After that, an another EAP authentication exchange follows (messages 12-18). Eronen & Korhonen Expires September 7, 2006 [Page 6] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(MULTIPLE_AUTH_SUPPORTED) 3. HDR, SK { IDi, [CERTREQ+], [IDr], SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } --> <-- 4. HDR, SK { IDr, [CERT+], AUTH, EAP(Request) } 5. HDR, SK { EAP(Response) } --> <-- 6. HDR, SK { EAP(Request) } 7. HDR, SK { EAP(Response) } --> <-- 8. HDR, SK { EAP(Success) } 9. HDR, SK { AUTH, N(ANOTHER_AUTH_FOLLOWS) } --> <-- 10. HDR, SK { AUTH } 11. HDR, SK { IDi } --> <-- 12. HDR, SK { EAP(Request) } 13. HDR, SK { EAP(Response) } --> <-- 14. HDR, SK { EAP(Request) } 15. HDR, SK { EAP(Response) } --> <-- 16. HDR, SK { EAP(Success) } 17. HDR, SK { AUTH } --> <-- 18. HDR, SK { AUTH, SA, TSi, TSr } Figure 2: Certificate-based authentication of the responder, followed by two EAP authentication exchanges. 2.3. Example 2: Mixed EAP and Certificate Authentications Another example is shown in Figure 3: Here both the initiator and the responder are first authenticated using certificates (or shared secrets); this is followed by an EAP authentication exchange. Eronen & Korhonen Expires September 7, 2006 [Page 7] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(MULTIPLE_AUTH_SUPPORTED) 3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH, SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED), N(ANOTHER_AUTH_FOLLOWS) } --> <-- 4. HDR, SK { IDr, [CERT+], AUTH } 5. HDR, SK { IDi } --> <-- 6. HDR, SK { EAP(Request) } 7. HDR, SK { EAP(Response) } --> <-- 8. HDR, SK { EAP(Request) } 9. HDR, SK { EAP(Response) } --> <-- 10. HDR, SK { EAP(Success) } 11. HDR, SK { AUTH } --> <-- 12. HDR, SK { AUTH, SA, TSi, TSr } Figure 3: Certificate-based (or shared secret based) authentication of the initiator and the responder, followed by an EAP authentication exchange. 2.4. Example 3: Multiple Initiator Certificates Figure 4 shows yet another possibility: the initiator has two different certificates (and associated private keys), and authenticates both of them to the responder. Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(MULTIPLE_AUTH_SUPPORTED) 3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH, SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED), N(ANOTHER_AUTH_FOLLOWS) } --> <-- 4. HDR, SK { IDr, [CERT+], AUTH } 5. HDR, SK { IDi, [CERT+], AUTH } --> <-- 6. HDR, SK { SA, TSi, TSr } Figure 4: Two certificate-based authentications of the initiator, and one certificate-based authentication of the responder. 2.5. Example 4: Multiple Responder Certificates Figure 5 shows yet another possibility: the responder has two different certificates (and associated private keys), and Eronen & Korhonen Expires September 7, 2006 [Page 8] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 authenticates both of them to the initiator. Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(MULTIPLE_AUTH_SUPPORTED) 3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH, SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } --> <-- 4. HDR, SK { IDr, [CERT+], AUTH, N(ANOTHER_AUTH_FOLLOWS) } 5. HDR, SK { } --> <-- 6. HDR, SK { IDr, [CERT+], AUTH, SA, TSi, TSr } Figure 5: Two certificate-based authentications of the initiator, and one certificate-based authentication of the responder. 3. Payload Formats 3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload The MULTIPLE_AUTH_SUPPORTED notification is included in the IKE_SA_INIT response to indicate that the responder supports this specification. The Notify Message Type is TBD-BY- IANA1(16396..40959). The Protocol ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type. 3.2. ANOTHER_AUTH_FOLLOWS Notify Payload The ANOTHER_AUTH_FOLLOWS notification payload is included in an IKE_AUTH request containing an AUTH payload to indicate that the initiator wants to continue with another authentication exchange. The Notify Message Type is TBD-BY-IANA2(16396..40959). The Protocol ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type. 4. IANA Considerations This document defines two new IKEv2 notifications, MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are to be allocated from the "IKEv2 Notify Message Types" namespace defined in [IKEv2]. This document does not define any new namespaces to be managed by Eronen & Korhonen Expires September 7, 2006 [Page 9] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 IANA. 5. Security Considerations Security considerations for IKEv2 are discussed in [IKEv2]. The reader is encouraged to pay special attention to considerations relating to the use of EAP methods which do not generate shared keys. However, the use of multiple authentication exchanges result in some new security considerations as well. In normal IKEv2, the initiator authenticates the responder before revealing its identity. When multiple authentication exchanges are used to authenticate the responder, the initiator has to reveal its identity before all of the responder authentication exchanges have been completed. 6. Acknowledgments The authors would like to thank Jari Arkko, Henry Haverinen, Mika Joutsenvirta, Tero Kivinen, Yoav Nir, Mohan Parthasarathy, and Juha Savolainen for their valuable comments. 7. References 7.1. Normative References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7.2. Informative References [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [PANA] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. Eronen & Korhonen Expires September 7, 2006 [Page 10] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 2006 Authors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Jouni Korhonen TeliaSonera P.O. Box 970 FIN-00051 Sonera Finland Email: jouni.korhonen@teliasonera.com Eronen & Korhonen Expires September 7, 2006 [Page 11] Internet-Draft Multiple Auth. Exchanges in IKEv2 March 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. Eronen & Korhonen Expires September 7, 2006 [Page 12]