| blob | 8623e73bf596f69ebe5ebe6c6d8d437bdba5d6e1 |
4 Network Working Group J. Salowey
5 Internet-Draft H. Zhou
6 Obsoletes: 4507 (if approved) Cisco Systems
7 Intended status: Standards Track P. Eronen
8 Expires: December 13, 2007 Nokia
9 H. Tschofenig
10 Nokia Siemens Networks
11 June 11, 2007
14 Transport Layer Security (TLS) Session Resumption without Server-Side
15 State
16 draft-salowey-tls-rfc4507bis-00.txt
18 Status of this Memo
20 By submitting this Internet-Draft, each author represents that any
21 applicable patent or other IPR claims of which he or she is aware
22 have been or will be disclosed, and any of which he or she becomes
23 aware will be disclosed, in accordance with Section 6 of BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on December 13, 2007.
43 Copyright Notice
45 Copyright (C) The IETF Trust (2007).
47 Abstract
49 This document describes a mechanism that enables the Transport Layer
50 Security (TLS) server to resume sessions and avoid keeping per-client
51 session state. The TLS server encapsulates the session state into a
55 Salowey, et al. Expires December 13, 2007 [Page 1]
56 \f
57 Internet-Draft Stateless TLS Session Resumption June 2007
60 ticket and forwards it to the client. The client can subsequently
61 resume a session using the obtained ticket. This document obsoletes
62 RFC 4507.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
72 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 7
73 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
74 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 9
75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
76 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 11
77 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 11
78 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 11
79 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
80 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 12
81 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 12
82 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 12
83 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13
84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
88 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
89 Appendix A. Discussion of Changes to RFC4507 . . . . . . . . . . 15
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
91 Intellectual Property and Copyright Statements . . . . . . . . . . 18
111 Salowey, et al. Expires December 13, 2007 [Page 2]
112 \f
113 Internet-Draft Stateless TLS Session Resumption June 2007
116 1. Introduction
118 This document defines a way to resume a Transport Layer Security
119 (TLS) session without requiring session-specific state at the TLS
120 server. This mechanism may be used with any TLS ciphersuite. This
121 document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
122 defined in [RFC4346]. The mechanism makes use of TLS extensions
123 defined in [RFC4366] and defines a new TLS message type.
125 This mechanism is useful in the following situations:
128 1. servers that handle a large number of transactions from
129 different users
130 2. servers that desire to cache sessions for a long time
131 3. ability to load balance requests across servers
132 4. embedded servers with little memory
134 This document obsoletes RFC 4507 [RFC4507] to correct an error in the
135 encoding that caused the specification to differ from deployed
136 implementations. At the time of this writing there are no known
137 implementations that follow the encoding specified in RFC 4507. This
138 update to RFC 4507 aligns the document with this currently deployed
139 implementations. More details of the change are given in Appendix A.
142 2. Terminology
144 Within this document, the term 'ticket' refers to a cryptographically
145 protected data structure that is created by the server and consumed
146 by the server to rebuild session-specific state.
148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
150 document are to be interpreted as described in [RFC2119].
153 3. Protocol
155 This specification describes a mechanism to distribute encrypted
156 session-state information in the form of a ticket. The ticket is
157 created by a TLS server and sent to a TLS client. The TLS client
158 presents the ticket to the TLS server to resume a session.
159 Implementations of this specification are expected to support both
160 mechanisms. Other specifications can take advantage of the session
161 tickets, perhaps specifying alternative means for distribution or
162 selection. For example, a separate specification may describe an
163 alternate way to distribute a ticket and use the TLS extension in
167 Salowey, et al. Expires December 13, 2007 [Page 3]
168 \f
169 Internet-Draft Stateless TLS Session Resumption June 2007
172 this document to resume the session. This behavior is beyond the
173 scope of the document and would need to be described in a separate
174 specification.
176 3.1. Overview
178 The client indicates that it supports this mechanism by including a
179 SessionTicket TLS extension in the ClientHello message. The
180 extension will be empty if the client does not already possess a
181 ticket for the server. The extension is described in Section 3.2.
183 If the server wants to use this mechanism, it stores its session
184 state (such as ciphersuite and master secret) to a ticket that is
185 encrypted and integrity-protected by a key known only to the server.
186 The ticket is distributed to the client using the NewSessionTicket
187 TLS handshake message described in Section 3.3. This message is sent
188 during the TLS handshake before the ChangeCipherSpec message, after
189 the server has successfully verified the client's Finished message.
192 Client Server
194 ClientHello
195 (empty SessionTicket extension)-------->
196 ServerHello
197 (empty SessionTicket extension)
198 Certificate*
199 ServerKeyExchange*
200 CertificateRequest*
201 <-------- ServerHelloDone
202 Certificate*
203 ClientKeyExchange
204 CertificateVerify*
205 [ChangeCipherSpec]
206 Finished -------->
207 NewSessionTicket
208 [ChangeCipherSpec]
209 <-------- Finished
210 Application Data <-------> Application Data
212 Figure 1: Message flow for full handshake issuing new session ticket
214 The client caches this ticket along with the master secret and other
215 parameters associated with the current session. When the client
216 wishes to resume the session, it includes the ticket in the
217 SessionTicket extension within the ClientHello message. The server
218 then decrypts the received ticket, verifies the ticket's validity,
219 retrieves the session state from the contents of the ticket, and uses
223 Salowey, et al. Expires December 13, 2007 [Page 4]
224 \f
225 Internet-Draft Stateless TLS Session Resumption June 2007
228 this state to resume the session. The interaction with the TLS
229 Session ID is described in Section 3.4. If the server successfully
230 verifies the client's ticket, then it may renew the ticket by
231 including a NewSessionTicket handshake message after the ServerHello.
234 Client Server
235 ClientHello
236 (SessionTicket extension) -------->
237 ServerHello
238 (empty SessionTicket extension)
239 NewSessionTicket
240 [ChangeCipherSpec]
241 <-------- Finished
242 [ChangeCipherSpec]
243 Finished -------->
244 Application Data <-------> Application Data
246 Figure 2: Message flow for abbreviated handshake using
247 new
248 session ticket
250 A recommended ticket format is given in Section 4.
252 If the server cannot or does not want to honor the ticket, then it
253 can initiate a full handshake with the client.
255 In the case that the server does not wish to issue a new ticket at
256 this time, it just completes the handshake without including a
257 SessionTicket extension or NewSessionTicket handshake message. This
258 is shown below (this flow is identical to Figure 1 in RFC 2246,
259 except for the session ticket extension in the first message):
280 Salowey, et al. Expires December 13, 2007 [Page 5]
281 \f
282 Internet-Draft Stateless TLS Session Resumption June 2007
285 Client Server
287 ClientHello
288 (SessionTicket extension) -------->
289 ServerHello
290 Certificate*
291 ServerKeyExchange*
292 CertificateRequest*
293 <-------- ServerHelloDone
294 Certificate*
295 ClientKeyExchange
296 CertificateVerify*
297 [ChangeCipherSpec]
298 Finished -------->
299 [ChangeCipherSpec]
300 <-------- Finished
301 Application Data <-------> Application Data
303 Figure 3: Message flow for server completing full handshake without
304 issuing new session ticket
306 If the server rejects the ticket, it may still wish to issue a new
307 ticket after performing the full handshake as shown below (this flow
308 is identical to Figure 1, except the SessionTicket extension in the
309 Client Hello is not empty):
312 Client Server
314 ClientHello
315 (SessionTicket extension) -------->
316 ServerHello
317 (empty SessionTicket extension)
318 Certificate*
319 ServerKeyExchange*
320 CertificateRequest*
321 <-------- ServerHelloDone
322 Certificate*
323 ClientKeyExchange
324 CertificateVerify*
325 [ChangeCipherSpec]
326 Finished -------->
327 NewSessionTicket
328 [ChangeCipherSpec]
329 <-------- Finished
330 Application Data <-------> Application Data
332 Figure 4: Message flow for server rejecting ticket, performing full
336 Salowey, et al. Expires December 13, 2007 [Page 6]
337 \f
338 Internet-Draft Stateless TLS Session Resumption June 2007
341 handshake and issuing new session ticket
343 3.2. SessionTicket TLS Extension
345 The SessionTicket TLS extension is based on [RFC4366]. The format of
346 the ticket is an opaque structure used to carry session-specific
347 state information. This extension may be sent in the ClientHello and
348 ServerHello.
350 If the client possesses a ticket that it wants to use to resume a
351 session, then it includes the ticket in the SessionTicket extension
352 in the ClientHello. If the client does not have a ticket and is
353 prepared to receive one in the NewSessionTicket handshake message,
354 then it MUST include a zero-length ticket in the SessionTicket
355 extension. If the client is not prepared to receive a ticket in the
356 NewSessionTicket handshake message then it MUST NOT include a
357 SessionTicket extension unless it is sending a non-empty ticket it
358 received through some other means from the server.
360 The server uses an zero-length SessionTicket extension to indicate to
361 the client that it will send a new session ticket using the
362 NewSessionTicket handshake message described in Section 3.3. The
363 server MUST send this extension in the ServerHello if it wishes to
364 issue a new ticket to the client using the NewSessionTicket handshake
365 message. The server MUST NOT send this extension if it does not
366 receive one in the ClientHello.
368 If the server fails to verify the ticket, then it falls back to
369 performing a full handshake. If the ticket is accepted by the server
370 but the handshake fails, the client SHOULD delete the ticket.
372 The SessionTicket extension has been assigned the number 35. The
373 extension_data field of SessionTicket extension contains the ticket.
375 3.3. NewSessionTicket Handshake Message
377 This message is sent by the server during the TLS handshake before
378 the ChangeCipherSpec message. This message MUST be sent if the
379 server included a SessionTicket extension in the ServerHello. This
380 message MUST NOT be sent if the server did not include a
381 SessionTicket extension in the ServerHello. In the case of a full
382 handshake, the server MUST verify the client's Finished message
383 before sending the ticket. The client MUST NOT treat the ticket as
384 valid until it has verified the server's Finished message. If the
385 server determines that it does not want to include a ticket after it
386 has included the SessionTicket extension in the ServerHello, then it
387 sends a zero-length ticket in the NewSessionTicket handshake message.
392 Salowey, et al. Expires December 13, 2007 [Page 7]
393 \f
394 Internet-Draft Stateless TLS Session Resumption June 2007
397 If the server successfully verifies the client's ticket, then it MAY
398 renew the ticket by including a NewSessionTicket handshake message
399 after the ServerHello in the abbreviated handshake. The client
400 should start using the new ticket as soon as possible after it
401 verifies the server's Finished message for new connections. Note
402 that since the updated ticket is issued before the handshake
403 completes, it is possible that the client may not put the new ticket
404 into use before it initiates new connections. The server MUST NOT
405 assume that the client actually received the updated ticket until it
406 successfully verifies the client's Finished message.
408 The NewSessionTicket handshake message has been assigned the number 4
409 and its definition is given at the end of this section. The
410 ticket_lifetime_hint field contains a hint from the server about how
411 long the ticket should be stored. The value indicates the lifetime
412 in seconds as a 32-bit unsigned integer in network byte order. A
413 value of zero is reserved to indicate that the lifetime of the ticket
414 is unspecified. A client SHOULD delete the ticket and associated
415 state when the time expires. It MAY delete the ticket earlier based
416 on local policy. A server MAY treat a ticket as valid for a shorter
417 or longer period of time than what is stated in the
418 ticket_lifetime_hint.
421 struct {
422 HandshakeType msg_type;
423 uint24 length;
424 select (HandshakeType) {
425 case hello_request: HelloRequest;
426 case client_hello: ClientHello;
427 case server_hello: ServerHello;
428 case certificate: Certificate;
429 case server_key_exchange: ServerKeyExchange;
430 case certificate_request: CertificateRequest;
431 case server_hello_done: ServerHelloDone;
432 case certificate_verify: CertificateVerify;
433 case client_key_exchange: ClientKeyExchange;
434 case finished: Finished;
435 case session_ticket: NewSessionTicket; /* NEW */
436 } body;
437 } Handshake;
440 struct {
441 uint32 ticket_lifetime_hint;
442 opaque ticket<0..2^16-1>;
443 } NewSessionTicket;
448 Salowey, et al. Expires December 13, 2007 [Page 8]
449 \f
450 Internet-Draft Stateless TLS Session Resumption June 2007
453 3.4. Interaction with TLS Session ID
455 If a server is planning on issuing a SessionTicket to a client that
456 does not present one, it SHOULD include an empty Session ID in the
457 ServerHello. If the server includes a non-empty session ID, then it
458 is indicating intent to use stateful session resume. If the client
459 receives a SessionTicket from the server, then it discards any
460 Session ID that was sent in the ServerHello.
462 When presenting a ticket, the client MAY generate and include a
463 Session ID in the TLS ClientHello. If the server accepts the ticket
464 and the Session ID is not empty, then it MUST respond with the same
465 Session ID present in the ClientHello. This allows the client to
466 easily differentiate when the server is resuming a session from when
467 it is falling back to a full handshake. Since the client generates a
468 Session ID, the server MUST NOT rely upon the Session ID having a
469 particular value when validating the ticket. If a ticket is
470 presented by the client, the server MUST NOT attempt to use the
471 Session ID in the ClientHello for stateful session resume.
472 Alternatively, the client MAY include an empty Session ID in the
473 ClientHello. In this case, the client ignores the Session ID sent in
474 the ServerHello and determines if the server is resuming a session by
475 the subsequent handshake messages.
478 4. Recommended Ticket Construction
480 This section describes a recommended format and protection for the
481 ticket. Note that the ticket is opaque to the client, so the
482 structure is not subject to interoperability concerns, and
483 implementations may diverge from this format. If implementations do
484 diverge from this format, they must take security concerns seriously.
485 Clients MUST NOT examine the ticket under the assumption that it
486 complies with this document.
488 The server uses two different keys: one 128-bit key for AES [AES] in
489 CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
490 [SHA1].
492 The ticket is structured as follows:
494 struct {
495 opaque key_name[16];
496 opaque iv[16];
497 opaque encrypted_state<0..2^16-1>;
498 opaque mac[20];
499 } ticket;
504 Salowey, et al. Expires December 13, 2007 [Page 9]
505 \f
506 Internet-Draft Stateless TLS Session Resumption June 2007
509 Here, key_name serves to identify a particular set of keys used to
510 protect the ticket. It enables the server to easily recognize
511 tickets it has issued. The key_name should be randomly generated to
512 avoid collisions between servers. One possibility is to generate new
513 random keys and key_name every time the server is started.
515 The actual state information in encrypted_state is encrypted using
516 128-bit AES in CBC mode with the given IV. The MAC is calculated
517 using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed
518 by the length of the encrypted_state field (2 octets) and its
519 contents (variable length).
522 struct {
523 ProtocolVersion protocol_version;
524 CipherSuite cipher_suite;
525 CompressionMethod compression_method;
526 opaque master_secret[48];
527 ClientIdentity client_identity;
528 uint32 timestamp;
529 } StatePlaintext;
531 enum {
532 anonymous(0),
533 certificate_based(1),
534 psk(2)
535 } ClientAuthenticationType;
537 struct {
538 ClientAuthenticationType client_authentication_type;
539 select (ClientAuthenticationType) {
540 case anonymous: struct {};
541 case certificate_based:
542 ASN.1Cert certificate_list<0..2^24-1>;
543 case psk:
544 opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
546 }
547 } ClientIdentity;
549 The structure StatePlaintext stores the TLS session state including
550 the master_secret. The timestamp within this structure allows the
551 TLS server to expire tickets. To cover the authentication and key
552 exchange protocols provided by TLS, the ClientIdentity structure
553 contains the authentication type of the client used in the initial
554 exchange (see ClientAuthenticationType). To offer the TLS server
555 with the same capabilities for authentication and authorization, a
556 certificate list is included in case of public-key-based
560 Salowey, et al. Expires December 13, 2007 [Page 10]
561 \f
562 Internet-Draft Stateless TLS Session Resumption June 2007
565 authentication. The TLS server is therefore able to inspect a number
566 of different attributes within these certificates. A specific
567 implementation might choose to store a subset of this information or
568 additional information. Other authentication mechanisms, such as
569 Kerberos [RFC2712], would require different client identity data.
572 5. Security Considerations
574 This section addresses security issues related to the usage of a
575 ticket. Tickets must be authenticated and encrypted to prevent
576 modification or eavesdropping by an attacker. Several attacks
577 described below will be possible if this is not carefully done.
579 Implementations should take care to ensure that the processing of
580 tickets does not increase the chance of denial of service as
581 described below.
583 5.1. Invalidating Sessions
585 The TLS specification requires that TLS sessions be invalidated when
586 errors occur. [CSSC] discusses the security implications of this in
587 detail. In the analysis in this paper, failure to invalidate
588 sessions does not pose a security risk. This is because the TLS
589 handshake uses a non-reversible function to derive keys for a session
590 so information about one session does not provide an advantage to
591 attack the master secret or a different session. If a session
592 invalidation scheme is used, the implementation should verify the
593 integrity of the ticket before using the contents to invalidate a
594 session to ensure that an attacker cannot invalidate a chosen
595 session.
597 5.2. Stolen Tickets
599 An eavesdropper or man-in-the-middle may obtain the ticket and
600 attempt to use the ticket to establish a session with the server;
601 however, since the ticket is encrypted and the attacker does not know
602 the secret key, a stolen ticket does not help an attacker resume a
603 session. A TLS server MUST use strong encryption and integrity
604 protection for the ticket to prevent an attacker from using a brute
605 force mechanism to obtain the ticket's contents.
607 5.3. Forged Tickets
609 A malicious user could forge or alter a ticket in order to resume a
610 session, to extend its lifetime, to impersonate as another user, or
611 to gain additional privileges. This attack is not possible if the
612 ticket is protected using a strong integrity protection algorithm
616 Salowey, et al. Expires December 13, 2007 [Page 11]
617 \f
618 Internet-Draft Stateless TLS Session Resumption June 2007
621 such as a keyed HMAC-SHA1.
623 5.4. Denial of Service Attacks
625 The key_name field defined in the recommended ticket format helps the
626 server efficiently reject tickets that it did not issue. However, an
627 adversary could store or generate a large number of tickets to send
628 to the TLS server for verification. To minimize the possibility of a
629 denial of service, the verification of the ticket should be
630 lightweight (e.g., using efficient symmetric key cryptographic
631 algorithms).
633 5.5. Ticket Protection Key Management
635 A full description of the management of the keys used to protect the
636 ticket is beyond the scope of this document. A list of RECOMMENDED
637 practices is given below.
639 o The keys should be generated securely following the randomness
640 recommendations in [RFC4086].
641 o The keys and cryptographic protection algorithms should be at
642 least 128 bits in strength.
643 o The keys should not be used for any other purpose than generating
644 and verifying tickets.
645 o The keys should be changed regularly.
646 o The keys should be changed if the ticket format or cryptographic
647 protection algorithms change.
649 5.6. Ticket Lifetime
651 The TLS server controls the lifetime of the ticket. Servers
652 determine the acceptable lifetime based on the operational and
653 security requirements of the environments in which they are deployed.
654 The ticket lifetime may be longer than the 24-hour lifetime
655 recommended in [RFC2246]. TLS clients may be given a hint of the
656 lifetime of the ticket. Since the lifetime of a ticket may be
657 unspecified, a client has its own local policy that determines when
658 it discards tickets.
660 5.7. Alternate Ticket Formats and Distribution Schemes
662 If the ticket format or distribution scheme defined in this document
663 is not used, then great care must be taken in analyzing the security
664 of the solution. In particular, if confidential information, such as
665 a secret key, is transferred to the client, it MUST be done using
666 secure communication so as to prevent attackers from obtaining or
667 modifying the key. Also, the ticket MUST have its integrity and
668 confidentiality protected with strong cryptographic techniques to
672 Salowey, et al. Expires December 13, 2007 [Page 12]
673 \f
674 Internet-Draft Stateless TLS Session Resumption June 2007
677 prevent a breach in the security of the system.
679 5.8. Identity Privacy, Anonymity, and Unlinkability
681 This document mandates that the content of the ticket is
682 confidentiality protected in order to avoid leakage of its content,
683 such as user-relevant information. As such, it prevents disclosure
684 of potentially sensitive information carried within the ticket.
686 The initial handshake exchange, which was used to obtain the ticket,
687 might not provide identity confidentiality of the client based on the
688 properties of TLS. Another relevant security threat is the ability
689 for an on-path adversary to observe multiple TLS handshakes where the
690 same ticket is used and therefore to conclude that they belong to the
691 same communication endpoints. Application designers that use the
692 ticket mechanism described in this document should consider that
693 unlinkability [ANON] is not necessarily provided.
695 While a full discussion of these topics is beyond the scope of this
696 document, it should be noted that it is possible to issue a ticket
697 using a TLS renegotiation handshake that occurs after a secure tunnel
698 has been established by a previous handshake. This may help address
699 some privacy and unlinkability issues in some environments.
702 6. Acknowledgements
704 The authors would like to thank the following people for their help
705 with preparing and reviewing this document: Eric Rescorla, Mohamad
706 Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
707 Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
708 the TLS working group.
710 [CSSC] describes a solution that is very similar to the one described
711 in this document and gives a detailed analysis of the security
712 considerations involved. [RFC2712] describes a mechanism for using
713 Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
714 of tickets to avoid server state. [RFC4851] makes use of a similar
715 mechanism to avoid maintaining server state for the cryptographic
716 tunnel. [SC97] also investigates the concept of stateless sessions.
718 The authors would also like to thank Jan Nordqvist who found the
719 encoding error in RFC 4507 corrected by this document.
722 7. IANA Considerations
724 IANA has assigned a TLS extension number of 35 to the SessionTicket
728 Salowey, et al. Expires December 13, 2007 [Page 13]
729 \f
730 Internet-Draft Stateless TLS Session Resumption June 2007
733 TLS extension from the TLS registry of ExtensionType values defined
734 in [RFC4366].
736 IANA has assigned a TLS HandshakeType number 4 to the
737 NewSessionTicket handshake type from the TLS registry of
738 HandshakeType values defined in [RFC4346].
741 8. References
743 8.1. Normative References
745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
746 Requirement Levels", BCP 14, RFC 2119, March 1997.
748 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
749 RFC 2246, January 1999.
751 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
752 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
754 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
755 and T. Wright, "Transport Layer Security (TLS)
756 Extensions", RFC 4366, April 2006.
758 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
759 "Transport Layer Security (TLS) Session Resumption without
760 Server-Side State", RFC 4507, May 2006.
762 8.2. Informative References
764 [AES] National Institute of Standards and Technology, "Advanced
765 Encryption Standard (AES)", Federal Information
766 Processing Standards (FIPS) Publication 197,
767 November 2001.
769 [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
770 Unobservability, Pseudonymity, and Identity Management - A
771 Consolidated Proposal for Terminology", http://
772 dud.inf.tu-dresden.de/literatur/
773 Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005.
775 [CBC] National Institute of Standards and Technology,
776 "Recommendation for Block Cipher Modes of Operation -
777 Methods and Techniques", NIST Special Publication 800-38A,
778 December 2001.
780 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
784 Salowey, et al. Expires December 13, 2007 [Page 14]
785 \f
786 Internet-Draft Stateless TLS Session Resumption June 2007
789 caching for TLS", Transactions on Information and
790 System Security (TISSEC) , Volume 7, Issue 4,
791 November 2004.
793 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
794 Hashing for Message Authentication", RFC 2104,
795 February 1997.
797 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
798 Suites to Transport Layer Security (TLS)", RFC 2712,
799 October 1999.
801 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
802 Requirements for Security", BCP 106, RFC 4086, June 2005.
804 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
805 Kerberos Network Authentication Service (V5)", RFC 4120,
806 July 2005.
808 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
809 for Transport Layer Security (TLS)", RFC 4279,
810 December 2005.
812 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
813 Flexible Authentication via Secure Tunneling Extensible
814 Authentication Protocol Method (EAP-FAST)", RFC 4851,
815 May 2007.
817 [SC97] Aura, T. and P. Nikander, "Stateless Connections",
818 Proceedings of the First International Conference on
819 Information and Communication Security (ICICS '97) , 1997.
821 [SHA1] National Institute of Standards and Technology, "Secure
822 Hash Standard (SHS)", Federal Information Processing
823 Standards (FIPS) Publication 180-2, August 2002.
826 Appendix A. Discussion of Changes to RFC4507
828 RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
829 without maintaining server side state by specifying an encrypted
830 ticket that is maintained on the client. The client presents this
831 ticket to the server in a SessionTicket hello extension. The
832 encoding in RFC 4507 used the XDR style encoding specified in TLS
833 [RFC4346].
835 An error in the encoding caused the specification to differ from
836 deployed implementations. At the time of this writing there are no
840 Salowey, et al. Expires December 13, 2007 [Page 15]
841 \f
842 Internet-Draft Stateless TLS Session Resumption June 2007
845 known implementations that follow the encoding specified in RFC 4507.
846 This update to RFC 4507 aligns the document with this currently
847 deployed implementations.
849 Erroneous encoding in RFC 4507 resulted in two length fields; one for
850 the extension contents and one for the ticket itself. Hence, for a
851 ticket that is 256 bytes long and begins with the hex value FF FF the
852 encoding of the extension would be as follows according to RFC 4507:
855 00 23 Ticket Extension type 35
856 01 02 Length of extension contents
857 01 00 Length of ticket
858 FF FF .. .. Actual ticket
860 The update proposed in this document reflects what implementations
861 actually encode, namely it removes the redundant length field. So,
862 for a ticket that is 256 bytes long and begins with the hex value FF
863 FF the encoding of the extension would be as follows according to
864 this update:
867 00 23 SessionTicket Extension type 35
868 01 00 Length of extension contents (ticket)
869 FF FF .. .. Actual ticket
871 A server implemented according to RFC 4507 receiving a ticket
872 extension from an client conforming to this document would interpret
873 the first two bytes of the ticket as the length of this ticket. This
874 will result in either an inconsistent length field or in the
875 processing of a ticket missing the first two bytes. In the first
876 case the server should reject the request based on a malformed length
877 and in the second case the server should reject the ticket based on a
878 malformed ticket, incorrect key version or failed decryption. A
879 server implementation based on this update receiving an RFC 4507
880 extension would interpret the first length field as the length of the
881 ticket and include the second two length bytes as the first bytes in
882 the ticket resulting in the ticket being rejected based on a
883 malformed ticket, incorrect key version or failed decryption.
885 A server implementation can construct tickets such that it can detect
886 an RFC 4507 implementation, if one existed, by including a cookie at
887 the beginning of the tickets that can be differentiated from a valid
888 length. For example, if an implementation constructed tickets to
889 start with the hex values FF FF then it could determine where the
890 ticket begins and determine the length correctly from the type of
891 length fields present.
896 Salowey, et al. Expires December 13, 2007 [Page 16]
897 \f
898 Internet-Draft Stateless TLS Session Resumption June 2007
901 Authors' Addresses
903 Joseph Salowey
904 Cisco Systems
905 2901 3rd Ave
906 Seattle, WA 98121
907 US
909 Email: jsalowey@cisco.com
912 Hao Zhou
913 Cisco Systems
914 4125 Highlander Parkway
915 Richfield, OH 44286
916 US
918 Email: hzhou@cisco.com
921 Pasi Eronen
922 Nokia Research Center
923 P.O. Box 407
924 FIN-00045 Nokia Group
925 Finland
927 Email: pasi.eronen@nokia.com
930 Hannes Tschofenig
931 Nokia Siemens Networks
932 Otto-Hahn-Ring 6
933 Munich, Bayern 81739
934 Germany
936 Email: Hannes.Tschofenig@siemens.com
952 Salowey, et al. Expires December 13, 2007 [Page 17]
953 \f
954 Internet-Draft Stateless TLS Session Resumption June 2007
957 Full Copyright Statement
959 Copyright (C) The IETF Trust (2007).
961 This document is subject to the rights, licenses and restrictions
962 contained in BCP 78, and except as set forth therein, the authors
963 retain all their rights.
965 This document and the information contained herein are provided on an
966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
968 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
969 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
970 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
974 Intellectual Property
976 The IETF takes no position regarding the validity or scope of any
977 Intellectual Property Rights or other rights that might be claimed to
978 pertain to the implementation or use of the technology described in
979 this document or the extent to which any license under such rights
980 might or might not be available; nor does it represent that it has
981 made any independent effort to identify any such rights. Information
982 on the procedures with respect to rights in RFC documents can be
983 found in BCP 78 and BCP 79.
985 Copies of IPR disclosures made to the IETF Secretariat and any
986 assurances of licenses to be made available, or the result of an
987 attempt made to obtain a general license or permission for the use of
988 such proprietary rights by implementers or users of this
989 specification can be obtained from the IETF on-line IPR repository at
990 http://www.ietf.org/ipr.
992 The IETF invites any interested party to bring to its attention any
993 copyrights, patents or patent applications, or other proprietary
994 rights that may cover technology that may be required to implement
995 this standard. Please address the information to the IETF at
996 ietf-ipr@ietf.org.
999 Acknowledgment
1001 Funding for the RFC Editor function is provided by the IETF
1002 Administrative Support Activity (IASA).
1008 Salowey, et al. Expires December 13, 2007 [Page 18]
1009 \f