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, ) 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]