< draft-sheffer-ipsec-failover-00.txt   draft-sheffer-ipsec-failover-01.txt >
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: April 20, 2008 Nokia Siemens Networks Expires: May 18, 2008 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
October 18, 2007 November 15, 2007
IPsec Gateway Failover Protocol IPsec Gateway Failover Protocol
draft-sheffer-ipsec-failover-00.txt draft-sheffer-ipsec-failover-01.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 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2008. This Internet-Draft will expire on May 18, 2008.
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 is The Internet Key Exchange version 2 (IKEv2) protocol has
computationally intensive with respect to the number of round-trips computational and communication overhead with respect to the number
required and cryptographic operations involved. In remote access of round-trips required and cryptographic operations involved. In
situations, the Extensible Authentication Protocol is used for remote access situations, the Extensible Authentication Protocol is
authentication, which adds additional computational intensity. used for authentication, which adds additional 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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
4.5. Processing Guidelines for IKE SA Establishment . . . . . . 13 4.5. Processing Guidelines for IKE SA Establishment . . . . . . 13
5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 14 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 14 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 14
5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 15 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 16 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 16
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 16 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 17
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 17 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 17
7.6. Alternate Ticket Formats and Distribution Schemes . . . . 17 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 17
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 17 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 17
7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 18 7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 18
7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE . . . 18 7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol is The Internet Key Exchange version 2 (IKEv2) protocol has
computationally intensive with respect to the number of round-trips computational and communication overhead with respect to the number
required and cryptographic operations involved. In particular the of round-trips required and cryptographic operations involved. In
Extensible Authentication Protocol is used for authentication in particular the Extensible Authentication Protocol is used for
remote access cases, which adds additional computational intensity. 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
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. 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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 failure ("network
reboot"), where clients reconnect into the same gateway. In this reboot"), where clients reconnect into the same gateway. In this
case the gateway would typically had detected the clients' absence case, the gateway would typically have detected the clients'
and removed the state associated with them. absence and removed the state 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
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 any able to resume an IKEv2 session that may have been established by
other gateway within the domain. All the gateways in the secure any other gateway within the domain. All the gateways in the
domain are expected to share a security association -- either with secure domain are expected to share a security association -
each other or through a trusted third party -- so they can verify either with each other or through a trusted third party - so that
the validity of the ticket and can extract the IKEv2 policy and they can verify the validity of the ticket and can extract the
session key material from the ticket. IKEv2 policy 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 infrastructure 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
skipping to change at page 7, line 26 skipping to change at page 7, line 26
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! ! IKE_SESSION_RESUME ! ! ! ! IKE_SESSION_RESUME ! !
! Remote !<------------------------>! New/Old ! ! Remote !<------------------------>! New/Old !
! Access ! ! Gateway ! ! Access ! ! Gateway !
! Client !<------------------------>! ! ! Client !<------------------------>! !
! ! IPsec tunnel ! ! ! ! IPsec tunnel ! !
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 1: Remote Access Gateway Failure Figure 1: Remote Access Gateway Failure
In this scenario, an endhost (an entity with a host implementation of In this scenario, an end-host (an entity with a host implementation
IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a gateway of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
in a remote network using IKEv2. The endhost in this scenario is gateway in a remote network using IKEv2. The end-host in this
sometimes referred to as a remote access client. When the remote scenario is sometimes referred to as a remote access client. When
gateway fails, all the clients associated with the gateway either the remote gateway fails, all the clients associated with the gateway
need to re-establish IKEv2 sessions with another gateway within the either need to re-establish IKEv2 sessions with another gateway
same secure domain of the original gateway, or with the original within the same secure domain of the original gateway, or with the
gateway if the server is back online soon. original gateway if the server is back online soon.
The clients may choose to establish IPsec SAs using a full IKEv2 The clients may choose to establish IPsec SAs using a full IKEv2
exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).
In this scenario, the client needs to get an IP address from the In this scenario, the client needs to get an IP address from the
remote network so that traffic can be encapsulated by the remote remote network so that traffic can be encapsulated by the remote
access gateway before reaching the client. In the initial exchange, access gateway before reaching the client. In the initial exchange,
the gateway may acquire IP addresses from the address pool of a local 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 DHCP server. The new gateway that a client gets associated may not
receive addresses from the same address pool. Thus, the session receive addresses from the same address pool. Thus, the session
resumption protocol needs to be able to support for new IP address resumption protocol needs to support the assignment of a new IP
assignment. address.
3.2. Recovering from an Application Server Failover 3.2. Recovering from an Application Server Failover
(a) (a)
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! App. ! IKEv2/IKEv2-EAP ! App. ! ! App. ! IKEv2/IKEv2-EAP ! App. !
! Client !<------------------------>! Server ! ! Client !<------------------------>! Server !
! & ! ! & ! ! & ! ! & !
! IPsec !<------------------------>! IPsec ! ! IPsec !<------------------------>! IPsec !
skipping to change at page 9, line 8 skipping to change at page 9, line 8
The client-server relationship at the application layer ensures that The client-server relationship at the application layer ensures that
one of the entities in this usage scenario is unambiguously always one of the entities in this usage scenario is unambiguously always
the Initiator and the other the Responder. This role determination the Initiator and the other the Responder. This role determination
also allows the Initiator to request an address in the Responder's also allows the Initiator to request an address in the Responder's
network using the Configuration Payload mechanism of the IKEv2 network using the Configuration Payload mechanism of the IKEv2
protocol. If the client has thus received an address during the protocol. If the client has thus received an address during the
initial IKEv2 exchange, when it associates with a new server upon initial IKEv2 exchange, when it associates with a new server upon
failure of the original server, it needs to request an address, failure of the original server, it needs to request an address,
specifying its assigned address. The server may allow the client to specifying its assigned address. The server may allow the client to
use the original address or if it is not permitted to use that use the original address or if it is not permitted to use that
address, assigns a new address. address, assign a new address.
4. Protocol Details 4. Protocol Details
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket and presenting a ticket. Section 4.1 describes requesting a ticket and presenting a ticket. Section 4.1 describes
the procedure to request a ticket and Section 4.2 illustrates how to the procedure to request a ticket and Section 4.2 illustrates how to
present a ticket. present a ticket.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
skipping to change at page 10, line 47 skipping to change at page 10, line 47
lifetime has expired. lifetime has expired.
It is purely a local decision of the client when and based on what It is purely a local decision of the client when and based on what
information to decide that a communication failure has happened and information to decide that a communication failure has happened and
that a new exchange including the ticket is needed. that a new exchange including the ticket is needed.
We specify a new IKEv2 exchange type called IKE_SESSION_RESUME whose We specify a new IKEv2 exchange type called IKE_SESSION_RESUME whose
value is TBA by IANA. This exchange is somewhat similar to the 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 IKE_AUTH exchange, and results in the creation of a Child SA. The
client MUST NOT use this exchange unless it knows that the gateway client MUST NOT use this exchange unless it knows that the gateway
supports failover, either through configuration or by using the supports failover, either through configuration, by out-of-band means
Gateway List provision. 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 33 skipping to change at page 11, line 33
payload it MUST perform one of the following steps if it supports the payload it MUST perform one of the following steps if it supports the
extension defined in this document: extension defined in this document:
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 If 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 accepts it, it SHOULD silently delete the old SA
without sending a DELETE Informational exchange. 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
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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 MUST NOT be reused. exchange. SPI values from the ticket SHOULD NOT be reused.
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 16 skipping to change at page 15, line 16
This document does not specify a ticket format. The following format This document does not specify a ticket format. The following format
(this entire current section) is a RECOMMENDED implementation. The (this entire current section) is a RECOMMENDED implementation. The
client SHOULD NOT attempt to decode the ticket. client SHOULD NOT attempt to decode the ticket.
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
[protected] 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
opaque SK_d; opaque SK_d;
opaque expiration; // an absolute time value opaque expiration; // an absolute time value
} ikev2_state; // encrypted and authenticated } ikev2_state; // encrypted and authenticated
opaque MAC[0..255]; // the length (possibly 0) depends opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
skipping to change at page 15, line 50 skipping to change at page 15, line 50
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 included with the ticket 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 is enforced by the gateway, a
finite lifetime MUST be specified for the ticket and SHOULD be less finite lifetime MUST be specified for the ticket.
than 24 hours.
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.
7. Security Considerations 7. Security Considerations
This section addresses security issues related to the usage of a This section addresses security issues related to the usage of a
ticket. ticket.
7.1. Stolen Tickets 7.1. Stolen Tickets
An eavesdropper or man-in-the-middle may try to obtain a ticket and An eavesdropper or man-in-the-middle may try to obtain a ticket and
use it to establish a session with the IKEv2 responder. However, use it to establish a session with the IKEv2 responder. This can
since the ticket is encrypted and the attacker does not know the happen in different ways: by eavesdropping on the initial
corresponding secret key (specifically, SK_d), a stolen ticket cannot communication and copying the ticket when it is granted and before it
be used by an attacker to resume a session. An IKEv2 responder MUST is used, or by listening in on a client's use of the ticket to resume
use strong encryption and integrity protection for the ticket to a session. However, since the ticket's contents is encrypted and the
prevent an attacker from obtaining the ticket's contents, e.g., by attacker does not know the corresponding secret key (specifically,
using a brute force attack. 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.
7.2. Forged Tickets 7.2. Forged Tickets
A malicious user could forge or alter a ticket in order to resume a 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 session, to extend its lifetime, to impersonate as another user, or
to gain additional privileges. This attack is not possible if the to gain additional privileges. This attack is not possible if the
ticket is protected using a strong integrity protection algorithm ticket is protected using a strong integrity protection algorithm.
such as a keyed HMAC-SHA1.
7.3. Denial of Service Attacks 7.3. Denial of Service Attacks
The key_name field defined in the recommended ticket format helps the The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an server efficiently reject tickets that it did not issue. However, an
adversary could generate and send a large number of tickets to a adversary could generate and send a large number of tickets to a
gateway for verification. To minimize the possibility of such denial gateway for verification. To minimize the possibility of such denial
of service, ticket verification should be lightweight (e.g., using of service, ticket verification should be lightweight (e.g., using
efficient symmetric key cryptographic algorithms). See also efficient symmetric key cryptographic algorithms). See also
Section 7.8. Section 7.8.
skipping to change at page 17, line 51 skipping to change at page 18, line 7
prevent a breach in the security of the system. prevent a breach in the security of the system.
7.7. Identity Privacy, Anonymity, and Unlinkability 7.7. Identity Privacy, Anonymity, and Unlinkability
This document mandates that the content of the ticket MUST be This document mandates that the content of the ticket MUST be
encrypted in order to avoid leakage of information, such as the encrypted in order to avoid leakage of information, such as the
identities of an IKEv2 initiator and a responder. Thus, it prevents identities of an IKEv2 initiator and a responder. Thus, it prevents
the disclosure of potentially sensitive information carried within the disclosure of potentially sensitive information carried within
the ticket. the ticket.
When an IKEv2 initiator presents the ticket as part of the first When an IKEv2 initiator presents the ticket as part of the
message of the IKE_SA_INIT exchange, confidentiality is not provided IKE_SESSION_RESUME exchange, confidentiality is not provided for the
for the exchange. Although the ticket itself is encrypted there exchange. Although the ticket itself is encrypted there might still
might still be a possibility for an on-path adversary to observe be a possibility for an on-path adversary to observe multiple
multiple exchange handshakes where the same ticket is used and exchange handshakes where the same ticket is used and therefore to
therefore to conclude that they belong to the same communication end conclude that they belong to the same communication end points.
points. Administrators that use the ticket mechanism described in Administrators that use the ticket mechanism described in this
this document should be aware that unlinkability may not be provided document should be aware that unlinkability may not be provided by
by this mechanism. Note, however, that IKEv2 does not provide active this mechanism. Note, however, that IKEv2 does not provide active
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.
skipping to change at page 20, line 9 skipping to change at page 20, line 11
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. -00 B.1. -01
Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy.
B.2. -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.
Tel Aviv 67897 Tel Aviv 67897
Israel Israel
Email: yaronf@checkpoint.com Email: yaronf@checkpoint.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
 End of changes. 24 change blocks. 
63 lines changed or deleted 70 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/