idnits 2.17.1 draft-salowey-tls-ticket-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 443 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 30 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '... key material it MUST be distributed b...' RFC 2119 keyword, line 92: '...bution mechanism SHOULD authenticate a...' RFC 2119 keyword, line 127: '...on the server the Session ID SHOULD be...' RFC 2119 keyword, line 131: '...y the client. It MUST NOT be feasible...' RFC 2119 keyword, line 219: '...he very least it MUST contain enough i...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 2004) is 7278 days in the past. Is this intentional? 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 110, but not defined ** 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-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft N. Cam-Winget 4 D. McGrew 5 J. Salowey 6 H. Zhou 7 Document: draft-salowey-tls-ticket-00.txt Cisco Systems 8 Expires: October 2004 May 2004 10 A TLS Hello Extension for Ticket Based Pre-Shared Keys 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a TLS extension that makes use of a pre- 35 established ticket to distribute the shared secret for establishing a 36 TLS session. The mechanism uses extensions to the TLS session resume 37 hello exchange. In particular the ticket enables the client to 38 maintain state so the server does not have to maintain per-client 39 session state. The use of a hello extension allows fallback to a 40 full ciphersuite handshake. Considerations for the initial 41 establishment of the ticket material are discussed. 43 Table of Contents 45 1. Introduction........................................... 2 46 2. Basic operation........................................ 2 48 Cam-Winget, et. al. Expires - November 2004 [Page 1] =0C 49 TLS Hello Extension for Tickets May 2004 51 2.1 TLS Hello Ticket Extension......................... 3 52 2.2 Generating the master secret ...................... 4 53 2.3 TLS Hello Ticket extension format.................. 4 54 3. Ticket Considerations.................................. 5 55 3.1 Ticket Contents.................................... 5 56 3.2 Ticket Issuance.................................... 5 57 3.3 Ticket Format...................................... 6 58 4. Security Considerations................................ 7 59 Normative References...................................... 7 60 Informative References.................................... 7 61 Acknowledgments........................................... 8 62 Author's Addresses........................................ 8 64 1. Introduction 66 This document describes an extension to TLS that allows shared keys 67 to be used similar to [TLS-SHARED-KEY] but enables one of the peers 68 to be stateless. The extension is modeled after [RFC 3546] and 69 employs the session resume logic. The proposal allows for the session 70 state to be stored on the client in a ticket issued by the server or 71 some central authority. This relieves the server from maintaining 72 per-client session state. This mechanism is based on work done for 73 [EAP-FAST] which discusses this extension as well as a method for 74 distributing the initial ticket. 76 An extension to the TLS resume functionality instead of a new cipher 77 suite was chosen because it allows the protocol to fall back to full 78 authentication cipher suite if the ticket provided in the hello 79 message is not valid. This extension can be used in conjunction with 80 any TLS cipher suite including those specified in [TLS-PSK]. 82 2. Basic operation 84 The basic operation assumes that a ticket has been previously issued 85 to the client. The ticket consists of a ticket key which is known to 86 the client, an opaque portion which contains information for the 87 server and optional informational section which describes information 88 in the ticket to the client. A suggested format for the distribution 89 of the ticket is described in section 3.3. Since the ticket contains 90 secret key material it MUST be distributed by a mechanism that 91 protects the integrity and the confidentiality of the ticket. In 92 addition the distribution mechanism SHOULD authenticate and authorize 93 the issuer. The exact means for distributing this ticket is not 94 specified in this document; however suggestions and considerations 95 are discussed in section 3.2 and in [EAP-FAST]. In EAP-FAST this 96 ticket is called the PAC. 98 Cam-Winget, et. Al. Expires - November 2004 [Page 2] =0C 99 TLS Hello Extension for Tickets May 2004 101 The exchange for establishing a session is the same as that used by 102 TLS abbreviated handshake for session resume from [RFC 2246]: 104 Client Server 106 ClientHello --------> 107 ServerHello 108 [ChangeCipherSpec] 109 <-------- Finished 110 [ChangeCipherSpec] 111 Finished --------> 112 Application Data <-------> Application Data 114 A new extension to the client hello is defined to contain the opaque 115 part of the ticket held by the client. 117 2.1 TLS Hello Ticket Extension 119 The TLS Hello ticket extension is an extension to the client hello 120 message and is included in the client_hello_extension_list defined in 121 [RFC 3546]. The extension is used as follows. 123 When then client wants to establish a session with the server, it 124 creates a TLS client hello record. It includes the appropriate 125 protocol version, new random value, acceptable cipher suites and 126 compression methods just as in standard TLS [RFC 2246]. Since the 127 session state is not stored on the server the Session ID SHOULD be 128 set to 0. The client includes a client hello extension which 129 contains only the opaque part of the client=92s ticket. For the 130 remainder of this section the word ticket indicates only the opaque 131 portion of the ticket held by the client. It MUST NOT be feasible 132 for an eavesdropper to extract valuable information, such as the 133 ticket key, from the opaque portion of the ticket. 135 When the server receives a client hello containing a ticket extension 136 it extracts the ticket information and attempts to decode it. The 137 opaque portion of the ticket is opaque to the client, not the server. = 139 If the server cannot process the ticket or the ticket is not usable 140 for any reason (for example it may have expired) then it may initiate 141 the normal full TLS handshake with the client. Alternatively, if the 142 server is unable to process the ticket it may send a TLS-Alert 143 indicating handshake_failure. 145 If it can decode the ticket then it uses the information in the 146 ticket to re-generate the ticket key (this will typically require the 147 server to decrypt the ticket). The server derives the TLS master 148 secret from the ticket key as described in the section 2.2. The 149 server then continues with the abbreviated handshake for TLS session 150 Resume. It chooses appropriate ciphersuite and compression data based 152 Cam-Winget, et. Al. Expires - November 2004 [Page 3] =0C 153 TLS Hello Extension for Tickets May 2004 155 on the client request and any additional data in the ticket if any 156 exists. 158 The server may return a session-id in the server hello message. The 159 client may then store this session-id along with the required 160 cryptographic state so that session resume can be performed as in 161 standard TLS. In the case that the client wants to use the standard 162 session resume it includes the session-id issued by the server in the 163 client hello. 165 2.2 Generating the master secret 167 A 48 byte TLS master secret is generated from the ticket key (TK) in 168 the TLS Hello ticket as follows. 170 master_secret =3D T-PRF (TK, "PAC to master secret label hash", 171 server_random + client_random, 48) 173 T-PRF is defined in [EAP-FAST] as 175 T-PRF (Key, label, seed, OutputLength) =3D T1 + T2 + T3 + T4 + ... 177 Where + denote concatenation; 178 S =3D label + 0x00 + seed; 180 and 182 T1 =3D HMAC-SHA1 (Key, S + OutputLength + 0x01) 183 T2 =3D HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) 184 T3 =3D HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) 185 T4 =3D HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) 187 The master secret is then used to generate the key block as described 188 in [RFC 2246]. 190 2.3 TLS Hello Ticket extension format 192 The format of the TLS Hello ticket extension can be described as 193 follows. 195 The extension type number for TLS ticket extension is 35. 197 The TLS ticket extension format is defined as: 199 struct { 200 opaque _Hello ticket<1..2^16-1> 201 } HelloTicket; 203 Cam-Winget, et. Al. Expires - November 2004 [Page 4] =0C 204 TLS Hello Extension for Tickets May 2004 206 3. Ticket Considerations 208 3.1 Ticket Contents 210 The TLS Hello ticket consists of three discreet components: the 211 ticket key, the ticket opaque data and the ticket informational data. 213 The ticket key is a symmetric key of at least 16 bytes in length. 214 This is the key that is used to derive the TLS master secret. 216 The ticket opaque data is data to be processed by the server and its 217 contents must be completely opaque to the client or any eavesdropper. = 219 At the very least it MUST contain enough information for the TLS 220 server to derive the TLS master secret. The ticket should also 221 contain information restricting its validity in time. The ticket 222 opaque data may contain additional data such as identity information, 223 ciphersuite information, capabilities and authorization attributes. 224 How this information is processed is up to the entities that issue 225 and process the ticket. 227 Ticket informational data consists of data for the client which 228 provides information about the usage of the ticket. The ticket 229 information data may contain validity data such as an expiry time or 230 information on which ciphersuite to use. This information is 231 optional. If the client cannot interpret any of the data it should 232 ignore the data it does not understand. 234 The ticket MUST be transmitted and stored in a manner that maintains 235 its confidentiality and authenticity. 237 The client may maintain a cache of tickets it shares with respective 238 servers. Since these tickets contain keys access to this cache must 239 be restricted to authorized entities. 241 3.2 Ticket Issuance 243 The client may obtain a ticket in many different ways. It may be 244 issued by the same server that processes the ticket or it may be 245 issued by a trusted third party. How this is done is beyond the 246 scope of this document. In [EAP-FAST] the TLS Hello ticket is 247 distributed within an established TLS tunnel after user 248 authentication is performed. 250 As stated above the ticket MUST be transmitted in a manner that 251 maintains its confidentiality and authenticity. In addition if the 252 ticket is meant to convey identity or authorization then the system 254 Cam-Winget, et. Al. Expires - November 2004 [Page 5] =0C 255 TLS Hello Extension for Tickets May 2004 257 must ensure that only the intended party can obtain the ticket. In 258 this case the ticket must only be issued after appropriate 259 authentication and authorization has taken place. 261 3.3 Ticket Format 263 In order to promote interoperable implementation the PAC format from 264 EAP-FAST is used when transporting the ticket. The format MUST be 265 used with a security mechanism to protect the ticket key. 267 The basic format consists of a series type-length-value (TLV) 268 structures. A TLV is defined as follows: 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |R|R| TLV Type | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Value... 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 R Reserved 279 The first two bytes are reserved and set to 0 281 TLV Type 282 Enumerated type value 284 Length 285 Two byte length value in network byte order 287 Value 288 Variable length value 290 The ticket key (PAC-key) has a TLV type of 1 and a length of at least 291 16 bytes. The value contains the key used to derive the TLS Master 292 Secret. 294 The ticket opaque data (PAC-Opaque) has a TLV type of 2 and a length 295 of at least 16 bytes. The value contains the opaque data which is 296 treated as opaque data by the client. 298 The ticket lifetime (CRED_LIFETIME) has a TLV type of 3 and a length 299 of 4 bytes. The value contains the expiration time of the credential 300 in UNIX UTC time. 301 The ticket issuer ID (A-ID) has a TLV type of 4 and a variable 302 length. The value contains a name used to identify the issuer of the 303 ticket. 305 Cam-Winget, et. Al. Expires - November 2004 [Page 6] =0C 306 TLS Hello Extension for Tickets May 2004 308 Values 5-9 are defined in [EAP-FAST]. 310 4. Security Considerations 312 The ticket opaque is transmitted in the clear during the TLS 313 handshake; therefore it MUST NOT reveal sensitive information to an 314 eavesdropper. 316 The master secret key in the ticket is used to derive the TLS master 317 secret. It should be generated in a way that ensures that it has 318 sufficient entropy. It SHOULD NOT be derived directly from a 319 password, however the ticket may be issued as a result of password 320 based authentication. 322 When the ticket is cached it MUST be stored so that access to the 323 cache is restricted to only allow authorized parties. 325 If the ticket contains authorization information then it should only 326 be issued after successful authentication and authorization have 327 occurred. Various aspects of credentials management such as 328 revocation, expiry and renewal need to be considered when placing 329 identity and authorization information in a ticket. 331 Normative References 333 [RFC 2246] 334 Dierks, Tim and Allen, Christopher, "The TLS Protocol", RFC 335 2246, January 1999. 337 [RFC 3546] 338 Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. 339 and Wright, T., "Transport Layer Security (TLS) Extensions", 340 RFC 3546, June 2003 342 Informative References 344 [EAP-FAST] 345 Cam-Winget, N., McGrew, D., Salowey, J., Zhou, H., "EAP 346 Flexible Authentication via Secure Tunneling (EAP-FAST)", 347 draft-cam-winget-eap-fast-00 (work in progress), February 348 2004 350 Cam-Winget, et. Al. Expires - November 2004 [Page 7] =0C 351 TLS Hello Extension for Tickets May 2004 353 [TLS-SHARED-KEY] 354 Gutmann, P., "Use of Shared Keys in the TLS Protocol", 355 draft-ietf-tls-sharedkeys-02 (work in progress), October 356 2003. 358 [TLS-PSK] 359 Eronen, P., and Tschofenig, H. "Pre-Shared Key Ciphersuites 360 for Transport Layer Security (TLS)", draft-eronen-tls-psk- 361 00.txt (work in progress), February 2004 363 Acknowledgments 365 Author's Addresses 367 Nancy Cam-Winget 368 Cisco Systems 369 3625 Cisco Way 370 San Jose, CA 95134 371 US 372 Phone: +1 408 853 0532 373 Email: ncamwing@cisco.com 375 David McGrew 376 Cisco Systems 377 San Jose, CA 95134 378 US 379 Email: mcgrew@cisco.com 381 Joseph Salowey 382 Cisco Systems 383 2901 3rd Ave 384 Seattle, WA 98121 385 US 386 Email: jsalowey@cisco.com 388 Hao Zhou 389 Cisco Systems 390 4125 Highlander Parkway 391 Richfield, OH 44286 392 US 393 Phone : +1 330 523 2132 394 Email: hzhou@cisco.com 396 Cam-Winget, et. Al. Expires - November 2004 [Page 8] =0C