restructured file layout
new configuration structure: peer_cfg: configuration related to a peer (authenitcation, ...= ike_cfg: config to use for IKE setup (proposals) child_Cfg: config for CHILD_SA (proposals, traffic selectors) a peer_cfg has one ike_cfg and multiple child_cfg's stroke now uses fixed count of threads
This commit is contained in:
Martin Willi
@@ -0,0 +1,5 @@
|
||||
Known bugs in charon
|
||||
======================
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
/** @mainpage
|
||||
|
||||
@section design strongSwans overall design
|
||||
|
||||
IKEv1 and IKEv2 is handled in different keying daemons. The ole IKEv1 stuff is
|
||||
completely handled in pluto, as it was all the times. IKEv2 is handled in the
|
||||
new keying daemon, which is called #charon.
|
||||
Daemon control is done over unix sockets. Pluto uses whack, as it did for years.
|
||||
Charon uses another socket interface, called stroke. Stroke uses another
|
||||
format as whack and therefore is not compatible to whack. The starter utility,
|
||||
wich does fast configuration parsing, speaks both the protocols, whack and
|
||||
stroke. It also handles daemon startup and termination.
|
||||
Pluto uses starter for some commands, for other it uses the whack utility. To be
|
||||
as close to pluto as possible, charon has the same split up of commands to
|
||||
starter and stroke. All commands are wrapped together in the ipsec script, which
|
||||
allows transparent control of both daemons.
|
||||
@verbatim
|
||||
|
||||
+-----------------------------------------+
|
||||
| ipsec |
|
||||
+-----+--------------+---------------+----+
|
||||
| | |
|
||||
| | |
|
||||
| +-----+-----+ |
|
||||
+-----+----+ | | +-----+----+
|
||||
| | | starter | | |
|
||||
| stroke | | | | whack |
|
||||
| | +---+--+----+ | |
|
||||
+------+---+ | | +--+-------+
|
||||
| | | |
|
||||
+---+------+ | | +------+--+
|
||||
| | | | | |
|
||||
| charon +----+ +----+ pluto |
|
||||
| | | |
|
||||
+-----+----+ +----+----+
|
||||
| |
|
||||
+-----+----+ |
|
||||
| LSF | |
|
||||
+-----+----+ |
|
||||
| |
|
||||
+-----+----+ +----+----+
|
||||
| RAW Sock | | UDP/500 |
|
||||
+----------+ +---------+
|
||||
|
||||
@endverbatim
|
||||
Since IKEv2 uses the same port as IKEv1, both daemons must listen to UDP port
|
||||
500. Under Linux, there is no clean way to set up two sockets at the same port.
|
||||
To reslove this problem, charon uses a RAW socket, as they are used in network
|
||||
sniffers. An installed Linux Socket Filter (LSF) filters out all none-IKEv2
|
||||
traffic. Pluto receives any IKE message, independant of charons behavior.
|
||||
Therefore plutos behavior is changed to discard any IKEv2 traffic silently.
|
||||
|
||||
To gain some reusability of the code, generic crypto and utility functions are
|
||||
separeted in a shared library, libstrongswan.
|
||||
|
||||
*/
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,729 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group P. Eronen
|
||||
Internet-Draft Nokia
|
||||
Expires: December 28, 2006 H. Tschofenig
|
||||
Siemens
|
||||
June 26, 2006
|
||||
|
||||
|
||||
Extension for EAP Authentication in IKEv2
|
||||
draft-eronen-ipsec-ikev2-eap-auth-05.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 December 28, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
IKEv2 specifies that EAP authentication must be used together with
|
||||
public key signature based responder authentication. This is
|
||||
necessary with old EAP methods that provide only unilateral
|
||||
authentication using, e.g., one-time passwords or token cards.
|
||||
|
||||
This document specifies how EAP methods that provide mutual
|
||||
authentication and key agreement can be used to provide extensible
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 1]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
responder authentication for IKEv2 based on other methods than public
|
||||
key signatures.
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Extensible Authentication Protocol (EAP), defined in [4], is an
|
||||
authentication framework which supports multiple authentication
|
||||
mechanisms. Today, EAP has been implemented at end hosts and routers
|
||||
that connect via switched circuits or dial-up lines using PPP [13],
|
||||
IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
|
||||
[11].
|
||||
|
||||
One of the advantages of the EAP architecture is its flexibility.
|
||||
EAP is used to select a specific authentication mechanism, typically
|
||||
after the authenticator requests more information in order to
|
||||
determine the specific authentication method to be used. Rather than
|
||||
requiring the authenticator (e.g., wireless LAN access point) to be
|
||||
updated to support each new authentication method, EAP permits the
|
||||
use of a backend authentication server which may implement some or
|
||||
all authentication methods.
|
||||
|
||||
IKEv2 [3] is a component of IPsec used for performing mutual
|
||||
authentication and establishing and maintaining security associations
|
||||
for IPsec ESP and AH. In addition to supporting authentication using
|
||||
public key signatures and shared secrets, IKEv2 also supports EAP
|
||||
authentication.
|
||||
|
||||
IKEv2 provides EAP authentication since it was recognized that public
|
||||
key signatures and shared secrets are not flexible enough to meet the
|
||||
requirements of many deployment scenarios. By using EAP, IKEv2 can
|
||||
leverage existing authentication infrastructure and credential
|
||||
databases, since EAP allows users to choose a method suitable for
|
||||
existing credentials, and also makes separation of the IKEv2
|
||||
responder (VPN gateway) from the EAP authentication endpoint (backend
|
||||
AAA server) easier.
|
||||
|
||||
Some older EAP methods are designed for unilateral authentication
|
||||
only (that is, EAP peer to EAP server). These methods are used in
|
||||
conjunction with IKEv2 public key based authentication of the
|
||||
responder to the initiator. It is expected that this approach is
|
||||
especially useful for "road warrior" VPN gateways that use, for
|
||||
instance, one-time passwords or token cards to authenticate the
|
||||
clients.
|
||||
|
||||
However, most newer EAP methods, such as those typically used with
|
||||
IEEE 802.11i wireless LANs, provide mutual authentication and key
|
||||
agreement. Currently, IKEv2 specifies that also these EAP methods
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 2]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
must be used together with public key signature based responder
|
||||
authentication.
|
||||
|
||||
In some environments, requiring the deployment of PKI for just this
|
||||
purpose can be counterproductive. Deploying new infrastructure can
|
||||
be expensive, and it may weaken security by creating new
|
||||
vulnerabilities. Mutually authenticating EAP methods alone can
|
||||
provide a sufficient level of security in many circumstances, and
|
||||
indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
|
||||
WLAN access points.
|
||||
|
||||
This document specifies how EAP methods that offer mutual
|
||||
authentication and key agreement can be used to provide responder
|
||||
authentication in IKEv2 completely based on EAP.
|
||||
|
||||
1.1. 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 [2].
|
||||
|
||||
|
||||
2. Scenarios
|
||||
|
||||
In this section we describe two scenarios for extensible
|
||||
authentication within IKEv2. These scenarios are intended to be
|
||||
illustrative examples rather than specifying how things should be
|
||||
done.
|
||||
|
||||
Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
|
||||
are co-located. Authenticating the IKEv2 responder using both EAP
|
||||
and public key signatures is redundant. Offering EAP based
|
||||
authentication has the advantage that multiple different
|
||||
authentication and key exchange protocols are available with EAP with
|
||||
different security properties (such as strong password based
|
||||
protocols, protocols offering user identity confidentiality and many
|
||||
more). As an example it is possible to use GSS-API support within
|
||||
EAP [6] to support Kerberos based authentication which effectively
|
||||
replaces the need for KINK [14].
|
||||
|
||||
+------+-----+ +------------+
|
||||
O | IKEv2 | | IKEv2 |
|
||||
/|\ | Initiator |<---////////////////////--->| Responder |
|
||||
/ \ +------------+ IKEv2 +------------+
|
||||
User | EAP Peer | Exchange | EAP Server |
|
||||
+------------+ +------------+
|
||||
|
||||
Figure 1: EAP and IKEv2 endpoints are co-located
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 3]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
Figure 2 shows a typical corporate network access scenario. The
|
||||
initiator (client) interacts with the responder (VPN gateway) in the
|
||||
corporate network. The EAP exchange within IKE runs between the
|
||||
client and the home AAA server. As a result of a successful EAP
|
||||
authentication protocol run, session keys are established and sent
|
||||
from the AAA server to the VPN gateway, and then used to authenticate
|
||||
the IKEv2 SA with AUTH payloads.
|
||||
|
||||
The protocol used between the VPN gateway and AAA server could be,
|
||||
for instance, Diameter [4] or RADIUS [5]. See Section 5 for related
|
||||
security considerations.
|
||||
|
||||
+-------------------------------+
|
||||
| Corporate network |
|
||||
| |
|
||||
+-----------+ +--------+ |
|
||||
| IKEv2 | AAA | Home | |
|
||||
IKEv2 +////----->+ Responder +<---------->+ AAA | |
|
||||
Exchange / | (VPN GW) | (RADIUS/ | Server | |
|
||||
/ +-----------+ Diameter) +--------+ |
|
||||
/ | carrying EAP |
|
||||
| | |
|
||||
| +-------------------------------+
|
||||
v
|
||||
+------+-----+
|
||||
o | IKEv2 |
|
||||
/|\ | Initiator |
|
||||
/ \ | VPN client |
|
||||
User +------------+
|
||||
|
||||
Figure 2: Corporate Network Access
|
||||
|
||||
|
||||
3. Solution
|
||||
|
||||
IKEv2 specifies that when the EAP method establishes a shared secret
|
||||
key, that key is used by both the initiator and responder to generate
|
||||
an AUTH payload (thus authenticating the IKEv2 SA set up by messages
|
||||
1 and 2).
|
||||
|
||||
When used together with public key responder authentication, the
|
||||
responder is in effect authenticated using two different methods: the
|
||||
public key signature AUTH payload in message 4, and the EAP-based
|
||||
AUTH payload later.
|
||||
|
||||
If the initiator does not wish to use public key based responder
|
||||
authentication, it includes an EAP_ONLY_AUTHENTICATION notification
|
||||
payload (type TBD-BY-IANA) in message 3. The SPI size field is set
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 4]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
to zero, and there is no additional data associated with this
|
||||
notification.
|
||||
|
||||
If the responder supports this notification, it omits the public key
|
||||
based AUTH payload and CERT payloads from message 4.
|
||||
|
||||
If the responder does not support the EAP_ONLY_AUTHENTICATION
|
||||
notification, it ignores the notification payload, and includes the
|
||||
AUTH payload in message 4. In this case the initiator can, based on
|
||||
its local policy, choose to either ignore the AUTH payload, or verify
|
||||
it and any associated certificates as usual.
|
||||
|
||||
Both the initiator and responder MUST verify that the EAP method
|
||||
actually used provided mutual authentication and established a shared
|
||||
secret key. The AUTH payloads sent after EAP Success MUST use the
|
||||
EAP-generated key, and MUST NOT use SK_pi or SK_pr.
|
||||
|
||||
An IKEv2 message exchange with this modification is shown below:
|
||||
|
||||
|
||||
Initiator Responder
|
||||
----------- -----------
|
||||
HDR, SAi1, KEi, Ni,
|
||||
[N(NAT_DETECTION_SOURCE_IP),
|
||||
N(NAT_DETECTION_DESTINATION_IP)] -->
|
||||
|
||||
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
|
||||
[N(NAT_DETECTION_SOURCE_IP),
|
||||
N(NAT_DETECTION_DESTINATION_IP)]
|
||||
|
||||
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
|
||||
N(EAP_ONLY_AUTHENTICATION),
|
||||
[CP(CFG_REQUEST)] } -->
|
||||
|
||||
<-- HDR, SK { IDr, EAP(Request) }
|
||||
|
||||
HDR, SK { EAP(Response) } -->
|
||||
|
||||
<-- HDR, SK { EAP(Request) }
|
||||
|
||||
HDR, SK { EAP(Response) } -->
|
||||
|
||||
<-- HDR, SK { EAP(Success) }
|
||||
|
||||
HDR, SK { AUTH } -->
|
||||
|
||||
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
|
||||
[CP(CFG_REPLY] }
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 5]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
The NAT detection and Configuration payloads are shown for
|
||||
informative purposes only; they do not change how EAP authentication
|
||||
works.
|
||||
|
||||
|
||||
4. IANA considerations
|
||||
|
||||
This document defines a new IKEv2 Notification Payload type,
|
||||
EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must
|
||||
be assigned a new type number from the "status types" range.
|
||||
|
||||
This document does not define any new namespaces to be managed by
|
||||
IANA.
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Security considerations applicable to all EAP methods are discussed
|
||||
in [1]. The EAP Key Management Framework [7] deals with issues that
|
||||
arise when EAP is used as a part of a larger system.
|
||||
|
||||
5.1. Authentication of IKEv2 SA
|
||||
|
||||
It is important to note that the IKEv2 SA is not authenticated by
|
||||
just running an EAP conversation: the crucial step is the AUTH
|
||||
payload based on the EAP-generated key. Thus, EAP methods that do
|
||||
not provide mutual authentication or establish a shared secret key
|
||||
MUST NOT be used with the modifications presented in this document.
|
||||
|
||||
5.2. Authentication with separated IKEv2 responder/EAP server
|
||||
|
||||
As described in Section 2, the EAP conversation can terminate either
|
||||
at the IKEv2 responder or at a backend AAA server.
|
||||
|
||||
If the EAP method terminates at the IKEv2 responder then no key
|
||||
transport via the AAA infrastructure is required. Pre-shared secret
|
||||
and public key based authentication offered by IKEv2 is then replaced
|
||||
by a wider range of authentication and key exchange methods.
|
||||
|
||||
However, typically EAP will be used with a backend AAA server. See
|
||||
[7] for a more complete discussion of the related security issues;
|
||||
here we provide only a short summary.
|
||||
|
||||
When a backend server is used, there are actually two authentication
|
||||
exchanges: the EAP method between the client and the AAA server, and
|
||||
another authentication between the AAA server and IKEv2 gateway. The
|
||||
AAA server authenticates the client using the selected EAP method,
|
||||
and they establish a session key. The AAA server then sends this key
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 6]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
to the IKEv2 gateway over a connection authenticated using, e.g.,
|
||||
IPsec or TLS.
|
||||
|
||||
Some EAP methods do not have any concept of pass-through
|
||||
authenticator (e.g., NAS or IKEv2 gateway) identity, and these two
|
||||
authentications remain quite independent of each other. That is,
|
||||
after the client has verified the AUTH payload sent by the IKEv2
|
||||
gateway, it knows that it is talking to SOME gateway trusted by the
|
||||
home AAA server, but not which one. The situation is somewhat
|
||||
similar if a single cryptographic hardware accelerator, containing a
|
||||
single private key, would be shared between multiple IKEv2 gateways
|
||||
(perhaps in some kind of cluster configuration). In particular, if
|
||||
one of the gateways is compromised, it can impersonate any of the
|
||||
other gateways towards the user (until the compromise is discovered
|
||||
and access rights revoked).
|
||||
|
||||
In some environments it is not desirable to trust the IKEv2 gateways
|
||||
this much (also known as the "Lying NAS Problem"). EAP methods that
|
||||
provide what is called "connection binding" or "channel binding"
|
||||
transport some identity or identities of the gateway (or WLAN access
|
||||
point/NAS) inside the EAP method. Then the AAA server can check that
|
||||
it is indeed sending the key to the gateway expected by the client.
|
||||
A potential solution is described in [16].
|
||||
|
||||
In some deployment configurations, AAA proxies may be present between
|
||||
the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
|
||||
be trusted for secure operation, and therefore SHOULD be avoided when
|
||||
possible; see [4] and [7] for more discussion.
|
||||
|
||||
5.3. Protection of EAP payloads
|
||||
|
||||
Although the EAP payloads are encrypted and integrity protected with
|
||||
SK_e/SK_a, this does not provide any protection against active
|
||||
attackers. Until the AUTH payload has been received and verified, a
|
||||
man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
|
||||
modify the EAP payloads.
|
||||
|
||||
In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
|
||||
integrity protected (by the link layer), so EAP methods are typically
|
||||
designed to take that into account.
|
||||
|
||||
In particular, EAP methods that are vulnerable to dictionary attacks
|
||||
when used in WLANs are still vulnerable (to active attackers) when
|
||||
run inside IKEv2.
|
||||
|
||||
5.4. User identity confidentiality
|
||||
|
||||
IKEv2 provides confidentiality for the initiator identity against
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 7]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
passive eavesdroppers, but not against active attackers. The
|
||||
initiator announces its identity first (in message #3), before the
|
||||
responder has been authenticated. The usage of EAP in IKEv2 does not
|
||||
change this situation, since the ID payload in message #3 is used
|
||||
instead of the EAP Identity Request/Response exchange. This is
|
||||
somewhat unfortunate since when EAP is used with public key
|
||||
authentication of the responder, it would be possible to provide
|
||||
active user identity confidentiality for the initiator.
|
||||
|
||||
IKEv2 protects the responder identity even against active attacks.
|
||||
This property cannot be provided when using EAP. If public key
|
||||
responder authentication is used in addition to EAP, the responder
|
||||
reveals its identity before authenticating the initiator. If only
|
||||
EAP is used (as proposed in this document), the situation depends on
|
||||
the EAP method used (in some EAP methods, the server reveals its
|
||||
identity first).
|
||||
|
||||
Hence, if active user identity confidentiality for the initiator is
|
||||
required then EAP methods that offer this functionality have to be
|
||||
used (see [1], Section 7.3).
|
||||
|
||||
|
||||
6. Acknowledgments
|
||||
|
||||
This document borrows some text from [1], [3], and [4]. We would
|
||||
also like to thank Hugo Krawczyk for interesting discussions about
|
||||
this topic.
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
7.1. Normative References
|
||||
|
||||
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
|
||||
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
|
||||
June 2004.
|
||||
|
||||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", RFC 2119, March 1997.
|
||||
|
||||
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
|
||||
December 2005.
|
||||
|
||||
[4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
|
||||
Authentication Protocol (EAP) Application", RFC 4072,
|
||||
August 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 8]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[5] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
|
||||
In User Service) Support For Extensible Authentication Protocol
|
||||
(EAP)", RFC 3579, September 2003.
|
||||
|
||||
[6] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
|
||||
draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
|
||||
|
||||
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
|
||||
Management Framework", draft-ietf-eap-keying-13 (work in
|
||||
progress), May 2006.
|
||||
|
||||
[8] Forsberg, D., "Protocol for Carrying Authentication for Network
|
||||
Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
|
||||
March 2006.
|
||||
|
||||
[9] Institute of Electrical and Electronics Engineers, "Local and
|
||||
Metropolitan Area Networks: Port-Based Network Access Control",
|
||||
IEEE Standard 802.1X-2001, 2001.
|
||||
|
||||
[10] Institute of Electrical and Electronics Engineers, "Information
|
||||
technology - Telecommunications and information exchange
|
||||
between systems - Local and metropolitan area networks -
|
||||
Specific Requirements Part 11: Wireless LAN Medium Access
|
||||
Control (MAC) and Physical Layer (PHY) Specifications", IEEE
|
||||
Standard 802.11-1999, 1999.
|
||||
|
||||
[11] Institute of Electrical and Electronics Engineers, "IEEE
|
||||
Standard for Information technology - Telecommunications and
|
||||
information exchange between systems - Local and metropolitan
|
||||
area networks - Specific requirements - Part 11: Wireless
|
||||
Medium Access Control (MAC) and Physical Layer (PHY)
|
||||
specifications: Amendment 6: Medium Access Control (MAC)
|
||||
Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
|
||||
|
||||
[12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
|
||||
Authentication Dial In User Service (RADIUS)", RFC 2865,
|
||||
June 2000.
|
||||
|
||||
[13] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
|
||||
RFC 1661, July 1994.
|
||||
|
||||
[14] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
|
||||
"Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
|
||||
March 2006.
|
||||
|
||||
[15] Tschofenig, H., "EAP IKEv2 Method",
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 9]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
|
||||
|
||||
[16] Arkko, J. and P. Eronen, "Authenticated Service Information for
|
||||
the Extensible Authentication Protocol (EAP)",
|
||||
draft-arkko-eap-service-identity-auth-04 (work in progress),
|
||||
October 2005.
|
||||
|
||||
|
||||
Appendix A. Alternative Approaches
|
||||
|
||||
In this section we list alternatives which have been considered
|
||||
during the work on this document. Finally, the solution presented in
|
||||
Section 3 seems to fit better into IKEv2.
|
||||
|
||||
A.1. Ignore AUTH payload at the initiator
|
||||
|
||||
With this approach, the initiator simply ignores the AUTH payload in
|
||||
message #4 (but obviously must check the second AUTH payload later!).
|
||||
The main advantage of this approach is that no protocol modifications
|
||||
are required and no signature verification is required.
|
||||
|
||||
The initiator could signal the responder (using a NOTIFY payload)
|
||||
that it did not verify the first AUTH payload.
|
||||
|
||||
A.2. Unauthenticated PKs in AUTH payload (message 4)
|
||||
|
||||
The first solution approach suggests the use of unauthenticated
|
||||
public keys in the public key signature AUTH payload (for message 4).
|
||||
|
||||
That is, the initiator verifies the signature in the AUTH payload,
|
||||
but does not verify that the public key indeed belongs to the
|
||||
intended party (using certificates)--since it doesn't have a PKI that
|
||||
would allow this. This could be used with X.509 certificates (the
|
||||
initiator ignores all other fields of the certificate except the
|
||||
public key), or "Raw RSA Key" CERT payloads.
|
||||
|
||||
This approach has the advantage that initiators that wish to perform
|
||||
certificate-based responder authentication (in addition to EAP) may
|
||||
do so, without requiring the responder to handle these cases
|
||||
separately.
|
||||
|
||||
If using RSA, the overhead of signature verification is quite small
|
||||
(compared to g^xy calculation).
|
||||
|
||||
A.3. Use EAP derived session keys for IKEv2
|
||||
|
||||
It has been proposed that when using an EAP methods that provides
|
||||
mutual authentication and key agreement, the IKEv2 Diffie-Hellman
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 10]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
exchange could also be omitted. This would mean that the sessions
|
||||
keys for IPsec SAs established later would rely only on EAP-provided
|
||||
keys.
|
||||
|
||||
It seems the only benefit of this approach is saving some computation
|
||||
time (g^xy calculation). This approach requires designing a
|
||||
completely new protocol (which would not resemble IKEv2 anymore) we
|
||||
do not believe that it should be considered. Nevertheless, we
|
||||
include it for completeness.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 11]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Pasi Eronen
|
||||
Nokia Research Center
|
||||
P.O. Box 407
|
||||
FIN-00045 Nokia Group
|
||||
Finland
|
||||
|
||||
Email: [email protected]
|
||||
|
||||
|
||||
Hannes Tschofenig
|
||||
Siemens
|
||||
Otto-Hahn-Ring 6
|
||||
Munich, Bayern 81739
|
||||
Germany
|
||||
|
||||
Email: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eronen & Tschofenig Expires December 28, 2006 [Page 12]
|
||||
|
||||
Internet-Draft Extension for EAP in IKEv2 June 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
|
||||
[email protected].
|
||||
|
||||
|
||||
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 & Tschofenig Expires December 28, 2006 [Page 13]
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,785 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Myers
|
||||
Internet-Draft TraceRoute Security LLC
|
||||
Expires: January 12, 2007 H. Tschofenig
|
||||
Siemens
|
||||
July 11, 2006
|
||||
|
||||
|
||||
OCSP Extensions to IKEv2
|
||||
draft-myers-ikev2-ocsp-03.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 12, 2007.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
While IKEv2 supports public key based authentication (PKI), the
|
||||
corresponding use of in-band CRLs is problematic due to unbounded CRL
|
||||
size. The size of an OCSP response is however well-bounded and
|
||||
small. This document defines the "OCSP Content" extension to IKEv2.
|
||||
A CERTREQ payload with "OCSP Content" identifies one or more trusted
|
||||
OCSP responders and is a request for inclusion of an OCSP response in
|
||||
the IKEv2 handshake. A cooperative recipient of such a request
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 1]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
responds with a CERT payload containing the appropriate OCSP
|
||||
response. This content is recognizable via the same "OCSP Content"
|
||||
identifier.
|
||||
|
||||
When certificates are used with IKEv2, the communicating peers need a
|
||||
mechanism to determine the revocation status of the peer's
|
||||
certificate. OCSP is one such mechanism. This document applies when
|
||||
OCSP is desired and security policy prevents one of the IKEv2 peers
|
||||
from accessing the relevant OCSP responder directly. Firewalls are
|
||||
often deployed in a manner that prevents such access by IKEv2 peers
|
||||
outside of an enterprise network.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8
|
||||
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
|
||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
|
||||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 14
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 2]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
|
||||
supports a range of authentication mechanisms, including the use of
|
||||
public key based authentication. Confirmation of certificate
|
||||
reliability is essential to achieve the security assurances public
|
||||
key cryptography provides. One fundamental element of such
|
||||
confirmation is reference to certificate revocation status (see
|
||||
[RFC3280] for additional detail).
|
||||
|
||||
The historic means of determining certificate revocation status is
|
||||
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
|
||||
CRLs to be exchanged in-band via the CERT payload.
|
||||
|
||||
CRLs can however grow unbounded in size. Many real-world examples
|
||||
exist to demonstrate the impracticality of including a multi-megabyte
|
||||
file in an IKE exchange. This constraint is particularly acute in
|
||||
bandwidth limited environments (e.g., mobile communications). The
|
||||
net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
|
||||
acquisition of these data, should they even be used at all.
|
||||
|
||||
Reliance on OOB methods can be further complicated if access to
|
||||
revocation data requires use of IPsec (and therefore IKE) to
|
||||
establish secure and authorized access to the CRLs of an IKE
|
||||
participant. Such network access deadlock further contributes to a
|
||||
reduced reliance on certificate revocation status in favor of blind
|
||||
trust.
|
||||
|
||||
OCSP [RFC2560] offers a useful alternative. The size of an OCSP
|
||||
response is bounded and small and therefore suitable for in-band
|
||||
IKEv2 signaling of a certificate's revocation status.
|
||||
|
||||
This document defines an extension to IKEv2 that enables the use of
|
||||
OCSP for in-band signaling of certificate revocation status. A new
|
||||
content encoding is defined for use in the CERTREQ and CERT payloads.
|
||||
A CERTREQ payload with "OCSP Content" identifies one or more trusted
|
||||
OCSP responders and is a request for inclusion of an OCSP response in
|
||||
the IKEv2 handshake. A cooperative recipient of such a request
|
||||
responds with a CERT payload containing the appropriate OCSP
|
||||
response. This content is recognizable via the same "OCSP Content"
|
||||
identifier.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 3]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
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 RFC 2119 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 4]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
3. Extension Definition
|
||||
|
||||
With reference to Section 3.6 of [IKEv2], the values for the Cert
|
||||
Encoding field of the CERT payload are extended as follows (see also
|
||||
the IANA Considerations section of this document):
|
||||
|
||||
Certificate Encoding Value
|
||||
-------------------- -----
|
||||
OCSP Content 14
|
||||
|
||||
3.1. OCSP Request
|
||||
|
||||
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
|
||||
Payload indicates the presence of one or more OCSP Responder
|
||||
certificate hashes in the Certificate Authority field of the CERTREQ
|
||||
payload.
|
||||
|
||||
The presence of OCSP Content (14) in a CERTREQ message:
|
||||
|
||||
1. identifies one or more OCSP responders trusted by the sender;
|
||||
|
||||
2. notifies the recipient of sender's support for the OCSP extension
|
||||
to IKEv2; and
|
||||
|
||||
3. notifies the recipient of sender's desire to receive OCSP
|
||||
confirmation in a subsequent CERT payload.
|
||||
|
||||
3.2. OCSP Response
|
||||
|
||||
A value of OCSP Content (14) in the Cert Encoding field of a CERT
|
||||
Payload indicates the presence of an OCSP Response in the Certificate
|
||||
Data field of the CERT payload.
|
||||
|
||||
Correlation between an OCSP Response CERT payload and a corresponding
|
||||
CERT payload carrying a certificate can be achieved by matching the
|
||||
OCSP response CertID field to the certificate. See [RFC2560] for the
|
||||
definition of OCSP response content.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 5]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
4. Extension Requirements
|
||||
|
||||
4.1. OCSP Request
|
||||
|
||||
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
|
||||
hashes as the Certification Authority value of a single CERTREQ
|
||||
message. There is no means however to indicate which among those
|
||||
hashes relates to the certificate of a trusted OCSP responder.
|
||||
|
||||
Therefore an OCSP Request as defined in Section 3.1 above SHALL be
|
||||
transmitted separate from any other CERTREQ payloads in an IKEv2
|
||||
exchange.
|
||||
|
||||
Where it is useful to identify more than one trusted OCSP responder,
|
||||
each such identification SHALL be concatenated in a manner identical
|
||||
to the method documented in Section 3.7 of [IKEv2] regarding the
|
||||
assembly of multiple trust anchor hashes.
|
||||
|
||||
The Certification Authority value in an OCSP Request CERTREQ SHALL be
|
||||
computed and produced in a manner identical to that of trust anchor
|
||||
hashes as documented in Section 3.7 of [IKEv2].
|
||||
|
||||
Upon receipt of an OCSP Response CERT payload corresponding to a
|
||||
prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the
|
||||
OCSP response into path validation logic defined by [RFC3280].
|
||||
|
||||
The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if
|
||||
either:
|
||||
|
||||
1. the corresponding OCSP Response CERT payload indicates that the
|
||||
subject certificate is revoked; OR
|
||||
|
||||
2. the corresponding OCSP Response CERT payload indicates an OCSP
|
||||
error (e.g., malformedRequest, internalError, tryLater,
|
||||
sigRequired, unauthorized, etc.).
|
||||
|
||||
The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange
|
||||
if a corresponding OCSP Response CERT payload is not received. This
|
||||
might be an indication that this OCSP extension is not supported.
|
||||
|
||||
4.2. OCSP Response
|
||||
|
||||
Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD
|
||||
acquire the related OCSP-based assertion and produce and transmit an
|
||||
OCSP Response CERT payload corresponding to the certificate needed to
|
||||
verify its signature on IKEv2 payloads.
|
||||
|
||||
An OCSP Response CERT payload SHALL be transmitted separate from any
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 6]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
other CERT payload in an IKEv2 exchange.
|
||||
|
||||
The means by which an OCSP response may be acquired for production of
|
||||
an OCSP Response CERT payload is out of scope of this document.
|
||||
|
||||
The structure and encoding of the Certificate Data field of an OCSP
|
||||
Response CERT payload SHALL be identical to that defined in
|
||||
[RFC2560].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 7]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
5. Examples and Discussion
|
||||
|
||||
This section shows the standard IKEv2 message examples with both
|
||||
peers, the initiator and the responder, using public key based
|
||||
authentication, CERTREQ and CERT payloads. The first instance
|
||||
corresponds to Section 1.2 of [IKEv2], the illustrations of which are
|
||||
reproduced below for reference.
|
||||
|
||||
5.1. Peer to Peer
|
||||
|
||||
Application of the IKEv2 extensions defined in this document to the
|
||||
peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
|
||||
follows. Messages are numbered for ease of reference.
|
||||
|
||||
|
||||
Initiator Responder
|
||||
----------- -----------
|
||||
(1) HDR, SAi1, KEi, Ni -->
|
||||
|
||||
(2) <-- HDR, SAr1, KEr, Nr,
|
||||
CERTREQ(OCSP Request)
|
||||
(3) HDR, SK {IDi, CERT(certificate),-->
|
||||
CERT(OCSP Response),
|
||||
CERTREQ(OCSP Request),
|
||||
[IDr,] AUTH, SAi2, TSi, TSr}
|
||||
|
||||
(4) <-- HDR, SK {IDr,
|
||||
CERT(certificate),
|
||||
CERT(OCSP Response),
|
||||
AUTH, SAr2, TSi, TSr}
|
||||
|
||||
In (2) Responder sends an OCSP Request CERTREQ payload identifying
|
||||
one or more OCSP responders trusted by Responder. In response,
|
||||
Initiator sends in (3) both a CERT payload carrying its certificate
|
||||
and an OCSP Response CERT payload covering that certificate. In (3)
|
||||
Initiator also requests an OCSP response via the OCSP Request CERTREQ
|
||||
payload. In (4) Responder returns its certificate and a separate
|
||||
OCSP Response CERT payload covering that certificate.
|
||||
|
||||
It is important to note that in this scenario, the Responder in (2)
|
||||
does not yet possess the Initiator's certificate and therefore cannot
|
||||
form an OCSP request. [RFC2560] allows for pre-produced responses.
|
||||
It is thus easily inferred that OCSP responses can be produced in the
|
||||
absence of a corresponding request (OCSP nonces notwithstanding). In
|
||||
such instances OCSP Requests are simply index values into these data.
|
||||
|
||||
It is also important in extending IKEv2 towards OCSP in this scenario
|
||||
that the Initiator has certain knowledge that the Responder is
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 8]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
capable of and willing to participate in the extension. Yet the
|
||||
Responder will only trust one or more OCSP responder signatures.
|
||||
These factors motivate the definition of OCSP Responder Hash
|
||||
extension.
|
||||
|
||||
5.2. Extended Authentication Protocol (EAP)
|
||||
|
||||
Another scenario of pressing interest is the use of EAP to
|
||||
accommodate multiple end users seeking enterprise access to an IPsec
|
||||
gateway. As with the preceding section, the following illustration
|
||||
is extracted from [IKEv2]. In the event of a conflict between this
|
||||
document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
|
||||
dominate.
|
||||
|
||||
|
||||
Initiator Responder
|
||||
----------- -----------
|
||||
(1) HDR, SAi1, KEi, Ni -->
|
||||
(2) <-- HDR, SAr1, KEr, Nr
|
||||
(3) HDR, SK {IDi, -->
|
||||
CERTREQ(OCSP Request),
|
||||
[IDr,] AUTH, SAi2, TSi, TSr}
|
||||
(4) <-- HDR, SK {IDr,
|
||||
CERT(certificate),
|
||||
CERT(OCSP Response),
|
||||
AUTH, EAP}
|
||||
(5) HDR, SK {EAP} -->
|
||||
|
||||
(6) <-- HDR, SK {EAP (success)}
|
||||
|
||||
(7) HDR, SK {AUTH} -->
|
||||
|
||||
(8) <-- HDR, SK {AUTH, SAr2, TSi,
|
||||
TSr }
|
||||
|
||||
In the EAP scenario, messages (5) through (8) are not relevant to
|
||||
this document. Note that while [IKEv2] allows for the optional
|
||||
inclusion of a CERTREQ in (2), this document asserts no need of its
|
||||
use. It is assumed that environments including this optional payload
|
||||
and yet wishing to implement the OCSP extension to IKEv2 are
|
||||
sufficiently robust as to accommodate this redundant payload.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 9]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
For the reasons noted above, OCSP request as defined in Section 3.1
|
||||
is used in place of OCSP request syntax to trigger production and
|
||||
transmission of an OCSP response. OCSP as defined in [RFC2560] may
|
||||
contain a nonce request extension to improve security against replay
|
||||
attacks (see Section 4.4.1 of [RFC2560] for further details). The
|
||||
OCSP Request defined by this document cannot accommodate nonces.
|
||||
[RFC2560] deals with this aspect by allowing pre-produced responses.
|
||||
|
||||
[RFC2560] points to this replay vulnerability and indicates: "The use
|
||||
of precomputed responses allows replay attacks in which an old (good)
|
||||
response is replayed prior to its expiration date but after the
|
||||
certificate has been revoked. Deployments of OCSP should carefully
|
||||
evaluate the benefit of precomputed responses against the probability
|
||||
of a replay attack and the costs associated with its successful
|
||||
execution." Nodes SHOULD make the required freshness of an OCSP
|
||||
Response configurable.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 10]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
This document defines one new field type for use in the IKEv2 Cert
|
||||
Encoding field of the Certificate Payload format. Official
|
||||
assignment of the "OCSP Content" extension to the Cert Encoding table
|
||||
of Section 3.6 of [IKEv2] needs to be acquired from IANA.
|
||||
|
||||
Certificate Encoding Value
|
||||
-------------------- -----
|
||||
OCSP Content 14
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 11]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The authors would like to thank Russ Housley for his support.
|
||||
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
|
||||
Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
|
||||
review.
|
||||
|
||||
9. Normative References
|
||||
|
||||
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
|
||||
RFC 4306, December 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
|
||||
Adams, "X.509 Internet Public Key Infrastructure Online
|
||||
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
|
||||
|
||||
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
|
||||
X.509 Public Key Infrastructure Certificate and
|
||||
Certificate Revocation List (CRL) Profile", RFC 3280,
|
||||
April 2002.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 12]
|
||||
|
||||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Michael Myers
|
||||
TraceRoute Security LLC
|
||||
|
||||
|
||||
Email: [email protected]
|
||||
|
||||
|
||||
Hannes Tschofenig
|
||||
Siemens
|
||||
Otto-Hahn-Ring 6
|
||||
Munich, Bavaria 81739
|
||||
Germany
|
||||
|
||||
Email: [email protected]
|
||||
URI: http://www.tschofenig.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 13]
|
||||
|
||||
Internet-Draft OCSP Extensions to 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
|
||||
[email protected].
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
Myers & Tschofenig Expires January 12, 2007 [Page 14]
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Schiller
|
||||
Request for Comments: 4307 Massachusetts Institute of Technology
|
||||
Category: Standards Track December 2005
|
||||
|
||||
|
||||
Cryptographic Algorithms for Use in the
|
||||
Internet Key Exchange Version 2 (IKEv2)
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
Abstract
|
||||
|
||||
The IPsec series of protocols makes use of various cryptographic
|
||||
algorithms in order to provide security services. The Internet Key
|
||||
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
|
||||
which algorithms should be used in any given association. However,
|
||||
to ensure interoperability between disparate implementations, it is
|
||||
necessary to specify a set of mandatory-to-implement algorithms to
|
||||
ensure that there is at least one algorithm that all implementations
|
||||
will have available. This document defines the current set of
|
||||
algorithms that are mandatory to implement as part of IKEv2, as well
|
||||
as algorithms that should be implemented because they may be promoted
|
||||
to mandatory at some future time.
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Internet Key Exchange protocol provides for the negotiation of
|
||||
cryptographic algorithms between both endpoints of a cryptographic
|
||||
|
||||
association. Different implementations of IPsec and IKE may provide
|
||||
different algorithms. However, the IETF desires that all
|
||||
implementations should have some way to interoperate. In particular,
|
||||
this requires that IKE define a set of mandatory-to-implement
|
||||
algorithms because IKE itself uses such algorithms as part of its own
|
||||
negotiations. This requires that some set of algorithms be specified
|
||||
as "mandatory-to-implement" for IKE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 1]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
The nature of cryptography is that new algorithms surface
|
||||
continuously and existing algorithms are continuously attacked. An
|
||||
algorithm believed to be strong today may be demonstrated to be weak
|
||||
tomorrow. Given this, the choice of mandatory-to-implement algorithm
|
||||
should be conservative so as to minimize the likelihood of it being
|
||||
compromised quickly. Thought should also be given to performance
|
||||
considerations as many uses of IPsec will be in environments where
|
||||
performance is a concern.
|
||||
|
||||
Finally, we need to recognize that the mandatory-to-implement
|
||||
algorithm(s) may need to change over time to adapt to the changing
|
||||
world. For this reason, the selection of mandatory-to-implement
|
||||
algorithms was removed from the main IKEv2 specification and placed
|
||||
in this document. As the choice of algorithm changes, only this
|
||||
document should need to be updated.
|
||||
|
||||
Ideally, the mandatory-to-implement algorithm of tomorrow should
|
||||
already be available in most implementations of IPsec by the time it
|
||||
is made mandatory. To facilitate this, we will attempt to identify
|
||||
those algorithms (that are known today) in this document. There is
|
||||
no guarantee that the algorithms we believe today may be mandatory in
|
||||
the future will in fact become so. All algorithms known today are
|
||||
subject to cryptographic attack and may be broken in the future.
|
||||
|
||||
2. Requirements Terminology
|
||||
|
||||
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
|
||||
"MAY" that appear in this document are to be interpreted as described
|
||||
in [RFC2119].
|
||||
|
||||
We define some additional terms here:
|
||||
|
||||
SHOULD+ This term means the same as SHOULD. However, it is likely
|
||||
that an algorithm marked as SHOULD+ will be promoted at
|
||||
some future time to be a MUST.
|
||||
|
||||
SHOULD- This term means the same as SHOULD. However, an algorithm
|
||||
marked as SHOULD- may be deprecated to a MAY in a future
|
||||
version of this document.
|
||||
|
||||
MUST- This term means the same as MUST. However, we expect at
|
||||
some point that this algorithm will no longer be a MUST in
|
||||
a future document. Although its status will be determined
|
||||
at a later time, it is reasonable to expect that if a
|
||||
future revision of a document alters the status of a MUST-
|
||||
algorithm, it will remain at least a SHOULD or a SHOULD-.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 2]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
3. Algorithm Selection
|
||||
|
||||
3.1. IKEv2 Algorithm Selection
|
||||
|
||||
3.1.1. Encrypted Payload Algorithms
|
||||
|
||||
The IKEv2 Encrypted Payload requires both a confidentiality algorithm
|
||||
and an integrity algorithm. For confidentiality, implementations
|
||||
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
|
||||
integrity, HMAC-SHA1 MUST be implemented.
|
||||
|
||||
3.1.2. Diffie-Hellman Groups
|
||||
|
||||
There are several Modular Exponential (MODP) groups that are defined
|
||||
for use in IKEv2. They are defined in both the [IKEv2] base document
|
||||
and in the MODP extensions document. They are identified by group
|
||||
number. Any groups not listed here are considered as "MAY be
|
||||
implemented".
|
||||
|
||||
Group Number Bit Length Status Defined
|
||||
2 1024 MODP Group MUST- [RFC2409]
|
||||
14 2048 MODP Group SHOULD+ [RFC3526]
|
||||
|
||||
3.1.3. IKEv2 Transform Type 1 Algorithms
|
||||
|
||||
IKEv2 defines several possible algorithms for Transfer Type 1
|
||||
(encryption). These are defined below with their implementation
|
||||
status.
|
||||
|
||||
Name Number Defined In Status
|
||||
RESERVED 0
|
||||
ENCR_3DES 3 [RFC2451] MUST-
|
||||
ENCR_NULL 11 [RFC2410] MAY
|
||||
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
|
||||
ENCR_AES_CTR 13 [AES-CTR] SHOULD
|
||||
|
||||
3.1.4. IKEv2 Transform Type 2 Algorithms
|
||||
|
||||
Transfer Type 2 Algorithms are pseudo-random functions used to
|
||||
generate random values when needed.
|
||||
|
||||
Name Number Defined In Status
|
||||
RESERVED 0
|
||||
PRF_HMAC_MD5 1 [RFC2104] MAY
|
||||
PRF_HMAC_SHA1 2 [RFC2104] MUST
|
||||
PRF_AES128_CBC 4 [AESPRF] SHOULD+
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 3]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
3.1.5. IKEv2 Transform Type 3 Algorithms
|
||||
|
||||
Transfer Type 3 Algorithms are Integrity algorithms used to protect
|
||||
data against tampering.
|
||||
|
||||
Name Number Defined In Status
|
||||
NONE 0
|
||||
AUTH_HMAC_MD5_96 1 [RFC2403] MAY
|
||||
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
|
||||
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
The security of cryptographic-based systems depends on both the
|
||||
strength of the cryptographic algorithms chosen and the strength of
|
||||
the keys used with those algorithms. The security also depends on
|
||||
the engineering of the protocol used by the system to ensure that
|
||||
there are no non-cryptographic ways to bypass the security of the
|
||||
overall system.
|
||||
|
||||
This document concerns itself with the selection of cryptographic
|
||||
algorithms for the use of IKEv2, specifically with the selection of
|
||||
"mandatory-to-implement" algorithms. The algorithms identified in
|
||||
this document as "MUST implement" or "SHOULD implement" are not known
|
||||
to be broken at the current time, and cryptographic research so far
|
||||
leads us to believe that they will likely remain secure into the
|
||||
foreseeable future. However, this isn't necessarily forever. We
|
||||
would therefore expect that new revisions of this document will be
|
||||
issued from time to time that reflect the current best practice in
|
||||
this area.
|
||||
|
||||
5. Normative References
|
||||
|
||||
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
|
||||
(IKE)", RFC 2409, November 1998.
|
||||
|
||||
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
|
||||
Protocol", RFC 4306, December 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
|
||||
(MODP) Diffie-Hellman groups for Internet Key Exchange
|
||||
(IKE)", RFC 3526, May 2003.
|
||||
|
||||
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
|
||||
Algorithms", RFC 2451, November 1998.
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 4]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
|
||||
and Its Use With IPsec", RFC 2410, November 1998.
|
||||
|
||||
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
|
||||
Cipher Algorithm and Its Use with IPsec", RFC 3602,
|
||||
September 2003.
|
||||
|
||||
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES)
|
||||
Counter Mode With IPsec Encapsulating Security Payload
|
||||
(ESP)", RFC 3686, January 2004.
|
||||
|
||||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
|
||||
Keyed-Hashing for Message Authentication", RFC 2104,
|
||||
February 1997.
|
||||
|
||||
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
|
||||
Internet Key Exchange Protocol (IKE)", RFC 3664, January
|
||||
2004.
|
||||
|
||||
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
|
||||
ESP and AH", RFC 2403, November 1998.
|
||||
|
||||
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
|
||||
within ESP and AH", RFC 2404, November 1998.
|
||||
|
||||
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
|
||||
Algorithm and Its Use With IPsec", RFC 3566, September
|
||||
2003.
|
||||
|
||||
Author's Address
|
||||
|
||||
Jeffrey I. Schiller
|
||||
Massachusetts Institute of Technology
|
||||
Room W92-190
|
||||
77 Massachusetts Avenue
|
||||
Cambridge, MA 02139-4307
|
||||
USA
|
||||
|
||||
Phone: +1 (617) 253-0161
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 5]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
Full 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.
|
||||
|
||||
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.
|
||||
|
||||
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-
|
||||
[email protected].
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 6]
|
||||
|
||||
@@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group Y. Nir
|
||||
Request for Comments: 4478 Check Point
|
||||
Category: Experimental April 2006
|
||||
|
||||
|
||||
Repeated Authentication in 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 Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document extends the Internet Key Exchange (IKEv2) Protocol
|
||||
document [IKEv2]. With some IPsec peers, particularly in the remote
|
||||
access scenario, it is desirable to repeat the mutual authentication
|
||||
periodically. The purpose of this is to limit the time that security
|
||||
associations (SAs) can be used by a third party who has gained
|
||||
control of the IPsec peer. This document describes a mechanism to
|
||||
perform this function.
|
||||
|
||||
1. Introduction
|
||||
|
||||
In several cases, such as the remote access scenario, policy dictates
|
||||
that the mutual authentication needs to be repeated periodically.
|
||||
Repeated authentication can usually be achieved by simply repeating
|
||||
the Initial exchange by whichever side has a stricter policy.
|
||||
|
||||
However, in the remote access scenario it is usually up to a human
|
||||
user to supply the authentication credentials, and often Extensible
|
||||
Authentication Protocol (EAP) is used for authentication, which makes
|
||||
it unreasonable or impossible for the remote access gateway to
|
||||
initiate the IKEv2 exchange.
|
||||
|
||||
This document describes a new notification that the original
|
||||
Responder can send to the original Initiator with the number of
|
||||
seconds before the authentication needs to be repeated. The
|
||||
Initiator SHOULD repeat the Initial exchange before that time is
|
||||
expired. If the Initiator fails to do so, the Responder may close
|
||||
all Security Associations.
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 1]
|
||||
|
||||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||||
|
||||
|
||||
Repeated authentication is not the same as IKE SA rekeying, and need
|
||||
not be tied to it. The key words "MUST", "MUST NOT", "SHOULD",
|
||||
"SHOULD NOT", and "MAY" in this document are to be interpreted as
|
||||
described in [RFC2119].
|
||||
|
||||
2. Authentication Lifetime
|
||||
|
||||
The Responder in an IKEv2 negotiation MAY be configured to limit the
|
||||
time that an IKE SA and the associated IPsec SAs may be used before
|
||||
the peer is required to repeat the authentication, through a new
|
||||
Initial Exchange.
|
||||
|
||||
The Responder MUST send this information to the Initiator in an
|
||||
AUTH_LIFETIME notification either in the last message of an IKE_AUTH
|
||||
exchange, or in an INFORMATIONAL request, which may be sent at any
|
||||
time.
|
||||
|
||||
When sent as part of the IKE SA setup, the AUTH_LIFETIME notification
|
||||
is used as follows:
|
||||
|
||||
Initiator Responder
|
||||
------------------------------- -----------------------------
|
||||
HDR, SAi1, KEi, Ni -->
|
||||
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
|
||||
HDR, SK {IDi, [CERT,] [CERTREQ,]
|
||||
[IDr,] AUTH, SAi2, TSi, TSr} -->
|
||||
<-- HDR, SK {IDr, [CERT,] AUTH,
|
||||
SAr2, TSi, TSr,
|
||||
N(AUTH_LIFETIME)}
|
||||
|
||||
The separate Informational exchange is formed as follows:
|
||||
|
||||
<-- HDR, SK {N(AUTH_LIFETIME)}
|
||||
HDR SK {} -->
|
||||
|
||||
The AUTH_LIFETIME notification is described in Section 3.
|
||||
|
||||
The original Responder that sends the AUTH_LIFETIME notification
|
||||
SHOULD send a DELETE notification soon after the end of the lifetime
|
||||
period, unless the IKE SA is deleted before the lifetime period
|
||||
elapses. If the IKE SA is rekeyed, then the time limit applies to
|
||||
the new SA.
|
||||
|
||||
An Initiator that received an AUTH_LIFETIME notification SHOULD
|
||||
repeat the Initial exchange within the time indicated in the
|
||||
notification. The time is measured from the time that the original
|
||||
Initiator receives the notification.
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 2]
|
||||
|
||||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||||
|
||||
|
||||
A special case is where the notification is sent in an Informational
|
||||
exchange, and the lifetime is zero. In that case, the original
|
||||
responder SHOULD allow a reasonable time for the repeated
|
||||
authentication to occur.
|
||||
|
||||
The AUTH_LIFETIME notification MUST be protected and MAY be sent by
|
||||
the original Responder at any time. If the policy changes, the
|
||||
original Responder MAY send it again in a new Informational.
|
||||
|
||||
The new Initial exchange is not altered. The initiator SHOULD delete
|
||||
the old IKE SA within a reasonable time of the new Auth exchange.
|
||||
|
||||
3. AUTH_LIFETIME Notification
|
||||
|
||||
The AUTH_LIFETIME message is a notification payload formatted as
|
||||
follows:
|
||||
|
||||
1 2 3
|
||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
! Next Payload !C! RESERVED ! Payload Length !
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
! Protocol ID ! SPI Size ! Notify Message Type !
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
! Lifetime !
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
o Payload Length is 12.
|
||||
o Protocol ID (1 octet) MUST be 0.
|
||||
o SPI size is 0 (SPI is in message header).
|
||||
o Notify Message type is 16403 by IANA.
|
||||
o Lifetime is the amount of time (in seconds) left before the
|
||||
peer should repeat the Initial exchange. A zero value
|
||||
signifies that the Initial exchange should begin immediately.
|
||||
It is usually not reasonable to set this value to less than 300
|
||||
(5 minutes) since that is too cumbersome for a user.
|
||||
It is also usually not reasonable to set this value to more
|
||||
than 86400 (1 day) as that would negate the security benefit of
|
||||
repeating the authentication.
|
||||
|
||||
4. Interoperability with Non-Supporting IKEv2 Implementations
|
||||
|
||||
IKEv2 implementations that do not support the AUTH_LIFETIME
|
||||
notification will ignore it and will not repeat the authentication.
|
||||
In that case the original Responder will send a Delete notification
|
||||
for the IKE SA in an Informational exchange. Such implementations
|
||||
may be configured manually to repeat the authentication periodically.
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 3]
|
||||
|
||||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||||
|
||||
|
||||
Non-supporting Responders are not a problem because they will simply
|
||||
not send these notifications. In that case, there is no requirement
|
||||
that the original Initiator re-authenticate.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The AUTH_LIFETIME notification sent by the Responder does not
|
||||
override any security policy on the Initiator. In particular, the
|
||||
Initiator may have a different policy regarding re-authentication,
|
||||
requiring more frequent re-authentication. Such an Initiator can
|
||||
repeat the authentication earlier then is required by the
|
||||
notification.
|
||||
|
||||
An Initiator MAY set reasonable limits on the amount of time in the
|
||||
AUTH_LIFETIME notification. For example, an authentication lifetime
|
||||
of less than 300 seconds from SA initiation may be considered
|
||||
unreasonable.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The IANA has assigned a notification payload type for the
|
||||
AUTH_LIFETIME notifications from the IKEv2 Notify Message Types
|
||||
registry.
|
||||
|
||||
7. Normative References
|
||||
|
||||
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
|
||||
4306, December 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
Author's Address
|
||||
|
||||
Yoav Nir
|
||||
Check Point Software Technologies
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 4]
|
||||
|
||||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||||
|
||||
|
||||
Full 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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
[email protected].
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 5]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,619 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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: [email protected]
|
||||
|
||||
|
||||
Jouni Korhonen
|
||||
TeliaSonera
|
||||
P.O. Box 970
|
||||
FIN-00051 Sonera
|
||||
Finland
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
[email protected].
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eronen & Korhonen Experimental [Page 11]
|
||||
|
||||
Reference in New Issue
Block a user