1402 lines
51 KiB
Plaintext
1402 lines
51 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group Y. Sheffer
|
|||
|
Internet-Draft Check Point
|
|||
|
Intended status: Experimental H. Tschofenig
|
|||
|
Expires: September 20, 2008 Nokia Siemens Networks
|
|||
|
L. Dondeti
|
|||
|
V. Narayanan
|
|||
|
QUALCOMM, Inc.
|
|||
|
March 19, 2008
|
|||
|
|
|||
|
|
|||
|
IPsec Gateway Failover Protocol
|
|||
|
draft-sheffer-ipsec-failover-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 September 20, 2008.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
The Internet Key Exchange version 2 (IKEv2) protocol has
|
|||
|
computational and communication overhead with respect to the number
|
|||
|
of round-trips required and cryptographic operations involved. In
|
|||
|
remote access situations, the Extensible Authentication Protocol is
|
|||
|
used for authentication, which adds several more round trips and
|
|||
|
therefore latency.
|
|||
|
|
|||
|
To re-establish security associations (SA) upon a failure recovery
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 1]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
condition is time consuming, especially when an IPsec peer, such as a
|
|||
|
VPN gateway, needs to re-establish a large number of SAs with various
|
|||
|
end points. A high number of concurrent sessions might cause
|
|||
|
additional problems for an IPsec peer during SA re-establishment.
|
|||
|
|
|||
|
In many failure cases it would be useful to provide an efficient way
|
|||
|
to resume an interrupted IKE/IPsec session. This document proposes
|
|||
|
an extension to IKEv2 that allows a client to re-establish an IKE SA
|
|||
|
with a gateway in a highly efficient manner, utilizing a previously
|
|||
|
established IKE SA.
|
|||
|
|
|||
|
A client can reconnect to a gateway from which it was disconnected,
|
|||
|
or alternatively migrate to another gateway that is associated with
|
|||
|
the previous one. The proposed approach conveys IKEv2 state
|
|||
|
information, in the form of an encrypted ticket, to a VPN client that
|
|||
|
is later presented to the VPN gateway for re-authentication. The
|
|||
|
encrypted ticket can only be decrypted by the VPN gateway in order to
|
|||
|
restore state for faster session setup.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 2]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
|||
|
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
|||
|
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
3.1. Recovering from a Remote Access Gateway Failover . . . . . 6
|
|||
|
3.2. Recovering from an Application Server Failover . . . . . . 8
|
|||
|
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9
|
|||
|
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9
|
|||
|
4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
|
|||
|
4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12
|
|||
|
4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 12
|
|||
|
4.2.3. Requesting a ticket during resumption . . . . . . . . 13
|
|||
|
4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13
|
|||
|
4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
|
|||
|
4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
|
|||
|
4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15
|
|||
|
5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
|
|||
|
5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16
|
|||
|
5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17
|
|||
|
5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
|
|||
|
5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
|
|||
|
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
|
|||
|
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
|
|||
|
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
|
|||
|
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
|
|||
|
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19
|
|||
|
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19
|
|||
|
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
|
|||
|
7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20
|
|||
|
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
|
|||
|
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
|
|||
|
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
|
|||
|
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
|
|||
|
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
|
|||
|
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
|
|||
|
Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22
|
|||
|
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
|
|||
|
B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
|
|||
|
B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
|
|||
|
B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
|
|||
|
B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
|
|||
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
|
|||
|
Intellectual Property and Copyright Statements . . . . . . . . . . 25
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 3]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The Internet Key Exchange version 2 (IKEv2) protocol has
|
|||
|
computational and communication overhead with respect to the number
|
|||
|
of round-trips required and cryptographic operations involved. In
|
|||
|
particular the Extensible Authentication Protocol is used for
|
|||
|
authentication in remote access cases, which increases latency.
|
|||
|
|
|||
|
To re-establish security associations (SA) upon a failure recovery
|
|||
|
condition is time-consuming, especially when an IPsec peer, such as a
|
|||
|
VPN gateway, needs to re-establish a large number of SAs with various
|
|||
|
end points. A high number of concurrent sessions might cause
|
|||
|
additional problems for an IPsec peer.
|
|||
|
|
|||
|
In many failure cases it would be useful to provide an efficient way
|
|||
|
to resume an interrupted IKE/IPsec session. This document proposes
|
|||
|
an extension to IKEv2 that allows a client to re-establish an IKE SA
|
|||
|
with a gateway in a highly efficient manner, utilizing a previously
|
|||
|
established IKE SA.
|
|||
|
|
|||
|
A client can reconnect to a gateway from which it was disconnected,
|
|||
|
or alternatively migrate to another gateway that is associated with
|
|||
|
the previous one. This document proposes to maintain IKEv2 state in
|
|||
|
a "ticket", an opaque data structure created and used by a server and
|
|||
|
stored by a client, which the client cannot understand or tamper
|
|||
|
with. The IKEv2 protocol is extended to allow a client to request
|
|||
|
and present a ticket. When two gateways mutually trust each other,
|
|||
|
one can accept a ticket generated by the other.
|
|||
|
|
|||
|
This approach is similar to the one taken by TLS session resumption
|
|||
|
[RFC4507] with the required adaptations for IKEv2, e.g., to
|
|||
|
accommodate the two-phase protocol structure. We have borrowed
|
|||
|
heavily from that specification.
|
|||
|
|
|||
|
1.1. Goals
|
|||
|
|
|||
|
The high-level goal of this extension is to provide an IPsec failover
|
|||
|
solution, according to the requirements defined in
|
|||
|
[I-D.vidya-ipsec-failover-ps].
|
|||
|
|
|||
|
Specifically, the proposed extension should allow IPsec sessions to
|
|||
|
be recovered from failures in remote access scenarios, in a more
|
|||
|
efficient manner than the basic IKE solution. This efficiency is
|
|||
|
primarily on the gateway side, since the gateway might have to deal
|
|||
|
with many thousands of concurrent requests. We should enable the
|
|||
|
following cases:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 4]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
o Failover from one gateway to another, where the two gateways do
|
|||
|
not share state but do have mutual trust. For example, the
|
|||
|
gateways may be operated by the same provider and share the same
|
|||
|
keying materials to access an encrypted ticket.
|
|||
|
o Recovery from an intermittent connectivity, where clients
|
|||
|
reconnect into the same gateway. In this case, the gateway would
|
|||
|
typically have detected the clients' absence and removed the state
|
|||
|
associated with them.
|
|||
|
o Recovery from a gateway restart, where clients reconnect into the
|
|||
|
same gateway.
|
|||
|
|
|||
|
The proposed solution should additionally meet the following goals:
|
|||
|
|
|||
|
o Using only symmetric cryptography to minimize CPU consumption.
|
|||
|
o Allowing a gateway to push state to clients.
|
|||
|
o Providing cryptographic agility.
|
|||
|
o Having no negative impact on IKEv2 security features.
|
|||
|
|
|||
|
1.2. Non-Goals
|
|||
|
|
|||
|
The following are non-goals of this solution:
|
|||
|
o Providing load balancing among gateways.
|
|||
|
o Specifying how a client detects the need for a failover.
|
|||
|
|
|||
|
|
|||
|
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 [RFC2119].
|
|||
|
|
|||
|
This document uses terminology defined in [RFC4301], [RFC4306], and
|
|||
|
[RFC4555]. In addition, this document uses the following terms:
|
|||
|
|
|||
|
Secure domain: A secure domain comprises a set of gateways that are
|
|||
|
able to resume an IKEv2 session that may have been established by
|
|||
|
any other gateway within the domain. All gateways in the secure
|
|||
|
domain are expected to share some secrets, so that they can
|
|||
|
generate an IKEv2 ticket, verify the validity of the ticket and
|
|||
|
extract the IKEv2 policy and session key material from the ticket.
|
|||
|
IKEv2 ticket: An IKEv2 ticket is a data structure that contains all
|
|||
|
the necessary information that allows any gateway within the same
|
|||
|
secure domain as the gateway that created the ticket to verify the
|
|||
|
validity of the ticket and extract IKEv2 policy and session keys
|
|||
|
to re-establish an IKEv2 session.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 5]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
Stateless failover: When the IKEv2 session state is stored at the
|
|||
|
client, the IKEv2 responder is "stateless" until the client
|
|||
|
restores the SA with one of the gateways within the secure domain;
|
|||
|
thus, we refer to SA resumption with SA storage at the client as
|
|||
|
stateless session resumption.
|
|||
|
Stateful failover: When the infrastructure maintains IKEv2 session
|
|||
|
state, we refer to the process of IKEv2 SA re-establishment as
|
|||
|
stateful session resumption.
|
|||
|
|
|||
|
|
|||
|
3. Usage Scenarios
|
|||
|
|
|||
|
This specification envisions two usage scenarios for efficient IKEv2
|
|||
|
and IPsec SA session re-establishment.
|
|||
|
|
|||
|
The first is similar to the use case specified in Section 1.1.3 of
|
|||
|
the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
|
|||
|
used to establish a secure channel between a remote access client and
|
|||
|
a gateway; the traffic flow may be between the client and entities
|
|||
|
beyond the gateway.
|
|||
|
|
|||
|
The second use case focuses on the usage of transport (or tunnel)
|
|||
|
mode to secure the communicate between two end points (e.g., two
|
|||
|
servers). The two endpoints have a client-server relationship with
|
|||
|
respect to a protocol that runs using the protections afforded by the
|
|||
|
IPsec SA.
|
|||
|
|
|||
|
3.1. Recovering from a Remote Access Gateway Failover
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 6]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
(a)
|
|||
|
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
! ! IKEv2/IKEv2-EAP ! ! Protected
|
|||
|
! Remote !<------------------------>! Remote ! Subnet
|
|||
|
! Access ! ! Access !<--- and/or
|
|||
|
! Client !<------------------------>! Gateway ! Internet
|
|||
|
! ! IPsec tunnel ! !
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
(b)
|
|||
|
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
! ! IKE_SESSION_RESUME ! !
|
|||
|
! Remote !<------------------------>! New/Old !
|
|||
|
! Access ! ! Gateway !
|
|||
|
! Client !<------------------------>! !
|
|||
|
! ! IPsec tunnel ! !
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Figure 1: Remote Access Gateway Failure
|
|||
|
|
|||
|
In this scenario, an end-host (an entity with a host implementation
|
|||
|
of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
|
|||
|
gateway in a remote network using IKEv2. The end-host in this
|
|||
|
scenario is sometimes referred to as a remote access client. When
|
|||
|
the remote gateway fails, all the clients associated with the gateway
|
|||
|
either need to re-establish IKEv2 sessions with another gateway
|
|||
|
within the same secure domain of the original gateway, or with the
|
|||
|
original gateway if the server is back online soon.
|
|||
|
|
|||
|
The clients may choose to establish IPsec SAs using a full IKEv2
|
|||
|
exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).
|
|||
|
|
|||
|
In this scenario, the client needs to get an IP address from the
|
|||
|
remote network so that traffic can be encapsulated by the remote
|
|||
|
access gateway before reaching the client. In the initial exchange,
|
|||
|
the gateway may acquire IP addresses from the address pool of a local
|
|||
|
DHCP server. The new gateway that a client gets associated may not
|
|||
|
receive addresses from the same address pool. Thus, the session
|
|||
|
resumption protocol needs to support the assignment of a new IP
|
|||
|
address.
|
|||
|
|
|||
|
The protocol defined in this document supports the re-allocation of
|
|||
|
an IP address to the client, if this capability is provided by the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 7]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
network. For example, if routing tables are modified so that traffic
|
|||
|
is rerouted through the new gateway. This capability is implicit in
|
|||
|
the use of the IKE Config mechanism, which allows the client to
|
|||
|
present its existing IP address and receive the same address back, if
|
|||
|
allowed by the gateway.
|
|||
|
|
|||
|
The protocol defined here supports both stateful and stateless
|
|||
|
scenarios. In other words, tickets can be stored wholly on the
|
|||
|
client, or the ticket can be stored on the gateway (or in a database
|
|||
|
shared between multiple gateways), with the client only presenting a
|
|||
|
handle that identifies a particular ticket. In fact these scenarios
|
|||
|
are transparent to the protocols, with the only change being the non-
|
|||
|
mandatory ticket format.
|
|||
|
|
|||
|
3.2. Recovering from an Application Server Failover
|
|||
|
|
|||
|
|
|||
|
(a)
|
|||
|
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
! App. ! IKEv2/IKEv2-EAP ! App. !
|
|||
|
! Client !<------------------------>! Server !
|
|||
|
! & ! ! & !
|
|||
|
! IPsec !<------------------------>! IPsec !
|
|||
|
! host ! IPsec transport/ ! host !
|
|||
|
+-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
(b)
|
|||
|
|
|||
|
+-+-+-+-+-+ +-+-+-+-+-+
|
|||
|
! App. ! IKE_SESSION_RESUME ! New !
|
|||
|
! Client !<------------------------>! Server !
|
|||
|
! & ! ! & !
|
|||
|
! IPsec !<------------------------>! IPsec !
|
|||
|
! host ! IPsec transport/ ! host !
|
|||
|
+-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
Figure 2: Application Server Failover
|
|||
|
|
|||
|
The second usage scenario is as follows: two entities with IPsec host
|
|||
|
implementations establish an IPsec transport or tunnel mode SA
|
|||
|
between themselves; this is similar to the model described in Section
|
|||
|
1.1.2. of [RFC4306]. At the application level, one of the entities
|
|||
|
is always the client and the other is a server. From that view
|
|||
|
point, the IKEv2 exchange is always initiated by the client. This
|
|||
|
allows the Initiator (the client) to authenticate itself using EAP,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 8]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
as long as the Responder (or the application server) allows it.
|
|||
|
|
|||
|
If the application server fails, the client may find other servers
|
|||
|
within the same secure domain for service continuity. It may use a
|
|||
|
full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re-
|
|||
|
establish the IPsec SAs for secure communication required by the
|
|||
|
application layer signaling.
|
|||
|
|
|||
|
The client-server relationship at the application layer ensures that
|
|||
|
one of the entities in this usage scenario is unambiguously always
|
|||
|
the Initiator and the other the Responder. This role determination
|
|||
|
also allows the Initiator to request an address in the Responder's
|
|||
|
network using the Configuration Payload mechanism of the IKEv2
|
|||
|
protocol. If the client has thus received an address during the
|
|||
|
initial IKEv2 exchange, when it associates with a new server upon
|
|||
|
failure of the original server, it needs to request an address,
|
|||
|
specifying its assigned address. The server may allow the client to
|
|||
|
use the original address or if it is not permitted to use that
|
|||
|
address, assign a new address.
|
|||
|
|
|||
|
|
|||
|
4. Protocol Details
|
|||
|
|
|||
|
This section provides protocol details and contains the normative
|
|||
|
parts. This document defines two protocol exchanges, namely
|
|||
|
requesting a ticket and presenting a ticket. Section 4.1 describes
|
|||
|
the procedure to request a ticket and Section 4.2 illustrates how to
|
|||
|
present a ticket.
|
|||
|
|
|||
|
4.1. Requesting a Ticket
|
|||
|
|
|||
|
A client MAY request a ticket in the following exchanges:
|
|||
|
|
|||
|
o In an IKE_AUTH exchange, as shown in the example message exchange
|
|||
|
in Figure 3 below.
|
|||
|
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
|
|||
|
o In an Informational exchange, if the gateway previously replied
|
|||
|
with an N(TICKET_ACK) instead of providing a ticket.
|
|||
|
o In an Informational exchange, when the ticket lifetime is about to
|
|||
|
expire.
|
|||
|
o In an IKE_SESSION_RESUME exchange, see Section 4.2.3.
|
|||
|
|
|||
|
Normally, a client requests a ticket in the third message of an IKEv2
|
|||
|
exchange (the first of IKE_AUTH). Figure 3 shows the message
|
|||
|
exchange for this typical case.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 9]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
Initiator Responder
|
|||
|
----------- -----------
|
|||
|
HDR, SAi1, KEi, Ni -->
|
|||
|
|
|||
|
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
|
|||
|
|
|||
|
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
|
|||
|
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
|
|||
|
|
|||
|
Figure 3: Example Message Exchange for Requesting a Ticket
|
|||
|
|
|||
|
The notification payloads are described in Section 4.3. The above is
|
|||
|
an example, and IKEv2 allows a number of variants on these messages.
|
|||
|
A complete description of IKEv2 can be found in [RFC4718].
|
|||
|
|
|||
|
When an IKEv2 responder receives a request for a ticket using the
|
|||
|
N(TICKET_REQUEST) payload it MUST perform one of the following
|
|||
|
operations if it supports the extension defined in this document:
|
|||
|
o it creates a ticket and returns it with the N(TICKET_OPAQUE)
|
|||
|
payload in a subsequent message towards the IKEv2 initiator. This
|
|||
|
is shown in Figure 4.
|
|||
|
o it returns an N(TICKET_NACK) payload, if it refuses to grant a
|
|||
|
ticket for some reason.
|
|||
|
o it returns an N(TICKET_ACK), if it cannot grant a ticket
|
|||
|
immediately, e.g., due to packet size limitations. In this case
|
|||
|
the client MAY request a ticket later using an Informational
|
|||
|
exchange, at any time during the lifetime of the IKE SA.
|
|||
|
|
|||
|
Provided the IKEv2 exchange was successful, the IKEv2 initiator can
|
|||
|
accept the requested ticket. The ticket may be used later with an
|
|||
|
IKEv2 responder which supports this extension. Figure 4 shows how
|
|||
|
the initiator receives the ticket.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Initiator Responder
|
|||
|
----------- -----------
|
|||
|
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
|
|||
|
TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
|
|||
|
|
|||
|
|
|||
|
Figure 4: Receiving a Ticket
|
|||
|
|
|||
|
4.2. Presenting a Ticket
|
|||
|
|
|||
|
Following a communication failure, a client re-initiates an IKE
|
|||
|
exchange to the same gateway or to a different one, and includes a
|
|||
|
ticket in the first message. A client MAY initiate a regular (non-
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 10]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
ticket-based) IKEv2 exchange even if it is in possession of a valid
|
|||
|
ticket. A client MUST NOT present a ticket after the ticket's
|
|||
|
lifetime has expired.
|
|||
|
|
|||
|
It is up to the client's local policy to decide when the
|
|||
|
communication with the IKEv2 responder is seen as interrupted and a
|
|||
|
new exchange needs to be initiated and the session resumption
|
|||
|
procedure to be initiated.
|
|||
|
|
|||
|
Tickets are intended for one-time use: a client MUST NOT reuse a
|
|||
|
ticket, either with the same or with a different gateway. A gateway
|
|||
|
SHOULD reject a reused ticket. Note however that a gateway can elect
|
|||
|
not to retain a list of already-used tickets. Potential replay
|
|||
|
attacks on such gateways are mitigated by the cookie mechanism
|
|||
|
described in Section 4.2.2.
|
|||
|
|
|||
|
This document specifies a new IKEv2 exchange type called
|
|||
|
IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
|
|||
|
somewhat similar to the IKE_AUTH exchange, and results in the
|
|||
|
creation of a Child SA. The client SHOULD NOT use this exchange type
|
|||
|
unless it knows that the gateway supports it, either through
|
|||
|
configuration, by out-of-band means or by using the Gateway List
|
|||
|
provision.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Initiator Responder
|
|||
|
----------- -----------
|
|||
|
HDR, Ni, N(TICKET_OPAQUE), [N+,]
|
|||
|
SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
|
|||
|
|
|||
|
The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
|
|||
|
|
|||
|
See Section 4.2.1 for details on computing the protected (SK)
|
|||
|
payload.
|
|||
|
|
|||
|
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
|
|||
|
payload it MUST perform one of the following steps if it supports the
|
|||
|
extension defined in this document:
|
|||
|
o If it is willing to accept the ticket, it responds as shown in
|
|||
|
Figure 5.
|
|||
|
o It responds with an unprotected N(TICKET_NACK) notification, if it
|
|||
|
rejects the ticket for any reason. In that case, the initiator
|
|||
|
should re-initiate a regular IKE exchange. One such case is when
|
|||
|
the responder receives a ticket for an IKE SA that has previously
|
|||
|
been terminated on the responder itself, which may indicate
|
|||
|
inconsistent state between the IKEv2 initiator and the responder.
|
|||
|
However, a responder is not required to maintain the state for
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 11]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
terminated sessions.
|
|||
|
o When the responder receives a ticket for an IKE SA that is still
|
|||
|
active and if the responder accepts it, then the old SAs SHOULD be
|
|||
|
silently deleted without sending a DELETE informational exchange.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Initiator Responder
|
|||
|
----------- -----------
|
|||
|
<-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
|
|||
|
[CP(CFG_REPLY)]}
|
|||
|
|
|||
|
Figure 5: IKEv2 Responder accepts the ticket
|
|||
|
|
|||
|
Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.
|
|||
|
|
|||
|
The SK payload is protected using the cryptographic parameters
|
|||
|
derived from the ticket, see Section 4.2.1 below.
|
|||
|
|
|||
|
At this point a new IKE SA is created by both parties, see
|
|||
|
Section 4.6. This is followed by normal derivation of a child SA,
|
|||
|
per Sec. 2.17 of [RFC4306].
|
|||
|
|
|||
|
4.2.1. Protection of the IKE_SESSION_RESUME Exchange
|
|||
|
|
|||
|
The two messages of this exchange are protected by a "subset" IKE SA.
|
|||
|
The key material is derived from the ticket, as follows:
|
|||
|
|
|||
|
|
|||
|
{SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)
|
|||
|
|
|||
|
where SK_d_old is the SK_d value of the original IKE SA, as retrieved
|
|||
|
from the ticket. Ni guarantees freshness of the key material. SK_d2
|
|||
|
is used later to derive the new IKE SA, see Section 4.6.
|
|||
|
|
|||
|
See [RFC4306] for the notation. "prf" is determined from the SA value
|
|||
|
in the ticket.
|
|||
|
|
|||
|
4.2.2. Presenting a Ticket: The DoS Case
|
|||
|
|
|||
|
When receiving the first message of the IKE_SESSION_RESUME exchange,
|
|||
|
the gateway may decide that it is under a denial-of-service attack.
|
|||
|
In such a case, the gateway SHOULD defer the establishment of session
|
|||
|
state until it has verified the identity of the client. We use a
|
|||
|
variation of the IKEv2 Cookie mechanism, where the cookie is
|
|||
|
protected.
|
|||
|
|
|||
|
In the two messages that follow, the gateway responds that it is
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 12]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
unwilling to resume the session until the client is verified, and the
|
|||
|
client resubmits its first message, this time with the cookie:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Initiator Responder
|
|||
|
----------- -----------
|
|||
|
<-- HDR, SK{N(COOKIE)}
|
|||
|
HDR, Ni, N(TICKET_OPAQUE), [N+,]
|
|||
|
SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
|
|||
|
|
|||
|
Assuming the cookie is correct, the gateway now replies normally.
|
|||
|
|
|||
|
This now becomes a 4-message exchange. The entire exchange is
|
|||
|
protected as defined in Section 4.2.1.
|
|||
|
|
|||
|
See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding
|
|||
|
the usage and syntax of the cookie. Note that the cookie is
|
|||
|
completely independent of the IKEv2 ticket.
|
|||
|
|
|||
|
4.2.3. Requesting a ticket during resumption
|
|||
|
|
|||
|
When resuming a session, a client will typically request a new ticket
|
|||
|
immediately, so it is able to resume the session again in the case of
|
|||
|
a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
|
|||
|
and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
|
|||
|
protected payloads to the IKE_SESSION_RESUME exchange.
|
|||
|
|
|||
|
The returned ticket (if any) will correspond to the IKE SA created
|
|||
|
per the rules described in Section 4.6.
|
|||
|
|
|||
|
4.3. IKE Notifications
|
|||
|
|
|||
|
This document defines a number of notifications. The notification
|
|||
|
numbers are TBA by IANA.
|
|||
|
|
|||
|
+---------------------+--------+-----------------+
|
|||
|
| Notification Name | Number | Data |
|
|||
|
+---------------------+--------+-----------------+
|
|||
|
| TICKET_OPAQUE | TBA1 | See Section 4.4 |
|
|||
|
| TICKET_REQUEST | TBA2 | None |
|
|||
|
| TICKET_ACK | TBA3 | None |
|
|||
|
| TICKET_NACK | TBA4 | None |
|
|||
|
| TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 |
|
|||
|
+---------------------+--------+-----------------+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 13]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
4.4. TICKET_OPAQUE Notify Payload
|
|||
|
|
|||
|
The data for the TICKET_OPAQUE Notify payload consists of the Notify
|
|||
|
message header, a lifetime field and the ticket itself. The four
|
|||
|
octet lifetime field contains the number of seconds until the ticket
|
|||
|
expires as an unsigned integer. Section 5.2 describes a possible
|
|||
|
ticket format, and Section 5.3 offers further guidelines regarding
|
|||
|
the ticket's lifetime.
|
|||
|
|
|||
|
|
|||
|
0 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 = 0 ! Notify Message Type !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
! Lifetime !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
! !
|
|||
|
~ Ticket ~
|
|||
|
! !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
Figure 6: TICKET_OPAQUE Notify Payload
|
|||
|
|
|||
|
4.5. TICKET_GATEWAY_LIST Notify Payload
|
|||
|
|
|||
|
The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
|
|||
|
header followed by a sequence of one or more gateway identifiers,
|
|||
|
each of the format depicted in Figure 8.
|
|||
|
|
|||
|
|
|||
|
0 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 = 0 ! Notify Message Type !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
! !
|
|||
|
~ Gateway Identifier List ~
|
|||
|
! !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
Figure 7: TICKET_GATEWAY_LIST Notify Payload
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 14]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
0 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
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
! ID Type ! Reserved ! Length !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
! !
|
|||
|
~ Identification Data ~
|
|||
|
! !
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
Figure 8: Gateway Identifier for One Gateway
|
|||
|
|
|||
|
ID Type:
|
|||
|
|
|||
|
The ID Type contains a restricted set of the IKEv2 ID payloads
|
|||
|
(see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR,
|
|||
|
ID_IPV6_ADDR, ID_FQDN and the various reserved values.
|
|||
|
|
|||
|
Reserved:
|
|||
|
|
|||
|
This field must be sent as 0 and must be ignored when received.
|
|||
|
|
|||
|
Length:
|
|||
|
|
|||
|
The length field indicates the total size of the Identification
|
|||
|
data.
|
|||
|
|
|||
|
Identification Data:
|
|||
|
|
|||
|
The Identification Data field is of variable length and depends on
|
|||
|
the ID type. The length is not necessarily a multiple of 4.
|
|||
|
|
|||
|
4.6. Processing Guidelines for IKE SA Establishment
|
|||
|
|
|||
|
When a ticket is presented, the gateway parses the ticket to retrieve
|
|||
|
the state of the old IKE SA, and the client retrieves this state from
|
|||
|
its local store. Both peers now create state for the new IKE SA as
|
|||
|
follows:
|
|||
|
|
|||
|
o The SA value (transforms etc.) is taken directly from the ticket.
|
|||
|
o The sequence numbers are reset to 0.
|
|||
|
o The IDi value is obtained from the ticket.
|
|||
|
o The IDr value is obtained from the new exchange. The gateway MAY
|
|||
|
make policy decisions based on the IDr value encoded in the
|
|||
|
ticket.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 15]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
o The SPI values are created anew, similarly to a regular IKE
|
|||
|
exchange. SPI values from the ticket SHOULD NOT be reused. This
|
|||
|
restriction is to avoid problems caused by collisions with other
|
|||
|
SPI values used already by the initiator/responder. The SPI value
|
|||
|
should only be reused if collision avoidance can be ensured
|
|||
|
through other means.
|
|||
|
|
|||
|
The cryptographic material is refreshed based on the ticket and the
|
|||
|
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
|
|||
|
value is derived as follows:
|
|||
|
|
|||
|
|
|||
|
SKEYSEED = prf(SK_d2, Ni | Nr)
|
|||
|
|
|||
|
where SK_d2 was computed earlier (Section 4.2.1).
|
|||
|
|
|||
|
The keys are derived as follows, unchanged from IKEv2:
|
|||
|
|
|||
|
|
|||
|
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
|
|||
|
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
|
|||
|
|
|||
|
where SPIi, SPIr are the SPI values created in the new IKE exchange.
|
|||
|
|
|||
|
See [RFC4306] for the notation. "prf" is determined from the SA value
|
|||
|
in the ticket.
|
|||
|
|
|||
|
|
|||
|
5. The IKE Ticket
|
|||
|
|
|||
|
This section lists the required contents of the ticket, and
|
|||
|
recommends a non-normative format. This is followed by a discussion
|
|||
|
of the ticket's lifecycle.
|
|||
|
|
|||
|
5.1. Ticket Contents
|
|||
|
|
|||
|
The ticket MUST encode at least the following state from an IKE SA.
|
|||
|
These values MUST be encrypted and authenticated.
|
|||
|
|
|||
|
o IDi, IDr.
|
|||
|
o SPIi, SPIr.
|
|||
|
o SAr (the accepted proposal).
|
|||
|
o SK_d.
|
|||
|
|
|||
|
In addition, the ticket MUST encode a protected ticket expiration
|
|||
|
value.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 16]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
5.2. Ticket Format
|
|||
|
|
|||
|
This document does not specify a mandatory-to-implement or a
|
|||
|
mandatory-to-use ticket format. The following format is RECOMMENDED,
|
|||
|
if interoperability between gateways is desired.
|
|||
|
|
|||
|
|
|||
|
struct {
|
|||
|
[authenticated] struct {
|
|||
|
octet format_version; // 1 for this version of the protocol
|
|||
|
octet reserved[3]; // sent as 0, ignored by receiver.
|
|||
|
octet key_id[8]; // arbitrary byte string
|
|||
|
opaque IV[0..255]; // actual length (possibly 0) depends
|
|||
|
// on the encryption algorithm
|
|||
|
|
|||
|
[encrypted] struct {
|
|||
|
opaque IDi, IDr; // the full payloads
|
|||
|
octet SPIi[8], SPIr[8];
|
|||
|
opaque SA; // the full SAr payload
|
|||
|
octet SK_d[0..255]; // actual length depends on SA value
|
|||
|
int32 expiration; // an absolute time value, seconds
|
|||
|
// since Jan. 1, 1970
|
|||
|
} ikev2_state;
|
|||
|
} protected_part;
|
|||
|
opaque MAC[0..255]; // the length (possibly 0) depends
|
|||
|
// on the integrity algorithm
|
|||
|
} ticket;
|
|||
|
|
|||
|
Note that the key defined by "key_id" determines the encryption and
|
|||
|
authentication algorithms used for this ticket. Those algorithms are
|
|||
|
unrelated to the transforms defined by the SA payload.
|
|||
|
|
|||
|
The reader is referred to a recent draft
|
|||
|
[I-D.rescorla-stateless-tokens] that recommends a similar (but not
|
|||
|
identical) ticket format, and discusses related security
|
|||
|
considerations in depth.
|
|||
|
|
|||
|
5.3. Ticket Identity and Lifecycle
|
|||
|
|
|||
|
Each ticket is associated with a single IKE SA. In particular, when
|
|||
|
an IKE SA is deleted, the client MUST delete its stored ticket.
|
|||
|
|
|||
|
A ticket is therefore associated with the tuple (IDi, IDr). The
|
|||
|
client MAY however use a ticket to approach other gateways that are
|
|||
|
willing to accept it. How a client discovers such gateways is
|
|||
|
outside the scope of this document.
|
|||
|
|
|||
|
The lifetime of the ticket carried in the N(TICKET_OPAQUE)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 17]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
notification should be the minimum of the IKE SA lifetime (per the
|
|||
|
gateway's local policy) and its re-authentication time, according to
|
|||
|
[RFC4478]. Even if neither of these are enforced by the gateway, a
|
|||
|
finite lifetime MUST be specified for the ticket.
|
|||
|
|
|||
|
5.4. Exchange of Ticket-Protecting Keys
|
|||
|
|
|||
|
This document does not define an interoperable mechanism for the
|
|||
|
generation and distribution of the keys that protect IKE keys. Such
|
|||
|
a mechanism can be developed, based on the GDOI group key exchange
|
|||
|
protocol [RFC3547]. There is on-going work to enable the generation
|
|||
|
of non-IPsec keys by means of GDOI, e.g. to provide RSVP router
|
|||
|
groups with a single key [I-D.weis-gdoi-for-rsvp]. This work can be
|
|||
|
generalized for our purposes. We note that there are no significant
|
|||
|
performance requirements on such a protocol, as key rollover can be
|
|||
|
at a daily or even more leisurely rate.
|
|||
|
|
|||
|
|
|||
|
6. IANA Considerations
|
|||
|
|
|||
|
This document requires a number of IKEv2 notification status types in
|
|||
|
Section 4.3, to be registered by IANA. The corresponding registry
|
|||
|
was established by IANA.
|
|||
|
|
|||
|
The document defines a new IKEv2 exchange in Section 4.2. The
|
|||
|
corresponding registry was established by IANA.
|
|||
|
|
|||
|
|
|||
|
7. Security Considerations
|
|||
|
|
|||
|
This section addresses security issues related to the usage of a
|
|||
|
ticket.
|
|||
|
|
|||
|
7.1. Stolen Tickets
|
|||
|
|
|||
|
An eavesdropper or man-in-the-middle may try to obtain a ticket and
|
|||
|
use it to establish a session with the IKEv2 responder. This can
|
|||
|
happen in different ways: by eavesdropping on the initial
|
|||
|
communication and copying the ticket when it is granted and before it
|
|||
|
is used, or by listening in on a client's use of the ticket to resume
|
|||
|
a session. However, since the ticket's contents is encrypted and the
|
|||
|
attacker does not know the corresponding secret key (specifically,
|
|||
|
SK_d), a stolen ticket cannot be used by an attacker to resume a
|
|||
|
session. An IKEv2 responder MUST use strong encryption and integrity
|
|||
|
protection of the ticket to prevent an attacker from obtaining the
|
|||
|
ticket's contents, e.g., by using a brute force attack.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 18]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
7.2. Forged Tickets
|
|||
|
|
|||
|
A malicious user could forge or alter a ticket in order to resume a
|
|||
|
session, to extend its lifetime, to impersonate as another user, or
|
|||
|
to gain additional privileges. This attack is not possible if the
|
|||
|
ticket is protected using a strong integrity protection algorithm.
|
|||
|
|
|||
|
7.3. Denial of Service Attacks
|
|||
|
|
|||
|
The key_id field defined in the recommended ticket format helps the
|
|||
|
server efficiently reject tickets that it did not issue. However, an
|
|||
|
adversary could generate and send a large number of tickets to a
|
|||
|
gateway for verification. To minimize the possibility of such denial
|
|||
|
of service, ticket verification should be lightweight (e.g., using
|
|||
|
efficient symmetric key cryptographic algorithms).
|
|||
|
|
|||
|
7.4. Ticket Protection Key Management
|
|||
|
|
|||
|
A full description of the management of the keys used to protect the
|
|||
|
ticket is beyond the scope of this document. A list of RECOMMENDED
|
|||
|
practices is given below.
|
|||
|
o The keys should be generated securely following the randomness
|
|||
|
recommendations in [RFC4086].
|
|||
|
o The keys and cryptographic protection algorithms should be at
|
|||
|
least 128 bits in strength.
|
|||
|
o The keys should not be used for any other purpose than generating
|
|||
|
and verifying tickets.
|
|||
|
o The keys should be changed regularly.
|
|||
|
o The keys should be changed if the ticket format or cryptographic
|
|||
|
protection algorithms change.
|
|||
|
|
|||
|
7.5. Ticket Lifetime
|
|||
|
|
|||
|
An IKEv2 responder controls the lifetime of a ticket, based on the
|
|||
|
operational and security requirements of the environment in which it
|
|||
|
is deployed. The responder provides information about the ticket
|
|||
|
lifetime to the IKEv2 initiator, allowing it to manage its tickets.
|
|||
|
|
|||
|
An IKEv2 client may present a ticket in its possession to a gateway,
|
|||
|
even if the IKE SA associated with this ticket had previously been
|
|||
|
terminated by another gateway (the gateway that originally provided
|
|||
|
the ticket). Where such usage is against the local security policy,
|
|||
|
an Invalid Ticket List (ITL) may be used, see
|
|||
|
[I-D.rescorla-stateless-tokens]. Management of such lists is outside
|
|||
|
the scope of the current document. Note that a policy that requires
|
|||
|
tickets to have shorter lifetimes (e.g., 1 hour) significantly
|
|||
|
mitigates this risk.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 19]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
7.6. Alternate Ticket Formats and Distribution Schemes
|
|||
|
|
|||
|
If the ticket format or distribution scheme defined in this document
|
|||
|
is not used, then great care must be taken in analyzing the security
|
|||
|
of the solution. In particular, if confidential information, such as
|
|||
|
a secret key, is transferred to the client, it MUST be done using
|
|||
|
secure communication to prevent attackers from obtaining or modifying
|
|||
|
the key. Also, the ticket MUST have its integrity and
|
|||
|
confidentiality protected with strong cryptographic techniques to
|
|||
|
prevent a breach in the security of the system.
|
|||
|
|
|||
|
7.7. Identity Privacy, Anonymity, and Unlinkability
|
|||
|
|
|||
|
This document mandates that the content of the ticket MUST be
|
|||
|
encrypted in order to avoid leakage of information, such as the
|
|||
|
identities of an IKEv2 initiator and a responder. Thus, it prevents
|
|||
|
the disclosure of potentially sensitive information carried within
|
|||
|
the ticket.
|
|||
|
|
|||
|
When an IKEv2 initiator presents the ticket as part of the
|
|||
|
IKE_SESSION_RESUME exchange, confidentiality is not provided for the
|
|||
|
exchange. Although the ticket itself is encrypted there might still
|
|||
|
be a possibility for an on-path adversary to observe multiple
|
|||
|
exchange handshakes where the same ticket is used and therefore to
|
|||
|
conclude that they belong to the same communication end points.
|
|||
|
Administrators that use the ticket mechanism described in this
|
|||
|
document should be aware that unlinkability may not be provided by
|
|||
|
this mechanism. Note, however, that IKEv2 does not provide active
|
|||
|
user identity confidentiality for the IKEv2 initiator either.
|
|||
|
|
|||
|
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange
|
|||
|
|
|||
|
A major design goal of this protocol extension has been the two-
|
|||
|
message exchange for session resumption. There is a tradeoff between
|
|||
|
this abbreviated exchange and replay protection. It is RECOMMENDED
|
|||
|
that the gateway should cache tickets, and reject replayed ones.
|
|||
|
However some gateways may not do that in order to reduce state size.
|
|||
|
In addition, an adversary may replay a ticket last presented to
|
|||
|
gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
|
|||
|
mitigates both scenarios by ensuring that the client presenting the
|
|||
|
ticket is indeed its "owner": the client can be required by the
|
|||
|
gateway to prove that it knows the ticket's secret, before any state
|
|||
|
is committed on the gateway. Note that this is a stronger guarantee
|
|||
|
than the regular IKE cookie mechanism, which only proves IP return
|
|||
|
routability of the client. This is enabled by including the cookie
|
|||
|
in the protected portion of the message.
|
|||
|
|
|||
|
For performance reasons, the cookie mechanism is optional, and
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 20]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
invoked by the gateway only when it suspects that it is the subject
|
|||
|
of a denial-of-service attack.
|
|||
|
|
|||
|
In any case, a ticket replayed by an adversary only causes partial
|
|||
|
IKE state to be created on the gateway. The IKE exchange cannot be
|
|||
|
completed and an IKE SA cannot be created unless the client knows the
|
|||
|
ticket's secret values.
|
|||
|
|
|||
|
|
|||
|
8. Acknowledgements
|
|||
|
|
|||
|
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
|
|||
|
Yoav Nir and Tero Kivinen for their many helpful comments.
|
|||
|
|
|||
|
|
|||
|
9. References
|
|||
|
|
|||
|
9.1. Normative References
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
|
|||
|
RFC 4306, December 2005.
|
|||
|
|
|||
|
9.2. Informative References
|
|||
|
|
|||
|
[I-D.friedman-ike-short-term-certs]
|
|||
|
Friedman, A., "Short-Term Certificates",
|
|||
|
draft-friedman-ike-short-term-certs-02 (work in progress),
|
|||
|
June 2007.
|
|||
|
|
|||
|
[I-D.rescorla-stateless-tokens]
|
|||
|
Rescorla, E., "How to Implement Secure (Mostly) Stateless
|
|||
|
Tokens", draft-rescorla-stateless-tokens-01 (work in
|
|||
|
progress), March 2007.
|
|||
|
|
|||
|
[I-D.vidya-ipsec-failover-ps]
|
|||
|
Narayanan, V., "IPsec Gateway Failover and Redundancy -
|
|||
|
Problem Statement and Goals",
|
|||
|
draft-vidya-ipsec-failover-ps-02 (work in progress),
|
|||
|
December 2007.
|
|||
|
|
|||
|
[I-D.weis-gdoi-for-rsvp]
|
|||
|
Weis, B., "Group Domain of Interpretation (GDOI) support
|
|||
|
for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
|
|||
|
February 2008.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 21]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
|
|||
|
Group Domain of Interpretation", RFC 3547, July 2003.
|
|||
|
|
|||
|
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
|
|||
|
Requirements for Security", BCP 106, RFC 4086, June 2005.
|
|||
|
|
|||
|
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
|
|||
|
Internet Protocol", RFC 4301, December 2005.
|
|||
|
|
|||
|
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
|
|||
|
(IKEv2) Protocol", RFC 4478, April 2006.
|
|||
|
|
|||
|
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
|
|||
|
"Transport Layer Security (TLS) Session Resumption without
|
|||
|
Server-Side State", RFC 4507, May 2006.
|
|||
|
|
|||
|
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
|
|||
|
(MOBIKE)", RFC 4555, June 2006.
|
|||
|
|
|||
|
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
|
|||
|
Implementation Guidelines", RFC 4718, October 2006.
|
|||
|
|
|||
|
|
|||
|
Appendix A. Related Work
|
|||
|
|
|||
|
[I-D.friedman-ike-short-term-certs] is on-going work that discusses
|
|||
|
the use of short-term certificates for client re-authentication. It
|
|||
|
is similar to the ticket approach described in this document in that
|
|||
|
they both require enhancements to IKEv2 to allow information request,
|
|||
|
e.g., for a certificate or a ticket. However, the changes required
|
|||
|
by the former are fewer since an obtained certificate is valid for
|
|||
|
any IKE responder that is able to verify them. On the other hand,
|
|||
|
short-term certificates, while eliminating the usability issues of
|
|||
|
user re-authentication, do not reduce the amount of effort performed
|
|||
|
by the gateway in failover situations.
|
|||
|
|
|||
|
|
|||
|
Appendix B. Change Log
|
|||
|
|
|||
|
B.1. -03
|
|||
|
|
|||
|
Removed counter mechanism. Added an optional anti-DoS mechanism,
|
|||
|
based on IKEv2 cookies (removed previous discussion of cookies).
|
|||
|
Clarified that gateways may support reallocation of same IP address,
|
|||
|
if provided by network. Proposed a solution outline to the problem
|
|||
|
of key exchange for the keys that protect tickets. Added fields to
|
|||
|
the ticket to enable interoperability. Removed incorrect MOBIKE
|
|||
|
notification.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 22]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
B.2. -02
|
|||
|
|
|||
|
Clarifications on generation of SPI values, on the ticket's lifetime
|
|||
|
and on the integrity protection of the anti-replay counter.
|
|||
|
Eliminated redundant SPIs from the notification payloads.
|
|||
|
|
|||
|
B.3. -01
|
|||
|
|
|||
|
Editorial review. Removed 24-hour limitation on ticket lifetime,
|
|||
|
lifetime is up to local policy.
|
|||
|
|
|||
|
B.4. -00
|
|||
|
|
|||
|
Initial version. This draft is a selective merge of
|
|||
|
draft-sheffer-ike-session-resumption-00 and
|
|||
|
draft-dondeti-ipsec-failover-sol-00.
|
|||
|
|
|||
|
|
|||
|
Authors' Addresses
|
|||
|
|
|||
|
Yaron Sheffer
|
|||
|
Check Point Software Technologies Ltd.
|
|||
|
5 Hasolelim St.
|
|||
|
Tel Aviv 67897
|
|||
|
Israel
|
|||
|
|
|||
|
Email: yaronf@checkpoint.com
|
|||
|
|
|||
|
|
|||
|
Hannes Tschofenig
|
|||
|
Nokia Siemens Networks
|
|||
|
Otto-Hahn-Ring 6
|
|||
|
Munich, Bavaria 81739
|
|||
|
Germany
|
|||
|
|
|||
|
Email: Hannes.Tschofenig@nsn.com
|
|||
|
URI: http://www.tschofenig.priv.at
|
|||
|
|
|||
|
|
|||
|
Lakshminath Dondeti
|
|||
|
QUALCOMM, Inc.
|
|||
|
5775 Morehouse Dr
|
|||
|
San Diego, CA
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 858-845-1267
|
|||
|
Email: ldondeti@qualcomm.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 23]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
Vidya Narayanan
|
|||
|
QUALCOMM, Inc.
|
|||
|
5775 Morehouse Dr
|
|||
|
San Diego, CA
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 858-845-2483
|
|||
|
Email: vidyan@qualcomm.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 24]
|
|||
|
|
|||
|
Internet-Draft IPsec Gateway Failover Protocol March 2008
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The IETF Trust (2008).
|
|||
|
|
|||
|
This document is subject to the rights, licenses and restrictions
|
|||
|
contained in BCP 78, and except as set forth therein, the authors
|
|||
|
retain all their rights.
|
|||
|
|
|||
|
This document and the information contained herein are provided on an
|
|||
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|||
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
|||
|
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
|||
|
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|||
|
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|||
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
Intellectual Property
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
Intellectual Property Rights or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; nor does it represent that it has
|
|||
|
made any independent effort to identify any such rights. Information
|
|||
|
on the procedures with respect to rights in RFC documents can be
|
|||
|
found in BCP 78 and BCP 79.
|
|||
|
|
|||
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|||
|
assurances of licenses to be made available, or the result of an
|
|||
|
attempt made to obtain a general license or permission for the use of
|
|||
|
such proprietary rights by implementers or users of this
|
|||
|
specification can be obtained from the IETF on-line IPR repository at
|
|||
|
http://www.ietf.org/ipr.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights that may cover technology that may be required to implement
|
|||
|
this standard. Please address the information to the IETF at
|
|||
|
ietf-ipr@ietf.org.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sheffer, et al. Expires September 20, 2008 [Page 25]
|
|||
|
|
|||
|
|