diff options
Diffstat (limited to 'doc/protocol/draft-salowey-tls-ticket-06.txt')
| -rw-r--r-- | doc/protocol/draft-salowey-tls-ticket-06.txt | 784 |
1 files changed, 0 insertions, 784 deletions
diff --git a/doc/protocol/draft-salowey-tls-ticket-06.txt b/doc/protocol/draft-salowey-tls-ticket-06.txt deleted file mode 100644 index 7a142cc559..0000000000 --- a/doc/protocol/draft-salowey-tls-ticket-06.txt +++ /dev/null @@ -1,784 +0,0 @@ - - - -Network Working Group J. Salowey -Internet-Draft H. Zhou -Expires: June 18, 2006 Cisco Systems - P. Eronen - Nokia - H. Tschofenig - Siemens - December 15, 2005 - - - Transport Layer Security Session Resumption without Server-Side State - draft-salowey-tls-ticket-06.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 June 18, 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 June 18, 2006 [Page 1] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - resume a session using the obtained ticket. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5 - 3.3 SessionTicket handshake message . . . . . . . . . . . . . 6 - 3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7 - 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10 - 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10 - 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10 - 5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10 - 5.6 Alternate Ticket Formats and Distribution Schemes . . . . 11 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 - 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . . 14 - - - - - - - - - - - - - - - - - - - - - - - - - -Salowey, et al. Expires June 18, 2006 [Page 2] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - -1. Introduction - - This document defines a way to resume a Transport Layer Security - (TLS) session without requiring session-specific state at the TLS - server. This mechanism may be used with any TLS ciphersuite. This - document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1 - defined in [I-D.ietf-tls-rfc2246-bis]. The mechanism makes use of - TLS extensions defined in [I-D.ietf-tls-rfc3546bis] 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 - - This specification describes a mechanism to distribute encrypted - session state information in a ticket from a TLS server to a TLS - client and a mechanism for a TLS client to present a ticket to a TLS - server to resume a session. Implementations of this specification - are expected to support both mechanisms. Other specifications can - take advantage of the session tickets, perhaps specifying alternative - means for distribution or selection. For example a separate - specification may describe an alternate way to distribute a ticket - and use the TLS extension in this document to resume the session. - This behavior is beyond the scope of the document and would need to - be described in a separate specification. - -3.1 Overview - - The client indicates that it supports this mechanism by including a - SessionTicket TLS extension in the ClientHello message. The - extension will be empty if the client does not already possess a - ticket for the server. The extension is described in Section 3.2 - - - - -Salowey, et al. Expires June 18, 2006 [Page 3] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - 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 SessionTicket TLS - handshake message described in Section 3.3. This message is sent - during the TLS handshake before the ChangeCipherSpec message after - the server has successfully verified the client's Finished message. - - - Client Server - - ClientHello --------> - (empty SessionTicket extension) - ServerHello - (empty SessionTicket extension) - Certificate* - ServerKeyExchange* - CertificateRequest* - <-------- ServerHelloDone - Certificate* - ClientKeyExchange - CertificateVerify* - [ChangeCipherSpec] - Finished --------> - SessionTicket - [ChangeCipherSpec] - <-------- Finished - Application Data <-------> Application Data - - The client caches this ticket along with the master secret and other - parameters associated with the current session. When the client - wishes to resume the session, it includes the ticket in the - SessionTicket extension within ClientHello message. The server then - decrypts the received ticket, verifies that the ticket is valid and - has not been tampered with, retrieves the session state from the - contents of the ticket and uses this state to resume the session. - The interaction with the TLS Session ID is described in Section 3.4. - If the server successfully verifies the client's ticket then it may - renew the ticket by including a SessionTicket handshake message after - the ServerHello. - - - - - - - - - - - -Salowey, et al. Expires June 18, 2006 [Page 4] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - ClientHello - (SessionTicket extension) --------> - ServerHello - (empty SessionTicket extension) - SessionTicket - [ChangeCipherSpec] - <-------- Finished - [ChangeCipherSpec] - Finished --------> - Application Data <-------> Application Data - - A recommended 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. - -3.2 SessionTicket TLS extension - - The SessionTicket TLS extension is based on [I-D.ietf-tls- - rfc3546bis]. The format of the ticket is an opaque structure used to - carry session specific state information. This extension may be sent - in the ClientHello and ServerHello. - - If the client possesses a ticket that it wants to use to resume a - session then it includes it in the SessionTicket extension in the - ClientHello. If the client does not have a ticket and it is prepared - to receive one in the SessionTicket handshake message then it MUST - include a zero length ticket in the SessionTicket extension. If the - client is not prepared to receive a ticket in the SessionTicket - handshake message then it MUST NOT include a SessionTicket extension - unless it is sending a non-empty ticket it received through some - other means from the server. - - The server uses an zero length SessionTicket extension to indicate to - the client that it will send a new session ticket using the - SessionTicket handshake message described in Section 3.3. The server - MUST send this extension in the ServerHello if the server wishes to - issue a new ticket to the client using the SessionTicket handshake - message. The server MUST NOT send this extension if the client does - not include a SessionTicket handshake message in the client hello. - - If the server fails to verify the ticket then it falls back to - performing a full handshake. If the ticket is accepted by the server - but the handshake fails the client SHOULD delete the ticket. - - The SessionTicket extension has been assigned the number TBD1. The - format of the SessionTicket extension is given below. - - - - -Salowey, et al. Expires June 18, 2006 [Page 5] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - struct { - opaque ticket<0..2^16-1>; - } SessionTicket; - - -3.3 SessionTicket handshake message - - This message is sent by the server during the TLS handshake before - the ChangeCipherSpec message. This message MUST be sent if the - server included a SessionTicket extension in the ServerHello. This - message MUST NOT be sent if the server did not include a - SessionTicket extension in the ServerHello. In the case of a full - handshake, the server MUST verify the client's Finished message - before sending the ticket. The client MUST NOT treat the ticket as - valid until it has verified the server's Finished message. If the - server determines that it does not want to include a ticket after it - has included the SessionTicket extension in the ServerHello then it - MAY send a zero length ticket in the SessionTicket handshake message. - - If the server successfully verifies the client's ticket then it MAY - renew the ticket by including a SessionTicket handshake message after - the ServerHello in the abbreviated handshake. The client should - start using the new ticket as soon as possible after it verifies the - Server's finished message for new connections. Note that since the - updated ticket is issued before the handshake completes it is - possible that the client may not put the new ticket into use before - it initiates new connections. The server MUST NOT assume the client - actually received the updated ticket until it successfully verifies - the client's Finished message. - - The SessionTicket handshake message has been assigned the number - TBD2. The definition of the SessionTicket handshake message is given - below. - - - - - - - - - - - - - - - - - - -Salowey, et al. Expires June 18, 2006 [Page 6] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - 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 session_ticket: SessionTicket; /* NEW */ - } body; - } Handshake; - - - struct { - opaque ticket<0..2^16-1>; - } SessionTicket; - - -3.4 Interaction with TLS session ID - - If a server is planning on issuing a SessionTicket to a client that - does not present one it SHOULD include an empty Session ID in the - ServerHello. If the server includes a non-empty session ID then it - is indicating intent to use stateful session resume. If the client - receives a SessionTicket from the server then it discards any Session - ID that was sent in the ServerHello. - - When presenting a ticket the client MAY generate and include a - Session ID in the TLS ClientHello. If the server accepts the ticket - and the Session ID is not empty then it MUST respond with the same - Session ID present in the ClientHello. This allows the client to - easily differentiate when the server is resuming a session or falling - back to a full handshake. Since the client generates a Session ID - the server MUST NOT rely upon the Session ID having a particular - value when validating the ticket. If a ticket is presented by the - client the server MUST NOT attempt to use the Session ID in the - ClientHello for stateful session resume. Alternatively, the client - MAY include an empty Session ID in the ClientHello. In this case the - client ignores the Session ID sent in the ServerHello and determines - if the server is resuming a session by the subsequent handshake - messages. - - - - -Salowey, et al. Expires June 18, 2006 [Page 7] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - -4. Recommended Ticket Construction - - This section describes a recommended format and protection for the - ticket. Note that the ticket is opaque to the client so the - structure is not subject to interoperability concerns, so - implementations may diverge from this format. If implementations do - diverge from this format they must take security concerns seriously. - Clients MUST NOT examine the ticket under the assumption that it - complies with this document. - - The server uses two different keys, one 128-bit key for AES [AES] in - CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] - [SHA1]. - - The ticket is structured as follows: - - struct { - uint32 key_version; - opaque iv[16] - opaque encrypted_state<0..2^16-1>; - opaque mac[20]; - } Ticket; - - 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 length of the encrypted_state field (2 octets) and - its contents (variable length). - - - - - - - - - - - - - - - - - -Salowey, et al. Expires June 18, 2006 [Page 8] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - struct { - ProtocolVersion protocol_version; - CipherSuite cipher_suite; - CompressionMethod compression_method; - opaque master_secret[48]; - ExampleClientIdentity client_identity; - uint32 timestamp; - } StatePlaintext; - - enum { - anonymous(0), - certificate_based(1), - psk(2) - } ClientAuthenticationType; - - struct { - ClientAuthenticationType client_authentication_type; - select (ClientAuthenticationType) { - case anonymous: struct {}; - case certificate_based: - ASN.1Cert certificate_list<0..2^24-1>; - case psk: - opaque psk_identity<0..2^16-1>; - - } - } ClientIdentity; - - The structure StatePlaintext stores the TLS session state including - 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 ClientIdentity structure - contains the authentication type of the client used in the initial - exchange (see ClientAuthenticationType). 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 or - additional information. Other authentication mechanism such as - Kerberos [RFC2712] 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 - attacks described below will be possible if this is not carefully - done. - - - -Salowey, et al. Expires June 18, 2006 [Page 9] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - 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 ticket 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-SHA1. - -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). - -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. - - - -Salowey, et al. Expires June 18, 2006 [Page 10] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - -5.6 Alternate Ticket Formats and Distribution Schemes - - If a different ticket format or distribution scheme than the ones - defined in this document is used then great care must be taken in - analyzing the security of the solution. In particular if a secret is - transferred to the client it MUST be done using secure communication - so as to prevent attackers from obtaining or modifying the key. Also - the ticket MUST have its integrity and privacy protected with strong - cryptographic techniques to prevent a breach in the security of the - system. - -6. Acknowledgments - - The authors would like to thank the following people for their help - with preparing and reviewing this document: Eric Rescorla, Mohamad - Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, - Rob Dugal and members of the TLS working group. - - [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. [RFC2712] describes a mechanism for using - Kerberos ([RFC4120]) 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. [SC97] also investigates the concept - of stateless sessions. - -7. IANA considerations - - IANA has assigned a TLS extension number of TBD1 (the value 35 is - suggested) to the SessionTicket TLS extension from the TLS registry - of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis]. - - IANA has assigned a TLS HandshakeType number TBD2 to the - SessionTicket handshake type from the TLS registry of HandshakeType - values defined in [I-D.ietf-tls-rfc2246-bis]. - -8. References - -8.1 Normative References - - [I-D.ietf-tls-rfc2246-bis] - Dierks, T. and E. Rescorla, "The TLS Protocol Version - 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), - June 2005. - - [I-D.ietf-tls-rfc3546bis] - Blake-Wilson, S., "Transport Layer Security (TLS) - - - -Salowey, et al. Expires June 18, 2006 [Page 11] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - Extensions", draft-ietf-tls-rfc3546bis-02 (work in - progress), October 2005. - - [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. - -8.2 Informative References - - [AES] National Institute of Standards and Technology, "Advanced - Encryption Standard (AES)", Federal Information - Processing Standards (FIPS) Publication 197, - November 2001. - - [CBC] National Institute of Standards and Technology, - "Recommendation for Block Cipher Modes of Operation - - Methods and Techniques", NIST Special Publication 800-38A, - December 2001. - - [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side - caching for TLS", Transactions on Information and - System Security (TISSEC) , Volume 7, Issue 4, - November 2004. - - [I-D.cam-winget-eap-fast] - Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP - Flexible Authentication via Secure Tunneling (EAP-FAST)", - draft-cam-winget-eap-fast-02 (work in progress), - April 2005. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher - Suites to Transport Layer Security (TLS)", RFC 2712, - October 1999. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC 4120, - July 2005. - - [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites - for Transport Layer Security (TLS)", RFC 4279, - December 2005. - - - - -Salowey, et al. Expires June 18, 2006 [Page 12] - -Internet-Draft Stateless TLS Session Resumption December 2005 - - - [SC97] Aura, T. and P. Nikander, "Stateless Connections", - Proceedings of the First International Conference on - Information and Communication Security (ICICS '97) , 1997. - - [SHA1] National Institute of Standards and Technology, "Secure - Hash Standard (SHS)", Federal Information Processing - Standards (FIPS) Publication 180-2, August 2002. - - -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 - - - 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 June 18, 2006 [Page 13] - -Internet-Draft Stateless TLS Session Resumption December 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 June 18, 2006 [Page 14] - |