From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5077.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc5077.txt (limited to 'doc/rfc/rfc5077.txt') diff --git a/doc/rfc/rfc5077.txt b/doc/rfc/rfc5077.txt new file mode 100644 index 0000000..13e7abe --- /dev/null +++ b/doc/rfc/rfc5077.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Salowey +Request for Comments: 5077 H. Zhou +Obsoletes: 4507 Cisco Systems +Category: Standards Track P. Eronen + Nokia + H. Tschofenig + Nokia Siemens Networks + January 2008 + + + Transport Layer Security (TLS) Session Resumption without + Server-Side State + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a mechanism that 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 + resume a session using the obtained ticket. This document obsoletes + RFC 4507. + + + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 1] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7 + 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8 + 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9 + 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12 + 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12 + 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 + 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13 + 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13 + 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13 + 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17 + + + + + + + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 2] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +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 [RFC4346]. The mechanism makes use of TLS extensions + defined in [RFC4366] and defines a new TLS message type. + + This mechanism is useful in the following 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 + + This document obsoletes RFC 4507 [RFC4507] to correct an error in the + encoding that caused the specification to differ from deployed + implementations. At the time of this writing, there are no known + implementations that follow the encoding specified in RFC 4507. This + update to RFC 4507 aligns the document with currently deployed + implementations. More details of the change are given in Appendix A. + +2. Terminology + + Within this document, the term 'ticket' refers to a cryptographically + protected data structure that is created 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 to the client in the form of a ticket and a + mechanism to present the ticket back to the server. The ticket is + created by a TLS server and sent to a TLS client. The TLS client + presents the ticket to the 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 + + + +Salowey, et al. Standards Track [Page 3] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + 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 server sends an empty SessionTicket + extension to indicate that it will send a new session ticket using + the NewSessionTicket handshake message. The extension is described + in Section 3.2. + + 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 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 --------> + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 1: Message Flow for Full Handshake Issuing New Session Ticket + + + + + + + +Salowey, et al. Standards Track [Page 4] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + 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 the ClientHello message. Appendix A + provides a detailed description of the encoding of the extension and + changes from RFC 4507. The server then decrypts the received ticket, + verifies the ticket's validity, 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 NewSessionTicket handshake message + after the ServerHello. + + Client Server + ClientHello + (SessionTicket extension) --------> + ServerHello + (empty SessionTicket extension) + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + Finished --------> + Application Data <-------> Application Data + + Figure 2: Message Flow for Abbreviated Handshake Using New Session + Ticket + + 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. + + In the case that the server does not wish to issue a new ticket at + this time, it just completes the handshake without including a + SessionTicket extension or NewSessionTicket handshake message. This + is shown below (this flow is identical to Figure 1 in RFC 4346, + except for the SessionTicket extension in the first message): + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 5] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + Client Server + + ClientHello + (SessionTicket extension) --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 3: Message Flow for Server Completing Full Handshake Without + Issuing New Session Ticket + + It is also permissible to have an exchange similar to Figure 3 using + the abbreviated handshake defined in Figure 2 of RFC 4346, where the + client uses the SessionTicket extension to resume the session, but + the server does not wish to issue a new ticket, and therefore does + not send a SessionTicket extension. + + If the server rejects the ticket, it may still wish to issue a new + ticket after performing the full handshake as shown below (this flow + is identical to Figure 1, except the SessionTicket extension in the + ClientHello is not empty): + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 6] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + Client Server + + ClientHello + (SessionTicket extension) --------> + ServerHello + (empty SessionTicket extension) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 4: Message Flow for Server Rejecting Ticket, Performing Full + Handshake, and Issuing New Session Ticket + +3.2. SessionTicket TLS Extension + + The SessionTicket TLS extension is based on [RFC4366]. 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 the ticket in the SessionTicket extension + in the ClientHello. If the client does not have a ticket and is + prepared to receive one in the NewSessionTicket 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 + NewSessionTicket 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 a zero-length SessionTicket extension to indicate to + the client that it will send a new session ticket using the + NewSessionTicket handshake message described in Section 3.3. The + server MUST send this extension in the ServerHello if it wishes to + issue a new ticket to the client using the NewSessionTicket handshake + message. The server MUST NOT send this extension if it does not + receive one in the ClientHello. + + + + +Salowey, et al. Standards Track [Page 7] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + 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 35. The + extension_data field of SessionTicket extension contains the ticket. + +3.3. NewSessionTicket 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. This message is included + in the hash used to create and verify the Finished message. 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 sends a zero-length ticket in the + NewSessionTicket handshake message. + + If the server successfully verifies the client's ticket, then it MAY + renew the ticket by including a NewSessionTicket 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 that the client actually received the updated ticket until it + successfully verifies the client's Finished message. + + The NewSessionTicket handshake message has been assigned the number 4 + and its definition is given at the end of this section. The + ticket_lifetime_hint field contains a hint from the server about how + long the ticket should be stored. The value indicates the lifetime + in seconds as a 32-bit unsigned integer in network byte order + relative to when the ticket is received. A value of zero is reserved + to indicate that the lifetime of the ticket is unspecified. A client + SHOULD delete the ticket and associated state when the time expires. + It MAY delete the ticket earlier based on local policy. A server MAY + treat a ticket as valid for a shorter or longer period of time than + what is stated in the ticket_lifetime_hint. + + + + + + +Salowey, et al. Standards Track [Page 8] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + 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: NewSessionTicket; /* NEW */ + } body; + } Handshake; + + + struct { + uint32 ticket_lifetime_hint; + opaque ticket<0..2^16-1>; + } NewSessionTicket; + +3.4. Interaction with TLS Session ID + + If a server is planning on issuing a session ticket to a client that + does not present one, it SHOULD include an empty Session ID in the + ServerHello. If the server rejects the ticket and falls back to the + full handshake then it may include a non-empty Session ID to indicate + its support for stateful session resumption. If the client receives + a session ticket 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 from when + it is 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 resumption. + 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. Standards Track [Page 9] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +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, and + 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 Advanced + Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode + [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634]. + + The ticket is structured as follows: + + struct { + opaque key_name[16]; + opaque iv[16]; + opaque encrypted_state<0..2^16-1>; + opaque mac[32]; + } ticket; + + Here, key_name serves to identify a particular set of keys used to + protect the ticket. It enables the server to easily recognize + tickets it has issued. The key_name should be randomly generated to + avoid collisions between servers. One possibility is to generate new + random keys and key_name every time the server is started. + + The actual state information in encrypted_state is encrypted using + 128-bit AES in CBC mode with the given IV. The Message + Authentication Code (MAC) is calculated using HMAC-SHA-256 over + key_name (16 octets) and IV (16 octets), followed by the length of + the encrypted_state field (2 octets) and its contents (variable + length). + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 10] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + struct { + ProtocolVersion protocol_version; + CipherSuite cipher_suite; + CompressionMethod compression_method; + opaque master_secret[48]; + ClientIdentity 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>; /* from [RFC4279] */ + }; + } 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 mechanisms, such as + Kerberos [RFC2712], would require different client identity data. + Other TLS extensions may require the inclusion of additional data in + the StatePlaintext structure. + + + + + + + + + + +Salowey, et al. Standards Track [Page 11] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +5. Security Considerations + + This section addresses security issues related to the usage of a + ticket. Tickets must be authenticated and encrypted to prevent + modification or eavesdropping by an attacker. Several 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 service 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 within 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 that 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 it 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 ticket's 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 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-SHA-256. + +5.4. 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 store or generate a large number of tickets to send + + + +Salowey, et al. Standards Track [Page 12] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + 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 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. + + 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. Some ciphersuites and applications + may require cryptographic protection greater than 128 bits in + strength. + + o The keys should not be used for any purpose other 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. + +5.6. Ticket Lifetime + + The TLS server controls the lifetime of the ticket. Servers + determine the acceptable lifetime based on the operational and + security requirements of the environments in which they are deployed. + The ticket lifetime may be longer than the 24-hour lifetime + recommended in [RFC4346]. TLS clients may be given a hint of the + lifetime of the ticket. Since the lifetime of a ticket may be + unspecified, a client has its own local policy that determines when + it discards tickets. + +5.7. 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 so as 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. + + + +Salowey, et al. Standards Track [Page 13] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +5.8. Identity Privacy, Anonymity, and Unlinkability + + This document mandates that the content of the ticket is + confidentiality protected in order to avoid leakage of its content, + such as user-relevant information. As such, it prevents disclosure + of potentially sensitive information carried within the ticket. + + The initial handshake exchange, which was used to obtain the ticket, + might not provide identity confidentiality of the client based on the + properties of TLS. Another relevant security threat is the ability + for an on-path adversary to observe multiple TLS handshakes where the + same ticket is used, therefore concluding they belong to the same + communication endpoints. Application designers that use the ticket + mechanism described in this document should consider that + unlinkability [ANON] is not necessarily provided. + + While a full discussion of these topics is beyond the scope of this + document, it should be noted that it is possible to issue a ticket + using a TLS renegotiation handshake that occurs after a secure tunnel + has been established by a previous handshake. This may help address + some privacy and unlinkability issues in some environments. + +6. Acknowledgements + + 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, Russ Housley, Amir Herzberg, Bernard Aboba, 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. [RFC4851] makes use of a similar + mechanism to avoid maintaining server state for the cryptographic + tunnel. [SC97] also investigates the concept of stateless sessions. + + The authors would also like to thank Jan Nordqvist, who found the + encoding error in RFC 4507, corrected by this document. In addition + Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided + useful feedback during the review of this document. + + + + + + + + + +Salowey, et al. Standards Track [Page 14] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +7. IANA Considerations + + IANA has assigned a TLS extension number of 35 to the SessionTicket + TLS extension from the TLS registry of ExtensionType values defined + in [RFC4366]. + + IANA has assigned a TLS HandshakeType number 4 to the + NewSessionTicket handshake type from the TLS registry of + HandshakeType values defined in [RFC4346]. + + This document does not require any actions or assignments from IANA. + +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. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, 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. + +8.2. Informative References + + [AES] National Institute of Standards and Technology, "Advanced + Encryption Standard (AES)", Federal Information Processing + Standards (FIPS) Publication 197, November 2001. + + [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability, + Unobservability, Pseudonymity, and Identity Management - A + Consolidated Proposal for Terminology", http:// + dud.inf.tu-dresden.de/literatur/ + Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005. + + + + + + + +Salowey, et al. Standards Track [Page 15] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + [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. + + [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [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. + + [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and HMAC-SHA)", RFC 4634, July 2006. + + [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The + Flexible Authentication via Secure Tunneling Extensible + Authentication Protocol Method (EAP-FAST)", RFC 4851, + May 2007. + + [SC97] Aura, T. and P. Nikander, "Stateless Connections", + Proceedings of the First International Conference on + Information and Communication Security (ICICS '97) , 1997. + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 16] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Appendix A. Discussion of Changes to RFC 4507 + + RFC 4507 [RFC4507] defines a mechanism to resume a TLS session + without maintaining server side state by specifying an encrypted + ticket that is maintained on the client. The client presents this + ticket to the server in a SessionTicket hello extension. The + encoding in RFC 4507 used the XDR style encoding specified in TLS + [RFC4346]. + + An error in the encoding caused the specification to differ from + deployed implementations. At the time of this writing there are no + known implementations that follow the encoding specified in RFC 4507. + This update to RFC 4507 aligns the document with these currently + deployed implementations. + + Erroneous encoding in RFC 4507 resulted in two length fields; one for + the extension contents and one for the ticket itself. Hence, for a + ticket that is 256 bytes long and begins with the hex value FF FF, + the encoding of the extension would be as follows according to RFC + 4507: + + 00 23 Ticket Extension type 35 + 01 02 Length of extension contents + 01 00 Length of ticket + FF FF .. .. Actual ticket + + The update proposed in this document reflects what implementations + actually encode, namely it removes the redundant length field. So, + for a ticket that is 256 bytes long and begins with the hex value FF + FF, the encoding of the extension would be as follows according to + this update: + + 00 23 Extension type 35 + 01 00 Length of extension contents (ticket) + FF FF .. .. Actual ticket + + A server implemented according to RFC 4507 receiving a ticket + extension from a client conforming to this document would interpret + the first two bytes of the ticket as the length of this ticket. This + will result in either an inconsistent length field or in the + processing of a ticket missing the first two bytes. In the first + case, the server should reject the request based on a malformed + length. In the second case, the server should reject the ticket + based on a malformed ticket, incorrect key version, or failed + decryption. A server implementation based on this update receiving + an RFC 4507 extension would interpret the first length field as the + + + + + +Salowey, et al. Standards Track [Page 17] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + length of the ticket and include the second two length bytes as the + first bytes in the ticket, resulting in the ticket being rejected + based on a malformed ticket, incorrect key version, or failed + decryption. + + Note that the encoding of an empty SessionTicket extension was + ambiguous in RFC 4507. An RFC 4507 implementation may have encoded + it as: + + 00 23 Extension type 35 + 00 02 Length of extension contents + 00 00 Length of ticket + + or it may have encoded it the same way as this update: + + 00 23 Extension type 35 + 00 00 Length of extension contents + + A server wishing to support RFC 4507 clients should respond to an + empty SessionTicket extension encoded the same way as it received it. + + A server implementation can construct tickets such that it can detect + an RFC 4507 implementation, if one existed, by including a cookie at + the beginning of the tickets that can be differentiated from a valid + length. For example, if an implementation constructed tickets to + start with the hex values FF FF, then it could determine where the + ticket begins and determine the length correctly from the type of + length fields present. + + This document makes a few additional changes to RFC 4507 listed + below. + + o Clarifying that the server can allow session resumption using a + ticket without issuing a new ticket in Section 3.1. + + o Clarifying that the lifetime is relative to when the ticket is + received in section 3.3. + + o Clarifying that the NewSessionTicket handshake message is included + in the hash generated for the Finished messages in Section 3.3. + + o Clarifying the interaction with TLS Session ID in Section 3.4. + + o Recommending the use of SHA-256 for the integrity protection of + the ticket in Section 4. + + o Clarifying that additional data can be included in the + StatePlaintext structure in Section 4. + + + +Salowey, et al. Standards Track [Page 18] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +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 + Nokia Siemens Networks + Otto-Hahn-Ring 6 + Munich, Bayern 81739 + Germany + + EMail: Hannes.Tschofenig@nsn.com + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 19] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 20] + -- cgit v1.2.3