RFC 5077
Transport Layer Security (TLS) Session Resumption without Server-Side State
RFC 5077 🎀
Okay bestie, so this is RFC 5077, which is called "Transport Layer Security (TLS) Session Resumption without Server-Side State" ✨ It's a Standards Track document from the Network Working Group, dated January 2008. The authors are J. Salowey and H. Zhou from Cisco Systems, P. Eronen from Nokia, and H. Tschofenig from Nokia Siemens Networks 💅 It obsoletes RFC 4507, and it doesn't list any documents it updates 🦋
Status of This Memo
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💖 If you want to know where the protocol stands in standardization and its status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌸
Abstract
Okay so this one is about letting a TLS server resume sessions without keeping per-client session state lying around 🧚 The server packs the session state into a ticket and sends it to the client. Later, the client can resume its session by showing that ticket back 🎟️ This document obsoletes RFC 4507 🫶
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 . . . . . . . . . . 171. Introduction ✨
Okay this is the fun part 💖 This document defines a way to resume a Transport Layer Security (TLS) session without needing session-specific state on the TLS server 🦋 The mechanism may be used with any TLS ciphersuite. It applies to both TLS 1.0, defined in [RFC2246], and TLS 1.1, defined in [RFC4346]. It makes use of TLS extensions defined in [RFC4366], and it defines a new TLS message type 🔥
This mechanism is useful in the following situations:
- servers that handle a large number of transactions from different users
- servers that desire to cache sessions for a long time
- ability to load balance requests across servers
- embedded servers with little memory
This document obsoletes RFC 4507 [RFC4507] to correct an error in the encoding that made the specification 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 lines the document up with currently deployed implementations 🎀 More details of the change are given in Appendix A 🌈
2. Terminology 💅
In 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 🧚
Okay so this section describes a mechanism for handing encrypted session-state information to the client in the form of a ticket, plus a mechanism for presenting that ticket back to the server 🎟️ The ticket is created by a TLS server and sent to a TLS client. The TLS client then 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 session tickets, perhaps by 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. That behavior is beyond the scope of this document and would need to be described in a separate specification 💜
3.1. Overview 💖
okay so the client says "yes pls, I do the ticket thing" by including a SessionTicket TLS extension in its ClientHello 🎀. If it doesn't have a ticket for that server yet, the extension is just empty. The server replies with an empty SessionTicket extension to say "cool, I'm gonna send you a brand new ticket" using the NewSessionTicket handshake message ✨. The extension itself is explained in Section 3.2 🦋.
If the server wants in on this, it stores its session state (like the ciphersuite and master secret) inside a ticket that's encrypted and integrity-protected with a key only the server knows 🔐. The ticket gets delivered to the client through the NewSessionTicket TLS handshake message from Section 3.3. That message goes out during the handshake before the ChangeCipherSpec message, and only 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 DataFigure 1: Message Flow for Full Handshake Issuing New Session Ticket 🌸
The client caches this ticket along with the master secret and other parameters from the current session 🧚. When it wants to resume, it includes the ticket in the SessionTicket extension inside its ClientHello ✨. Appendix A has the full scoop on how the extension is encoded and what changed from RFC 4507, so go there if you're curious 🙈. The server then decrypts the ticket, checks that it's still valid, pulls the session state out of the ticket's contents, and uses that state to resume the session 💜. The interaction with the TLS Session ID is covered in Section 3.4. And if the server successfully verifies the client's ticket, it may renew it 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 DataFigure 2: Message Flow for Abbreviated Handshake Using New Session Ticket 🦋
A recommended ticket format lives in Section 4 🎀.
If the server can't or doesn't want to honor the ticket, it can kick off a full handshake with the client 🔁.
Now, if the server doesn't want to issue a new ticket this time, it just finishes the handshake without including a SessionTicket extension or a NewSessionTicket handshake message 😌. Here's what that looks like. This flow is identical to Figure 1 in RFC 4346, except for the SessionTicket extension in the first message 👑:
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application DataFigure 3: Message Flow for Server Completing Full Handshake Without Issuing New Session Ticket 🌈
It's also totally permissible to have an exchange like Figure 3 but using the abbreviated handshake from Figure 2 of RFC 4346 💅. In that case the client uses the SessionTicket extension to resume the session, but the server doesn't want to issue a new ticket, so it doesn't send a SessionTicket extension either 🫶.
If the server rejects the ticket, it may still want to issue a new one after doing the full handshake. Here's how that goes. This flow is identical to Figure 1, except the SessionTicket extension in the ClientHello is not empty 🔥:
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application DataFigure 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 ticket is an opaque structure that carries session-specific state information. This extension may be sent in the ClientHello and the ServerHello ✨.
If the client has a ticket it wants to use to resume a session, it includes that ticket in the SessionTicket extension in the ClientHello 🧚. If the client doesn't have a ticket but is ready 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 ready to receive a ticket in the NewSessionTicket handshake message, then it MUST NOT include a SessionTicket extension, unless it's sending a non-empty ticket it got from the server through some other means 🙅♀️.
The server uses a zero-length SessionTicket extension to tell 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 wants to issue a new ticket to the client using the NewSessionTicket handshake message 🫶. The server MUST NOT send this extension if it didn't receive one in the ClientHello 🚫.
If the server fails to verify the ticket, it falls back to doing a full handshake 🔁. If the server accepts the ticket but the handshake then fails, the client SHOULD delete the ticket 🗑️.
The SessionTicket extension has been assigned the number 35 🔢. The extension_data field of the SessionTicket extension contains the ticket 🎟️.
3.3. NewSessionTicket Handshake Message 🍓
The server sends this message 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 🙅. The 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 decides it doesn't want to include a ticket after all, even though it 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, 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 ⏩. Heads up though: since the updated ticket is issued before the handshake completes, the client might not put the new ticket into use before it starts new connections 🙈. The server MUST NOT assume 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 at the end of this section 🔢. The ticket_lifetime_hint field holds a hint from the server about how long the ticket should be stored ⏳. The value is the lifetime in seconds, as a 32-bit unsigned integer in network byte order, counted relative to when the ticket is received 🕐. A value of zero is reserved to mean the lifetime of the ticket is unspecified 🌀. A client SHOULD delete the ticket and its 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 than what's stated in the ticket_lifetime_hint 🌈.
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 ✨
okay so if a server is planning to hand a ticket to a client that didn't send one, it SHOULD put an empty Session ID in the ServerHello 🫶. if the server rejects the ticket and falls back to a full handshake, it may include a non-empty Session ID to show it supports stateful session resumption. and if the client gets a session ticket from the server, it throws away whatever Session ID was in the ServerHello 🗑️
when a client presents a ticket, it MAY generate and include a Session ID in the TLS ClientHello 💖 if the server accepts the ticket and the Session ID isn't empty, it MUST respond with that same Session ID. this is how the client can tell the difference between a server resuming a session and a server falling back to a full handshake 👀 since the client is the one generating the Session ID, the server MUST NOT rely on it having any particular value when it validates the ticket. and if a ticket is presented, the server MUST NOT try to use the ClientHello Session ID for stateful session resumption. the other option is that the client MAY include an empty Session ID in the ClientHello. then the client ignores the Session ID from the ServerHello and works out whether the server is resuming by looking at the handshake messages that come after 🧚
this part is giving main character energy, bestie 💅
4. Recommended Ticket Construction ✨
this section is a recommended format and protection scheme for the ticket 🎀 the ticket is opaque to the client, so its structure doesn't create interoperability problems, and implementations are free to do their own thing and diverge from this format. BUT if they diverge, they must take security concerns seriously 🔥 clients MUST NOT examine the ticket on the assumption that it follows this document. no peeking, periodt 🙈
the server uses two keys. one is a 128-bit key for Advanced Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode [CBC] encryption, and the other is a 256-bit key for HMAC-SHA-256 [RFC4634] 🔐
the ticket is structured like this:
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[32];
} ticket;okay so key_name is how the server figures out which set of keys protected a ticket. that's how it can easily recognize tickets it issued 🧠 key_name should be randomly generated so servers don't collide with each other. one option is to make brand new random keys and a new key_name every time the server starts up ✨
the actual state info in encrypted_state gets encrypted with 128-bit AES in CBC mode, using the given IV 💜 the Message Authentication Code (MAC) is calculated with HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), and then the length of the encrypted_state field (2 octets) and its contents (variable length) get added on too 🦋
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;so StatePlaintext is where the TLS session state lives, master_secret included 🗝️ the timestamp in there lets the TLS server expire tickets, which is so useful ⏰ to cover the authentication and key exchange stuff TLS already does, ClientIdentity holds the authentication type the client used in the initial exchange (see ClientAuthenticationType) 🪪 and so the TLS server can offer the same authentication and authorization abilities, a certificate list gets included when public-key-based authentication was used. that means the server can look at a bunch of different attributes inside those certificates 👑 an implementation might decide to store only some of this, or store extra stuff too. other auth mechanisms, like Kerberos [RFC2712], would need different client identity data. and other TLS extensions might need to put more data into StatePlaintext too 🌈
5. Security Considerations 🔥
this section is all about the security stuff that comes with using a ticket, and it's serious business 😭 tickets must be authenticated and encrypted so an attacker can't modify them or eavesdrop. several of the attacks below will totally be possible if this isn't done carefully 💀
implementations should be careful that processing tickets doesn't make denial of service more likely, as described below 🛡️
5.1. Invalidating Sessions
the TLS spec says sessions MUST be invalidated when errors happen. wait, no. it says TLS sessions are required to be invalidated when errors occur 🙃 [CSSC] goes into detail about what that means. in the analysis in that paper, failing to invalidate sessions doesn't pose a security risk. that's because the TLS handshake uses a non-reversible function to derive session keys, so info about one session doesn't give an attacker a way to go after 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 its contents to invalidate a session. that way an attacker can't invalidate a session of their choosing 🚫
5.2. Stolen Tickets
an eavesdropper or man-in-the-middle might grab the ticket and try to use it to set up a session with the server 👀 but the ticket is encrypted and the attacker doesn't know the secret key, so a stolen ticket doesn't help them resume anything 🙅♀️ still, a TLS server MUST use strong encryption and integrity protection for the ticket, so an attacker can't brute force their way to the ticket's contents 💪
5.3. Forged Tickets
a malicious user could forge or alter a ticket to resume a session, extend its lifetime, impersonate someone else, or gain extra privileges. yikes 😱 this attack isn't possible if the ticket is protected by a strong integrity algorithm, like a keyed HMAC-SHA-256 🔒
5.4. Denial of Service Attacks
the key_name field in the recommended ticket format helps the server quickly reject tickets it didn't issue ⚡ but an adversary could store or generate a huge pile of tickets and send them to the TLS server for verification. to keep denial of service from being likely, verifying a ticket should be lightweight (e.g., using efficient symmetric key cryptographic algorithms) 🧃
5.5. Ticket Protection Key Management
a full description of how to manage the keys that protect the ticket is beyond the scope of this document 🙃 here's a list of RECOMMENDED practices, though:
- the keys should be generated securely, following the randomness recommendations in [RFC4086] 🎲
- the keys and cryptographic protection algorithms should be at least 128 bits in strength. some ciphersuites and applications may need cryptographic protection stronger than 128 bits 💪
- the keys should not be used for anything other than generating and verifying tickets 🙅♀️
- the keys should be changed regularly 🔄
- the keys should be changed if the ticket format or the cryptographic protection algorithms change 🔁
5.6. Ticket Lifetime
the TLS server controls how long a ticket lives ⏳ servers figure out the acceptable lifetime based on the operational and security needs of wherever they're deployed. the ticket lifetime may be longer than the 24-hour lifetime recommended in [RFC4346] 🌙 TLS clients may get a hint about how long the ticket lasts. and since a ticket's lifetime might be unspecified, a client has its own local policy for deciding when to discard tickets 🗑️
5.7. Alternate Ticket Formats and Distribution Schemes
if you don't use the ticket format or distribution scheme defined in this document, you have to be really careful about analyzing the security of your solution 🧐 especially if confidential info, like a secret key, gets transferred to the client. that MUST be done over secure communication so attackers can't get or modify the key 🔐 and the ticket MUST have its integrity and confidentiality protected with strong cryptographic techniques, or the whole system's security could break 💔
5.8. Identity Privacy, Anonymity, and Unlinkability
this document says the content of the ticket is confidentiality protected, so its content (like user-relevant info) doesn't leak 🤫 that means it stops potentially sensitive info inside the ticket from being disclosed 🫣
the initial handshake that got the ticket might not give the client identity confidentiality, depending on how TLS works in that case 👀 another threat is that an on-path adversary could watch multiple TLS handshakes that use the same ticket and conclude they all belong to the same communication endpoints 🕵️♀️ so application designers who use the ticket mechanism from this document should keep in mind that unlinkability [ANON] is not necessarily provided 🙈
a full discussion of all this is beyond the scope of this document, but it's worth knowing that you can issue a ticket during a TLS renegotiation handshake that happens after a secure tunnel was already set up by an earlier handshake 🦋 that might help with some privacy and unlinkability issues in some environments ✨
6. Acknowledgements 🫶
the authors want to thank these people for helping them prepare and review this document: Eric Rescorla, Mohamad Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and the members of the TLS working group 💖
[CSSC] describes a solution that's super similar to the one in this document and gives a detailed analysis of the security considerations involved 🧠 [RFC2712] describes a way to use Kerberos [RFC4120] in TLS ciphersuites, which helped inspire using tickets to avoid keeping server state 🎀 [RFC4851] uses a similar mechanism to avoid maintaining server state for the cryptographic tunnel 🌸 and [SC97] also looks into the concept of stateless sessions 🧚
the authors also want to shout out Jan Nordqvist, who found the encoding error in RFC 4507 that this document corrects 📣 and Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico, who gave useful feedback while this document was being reviewed 👑
7. IANA Considerations 🌈
IANA has assigned TLS extension number 35 to the SessionTicket TLS extension, from the TLS registry of ExtensionType values defined in [RFC4366] 🎟️
IANA has also assigned TLS HandshakeType number 4 to the NewSessionTicket handshake type, from the TLS registry of HandshakeType values defined in [RFC4346] 🏷️
this document doesn't require any actions or assignments from IANA 🙌
8. References ✨
the actual reference entries aren't in this part of the text I was given, so they'll need to come through in the next part 🧚
8.1. Normative References
okay so these are the docs the whole spec leans on, so they're not optional reading 📚✨
[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
these ones are the extra reading for when you want the full story 🧚💜
[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.pdfVersion 0.26, December 2005.[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.
Appendix A. Discussion of Changes to RFC 4507 🎀
okay this appendix is the tea ☕💅 RFC 4507 ([RFC4507]) is the one that lets a TLS session resume without the server keeping any state. The server hands the client an encrypted ticket, and the client shows that ticket back in a SessionTicket hello extension. The encoding in RFC 4507 used the XDR style encoding from TLS [RFC4346].
here's the plot twist: the encoding had a bug, so the spec didn't match what people were actually shipping 🙈 At the time of writing there are no known implementations that follow the RFC 4507 encoding. This update lines the document up with what's really deployed.
the bug gave you two length fields, one for the extension contents and one for the ticket itself. So for a 256-byte ticket starting with FF FF, RFC 4507 has the extension look like this:
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticketthis update drops the extra length field, because that's what implementations actually encode 💖 So the same 256-byte ticket starting with FF FF now looks like this:
00 23 Extension type 35
01 00 Length of extension contents (ticket)
FF FF .. .. Actual ticketnow the mixup zone 🚨 If an RFC 4507 server gets a ticket extension from a client that follows this update, it reads the first two bytes of the ticket as the ticket length. That goes one of two ways. Either the length field doesn't match, or the server ends up processing a ticket that's missing its 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.
it works the other way around too 🔄 A server built on this update that receives an RFC 4507 extension reads the first length field as the ticket length. That pulls the second pair of length bytes into the front of the ticket, so the ticket gets rejected for being malformed, having an incorrect key version, or failing decryption.
one more messy bit: an empty SessionTicket extension was ambiguous in RFC 4507 🙃 An RFC 4507 implementation may have encoded it like this:
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticketor it may have encoded it the same way this update does:
00 23 Extension type 35
00 00 Length of extension contentsif you want to support RFC 4507 clients, respond to an empty SessionTicket extension in the same encoding you received it in 🫶
a server can also build its tickets so it can spot an RFC 4507 implementation, if one exists 🕵️♀️ The trick is to put a cookie at the start of each ticket that can't be mistaken for a valid length. For example, if a server makes every ticket start with FF FF, it can tell where the ticket begins and work out the correct length from whichever length fields are present.
this document also makes a few other changes to RFC 4507, and here they are 👑
- Clarifying that the server can allow session resumption using a ticket without issuing a new ticket in Section 3.1.
- Clarifying that the lifetime is relative to when the ticket is received in section 3.3.
- Clarifying that the NewSessionTicket handshake message is included in the hash generated for the Finished messages in Section 3.3.
- Clarifying the interaction with TLS Session ID in Section 3.4.
- Recommending the use of SHA-256 for the integrity protection of the ticket in Section 4.
- Clarifying that additional data can be included in the StatePlaintext structure in Section 4.
Authors' Addresses 🧑💻
the squad behind this one 🫶
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.comFull Copyright Statement ⚖️
copyright stuff, but make it cute 🎀
Copyright (C) The IETF Trust (2008).
this document is covered by the rights, licenses and restrictions in BCP 78. Other than what BCP 78 sets out, the authors keep all of their rights 💅
the legal fine print, kept word for word 📜 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 doesn't take a side on whether any IP rights apply to the tech in this doc, or whether you can get a license for it. It also hasn't checked for any rights on its own. If you want the details on how rights work for RFC documents, check BCP 78 and BCP 79 📚
IPR disclosures sent to the IETF Secretariat, any licensing assurances, and the results of attempts to get a general license for implementers or users are all available from the IETF's online IPR repository at http://www.ietf.org/ipr 🔍
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 💖
📦 where this page comes from
- ietf: rfc5077 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms