[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Statless IKE session resumption



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 
Network Working GroupY. Sheffer
Internet-DraftCheck Point
Intended status: Standards TrackJanuary 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 © 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.



Table of Contents

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 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Introduction



 TOC 

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] (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 

2.2.  Non Goals

The following are non-goals of this solution:



 TOC 

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] (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 

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.



 TOC 

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
                            ...
                                <-- 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 

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 (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 

3.3.  Additional Details: Acquiring a Ticket

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 

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 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 

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 NameNumberData
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 

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:

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 

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] (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 

3.8.  Session Resumption and MOBIKE

TBD.



 TOC 

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 (Overview: Presenting a Ticket) above.



 TOC 

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.



 TOC 

4.1.  Ticket Contents

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 

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.



 TOC 

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.

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 

5.  IANA Considerations



 TOC 

6.  Security Considerations

TBD. Include at least:



 TOC 

7.  Change Log



 TOC 

7.1.  -00

Initial version.



 TOC 

8.  Acknowledgements

We would like to thank Pasi Eronen and Yoav Nir for their review of early drafts.



 TOC 

9.  References



 TOC 

9.1. Normative References

[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 

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.


 TOC 

Author's Address

  Yaron Sheffer
  Check Point Software Technologies Ltd.
  3A Jabotinsky St.
  Ramat Gan 52520
  Israel
Email:  yaronf at checkpoint dot com


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment