idnits 2.17.1 draft-salowey-tls-ticket-03.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 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 451. ** 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 (July 15, 2005) is 6860 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 151, but not defined -- Looks like a reference, but probably isn't: '16' on line 216 -- Looks like a reference, but probably isn't: '20' on line 218 -- Looks like a reference, but probably isn't: '48' on line 238 == Unused Reference: 'RFC2246' is defined on line 361, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) == 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: January 16, 2006 Cisco Systems 5 P. Eronen 6 Nokia 7 H. Tschofenig 8 Siemens 9 July 15, 2005 11 Transport Layer Security Session Resumption without Server-Side State 12 draft-salowey-tls-ticket-03.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 January 16, 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 . . . . . . . . . . . . . . . . . . 9 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 [RFC3546] and 81 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 an 105 empty SessionTicket TLS extension in the ClientHello message. 107 If the server wants to use this mechanism, it stores its session 108 state (such as ciphersuite and master secret) to a ticket that is 109 encrypted and integrity-protected by a key known only to the server. 110 The ticket is distributed to the client using the NewSessionTicket 111 TLS handshake message. This message is sent during the TLS handshake 112 before the ChangeCipherSpec message after the server has verified the 113 client's Finished message. 115 Client Server 117 ClientHello --------> 118 (empty SessionTicket extension) 119 ServerHello 120 Certificate* 121 ServerKeyExchange* 122 CertificateRequest* 123 <-------- ServerHelloDone 124 Certificate* 125 ClientKeyExchange 126 CertificateVerify* 127 [ChangeCipherSpec] 128 Finished --------> 129 NewSessionTicket 130 [ChangeCipherSpec] 131 <-------- Finished 132 Application Data <-------> Application Data 134 The client caches this ticket along with the master secret, session 135 ID and other parameters associated with the current session. When 136 the client wishes to resume the session, it includes a SessionTicket 137 TLS extension in the SessionTicket extension within ClientHello 138 message. The server then verifies that the ticket has not been 139 tampered with, decrypts the contents, and retrieves the session state 140 from the contents of the ticket and uses this state to resume the 141 session. Since separate fields in the request are used for the 142 session ID and the ticket standard stateful session resume can co- 143 exist with the ticket based session resume described in this 144 specification. 146 ClientHello 147 (SessionTicket extension) --------> 148 ServerHello 149 [ChangeCipherSpec] 150 <-------- Finished 151 [ChangeCipherSpec] 152 Finished --------> 153 Application Data <-------> Application Data 155 Since the ticket is typically interpreted by the same server or group 156 of servers that created it, the exact format of the ticket does not 157 need to be the same for all implementations. A sample ticket format 158 is given in Section 4. If the server cannot or does not want to 159 honor the ticket then it can initiate a full handshake with the 160 client. 162 It is possible that the session ticket and master session key could 163 be delivered through some out of band mechanism. This behavior is 164 beyond the scope of the document and would need to be described in a 165 separate specification. 167 3.2 Format of SessionTicket TLS extension 169 The format of the ticket is an opaque structure used to carry session 170 specific state information. 172 struct { 173 opaque ticket<0..2^16-1>; 174 } SessionTicket; 176 3.3 Format of NewSessionTicket handshake message 178 This message is sent during the TLS handshake before the 179 ChangeCipherSpec message after the server has verified the client's 180 Finished message. 182 struct { 183 HandshakeType msg_type; 184 uint24 length; 185 select (HandshakeType) { 186 case hello_request: HelloRequest; 187 case client_hello: ClientHello; 188 case server_hello: ServerHello; 189 case certificate: Certificate; 190 case server_key_exchange: ServerKeyExchange; 191 case certificate_request: CertificateRequest; 192 case server_hello_done: ServerHelloDone; 193 case certificate_verify: CertificateVerify; 194 case client_key_exchange: ClientKeyExchange; 195 case finished: Finished; 196 case new_session_ticket: NewSessionTicket; /* NEW */ 197 } body; 198 } Handshake; 200 struct { 201 opaque ticket<0..2^16-1>; 202 } NewSessionTicket; 204 4. Sample ticket construction 206 This section describes one possibility how the ticket could be 207 constructed, other implementations are possible. 209 The server uses two keys, one 128-bit key for AES encryption and one 210 128-bit key for HMAC-SHA1. 212 The ticket is structured as follows: 214 struct { 215 uint32 key_version; 216 opaque iv[16] 217 opaque encrypted_state<0..2^16-1>; 218 opaque mac[20]; 219 } ExampleTicket; 221 Here key_version identifies a particular set of keys. One 222 possibility is to generate new random keys every time the server is 223 started, and use the timestamp as the key version. The same 224 mechanisms known from a number of other protocols can be reused for 225 this purpose. 227 The actual state information in encrypted_state is encrypted using 228 128-bit AES in CBC mode with the given IV. The MAC is calculated 229 using HMAC-SHA1 over key_version (4 octets) and IV (16 octets), 230 followed by the contents of the encrypted_state field (without the 231 length). 233 struct { 234 ProtocolVersion protocol_version; 235 SessionID session_id; 236 CipherSuite cipher_suite; 237 CompressionMethod compression_method; 238 opaque master_secret[48]; 239 ClientIdentity client_identity; 240 uint32 timestamp; 241 } ExampleStatePlaintext; 243 enum { 244 anonymous(0), 245 certificate_based(1), 246 psk(2) 247 } ExampleClientAuthenticationType; 249 struct { 250 ExampleClientAuthenticationType client_authentication_type; 251 select (ExampleClientAuthenticationType) { 252 case anonymous: struct {}; 253 case certificate_based: 254 ASN.1Cert certificate_list<0..2^24-1>; 255 case psk: 256 opaque psk_identity<0..2^16-1>; 258 } 259 } ExampleClientIdentity; 261 The structure ExampleStatePlaintext stores the TLS session state 262 including the SessionID and the master_secret. The timestamp within 263 this structure allows the TLS server to expire tickets. To cover the 264 authentication and key exchange protocols provided by TLS the 265 ExampleClientIdentity structure contains the authentication type of 266 the client used in the initial exchange (see 267 ExampleClientAuthenticationType). To offer the TLS server with the 268 same capabilities for authentication and authorization a certificate 269 list is included in case of public key based authentication. The TLS 270 server is therefore able to inspect a number of different attributes 271 within these certificates. A specific implementation might choose to 272 store a subset of this information. Other authentication mechanism 273 such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk] 274 would require different client identity data. 276 5. Security Considerations 278 This section addresses security issues related to the usage of a 279 ticket. Tickets must be sufficiently authenticated and encrypted to 280 prevent modification or eavesdropping by an attacker. Several 281 attacks described below will be possible if this is not carefully 282 done. 284 Implementations should take care to ensure that the processing of 285 tickets does not increase the chance of denial of serve as described 286 below. 288 5.1 Invalidating Sessions 290 The TLS specification requires that TLS sessions be invalidated when 291 errors occur. [CSSC] discusses the security implications of this in 292 detail. In the analysis in this paper, failure to invalidate 293 sessions does not pose a security risk. This is because the TLS 294 handshake uses a non-reversible function to derive keys for a session 295 so information about one session does not provide an advantage to 296 attack the master secret or a different session. If a session 297 invalidation scheme is used the implementation should verify the 298 integrity of the ticket before using the contents to invalidate a 299 session to ensure an attacker cannot invalidate a chosen session. 301 5.2 Stolen Tickets 303 An eavesdropper or man-in-the-middle may obtain the ticket and 304 attempt to use the ticket to establish a session with the server, 305 however since the ticket is encrypted and the attacker does not know 306 the secret key a stolen key does not help an attacker resume a 307 session. A TLS server MUST use strong encryption and integrity 308 protection for the ticket to prevent an attacker from using a brute 309 force mechanism to obtain the tickets contents. 311 5.3 Forged Tickets 313 A malicious user could forge or alter a ticket in order to resume a 314 session, to extend its lifetime, to impersonate as another user or 315 gain additional privileges. This attack is not possible if the 316 ticket is protected using a strong integrity protection algorithm 317 such as a keyed HMAC. 319 5.4 Denial of Service Attacks 321 An adversary could store or forge a large number of tickets to send 322 to the TLS server for verification. To minimize the possibility of a 323 denial of service the verification of the ticket should be 324 lightweight (e.g., using efficient symmetric key cryptographic 325 algorithms). 327 5.5 Ticket Protection Key Lifetime 329 The management of the keys used to protect the ticket is beyond the 330 scope of this document. It is advisable to limit the lifetime of 331 these keys to ensure they are not overused. 333 6. Acknowledgments 335 The authors would like to thank the following people for their help 336 with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget 337 and David McGrew 339 [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS 340 ciphersuites, which helped inspire the use of tickets to avoid server 341 state. [I-D.cam-winget-eap-fast] makes use of a similar mechanism to 342 avoid maintaining server state for the cryptographic tunnel. 343 [AURA97] also investigates the concept of stateless sessions. [CSSC] 344 describes a solution that is very similar to the one described in 345 this document and gives a detailed analysis of the security 346 considerations involved. 348 7. IANA considerations 350 Needs a TLS extension number (for including the ticket in client 351 hello), and HandshakeType number (for delivering the ticket to the 352 client). 354 8. References 356 8.1 Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 362 RFC 2246, January 1999. 364 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 365 and T. Wright, "Transport Layer Security (TLS) 366 Extensions", RFC 3546, June 2003. 368 8.2 Informative References 370 [AURA97] Aura, T. and P. Nikander, "Stateless Connections", 371 Proceedings of the First International Conference on 372 Information and Communication Security (ICICS '97) , 1997. 374 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client Side 375 Caching for TLS", 376 URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf, 377 2002. 379 [I-D.cam-winget-eap-fast] 380 Salowey, J., "EAP Flexible Authentication via Secure 381 Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work 382 in progress), April 2005. 384 [I-D.ietf-tls-psk] 385 Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 386 for Transport Layer Security (TLS)", draft-ietf-tls-psk-09 387 (work in progress), June 2005. 389 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 390 Authentication Service (V5)", RFC 1510, September 1993. 392 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 393 Suites to Transport Layer Security (TLS)", RFC 2712, 394 October 1999. 396 Authors' Addresses 398 Joseph Salowey 399 Cisco Systems 400 2901 3rd Ave 401 Seattle, WA 98121 402 US 404 Email: jsalowey@cisco.com 406 Hao Zhou 407 Cisco Systems 408 4125 Highlander Parkway 409 Richfield, OH 44286 410 US 412 Email: hzhou@cisco.com 413 Pasi Eronen 414 Nokia Research Center 415 P.O. Box 407 416 FIN-00045 Nokia Group 417 Finland 419 Email: pasi.eronen@nokia.com 421 Hannes Tschofenig 422 Siemens 423 Otto-Hahn-Ring 6 424 Munich, Bayern 81739 425 Germany 427 Email: Hannes.Tschofenig@siemens.com 429 Intellectual Property Statement 431 The IETF takes no position regarding the validity or scope of any 432 Intellectual Property Rights or other rights that might be claimed to 433 pertain to the implementation or use of the technology described in 434 this document or the extent to which any license under such rights 435 might or might not be available; nor does it represent that it has 436 made any independent effort to identify any such rights. Information 437 on the procedures with respect to rights in RFC documents can be 438 found in BCP 78 and BCP 79. 440 Copies of IPR disclosures made to the IETF Secretariat and any 441 assurances of licenses to be made available, or the result of an 442 attempt made to obtain a general license or permission for the use of 443 such proprietary rights by implementers or users of this 444 specification can be obtained from the IETF on-line IPR repository at 445 http://www.ietf.org/ipr. 447 The IETF invites any interested party to bring to its attention any 448 copyrights, patents or patent applications, or other proprietary 449 rights that may cover technology that may be required to implement 450 this standard. Please address the information to the IETF at 451 ietf-ipr@ietf.org. 453 Disclaimer of Validity 455 This document and the information contained herein are provided on an 456 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 457 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 458 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 459 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 460 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 461 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 463 Copyright Statement 465 Copyright (C) The Internet Society (2005). This document is subject 466 to the rights, licenses and restrictions contained in BCP 78, and 467 except as set forth therein, the authors retain all their rights. 469 Acknowledgment 471 Funding for the RFC Editor function is currently provided by the 472 Internet Society.