[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 RFC 4739

Network Working Group                                          P. Eronen
Internet-Draft                                                     Nokia
Expires: April 17, 2006                                      J. Korhonen
                                                             TeliaSonera
                                                        October 14, 2005


               Multiple Authentication Exchanges in IKEv2
             draft-eronen-ipsec-ikev2-multiple-auth-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Eronen & Korhonen        Expires April 17, 2006                 [Page 1]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Solution Overview  . . . . . . . . . . . . . . . . . . . .  6
     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  . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12






















Eronen & Korhonen        Expires April 17, 2006                 [Page 2]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


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
   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
   party's 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, 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.

   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 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 EAP conversations independent of each other.
   Usually, they are also terminated in different EAP servers.  This is
   similar to the separate Network Access Provider (NAP) and Internet
   Service Provider (ISP) authentication exchanges in [PANA].  The
   discovery of the appropriate EAP server for each EAP authentication
   conversation is based on AAA routing.





Eronen & Korhonen        Expires April 17, 2006                 [Page 3]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


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

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



Eronen & Korhonen        Expires April 17, 2006                 [Page 4]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


   The terms and abbreviations "authenticator", "backend authentication
   server", "EAP server", "peer", and "Silently Discard" in this
   document are to be interpreted as described in [EAP].
















































Eronen & Korhonen        Expires April 17, 2006                 [Page 5]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


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 request
   (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) and starts
   another authentication exchange.

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

2.2.  Example 1: Multiple EAP Authentications

   Figure 2 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, an another EAP authentication
   exchange follows (messages 12-18).
















Eronen & Korhonen        Expires April 17, 2006                 [Page 6]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


      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 }

          Figure 2: Certificate-based authentication of the
          responder, followed by two EAP authentication exchanges.

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.


















Eronen & Korhonen        Expires April 17, 2006                 [Page 7]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


      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 }

          Figure 3: Certificate-based (or shared secret based)
          authentication of the initiator and the responder,
          followed by an EAP authentication exchange.

2.4.  Example 3: Multiple Initiator Certificates

   Figure 4 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 }

          Figure 4: Two certificate-based authentications of the
          initiator, and one certificate-based authentication
          of the responder.

2.5.  Example 4: Multiple Responder Certificates

   Figure 5 shows yet another possibility: the responder has two
   different certificates (and associated private keys), and



Eronen & Korhonen        Expires April 17, 2006                 [Page 8]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


   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 }

          Figure 5: Two certificate-based authentications of the
          initiator, and one certificate-based authentication
          of the responder.


3.  Payload Formats

3.1.  MULTIPLE_AUTH_SUPPORTED Notify Payload

   The MULTIPLE_AUTH_SUPPORTED notification is included in the
   IKE_SA_INIT response to indicate that the responder supports this
   specification.  The Notify Message Type is TBD-BY-
   IANA1(16396..40959).  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 request containing an AUTH payload to indicate that the
   initiator wants to continue with another authentication exchange.
   The Notify Message Type is TBD-BY-IANA2(16396..40959).  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 to
   be allocated from the "IKEv2 Notify Message Types" namespace defined
   in [IKEv2].

   This document does not define any new namespaces to be managed by



Eronen & Korhonen        Expires April 17, 2006                 [Page 9]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


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

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

   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.


6.  Acknowledgments

   The authors would like to thank Jari Arkko, Henry Haverinen, Tero
   Kivinen, Mohan Parthasarathy, and Juha Savolainen for their valuable
   comments.


7.  References

7.1.  Normative References

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-17 (work in progress),
              September 2004.

   [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]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
           Yegin, "Protocol for Carrying Authentication for Network
           Access (PANA)", draft-ietf-pana-pana-10 (work in progress),
           July 2005.



Eronen & Korhonen        Expires April 17, 2006                [Page 10]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 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        Expires April 17, 2006                [Page 11]

Internet-Draft      Multiple Auth. Exchanges in IKEv2       October 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Eronen & Korhonen        Expires April 17, 2006                [Page 12]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/