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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4739 (Experimental) | |
| 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.
Show full document text