idnits 2.17.1 draft-ietf-tls-psk-09.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 776. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 21, 2005) is 6846 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) ** Obsolete normative reference: RFC 3268 (ref. 'AES') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3491 (ref. 'NAMEPREP') (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 4013 (ref. 'SASLPREP') (Obsoleted by RFC 7613) == Outdated reference: A later version (-14) exists of draft-ietf-tls-srp-09 -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) == Outdated reference: A later version (-13) exists of draft-ietf-tls-rfc2246-bis-12 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Eronen, Ed. 3 Internet-Draft Nokia 4 Expires: December 20, 2005 H. Tschofenig, Ed. 5 Siemens 6 June 21, 2005 8 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) 9 draft-ietf-tls-psk-09.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 20, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies three sets of new ciphersuites for the 43 Transport Layer Security (TLS) protocol to support authentication 44 based on pre-shared keys. These pre-shared keys are symmetric keys, 45 shared in advance among the communicating parties. The first set of 46 ciphersuites uses only symmetric key operations for authentication. 47 The second set uses a Diffie-Hellman exchange authenticated with a 48 pre-shared key; and the third set combines public key authentication 49 of the server with pre-shared key authentication of the client. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Applicability statement . . . . . . . . . . . . . . . . . 4 55 1.2 Conventions used in this document . . . . . . . . . . . . 4 56 2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5 57 3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7 58 4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8 59 5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9 60 5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9 61 5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 10 62 5.3 Requirements for TLS implementations . . . . . . . . . . 10 63 5.4 Requirements for management interfaces . . . . . . . . . 10 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11 67 7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11 68 7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12 69 7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 9.1 Normative References . . . . . . . . . . . . . . . . . . 13 73 9.2 Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15 75 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 Usually TLS uses public key certificates [TLS] or Kerberos [KERB] for 80 authentication. This document describes how to use symmetric keys 81 (later called pre-shared keys or PSKs), shared in advance among the 82 communicating parties, to establish a TLS connection. 84 There are basically two reasons why one might want to do this: 86 o First, using pre-shared keys can, depending on the ciphersuite, 87 avoid the need for public key operations. This is useful if TLS 88 is used in performance-constrained environments with limited CPU 89 power. 91 o Second, pre-shared keys may be more convenient from a key 92 management point of view. For instance, in closed environments 93 where the connections are mostly configured manually in advance, 94 it may be easier to configure a PSK than to use certificates. 95 Another case is when the parties already have a mechanism for 96 setting up a shared secret key, and that mechanism could be used 97 to "bootstrap" a key for authenticating a TLS connection. 99 This document specifies three sets of new ciphersuites for TLS. 100 These ciphersuites use new key exchange algorithms, and re-use 101 existing cipher and MAC algorithms from [TLS] and [AES]. A summary 102 of these ciphersuites is shown below. 104 CipherSuite Key Exchange Cipher Hash 106 TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA 107 TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA 108 TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA 109 TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA 110 TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA 111 TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA 112 TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA 113 TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA 114 TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA 115 TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA 116 TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA 117 TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA 119 The first set of ciphersuites (with PSK key exchange algorithm), 120 defined in Section 2 use only symmetric key algorithms, and are thus 121 especially suitable for performance-constrained environments. 123 The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) 124 use a PSK to authenticate a Diffie-Hellman exchange. These 125 ciphersuites protect against dictionary attacks by passive 126 eavesdroppers (but not active attackers), and also provide Perfect 127 Forward Secrecy (PFS). 129 The third set of ciphersuites (with RSA_PSK key exchange algorithm), 130 defined in Section 4, combine public key based authentication of the 131 server (using RSA and certificates) with mutual authentication using 132 a PSK. 134 1.1 Applicability statement 136 The ciphersuites defined in this document are intended for a rather 137 limited set of applications, usually involving only a very small 138 number of clients and servers. Even in such environments, other 139 alternatives may be more appropriate. 141 If the main goal is to avoid PKIs, another possibility worth 142 considering is to use self-signed certificates with public key 143 fingerprints. Instead of manually configuring a shared secret in, 144 for instance, some configuration file, a fingerprint (hash) of the 145 other party's public key (or certificate) could be placed there 146 instead. 148 It is also possible to use the SRP (Secure Remote Password) 149 ciphersuites for shared secret authentication [SRP]. SRP was 150 designed to be used with passwords, and incorporates protection 151 against dictionary attacks. However, it is computationally more 152 expensive than the PSK ciphersuites in Section 2. 154 1.2 Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [KEYWORDS]. 160 2. PSK key exchange algorithm 162 This section defines the PSK key exchange algorithm and associated 163 ciphersuites. These ciphersuites use only symmetric key algorithms. 165 It is assumed that the reader is familiar with ordinary TLS 166 handshake, shown below. The elements in parenthesis are not included 167 when PSK key exchange algorithm is used, and "*" indicates a 168 situation-dependent message that is not always sent. 170 Client Server 171 ------ ------ 173 ClientHello --------> 174 ServerHello 175 (Certificate) 176 ServerKeyExchange* 177 (CertificateRequest) 178 <-------- ServerHelloDone 179 (Certificate) 180 ClientKeyExchange 181 (CertificateVerify) 182 ChangeCipherSpec 183 Finished --------> 184 ChangeCipherSpec 185 <-------- Finished 186 Application Data <-------> Application Data 188 The client indicates its willingness to use pre-shared key 189 authentication by including one or more PSK ciphersuites in the 190 ClientHello message. If the TLS server also wants to use pre-shared 191 keys, it selects one of the PSK ciphersuites, places the selected 192 ciphersuite in the ServerHello message, and includes an appropriate 193 ServerKeyExchange message (see below). The Certificate and 194 CertificateRequest payloads are omitted from the response. 196 Both clients and servers may have pre-shared keys with several 197 different parties. The client indicates which key to use by 198 including a "PSK identity" in the ClientKeyExchange message (note 199 that unlike in [SHAREDKEYS], the session_id field in ClientHello 200 message keeps its usual meaning). To help the client in selecting 201 which identity to use, the server can provide a "PSK identity hint" 202 in the ServerKeyExchange message. If no hint is provided, the 203 ServerKeyExchange message is omitted. See Section 5 for more 204 detailed description of these fields. 206 The format of the ServerKeyExchange and ClientKeyExchange messages is 207 shown below. 209 struct { 210 select (KeyExchangeAlgorithm) { 211 /* other cases for rsa, diffie_hellman, etc. */ 212 case psk: /* NEW */ 213 opaque psk_identity_hint<0..2^16-1>; 214 }; 215 } ServerKeyExchange; 217 struct { 218 select (KeyExchangeAlgorithm) { 219 /* other cases for rsa, diffie_hellman, etc. */ 220 case psk: /* NEW */ 221 opaque psk_identity<0..2^16-1>; 222 } exchange_keys; 223 } ClientKeyExchange; 225 The premaster secret is formed as follows: if the PSK is N octets 226 long, concatenate a uint16 with the value N, N zero octets, a second 227 uint16 with the value N, and the PSK itself. 229 Note 1: All the ciphersuites in this document share the same 230 general structure for the premaster secret, namely 232 struct { 233 opaque other_secret<0..2^16-1>; 234 opaque psk<0..2^16-1>; 235 }; 237 Here "other_secret" is either zeroes (plain PSK case), or comes 238 from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, 239 respectively). See Sections 3 and 4 for a more detailed 240 description. 242 Note 2: Using zeroes for "other_secret" effectively means that 243 only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF 244 is used when constructing the master secret. This was considered 245 more elegant from an analytical viewpoint than, for instance, 246 using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See 247 [KRAWCZYK] for a more detailed rationale. 249 The TLS handshake is authenticated using the Finished messages as 250 usual. 252 If the server does not recognize the PSK identity, it MAY respond 253 with an "unknown_psk_identity" alert message. Alternatively, if the 254 server wishes to hide the fact that the PSK identity was not known, 255 it MAY continue the protocol as if the PSK identity existed but the 256 key was incorrect: that is, respond with a "decrypt_error" alert. 258 3. DHE_PSK key exchange algorithm 260 This section defines additional ciphersuites that use a PSK to 261 authenticate a Diffie-Hellman exchange. These ciphersuites give some 262 additional protection against dictionary attacks, and also provide 263 Perfect Forward Secrecy (PFS). See Section 7 for discussion of 264 related security considerations. 266 When these ciphersuites are used, the ServerKeyExchange and 267 ClientKeyExchange messages also include the Diffie-Hellman 268 parameters. The PSK identity and identity hint fields have the same 269 meaning as in the previous section (note that the ServerKeyExchange 270 message is always sent even if no PSK identity hint is provided). 272 The format of the ServerKeyExchange and ClientKeyExchange messages is 273 shown below. 275 struct { 276 select (KeyExchangeAlgorithm) { 277 /* other cases for rsa, diffie_hellman, etc. */ 278 case diffie_hellman_psk: /* NEW */ 279 opaque psk_identity_hint<0..2^16-1>; 280 ServerDHParams params; 281 }; 282 } ServerKeyExchange; 284 struct { 285 select (KeyExchangeAlgorithm) { 286 /* other cases for rsa, diffie_hellman, etc. */ 287 case diffie_hellman_psk: /* NEW */ 288 opaque psk_identity<0..2^16-1>; 289 ClientDiffieHellmanPublic public; 290 } exchange_keys; 291 } ClientKeyExchange; 293 The premaster secret is formed as follows. First, perform the 294 Diffie-Hellman computation in the same way as for other 295 Diffie-Hellman based ciphersuites in [TLS]. Let Z be the value 296 produced by this computation (with leading zero bytes stripped as in 297 other Diffie-Hellman based ciphersuites). Concatenate a uint16 298 containing the length of Z (in octets), Z itself, a uint16 containing 299 the length of the PSK (in octets), and the PSK itself. 301 This corresponds to the general structure for the premaster secrets 302 (see Note 1 in Section 2) in this document, with "other_secret" 303 containing Z. 305 4. RSA_PSK key exchange algorithm 307 The ciphersuites in this section use RSA and certificates to 308 authenticate the server, in addition to using a PSK. 310 As in normal RSA ciphersuites, the server must send a Certificate 311 message. The format of the ServerKeyExchange and ClientKeyExchange 312 messages is shown below. If no PSK identity hint is provided, the 313 ServerKeyExchange message is omitted. 315 struct { 316 select (KeyExchangeAlgorithm) { 317 /* other cases for rsa, diffie_hellman, etc. */ 318 case rsa_psk: /* NEW */ 319 opaque psk_identity_hint<0..2^16-1>; 320 }; 321 } ServerKeyExchange; 323 struct { 324 select (KeyExchangeAlgorithm) { 325 /* other cases for rsa, diffie_hellman, etc. */ 326 case rsa_psk: /* NEW */ 327 opaque psk_identity<0..2^16-1>; 328 EncryptedPreMasterSecret; 329 } exchange_keys; 330 } ClientKeyExchange; 332 The EncryptedPreMasterSecret field sent from the client to the server 333 contains a 2-byte version number and a 46-byte random value, 334 encrypted using the server's RSA public key as described in Section 335 7.4.7.1 of [TLS]. The actual premaster secret is formed by both 336 parties as follows: concatenate a uint16 with the value 48, the 337 2-byte version number and the 46-byte random value, a uint16 338 containing the length of the PSK (in octets), and the PSK itself. 339 (The premaster secret is thus 52 octets longer than the PSK.) 341 This corresponds to the general structure for the premaster secrets 342 (see Note 1 in Section 2) in this document, with "other_secret" 343 containing both the 2-byte version number and the 46-byte random 344 value. 346 Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites 347 themselves specify what the certificates contain (in addition to the 348 RSA public key), or how the certificates are to be validated. In 349 particular, it is possible to use the RSA_PSK ciphersuites with 350 unvalidated self-signed certificates to provide somewhat similar 351 protection against dictionary attacks as the DHE_PSK ciphersuites 352 defined in Section 3. 354 5. Conformance requirements 356 It is expected that different types of identities are useful for 357 different applications running over TLS. This document does not 358 therefore mandate the use of any particular type of identity (such as 359 IPv4 address or FQDN). 361 However, the TLS client and server clearly have to agree on the 362 identities and keys to be used. To improve interoperability, this 363 document places requirements on how the identity is encoded in the 364 protocol, and what kinds of identities and keys implementations have 365 to support. 367 The requirements for implementations are divided to two categories, 368 requirements for TLS implementations and management interfaces. In 369 this context, "TLS implementation" refers to a TLS library or module 370 that is intended to be used for several different purposes, while 371 "management interface" would typically be implemented by a particular 372 application that uses TLS. 374 This document does not specify how the server stores the keys and 375 identities, or how exactly it finds the key corresponding to the 376 identity it receives. For instance, if the identity is a domain 377 name, it might be appropriate to do a case-insensitive lookup. It is 378 RECOMMENDED that before looking up the key, the server processes the 379 PSK identity with a stringprep profile [STRINGPREP] appropriate for 380 the identity in question (such as Nameprep [NAMEPREP] for components 381 of domain names or SASLprep for usernames [SASLPREP]). 383 5.1 PSK identity encoding 385 The PSK identity MUST be first converted to a character string, and 386 then encoded to octets using UTF-8 [UTF8]. For instance, 388 o IPv4 addresses are sent as dotted-decimal strings (e.g., 389 "192.0.2.1"), not as 32-bit integers in network byte order. 391 o Domain names are sent in their usual text form (e.g., 392 "www.example.com" or "embedded.dot.example.net"), not in DNS 393 protocol format. 395 o X.500 Distinguished Names are sent in their string representation 396 [LDAPDN], not as BER-encoded ASN.1. 398 This encoding is clearly not optimal for many types of identities. 399 It was chosen to avoid identity type specific parsing and encoding 400 code in implementations where the identity is configured by a person 401 using some kind of management interface. Requiring such identity 402 type specific code would also increase the chances for 403 interoperability problems resulting from different implementations 404 supporting different identity types. 406 5.2 Identity hint 408 In the absence of an application profile specification specifying 409 otherwise, servers SHOULD NOT provide an identity hint and clients 410 MUST ignore the identity hint field. Applications that do use this 411 field MUST specify its contents, how the value is chosen by the TLS 412 server, and what the TLS client is expected to do with the value. 414 5.3 Requirements for TLS implementations 416 TLS implementations supporting these ciphersuites MUST support 417 arbitrary PSK identities up to 128 octets in length, and arbitrary 418 PSKs up to 64 octets in length. Supporting longer identities and 419 keys is RECOMMENDED. 421 5.4 Requirements for management interfaces 423 In the absence of an application profile specification specifying 424 otherwise, a management interface for entering the PSK and/or PSK 425 identity MUST support the following: 427 o Entering PSK identities consisting of up to 128 printable Unicode 428 characters. Supporting as wide character repertoire and as long 429 identities as feasible is RECOMMENDED. 431 o Entering PSKs up to 64 octets in length as ASCII strings and in 432 hexadecimal encoding. 434 6. IANA considerations 436 IANA does not currently have a registry for TLS ciphersuite or alert 437 numbers, so there are no IANA actions associated with this document. 439 For easier reference in the future, the ciphersuite numbers defined 440 in this document are summarized below. 442 CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A }; 443 CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B }; 444 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C }; 445 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D }; 446 CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E }; 447 CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F }; 448 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 }; 449 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 }; 450 CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 }; 451 CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 }; 452 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 }; 453 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 }; 455 This document also defines a new TLS alert message, 456 unknown_psk_identity(115). 458 7. Security Considerations 460 As with all schemes involving shared keys, special care should be 461 taken to protect the shared values and to limit their exposure over 462 time. 464 7.1 Perfect forward secrecy (PFS) 466 The PSK and RSA_PSK ciphersuites defined in this document do not 467 provide Perfect Forward Secrecy (PFS). That is, if the shared secret 468 key (in PSK ciphersuites), or both the shared secret key and the RSA 469 private key (in RSA_PSK ciphersuites), is somehow compromised, an 470 attacker can decrypt old conversations. 472 The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh 473 DH private key is generated for each handshake. 475 7.2 Brute-force and dictionary attacks 477 Use of a fixed shared secret of limited entropy (for example, a PSK 478 that is relatively short, or was chosen by a human and thus may 479 contain less entropy than its length would imply) may allow an 480 attacker to perform a brute-force or dictionary attack to recover the 481 secret. This may be either an off-line attack (against a captured 482 TLS handshake messages), or an on-line attack where the attacker 483 attempts to connect to the server and tries different keys. 485 For the PSK ciphersuites, an attacker can get the information 486 required for an off-line attack by eavesdropping a TLS handshake, or 487 by getting a valid client to attempt connection with the attacker (by 488 tricking the client to connect to wrong address, or intercepting a 489 connection attempt to the correct address, for instance). 491 For the DHE_PSK ciphersuites, an attacker can obtain the information 492 by getting a valid client to attempt connection with the attacker. 493 Passive eavesdropping alone is not sufficient. 495 For the RSA_PSK ciphersuites, only the server (authenticated using 496 RSA and certificates) can obtain sufficient information for an 497 off-line attack. 499 It is RECOMMENDED that implementations that allow the administrator 500 to manually configure the PSK also provide a functionality for 501 generating a new random PSK, taking [RANDOMNESS] into account. 503 7.3 Identity privacy 505 The PSK identity is sent in cleartext. While using a user name or 506 other similar string as the PSK identity is the most straightforward 507 option, it may lead to problems in some environments since an 508 eavesdropper is able to identify the communicating parties. Even 509 when the identity does not reveal any information itself, reusing the 510 same identity over time may eventually allow an attacker to perform 511 traffic analysis to identify the parties. It should be noted that 512 this is no worse than client certificates, since they are also sent 513 in cleartext. 515 7.4 Implementation notes 517 The implementation notes in [TLS11] about correct implementation and 518 use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including 519 Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as 520 well. 522 8. Acknowledgments 524 The protocol defined in this document is heavily based on work by Tim 525 Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and 526 [AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier 527 work in [KEYEX]. 529 Valuable feedback was also provided by Bernard Aboba, Lakshminath 530 Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley, 531 David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and 532 Mika Tervonen. 534 When the first version of this draft was almost ready, the authors 535 learned that something similar had been proposed already in 1996 536 [PASSAUTH]. However, this draft is not intended for web password 537 authentication, but rather for other uses of TLS. 539 9. References 541 9.1 Normative References 543 [AES] Chown, P., "Advanced Encryption Standard (AES) 544 Ciphersuites for Transport Layer Security (TLS)", RFC 545 3268, June 2002. 547 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", RFC 2119, March 1997. 550 [RANDOMNESS] 551 Eastlake, D., 3rd, Schiller, J., and S. Crocker, 552 "Randomness Requirements for Security", BCP 106, RFC 4086, 553 June 2005. 555 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 556 RFC 2246, January 1999. 558 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 559 10646", RFC 3629, November 2003. 561 9.2 Informative References 563 [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 564 Suites to Transport Layer Security (TLS)", RFC 2712, 565 October 1999. 567 [KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, 568 "Pre-Shared-Key key Exchange methods for TLS", 569 draft-badra-tls-key-exchange-00 (expired), August 2004. 571 [KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF", message on 572 ietf-tls@lists.certicom.com mailing list 2004-01-13, 573 http://www.imc.org/ietf-tls/mail-archive/msg04098.html. 575 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 576 Distinguished Names", draft-ietf-ldapbis-dn-16 (work in 577 progress), February 2005. 579 [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 580 Profile for Internationalized Domain Names (IDN)", RFC 581 3491, March 2003. 583 [PASSAUTH] Simon, D., "Addition of Shared Key Authentication to 584 Transport Layer Security (TLS)", 585 draft-ietf-tls-passauth-00 (expired), November 1996. 587 [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 588 and Passwords", RFC 4013, February 2005. 590 [SHAREDKEYS] 591 Gutmann, P., "Use of Shared Keys in the TLS Protocol", 592 draft-ietf-tls-sharedkeys-02 (expired), October 2003. 594 [SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, 595 "Using SRP for TLS Authentication", draft-ietf-tls-srp-09 596 (work in progress), March 2005. 598 [STRINGPREP] 599 Hoffman, P. and M. Blanchet, "Preparation of 600 Internationalized Strings ("stringprep")", RFC 3454, 601 December 2002. 603 [TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 604 1.1", draft-ietf-tls-rfc2246-bis-12 (work in progress), 605 June 2005. 607 Authors' and Contributors' Addresses 609 Pasi Eronen 610 Nokia Research Center 611 P.O. Box 407 612 FIN-00045 Nokia Group 613 Finland 614 Email: pasi.eronen@nokia.com 616 Hannes Tschofenig 617 Siemens 618 Otto-Hahn-Ring 6 619 Munich, Bayern 81739 620 Germany 621 Email: Hannes.Tschofenig@siemens.com 623 Mohamad Badra 624 ENST Telecom 625 46 rue Barrault 626 75634 Paris 627 France 628 Email: Mohamad.Badra@enst.fr 630 Omar Cherkaoui 631 UQAM University 632 Montreal (Quebec) 633 Canada 634 Email: cherkaoui.omar@uqam.ca 636 Ibrahim Hajjeh 637 ENST Telecom 638 46 rue Barrault 639 75634 Paris 640 France 641 Email: Ibrahim.Hajjeh@enst.fr 643 Ahmed Serhrouchni 644 ENST Telecom 645 46 rue Barrault 646 75634 Paris 647 France 648 Email: Ahmed.Serhrouchni@enst.fr 650 Appendix A. Changelog 652 (This section should be removed by the RFC Editor before 653 publication.) 655 Changes from -08 to -09: 657 o Clarified internationalization of PSK identities in Section 5. 659 o Corrected the example IP address in Section 5.1. 661 o Small clarification to IANA considerations on Section 6. 663 o Editorial: changed numeric references to symbolic ones, updated 664 references to latest versions. 666 Changes from -07 to -08: 668 o Added table of contents and updated I-D boilerplate. 670 o Small clarification to motivation in Section 1. 672 o Small clarification to note 2 in Section 2. 674 o Corrected all instances of "an uint16" to "a uint16". 676 o Updated references to latest versions. 678 Changes from -06 to -07: 680 o Small clarifications to management interface requirements. 682 Changes from -05 to -06: 684 o Small clarifications to how the premaster secret is formed. 686 o Added a section about conformance requirements, and moved existing 687 text about identity formats there. 689 Changes from -04 to -05: 691 o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no 692 identity hint is provided. 694 Changes from -03 to -04: 696 o Added a note about premaster secret "general structure" in 697 Sections 3 and 4. 699 o Something in the I-D submission procedure had removed all 700 circumflexes from -03 version, turning e.g. "2^16" (two-to- the 701 sixteenth power) to "216" (two hundred and sixteen). Let's try 702 again. 704 Changes from -02 to -03: 706 o Aligned the way the premaster secret is derived. 708 o Specified that identities must be sent as human-readable UTF-8 709 strings, not in binary formats. Changed reference to RFC 3629 710 from informative to normative. 712 o Selected ciphersuite and alert numbers, and updated IANA 713 considerations section to match this. 715 o Reworded some text about dictionary attacks in Section 6.2. 717 Changes from -01 to -02: 719 o Clarified text about DHE_PSK ciphersuites in Section 1. 721 o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2. 723 o Added note about certificate validation and self-signed 724 certificates in Section 4. 726 o Added Mohamad Badra et al. as contributors. 728 Changes from draft-ietf-tls-psk-00 to -01: 730 o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated 731 other text accordingly 733 o Removed SHA-1 hash from PSK key exchange premaster secret 734 construction (since premaster secret doesn't need to be 48 bytes). 736 o Added unknown_psk_identity alert message. 738 o Updated IANA considerations section. 740 Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00: 742 o Updated dictionary attack considerations based on comments from 743 David Jablon. 745 o Added a recommendation about using UTF-8 in the identity field. 747 o Removed Appendix A comparing this document with 748 draft-ietf-tls-sharedkeys-02. 750 o Removed IPR comment about SPR. 752 o Minor editorial changes. 754 Intellectual Property Statement 756 The IETF takes no position regarding the validity or scope of any 757 Intellectual Property Rights or other rights that might be claimed to 758 pertain to the implementation or use of the technology described in 759 this document or the extent to which any license under such rights 760 might or might not be available; nor does it represent that it has 761 made any independent effort to identify any such rights. Information 762 on the procedures with respect to rights in RFC documents can be 763 found in BCP 78 and BCP 79. 765 Copies of IPR disclosures made to the IETF Secretariat and any 766 assurances of licenses to be made available, or the result of an 767 attempt made to obtain a general license or permission for the use of 768 such proprietary rights by implementers or users of this 769 specification can be obtained from the IETF on-line IPR repository at 770 http://www.ietf.org/ipr. 772 The IETF invites any interested party to bring to its attention any 773 copyrights, patents or patent applications, or other proprietary 774 rights that may cover technology that may be required to implement 775 this standard. Please address the information to the IETF at 776 ietf-ipr@ietf.org. 778 Disclaimer of Validity 780 This document and the information contained herein are provided on an 781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 783 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 784 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 785 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Copyright Statement 790 Copyright (C) The Internet Society (2005). This document is subject 791 to the rights, licenses and restrictions contained in BCP 78, and 792 except as set forth therein, the authors retain all their rights. 794 Acknowledgment 796 Funding for the RFC Editor function is currently provided by the 797 Internet Society.