idnits 2.17.1 draft-salowey-tls-ticket-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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 463), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 19, 2004) is 7161 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 146, but not defined -- Looks like a reference, but probably isn't: '16' on line 211 -- Looks like a reference, but probably isn't: '20' on line 213 -- Looks like a reference, but probably isn't: '48' on line 233 == Unused Reference: 'TLS' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group J. Salowey 3 Internet-Draft H. Zhou 4 Expires: February 17, 2005 Cisco Systems 5 P. Eronen 6 Nokia 7 H. Tschofenig 8 Siemens 9 August 19, 2004 11 TLS Session Resumption without Server-Side State 12 draft-salowey-tls-ticket-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 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 24 Internet-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 17, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document describes a mechanism which enables the TLS server to 46 resume sessions and avoid keeping per-client session state. The TLS 47 server encapsulates the session state into a ticket and forwards it 48 to the client. The client can subsequently resume a session using 49 the obtained ticket. This mechanism makes use of TLS extensions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2 Format of SessionTicket TLS extension . . . . . . . . . . 5 58 3.3 Format of NewSessionTicket handshake message . . . . . . . 5 59 4. Sample ticket construction . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5.1 Stolen Ticket . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3 Forged Ticket . . . . . . . . . . . . . . . . . . . . . . 8 64 5.4 Privilege Escalation Attack . . . . . . . . . . . . . . . 8 65 5.5 Denial of Service Attacks . . . . . . . . . . . . . . . . 8 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 70 8.2 Informative References . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . 11 74 1. Introduction 76 This document defines a way to resume a TLS session without requiring 77 session-specific state at the TLS server. This mechanism is not tied 78 to any particular TLS ciphersuite, but can be used with any of them. 79 The mechanism makes use of TLS extensions [RFC3546] and defines a 80 new TLS message type. 82 This mechanism is useful in the following types of situations 83 (1) servers that handle a large number of transactions from 84 different users 85 (2) servers that desire to cache sessions for a long time 86 (3) ability to load balance requests across servers 87 (4) embedded servers with little memory 89 2. Terminology 91 Within this document the term 'ticket' refers to a data structure 92 which is created by the server and used to rebuild session specific 93 state. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Protocol 101 3.1 Overview 103 The client indicates that it supports this mechanism by including an 104 empty SessionTicket TLS extension in the ClientHello message. 106 If the server wants to use this mechanism, it stores its session 107 state (such as ciphersuite and master secret) to a ticket that is 108 encrypted and integrity-protected by a key known only to the server. 109 One mechanism to deliver this ticket to the client using a new TLS 110 handshake message, NewSessionTicket. Other mechanisms for 111 distributing tickets and keys are possible, but they are beyond the 112 scope of this document. 114 Client Server 116 ClientHello --------> 117 SessionTicket (empty) 118 ServerHello 119 Certificate* 120 ServerKeyExchange* 121 CertificateRequest* 122 <-------- ServerHelloDone 123 Certificate* 124 ClientKeyExchange 125 CertificateVerify* 126 [ChangeCipherSpec] 127 Finished --------> 128 [ChangeCipherSpec] 129 NewSessionTicket 130 <-------- Finished 131 Application Data <-------> Application Data 133 The client caches this ticket along with the master secret and 134 session ID associated with the current session. When the client 135 wishes to resume the session, it includes a SessionTicket TLS 136 extension in the ClientHello message. The server then verifies that 137 the ticket has not been tampered with, decrypts the contents, and 138 retrieves the session state it needs to resume a session in a normal 139 way. 141 ClientHello 142 SessionTicket extension --------> 143 ServerHello 144 [ChangeCipherSpec] 145 <-------- Finished 146 [ChangeCipherSpec] 147 Finished --------> 148 Application Data <-------> Application Data 150 Since the ticket is interpreted by the same server that created it, 151 the exact format of the ticket does not need to be the same for all 152 implementations. A sample ticket format is given in Section 4. If 153 the server cannot or does not want to honor the ticket then it can 154 initiate a full handshake with the client. 156 It is possible that the session ticket and and master session key 157 could be delivered through some out of band mechanism. This behavior 158 is beyond the scope of the document and would need to be described in 159 a separate specification. 161 3.2 Format of SessionTicket TLS extension 163 The format of the ticket is an opaque structure used to carry session 164 specific state information. 166 struct { 167 opaque ticket<0..2^16-1>; 168 } SessionTicket; 170 3.3 Format of NewSessionTicket handshake message 172 This message can be sent at any point in the TLS conversation. 173 Typically this would be before the Finished message. Would it be 174 better to distribute it after the proection has started to prevent a 175 bad ticket from being inserted? 177 struct { 178 HandshakeType msg_type; 179 uint24 length; 180 select (HandshakeType) { 181 case hello_request: HelloRequest; 182 case client_hello: ClientHello; 183 case server_hello: ServerHello; 184 case certificate: Certificate; 185 case server_key_exchange: ServerKeyExchange; 186 case certificate_request: CertificateRequest; 187 case server_hello_done: ServerHelloDone; 188 case certificate_verify: CertificateVerify; 189 case client_key_exchange: ClientKeyExchange; 190 case finished: Finished; 191 case new_session_ticket: NewSessionTicket; /* NEW */ 192 } body; 193 } Handshake; 195 struct { 196 opaque ticket<0..2^16-1>; 197 } NewSessionTicket; 199 4. Sample ticket construction 201 This section describes one possibility how the ticket could be 202 constructed, other implementations are possible. 204 The server uses two keys, one 128-bit key for AES encryption and one 205 128-bit key for HMAC-SHA1. 207 The ticket is structured as follows: 209 struct { 210 uint32 key_version; 211 opaque iv[16] 212 opaque encrypted_state<0..2^16-1>; 213 opaque mac[20]; 214 } ExampleTicket; 216 Here key_version identifies a particular set of keys. One 217 possibility is to generate new random keys every time the server is 218 started, and use the timestamp as the key version. The same 219 mechanisms known from a number of other protocols can be reused for 220 this purpose. 222 The actual state information in encrypted_state is encrypted using 223 128-bit AES in CBC mode with the given IV. The MAC is calculated 224 using HMAC-SHA1 over key_version (4 octets) and IV (16 octets), 225 followed by the contents of the encrypted_state field (without the 226 length). 228 struct { 229 ProtocolVersion protocol_version; 230 SessionID session_id; 231 CipherSuite cipher_suite; 232 CompressionMethod compression_method; 233 opaque master_secret[48]; 234 ClientIdentity client_identity; 235 uint32 timestamp; 236 } ExampleStatePlaintext; 238 enum { 239 anonymous(0), 240 certificate_based(1) 241 } ExampleClientAuthenticationType; 243 struct { 244 ExampleClientAuthenticationType client_authentication_type; 245 select (ExampleClientAuthenticationType) { 246 case anonymous: struct {}; 247 case certificate_based: 248 ASN.1Cert certificate_list<0..2^24-1>; 249 } 250 } ExampleClientIdentity; 252 In ExampleStatePlaintext the TLS session state including the 253 SessionID and the master_secret is stored. The timestamp within this 254 structure assures that the TLS server is able to expire tickets. To 255 cover the authentication and key exchange protocols provided by TLS 256 the ExampleClientIdentity structure contains the authentication type 257 of the client used in the initial exchange (see 258 ExampleClientAuthenticationType). To offer the TLS server with the 259 same capabilities for authentication and authorization a certificate 260 list is included in case of public key based authentication. The TLS 261 server is therefore able to inspect a number of different attributes 262 within these certificates. A specific implementation might want to 263 use only the subject name instead of other information such as 264 subjectAltName. Other authentication mechanism such as kerberos or 265 pre-shared keys would require different client identity data. 267 5. Security Considerations 269 This section addresses security issues related to the usage of a 270 ticket. Tickets must be sufficiently authenticated and encrypted to 271 prevent modification or eavesdropping by an attacker. Several 272 attacks described below will be possible if this is not carefully 273 done. 275 Implementations should take care to ensure that the processing of 276 tickets does not increase the chance of denial of serve as described 277 below. 279 5.1 Stolen Ticket 281 Threat: If an eavesdropper can learn the ticket (e.g., by 282 eavesdropping) and, then the eavesdropper could be learn the 283 content of the ticket (in particular sensitive information such as 284 the session key). 285 Countermeasures: As shown in Section 4 a TLS server MUST encrypt the 286 ticket in order not to reveal the embedded session key and other 287 state information. 289 5.2 MitM Attack 291 Threat: Since the SessionTicket TLS extension is included in the 292 ClientHello message in cleartext an eavesdropper could store the 293 ticket and use it in a later protocol session in order to 294 impersonate the legitimate user. 295 Countermeasures: The session key which is included in the ticket is 296 not available to the adversary assuming that the ticket is 297 properly protected with a key known only to the TLS server. An 298 adversary reusing the ticket would be detected immediately after 299 the session key has to be used. 301 5.3 Forged Ticket 303 Threat: A malicious user could forge or alter a ticket in order to 304 resume a session, to extend its lifetime or to impersonate as 305 another user. 306 Countermeasures: To avoid this kind of attack, the TLS server must 307 assure that proper mechanisms for protecting the ticket are in 308 place. It is recommended to protect the ticket using a keyed 309 message digest or a digital signature. 311 5.4 Privilege Escalation Attack 313 Threat: A malicious user could modify content of the ticket to 314 increase its authorization privileges by modifying authorization 315 information stored in the ticket. 316 Countermeasures: The TLS server MUST integrity protect the ticket to 317 protect the authorization part of the ticket against 318 modifications. 320 5.5 Denial of Service Attacks 322 Threat: An adversary could store a large number of tickets (possibly 323 forged tickets) to send them to the TLS server for verification. 324 Depending on the complexity of the verification procedure the TLS 325 server might experience a denial of service attack. Additionally, 326 an adversary might inject faked tickets which cause effects 327 similar to buffer overflow attacks at the TLS server. 328 Countermeasures: The verification of the ticket MUST be lightweight 329 (e.g., no digital signature or other expensive computations 330 involving other entities for verifications). Furthermore, the TLS 331 server MUST provide integrity protection of the ticket to avoid 332 tampering. 334 6. Acknowledgments 336 The authors would like to thank the following people for their help 337 with a previous version of this draft and for their input: Nancy 338 Cam-Winget and David McGrew 340 [RFC2712] describes a mechanism for using kerberos ([RFC1510]) in TLS 341 ciphersuites, which helped inspire the use of tickets to avoid server 342 state. [EAP-FAST] makes use of a similar mechanism to avoid 343 maintaing server state for the cryptographic tunnel. [AURA97] also 344 investigates the concept of stateless sessions. [CSSC] describes a 345 solution that is very similar to the one described in this document 346 and gives a detailed analysis of the security considerations 347 involved. 349 7. IANA considerations 351 Needs a TLS extension number (for including the ticket in client 352 hello), and HandshakeType number (for delivering the ticket to the 353 client). 355 8. References 357 8.1 Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", March 1997. 362 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. 363 and T. Wright, "Transport Layer Security (TLS) 364 Extensions", RFC 3546, June 2003. 366 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 367 RFC 2246, January 1999. 369 8.2 Informative References 371 [AURA97] Aura, T. and P. Nikander, "Stateless Connections", 372 Proceedings of the First International Conference on 373 Information and Communication Security (ICICS '97) , 1997. 375 [CSSC] Shacham, H., Boneh, D. and E. Rescorla, "Client Side 376 Caching for TLS", URI 377 http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf. 379 [EAP-FAST] 380 Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "EAP 381 Flexible Authentication via Secure Tunneling (EAP-FAST)", 382 Internet-Draft work-in-progress, February 2004. 384 [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network 385 Authentication Service (V5)", RFC 1510, September 1993. 387 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 388 Suites to Transport Layer Security (TLS)", RFC 2712, 389 October 1999. 391 Authors' Addresses 393 Joseph Salowey 394 Cisco Systems 395 2901 3rd Ave 396 Seattle, WA 98121 397 US 399 EMail: jsalowey@cisco.com 401 Hao Zhou 402 Cisco Systems 403 4125 Highlander Parkway 404 Richfield, OH 44286 405 US 407 EMail: hzhou@cisco.com 409 Pasi Eronen 410 Nokia Research Center 411 P.O. Box 407 412 FIN-00045 Nokia Group 413 Finland 415 EMail: pasi.eronen@nokia.com 417 Hannes Tschofenig 418 Siemens 419 Otto-Hahn-Ring 6 420 Munich, Bayern 81739 421 Germany 423 EMail: Hannes.Tschofenig@siemens.com 425 Intellectual Property Statement 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Disclaimer of Validity 451 This document and the information contained herein are provided on an 452 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 453 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 454 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 455 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 456 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 457 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 459 Copyright Statement 461 Copyright (C) The Internet Society (2004). This document is subject 462 to the rights, licenses and restrictions contained in BCP 78, and 463 except as set forth therein, the authors retain all their rights. 465 Acknowledgment 467 Funding for the RFC Editor function is currently provided by the 468 Internet Society.