|
Hi, Stateless session resumption seems to be a nice solution for
some (most?) of the common IPsec failover cases. I have written the attached
draft which is modeled after the analogous solution for TLS, RFC 4507. I think
it is reasonably complete for a -00 version (other than the non-existent security
considerations) but I'm sure you people will find the holes I have missed. I would appreciate your review of the draft-draft before I
submit it as an I-D. I would be even happier if any of you are willing to join as
coauthors, since there's still a lot to be done. Regards, and happy new year. Yaron |
Network Working Group Y. Sheffer
Internet-Draft Check Point
Intended status: Standards Track January 8, 2007
Expires: July 12, 2007
Stateless Session Resumption for the IKE Protocol
draft-sheffer-ike-session-resumption-00
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 12, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
In many failure cases it is useful to resume an interrupted IKE/IPsec
session. We propose an extension to IKEv2 that allows a client to
establish an IKE SA with a gateway in a highly efficient manner,
utilizing a prior IKE SA. A client can reconnect to a gateway from
which it was disconnected, or else it can migrate to another gateway.
The solution is stateless: no per-client state is required on the
gateway until the IKE SA is reestablished. This is done by retaining
parts of the IKE SA in a protected ticket stored on the client.
Sheffer Expires July 12, 2007 [Page 1]
Internet-Draft IKE Session Resumption January 2007
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Our Approach and Related Work . . . . . . . . . . . . . . 4
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview: Acquiring a Ticket . . . . . . . . . . . . . . . 4
3.2. Overview: Presenting a Ticket . . . . . . . . . . . . . . 5
3.3. Additional Details: Acquiring a Ticket . . . . . . . . . . 6
3.4. Additional Details: Presenting a Ticket . . . . . . . . . 6
3.5. IKE Notifications . . . . . . . . . . . . . . . . . . . . 7
3.6. The New IKE SA . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Deriving the AUTH Values . . . . . . . . . . . . . . . . . 8
3.8. Session Resumption and MOBIKE . . . . . . . . . . . . . . 8
3.9. IKE Cookies . . . . . . . . . . . . . . . . . . . . . . . 8
4. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Sheffer Expires July 12, 2007 [Page 2]
Internet-Draft IKE Session Resumption January 2007
1. 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].
2. Introduction
2.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
put down in [I-D.vidya-ipsec-failover-ps].
Specifically, the proposed extension should allow IPsec sessions to
recover from failures in the remote access scenario, and do it much
more efficiently 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:
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 located at a geographical distance from one
another.
o Recovery from an intermittent connectivity failure ("network
reboot"), where the 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 In the normal case, use only symmetric crypto to minimize CPU
consumption.
o Be stateless, so that the gateway does not need to maintain state
for clients that may have roamed away.
o Provide crypto agility.
o Have no security impact on IKE. Specifically, the solution must
not create new DOS risks.
2.2. Non Goals
The following are non-goals of this solution:
Sheffer Expires July 12, 2007 [Page 3]
Internet-Draft IKE Session Resumption January 2007
o Provide for load balancing among gateways.
o Specify how the client detects the need for failover.
o Allow for trust establishment and/or state synchronization between
gateways.
2.3. Our Approach and Related Work
We propose to maintain IKEv2 state in a "ticket", an opaque data
structure maintained on the client, but one which the client cannot
read or modify. We extend the IKEv2 protocol to allow the client to
request and/or present the ticket. When two gateways are mutually
trusting, one can accept a ticket which was generated earlier by the
other.
This approach is similar to the one taken for TLS session resumption
[RFC4507] with the required adaptations for IKE, e.g. to accommodate
the two-phase protocol structure. We have borrowed heavily from that
specification.
An on-going work [I-D.friedman-ike-short-term-certs] discusses the
use of short-term certificates for client re-authentication. This
has some similarities to the current work, and the following
differences. Short-term certificates require a smaller change to IKE
compared to stateless tickets, since the certificates obtained are
valid for any IKE responder and in fact when they are presented, the
protocol is the "plain vanilla" IKEv2. For the same reason, 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.
3. Protocol Details
We start this section by describing the two typical cases: obtaining
and presenting an IKE ticket. Then we expand on these cases. This
is followed by syntactic details and additional considerations.
3.1. Overview: Acquiring a Ticket
Normally, a client requests a ticket in the third message of IKE (the
first of IKE_AUTH), and receives the ticket when authentication is
complete.
Initiator Responder
----------- -----------
--> IDi, N(TICKET/Request), SA, TSi, TSr
<-- IDr, AUTH, EAP
...
Sheffer Expires July 12, 2007 [Page 4]
Internet-Draft IKE Session Resumption January 2007
<-- AUTH, N(TICKET/Opaque), SA, TSi, TSr
Note that a large number of optional notifications are omitted for
clarity, see [RFC4718] for details. The notifications are defined in
Section 3.5 below.
3.2. Overview: Presenting a Ticket
Following an extended communication failure, the 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.
--> SA, KE, Ni, N(TICKET/Opaque)
If the gateway supports this extension and is willing to accept the
ticket, it responds with:
<-- SA, Nr, N(TICKET/Ack)
The KE payload is omitted in the response, however Ni and Nr are
still used for freshness.
At this point a new IKE SA is created by both parties (see
Section 3.6), and used for the following IKE_AUTH exchange. This IKE
SA is still unauthenticated. Both parties now sign the exchange:
--> IDi, [IDr,] AUTH
<-- IDr, AUTH
See Section 3.7 for the derivation of the AUTH values from the
message bytes, the ticket and the nonce values. The gateway and the
client MUST verify the AUTH values they receive. The new IKE SA only
becomes fully valid once each party has verified the other party's
signature. If either side receives an incorrect AUTH value, it MUST
terminate the protocol.
Alternatively and more efficiently, the IKE_AUTH exchange can be
piggybacked into a CREATE_CHILD_SA exchange:
--> IDi, [IDr,] AUTH, SAi2, Ni2, TSi, TSr [, CP(CFG_REQUEST)]
<-- IDr, AUTH, SAr2, Nr2, TSi, TSr [, CP(CFG_REPLY)]
The Child SA values here (SAi2, Ni2 etc.) should not be confused with
the similar values for the IKE SA. This document only discusses the
values related to the IKE SA.
Sheffer Expires July 12, 2007 [Page 5]
Internet-Draft IKE Session Resumption January 2007
3.3. Additional Details: Acquiring a Ticket
A client MAY request a ticket in the following exchanges:
o In an IKE_AUTH exchange, as described above.
o In a CREATE_CHILD_SA exchange, when it is used to rekey the IKE
SA.
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 expires.
It makes sense to request and use a ticket when IKE is used with non-
EAP forms of authentication. These cases are not defined in the
current document.
The gateway normally grants a ticket using N(TICKET/Opaque). It may
instead use the same message to reply with:
o N(TICKET/Nack), if it refuses to grant a ticket for some reason.
o N(TICKET/Ack), if it cannot grant a ticket immediately, e.g.
because that would make the packet too large. In that case the
client MAY request a ticket later using an Informational exchange,
at any time during the lifetime of the IKE SA.
3.4. Additional Details: Presenting a Ticket
A client MAY initiate a regular (non-ticket) IKE exchange even if it
is in possession of a valid ticket. A client MUST NOT present a
ticket after its lifetime has expired.
If the gateway does not accept the ticket for any reason, it MUST
respond with an N(TICKET/Nack) notification. If the gateway responds
with N(TICKET/Nack), it MUST include the KE payload to allow for a
regular IKE exchange. A client receiving an N(TICKET/Nack)
notification MUST discard the ticket and continue with a full,
regular IKE exchange. It MAY request a new ticket later in the
exchange.
If the gateway responds with a standard IKE_INIT message #2, this may
indicate that the gateway does not implement this extension. In this
case, the client SHOULD NOT discard the ticket.
If the gateway receives a ticket for an IKE SA that is still active,
it SHOULD silently delete the old SA without sending a DELETE
Informational exchange.
If the gateway receives a ticket for an IKE SA that has previously
been terminated on this same gateway, this may indicate inconsistent
Sheffer Expires July 12, 2007 [Page 6]
Internet-Draft IKE Session Resumption January 2007
state between the client and the gateway. The gateway SHOULD respond
with an N(TICKET/Nack) notification and proceed to a full IKE
exchange. A gateway is not required to maintain state for terminated
sessions.
3.5. IKE Notifications
We define a single notification type, TICKET, with a number of
subtypes. The notification number is TBD by IANA. 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. See Section 4.3 for further guidelines
regarding the ticket's lifetime, and Section 4.2 for a recommended
ticket format.
3.6. The New IKE SA
When a ticket is presented, the gateway derives the new IKE SA from
the information contained in the ticket, and the client from its
local store:
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 new exchange. It must be
unchanged, i.e. the gateway MUST verify that this value is
identical to the value encoded in the ticket.
o The IDr value is obtained from the new exchange. The gateway MAY
use the IDr value in the ticket for policy decisions.
o The SPI values are created anew, similarly to a regular IKE
exchange. They are NOT reused from the ticket.
The cryptographic material is refreshed based on the ticket and the
nonce values. The new value of SKEYSEED is derived as follows:
SKEYSEED = prf+(SK_d_old, Ni | Nr)
Sheffer Expires July 12, 2007 [Page 7]
Internet-Draft IKE Session Resumption January 2007
Where SK_d_old is the value retrieved from the ticket.
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.7. Deriving the AUTH Values
The AUTH value is derived similarly to the case of a normal IKE pre-
shared secret.
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 material to be signed is defined exactly as in Sec. 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.
3.8. Session Resumption and MOBIKE
TBD.
3.9. IKE Cookies
The current extension eliminates much of the DOS potential that the
cookie mechanism aims to solve. However memory exhaustion remains a
possible issue. Therefore the cookie mechanism (RFC 4306, Sec. 2.6)
MAY be invoked by the gateway for the modified IKE_INIT exchange
described in Section 3.2 above.
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.
Sheffer Expires July 12, 2007 [Page 8]
Internet-Draft IKE Session Resumption January 2007
4.1. Ticket Contents
The ticket MUST encode at least the following state from the 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.
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
integrity algorithms used for the ticket. These are unrelated to the
transforms defined by the SA payload.
4.3. Ticket Identity and Lifecycle
The ticket is associated with a single IKE SA. In particular, when
the IKE SA is deleted, the client MUST delete its stored ticket.
The ticket is therefore associated with the tuple (IDi, IDr). The
client MAY however use the ticket to approach other gateways that are
likely to accept it. How the client discovers such gateways is
outside the scope of this document.
Sheffer Expires July 12, 2007 [Page 9]
Internet-Draft IKE Session Resumption January 2007
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.
5. IANA Considerations
o Notification type (Section 3.5).
o Notification subtypes (Section 3.5).
6. Security Considerations
TBD. Include at least:
o DOS resistance.
o Authentication of identities.
o Reuse of ticket from a terminated session.
o Strength of the ticket protection stronger than the protected
data.
o Time synchronization between gateways.
7. Change Log
7.1. -00
Initial version.
8. Acknowledgements
We would like to thank Pasi Eronen and Yoav Nir for their review of
early drafts.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Sheffer Expires July 12, 2007 [Page 10]
Internet-Draft IKE Session Resumption January 2007
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
9.2. Informative References
[I-D.friedman-ike-short-term-certs]
Friedman, A., "Short-Term Certificates",
draft-friedman-ike-short-term-certs-01 (work in progress),
December 2006.
[I-D.vidya-ipsec-failover-ps]
Narayanan, V., "IPsec Gateway Failover and Redundancy -
Problem Statement and Goals",
draft-vidya-ipsec-failover-ps-00 (work in progress),
December 2006.
[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.
Author's Address
Yaron Sheffer
Check Point Software Technologies Ltd.
3A Jabotinsky St.
Ramat Gan 52520
Israel
Email: yaronf at checkpoint dot com
Sheffer Expires July 12, 2007 [Page 11]
Internet-Draft IKE Session Resumption January 2007
Full Copyright Statement
Copyright (C) The Internet Society (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 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@xxxxxxxxx
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sheffer Expires July 12, 2007 [Page 12]
Title: Stateless Session Resumption for the IKE Protocol
| TOC |
|
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 12, 2007.
Copyright © The Internet Society (2007).
In many failure cases it is useful to resume an interrupted IKE/IPsec session. We propose an extension to IKEv2 that allows a client to establish an IKE SA with a gateway in a highly efficient manner, utilizing a prior IKE SA. A client can reconnect to a gateway from which it was disconnected, or else it can migrate to another gateway. The solution is stateless: no per-client state is required on the gateway until the IKE SA is reestablished. This is done by retaining parts of the IKE SA in a protected ticket stored on the client.
1.
Requirements Notation
2.
Introduction
2.1.
Goals
2.2.
Non Goals
2.3.
Our Approach and Related Work
3.
Protocol Details
3.1.
Overview: Acquiring a Ticket
3.2.
Overview: Presenting a Ticket
3.3.
Additional Details: Acquiring a Ticket
3.4.
Additional Details: Presenting a Ticket
3.5.
IKE Notifications
3.6.
The New IKE SA
3.7.
Deriving the AUTH Values
3.8.
Session Resumption and MOBIKE
3.9.
IKE Cookies
4.
The IKE Ticket
4.1.
Ticket Contents
4.2.
Ticket Format
4.3.
Ticket Identity and Lifecycle
5.
IANA Considerations
6.
Security Considerations
7.
Change Log
7.1.
-00
8.
Acknowledgements
9.
References
9.1.
Normative References
9.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
| TOC |
The high-level goal of this extension is to become a building block of an overall IPsec failover solution, according to the requirements put down in [I‑D.vidya‑ipsec‑failover‑ps] (Narayanan, V., “IPsec Gateway Failover and Redundancy - Problem Statement and Goals,” December 2006.).
Specifically, the proposed extension should allow IPsec sessions to recover from failures in the remote access scenario, and do it much more efficiently 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:
The proposed solution should additionally meet the following goals:
| TOC |
The following are non-goals of this solution:
| TOC |
We propose to maintain IKEv2 state in a "ticket", an opaque data structure maintained on the client, but one which the client cannot read or modify. We extend the IKEv2 protocol to allow the client to request and/or present the ticket. When two gateways are mutually trusting, one can accept a ticket which was generated earlier by the other.
This approach is similar to the one taken for TLS session resumption [RFC4507] (Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” May 2006.) with the required adaptations for IKE, e.g. to accommodate the two-phase protocol structure. We have borrowed heavily from that specification.
An on-going work [I‑D.friedman‑ike‑short‑term‑certs] (Friedman, A., “Short-Term Certificates,” December 2006.) discusses the use of short-term certificates for client re-authentication. This has some similarities to the current work, and the following differences. Short-term certificates require a smaller change to IKE compared to stateless tickets, since the certificates obtained are valid for any IKE responder and in fact when they are presented, the protocol is the "plain vanilla" IKEv2. For the same reason, 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.
| TOC |
We start this section by describing the two typical cases: obtaining and presenting an IKE ticket. Then we expand on these cases. This is followed by syntactic details and additional considerations.
| TOC |
Normally, a client requests a ticket in the third message of IKE (the first of IKE_AUTH), and receives the ticket when authentication is complete.
Initiator Responder
----------- -----------
--> IDi, N(TICKET/Request), SA, TSi, TSr
<-- IDr, AUTH, EAP
...
<-- AUTH, N(TICKET/Opaque), SA, TSi, TSr
Note that a large number of optional notifications are omitted for clarity, see [RFC4718] (Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” October 2006.) for details. The notifications are defined in Section 3.5 (IKE Notifications) below.
| TOC |
Following an extended communication failure, the 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.
--> SA, KE, Ni, N(TICKET/Opaque)
If the gateway supports this extension and is willing to accept the ticket, it responds with:
<-- SA, Nr, N(TICKET/Ack)
The KE payload is omitted in the response, however Ni and Nr are still used for freshness.
At this point a new IKE SA is created by both parties (see Section 3.6 (The New IKE SA)), and used for the following IKE_AUTH exchange. This IKE SA is still unauthenticated. Both parties now sign the exchange:
--> IDi, [IDr,] AUTH
<-- IDr, AUTH
See Section 3.7 (Deriving the AUTH Values) for the derivation of the AUTH values from the message bytes, the ticket and the nonce values. The gateway and the client MUST verify the AUTH values they receive. The new IKE SA only becomes fully valid once each party has verified the other party's signature. If either side receives an incorrect AUTH value, it MUST terminate the protocol.
Alternatively and more efficiently, the IKE_AUTH exchange can be piggybacked into a CREATE_CHILD_SA exchange:
--> IDi, [IDr,] AUTH, SAi2, Ni2, TSi, TSr [, CP(CFG_REQUEST)]
<-- IDr, AUTH, SAr2, Nr2, TSi, TSr [, CP(CFG_REPLY)]
The Child SA values here (SAi2, Ni2 etc.) should not be confused with the similar values for the IKE SA. This document only discusses the values related to the IKE SA.
| TOC |
A client MAY request a ticket in the following exchanges:
It makes sense to request and use a ticket when IKE is used with non-EAP forms of authentication. These cases are not defined in the current document.
The gateway normally grants a ticket using N(TICKET/Opaque). It may instead use the same message to reply with:
| TOC |
A client MAY initiate a regular (non-ticket) IKE exchange even if it is in possession of a valid ticket. A client MUST NOT present a ticket after its lifetime has expired.
If the gateway does not accept the ticket for any reason, it MUST respond with an N(TICKET/Nack) notification. If the gateway responds with N(TICKET/Nack), it MUST include the KE payload to allow for a regular IKE exchange. A client receiving an N(TICKET/Nack) notification MUST discard the ticket and continue with a full, regular IKE exchange. It MAY request a new ticket later in the exchange.
If the gateway responds with a standard IKE_INIT message #2, this may indicate that the gateway does not implement this extension. In this case, the client SHOULD NOT discard the ticket.
If the gateway receives a ticket for an IKE SA that is still active, it SHOULD silently delete the old SA without sending a DELETE Informational exchange.
If the gateway receives a ticket for an IKE SA that has previously been terminated on this same gateway, this may indicate inconsistent state between the client and the gateway. The gateway SHOULD respond with an N(TICKET/Nack) notification and proceed to a full IKE exchange. A gateway is not required to maintain state for terminated sessions.
| TOC |
We define a single notification type, TICKET, with a number of subtypes. The notification number is TBD by IANA. 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. See Section 4.3 (Ticket Identity and Lifecycle) for further guidelines regarding the ticket's lifetime, and Section 4.2 (Ticket Format) for a recommended ticket format.
| TOC |
When a ticket is presented, the gateway derives the new IKE SA from the information contained in the ticket, and the client from its local store:
The cryptographic material is refreshed based on the ticket and the nonce values. The new value of SKEYSEED is derived as follows:
SKEYSEED = prf+(SK_d_old, Ni | Nr)
Where SK_d_old is the value retrieved from the ticket.
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] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) for the notation. "prf" is determined from the SA value in the ticket.
| TOC |
The AUTH value is derived similarly to the case of a normal IKE pre-shared secret.
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 material to be signed is defined exactly as in Sec. 2.15 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). 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.
| TOC |
TBD.
| TOC |
The current extension eliminates much of the DOS potential that the cookie mechanism aims to solve. However memory exhaustion remains a possible issue. Therefore the cookie mechanism (RFC 4306, Sec. 2.6) MAY be invoked by the gateway for the modified IKE_INIT exchange described in Section 3.2 (Overview: Presenting a Ticket) above.
| TOC |
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.
| TOC |
The ticket MUST encode at least the following state from the IKE SA. These values MUST be encrypted and authenticated.
In addition, the ticket MUST encode a protected ticket expiration value.
| TOC |
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 integrity algorithms used for the ticket. These are unrelated to the transforms defined by the SA payload.
| TOC |
The ticket is associated with a single IKE SA. In particular, when the IKE SA is deleted, the client MUST delete its stored ticket.
The ticket is therefore associated with the tuple (IDi, IDr). The client MAY however use the ticket to approach other gateways that are likely to accept it. How the 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] (Nir, Y., “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol,” April 2006.). 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.
| TOC |
| TOC |
TBD. Include at least:
| TOC |
| TOC |
Initial version.
| TOC |
We would like to thank Pasi Eronen and Yoav Nir for their review of early drafts.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4301] | Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005. |
| [RFC4306] | Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005. |
| TOC |
| [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.vidya-ipsec-failover-ps] | Narayanan, V., “IPsec Gateway Failover and Redundancy - Problem Statement and Goals,” draft-vidya-ipsec-failover-ps-00 (work in progress), December 2006. |
| [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. |
| TOC |
| Yaron Sheffer | |
| Check Point Software Technologies Ltd. | |
| 3A Jabotinsky St. | |
| Ramat Gan 52520 | |
| Israel | |
| Email: | yaronf at checkpoint dot com |
| TOC |
Copyright © The Internet Society (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 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.
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@xxxxxxxx.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).