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 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 4739 (Experimental)
Telechat date
Responsible AD Russ Housley
Send notices to pasi.eronen@nokia.com, jouni.korhonen@teliasonera.com

Email authors IPR References Referenced by Nits Search lists

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