| blob | 13e7abe66e560c56abc6f312f7927810d54fd5d3 |
7 Network Working Group J. Salowey
8 Request for Comments: 5077 H. Zhou
9 Obsoletes: 4507 Cisco Systems
10 Category: Standards Track P. Eronen
11 Nokia
12 H. Tschofenig
13 Nokia Siemens Networks
14 January 2008
17 Transport Layer Security (TLS) Session Resumption without
18 Server-Side State
20 Status of This Memo
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
28 Abstract
30 This document describes a mechanism that enables the Transport Layer
31 Security (TLS) server to resume sessions and avoid keeping per-client
32 session state. The TLS server encapsulates the session state into a
33 ticket and forwards it to the client. The client can subsequently
34 resume a session using the obtained ticket. This document obsoletes
35 RFC 4507.
58 Salowey, et al. Standards Track [Page 1]
59 \f
60 RFC 5077 Stateless TLS Session Resumption January 2008
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
70 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8
71 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
72 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10
73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
74 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12
75 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
76 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
77 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
78 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13
79 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
80 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13
81 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
86 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
87 Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17
114 Salowey, et al. Standards Track [Page 2]
115 \f
116 RFC 5077 Stateless TLS Session Resumption January 2008
119 1. Introduction
121 This document defines a way to resume a Transport Layer Security
122 (TLS) session without requiring session-specific state at the TLS
123 server. This mechanism may be used with any TLS ciphersuite. This
124 document applies to both TLS 1.0 defined in [RFC2246], and TLS 1.1
125 defined in [RFC4346]. The mechanism makes use of TLS extensions
126 defined in [RFC4366] and defines a new TLS message type.
128 This mechanism is useful in the following situations:
130 1. servers that handle a large number of transactions from different
131 users
133 2. servers that desire to cache sessions for a long time
135 3. ability to load balance requests across servers
137 4. embedded servers with little memory
139 This document obsoletes RFC 4507 [RFC4507] to correct an error in the
140 encoding that caused the specification to differ from deployed
141 implementations. At the time of this writing, there are no known
142 implementations that follow the encoding specified in RFC 4507. This
143 update to RFC 4507 aligns the document with currently deployed
144 implementations. More details of the change are given in Appendix A.
146 2. Terminology
148 Within this document, the term 'ticket' refers to a cryptographically
149 protected data structure that is created and consumed by the server
150 to rebuild session-specific state.
152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
154 document are to be interpreted as described in [RFC2119].
156 3. Protocol
158 This specification describes a mechanism to distribute encrypted
159 session-state information to the client in the form of a ticket and a
160 mechanism to present the ticket back to the server. The ticket is
161 created by a TLS server and sent to a TLS client. The TLS client
162 presents the ticket to the TLS server to resume a session.
163 Implementations of this specification are expected to support both
164 mechanisms. Other specifications can take advantage of the session
165 tickets, perhaps specifying alternative means for distribution or
166 selection. For example, a separate specification may describe an
170 Salowey, et al. Standards Track [Page 3]
171 \f
172 RFC 5077 Stateless TLS Session Resumption January 2008
175 alternate way to distribute a ticket and use the TLS extension in
176 this document to resume the session. This behavior is beyond the
177 scope of the document and would need to be described in a separate
178 specification.
180 3.1. Overview
182 The client indicates that it supports this mechanism by including a
183 SessionTicket TLS extension in the ClientHello message. The
184 extension will be empty if the client does not already possess a
185 ticket for the server. The server sends an empty SessionTicket
186 extension to indicate that it will send a new session ticket using
187 the NewSessionTicket handshake message. The extension is described
188 in Section 3.2.
190 If the server wants to use this mechanism, it stores its session
191 state (such as ciphersuite and master secret) to a ticket that is
192 encrypted and integrity-protected by a key known only to the server.
193 The ticket is distributed to the client using the NewSessionTicket
194 TLS handshake message described in Section 3.3. This message is sent
195 during the TLS handshake before the ChangeCipherSpec message, after
196 the server has successfully verified the client's Finished message.
198 Client Server
200 ClientHello
201 (empty SessionTicket extension)-------->
202 ServerHello
203 (empty SessionTicket extension)
204 Certificate*
205 ServerKeyExchange*
206 CertificateRequest*
207 <-------- ServerHelloDone
208 Certificate*
209 ClientKeyExchange
210 CertificateVerify*
211 [ChangeCipherSpec]
212 Finished -------->
213 NewSessionTicket
214 [ChangeCipherSpec]
215 <-------- Finished
216 Application Data <-------> Application Data
218 Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
226 Salowey, et al. Standards Track [Page 4]
227 \f
228 RFC 5077 Stateless TLS Session Resumption January 2008
231 The client caches this ticket along with the master secret and other
232 parameters associated with the current session. When the client
233 wishes to resume the session, it includes the ticket in the
234 SessionTicket extension within the ClientHello message. Appendix A
235 provides a detailed description of the encoding of the extension and
236 changes from RFC 4507. The server then decrypts the received ticket,
237 verifies the ticket's validity, retrieves the session state from the
238 contents of the ticket, and uses this state to resume the session.
239 The interaction with the TLS Session ID is described in Section 3.4.
240 If the server successfully verifies the client's ticket, then it may
241 renew the ticket by including a NewSessionTicket handshake message
242 after the ServerHello.
244 Client Server
245 ClientHello
246 (SessionTicket extension) -------->
247 ServerHello
248 (empty SessionTicket extension)
249 NewSessionTicket
250 [ChangeCipherSpec]
251 <-------- Finished
252 [ChangeCipherSpec]
253 Finished -------->
254 Application Data <-------> Application Data
256 Figure 2: Message Flow for Abbreviated Handshake Using New Session
257 Ticket
259 A recommended ticket format is given in Section 4.
261 If the server cannot or does not want to honor the ticket, then it
262 can initiate a full handshake with the client.
264 In the case that the server does not wish to issue a new ticket at
265 this time, it just completes the handshake without including a
266 SessionTicket extension or NewSessionTicket handshake message. This
267 is shown below (this flow is identical to Figure 1 in RFC 4346,
268 except for the SessionTicket extension in the first message):
282 Salowey, et al. Standards Track [Page 5]
283 \f
284 RFC 5077 Stateless TLS Session Resumption January 2008
287 Client Server
289 ClientHello
290 (SessionTicket extension) -------->
291 ServerHello
292 Certificate*
293 ServerKeyExchange*
294 CertificateRequest*
295 <-------- ServerHelloDone
296 Certificate*
297 ClientKeyExchange
298 CertificateVerify*
299 [ChangeCipherSpec]
300 Finished -------->
301 [ChangeCipherSpec]
302 <-------- Finished
303 Application Data <-------> Application Data
305 Figure 3: Message Flow for Server Completing Full Handshake Without
306 Issuing New Session Ticket
308 It is also permissible to have an exchange similar to Figure 3 using
309 the abbreviated handshake defined in Figure 2 of RFC 4346, where the
310 client uses the SessionTicket extension to resume the session, but
311 the server does not wish to issue a new ticket, and therefore does
312 not send a SessionTicket extension.
314 If the server rejects the ticket, it may still wish to issue a new
315 ticket after performing the full handshake as shown below (this flow
316 is identical to Figure 1, except the SessionTicket extension in the
317 ClientHello is not empty):
338 Salowey, et al. Standards Track [Page 6]
339 \f
340 RFC 5077 Stateless TLS Session Resumption January 2008
343 Client Server
345 ClientHello
346 (SessionTicket extension) -------->
347 ServerHello
348 (empty SessionTicket extension)
349 Certificate*
350 ServerKeyExchange*
351 CertificateRequest*
352 <-------- ServerHelloDone
353 Certificate*
354 ClientKeyExchange
355 CertificateVerify*
356 [ChangeCipherSpec]
357 Finished -------->
358 NewSessionTicket
359 [ChangeCipherSpec]
360 <-------- Finished
361 Application Data <-------> Application Data
363 Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
364 Handshake, and Issuing New Session Ticket
366 3.2. SessionTicket TLS Extension
368 The SessionTicket TLS extension is based on [RFC4366]. The format of
369 the ticket is an opaque structure used to carry session-specific
370 state information. This extension may be sent in the ClientHello and
371 ServerHello.
373 If the client possesses a ticket that it wants to use to resume a
374 session, then it includes the ticket in the SessionTicket extension
375 in the ClientHello. If the client does not have a ticket and is
376 prepared to receive one in the NewSessionTicket handshake message,
377 then it MUST include a zero-length ticket in the SessionTicket
378 extension. If the client is not prepared to receive a ticket in the
379 NewSessionTicket handshake message, then it MUST NOT include a
380 SessionTicket extension unless it is sending a non-empty ticket it
381 received through some other means from the server.
383 The server uses a zero-length SessionTicket extension to indicate to
384 the client that it will send a new session ticket using the
385 NewSessionTicket handshake message described in Section 3.3. The
386 server MUST send this extension in the ServerHello if it wishes to
387 issue a new ticket to the client using the NewSessionTicket handshake
388 message. The server MUST NOT send this extension if it does not
389 receive one in the ClientHello.
394 Salowey, et al. Standards Track [Page 7]
395 \f
396 RFC 5077 Stateless TLS Session Resumption January 2008
399 If the server fails to verify the ticket, then it falls back to
400 performing a full handshake. If the ticket is accepted by the server
401 but the handshake fails, the client SHOULD delete the ticket.
403 The SessionTicket extension has been assigned the number 35. The
404 extension_data field of SessionTicket extension contains the ticket.
406 3.3. NewSessionTicket Handshake Message
408 This message is sent by the server during the TLS handshake before
409 the ChangeCipherSpec message. This message MUST be sent if the
410 server included a SessionTicket extension in the ServerHello. This
411 message MUST NOT be sent if the server did not include a
412 SessionTicket extension in the ServerHello. This message is included
413 in the hash used to create and verify the Finished message. In the
414 case of a full handshake, the server MUST verify the client's
415 Finished message before sending the ticket. The client MUST NOT
416 treat the ticket as valid until it has verified the server's Finished
417 message. If the server determines that it does not want to include a
418 ticket after it has included the SessionTicket extension in the
419 ServerHello, then it sends a zero-length ticket in the
420 NewSessionTicket handshake message.
422 If the server successfully verifies the client's ticket, then it MAY
423 renew the ticket by including a NewSessionTicket handshake message
424 after the ServerHello in the abbreviated handshake. The client
425 should start using the new ticket as soon as possible after it
426 verifies the server's Finished message for new connections. Note
427 that since the updated ticket is issued before the handshake
428 completes, it is possible that the client may not put the new ticket
429 into use before it initiates new connections. The server MUST NOT
430 assume that the client actually received the updated ticket until it
431 successfully verifies the client's Finished message.
433 The NewSessionTicket handshake message has been assigned the number 4
434 and its definition is given at the end of this section. The
435 ticket_lifetime_hint field contains a hint from the server about how
436 long the ticket should be stored. The value indicates the lifetime
437 in seconds as a 32-bit unsigned integer in network byte order
438 relative to when the ticket is received. A value of zero is reserved
439 to indicate that the lifetime of the ticket is unspecified. A client
440 SHOULD delete the ticket and associated state when the time expires.
441 It MAY delete the ticket earlier based on local policy. A server MAY
442 treat a ticket as valid for a shorter or longer period of time than
443 what is stated in the ticket_lifetime_hint.
450 Salowey, et al. Standards Track [Page 8]
451 \f
452 RFC 5077 Stateless TLS Session Resumption January 2008
455 struct {
456 HandshakeType msg_type;
457 uint24 length;
458 select (HandshakeType) {
459 case hello_request: HelloRequest;
460 case client_hello: ClientHello;
461 case server_hello: ServerHello;
462 case certificate: Certificate;
463 case server_key_exchange: ServerKeyExchange;
464 case certificate_request: CertificateRequest;
465 case server_hello_done: ServerHelloDone;
466 case certificate_verify: CertificateVerify;
467 case client_key_exchange: ClientKeyExchange;
468 case finished: Finished;
469 case session_ticket: NewSessionTicket; /* NEW */
470 } body;
471 } Handshake;
474 struct {
475 uint32 ticket_lifetime_hint;
476 opaque ticket<0..2^16-1>;
477 } NewSessionTicket;
479 3.4. Interaction with TLS Session ID
481 If a server is planning on issuing a session ticket to a client that
482 does not present one, it SHOULD include an empty Session ID in the
483 ServerHello. If the server rejects the ticket and falls back to the
484 full handshake then it may include a non-empty Session ID to indicate
485 its support for stateful session resumption. If the client receives
486 a session ticket from the server, then it discards any Session ID
487 that was sent in the ServerHello.
489 When presenting a ticket, the client MAY generate and include a
490 Session ID in the TLS ClientHello. If the server accepts the ticket
491 and the Session ID is not empty, then it MUST respond with the same
492 Session ID present in the ClientHello. This allows the client to
493 easily differentiate when the server is resuming a session from when
494 it is falling back to a full handshake. Since the client generates a
495 Session ID, the server MUST NOT rely upon the Session ID having a
496 particular value when validating the ticket. If a ticket is
497 presented by the client, the server MUST NOT attempt to use the
498 Session ID in the ClientHello for stateful session resumption.
499 Alternatively, the client MAY include an empty Session ID in the
500 ClientHello. In this case, the client ignores the Session ID sent in
501 the ServerHello and determines if the server is resuming a session by
502 the subsequent handshake messages.
506 Salowey, et al. Standards Track [Page 9]
507 \f
508 RFC 5077 Stateless TLS Session Resumption January 2008
511 4. Recommended Ticket Construction
513 This section describes a recommended format and protection for the
514 ticket. Note that the ticket is opaque to the client, so the
515 structure is not subject to interoperability concerns, and
516 implementations may diverge from this format. If implementations do
517 diverge from this format, they must take security concerns seriously.
518 Clients MUST NOT examine the ticket under the assumption that it
519 complies with this document.
521 The server uses two different keys: one 128-bit key for Advanced
522 Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode
523 [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].
525 The ticket is structured as follows:
527 struct {
528 opaque key_name[16];
529 opaque iv[16];
530 opaque encrypted_state<0..2^16-1>;
531 opaque mac[32];
532 } ticket;
534 Here, key_name serves to identify a particular set of keys used to
535 protect the ticket. It enables the server to easily recognize
536 tickets it has issued. The key_name should be randomly generated to
537 avoid collisions between servers. One possibility is to generate new
538 random keys and key_name every time the server is started.
540 The actual state information in encrypted_state is encrypted using
541 128-bit AES in CBC mode with the given IV. The Message
542 Authentication Code (MAC) is calculated using HMAC-SHA-256 over
543 key_name (16 octets) and IV (16 octets), followed by the length of
544 the encrypted_state field (2 octets) and its contents (variable
545 length).
562 Salowey, et al. Standards Track [Page 10]
563 \f
564 RFC 5077 Stateless TLS Session Resumption January 2008
567 struct {
568 ProtocolVersion protocol_version;
569 CipherSuite cipher_suite;
570 CompressionMethod compression_method;
571 opaque master_secret[48];
572 ClientIdentity client_identity;
573 uint32 timestamp;
574 } StatePlaintext;
576 enum {
577 anonymous(0),
578 certificate_based(1),
579 psk(2)
580 } ClientAuthenticationType;
582 struct {
583 ClientAuthenticationType client_authentication_type;
584 select (ClientAuthenticationType) {
585 case anonymous: struct {};
586 case certificate_based:
587 ASN.1Cert certificate_list<0..2^24-1>;
588 case psk:
589 opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
590 };
591 } ClientIdentity;
593 The structure StatePlaintext stores the TLS session state including
594 the master_secret. The timestamp within this structure allows the
595 TLS server to expire tickets. To cover the authentication and key
596 exchange protocols provided by TLS, the ClientIdentity structure
597 contains the authentication type of the client used in the initial
598 exchange (see ClientAuthenticationType). To offer the TLS server
599 with the same capabilities for authentication and authorization, a
600 certificate list is included in case of public-key-based
601 authentication. The TLS server is therefore able to inspect a number
602 of different attributes within these certificates. A specific
603 implementation might choose to store a subset of this information or
604 additional information. Other authentication mechanisms, such as
605 Kerberos [RFC2712], would require different client identity data.
606 Other TLS extensions may require the inclusion of additional data in
607 the StatePlaintext structure.
618 Salowey, et al. Standards Track [Page 11]
619 \f
620 RFC 5077 Stateless TLS Session Resumption January 2008
623 5. Security Considerations
625 This section addresses security issues related to the usage of a
626 ticket. Tickets must be authenticated and encrypted to prevent
627 modification or eavesdropping by an attacker. Several attacks
628 described below will be possible if this is not carefully done.
630 Implementations should take care to ensure that the processing of
631 tickets does not increase the chance of denial of service as
632 described below.
634 5.1. Invalidating Sessions
636 The TLS specification requires that TLS sessions be invalidated when
637 errors occur. [CSSC] discusses the security implications of this in
638 detail. In the analysis within this paper, failure to invalidate
639 sessions does not pose a security risk. This is because the TLS
640 handshake uses a non-reversible function to derive keys for a session
641 so information about one session does not provide an advantage to
642 attack the master secret or a different session. If a session
643 invalidation scheme is used, the implementation should verify the
644 integrity of the ticket before using the contents to invalidate a
645 session to ensure that an attacker cannot invalidate a chosen
646 session.
648 5.2. Stolen Tickets
650 An eavesdropper or man-in-the-middle may obtain the ticket and
651 attempt to use it to establish a session with the server; however,
652 since the ticket is encrypted and the attacker does not know the
653 secret key, a stolen ticket does not help an attacker resume a
654 session. A TLS server MUST use strong encryption and integrity
655 protection for the ticket to prevent an attacker from using a brute
656 force mechanism to obtain the ticket's contents.
658 5.3. Forged Tickets
660 A malicious user could forge or alter a ticket in order to resume a
661 session, to extend its lifetime, to impersonate another user, or to
662 gain additional privileges. This attack is not possible if the
663 ticket is protected using a strong integrity protection algorithm
664 such as a keyed HMAC-SHA-256.
666 5.4. Denial of Service Attacks
668 The key_name field defined in the recommended ticket format helps the
669 server efficiently reject tickets that it did not issue. However, an
670 adversary could store or generate a large number of tickets to send
674 Salowey, et al. Standards Track [Page 12]
675 \f
676 RFC 5077 Stateless TLS Session Resumption January 2008
679 to the TLS server for verification. To minimize the possibility of a
680 denial of service, the verification of the ticket should be
681 lightweight (e.g., using efficient symmetric key cryptographic
682 algorithms).
684 5.5. Ticket Protection Key Management
686 A full description of the management of the keys used to protect the
687 ticket is beyond the scope of this document. A list of RECOMMENDED
688 practices is given below.
690 o The keys should be generated securely following the randomness
691 recommendations in [RFC4086].
693 o The keys and cryptographic protection algorithms should be at
694 least 128 bits in strength. Some ciphersuites and applications
695 may require cryptographic protection greater than 128 bits in
696 strength.
698 o The keys should not be used for any purpose other than generating
699 and verifying tickets.
701 o The keys should be changed regularly.
703 o The keys should be changed if the ticket format or cryptographic
704 protection algorithms change.
706 5.6. Ticket Lifetime
708 The TLS server controls the lifetime of the ticket. Servers
709 determine the acceptable lifetime based on the operational and
710 security requirements of the environments in which they are deployed.
711 The ticket lifetime may be longer than the 24-hour lifetime
712 recommended in [RFC4346]. TLS clients may be given a hint of the
713 lifetime of the ticket. Since the lifetime of a ticket may be
714 unspecified, a client has its own local policy that determines when
715 it discards tickets.
717 5.7. Alternate Ticket Formats and Distribution Schemes
719 If the ticket format or distribution scheme defined in this document
720 is not used, then great care must be taken in analyzing the security
721 of the solution. In particular, if confidential information, such as
722 a secret key, is transferred to the client, it MUST be done using
723 secure communication so as to prevent attackers from obtaining or
724 modifying the key. Also, the ticket MUST have its integrity and
725 confidentiality protected with strong cryptographic techniques to
726 prevent a breach in the security of the system.
730 Salowey, et al. Standards Track [Page 13]
731 \f
732 RFC 5077 Stateless TLS Session Resumption January 2008
735 5.8. Identity Privacy, Anonymity, and Unlinkability
737 This document mandates that the content of the ticket is
738 confidentiality protected in order to avoid leakage of its content,
739 such as user-relevant information. As such, it prevents disclosure
740 of potentially sensitive information carried within the ticket.
742 The initial handshake exchange, which was used to obtain the ticket,
743 might not provide identity confidentiality of the client based on the
744 properties of TLS. Another relevant security threat is the ability
745 for an on-path adversary to observe multiple TLS handshakes where the
746 same ticket is used, therefore concluding they belong to the same
747 communication endpoints. Application designers that use the ticket
748 mechanism described in this document should consider that
749 unlinkability [ANON] is not necessarily provided.
751 While a full discussion of these topics is beyond the scope of this
752 document, it should be noted that it is possible to issue a ticket
753 using a TLS renegotiation handshake that occurs after a secure tunnel
754 has been established by a previous handshake. This may help address
755 some privacy and unlinkability issues in some environments.
757 6. Acknowledgements
759 The authors would like to thank the following people for their help
760 with preparing and reviewing this document: Eric Rescorla, Mohamad
761 Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
762 Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
763 the TLS working group.
765 [CSSC] describes a solution that is very similar to the one described
766 in this document and gives a detailed analysis of the security
767 considerations involved. [RFC2712] describes a mechanism for using
768 Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
769 of tickets to avoid server state. [RFC4851] makes use of a similar
770 mechanism to avoid maintaining server state for the cryptographic
771 tunnel. [SC97] also investigates the concept of stateless sessions.
773 The authors would also like to thank Jan Nordqvist, who found the
774 encoding error in RFC 4507, corrected by this document. In addition
775 Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided
776 useful feedback during the review of this document.
786 Salowey, et al. Standards Track [Page 14]
787 \f
788 RFC 5077 Stateless TLS Session Resumption January 2008
791 7. IANA Considerations
793 IANA has assigned a TLS extension number of 35 to the SessionTicket
794 TLS extension from the TLS registry of ExtensionType values defined
795 in [RFC4366].
797 IANA has assigned a TLS HandshakeType number 4 to the
798 NewSessionTicket handshake type from the TLS registry of
799 HandshakeType values defined in [RFC4346].
801 This document does not require any actions or assignments from IANA.
803 8. References
805 8.1. Normative References
807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
808 Requirement Levels", BCP 14, RFC 2119, March 1997.
810 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
811 RFC 2246, January 1999.
813 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
814 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
816 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
817 and T. Wright, "Transport Layer Security (TLS)
818 Extensions", RFC 4366, April 2006.
820 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
821 "Transport Layer Security (TLS) Session Resumption without
822 Server-Side State", RFC 4507, May 2006.
824 8.2. Informative References
826 [AES] National Institute of Standards and Technology, "Advanced
827 Encryption Standard (AES)", Federal Information Processing
828 Standards (FIPS) Publication 197, November 2001.
830 [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
831 Unobservability, Pseudonymity, and Identity Management - A
832 Consolidated Proposal for Terminology", http://
833 dud.inf.tu-dresden.de/literatur/
834 Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005.
842 Salowey, et al. Standards Track [Page 15]
843 \f
844 RFC 5077 Stateless TLS Session Resumption January 2008
847 [CBC] National Institute of Standards and Technology,
848 "Recommendation for Block Cipher Modes of Operation -
849 Methods and Techniques", NIST Special Publication 800-38A,
850 December 2001.
852 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
853 caching for TLS", Transactions on Information and System
854 Security (TISSEC) , Volume 7, Issue 4, November 2004.
856 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
857 Suites to Transport Layer Security (TLS)", RFC 2712,
858 October 1999.
860 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
861 Requirements for Security", BCP 106, RFC 4086, June 2005.
863 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
864 Kerberos Network Authentication Service (V5)", RFC 4120,
865 July 2005.
867 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
868 for Transport Layer Security (TLS)", RFC 4279,
869 December 2005.
871 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
872 (SHA and HMAC-SHA)", RFC 4634, July 2006.
874 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
875 Flexible Authentication via Secure Tunneling Extensible
876 Authentication Protocol Method (EAP-FAST)", RFC 4851,
877 May 2007.
879 [SC97] Aura, T. and P. Nikander, "Stateless Connections",
880 Proceedings of the First International Conference on
881 Information and Communication Security (ICICS '97) , 1997.
898 Salowey, et al. Standards Track [Page 16]
899 \f
900 RFC 5077 Stateless TLS Session Resumption January 2008
903 Appendix A. Discussion of Changes to RFC 4507
905 RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
906 without maintaining server side state by specifying an encrypted
907 ticket that is maintained on the client. The client presents this
908 ticket to the server in a SessionTicket hello extension. The
909 encoding in RFC 4507 used the XDR style encoding specified in TLS
910 [RFC4346].
912 An error in the encoding caused the specification to differ from
913 deployed implementations. At the time of this writing there are no
914 known implementations that follow the encoding specified in RFC 4507.
915 This update to RFC 4507 aligns the document with these currently
916 deployed implementations.
918 Erroneous encoding in RFC 4507 resulted in two length fields; one for
919 the extension contents and one for the ticket itself. Hence, for a
920 ticket that is 256 bytes long and begins with the hex value FF FF,
921 the encoding of the extension would be as follows according to RFC
922 4507:
924 00 23 Ticket Extension type 35
925 01 02 Length of extension contents
926 01 00 Length of ticket
927 FF FF .. .. Actual ticket
929 The update proposed in this document reflects what implementations
930 actually encode, namely it removes the redundant length field. So,
931 for a ticket that is 256 bytes long and begins with the hex value FF
932 FF, the encoding of the extension would be as follows according to
933 this update:
935 00 23 Extension type 35
936 01 00 Length of extension contents (ticket)
937 FF FF .. .. Actual ticket
939 A server implemented according to RFC 4507 receiving a ticket
940 extension from a client conforming to this document would interpret
941 the first two bytes of the ticket as the length of this ticket. This
942 will result in either an inconsistent length field or in the
943 processing of a ticket missing the first two bytes. In the first
944 case, the server should reject the request based on a malformed
945 length. In the second case, the server should reject the ticket
946 based on a malformed ticket, incorrect key version, or failed
947 decryption. A server implementation based on this update receiving
948 an RFC 4507 extension would interpret the first length field as the
954 Salowey, et al. Standards Track [Page 17]
955 \f
956 RFC 5077 Stateless TLS Session Resumption January 2008
959 length of the ticket and include the second two length bytes as the
960 first bytes in the ticket, resulting in the ticket being rejected
961 based on a malformed ticket, incorrect key version, or failed
962 decryption.
964 Note that the encoding of an empty SessionTicket extension was
965 ambiguous in RFC 4507. An RFC 4507 implementation may have encoded
966 it as:
968 00 23 Extension type 35
969 00 02 Length of extension contents
970 00 00 Length of ticket
972 or it may have encoded it the same way as this update:
974 00 23 Extension type 35
975 00 00 Length of extension contents
977 A server wishing to support RFC 4507 clients should respond to an
978 empty SessionTicket extension encoded the same way as it received it.
980 A server implementation can construct tickets such that it can detect
981 an RFC 4507 implementation, if one existed, by including a cookie at
982 the beginning of the tickets that can be differentiated from a valid
983 length. For example, if an implementation constructed tickets to
984 start with the hex values FF FF, then it could determine where the
985 ticket begins and determine the length correctly from the type of
986 length fields present.
988 This document makes a few additional changes to RFC 4507 listed
989 below.
991 o Clarifying that the server can allow session resumption using a
992 ticket without issuing a new ticket in Section 3.1.
994 o Clarifying that the lifetime is relative to when the ticket is
995 received in section 3.3.
997 o Clarifying that the NewSessionTicket handshake message is included
998 in the hash generated for the Finished messages in Section 3.3.
1000 o Clarifying the interaction with TLS Session ID in Section 3.4.
1002 o Recommending the use of SHA-256 for the integrity protection of
1003 the ticket in Section 4.
1005 o Clarifying that additional data can be included in the
1006 StatePlaintext structure in Section 4.
1010 Salowey, et al. Standards Track [Page 18]
1011 \f
1012 RFC 5077 Stateless TLS Session Resumption January 2008
1015 Authors' Addresses
1017 Joseph Salowey
1018 Cisco Systems
1019 2901 3rd Ave
1020 Seattle, WA 98121
1021 US
1023 EMail: jsalowey@cisco.com
1026 Hao Zhou
1027 Cisco Systems
1028 4125 Highlander Parkway
1029 Richfield, OH 44286
1030 US
1032 EMail: hzhou@cisco.com
1035 Pasi Eronen
1036 Nokia Research Center
1037 P.O. Box 407
1038 FIN-00045 Nokia Group
1039 Finland
1041 EMail: pasi.eronen@nokia.com
1044 Hannes Tschofenig
1045 Nokia Siemens Networks
1046 Otto-Hahn-Ring 6
1047 Munich, Bayern 81739
1048 Germany
1050 EMail: Hannes.Tschofenig@nsn.com
1066 Salowey, et al. Standards Track [Page 19]
1067 \f
1068 RFC 5077 Stateless TLS Session Resumption January 2008
1071 Full Copyright Statement
1073 Copyright (C) The IETF Trust (2008).
1075 This document is subject to the rights, licenses and restrictions
1076 contained in BCP 78, and except as set forth therein, the authors
1077 retain all their rights.
1079 This document and the information contained herein are provided on an
1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1087 Intellectual Property
1089 The IETF takes no position regarding the validity or scope of any
1090 Intellectual Property Rights or other rights that might be claimed to
1091 pertain to the implementation or use of the technology described in
1092 this document or the extent to which any license under such rights
1093 might or might not be available; nor does it represent that it has
1094 made any independent effort to identify any such rights. Information
1095 on the procedures with respect to rights in RFC documents can be
1096 found in BCP 78 and BCP 79.
1098 Copies of IPR disclosures made to the IETF Secretariat and any
1099 assurances of licenses to be made available, or the result of an
1100 attempt made to obtain a general license or permission for the use of
1101 such proprietary rights by implementers or users of this
1102 specification can be obtained from the IETF on-line IPR repository at
1103 http://www.ietf.org/ipr.
1105 The IETF invites any interested party to bring to its attention any
1106 copyrights, patents or patent applications, or other proprietary
1107 rights that may cover technology that may be required to implement
1108 this standard. Please address the information to the IETF at
1109 ietf-ipr@ietf.org.
1122 Salowey, et al. Standards Track [Page 20]
1123 \f