< draft-sheffer-ipsec-failover-02.txt   draft-sheffer-ipsec-failover-03.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: May 18, 2008 Nokia Siemens Networks Expires: September 20, 2008 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
November 15, 2007 March 19, 2008
IPsec Gateway Failover Protocol IPsec Gateway Failover Protocol
draft-sheffer-ipsec-failover-02.txt draft-sheffer-ipsec-failover-03.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 May 18, 2008. This Internet-Draft will expire on September 20, 2008.
Copyright Notice
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 roundstrips and used for authentication, which adds several more round trips and
therefore latency. 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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. Presenting a Ticket: The DoS Case . . . . . . . . . . 12
4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Requesting a ticket during resumption . . . . . . . . 13
4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 13 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13
4.5. TICKET_COUNTER Notify Payload . . . . . . . . . . . . . . 13 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
4.6. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14 4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
4.7. Processing Guidelines for IKE SA Establishment . . . . . . 15 4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15
5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16
5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 18 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 18 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19
7.6. Alternate Ticket Formats and Distribution Schemes . . . . 19 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 19 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20
7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 19 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
7.9. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 19 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
B.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 increases 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
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 IKEv2 state in the previous one. This document proposes to maintain IKEv2 state in
a "ticket", an opaque data structure created and used by a server and a "ticket", an opaque data structure created and used by a server 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 is extended to allow a client to request
request and present a ticket. When two gateways mutually trust each and present a ticket. When two gateways mutually trust each other,
other, one can accept a ticket generated by the 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
The high-level goal of this extension is to provide an IPsec failover The high-level goal of this extension is to provide an IPsec failover
solution, according to the requirements defined in solution, according to the requirements defined in
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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
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.
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 gateways in the secure any other gateway within the domain. All gateways in the secure
domain are expected to share a security association - either with domain are expected to share some secrets, so that they can
each other or through a trusted third party - so that they can generate an IKEv2 ticket, verify the validity of the ticket and
verify the validity of the ticket and can extract the IKEv2 policy extract the 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 IKEv2 responder 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. stateful session resumption.
3. Usage Scenarios 3. Usage Scenarios
skipping to change at page 8, line 5 skipping to change at page 7, line 47
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 support the assignment of a new IP resumption protocol needs to support the assignment of a new IP
address. 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
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 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 !
! host ! IPsec transport/ ! host ! ! host ! IPsec transport/ ! host !
skipping to change at page 9, line 29 skipping to change at page 9, line 43
A client MAY request a ticket in the following exchanges: A client MAY request a ticket in the following exchanges:
o In an IKE_AUTH exchange, as shown in the example message exchange o In an IKE_AUTH exchange, as shown in the example message exchange
in Figure 3 below. in Figure 3 below.
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
o In an Informational exchange, if the gateway previously replied o In an Informational exchange, if the gateway previously replied
with an N(TICKET_ACK) instead of providing a ticket. with an N(TICKET_ACK) instead of providing a ticket.
o In an Informational exchange, when the ticket lifetime is about to o In an Informational exchange, when the ticket lifetime is about to
expire. expire.
o In an IKE_SESSION_RESUME exchange, see Section 4.2.2. 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 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 (the first of IKE_AUTH). Figure 3 shows the message
exchange for this typical case. exchange for this typical case.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
skipping to change at page 10, line 44 skipping to change at page 11, line 13
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 up to the client's local policy to decide when the It is up to the client's local policy to decide when the
communication with the IKEv2 responder is seen as interrupted and a communication with the IKEv2 responder is seen as interrupted and a
new exchange needs to be initiated and the session resumption new exchange needs to be initiated and the session resumption
procedure to be initiated. 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 This document specifies a new IKEv2 exchange type called
IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
somewhat similar to the IKE_AUTH exchange, and results in the somewhat similar to the IKE_AUTH exchange, and results in the
creation of a Child SA. The client MUST NOT use this exchange unless creation of a Child SA. The client SHOULD NOT use this exchange type
it knows that the gateway supports failover, either through unless it knows that the gateway supports it, either through
configuration, by out-of-band means or by using the Gateway List configuration, by out-of-band means or by using the Gateway List
provision. provision.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,] HDR, 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)]} -->
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)
payload. payload.
The client MUST increment the counter value each time it uses this
same ticket to resume the session. When the gateway receives a
resumption request for a ticket it has seen in the past, it MUST
reject the request unless the counter value is larger than its
previous value.
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 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 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 5.
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 When 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 if the responder accepts it, then the old SAs SHOULD be active and if the responder accepts it, then the old SAs SHOULD be
silently deleted 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 5: 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.7. This is followed by normal derivation of a child SA, Section 4.6. 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.7. 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 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. 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
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 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.7. per the rules described in Section 4.6.
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 Figure 8 | | TICKET_OPAQUE | TBA1 | See Section 4.4 |
| 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 Section 4.5 | | TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 |
| TICKET_GATEWAY_LIST | TBA6 | See Section 4.6 |
+---------------------+--------+-----------------+ +---------------------+--------+-----------------+
4.4. TICKET_OPAQUE Notify Payload 4.4. TICKET_OPAQUE Notify Payload
The data for the TICKET_OPAQUE Notify payload consists of the Notify The data for the TICKET_OPAQUE Notify payload consists of the Notify
message header, a lifetime field and the ticket itself. The four message header, a lifetime field and the ticket itself. The four
octet lifetime field contains the number of seconds until the ticket octet lifetime field contains the number of seconds until the ticket
expires as an unsigned integer. Section 5.2 describes a possible expires as an unsigned integer. Section 5.2 describes a possible
ticket format, and Section 5.3 offers further guidelines regarding ticket format, and Section 5.3 offers further guidelines regarding
the ticket's lifetime. the ticket's lifetime.
skipping to change at page 13, line 28 skipping to change at page 14, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type ! ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Lifetime ! ! Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Ticket ~ ~ Ticket ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: TICKET_OPAQUE Notify Payload Figure 6: TICKET_OPAQUE Notify Payload
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 4.5. TICKET_GATEWAY_LIST Notify Payload
The TICKET_GATEWAY_LIST Notify payload contains the Notify payload The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
header followed by a sequence of one or more gateway identifiers, header followed by a sequence of one or more gateway identifiers,
each of the format depicted in Figure 11. each of the format depicted in Figure 8.
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length ! ! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type ! ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Gateway Identifier List ~ ~ Gateway Identifier List ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TICKET_GATEWAY_LIST Notify Payload Figure 7: TICKET_GATEWAY_LIST Notify Payload
0 1 2 3 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Identification Data ~ ~ Identification Data ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Gateway Identifier for One Gateway Figure 8: Gateway Identifier for One Gateway
ID Type: ID Type:
The ID Type contains a restricted set of the IKEv2 ID payloads The ID Type contains a restricted set of the IKEv2 ID payloads
(see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR, (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR,
ID_IPV6_ADDR, ID_FQDN and the various reserved values. ID_IPV6_ADDR, ID_FQDN and the various reserved values.
Reserved: Reserved:
This field must be sent as 0 and must be ignored when received. This field must be sent as 0 and must be ignored when received.
skipping to change at page 15, line 15 skipping to change at page 15, line 37
Length: Length:
The length field indicates the total size of the Identification The length field indicates the total size of the Identification
data. data.
Identification Data: Identification Data:
The Identification Data field is of variable length and depends on The Identification Data field is of variable length and depends on
the ID type. The length is not necessarily a multiple of 4. the ID type. The length is not necessarily a multiple of 4.
4.7. Processing Guidelines for IKE SA Establishment 4.6. 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
skipping to change at page 16, line 28 skipping to change at page 17, line 8
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 mandatory-to-implement or a This document does not specify a mandatory-to-implement or a
mandatory-to-use ticket format. The following format illustrates a mandatory-to-use ticket format. The following format is RECOMMENDED,
potential ticket implementation. if interoperability between gateways is desired.
struct { struct {
opaque key_name[16]; // ASCII, null-terminated [authenticated] struct {
opaque IV[0..255]; // the length (possibly 0) depends octet format_version; // 1 for this version of the protocol
// on the encryption algorithm 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 { [encrypted] struct {
opaque IDi, IDr; // the full payloads opaque IDi, IDr; // the full payloads
opaque SPIi, SPIr; octet SPIi[8], SPIr[8];
opaque SA; // the full payload, returned as SAr opaque SA; // the full SAr payload
opaque SK_d; octet SK_d[0..255]; // actual length depends on SA value
opaque expiration; // an absolute time value int32 expiration; // an absolute time value, seconds
} ikev2_state; // encrypted and authenticated // since Jan. 1, 1970
opaque MAC[0..255]; // the length (possibly 0) depends } ikev2_state;
// on the integrity algorithm } protected_part;
} ticket; opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm
} ticket;
Note that the key defined by "key_name" determines the encryption and Note that the key defined by "key_id" determines the encryption and
authentication algorithms used for this ticket. Those algorithms are authentication algorithms used for this ticket. Those algorithms are
unrelated to the transforms defined by the SA payload. unrelated to the transforms defined by the SA payload.
The reader is referred to a recent draft The reader is referred to a recent draft
[I-D.rescorla-stateless-tokens] that recommends a similar (but not [I-D.rescorla-stateless-tokens] that recommends a similar (but not
identical) ticket format, and discusses related security identical) ticket format, and discusses related security
considerations in depth. considerations in depth.
5.3. Ticket Identity and Lifecycle 5.3. Ticket Identity and Lifecycle
skipping to change at page 17, line 26 skipping to change at page 18, line 9
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 of the ticket carried 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 are 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.
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 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
skipping to change at page 18, line 16 skipping to change at page 19, line 14
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.
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_id 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).
Section 7.8.
7.4. Ticket Protection Key Management 7.4. Ticket Protection Key Management
A full description of the management of the keys used to protect the 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 ticket is beyond the scope of this document. A list of RECOMMENDED
practices is given below. practices is given below.
o The keys should be generated securely following the randomness o The keys should be generated securely following the randomness
recommendations in [RFC4086]. recommendations in [RFC4086].
o The keys and cryptographic protection algorithms should be at o The keys and cryptographic protection algorithms should be at
least 128 bits in strength. least 128 bits in strength.
skipping to change at page 19, line 38 skipping to change at page 20, line 35
IKE_SESSION_RESUME exchange, confidentiality is not provided for the IKE_SESSION_RESUME exchange, confidentiality is not provided for the
exchange. Although the ticket itself is encrypted there might still exchange. Although the ticket itself is encrypted there might still
be a possibility for an on-path adversary to observe multiple be a possibility for an on-path adversary to observe multiple
exchange handshakes where the same ticket is used and therefore to exchange handshakes where the same ticket is used and therefore to
conclude that they belong to the same communication end points. conclude that they belong to the same communication end points.
Administrators that use the ticket mechanism described in this Administrators that use the ticket mechanism described in this
document should be aware that unlinkability may not be provided by document should be aware that unlinkability may not be provided 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. Replay Protection in the IKE_SESSION_RESUME Exchange
The extension specified in this document eliminates most potential
denial-of-service attacks that the cookie mechanism aims to solve.
However, memory exhaustion remains possible. Therefore the cookie
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.
7.9. Replay Protection in the IKE_SESSION_RESUME Exchange
A major design goal of this protocol extension has been the two- A major design goal of this protocol extension has been the two-
message exchange for session resumption. There is a tradeoff between message exchange for session resumption. There is a tradeoff between
this abbreviated exchange and replay protection. Using the counter- this abbreviated exchange and replay protection. It is RECOMMENDED
based replay protection solution, an attacker cannot replay a ticket that the gateway should cache tickets, and reject replayed ones.
to a gateway that had seen the same ticket before. The counter value However some gateways may not do that in order to reduce state size.
that is incremented for each ticket usage by the client cannot be In addition, an adversary may replay a ticket last presented to
modified by an adversary due to the integrity protection being gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
applied (see Section 4.2, and note that the SK payload integrity- mitigates both scenarios by ensuring that the client presenting the
protects the entire message, per RFC 4306, Sec. 3.14). The gateway ticket is indeed its "owner": the client can be required by the
must only store the most recent counter value once the verification gateway to prove that it knows the ticket's secret, before any state
of the mssage and the ticket was successful. 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.
However, the attacker can attempt to replay a ticket to another For performance reasons, the cookie mechanism is optional, and
gateway, and create intermittent IKE state (but no successful invoked by the gateway only when it suspects that it is the subject
establishment of an IKE SA). The standard IKE Cookie mechanism can of a denial-of-service attack.
be used to mitigate this risk.
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 8. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler and We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
Yoav Nir for their review of earlier drafts. Yoav Nir and Tero Kivinen for their many helpful comments.
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 48 skipping to change at page 21, line 43
[I-D.rescorla-stateless-tokens] [I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-01 (work in Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007. progress), March 2007.
[I-D.vidya-ipsec-failover-ps] [I-D.vidya-ipsec-failover-ps]
Narayanan, V., "IPsec Gateway Failover and Redundancy - Narayanan, V., "IPsec Gateway Failover and Redundancy -
Problem Statement and Goals", Problem Statement and Goals",
draft-vidya-ipsec-failover-ps-02 (work in progress), draft-vidya-ipsec-failover-ps-02 (work in progress),
May 2007. 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.
[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 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
skipping to change at page 21, line 39 skipping to change at page 22, line 42
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. -02 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.
B.2. -02
Clarifications on generation of SPI values, on the ticket's lifetime Clarifications on generation of SPI values, on the ticket's lifetime
and on the integrity protection of the anti-replay counter. and on the integrity protection of the anti-replay counter.
Eliminated redundant SPIs from the notification payloads. Eliminated redundant SPIs from the notification payloads.
B.2. -01 B.3. -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.3. -00 B.4. -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.
skipping to change at page 22, line 28 skipping to change at page 23, line 39
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
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.priv.at
Lakshminath Dondeti Lakshminath Dondeti
QUALCOMM, Inc. QUALCOMM, Inc.
5775 Morehouse Dr 5775 Morehouse Dr
San Diego, CA San Diego, CA
USA USA
Phone: +1 858-845-1267 Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com Email: ldondeti@qualcomm.com
Vidya Narayanan Vidya Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
5775 Morehouse Dr 5775 Morehouse Dr
San Diego, CA San Diego, CA
USA USA
Phone: +1 858-845-2483 Phone: +1 858-845-2483
Email: vidyan@qualcomm.com Email: vidyan@qualcomm.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 23, line 44 skipping to change at line 1057
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 53 change blocks. 
147 lines changed or deleted 196 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/