idnits 2.17.1 draft-salowey-tls-rfc4507bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 27, 2007) is 6086 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 253, but not defined -- Looks like a reference, but probably isn't: '16' on line 396 -- Looks like a reference, but probably isn't: '32' on line 398 -- Looks like a reference, but probably isn't: '48' on line 417 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4507 (Obsoleted by RFC 5077) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft H. Zhou 4 Obsoletes: 4507 (if approved) Cisco Systems 5 Intended status: Standards Track P. Eronen 6 Expires: February 28, 2008 Nokia 7 H. Tschofenig 8 Nokia Siemens Networks 9 August 27, 2007 11 Transport Layer Security (TLS) Session Resumption without Server-Side 12 State 13 draft-salowey-tls-rfc4507bis-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 28, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes a mechanism that enables the Transport Layer 47 Security (TLS) server to resume sessions and avoid keeping per-client 48 session state. The TLS server encapsulates the session state into a 49 ticket and forwards it to the client. The client can subsequently 50 resume a session using the obtained ticket. This document obsoletes 51 RFC 4507. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7 60 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8 61 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9 62 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12 65 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12 66 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12 67 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 68 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13 69 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13 70 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13 71 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Appendix A. Discussion of Changes to RFC4507 . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . . . . 19 81 1. Introduction 83 This document defines a way to resume a Transport Layer Security 84 (TLS) session without requiring session-specific state at the TLS 85 server. This mechanism may be used with any TLS ciphersuite. This 86 document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1 87 defined in [RFC4346]. The mechanism makes use of TLS extensions 88 defined in [RFC4366] and defines a new TLS message type. 90 This mechanism is useful in the following situations: 92 1. servers that handle a large number of transactions from 93 different users 94 2. servers that desire to cache sessions for a long time 95 3. ability to load balance requests across servers 96 4. embedded servers with little memory 98 This document obsoletes RFC 4507 [RFC4507] to correct an error in the 99 encoding that caused the specification to differ from deployed 100 implementations. At the time of this writing there are no known 101 implementations that follow the encoding specified in RFC 4507. This 102 update to RFC 4507 aligns the document with this currently deployed 103 implementations. More details of the change are given in Appendix A. 105 2. Terminology 107 Within this document, the term 'ticket' refers to a cryptographically 108 protected data structure that is created by the server and consumed 109 by the server to rebuild session-specific state. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Protocol 117 This specification describes a mechanism to distribute encrypted 118 session-state information to the client in the form of a ticket and a 119 mechanism to present the ticket back to the server. The ticket is 120 created by a TLS server and sent to a TLS client. The TLS client 121 presents the ticket to the TLS server to resume a session. 122 Implementations of this specification are expected to support both 123 mechanisms. Other specifications can take advantage of the session 124 tickets, perhaps specifying alternative means for distribution or 125 selection. For example, a separate specification may describe an 126 alternate way to distribute a ticket and use the TLS extension in 127 this document to resume the session. This behavior is beyond the 128 scope of the document and would need to be described in a separate 129 specification. 131 3.1. Overview 133 The client indicates that it supports this mechanism by including a 134 SessionTicket TLS extension in the ClientHello message. The 135 extension will be empty if the client does not already possess a 136 ticket for the server. The extension is described in Section 3.2. 138 If the server wants to use this mechanism, it stores its session 139 state (such as ciphersuite and master secret) to a ticket that is 140 encrypted and integrity-protected by a key known only to the server. 141 The ticket is distributed to the client using the NewSessionTicket 142 TLS handshake message described in Section 3.3. This message is sent 143 during the TLS handshake before the ChangeCipherSpec message, after 144 the server has successfully verified the client's Finished message. 146 Client Server 148 ClientHello 149 (empty SessionTicket extension)--------> 150 ServerHello 151 (empty SessionTicket extension) 152 Certificate* 153 ServerKeyExchange* 154 CertificateRequest* 155 <-------- ServerHelloDone 156 Certificate* 157 ClientKeyExchange 158 CertificateVerify* 159 [ChangeCipherSpec] 160 Finished --------> 161 NewSessionTicket 162 [ChangeCipherSpec] 163 <-------- Finished 164 Application Data <-------> Application Data 166 Figure 1: Message flow for full handshake issuing new session ticket 168 The client caches this ticket along with the master secret and other 169 parameters associated with the current session. When the client 170 wishes to resume the session, it includes the ticket in the 171 SessionTicket extension within the ClientHello message. The server 172 then decrypts the received ticket, verifies the ticket's validity, 173 retrieves the session state from the contents of the ticket, and uses 174 this state to resume the session. The interaction with the TLS 175 Session ID is described in Section 3.4. If the server successfully 176 verifies the client's ticket, then it may renew the ticket by 177 including a NewSessionTicket handshake message after the ServerHello. 179 Client Server 180 ClientHello 181 (SessionTicket extension) --------> 182 ServerHello 183 (empty SessionTicket extension) 184 NewSessionTicket 185 [ChangeCipherSpec] 186 <-------- Finished 187 [ChangeCipherSpec] 188 Finished --------> 189 Application Data <-------> Application Data 191 Figure 2: Message flow for abbreviated handshake using new session 192 ticket 194 A recommended ticket format is given in Section 4. 196 If the server cannot or does not want to honor the ticket, then it 197 can initiate a full handshake with the client. 199 In the case that the server does not wish to issue a new ticket at 200 this time, it just completes the handshake without including a 201 SessionTicket extension or NewSessionTicket handshake message. This 202 is shown below (this flow is identical to Figure 1 in RFC 4346, 203 except for the session ticket extension in the first message): 205 Client Server 207 ClientHello 208 (SessionTicket extension) --------> 209 ServerHello 210 Certificate* 211 ServerKeyExchange* 212 CertificateRequest* 213 <-------- ServerHelloDone 214 Certificate* 215 ClientKeyExchange 216 CertificateVerify* 217 [ChangeCipherSpec] 218 Finished --------> 219 [ChangeCipherSpec] 220 <-------- Finished 221 Application Data <-------> Application Data 223 Figure 3: Message flow for server completing full handshake without 224 issuing new session ticket 226 It is also permissible to have an exchange similar to Figure 3 using 227 the abbreviated handshake defined in Figure 2 of RFC 4346 where the 228 client uses the SessionTicket extension to resume the session, but 229 the server does not wish issue a new ticket and therefore does not 230 send a SessionTicket extension. 232 If the server rejects the ticket, it may still wish to issue a new 233 ticket after performing the full handshake as shown below (this flow 234 is identical to Figure 1, except the SessionTicket extension in the 235 Client Hello is not empty): 237 Client Server 239 ClientHello 240 (SessionTicket extension) --------> 241 ServerHello 242 (empty SessionTicket extension) 243 Certificate* 244 ServerKeyExchange* 245 CertificateRequest* 246 <-------- ServerHelloDone 247 Certificate* 248 ClientKeyExchange 249 CertificateVerify* 250 [ChangeCipherSpec] 251 Finished --------> 252 NewSessionTicket 253 [ChangeCipherSpec] 254 <-------- Finished 255 Application Data <-------> Application Data 257 Figure 4: Message flow for server rejecting ticket, performing full 258 handshake and issuing new session ticket 260 3.2. SessionTicket TLS Extension 262 The SessionTicket TLS extension is based on [RFC4366]. The format of 263 the ticket is an opaque structure used to carry session-specific 264 state information. This extension may be sent in the ClientHello and 265 ServerHello. 267 If the client possesses a ticket that it wants to use to resume a 268 session, then it includes the ticket in the SessionTicket extension 269 in the ClientHello. If the client does not have a ticket and is 270 prepared to receive one in the NewSessionTicket handshake message, 271 then it MUST include a zero-length ticket in the SessionTicket 272 extension. If the client is not prepared to receive a ticket in the 273 NewSessionTicket handshake message then it MUST NOT include a 274 SessionTicket extension unless it is sending a non-empty ticket it 275 received through some other means from the server. 277 The server uses an zero-length SessionTicket extension to indicate to 278 the client that it will send a new session ticket using the 279 NewSessionTicket handshake message described in Section 3.3. The 280 server MUST send this extension in the ServerHello if it wishes to 281 issue a new ticket to the client using the NewSessionTicket handshake 282 message. The server MUST NOT send this extension if it does not 283 receive one in the ClientHello. 285 If the server fails to verify the ticket, then it falls back to 286 performing a full handshake. If the ticket is accepted by the server 287 but the handshake fails, the client SHOULD delete the ticket. 289 The SessionTicket extension has been assigned the number 35. The 290 extension_data field of SessionTicket extension contains the ticket. 292 3.3. NewSessionTicket Handshake Message 294 This message is sent by the server during the TLS handshake before 295 the ChangeCipherSpec message. This message MUST be sent if the 296 server included a SessionTicket extension in the ServerHello. This 297 message MUST NOT be sent if the server did not include a 298 SessionTicket extension in the ServerHello. This message is included 299 in the hash used to create and verify the Finished message. In the 300 case of a full handshake, the server MUST verify the client's 301 Finished message before sending the ticket. The client MUST NOT 302 treat the ticket as valid until it has verified the server's Finished 303 message. If the server determines that it does not want to include a 304 ticket after it has included the SessionTicket extension in the 305 ServerHello, then it sends a zero-length ticket in the 306 NewSessionTicket handshake message. 308 If the server successfully verifies the client's ticket, then it MAY 309 renew the ticket by including a NewSessionTicket handshake message 310 after the ServerHello in the abbreviated handshake. The client 311 should start using the new ticket as soon as possible after it 312 verifies the server's Finished message for new connections. Note 313 that since the updated ticket is issued before the handshake 314 completes, it is possible that the client may not put the new ticket 315 into use before it initiates new connections. The server MUST NOT 316 assume that the client actually received the updated ticket until it 317 successfully verifies the client's Finished message. 319 The NewSessionTicket handshake message has been assigned the number 4 320 and its definition is given at the end of this section. The 321 ticket_lifetime_hint field contains a hint from the server about how 322 long the ticket should be stored. The value indicates the lifetime 323 in seconds as a 32-bit unsigned integer in network byte order. A 324 value of zero is reserved to indicate that the lifetime of the ticket 325 is unspecified. A client SHOULD delete the ticket and associated 326 state when the time expires. It MAY delete the ticket earlier based 327 on local policy. A server MAY treat a ticket as valid for a shorter 328 or longer period of time than what is stated in the 329 ticket_lifetime_hint. 331 struct { 332 HandshakeType msg_type; 333 uint24 length; 334 select (HandshakeType) { 335 case hello_request: HelloRequest; 336 case client_hello: ClientHello; 337 case server_hello: ServerHello; 338 case certificate: Certificate; 339 case server_key_exchange: ServerKeyExchange; 340 case certificate_request: CertificateRequest; 341 case server_hello_done: ServerHelloDone; 342 case certificate_verify: CertificateVerify; 343 case client_key_exchange: ClientKeyExchange; 344 case finished: Finished; 345 case session_ticket: NewSessionTicket; /* NEW */ 346 } body; 347 } Handshake; 349 struct { 350 uint32 ticket_lifetime_hint; 351 opaque ticket<0..2^16-1>; 352 } NewSessionTicket; 354 3.4. Interaction with TLS Session ID 356 If a server is planning on issuing a SessionTicket to a client that 357 does not present one, it SHOULD include an empty Session ID in the 358 ServerHello. If the server includes a non-empty session ID, then it 359 is indicating intent to use stateful session resume. If the client 360 receives a SessionTicket from the server, then it discards any 361 Session ID that was sent in the ServerHello. 363 When presenting a ticket, the client MAY generate and include a 364 Session ID in the TLS ClientHello. If the server accepts the ticket 365 and the Session ID is not empty, then it MUST respond with the same 366 Session ID present in the ClientHello. This allows the client to 367 easily differentiate when the server is resuming a session from when 368 it is falling back to a full handshake. Since the client generates a 369 Session ID, the server MUST NOT rely upon the Session ID having a 370 particular value when validating the ticket. If a ticket is 371 presented by the client, the server MUST NOT attempt to use the 372 Session ID in the ClientHello for stateful session resume. 373 Alternatively, the client MAY include an empty Session ID in the 374 ClientHello. In this case, the client ignores the Session ID sent in 375 the ServerHello and determines if the server is resuming a session by 376 the subsequent handshake messages. 378 4. Recommended Ticket Construction 380 This section describes a recommended format and protection for the 381 ticket. Note that the ticket is opaque to the client, so the 382 structure is not subject to interoperability concerns, and 383 implementations may diverge from this format. If implementations do 384 diverge from this format, they must take security concerns seriously. 385 Clients MUST NOT examine the ticket under the assumption that it 386 complies with this document. 388 The server uses two different keys: one 128-bit key for AES [AES] in 389 CBC mode [CBC] encryption and one 256-bit key for HMAC-SHA-256 390 [RFC4634]. 392 The ticket is structured as follows: 394 struct { 395 opaque key_name[16]; 396 opaque iv[16]; 397 opaque encrypted_state<0..2^16-1>; 398 opaque mac[32]; 399 } ticket; 401 Here, key_name serves to identify a particular set of keys used to 402 protect the ticket. It enables the server to easily recognize 403 tickets it has issued. The key_name should be randomly generated to 404 avoid collisions between servers. One possibility is to generate new 405 random keys and key_name every time the server is started. 407 The actual state information in encrypted_state is encrypted using 408 128-bit AES in CBC mode with the given IV. The MAC is calculated 409 using HMAC-SHA-256 over key_name (16 octets)and IV (16 octets), 410 followed by the length of the encrypted_state field (2 octets) and 411 its contents (variable length). 413 struct { 414 ProtocolVersion protocol_version; 415 CipherSuite cipher_suite; 416 CompressionMethod compression_method; 417 opaque master_secret[48]; 418 ClientIdentity client_identity; 419 uint32 timestamp; 420 } StatePlaintext; 422 enum { 423 anonymous(0), 424 certificate_based(1), 425 psk(2) 426 } ClientAuthenticationType; 428 struct { 429 ClientAuthenticationType client_authentication_type; 430 select (ClientAuthenticationType) { 431 case anonymous: struct {}; 432 case certificate_based: 433 ASN.1Cert certificate_list<0..2^24-1>; 434 case psk: 435 opaque psk_identity<0..2^16-1>; /* from [RFC4279] */ 437 } 438 } ClientIdentity; 440 The structure StatePlaintext stores the TLS session state including 441 the master_secret. The timestamp within this structure allows the 442 TLS server to expire tickets. To cover the authentication and key 443 exchange protocols provided by TLS, the ClientIdentity structure 444 contains the authentication type of the client used in the initial 445 exchange (see ClientAuthenticationType). To offer the TLS server 446 with the same capabilities for authentication and authorization, a 447 certificate list is included in case of public-key-based 448 authentication. The TLS server is therefore able to inspect a number 449 of different attributes within these certificates. A specific 450 implementation might choose to store a subset of this information or 451 additional information. Other authentication mechanisms, such as 452 Kerberos [RFC2712], would require different client identity data. 453 Other TLS extensions may require the inclusion of additional data in 454 the StatePlaintext structure. 456 5. Security Considerations 458 This section addresses security issues related to the usage of a 459 ticket. Tickets must be authenticated and encrypted to prevent 460 modification or eavesdropping by an attacker. Several attacks 461 described below will be possible if this is not carefully done. 463 Implementations should take care to ensure that the processing of 464 tickets does not increase the chance of denial of service as 465 described below. 467 5.1. Invalidating Sessions 469 The TLS specification requires that TLS sessions be invalidated when 470 errors occur. [CSSC] discusses the security implications of this in 471 detail. In the analysis in this paper, failure to invalidate 472 sessions does not pose a security risk. This is because the TLS 473 handshake uses a non-reversible function to derive keys for a session 474 so information about one session does not provide an advantage to 475 attack the master secret or a different session. If a session 476 invalidation scheme is used, the implementation should verify the 477 integrity of the ticket before using the contents to invalidate a 478 session to ensure that an attacker cannot invalidate a chosen 479 session. 481 5.2. Stolen Tickets 483 An eavesdropper or man-in-the-middle may obtain the ticket and 484 attempt to use the ticket to establish a session with the server; 485 however, since the ticket is encrypted and the attacker does not know 486 the secret key, a stolen ticket does not help an attacker resume a 487 session. A TLS server MUST use strong encryption and integrity 488 protection for the ticket to prevent an attacker from using a brute 489 force mechanism to obtain the ticket's contents. 491 5.3. Forged Tickets 493 A malicious user could forge or alter a ticket in order to resume a 494 session, to extend its lifetime, to impersonate as another user, or 495 to gain additional privileges. This attack is not possible if the 496 ticket is protected using a strong integrity protection algorithm 497 such as a keyed HMAC-SHA-256. 499 5.4. Denial of Service Attacks 501 The key_name field defined in the recommended ticket format helps the 502 server efficiently reject tickets that it did not issue. However, an 503 adversary could store or generate a large number of tickets to send 504 to the TLS server for verification. To minimize the possibility of a 505 denial of service, the verification of the ticket should be 506 lightweight (e.g., using efficient symmetric key cryptographic 507 algorithms). 509 5.5. Ticket Protection Key Management 511 A full description of the management of the keys used to protect the 512 ticket is beyond the scope of this document. A list of RECOMMENDED 513 practices is given below. 515 o The keys should be generated securely following the randomness 516 recommendations in [RFC4086]. 517 o The keys and cryptographic protection algorithms should be at 518 least 128 bits in strength. 519 o The keys should not be used for any other purpose than generating 520 and verifying tickets. 521 o The keys should be changed regularly. 522 o The keys should be changed if the ticket format or cryptographic 523 protection algorithms change. 525 5.6. Ticket Lifetime 527 The TLS server controls the lifetime of the ticket. Servers 528 determine the acceptable lifetime based on the operational and 529 security requirements of the environments in which they are deployed. 530 The ticket lifetime may be longer than the 24-hour lifetime 531 recommended in [RFC4346]. TLS clients may be given a hint of the 532 lifetime of the ticket. Since the lifetime of a ticket may be 533 unspecified, a client has its own local policy that determines when 534 it discards tickets. 536 5.7. Alternate Ticket Formats and Distribution Schemes 538 If the ticket format or distribution scheme defined in this document 539 is not used, then great care must be taken in analyzing the security 540 of the solution. In particular, if confidential information, such as 541 a secret key, is transferred to the client, it MUST be done using 542 secure communication so as to prevent attackers from obtaining or 543 modifying the key. Also, the ticket MUST have its integrity and 544 confidentiality protected with strong cryptographic techniques to 545 prevent a breach in the security of the system. 547 5.8. Identity Privacy, Anonymity, and Unlinkability 549 This document mandates that the content of the ticket is 550 confidentiality protected in order to avoid leakage of its content, 551 such as user-relevant information. As such, it prevents disclosure 552 of potentially sensitive information carried within the ticket. 554 The initial handshake exchange, which was used to obtain the ticket, 555 might not provide identity confidentiality of the client based on the 556 properties of TLS. Another relevant security threat is the ability 557 for an on-path adversary to observe multiple TLS handshakes where the 558 same ticket is used and therefore to conclude that they belong to the 559 same communication endpoints. Application designers that use the 560 ticket mechanism described in this document should consider that 561 unlinkability [ANON] is not necessarily provided. 563 While a full discussion of these topics is beyond the scope of this 564 document, it should be noted that it is possible to issue a ticket 565 using a TLS renegotiation handshake that occurs after a secure tunnel 566 has been established by a previous handshake. This may help address 567 some privacy and unlinkability issues in some environments. 569 6. Acknowledgements 571 The authors would like to thank the following people for their help 572 with preparing and reviewing this document: Eric Rescorla, Mohamad 573 Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, 574 Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of 575 the TLS working group. 577 [CSSC] describes a solution that is very similar to the one described 578 in this document and gives a detailed analysis of the security 579 considerations involved. [RFC2712] describes a mechanism for using 580 Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use 581 of tickets to avoid server state. [RFC4851] makes use of a similar 582 mechanism to avoid maintaining server state for the cryptographic 583 tunnel. [SC97] also investigates the concept of stateless sessions. 585 The authors would also like to thank Jan Nordqvist who found the 586 encoding error in RFC 4507 corrected by this document. 588 7. IANA Considerations 590 IANA has assigned a TLS extension number of 35 to the SessionTicket 591 TLS extension from the TLS registry of ExtensionType values defined 592 in [RFC4366]. 594 IANA has assigned a TLS HandshakeType number 4 to the 595 NewSessionTicket handshake type from the TLS registry of 596 HandshakeType values defined in [RFC4346]. 598 This document does not require any actions or assignments from IANA. 600 8. References 601 8.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 607 RFC 2246, January 1999. 609 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 610 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 612 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 613 and T. Wright, "Transport Layer Security (TLS) 614 Extensions", RFC 4366, April 2006. 616 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 617 "Transport Layer Security (TLS) Session Resumption without 618 Server-Side State", RFC 4507, May 2006. 620 8.2. Informative References 622 [AES] National Institute of Standards and Technology, "Advanced 623 Encryption Standard (AES)", Federal Information 624 Processing Standards (FIPS) Publication 197, 625 November 2001. 627 [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability, 628 Unobservability, Pseudonymity, and Identity Management - A 629 Consolidated Proposal for Terminology", http:// 630 dud.inf.tu-dresden.de/literatur/ 631 Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005. 633 [CBC] National Institute of Standards and Technology, 634 "Recommendation for Block Cipher Modes of Operation - 635 Methods and Techniques", NIST Special Publication 800-38A, 636 December 2001. 638 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side 639 caching for TLS", Transactions on Information and 640 System Security (TISSEC) , Volume 7, Issue 4, 641 November 2004. 643 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 644 Suites to Transport Layer Security (TLS)", RFC 2712, 645 October 1999. 647 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 648 Requirements for Security", BCP 106, RFC 4086, June 2005. 650 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 651 Kerberos Network Authentication Service (V5)", RFC 4120, 652 July 2005. 654 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 655 for Transport Layer Security (TLS)", RFC 4279, 656 December 2005. 658 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 659 (SHA and HMAC-SHA)", RFC 4634, July 2006. 661 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 662 Flexible Authentication via Secure Tunneling Extensible 663 Authentication Protocol Method (EAP-FAST)", RFC 4851, 664 May 2007. 666 [SC97] Aura, T. and P. Nikander, "Stateless Connections", 667 Proceedings of the First International Conference on 668 Information and Communication Security (ICICS '97) , 1997. 670 Appendix A. Discussion of Changes to RFC4507 672 RFC 4507 [RFC4507] defines a mechanism to resume a TLS session 673 without maintaining server side state by specifying an encrypted 674 ticket that is maintained on the client. The client presents this 675 ticket to the server in a SessionTicket hello extension. The 676 encoding in RFC 4507 used the XDR style encoding specified in TLS 677 [RFC4346]. 679 An error in the encoding caused the specification to differ from 680 deployed implementations. At the time of this writing there are no 681 known implementations that follow the encoding specified in RFC 4507. 682 This update to RFC 4507 aligns the document with this currently 683 deployed implementations. 685 Erroneous encoding in RFC 4507 resulted in two length fields; one for 686 the extension contents and one for the ticket itself. Hence, for a 687 ticket that is 256 bytes long and begins with the hex value FF FF the 688 encoding of the extension would be as follows according to RFC 4507: 690 00 23 Ticket Extension type 35 691 01 02 Length of extension contents 692 01 00 Length of ticket 693 FF FF .. .. Actual ticket 695 The update proposed in this document reflects what implementations 696 actually encode, namely it removes the redundant length field. So, 697 for a ticket that is 256 bytes long and begins with the hex value FF 698 FF the encoding of the extension would be as follows according to 699 this update: 701 00 23 SessionTicket Extension type 35 702 01 00 Length of extension contents (ticket) 703 FF FF .. .. Actual ticket 705 A server implemented according to RFC 4507 receiving a ticket 706 extension from an client conforming to this document would interpret 707 the first two bytes of the ticket as the length of this ticket. This 708 will result in either an inconsistent length field or in the 709 processing of a ticket missing the first two bytes. In the first 710 case the server should reject the request based on a malformed length 711 and in the second case the server should reject the ticket based on a 712 malformed ticket, incorrect key version or failed decryption. A 713 server implementation based on this update receiving an RFC 4507 714 extension would interpret the first length field as the length of the 715 ticket and include the second two length bytes as the first bytes in 716 the ticket resulting in the ticket being rejected based on a 717 malformed ticket, incorrect key version or failed decryption. 719 A server implementation can construct tickets such that it can detect 720 an RFC 4507 implementation, if one existed, by including a cookie at 721 the beginning of the tickets that can be differentiated from a valid 722 length. For example, if an implementation constructed tickets to 723 start with the hex values FF FF then it could determine where the 724 ticket begins and determine the length correctly from the type of 725 length fields present. 727 Authors' Addresses 729 Joseph Salowey 730 Cisco Systems 731 2901 3rd Ave 732 Seattle, WA 98121 733 US 735 Email: jsalowey@cisco.com 736 Hao Zhou 737 Cisco Systems 738 4125 Highlander Parkway 739 Richfield, OH 44286 740 US 742 Email: hzhou@cisco.com 744 Pasi Eronen 745 Nokia Research Center 746 P.O. Box 407 747 FIN-00045 Nokia Group 748 Finland 750 Email: pasi.eronen@nokia.com 752 Hannes Tschofenig 753 Nokia Siemens Networks 754 Otto-Hahn-Ring 6 755 Munich, Bayern 81739 756 Germany 758 Email: Hannes.Tschofenig@siemens.com 760 Full Copyright Statement 762 Copyright (C) The IETF Trust (2007). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Intellectual Property 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org. 800 Acknowledgment 802 Funding for the RFC Editor function is provided by the IETF 803 Administrative Support Activity (IASA).