| |
| |
| |
| |
| |
| |
| Network Working Group P. Eronen |
| Request for Comments: 4739 Nokia |
| Category: Experimental J. Korhonen |
| TeliaSonera |
| November 2006 |
| |
| |
| Multiple Authentication Exchanges |
| in the Internet Key Exchange (IKEv2) Protocol |
| |
| Status of This Memo |
| |
| This memo defines an Experimental Protocol for the Internet |
| community. It does not specify an Internet standard of any kind. |
| Discussion and suggestions for improvement are requested. |
| Distribution of this memo is unlimited. |
| |
| Copyright Notice |
| |
| Copyright (C) The IETF Trust (2006). |
| |
| Abstract |
| |
| The Internet Key Exchange (IKEv2) protocol 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, using either 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. When backend authentication servers |
| are used, they can belong to different administrative domains, such |
| as the network access provider and the service provider. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 1] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| Table of Contents |
| |
| 1. Introduction ....................................................3 |
| 1.1. Usage Scenarios ............................................4 |
| 1.2. Terminology ................................................5 |
| 2. Solution ........................................................5 |
| 2.1. Solution Overview ..........................................5 |
| 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 .........................................9 |
| 6. Acknowledgments ................................................10 |
| 7. References .....................................................10 |
| 7.1. Normative References ......................................10 |
| 7.2. Informative References ....................................10 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 2] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 1. Introduction |
| |
| IKEv2 [IKEv2] supports several mechanisms for parties involved in the |
| IKE_SA (IKE security association). 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) |
| requires 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) and might even use |
| different authentication mechanisms. |
| |
| To take another example, when an operator is hosting a Virtual |
| Private Network (VPN) gateway service for a third party, it may be |
| necessary to authenticate the client to both the operator (for |
| billing purposes) and the third party's Authentication, |
| Authorization, and Accounting (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, using either 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 it 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 independent EAP conversations, which are usually |
| also terminated in different EAP servers. Multiple authentication |
| methods within a single EAP conversation are still prohibited as |
| described in Section 2.1 of [EAP]. Using multiple independent EAP |
| conversations is similar to the separate Network Access Provider |
| (NAP) and Internet Service Provider (ISP) authentication exchanges |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 3] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| planned for [PANA]. The discovery of the appropriate EAP server for |
| each EAP authentication conversation is based on AAA routing. |
| |
| 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 the |
| 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. |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 4] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 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]. |
| |
| The terms and abbreviations "authenticator", "backend authentication |
| server", "EAP server", and "peer" in this document are to be |
| interpreted as described in [EAP]. |
| |
| When messages containing IKEv2 payloads are described, optional |
| payloads are shown in brackets (for instance, "[FOO]"), and a plus |
| sign indicates that a payload can be repeated one or more times (for |
| instance, "FOO+"). |
| |
| 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 or IDr) and |
| starts another authentication exchange. The IKE_AUTH phase is |
| considered successful only if all the individual authentication |
| exchanges complete successfully. |
| |
| 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] Sections |
| 2.15 and 2.16, where IDi' refers to the latest IDi payload sent by |
| the initiator, and IDr' refers to the latest IDr payload sent by the |
| responder. If EAP methods that do not generate shared keys are used, |
| it is possible that several AUTH payloads with identical contents are |
| sent. When such EAP methods are used, 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. |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 5] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 2.2. Example 1: Multiple EAP Authentications |
| |
| This example 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, another EAP authentication |
| exchange follows (messages 12-18). |
| |
| 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 } |
| |
| Example 1: Certificate-based authentication of the |
| responder, followed by two EAP authentication exchanges. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 6] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 2.3. Example 2: Mixed EAP and Certificate Authentications |
| |
| Another example is shown below: here both the initiator and the |
| responder are first authenticated using certificates (or shared |
| secrets); this is followed by an EAP authentication exchange. |
| |
| 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 } |
| |
| Example 2: Certificate-based (or shared-secret-based) |
| authentication of the initiator and the responder, |
| followed by an EAP authentication exchange. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 7] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 2.4. Example 3: Multiple Initiator Certificates |
| |
| This example 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 } |
| |
| Example 3: Two certificate-based authentications of the |
| initiator, and one certificate-based authentication |
| of the responder. |
| |
| 2.5. Example 4: Multiple Responder Certificates |
| |
| This example shows yet another possibility: the responder has two |
| different certificates (and associated private keys), and |
| 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 } |
| |
| Example 4: Two certificate-based authentications of the |
| responder, and one certificate-based authentication |
| of the initiator. |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 8] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 3. Payload Formats |
| |
| 3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload |
| |
| The MULTIPLE_AUTH_SUPPORTED notification is included in the |
| IKE_SA_INIT response or the first IKE_AUTH request to indicate that |
| the peer supports this specification. The Notify Message Type is |
| MULTIPLE_AUTH_SUPPORTED (16404). 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 message containing an AUTH payload to indicate that the peer |
| wants to continue with another authentication exchange. The Notify |
| Message Type is ANOTHER_AUTH_FOLLOWS (16405). 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 |
| allocated from the "IKEv2 Notify Message Types" namespace defined in |
| [IKEv2]. |
| |
| This document does not define any new namespaces to be managed by |
| 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 that do not generate shared keys. |
| However, the use of multiple authentication exchanges results in at |
| least one new security consideration. |
| |
| In normal IKEv2, the responder authenticates the initiator before |
| revealing its identity (except when EAP is used). When multiple |
| authentication exchanges are used to authenticate the initiator, the |
| responder has to reveal its identity before all of the initiator |
| authentication exchanges have been completed. |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 9] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| 6. Acknowledgments |
| |
| The authors would like to thank Bernard Aboba, Jari Arkko, Spencer |
| Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika |
| Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus |
| Nystrom, 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] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. |
| Wang, "Protocol for Carrying Authentication for Network |
| Access (PANA) Requirements", RFC 4058, May 2005. |
| |
| 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 Experimental [Page 10] |
| |
| RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006 |
| |
| |
| Full Copyright Statement |
| |
| Copyright (C) The IETF Trust (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. |
| |
| 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. |
| |
| Acknowledgement |
| |
| Funding for the RFC Editor function is currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| |
| |
| Eronen & Korhonen Experimental [Page 11] |
| |
