idnits 2.17.1 draft-ietf-tls-sharedkeys-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 439 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 185 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (October 2003) is 7471 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) ** Obsolete normative reference: RFC 2246 (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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P.Gutmann 3 Internet-Draft University of Auckland 4 Expires: April 2004 October 2003 6 Use of Shared Keys in the TLS Protocol 7 draft-ietf-tls-sharedkeys-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and may 19 be updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite them 21 other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 1. Abstract 35 The TLS handshake requires the use of CPU-intensive public-key algorithms with 36 a considerable overhead in resource-constrained environments or ones such as 37 mainframes where users are charged for CPU time. This document describes a 38 means of employing TLS using symmetric keys or passwords shared in advance 39 among communicating parties. As an additional benefit, this mechanism 40 provides cryptographic authentication of both client and server without 41 requiring the transmission of passwords or the use of certificates. No 42 modifications or alterations to the TLS protocol are required for this 43 process. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 46 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 47 uppercase, as shown) are to be interpreted as described in [RFC 2119]. 49 2. Problem analysis 51 TLS is frequently used with devices with little CPU power available, for 52 example mobile and embedded devices. In these situations the initial TLS 53 handshake can take as long as half a minute with a 1Kbit RSA key. In many 54 cases a fully general public-key-based handshake is unnecessary, since the 55 device is only syncing to a host PC or contacting a fixed base station, which 56 would allow a pre-shared symmetric key to be used instead. An example of this 57 kind of use is using 3GPP cellular mechanisms to establish keys used to secure 58 a TLS tunnel to a mobile device. 60 In a slight variation of this case, CPU power is available but is too 61 expensive to devote to public-key operations. This situation is common in 62 mainframe environments, where users are charged for CPU time. As with mobile 63 devices, mainframe-to-mainframe or client-to-mainframe communications are 64 generally fixed in advance, allowing shared symmetric keys to be employed. 66 In order to solve these problems, we require a means of eliminating the 67 expensive public-key operations in the TLS handshake, while providing an 68 equivalent level of security using shared symmetric keys. The solution is 69 fairly straightforward. Observe that after the initial handshake phase, TLS 70 is operating with a quantity of symmetric keying material derived from the 71 information exchanged during the initial handshake. Using shared symmetric 72 keys involves explicitly deriving the TLS master secret from the shared key, 73 rather than sharing it implicitly via the public-key-based key agreement 74 process. TLS already contains such a mechanism built into the protocol in the 75 form of the session cacheing mechanism, which allows a TLS session to be 76 resumed without requiring a full public-key-based re-handshake. 78 The solution to the problem then is obvious: We need to seed the TLS session 79 cache with the shared symmetric key. When the client connects, the session 80 cacheing mechanism takes over and the client and server "resume" the phantom 81 session created by seeding the cache. This mechanism requires an absolute 82 minimum of code changes to existing TLS implementations (it can be bolted onto 83 any existing TLS engine without needing to change the engine itself), and no 84 changes to the TLS protocol itself. 86 2.1 Design considerations 88 In order to work within the existing TLS protocol design, we require a means 89 of identifying a particular session (the session ID in TLS terminology), and 90 the keying material required to protect the session. The { ID, key } 91 combination is analogous to the { user name, password } combination 92 traditionally used to secure access to computer systems. 94 In TLS, the session ID is a variable-length value of up to 32 bytes, but is 95 typically 32 or less frequently 16 bytes long. For our use we don't really 96 care about its form. A (somewhat unsound) practice would be to use the user 97 name as the session ID. A more secure alternative would be to employ a value 98 derived from the user name in such a way that it can't be directly connected 99 to it, for example a MAC of the user name. 101 Normally the exact format of the session ID is determined explicitly by the 102 server and remembered by the client for use during session resumption. 103 However, when "resuming" a phantom session in the manner described here, both 104 the client and the server must be able to implicitly generate identical 105 session ID values in order to identify the phantom session to be resumed. To 106 create a canonical session ID value, we pad the variable-length value out to a 107 fixed length by appending zero bytes. 109 The TLS master secret is a 48-byte value, which is unlikely to correspond to 110 the value of the shared symmetric key or password, which would typically be a 111 128-bit key or a text password/passphrase. In order to transform this into 112 the type of keying material required by TLS, we need to apply the TLS 113 pseudorandom function (PRF) to produce the master secret with which we seed 114 the session cache. The shared secret thus takes the place of the 48-byte 115 premaster secret usually used to derive the master secret. As with the 116 variable-length session ID, we need to canonicalise the variable-length 117 secret. 119 The obvious way to do this would be to by zero-pad it to the standard 48-byte 120 length usually used for the premaster secret, as for the session ID. 121 Unfortunately this straightforward approach doesn't work. Unlike the SSL PRF, 122 which uses the full secret for both the MD5 and SHA-1 halves, the TLS PRF 123 isn't a pure black-box design because it splits the secret into two halves 124 before using it. This would result in the second (SHA-1) half in most cases 125 end up with only the zero padding bytes as its "secret". The reasoning behind 126 this splitting of the secret was that there might be some interaction between 127 the two algorithms that could cause security problems. 129 As a result, it's necessary to be aware of the PRF's internal structure and 130 pre-process the input in a way that negates what the PRF does. Some of the 131 possible options to fix the problem are: 133 1. Synthesise a new PRF from HMAC to pre-PRF the input to the TLS PRF. Apart 134 from just being an awful approach, this violates the minimal code-change 135 requirement for TLS implementations that the shared-keys mechanism is 136 supposed to provide. Instead of simply feeding data in via a standard 137 mechanism, implementors would now need to extend their TLS implementation 138 to introduce new crypto mechanisms. 140 2. Repeat the input (or some variant thereof) to fill the 48-byte secret 141 value. This is problematic in that it creates key equivalence classes, 142 for example "ABCD" == "ABCDABCD". 144 3. Unsplit the input, so that instead of arranaging it as 1 x 48 bytes it's 145 done as 2 x 24 bytes. This limits the overall key size, and is specific to 146 the PRF being used - a future PRF design may not split the input in this 147 manner, negating the un-splitting step. 149 The least ugly solution is a variation of 2, prepending a single length byte 150 to the secret, then repeating it to fill 48 bytes, to fix the problem of key 151 equivalence classes. This is the approach used here. 153 Currently the shared-key mechanism always uses the TLS PRF (even if it's used 154 with SSL, since this is purely a TLS mechanism). If in the future a new PRF 155 is introduced, it will be necessary to provide some means of switching over to 156 the new PRF if both it and the current one are in active use. Presumably the 157 only reason to introduce a new, incompatible PRF would be a successful attack 158 on the current one, in which case the point is moot. However, if for some 159 reason it's necessary to keep both PRFs in active use at the same time, then 160 some mechanism such as adding the session ID and shared key in the standard 161 manner using the TLS PRF and some transformation of the session ID and the 162 shared key using the new PRF can be adopted. Since the details of a possible 163 PRF switch are impossible to predict (it may entail a complete protocol 164 overhaul for example), this document does not attempt to guess at the details 165 beyond providing this implementation hint. 167 Finally, we need a means of injecting the resulting session ID and master 168 secret into the session cache. This is the only modification required to 169 existing TLS implementations. Once the cache is seeded, all further details 170 are handled automatically by the TLS protocol. 172 It should be noted that this mechanism is best suited for situations where a 173 small number of clients/servers are communicating. While seeding a session 174 cache with IDs and keys for 10,000 different users is certainly possible, this 175 is rather wasteful of server resources, not to mention the accompanying key 176 management nightmare involved in handling such a large number of shared 177 symmetric keys. 179 3. TLS using shared keys 181 [Note: The following is phrased fairly informally, since it's really an 182 application note rather than a standards-track RFC] 184 Before any exchange takes place, the client and server session caches are 185 seeded with a session ID identifying the user/session, and a master secret 186 derived from the shared secret key or password/passphrase. The exact form of 187 the data used to create the session ID is application specific (but see the 188 comment in the security considerations). The data used to create the session 189 ID is zero-padded to 16 bytes (128 bits) if necessary to meet the requirements 190 given in section 2.1. In C this may be expressed as: 192 memset( session_id, 0, 16 ); 193 memcpy( session_id, input_data, min( input_data_length, 16 ) ); 195 The master secret used to seed the cache is computed in the standard manner 196 using the TLS PRF: 198 master_secret = PRF(shared_secret, "shared secret", "")[0..47]; 200 The shared secret or password/passphrase takes the place of the premaster 201 secret that is normally used at this point, arranged as follows: First, the 202 shared secret/password has a single length byte prepended to it. The length + 203 secret value is then repeated as required to fill the standard 48 bytes. In C 204 this may be expressed as: 206 for( premaster_index = 0; premaster_index < 48; ) 207 { 208 int i; 210 premaster_secret[ premaster_index++ ] = shared_secret_length; 211 for( i = 0; i < shared_secret_length && premaster_index < 48; i++ ) 212 premaster_secret[ premaster_index++ ] = shared_secret[ i ]; 213 } 215 This formats the shared secret in a manner that allows it to be used directly 216 in place of the standard premaster secret derived from the public-key-based 217 key agreement process. 219 The 'seed' component of the calculation (normally occupied by the client and 220 server nonces) is empty in this case, however applications may choose to use 221 an application or system-specific value to ensure that the same shared secret 222 used with another application or system yields a different master secret. 223 When the 'seed' component is non-empty, it should not contain information 224 computed from the shared_secret value [SIGMA]. Note that the use of the 225 client and server nonces will always produce different keys for each session, 226 even if the same master secret is employed. 228 The final step involves injecting the session ID and master secret into the 229 session cache. This is an implementation-specific issue beyond the scope of 230 this document. All further steps are handled automatically by the TLS 231 protocol, which will "resume" the phantom session created by the above steps 232 without going through the full public-key-based handshake. 234 Session cache entries are normally expired after a given amount of time, or 235 overwritten on an LRU basis. In order to prevent shared secret-based entries 236 from vanishing after a certain amount of time, these cache entries will need 237 to be distinguished from standard cache entries and made more persistent then 238 the latter, for example by giving them a longer expiry time when they are 239 added or periodically touching them to update their last-access time. Again, 240 this is an implementation issue beyond the scope of this document. 242 3.1 Use of shared keys with SSLv3 244 If this key management mechanism is used with an implementation that supports 245 SSLv3 alongside TLS (as most do), the TLS PRF must be used for both SSLv3 and 246 TLS. This is required in order to allow the mechanism to function for both 247 SSLv3 and TLS, since using different PRFs would require a different session ID 248 for each PRF used. 250 3.2 Test vectors 252 The following test vectors are derived from the transformation of the password 253 "test" into a master_secret value to be added to the session cache: 255 Shared secret: 257 74 65 73 74 ("test") 259 Shared secret expanded to 48-byte premaster secret size: 261 04 74 65 73 74 04 74 65 262 73 74 04 74 65 73 74 04 263 ... 265 Master secret added to session cache: 267 F5 CE 30 92 B8 09 70 D9 268 22 D5 A1 2C EB 7C 43 FA 269 9C 46 A8 83 EA 6E EF 98 270 EB A5 15 12 FD B1 B6 5A 271 5A 47 B8 C4 C5 63 5B 30 272 86 96 F4 FC FB D5 45 78 274 4. Security considerations 276 The session ID used to identify sessions is visible to observers. While using 277 a user name as the session ID is the most straightforward option, it may lead 278 to problems with traffic analysis, with an attacker being able to track the 279 identities of communicating parties. In addition since the session ID is 280 reused over time, traffic analysis may eventually allow an attacker to 281 identify parties even if an opaque session ID is used. [RFC 2246] contains a 282 similar warning about the contents of session IDs with TLS in general. It 283 should be noted though that even a worse-case non-opaque session ID results in 284 no more exposure than the use of client certificates during a handshake. 286 As with all schemes involving shared keys, special care should be taken to 287 protect the shared values and to limit their exposure over time. Documents 288 covering other shared-key protocols such as Kerberos [RFC 1510] contain 289 various security suggestions in this regard. 291 Use of a fixed shared secret of limited entropy (for example a password) 292 allows an attacker to perform an online password-guessing attack by trying to 293 resume a session with a master secret derived from each possible password. 294 This results in a fatal decrypt_error alert (or some equivalent such as 295 handshake_failure or bad_record_mac) which makes the session non-resumable 296 (that is, it clears the phantom session from the session cache). 297 Implementations should limit the enthusiasm with which they re-seed the 298 session cache after such an event; standard precautions against online 299 password-guessing attacks apply. 301 This mechanism is purely a shared-key session establishment mechanism and does 302 not provide perfect forward secrecy (PFS) by negotiating additional new keying 303 material for each session. Users requiring PFS can either use a shared-key 304 mechanism that also provides PFS such as SRP [SRP], or perform a rehandshake 305 using a standard PFS-providing mechanism over the shared key-protected 306 channel. Note though that both of these mechanisms negate the two main 307 advantages of the shared-key mechanism, requiring both considerable re- 308 engineering of an existing TLS implementation and considerable CPU time to 309 perform the PFS cryptographic operations. 311 Since it does not contain an innate cryptographic mechanism to provide PFS, 312 the shared-key mechanism is vulnerable to an offline password-guessing attack 313 as follows: An attacker who records all of the handshake messages and knows 314 the plaintext for at least one encrypted message can perform the TLS key- 315 derivation using a selection of guessed passwords, perform the cryptographic 316 operations required to process the TLS handshake exchange, and then apply the 317 resulting cryptographic keys to the known-plaintext message. Such an attack 318 consumes considerable time and CPU resources, but is nevertheless possible. 320 There are three possible defences against this type of attack, the first two 321 of which are standard defences against password-guessing attacks: 323 1. Don't use weak, easily-guess passwords or keys. 325 2. Perform iterated pre-processing of the password/key before adding it to the 326 session cache. This has the disadvantage that it negates the shared-key 327 advantage of low CPU consumption during the handshake phase, however the 328 preprocessing can be performed offline on a one-off basis and only the 329 preprocessed key stored by the two communicating parties. An attacker can, 330 however, also generate a dictionary of pre-processed keys offline, given 331 sufficient CPU and storage space. The use of a per-server diversifier 332 ('seed' in the PRF process) makes use of a precomputed dictionary 333 impractical, and a secret diversifier makes a general offline attack 334 considerably more difficult through to impossible depending on the 335 circumstances. 337 3. Use a mechanism that allows for the use of shared keys but also provides 338 PFS, with the advantages and disadvantages described earlier. 340 Note that the two password-guessing attacks possible against the shared-key 341 mechanism, while superficially similar, have quite different requirements on 342 the attacker's side. An online attack merely requires that the attacker know 343 the URL of the server that they wish to attack. An offline attack requires 344 that an attacker both know the URL of the server that they wish to attack and 345 be able to record complete sessions between the client and the server in order 346 to provide the material required for the offline attack. 348 The TLS specification requires that when a session is resumed, the resumed 349 session use the same cipher suite as the original one. Since with a shared- 350 secret session there is no actual session being resumed, it's not possible to 351 meet this requirement. Two approaches are possible to resolve this: 353 1. When the session cache is seeded on the server, a cipher suite acceptable 354 to the server is specified for the resumed session. This complies with the 355 requirements, but requires that the server know that the client is capable 356 of supporting this particular suite. In closed environments (for example 357 syncing to a host PC or a fixed base station, or in a mainframe 358 environment) this is likely to be the case. 360 2. The requirements are relaxed to allow the client and server to negotiate a 361 cipher suite in the usual manner. In order to subvert this, an attacker 362 would have to be able to perform a real-time simultaneous break of both 363 HMAC-MD5 and HMAC-SHA1. In particular the attacker would need to be able 364 to subvert: 366 HMAC( secret, PRF( secret, MD5+SHA1 hash ) ) 368 in the Finished message, which expands to: 370 HMAC( secret, HMAC-MD5^HMAC-SHA1( secret, MD5+SHA1 hash ) ) 372 Because of the unlikeliness of this occurring (an attacker capable of doing 373 this can subvert any TLS session, with or without shared secrets), it 374 appears safe to relax the requirement for resuming with the same cipher 375 suite. 377 References (Normative) 379 [RFC 2119] "Key words for use in RFCs to Indicate Requirement Levels", 380 Scott Bradner, RFC 2119, March 1997. 382 [RFC 2246] "The TLS Protocol", RFC 2246, Tim Dierks and Christopher 383 Allen, January 1999. 385 References (Informative) 387 [RFC 1510] "The Kerberos Network Authentication Service (V5)", 388 RFC 1510, John Kohl and B. Clifford Neuman, September 389 1993. 391 [SIGMA] "SIGMA: the `SIGn-and-MAc' Approach to Authenticated 392 Diffie-Hellman and its Use in the IKE Protocols", Hugo 393 Krawczyk, Proceedings of of Crypto'03, Springer-Verlag 394 Lecture Notes in Computer Science No.2729, p.399. 396 [SRP] "Using SRP for TLS Authentication", David Taylor, IETF draft, 397 November 2002. 399 Author's Address 401 Peter Gutmann 402 University of Auckland 403 Private Bag 92019 404 Auckland, New Zealand 406 Email: pgut001@cs.auckland.ac.nz 408 Full Copyright Statement 410 Copyright (C) The Internet Society (2003). All Rights Reserved. 412 This document and translations of it may be copied and furnished to others, 413 and derivative works that comment on or otherwise explain it or assist in its 414 implementation may be prepared, copied, published and distributed, in whole or 415 in part, without restriction of any kind, provided that the above copyright 416 notice and this paragraph are included on all such copies and derivative 417 works. However, this document itself may not be modified in any way, such as 418 by removing the copyright notice or references to the Internet Society or 419 other Internet organizations, except as needed for the purpose of developing 420 Internet standards in which case the procedures for copyrights defined in the 421 Internet Standards process must be followed, or as required to translate it 422 into languages other than English. 424 The limited permissions granted above are perpetual and will not be revoked by 425 the Internet Society or its successors or assigns. 427 This document and the information contained herein is provided on an "AS IS" 428 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 429 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 430 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 431 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 432 PURPOSE. 434 Acknowledgement 436 Funding for the RFC Editor function is currently provided by the Internet 437 Society.