--- 1/draft-ietf-tls-psk-03.txt 2006-02-05 02:01:15.000000000 +0100 +++ 2/draft-ietf-tls-psk-04.txt 2006-02-05 02:01:15.000000000 +0100 @@ -1,18 +1,18 @@ TLS Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: May 17, 2005 H. Tschofenig, Ed. +Expires: May 25, 2005 H. Tschofenig, Ed. Siemens - November 16, 2004 + November 24, 2004 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-psk-03.txt + draft-ietf-tls-psk-04.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. @@ -25,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 17, 2005. + This Internet-Draft will expire on May 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, @@ -138,22 +138,21 @@ It is assumed that the reader is familiar with ordinary TLS handshake, shown below. The elements in parenthesis are not included when PSK key exchange algorithm is used. Client Server ------ ------ ClientHello --------> ServerHello - (Certificate -) + (Certificate) ServerKeyExchange (CertificateRequest) <-------- ServerHelloDone (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished @@ -201,41 +200,41 @@ the character string with an appropriate stringprep [10] profile is RECOMMENDED. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ - opaque psk_identity_hint<0..216-1>; + opaque psk_identity_hint<0..2^16-1>; }; } ServerKeyExchange; struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ - opaque psk_identity<0..216-1>; + opaque psk_identity<0..2^16-1>; } exchange_keys; } ClientKeyExchange; The premaster secret is formed as follows: if the PSK is N octets long, concatenate an uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself. Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely struct { - opaque other_secret<0..216-1>; - opaque psk<0..216-1>; + opaque other_secret<0..2^16-1>; + opaque psk<0..2^16-1>; }; Here "other_secret" is either zeroes (plain PSK case), or comes from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, respectively). See Sections 3 and 4 for a more detailed description. Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. See [8] for a more @@ -263,75 +262,83 @@ PSK identity and identity hint fields have the same meaning as in the previous section. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case diffie_hellman_psk: /* NEW */ - opaque psk_identity_hint<0..216-1>; + opaque psk_identity_hint<0..2^16-1>; ServerDHParams params; }; } ServerKeyExchange; struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case diffie_hellman_psk: /* NEW */ - opaque psk_identity<0..216-1>; + opaque psk_identity<0..2^16-1>; ClientDiffieHellmanPublic public; } exchange_keys; } ClientKeyExchange; The premaster secret is formed as follows. Let Z be the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites). Concatenate an uint16 containing the length of Z (in octets), Z itself, an uint16 containing the length of the PSK (in octets), and the PSK itself. + This corresponds to the general structure for the premaster secrets + (see Note 1 in Section 2) in this document, with "other_secret" + containing Z. + 4. RSA_PSK key exchange algorithm The ciphersuites in this section use RSA and certificates to authenticate the server, in addition to using a PSK. As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ - opaque psk_identity_hint<0..216-1>; + opaque psk_identity_hint<0..2^16-1>; }; } ServerKeyExchange; struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ - opaque psk_identity<0..216-1>; + opaque psk_identity<0..2^16-1>; EncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange; The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, - encrypted using the server's RSA publi -c key as described in Section + encrypted using the server's RSA public key as described in Section 7.4.7.1 of [3]. The actual premaster secret is formed by both parties as follows: concatenate an uint16 with the value 48, the 2-byte version number and the 46-byte random value, an uint16 containing the length of the PSK (in octets), and the PSK itself. + This corresponds to the general structure for the premaster secrets + (see Note 1 in Section 2) in this document, with "other_secret" + containing both the 2-byte version number and the 46-byte random + value. + Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites themselves specify what the certificates contain (in addition to the RSA public key), or how the certificates are to be validated. In particular, it is possible to use the RSA_PSK ciphersuites with unvalidated self-signed certificates to provide somewhat similar protection against dictionary attacks as the DHE_PSK ciphersuites defined in Section 3. 5. IANA considerations @@ -477,22 +484,21 @@ [10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004. [12] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [13] Simon, D., "Addition of Shared Key Authentication to Transport - Layer Security (T -LS)", draft-ietf-tls-passauth-00 (expired), + Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), November 1996. [14] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in progress), August 2004. Authors' and Contributors' Addresses Pasi Eronen Nokia Research Center @@ -533,20 +539,30 @@ 46 rue Barrault 75634 Paris France Email: Ahmed.Serhrouchni@enst.fr Appendix A. Changelog (This section should be removed by the RFC Editor before publication.) + Changes from -03 to -04: + + o Added a note about premaster secret "general structure" in + Sections 3 and 4. + + o Something in the I-D submission procedure had removed all + circumflexes from -03 version, turning e.g. "2^16" (two-to- + the sixteenth power) to "216" (two hundred and sixteen). + Let's try again. + Changes from -02 to -03: o Aligned the way the premaster secret is derived. o Specified that identities must be sent as human-readable UTF-8 strings, not in binary formats. Changed reference to RFC 3629 from informative to normative. o Selected ciphersuite and alert numbers, and updated IANA considerations section to match this.