< draft-sheffer-ipsec-failover-01.txt   draft-sheffer-ipsec-failover-02.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Network Working Group Y. Sheffer Network Working Group Y. Sheffer
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Experimental H. Tschofenig Intended status: Experimental H. Tschofenig
Expires: May 18, 2008 Nokia Siemens Networks Expires: May 18, 2008 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
November 15, 2007 November 15, 2007
IPsec Gateway Failover Protocol IPsec Gateway Failover Protocol
draft-sheffer-ipsec-failover-01.txt draft-sheffer-ipsec-failover-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Internet Key Exchange version 2 (IKEv2) protocol has The Internet Key Exchange version 2 (IKEv2) protocol has
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and cryptographic operations involved. In of round-trips required and cryptographic operations involved. In
remote access situations, the Extensible Authentication Protocol is remote access situations, the Extensible Authentication Protocol is
used for authentication, which adds additional latency. used for authentication, which adds additional roundstrips and
therefore latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
condition is time consuming, especially when an IPsec peer, such as a 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 VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment. additional problems for an IPsec peer during SA re-establishment.
In many failure cases it would be useful to provide an efficient way In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA 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 with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected, A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with or alternatively migrate to another gateway that is associated with
the previous one. The proposed approach conveys IKEv2 state the previous one. The proposed approach conveys IKEv2 state
information, in the form of an encrypted ticket, to a VPN client that information, in the form of an encrypted ticket, to a VPN client that
is later presented to the VPN gateway for re-authentication. An is later presented to the VPN gateway for re-authentication. The
encrypted ticket cannot be decrypted by a VPN client but allows a VPN encrypted ticket can only be decrypted by the VPN gateway in order to
gateway to restore state for faster session state setup. restore state for faster session setup.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Recovering from a Remote Access Gateway Failover . . . . . 6 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6
3.2. Recovering from an Application Server Failover . . . . . . 8 3.2. Recovering from an Application Server Failover . . . . . . 8
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9
4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12
4.2.2. Requesting a ticket during resumption . . . . . . . . 12 4.2.2. Requesting a ticket during resumption . . . . . . . . 12
4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 12 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 12
4.4. Gateway List . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 13
4.5. Processing Guidelines for IKE SA Establishment . . . . . . 13 4.5. TICKET_COUNTER Notify Payload . . . . . . . . . . . . . . 13
5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 14 4.7. Processing Guidelines for IKE SA Establishment . . . . . . 15
5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 15 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 16 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 17
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 17 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 17 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18
7.6. Alternate Ticket Formats and Distribution Schemes . . . . 17 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 18
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 17 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 18
7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 18 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 19
7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE . . . 18 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.9. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 21
B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol has The Internet Key Exchange version 2 (IKEv2) protocol has
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and cryptographic operations involved. In of round-trips required and cryptographic operations involved. In
particular the Extensible Authentication Protocol is used for particular the Extensible Authentication Protocol is used for
authentication in remote access cases, which adds additional latency. authentication in remote access cases, which adds additional latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
skipping to change at page 4, line 27 skipping to change at page 4, line 27
additional problems for an IPsec peer. additional problems for an IPsec peer.
In many failure cases it would be useful to provide an efficient way In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA 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 with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected, A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with or alternatively migrate to another gateway that is associated with
the previous one. This document proposes to maintain an IKEv2 state the previous one. This document proposes to maintain IKEv2 state in
in a "ticket", an opaque data structure created and used by a server a "ticket", an opaque data structure created and used by a server and
and stored by a client, which the client cannot understand or tamper stored by a client, which the client cannot understand or tamper
with. The IKEv2 protocol needs to be extended to allow a client to with. The IKEv2 protocol needs to be extended to allow a client to
request and present a ticket. When two gateways mutually trust each request and present a ticket. When two gateways mutually trust each
other, one can accept a ticket generated by the other. other, one can accept a ticket generated by the other.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC4507] with the required adaptations for IKEv2, e.g., to [RFC4507] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed accommodate the two-phase protocol structure. We have borrowed
heavily from that specification. heavily from that specification.
1.1. Goals 1.1. Goals
skipping to change at page 5, line 9 skipping to change at page 5, line 9
be recovered from failures in remote access scenarios, in a more be recovered from failures in remote access scenarios, in a more
efficient manner than the basic IKE solution. This efficiency is efficient manner than the basic IKE solution. This efficiency is
primarily on the gateway side, since the gateway might have to deal primarily on the gateway side, since the gateway might have to deal
with many thousands of concurrent requests. We should enable the with many thousands of concurrent requests. We should enable the
following cases: following cases:
o Failover from one gateway to another, where the two gateways do o Failover from one gateway to another, where the two gateways do
not share state but do have mutual trust. For example, the not share state but do have mutual trust. For example, the
gateways may be operated by the same provider and share the same gateways may be operated by the same provider and share the same
keying materials to access an encrypted ticket. keying materials to access an encrypted ticket.
o Recovery from an intermittent connectivity failure ("network o Recovery from an intermittent connectivity, where clients
reboot"), where clients reconnect into the same gateway. In this reconnect into the same gateway. In this case, the gateway would
case, the gateway would typically have detected the clients' typically have detected the clients' absence and removed the state
absence and removed the state associated with them. associated with them.
o Recovery from a gateway restart, where clients reconnect into the o Recovery from a gateway restart, where clients reconnect into the
same gateway. same gateway.
The proposed solution should additionally meet the following goals: The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption. o Using only symmetric cryptography to minimize CPU consumption.
o Allowing a gateway to push state to clients. o Allowing a gateway to push state to clients.
o Providing cryptographic agility. o Providing cryptographic agility.
o Having no negative impact on IKEv2 security features. o Having no negative impact on IKEv2 security features.
Specifically, the solution must not introduce new security Specifically, the solution must not introduce new security
vulnerabilities, such as denial-of-service. vulnerabilities, such as vulnerabilities to denial-of-service
attacks.
1.2. Non-Goals 1.2. Non-Goals
The following are non-goals of this solution: The following are non-goals of this solution:
o Providing load balancing among gateways. o Providing load balancing among gateways.
o Specifying how a client detects the need for a failover. o Specifying how a client detects the need for a failover.
o Establishing trust among gateways. o Establishing trust among gateways.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terminology defined in [RFC4301], [RFC4306], and This document uses terminology defined in [RFC4301], [RFC4306], and
[RFC4555]. In addition, this document uses the following terms: [RFC4555]. In addition, this document uses the following terms:
Secure domain: A secure domain comprises a set of gateways that are Secure domain: A secure domain comprises a set of gateways that are
able to resume an IKEv2 session that may have been established by able to resume an IKEv2 session that may have been established by
any other gateway within the domain. All the gateways in the any other gateway within the domain. All gateways in the secure
secure domain are expected to share a security association - domain are expected to share a security association - either with
either with each other or through a trusted third party - so that each other or through a trusted third party - so that they can
they can verify the validity of the ticket and can extract the verify the validity of the ticket and can extract the IKEv2 policy
IKEv2 policy and session key material from the ticket. and session key material from the ticket.
IKEv2 ticket: An IKEv2 ticket is a data structure that contains all IKEv2 ticket: An IKEv2 ticket is a data structure that contains all
the necessary information that allows any gateway within the same the necessary information that allows any gateway within the same
secure domain as the gateway that created the ticket to verify the secure domain as the gateway that created the ticket to verify the
validity of the ticket and extract IKEv2 policy and session keys validity of the ticket and extract IKEv2 policy and session keys
to re-establish an IKEv2 session. to re-establish an IKEv2 session.
Stateless failover: When the IKEv2 session state is stored at the Stateless failover: When the IKEv2 session state is stored at the
client, the infrastructure is "stateless" until the client client, the IKEv2 responder is "stateless" until the client
restores the SA with one of the gateways within the secure domain; 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 thus, we refer to SA resumption with SA storage at the client as
stateless session resumption. stateless session resumption.
Stateful failover: When the infrastructure maintains IKEv2 session Stateful failover: When the infrastructure maintains IKEv2 session
state, we refer to the process of IKEv2 SA re-establishment as state, we refer to the process of IKEv2 SA re-establishment as
stateful session resumption. Note that even in this case, a small stateful session resumption.
amount of information (the "handle") needs to be stored on the
client.
3. Usage Scenarios 3. Usage Scenarios
This specification envisions two usage scenarios for efficient IKEv2 This specification envisions two usage scenarios for efficient IKEv2
and IPsec SA session re-establishment: The first is similar to the and IPsec SA session re-establishment.
use case specified in Section 1.1.3 of the IKEv2 specification
[RFC4306], where IPsec tunnel mode is to establish a secure channel The first is similar to the use case specified in Section 1.1.3 of
between a remote access client and a gateway; the traffic flow may be the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
between the client and entities beyond the gateway. The second use used to establish a secure channel between a remote access client and
case is somewhat different from any of the use cases defined in the a gateway; the traffic flow may be between the client and entities
IKEv2 specification: at the IP layer, two endpoints use transport (or beyond the gateway.
tunnel) mode to communicate between themselves. The two endpoints
have a client-server relationship with respect to a protocol that The second use case focuses on the usage of transport (or tunnel)
runs using the protections afforded by the IPsec SA. 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 3.1. Recovering from a Remote Access Gateway Failover
(a) (a)
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! ! IKEv2/IKEv2-EAP ! ! Protected ! ! IKEv2/IKEv2-EAP ! ! Protected
! Remote !<------------------------>! Remote ! Subnet ! Remote !<------------------------>! Remote ! Subnet
! Access ! ! Access !<--- and/or ! Access ! ! Access !<--- and/or
! Client !<------------------------>! Gateway ! Internet ! Client !<------------------------>! Gateway ! Internet
! ! IPsec tunnel ! ! ! ! IPsec tunnel ! !
skipping to change at page 10, line 39 skipping to change at page 10, line 39
4.2. Presenting a Ticket 4.2. Presenting a Ticket
Following a communication failure, a client re-initiates an IKE Following a communication failure, a client re-initiates an IKE
exchange to the same gateway or to a different one, and includes a 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- ticket in the first message. A client MAY initiate a regular (non-
ticket-based) IKEv2 exchange even if it is in possession of a valid 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 ticket. A client MUST NOT present a ticket after the ticket's
lifetime has expired. lifetime has expired.
It is purely a local decision of the client when and based on what It is up to the client's local policy to decide when the
information to decide that a communication failure has happened and communication with the IKEv2 responder is seen as interrupted and a
that a new exchange including the ticket is needed. new exchange needs to be initiated and the session resumption
procedure to be initiated.
We specify a new IKEv2 exchange type called IKE_SESSION_RESUME whose This document specifies a new IKEv2 exchange type called
value is TBA by IANA. This exchange is somewhat similar to the IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
IKE_AUTH exchange, and results in the creation of a Child SA. The somewhat similar to the IKE_AUTH exchange, and results in the
client MUST NOT use this exchange unless it knows that the gateway creation of a Child SA. The client MUST NOT use this exchange unless
supports failover, either through configuration, by out-of-band means it knows that the gateway supports failover, either through
or by using the Gateway List provision. configuration, by out-of-band means or by using the Gateway List
provision.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,] HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,]
SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)] SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]
[, N(UPDATE_SA_ADDRESSES)]} --> [, N(UPDATE_SA_ADDRESSES)]} -->
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
See Section 4.2.1 for details on computing the protected (SK) See Section 4.2.1 for details on computing the protected (SK)
skipping to change at page 11, line 35 skipping to change at page 11, line 36
o If it is willing to accept the ticket, it responds as shown in o If it is willing to accept the ticket, it responds as shown in
Figure 6. Figure 6.
o It responds with an unprotected N(TICKET_NACK) notification, if it o It responds with an unprotected N(TICKET_NACK) notification, if it
rejects the ticket for any reason. In that case, the initiator rejects the ticket for any reason. In that case, the initiator
should re-initiate a regular IKE exchange. One such case is when should re-initiate a regular IKE exchange. One such case is when
the responder receives a ticket for an IKE SA that has previously the responder receives a ticket for an IKE SA that has previously
been terminated on the responder itself, which may indicate been terminated on the responder itself, which may indicate
inconsistent state between the IKEv2 initiator and the responder. inconsistent state between the IKEv2 initiator and the responder.
However, a responder is not required to maintain the state for However, a responder is not required to maintain the state for
terminated sessions. terminated sessions.
o If the responder receives a ticket for an IKE SA that is still o When the responder receives a ticket for an IKE SA that is still
active and accepts it, it SHOULD silently delete the old SA active and if the responder accepts it, then the old SAs SHOULD be
without sending a DELETE Informational exchange. silently deleted without sending a DELETE informational exchange.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
[CP(CFG_REPLY)]} [CP(CFG_REPLY)]}
Figure 6: IKEv2 Responder accepts the ticket Figure 6: IKEv2 Responder accepts the ticket
Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.
The SK payload is protected using the cryptographic parameters The SK payload is protected using the cryptographic parameters
derived from the ticket, see Section 4.2.1 below. derived from the ticket, see Section 4.2.1 below.
At this point a new IKE SA is created by both parties, see At this point a new IKE SA is created by both parties, see
Section 4.5. This is followed by normal derivation of a child SA, Section 4.7. This is followed by normal derivation of a child SA,
per Sec. 2.17 of [RFC4306]. per Sec. 2.17 of [RFC4306].
4.2.1. Protection of the IKE_SESSION_RESUME Exchange 4.2.1. Protection of the IKE_SESSION_RESUME Exchange
The two messages of this exchange are protected by a "subset" IKE SA. The two messages of this exchange are protected by a "subset" IKE SA.
The key material is derived from the ticket, as follows: 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) {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 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 from the ticket. Ni guarantees freshness of the key material. SK_d2
is used later to derive the new IKE SA, see Section 4.5. is used later to derive the new IKE SA, see Section 4.7.
See [RFC4306] for the notation. "prf" is determined from the SA value See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket. in the ticket.
4.2.2. Requesting a ticket during resumption 4.2.2. Requesting a ticket during resumption
When resuming a session, a client will typically request a new ticket 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 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) a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
protected payloads to the IKE_SESSION_RESUME exchange. protected payloads to the IKE_SESSION_RESUME exchange.
The returned ticket (if any) will correspond to the IKE SA created The returned ticket (if any) will correspond to the IKE SA created
per the rules described in Section 4.5. per the rules described in Section 4.7.
4.3. IKE Notifications 4.3. IKE Notifications
This document defines a number of notifications. The notification This document defines a number of notifications. The notification
numbers are TBA by IANA. numbers are TBA by IANA.
+---------------------+--------+-----------------+ +---------------------+--------+-----------------+
| Notification Name | Number | Data | | Notification Name | Number | Data |
+---------------------+--------+-----------------+ +---------------------+--------+-----------------+
| TICKET_OPAQUE | TBA1 | See below | | TICKET_OPAQUE | TBA1 | See Figure 8 |
| TICKET_REQUEST | TBA2 | None | | TICKET_REQUEST | TBA2 | None |
| TICKET_ACK | TBA3 | None | | TICKET_ACK | TBA3 | None |
| TICKET_NACK | TBA4 | None | | TICKET_NACK | TBA4 | None |
| TICKET_COUNTER | TBA5 | See below | | TICKET_COUNTER | TBA5 | See Section 4.5 |
| TICKET_GATEWAY_LIST | TBA6 | See Section 4.4 | | TICKET_GATEWAY_LIST | TBA6 | See Section 4.6 |
+---------------------+--------+-----------------+ +---------------------+--------+-----------------+
The data for the TICKET_OPAQUE notification consists of a lifetime 4.4. TICKET_OPAQUE Notify Payload
duration in seconds (4 octets, denoting the time until the ticket
expires), followed by the ticket content. See Section 5.2 for a
recommended ticket format, and Section 5.3 for further guidelines
regarding the ticket's lifetime.
The data for TICKET_COUNTER consists of a single octet, treated as an The data for the TICKET_OPAQUE Notify payload consists of the Notify
unsigned integer. 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.
4.4. Gateway List 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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The gateway list is a sequence of zero or more gateway identifiers, Figure 8: TICKET_OPAQUE Notify Payload
each of the following format:
1 2 3 4.5. TICKET_COUNTER Notify Payload
The data for the TICKET_COUNTER Notify payload consists of the Notify
message header followed by a single octet, treated as an unsigned
integer as shown below.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Counter !
+-+-+-+-+-+-+-+-+
Figure 9: TICKET_COUNTER Notify Payload
4.6. 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 11.
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 10: TICKET_GATEWAY_LIST Notify Payload
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 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 ! ! ID Type ! Reserved ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Identifier Value !
! ! ! !
! ... ! ~ Identification Data ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Gateway Identifier Syntax Figure 11: Gateway Identifier for One Gateway
ID Type - see allowed values below. ID Type:
Reserved - must be sent as 0, ignored when received. 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.
Length - the length in octets of the identifier value. Reserved:
Identifier Value - variable length. The actual length depends on the This field must be sent as 0 and must be ignored when received.
ID type. The length is not necessarily a multiple of 4.
The values and semantics of identifiers follow those of IKEv2 ID Length:
payloads ([RFC4306], Sec. 3.5). Allowed ID types are: ID_IPV4_ADDR,
ID_IPV6_ADDR, ID_FQDN and the various reserved values.
4.5. Processing Guidelines for IKE SA Establishment 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.7. Processing Guidelines for IKE SA Establishment
When a ticket is presented, the gateway parses the ticket to retrieve 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 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 its local store. Both peers now create state for the new IKE SA as
follows: follows:
o The SA value (transforms etc.) is taken directly from the ticket. o The SA value (transforms etc.) is taken directly from the ticket.
o The sequence numbers are reset to 0. o The sequence numbers are reset to 0.
o The IDi value is obtained from the ticket. o The IDi value is obtained from the ticket.
o The IDr value is obtained from the new exchange. The gateway MAY o The IDr value is obtained from the new exchange. The gateway MAY
make policy decisions based on the IDr value encoded in the make policy decisions based on the IDr value encoded in the
ticket. ticket.
o The SPI values are created anew, similarly to a regular IKE o The SPI values are created anew, similarly to a regular IKE
exchange. SPI values from the ticket SHOULD NOT be reused. 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 The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows: value is derived as follows:
SKEYSEED = prf(SK_d2, Ni | Nr) SKEYSEED = prf(SK_d2, Ni | Nr)
where SK_d2 was computed earlier (Section 4.2.1). where SK_d2 was computed earlier (Section 4.2.1).
The keys are derived as follows, unchanged from IKEv2: The keys are derived as follows, unchanged from IKEv2:
skipping to change at page 15, line 7 skipping to change at page 16, line 27
o IDi, IDr. o IDi, IDr.
o SPIi, SPIr. o SPIi, SPIr.
o SAr (the accepted proposal). o SAr (the accepted proposal).
o SK_d. o SK_d.
In addition, the ticket MUST encode a protected ticket expiration In addition, the ticket MUST encode a protected ticket expiration
value. value.
5.2. Ticket Format 5.2. Ticket Format
This document does not specify a ticket format. The following format This document does not specify a mandatory-to-implement or a
(this entire current section) is a RECOMMENDED implementation. The mandatory-to-use ticket format. The following format illustrates a
client SHOULD NOT attempt to decode the ticket. potential ticket implementation.
struct { struct {
opaque key_name[16]; // ASCII, null-terminated opaque key_name[16]; // ASCII, null-terminated
opaque IV[0..255]; // the length (possibly 0) depends opaque IV[0..255]; // the length (possibly 0) depends
// on the encryption algorithm // on the encryption algorithm
[encrypted] struct { [encrypted] struct {
opaque IDi, IDr; // the full payloads opaque IDi, IDr; // the full payloads
opaque SPIi, SPIr; opaque SPIi, SPIr;
opaque SA; // the full payload, returned as SAr opaque SA; // the full payload, returned as SAr
skipping to change at page 15, line 46 skipping to change at page 17, line 20
5.3. Ticket Identity and Lifecycle 5.3. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted, the client MUST delete its stored ticket. an IKE SA is deleted, the client MUST delete its stored ticket.
A ticket is therefore associated with the tuple (IDi, IDr). The A ticket is therefore associated with the tuple (IDi, IDr). The
client MAY however use a ticket to approach other gateways that are client MAY however use a ticket to approach other gateways that are
willing to accept it. How a client discovers such gateways is willing to accept it. How a client discovers such gateways is
outside the scope of this document. outside the scope of this document.
The lifetime included with the ticket in the N(TICKET_OPAQUE) The lifetime of the ticket carried in the N(TICKET_OPAQUE)
notification should be the minimum of the IKE SA lifetime (per the notification should be the minimum of the IKE SA lifetime (per the
gateway's local policy) and its re-authentication time, according to gateway's local policy) and its re-authentication time, according to
[RFC4478]. Even if neither of these is enforced by the gateway, a [RFC4478]. Even if neither of these are enforced by the gateway, a
finite lifetime MUST be specified for the ticket. finite lifetime MUST be specified for the ticket.
6. IANA Considerations 6. IANA Considerations
This document requires a number of IKEv2 notification status types in This document requires a number of IKEv2 notification status types in
Section 4.3, to be registered by IANA. The corresponding registry Section 4.3, to be registered by IANA. The corresponding registry
was established by IANA. was established by IANA.
The document defines a new IKEv2 exchange in Section 4.2. The The document defines a new IKEv2 exchange in Section 4.2. The
corresponding registry was established by IANA. corresponding registry was established by IANA.
skipping to change at page 18, line 26 skipping to change at page 19, line 46
user identity confidentiality for the IKEv2 initiator either. user identity confidentiality for the IKEv2 initiator either.
7.8. Usage of IKE Cookies 7.8. Usage of IKE Cookies
The extension specified in this document eliminates most potential The extension specified in this document eliminates most potential
denial-of-service attacks that the cookie mechanism aims to solve. denial-of-service attacks that the cookie mechanism aims to solve.
However, memory exhaustion remains possible. Therefore the cookie However, memory exhaustion remains possible. Therefore the cookie
mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the
gateway for the IKE_SESSION_RESUME exchange described in Section 4.2. gateway for the IKE_SESSION_RESUME exchange described in Section 4.2.
7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE 7.9. Replay Protection in the IKE_SESSION_RESUME Exchange
A major design goal of the current protocol has been the two-message A major design goal of this protocol extension has been the two-
exchange for session resumption. There is a tradeoff between this message exchange for session resumption. There is a tradeoff between
abbreviated exchange and replay protection. Using our counter-based this abbreviated exchange and replay protection. Using the counter-
solution, an attacker cannot replay a ticket to a gateway that had based replay protection solution, an attacker cannot replay a ticket
seen this same ticket before. However the attacker can attempt to to a gateway that had seen the same ticket before. The counter value
replay a ticket to another gateway, and create intermittent IKE state that is incremented for each ticket usage by the client cannot be
(but no successful establishment of an IKE SA). The standard Cookie modified by an adversary due to the integrity protection being
mechanism can be used to mitigate this risk. applied (see Section 4.2, and note that the SK payload integrity-
protects the entire message, per RFC 4306, Sec. 3.14). The gateway
must only store the most recent counter value once the verification
of the mssage and the ticket was successful.
However, the attacker can attempt to replay a ticket to another
gateway, and create intermittent IKE state (but no successful
establishment of an IKE SA). The standard IKE Cookie mechanism can
be used to mitigate this risk.
8. Acknowledgements 8. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen and Yoav Nir for We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler and
their review of earlier drafts. Yoav Nir for their review of earlier drafts.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
skipping to change at page 20, line 11 skipping to change at page 21, line 39
they both require enhancements to IKEv2 to allow information request, they both require enhancements to IKEv2 to allow information request,
e.g., for a certificate or a ticket. However, the changes required e.g., for a certificate or a ticket. However, the changes required
by the former are fewer since an obtained certificate is valid for 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, any IKE responder that is able to verify them. On the other hand,
short-term certificates, while eliminating the usability issues of short-term certificates, while eliminating the usability issues of
user re-authentication, do not reduce the amount of effort performed user re-authentication, do not reduce the amount of effort performed
by the gateway in failover situations. by the gateway in failover situations.
Appendix B. Change Log Appendix B. Change Log
B.1. -01 B.1. -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.2. -01
Editorial review. Removed 24-hour limitation on ticket lifetime, Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy. lifetime is up to local policy.
B.2. -00 B.3. -00
Initial version. This draft is a selective merge of Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00. draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
 End of changes. 42 change blocks. 
119 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/