Add.

1 files changed, 672 insertions, 0 deletions

diff --git a/doc/protocol/draft-salowey-tls-ticket-03.txt b/doc/protocol/draft-salowey-tls-ticket-03.txt
new file mode 100644
index 0000000000..b7d694e3a1
--- /dev/null
+++ b/doc/protocol/draft-salowey-tls-ticket-03.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                                         J. Salowey
+Internet-Draft                                                   H. Zhou
+Expires: January 16, 2006                                  Cisco Systems
+                                                               P. Eronen
+                                                                   Nokia
+                                                           H. Tschofenig
+                                                                 Siemens
+                                                           July 15, 2005
+
+
+ Transport Layer Security Session Resumption without Server-Side State
+                    draft-salowey-tls-ticket-03.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 January 16, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a mechanism which enables the Transport Layer
+   Security (TLS) server to resume sessions and avoid keeping per-client
+   session state.  The TLS server encapsulates the session state into a
+   ticket and forwards it to the client.  The client can subsequently
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 1]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+   resume a session using the obtained ticket.  This mechanism makes use
+   of new TLS handshake messages and TLS hello extensions.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
+     3.3   Format of NewSessionTicket handshake message . . . . . . .  5
+   4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
+     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
+     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
+     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
+     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
+     8.2   Informative References . . . . . . . . . . . . . . . . . .  9
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
+       Intellectual Property and Copyright Statements . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 2]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+1.  Introduction
+
+   This document defines a way to resume a Transport Layer Security
+   (TLS) [RFC2246]session without requiring session-specific state at
+   the TLS server.  This mechanism may be used with any TLS ciphersuite.
+   The mechanism makes use of TLS extensions defined in [RFC3546] and
+   defines a new TLS message type.
+
+   This mechanism is useful in the following types of situations
+      (1) servers that handle a large number of transactions from
+      different users
+      (2) servers that desire to cache sessions for a long time
+      (3) ability to load balance requests across servers
+      (4) embedded servers with little memory
+
+2.  Terminology
+
+   Within this document the term 'ticket' refers to a cryptographically
+   protected data structure which is created by the server and consumed
+   by the server to rebuild session specific state.
+
+   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
+
+3.1  Overview
+
+   The client indicates that it supports this mechanism by including an
+   empty SessionTicket TLS extension in the ClientHello message.
+
+   If the server wants to use this mechanism, it stores its session
+   state (such as ciphersuite and master secret) to a ticket that is
+   encrypted and integrity-protected by a key known only to the server.
+   The ticket is distributed to the client using the NewSessionTicket
+   TLS handshake message.  This message is sent during the TLS handshake
+   before the ChangeCipherSpec message after the server has verified the
+   client's Finished message.
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 3]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+         Client                                               Server
+
+         ClientHello                   -------->
+        (empty SessionTicket extension)
+                                                         ServerHello
+                                                        Certificate*
+                                                  ServerKeyExchange*
+                                                 CertificateRequest*
+                                      <--------      ServerHelloDone
+         Certificate*
+         ClientKeyExchange
+         CertificateVerify*
+         [ChangeCipherSpec]
+         Finished                     -------->
+                                                  NewSessionTicket
+                                                  [ChangeCipherSpec]
+                                      <--------             Finished
+         Application Data             <------->     Application Data
+
+   The client caches this ticket along with the master secret, session
+   ID and other parameters associated with the current session.  When
+   the client wishes to resume the session, it includes a SessionTicket
+   TLS extension in the SessionTicket extension within ClientHello
+   message.  The server then verifies that the ticket has not been
+   tampered with, decrypts the contents, and retrieves the session state
+   from the contents of the ticket and uses this state to resume the
+   session.  Since separate fields in the request are used for the
+   session ID and the ticket standard stateful session resume can co-
+   exist with the ticket based session resume described in this
+   specification.
+
+
+         ClientHello
+         (SessionTicket extension)      -------->
+                                                          ServerHello
+                                                   [ChangeCipherSpec]
+                                       <--------             Finished
+         [ChangeCipherSpec]
+         Finished                      -------->
+         Application Data              <------->     Application Data
+
+   Since the ticket is typically interpreted by the same server or group
+   of servers that created it, the exact format of the ticket does not
+   need to be the same for all implementations.  A sample ticket format
+   is given in Section 4.  If the server cannot or does not want to
+   honor the ticket then it can initiate a full handshake with the
+   client.
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 4]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+   It is possible that the session ticket and master session key could
+   be delivered through some out of band mechanism.  This behavior is
+   beyond the scope of the document and would need to be described in a
+   separate specification.
+
+3.2  Format of SessionTicket TLS extension
+
+   The format of the ticket is an opaque structure used to carry session
+   specific state information.
+
+
+      struct {
+          opaque ticket<0..2^16-1>;
+      } SessionTicket;
+
+
+3.3  Format of NewSessionTicket handshake message
+
+   This message is sent during the TLS handshake before the
+   ChangeCipherSpec message after the server has verified the client's
+   Finished message.
+
+
+      struct {
+          HandshakeType msg_type;
+          uint24 length;
+          select (HandshakeType) {
+              case hello_request:       HelloRequest;
+              case client_hello:        ClientHello;
+              case server_hello:        ServerHello;
+              case certificate:         Certificate;
+              case server_key_exchange: ServerKeyExchange;
+              case certificate_request: CertificateRequest;
+              case server_hello_done:   ServerHelloDone;
+              case certificate_verify:  CertificateVerify;
+              case client_key_exchange: ClientKeyExchange;
+              case finished:            Finished;
+              case new_session_ticket:  NewSessionTicket; /* NEW */
+          } body;
+      } Handshake;
+
+
+      struct {
+          opaque ticket<0..2^16-1>;
+      } NewSessionTicket;
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 5]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+4.  Sample ticket construction
+
+   This section describes one possibility how the ticket could be
+   constructed, other implementations are possible.
+
+   The server uses two keys, one 128-bit key for AES encryption and one
+   128-bit key for HMAC-SHA1.
+
+   The ticket is structured as follows:
+
+      struct {
+          uint32 key_version;
+          opaque iv[16]
+          opaque encrypted_state<0..2^16-1>;
+          opaque mac[20];
+      } ExampleTicket;
+
+   Here key_version identifies a particular set of keys.  One
+   possibility is to generate new random keys every time the server is
+   started, and use the timestamp as the key version.  The same
+   mechanisms known from a number of other protocols can be reused for
+   this purpose.
+
+   The actual state information in encrypted_state is encrypted using
+   128-bit AES in CBC mode with the given IV.  The MAC is calculated
+   using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
+   followed by the contents of the encrypted_state field (without the
+   length).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 6]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+      struct {
+          ProtocolVersion protocol_version;
+          SessionID session_id;
+          CipherSuite cipher_suite;
+          CompressionMethod compression_method;
+          opaque master_secret[48];
+          ClientIdentity client_identity;
+          uint32 timestamp;
+      } ExampleStatePlaintext;
+
+      enum {
+         anonymous(0),
+         certificate_based(1),
+         psk(2)
+     } ExampleClientAuthenticationType;
+
+      struct {
+          ExampleClientAuthenticationType client_authentication_type;
+          select (ExampleClientAuthenticationType) {
+              case anonymous: struct {};
+              case certificate_based:
+                  ASN.1Cert certificate_list<0..2^24-1>;
+              case psk:
+                  opaque psk_identity<0..2^16-1>;
+
+          }
+       } ExampleClientIdentity;
+
+   The structure ExampleStatePlaintext stores the TLS session state
+   including the SessionID and the master_secret.  The timestamp within
+   this structure allows the TLS server to expire tickets.  To cover the
+   authentication and key exchange protocols provided by TLS the
+   ExampleClientIdentity structure contains the authentication type of
+   the client used in the initial exchange (see
+   ExampleClientAuthenticationType).  To offer the TLS server with the
+   same capabilities for authentication and authorization a certificate
+   list is included in case of public key based authentication.  The TLS
+   server is therefore able to inspect a number of different attributes
+   within these certificates.  A specific implementation might choose to
+   store a subset of this information.  Other authentication mechanism
+   such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk]
+   would require different client identity data.
+
+5.  Security Considerations
+
+   This section addresses security issues related to the usage of a
+   ticket.  Tickets must be sufficiently authenticated and encrypted to
+   prevent modification or eavesdropping by an attacker.  Several
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 7]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+   attacks described below will be possible if this is not carefully
+   done.
+
+   Implementations should take care to ensure that the processing of
+   tickets does not increase the chance of denial of serve as described
+   below.
+
+5.1  Invalidating Sessions
+
+   The TLS specification requires that TLS sessions be invalidated when
+   errors occur.  [CSSC] discusses the security implications of this in
+   detail.  In the analysis in this paper, failure to invalidate
+   sessions does not pose a security risk.  This is because the TLS
+   handshake uses a non-reversible function to derive keys for a session
+   so information about one session does not provide an advantage to
+   attack the master secret or a different session.  If a session
+   invalidation scheme is used the implementation should verify the
+   integrity of the ticket before using the contents to invalidate a
+   session to ensure an attacker cannot invalidate a chosen session.
+
+5.2  Stolen Tickets
+
+   An eavesdropper or man-in-the-middle may obtain the ticket and
+   attempt to use the ticket to establish a session with the server,
+   however since the ticket is encrypted and the attacker does not know
+   the secret key a stolen key does not help an attacker resume a
+   session.  A TLS server MUST use strong encryption and integrity
+   protection for the ticket to prevent an attacker from using a brute
+   force mechanism to obtain the tickets contents.
+
+5.3  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
+   gain additional privileges.  This attack is not possible if the
+   ticket is protected using a strong integrity protection algorithm
+   such as a keyed HMAC.
+
+5.4  Denial of Service Attacks
+
+   An adversary could store or forge a large number of tickets to send
+   to the TLS server for verification.  To minimize the possibility of a
+   denial of service the verification of the ticket should be
+   lightweight (e.g., using efficient symmetric key cryptographic
+   algorithms).
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 8]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+5.5  Ticket Protection Key Lifetime
+
+   The management of the keys used to protect the ticket is beyond the
+   scope of this document.  It is advisable to limit the lifetime of
+   these keys to ensure they are not overused.
+
+6.  Acknowledgments
+
+   The authors would like to thank the following people for their help
+   with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget
+   and David McGrew
+
+   [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS
+   ciphersuites, which helped inspire the use of tickets to avoid server
+   state.  [I-D.cam-winget-eap-fast] makes use of a similar mechanism to
+   avoid maintaining server state for the cryptographic tunnel.
+   [AURA97] also investigates the concept of stateless sessions.  [CSSC]
+   describes a solution that is very similar to the one described in
+   this document and gives a detailed analysis of the security
+   considerations involved.
+
+7.  IANA considerations
+
+   Needs a TLS extension number (for including the ticket in client
+   hello), and HandshakeType number (for delivering the ticket to the
+   client).
+
+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.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+              and T. Wright, "Transport Layer Security (TLS)
+              Extensions", RFC 3546, June 2003.
+
+8.2  Informative References
+
+   [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
+              Proceedings of the First International Conference on
+              Information and Communication Security (ICICS '97) , 1997.
+
+   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client Side
+
+
+
+Salowey, et al.         Expires January 16, 2006                [Page 9]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+              Caching for TLS",
+              URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf,
+              2002.
+
+   [I-D.cam-winget-eap-fast]
+              Salowey, J., "EAP Flexible Authentication via Secure
+              Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work
+              in progress), April 2005.
+
+   [I-D.ietf-tls-psk]
+              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
+              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
+              (work in progress), June 2005.
+
+   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
+              Suites to Transport Layer Security (TLS)", RFC 2712,
+              October 1999.
+
+
+Authors' Addresses
+
+   Joseph Salowey
+   Cisco Systems
+   2901 3rd Ave
+   Seattle, WA  98121
+   US
+
+   Email: jsalowey@cisco.com
+
+
+   Hao Zhou
+   Cisco Systems
+   4125 Highlander Parkway
+   Richfield, OH  44286
+   US
+
+   Email: hzhou@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006               [Page 10]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+   Pasi Eronen
+   Nokia Research Center
+   P.O. Box 407
+   FIN-00045 Nokia Group
+   Finland
+
+   Email: pasi.eronen@nokia.com
+
+
+   Hannes Tschofenig
+   Siemens
+   Otto-Hahn-Ring 6
+   Munich, Bayern  81739
+   Germany
+
+   Email: Hannes.Tschofenig@siemens.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.         Expires January 16, 2006               [Page 11]
+
+Internet-Draft      Stateless TLS Session Resumption           July 2005
+
+
+Intellectual Property Statement
+
+   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.
+
+
+Disclaimer of Validity
+
+   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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Salowey, et al.         Expires January 16, 2006               [Page 12]
+