Draft:  draft-eronen-ipsec-ikev2-multiple-auth-01.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: Wednesday 7/19/2006 10:39 AM CST
IETF LC Date: 24 July 2006

Summary: this draft is ready for publication as an Experimental RFC. I 
noticed a few Nits, noted below, but the draft is comprehensible and 
reasonable, so I have no non-Nit comments.

Please look at these comments along with any other Last Call comments you
may receive.

Abstract

   IKEv2 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, either using 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

Spencer/Nit - phrasing a bit rough here. Perhaps "For example, this 
extension allows certificate-based authentication of the client host 
followed by an EAP authentication of the user."

   authentication servers are used, they can belong to different
   administrative domains, such as the network access provider and the
   service provider.

1.  Introduction

   IKEv2 [IKEv2] supports several mechanisms for parties involved in the
   IKE_SA.  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)
   would benefit from 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), or even different

Spencer/Nit: s/or even/and might even use/

   authentication mechanisms.

   To take an another example, when an operator is hosting a VPN gateway
   service for a third party, it may be necessary to authenticate the
   client both to the operator (for billing purposes) and the third

Spencer/Nit: s/both to/to both/

   party's AAA server (for authorizing access to the third party's
   internal network).

1.1.  Usage Scenarios

   Figure 1 shows an example architecture of an operator hosted VPN

Spencer/Nit: s/operator hosted/operator-hosted/

   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 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.

2.1.  Solution Overview

   The AUTH payloads are calculated as specified in [IKEv2] Section 2.15
   and 2.16.  If EAP methods that do not generated shared keys are used,
   it is possible that several AUTH payloads with identical contents are
   sent.  With this kind of EAP methods, the purpose of the AUTH payload

Spencer/Nit: s/methods/method/

   is simply to delimit the authentication exchanges, and ensure that
   the IKE_SA_INIT request/response messages were not modified.

2.3.  Example 2: Mixed EAP and Certificate Authentications

   Another example is shown in Figure 3: Here both the initiator and the
   responder are first authenticated using certificates (or shared
   secrets); this is followed by an EAP authentication exchange.

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 which do not generate shared keys.

   However, the use of multiple authentication exchanges result in some
   new security considerations as well.

Spencer/Nit: s/some new security considerations/at least one new security 
consideration/?

   In normal IKEv2, the initiator authenticates the responder before
   revealing its identity.  When multiple authentication exchanges are
   used to authenticate the responder, the initiator has to reveal its
   identity before all of the responder authentication exchanges have
   been completed.