Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol
RFC 4739
Document | Type |
RFC - Experimental
(November 2006; No errata)
Was draft-eronen-ipsec-ikev2-multiple-auth (individual in sec area)
|
|
---|---|---|---|
Authors | Jouni Korhonen , Pasi Eronen | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4739 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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 theShow full document text