Network Working Group P. Eronen
Internet-Draft Nokia
Expires: January 27, 2007 J. Korhonen
TeliaSonera
July 26, 2006
Multiple Authentication Exchanges in IKEv2
draft-eronen-ipsec-ikev2-multiple-auth-02.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 January 27, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 January 27, 2007 [Page 1]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Eronen & Korhonen Expires January 27, 2007 [Page 2]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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)
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 an another example, when an operator is hosting a 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 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 independent EAP conversations, which are usually
also terminated in different EAP servers. Multiple authentication
methods within a single EAP conversation are still prohibited as
described in Section 2.1 of [EAP]. Using multiple independent EAP
conversations 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 January 27, 2007 [Page 3]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 January 27, 2007 [Page 4]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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].
When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for
instance, "FOO+").
Eronen & Korhonen Expires January 27, 2007 [Page 5]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 response
(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 or IDr) and
starts another authentication exchange. The IKE_AUTH phase is
considered successful only if all the individual authentication
exchanges complete successfully.
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).
The AUTH payloads are calculated as specified in [IKEv2] Section 2.15
and 2.16, where IDi' refers to the latest IDi payload sent by the
initiator, and IDr' refers to the latest IDr payload sent by the
responder. 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 method, the purpose of the
AUTH payload is simply to delimit the authentication exchanges, and
ensure that the IKE_SA_INIT request/response messages were not
modified.
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 January 27, 2007 [Page 6]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 January 27, 2007 [Page 7]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 January 27, 2007 [Page 8]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 or the first IKE_AUTH request to indicate that
the peer 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 message containing an AUTH payload to indicate that the peer
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].
Eronen & Korhonen Expires January 27, 2007 [Page 9]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
This document does not define any new namespaces to be managed by
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 at
least one new security consideration.
In normal IKEv2, the responder authenticates the initiator before
revealing its identity (except when EAP is used). When multiple
authentication exchanges are used to authenticate the initiator, the
responder has to reveal its identity before all of the initiator
authentication exchanges have been completed.
6. Acknowledgments
The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
Dawkins, Laksminath Dondeti, Henry Haverinen, Russ Housley, Mika
Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus
Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable
comments.
7. References
7.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[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-11 (work in progress),
Eronen & Korhonen Expires January 27, 2007 [Page 10]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
March 2006.
Eronen & Korhonen Expires January 27, 2007 [Page 11]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 January 27, 2007 [Page 12]
Internet-Draft Multiple Auth. Exchanges in IKEv2 July 2006
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 (2006). 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 January 27, 2007 [Page 13]
