1402 lines
51 KiB
Text
1402 lines
51 KiB
Text
|
||
|
||
|
||
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]
|
||
|
||
|