620 lines
22 KiB
Plaintext
620 lines
22 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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.
|
||
|
||
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 it 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
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 3]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
planned for [PANA]. The discovery of the appropriate EAP server for
|
||
each EAP authentication conversation is based on AAA routing.
|
||
|
||
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 the
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 4]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
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].
|
||
|
||
The terms and abbreviations "authenticator", "backend authentication
|
||
server", "EAP server", and "peer" 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+").
|
||
|
||
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] Sections
|
||
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 generate shared keys are used,
|
||
it is possible that several AUTH payloads with identical contents are
|
||
sent. When such EAP methods are used, 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.
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 5]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
2.2. Example 1: Multiple EAP Authentications
|
||
|
||
This example 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, another EAP authentication
|
||
exchange follows (messages 12-18).
|
||
|
||
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 }
|
||
|
||
Example 1: Certificate-based authentication of the
|
||
responder, followed by two EAP authentication exchanges.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 6]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
2.3. Example 2: Mixed EAP and Certificate Authentications
|
||
|
||
Another example is shown below: here both the initiator and the
|
||
responder are first authenticated using certificates (or shared
|
||
secrets); this is followed by an EAP authentication exchange.
|
||
|
||
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 }
|
||
|
||
Example 2: Certificate-based (or shared-secret-based)
|
||
authentication of the initiator and the responder,
|
||
followed by an EAP authentication exchange.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 7]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
2.4. Example 3: Multiple Initiator Certificates
|
||
|
||
This example 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 }
|
||
|
||
Example 3: Two certificate-based authentications of the
|
||
initiator, and one certificate-based authentication
|
||
of the responder.
|
||
|
||
2.5. Example 4: Multiple Responder Certificates
|
||
|
||
This example shows yet another possibility: the responder has two
|
||
different certificates (and associated private keys), and
|
||
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 }
|
||
|
||
Example 4: Two certificate-based authentications of the
|
||
responder, and one certificate-based authentication
|
||
of the initiator.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 8]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
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
|
||
MULTIPLE_AUTH_SUPPORTED (16404). 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 ANOTHER_AUTH_FOLLOWS (16405). 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
|
||
allocated from the "IKEv2 Notify Message Types" namespace defined in
|
||
[IKEv2].
|
||
|
||
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 that do not generate shared keys.
|
||
However, the use of multiple authentication exchanges results 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 9]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
6. Acknowledgments
|
||
|
||
The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
|
||
Dawkins, Lakshminath 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] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C.
|
||
Wang, "Protocol for Carrying Authentication for Network
|
||
Access (PANA) Requirements", RFC 4058, May 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 Experimental [Page 10]
|
||
|
||
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The IETF Trust (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.
|
||
|
||
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, THE IETF TRUST,
|
||
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.
|
||
|
||
Intellectual Property
|
||
|
||
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.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Korhonen Experimental [Page 11]
|
||
|