Network Working Group Y. Sheffer
Internet-Draft Check Point
Intended status: Standards Track H. Tschofenig
Expires: July 23, 2007 Siemens Networks GmbH & Co KG
T. Wan
Nortel
January 19, 2007
Stateless Session Resumption for the IKE Protocol
draft-sheffer-ike-session-resumption-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Internet Key Exchange version 2 (IKEv2) protocol is
computationally intensive with respect to the number of round-trips
required and cryptographic operations involved. In particular the
Extensible Authentication Protocol is used for authentication, which
adds additional computational intensity.
Sheffer, et al. Expires July 23, 2007 [Page 1]
Internet-Draft IKE Session Resumption January 2007
To re-establish security associations (SA) upon a failure recovery
condition is time comsuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA restablishment.
In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously
establied IKE SA.
A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with
the previous one. The proposed approach conveys IKEv2 state
information, in the form of an encrypted ticket, to a VPN client that
is later presented to the VPN gateway for re-authentication. An
encrypted ticket cannot be decrypted by a VPN client but allows a VPN
gateway to restore state for faster session state setup.
Sheffer, et al. Expires July 23, 2007 [Page 2]
Internet-Draft IKE Session Resumption January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 5
3.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 7
3.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 9
3.4. Processing Guidelines for IKE SA Establishment . . . . . . 9
3.5. Computing the AUTH Payload . . . . . . . . . . . . . . . . 10
4. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 10
4.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
6.4. Ticket Protection Key Management . . . . . . . . . . . . . 12
6.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
6.6. Alternate Ticket Formats and Distribution Schemes . . . . 13
6.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13
6.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15
B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Sheffer, et al. Expires July 23, 2007 [Page 3]
Internet-Draft IKE Session Resumption January 2007
1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol is
computationally intensive with respect to the number of round-trips
required and cryptographic operations involved. In particular the
Extensible Authentication Protocol is used for authentication, which
adds additional computational intensity.
To re-establish security associations (SA) upon a failure recovery
condition is time-consuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer.
In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously
establied IKE SA.
A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with
the previous one. This document proposes to maintain an IKEv2 state
in a "ticket", an opaque data structure created and used by a server
and stored by a client, which the client cannot understand or tamper
with. The IKEv2 protocol needs to be extended to allow a client to
request and present a ticket. When two gateways mutually trust each
other, one can accept a ticket generated by the other.
This approach is similar to the one taken by TLS session resumption
[RFC4507] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed
heavily from that specification.
1.1. Goals
The high-level goal of this extension is to become a building block
of an overall IPsec failover solution, according to the requirements
defined in [I-D.vidya-ipsec-failover-ps].
Specifically, the proposed extension should allow IPsec sessions to
be recovered from failures in remote access scenarios, in a more
efficient manner than the basic IKE solution. This efficiency is
primarily on the gateway side, since the gateway might have to deal
with many thousands of concurrent requests. We should enable the
following cases:
Sheffer, et al. Expires July 23, 2007 [Page 4]
Internet-Draft IKE Session Resumption January 2007
o Failover from one gateway to another, where the two gateways do
not share state but do have mutual trust. For example, the
gateways may be operated by the same provider and share the same
keying materials to access an encrypted ticket.
o Recovery from an intermittent connectivity failure ("network
reboot"), where clients reconnect into the same gateway. In this
case the gateway would typically had detected the clients' absence
and removed the state associated with them.
o Recovery from a gateway restart, where clients reconnect into the
same gateway.
The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption.
o Allowing a gateway to push state to clients.
o Providing cryptographic agility.
o Having no negative impact on IKEv2 security features.
Specifically, the solution must not introduce new security
vulnerabilities, such as denial-of-service.
1.2. Non-Goals
The following are non-goals of this solution:
o Providing load balancing among gateways.
o Specifying how a client detects the need for a failover.
o Establishing trust among gateways.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Protocol Details
This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely
requesting a ticket and presenting a ticket. Section 3.1 describes
the procedure to request a ticket and Section 3.2 illustrates how to
present a ticket.
3.1. Requesting a Ticket
A client MAY request a ticket in the following exchanges:
Sheffer, et al. Expires July 23, 2007 [Page 5]
Internet-Draft IKE Session Resumption January 2007
o In an IKE_AUTH exchange, as shown in the example message exchange
in Figure 1 below.
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
o In an Informational exchange, if the gateway previously replied
with an N(TICKET/Ack) instead of providing a ticket.
o In an Informational exchange, when the ticket lifetime is about to
expire.
Normally, a client requests a ticket in the third message of an IKEv2
(the first of IKE_AUTH). Figure 1 shows the message exchange for
this typical case.
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET/Request)} -->
Figure 1: Example Message Exchange for Requesting a Ticket
The notification payloads are described in Section 3.3. For
editorial reasons a number of IKEv2-specific details are omitted. A
complete description of IKEv2 can be found in [RFC4718].
When an IKEv2 responder receives a request for a ticket using the
N(TICKET/Request) payload it MUST perform one of the following
operations if it supports the extension defined in this document:
o it creates a ticket and returns it with the N(TICKET/Opaque)
payload in a subsequent message towards the IKEv2 initiator. This
exchange is shown in Figure 2.
o it returns an N(TICKET/Nack) payload, if it refuses to grant a
ticket for some reason.
o it returns an N(TICKET/Ack), if it cannot grant a ticket
immediately, e.g., due to packet size limitations. In this case
the client MAY request a ticket later using an Informational
exchange, at any time during the lifetime of the IKE SA.
The IKEv2 initiator receives the requested ticket if the IKEv2
exchange was successful, and the ticket later be used with an IKEv2
responder which supports this extension. The ticket exchange is
shown in Figure 2
Sheffer, et al. Expires July 23, 2007 [Page 6]
Internet-Draft IKE Session Resumption January 2007
Initiator Responder
----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, N(TICKET/Opaque)}
Figure 2: Receiving a Ticket
3.2. Presenting a Ticket
Following a communication failure, a client re-initiates an IKE
exchange to the same gateway or to a different one, and includes a
ticket in the first message of IKE_SA_INIT. A client MAY initiate a
regular (non-ticket-based ) IKEv2 exchange even if it is in
possession of a valid ticket. A client MUST NOT present a ticket
after the ticket's lifetime has expired.
It is purely a local decision of the client when and based on what
information to decide that a communication failure has happened and
that a new exchange including the ticket is needed.
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni, 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
extension defined in this document:
o It responds with an N(TICKET/Ack), if it supports this extension
and is willing to accept the ticket. This message is shown in
Figure 4.
o It responds with an N(TICKET/Nack) notification, if it does not
accept the ticket for any reason. The responder SHOULD respond
with a regular IKE_INIT message #2 including the said
notification, and the two IKEv2 peers SHOULD continue with a full,
regular IKE exchange. One such case is when the responder
receives a ticket for an IKE SA that has previously been
terminated on the responder itself, which may indicate
inconsistent state between the IKEv2 initiator and the responder.
However a responder is not required to maintain the state for
terminated sessions.
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
without sending a DELETE Informational exchange.
If the responder replies with a standard IKE_INIT message #2 then the
Sheffer, et al. Expires July 23, 2007 [Page 7]
Internet-Draft IKE Session Resumption January 2007
initiator can assume that the responder does not implement the
extension described in this document.
Initiator Responder
----------- -----------
<-- HDR, SAr1, Nr, N(TICKET/Ack)
Figure 4: IKEv2 Responder responds with N(TICKET/Ack)
The KE payload is omitted in the response, but Ni and Nr are still
exchanged to assure the freshness of subsequently derived keying
materials.
At this point a new IKE SA is created by both parties (see
Section 3.4), and used for the following IKE_AUTH exchange. Both
parties thereby exchange AUTH payloads, as shown below:
Initiator Responder
----------- -----------
--> HDR, SK {IDi, [IDr,] AUTH}
<-- HDR, SK {IDr, AUTH}
Figure 5: A Stand-Alone IKE_AUTH Exchange
See Section 3.5 for the derivation of the AUTH values from the
message bytes, the ticket and the nonce values. The initator and the
responder MUST verify the AUTH values they receive. The new IKE SA
only becomes fully valid if both parties have verified each other's
AUTH payload. If either side receives an incorrect AUTH value, it
MUST terminate the protocol.
the IKE_AUTH exchange can also be piggybacked into a CREATE_CHILD_SA
exchange, as shown in Figure 6. It is up to the client to decide
whether to piggyback the exchange.
--> HDR, SK {IDi, [IDr,] AUTH, SAi2, Ni2, TSi, TSr [, CP(CFG_REQUEST)]}
<-- HDR, SK {IDr, AUTH, SAr2, Nr2, TSi, TSr [, CP(CFG_REPLY)]}
Figure 6: IKE_AUTH piggybacked on top of a CREATE_CHILD_SA exchange
Sheffer, et al. Expires July 23, 2007 [Page 8]
Internet-Draft IKE Session Resumption January 2007
3.3. IKE Notifications
This document defines a single notification type, TICKET, with a
number of subtypes. The notification number is TBD and the subtypes
are listed below:
+--------------+---------+-----------+
| Subtype Name | Number | Data |
+--------------+---------+-----------+
| Opaque | 1 | See below |
| Request | 2 | None |
| Ack | 3 | None |
| Nack | 4 | None |
| Reserved | 5-127 | |
| Private Use | 128-255 | |
+--------------+---------+-----------+
The data for the Opaque subtype consists of a lifetime duration in
seconds (4 octets, denoting the time until the ticket expires),
followed by the ticket content. See Section 4.3 for further
guidelines regarding the ticket's lifetime, and Section 4.2 for a
recommended ticket format.
3.4. Processing Guidelines for IKE SA Establishment
When a ticket is presented, the gateway parses the ticket to retrieve
the state of the old IKE SA, and the client retrieves this state from
its local store. Both peers now create state for the new IKE SA as
follows:
o The SA value (transforms etc.) is taken directly from the ticket.
o The sequence numbers are reset to 0.
o The IDi value is obtained from the ticket.
o The IDr value is obtained from the new exchange. The gateway MAY
make policy decisions based on the IDr value encoded in the
ticket.
o The SPI values are created anew, similarly to a regular IKE
exchange. SPI values from the ticket MUST NOT be reused.
The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows:
SKEYSEED = prf+(SK_d_old, Ni | Nr)
where SK_d_old is the value retrieved from the ticket.
Sheffer, et al. Expires July 23, 2007 [Page 9]
Internet-Draft IKE Session Resumption January 2007
The keys are derived as follows, unchanged from IKEv2:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
where SPIi, SPIr are the SPI values created in the new IKE exchange.
See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket.
3.5. Computing the AUTH Payload
The value for the AUTH payload is derived in a manner similar to the
usage of IKEv2 pre-shared secret-based authentication, as shown
below:
AUTH = prf(SK_px, <msg octets>)
Each of the initiator and responder uses its own SK_p value, taken
from the newly generated IKE SA.
The exact material to be signed is defined in Section 2.15 of
[RFC4306]. The notation "IDr'" in RFC 4306 should be applied to the
new IDr value included in the exchange, rather than the value in the
ticket.
4. The IKE Ticket
This section lists the required contents of the ticket, and
recommends a non-normative format. This is followed by a discussion
of the ticket's lifecycle.
4.1. Ticket Contents
The ticket MUST encode at least the following state from an IKE SA.
These values MUST be encrypted and authenticated.
o IDi, IDr.
o SPIi, SPIr.
o SAr (the accepted proposal).
o SK_d.
In addition, the ticket MUST encode a protected ticket expiration
value.
Sheffer, et al. Expires July 23, 2007 [Page 10]
Internet-Draft IKE Session Resumption January 2007
4.2. Ticket Format
This document does not specify a ticket format. The following format
(this entire current section) is a RECOMMENDED implementation. The
client SHOULD NOT attempt to decode the ticket.
struct {
opaque key_name[16]; // ASCII, null-terminated
opaque IV[0..255]; // the length (possibly 0) depends
// on the encryption algorithm
[protected] struct {
opaque IDi, IDr; // the full payloads
opaque SPIi, SPIr;
opaque SA; // the full payload, returned as SAr
opaque SK_d;
opaque expiration; // an absolute time value
} ikev2_state; // encrypted and authenticated
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
authentication algorithms used for this ticket. Those algorithms are
unrelated to the transforms defined by the SA payload.
The reader is referred to a recent draft
[I-D.rescorla-stateless-tokens] that recommends a similar (but not
identical) ticket format, and discusses related security
considerations in depth.
4.3. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted, the client MUST delete its stored ticket.
A ticket is therefore associated with the tuple (IDi, IDr). The
client MAY however use a ticket to approach other gateways that are
willing to accept it. How a client discovers such gateways is
outside the scope of this document.
The lifetime included with the ticket in the N(TICKET/Opaque)
notification should be the minimum of the IKE SA lifetime (per the
gateway's local policy) and its re-authentication time, according to
[RFC4478]. Even if neither of these is enforced by the gateway, a
finite lifetime MUST be specified for the ticket and SHOULD be less
than 24 hours.
Sheffer, et al. Expires July 23, 2007 [Page 11]
Internet-Draft IKE Session Resumption January 2007
5. IANA Considerations
This document requires the following notifications to be registered
by IANA. The corresponding registry was established by IANA.
o Notification type (Section 3.3).
o Notification subtypes (Section 3.3).
6. Security Considerations
This section addresses security issues related to the usage of a
ticket.
6.1. Stolen Tickets
An eavesdropper or man-in-the-middle may try to obtain a ticket and
use it to establish a session with the IKEv2 responder. However,
since the ticket is encrypted and the attacker does not know the
corresponding secret key (specifically, SK_d), a stolen ticket cannot
be used by an attacker to resume a session. An IKEv2 responder MUST
use strong encryption and integrity protection for the ticket to
prevent an attacker from obtaining the ticket's contents, e.g., by
using a brute force attack.
6.2. Forged Tickets
A malicious user could forge or alter a ticket in order to resume a
session, to extend its lifetime, to impersonate as another user, or
to gain additional privileges. This attack is not possible if the
ticket is protected using a strong integrity protection algorithm
such as a keyed HMAC-SHA1.
6.3. Denial of Service Attacks
The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an
adversary could generate and send a large number of tickets to a
gateway for verification. To minimize the possibility of such denial
of service, ticket verification should be lightweight (e.g., using
efficient symmetric key cryptographic algorithms). See also
Section 6.8.
6.4. Ticket Protection Key Management
A full description of the management of the keys used to protect the
ticket is beyond the scope of this document. A list of RECOMMENDED
practices is given below.
Sheffer, et al. Expires July 23, 2007 [Page 12]
Internet-Draft IKE Session Resumption January 2007
o The keys should be generated securely following the randomness
recommendations in [RFC4086].
o The keys and cryptographic protection algorithms should be at
least 128 bits in strength.
o The keys should not be used for any other purpose than generating
and verifying tickets.
o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic
protection algorithms change.
6.5. Ticket Lifetime
An IKEv2 responder controls the lifetime of a ticket, based on the
operational and security requirements of the environment in which it
is deployed. The responder provides information about the ticket
lifetime to the IKEv2 initiator, allowing it to manage its tickets.
An IKEv2 client may present a ticket in its possession to a gateway,
even if the IKE SA associated with this ticket had previously been
terminated by another gateway (the gateway that originally provided
the ticket). Where such usage is against the local security policy,
an Invalid Ticket List (ITL) may be used, see
[I-D.rescorla-stateless-tokens]. Management of such lists is outside
the scope of the current document. Note that a policy that requires
tickets to have shorter lifetimes (e.g., 1 hour) significantly
mitigates this risk.
6.6. Alternate Ticket Formats and Distribution Schemes
If the ticket format or distribution scheme defined in this document
is not used, then great care must be taken in analyzing the security
of the solution. In particular, if confidential information, such as
a secret key, is transferred to the client, it MUST be done using
secure communication to prevent attackers from obtaining or modifying
the key. Also, the ticket MUST have its integrity and
confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system.
6.7. Identity Privacy, Anonymity, and Unlinkability
This document mandates that the content of the ticket MUST be
encrypted in order to avoid leakage of information, such as the
identities of an IKEv2 initiator and a responder. Thus, it prevents
the disclosure of potentially sensitive information carried within
the ticket.
When an IKEv2 initiator presents the ticket as part of the first
message of the IKE_SA_INIT exchange, confidentiality is not provided
Sheffer, et al. Expires July 23, 2007 [Page 13]
Internet-Draft IKE Session Resumption January 2007
for the exchange. Althought the ticket itself is encrypted there
might still be a possibility for an on-path adversary to observe
multiple exchange handshakes where the same ticket is used and
therefore to conclude that they belong to the same communication end
points. Administrators that use the ticket mechanism described in
this document should be aware that unlinkability may not be provided
by this mechanism. Note, however, that IKEv2 does not provide active
user identity confidentiality for the IKEv2 initiator either.
6.8. Usage of IKE Cookies
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 modified IKE_INIT exchange described in Section 3.2.
7. Acknowledgements
We would like to thank Pasi Eronen and Yoav Nir for their review of
early drafts.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2. Informative References
[I-D.friedman-ike-short-term-certs]
Friedman, A., "Short-Term Certificates",
draft-friedman-ike-short-term-certs-01 (work in progress),
December 2006.
[I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-00 (work in
progress), January 2007.
[I-D.vidya-ipsec-failover-ps]
Narayanan, V., "IPsec Gateway Failover and Redundancy -
Sheffer, et al. Expires July 23, 2007 [Page 14]
Internet-Draft IKE Session Resumption January 2007
Problem Statement and Goals",
draft-vidya-ipsec-failover-ps-00 (work in progress),
December 2006.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
Appendix A. Related Work
[I-D.friedman-ike-short-term-certs] is on-going work that discusses
the use of short-term certificates for client re-authentication. It
is similar to the ticket approach described in this document in that
they both require enhancements to IKEv2 to allow information request,
e.g., for a certificate or a ticket. However, the changes required
by the former are fewer since an obtained certificate is valid for
any IKE responder that is able to verify them. On the other hand,
short-term certificates, while eliminating the usability issues of
user re-authentication, do not reduce the amount of effort performed
by the gateway in failover situations.
Appendix B. Change Log
B.1. -00
Initial version.
Sheffer, et al. Expires July 23, 2007 [Page 15]
Internet-Draft IKE Session Resumption January 2007
Authors' Addresses
Yaron Sheffer
Check Point Software Technologies Ltd.
3A Jabotinsky St.
Ramat Gan 52520
Israel
Email: yaronf at checkpoint dot com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Tao Wan
Nortel Networks
250 Sidney Street
Belleville, Ontario K8N 5B7
Canada
Phone: +1 613 961 2350
Email: twan (at) nortel (dot) com
Sheffer, et al. Expires July 23, 2007 [Page 16]
Internet-Draft IKE Session Resumption January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sheffer, et al. Expires July 23, 2007 [Page 17]