idnits 2.17.1 draft-salowey-tls-ticket-04.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 468. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2005) is 6821 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 153, but not defined -- Looks like a reference, but probably isn't: '16' on line 223 -- Looks like a reference, but probably isn't: '20' on line 225 -- Looks like a reference, but probably isn't: '48' on line 245 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. 'I-D.ietf-tls-rfc2246-bis') == Outdated reference: A later version (-02) exists of draft-ietf-tls-rfc3546bis-01 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-02 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 5 errors (**), 0 flaws (~~), 5 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 Expires: February 2, 2006 Cisco Systems 5 P. Eronen 6 Nokia 7 H. Tschofenig 8 Siemens 9 August 2005 11 Transport Layer Security Session Resumption without Server-Side State 12 draft-salowey-tls-ticket-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 2, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes a mechanism which enables the Transport Layer 46 Security (TLS) server to resume sessions and avoid keeping per-client 47 session state. The TLS server encapsulates the session state into a 48 ticket and forwards it to the client. The client can subsequently 49 resume a session using the obtained ticket. This mechanism makes use 50 of new TLS handshake messages and TLS hello extensions. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2 Format of SessionTicket TLS extension . . . . . . . . . . 5 59 3.3 Format of NewSessionTicket handshake message . . . . . . . 5 60 4. Sample ticket construction . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 8 63 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 8 65 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 8 66 5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 9 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 71 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . 12 75 1. Introduction 77 This document defines a way to resume a Transport Layer Security 78 (TLS) [RFC2246] session without requiring session-specific state at 79 the TLS server. This mechanism may be used with any TLS ciphersuite. 80 The mechanism makes use of TLS extensions defined in [I-D.ietf-tls- 81 rfc3546bis] and defines a new TLS message type. 83 This mechanism is useful in the following types of situations 84 (1) servers that handle a large number of transactions from 85 different users 86 (2) servers that desire to cache sessions for a long time 87 (3) ability to load balance requests across servers 88 (4) embedded servers with little memory 90 2. Terminology 92 Within this document the term 'ticket' refers to a cryptographically 93 protected data structure which is created by the server and consumed 94 by the server to rebuild session specific state. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Protocol 102 3.1 Overview 104 The client indicates that it supports this mechanism by including a 105 SessionTicket TLS extension in the ClientHello message. The 106 extension will be empty if the client does not already possess a 107 ticket for the server. 109 If the server wants to use this mechanism, it stores its session 110 state (such as ciphersuite and master secret) to a ticket that is 111 encrypted and integrity-protected by a key known only to the server. 112 The ticket is distributed to the client using the NewSessionTicket 113 TLS handshake message. This message is sent during the TLS handshake 114 before the ChangeCipherSpec message after the server has verified the 115 client's Finished message. 117 Client Server 119 ClientHello --------> 120 (empty SessionTicket extension) 121 ServerHello 122 Certificate* 123 ServerKeyExchange* 124 CertificateRequest* 125 <-------- ServerHelloDone 126 Certificate* 127 ClientKeyExchange 128 CertificateVerify* 129 [ChangeCipherSpec] 130 Finished --------> 131 NewSessionTicket 132 [ChangeCipherSpec] 133 <-------- Finished 134 Application Data <-------> Application Data 136 The client caches this ticket along with the master secret, session 137 ID and other parameters associated with the current session. When 138 the client wishes to resume the session, it includes a SessionTicket 139 TLS extension in the SessionTicket extension within ClientHello 140 message. The server then verifies that the ticket has not been 141 tampered with, decrypts the contents, and retrieves the session state 142 from the contents of the ticket and uses this state to resume the 143 session. Since separate fields in the request are used for the 144 session ID and the ticket standard stateful session resume can co- 145 exist with the ticket based session resume described in this 146 specification. 148 ClientHello 149 (SessionTicket extension) --------> 150 ServerHello 151 [ChangeCipherSpec] 152 <-------- Finished 153 [ChangeCipherSpec] 154 Finished --------> 155 Application Data <-------> Application Data 157 Since the ticket is typically interpreted by the same server or group 158 of servers that created it, the exact format of the ticket does not 159 need to be the same for all implementations. A sample ticket format 160 is given in Section 4. If the server cannot or does not want to 161 honor the ticket then it can initiate a full handshake with the 162 client. 164 It is possible that the session ticket and master session key could 165 be delivered through some out of band mechanism. This behavior is 166 beyond the scope of the document and would need to be described in a 167 separate specification. 169 3.2 Format of SessionTicket TLS extension 171 The format of the ticket is an opaque structure used to carry session 172 specific state information. 174 struct { 175 opaque ticket<0..2^16-1>; 176 } SessionTicket; 178 The SessionTicket extension has been assigned the number TBD1. 180 3.3 Format of NewSessionTicket handshake message 182 This message is sent during the TLS handshake before the 183 ChangeCipherSpec message after the server has verified the client's 184 Finished message. 186 struct { 187 HandshakeType msg_type; 188 uint24 length; 189 select (HandshakeType) { 190 case hello_request: HelloRequest; 191 case client_hello: ClientHello; 192 case server_hello: ServerHello; 193 case certificate: Certificate; 194 case server_key_exchange: ServerKeyExchange; 195 case certificate_request: CertificateRequest; 196 case server_hello_done: ServerHelloDone; 197 case certificate_verify: CertificateVerify; 198 case client_key_exchange: ClientKeyExchange; 199 case finished: Finished; 200 case new_session_ticket: NewSessionTicket; /* NEW */ 201 } body; 202 } Handshake; 204 struct { 205 opaque ticket<0..2^16-1>; 206 } NewSessionTicket; 208 The NewSessionTicket handshake message has been assigned the number 209 TBD2. 211 4. Sample ticket construction 213 This section describes one possibility how the ticket could be 214 constructed, other implementations are possible. 216 The server uses two keys, one 128-bit key for AES encryption and one 217 128-bit key for HMAC-SHA1. 219 The ticket is structured as follows: 221 struct { 222 uint32 key_version; 223 opaque iv[16] 224 opaque encrypted_state<0..2^16-1>; 225 opaque mac[20]; 226 } ExampleTicket; 228 Here key_version identifies a particular set of keys. One 229 possibility is to generate new random keys every time the server is 230 started, and use the timestamp as the key version. The same 231 mechanisms known from a number of other protocols can be reused for 232 this purpose. 234 The actual state information in encrypted_state is encrypted using 235 128-bit AES in CBC mode with the given IV. The MAC is calculated 236 using HMAC-SHA1 over key_version (4 octets) and IV (16 octets), 237 followed by the contents of the encrypted_state field (without the 238 length). 240 struct { 241 ProtocolVersion protocol_version; 242 SessionID session_id; 243 CipherSuite cipher_suite; 244 CompressionMethod compression_method; 245 opaque master_secret[48]; 246 ExampleClientIdentity client_identity; 247 uint32 timestamp; 248 } ExampleStatePlaintext; 250 enum { 251 anonymous(0), 252 certificate_based(1), 253 psk(2) 254 } ExampleClientAuthenticationType; 256 struct { 257 ExampleClientAuthenticationType client_authentication_type; 258 select (ExampleClientAuthenticationType) { 259 case anonymous: struct {}; 260 case certificate_based: 261 ASN.1Cert certificate_list<0..2^24-1>; 262 case psk: 263 opaque psk_identity<0..2^16-1>; 265 } 266 } ExampleClientIdentity; 268 The structure ExampleStatePlaintext stores the TLS session state 269 including the SessionID and the master_secret. The timestamp within 270 this structure allows the TLS server to expire tickets. To cover the 271 authentication and key exchange protocols provided by TLS the 272 ExampleClientIdentity structure contains the authentication type of 273 the client used in the initial exchange (see 274 ExampleClientAuthenticationType). To offer the TLS server with the 275 same capabilities for authentication and authorization a certificate 276 list is included in case of public key based authentication. The TLS 277 server is therefore able to inspect a number of different attributes 278 within these certificates. A specific implementation might choose to 279 store a subset of this information. Other authentication mechanism 280 such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk] 281 would require different client identity data. 283 5. Security Considerations 285 This section addresses security issues related to the usage of a 286 ticket. Tickets must be sufficiently authenticated and encrypted to 287 prevent modification or eavesdropping by an attacker. Several 288 attacks described below will be possible if this is not carefully 289 done. 291 Implementations should take care to ensure that the processing of 292 tickets does not increase the chance of denial of serve as described 293 below. 295 5.1 Invalidating Sessions 297 The TLS specification requires that TLS sessions be invalidated when 298 errors occur. [CSSC] discusses the security implications of this in 299 detail. In the analysis in this paper, failure to invalidate 300 sessions does not pose a security risk. This is because the TLS 301 handshake uses a non-reversible function to derive keys for a session 302 so information about one session does not provide an advantage to 303 attack the master secret or a different session. If a session 304 invalidation scheme is used the implementation should verify the 305 integrity of the ticket before using the contents to invalidate a 306 session to ensure an attacker cannot invalidate a chosen session. 308 5.2 Stolen Tickets 310 An eavesdropper or man-in-the-middle may obtain the ticket and 311 attempt to use the ticket to establish a session with the server, 312 however since the ticket is encrypted and the attacker does not know 313 the secret key a stolen key does not help an attacker resume a 314 session. A TLS server MUST use strong encryption and integrity 315 protection for the ticket to prevent an attacker from using a brute 316 force mechanism to obtain the tickets contents. 318 5.3 Forged Tickets 320 A malicious user could forge or alter a ticket in order to resume a 321 session, to extend its lifetime, to impersonate as another user or 322 gain additional privileges. This attack is not possible if the 323 ticket is protected using a strong integrity protection algorithm 324 such as a keyed HMAC. 326 5.4 Denial of Service Attacks 328 An adversary could store or forge a large number of tickets to send 329 to the TLS server for verification. To minimize the possibility of a 330 denial of service the verification of the ticket should be 331 lightweight (e.g., using efficient symmetric key cryptographic 332 algorithms). 334 5.5 Ticket Protection Key Lifetime 336 The management of the keys used to protect the ticket is beyond the 337 scope of this document. It is advisable to limit the lifetime of 338 these keys to ensure they are not overused. 340 6. Acknowledgments 342 The authors would like to thank the following people for their help 343 with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget 344 and David McGrew. 346 [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS 347 ciphersuites, which helped inspire the use of tickets to avoid server 348 state. [I-D.cam-winget-eap-fast] makes use of a similar mechanism to 349 avoid maintaining server state for the cryptographic tunnel. 350 [AURA97] also investigates the concept of stateless sessions. [CSSC] 351 describes a solution that is very similar to the one described in 352 this document and gives a detailed analysis of the security 353 considerations involved. 355 7. IANA considerations 357 IANA has assigned a TLS extension number of TBD1 (the value 35 is 358 suggested) to the SessionTicket TLS extension from the TLS registry 359 of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis]. 361 IANA has assigned a TLS HandshakeType number TBD2 to the 362 NewSessionTicket handshake type from the TLS registry of 363 HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis]. 365 8. References 367 8.1 Normative References 369 [I-D.ietf-tls-rfc2246-bis] 370 Dierks, T. and E. Rescorla, "The TLS Protocol Version 371 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), 372 June 2005. 374 [I-D.ietf-tls-rfc3546bis] 375 Blake-Wilson, S., "Transport Layer Security (TLS) 376 Extensions", draft-ietf-tls-rfc3546bis-01 (work in 377 progress), May 2005. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 383 RFC 2246, January 1999. 385 8.2 Informative References 387 [AURA97] Aura, T. and P. Nikander, "Stateless Connections", 388 Proceedings of the First International Conference on 389 Information and Communication Security (ICICS '97) , 1997. 391 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client Side 392 Caching for TLS", 393 URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf. 395 [I-D.cam-winget-eap-fast] 396 Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP 397 Flexible Authentication via Secure Tunneling (EAP-FAST)", 398 draft-cam-winget-eap-fast-02 (work in progress), 399 April 2005. 401 [I-D.ietf-tls-psk] 402 Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 403 for Transport Layer Security (TLS)", draft-ietf-tls-psk-09 404 (work in progress), June 2005. 406 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 407 Authentication Service (V5)", RFC 1510, September 1993. 409 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 410 Suites to Transport Layer Security (TLS)", RFC 2712, 411 October 1999. 413 Authors' Addresses 415 Joseph Salowey 416 Cisco Systems 417 2901 3rd Ave 418 Seattle, WA 98121 419 US 421 Email: jsalowey@cisco.com 422 Hao Zhou 423 Cisco Systems 424 4125 Highlander Parkway 425 Richfield, OH 44286 426 US 428 Email: hzhou@cisco.com 430 Pasi Eronen 431 Nokia Research Center 432 P.O. Box 407 433 FIN-00045 Nokia Group 434 Finland 436 Email: pasi.eronen@nokia.com 438 Hannes Tschofenig 439 Siemens 440 Otto-Hahn-Ring 6 441 Munich, Bayern 81739 442 Germany 444 Email: Hannes.Tschofenig@siemens.com 446 Intellectual Property Statement 448 The IETF takes no position regarding the validity or scope of any 449 Intellectual Property Rights or other rights that might be claimed to 450 pertain to the implementation or use of the technology described in 451 this document or the extent to which any license under such rights 452 might or might not be available; nor does it represent that it has 453 made any independent effort to identify any such rights. Information 454 on the procedures with respect to rights in RFC documents can be 455 found in BCP 78 and BCP 79. 457 Copies of IPR disclosures made to the IETF Secretariat and any 458 assurances of licenses to be made available, or the result of an 459 attempt made to obtain a general license or permission for the use of 460 such proprietary rights by implementers or users of this 461 specification can be obtained from the IETF on-line IPR repository at 462 http://www.ietf.org/ipr. 464 The IETF invites any interested party to bring to its attention any 465 copyrights, patents or patent applications, or other proprietary 466 rights that may cover technology that may be required to implement 467 this standard. Please address the information to the IETF at 468 ietf-ipr@ietf.org. 470 Disclaimer of Validity 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Copyright Statement 482 Copyright (C) The Internet Society (2005). This document is subject 483 to the rights, licenses and restrictions contained in BCP 78, and 484 except as set forth therein, the authors retain all their rights. 486 Acknowledgment 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.