diff options
Diffstat (limited to 'doc/standards/rfc4739.txt')
| -rw-r--r-- | doc/standards/rfc4739.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/standards/rfc4739.txt b/doc/standards/rfc4739.txt new file mode 100644 index 000000000..db5cf6acf --- /dev/null +++ b/doc/standards/rfc4739.txt @@ -0,0 +1,619 @@ + + + + + + +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] + |