--- 1/draft-ietf-tls-psk-07.txt 2006-02-05 02:01:19.000000000 +0100 +++ 2/draft-ietf-tls-psk-08.txt 2006-02-05 02:01:19.000000000 +0100 @@ -1,74 +1,99 @@ TLS Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: September 12, 2005 H. Tschofenig, Ed. +Expires: October 25, 2005 H. Tschofenig, Ed. Siemens - March 14, 2005 + April 26, 2005 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-psk-07.txt + draft-ietf-tls-psk-08.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. + 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 becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 June 17, 2005. + This Internet-Draft will expire on October 25, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). 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, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Applicability statement . . . . . . . . . . . . . . . . . 4 + 1.2 Conventions used in this document . . . . . . . . . . . . 4 + 2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5 + 3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7 + 4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8 + 5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9 + 5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9 + 5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 9 + 5.3 Requirements for TLS implementations . . . . . . . . . . 10 + 5.4 Requirements for management interfaces . . . . . . . . . 10 + 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11 + 7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11 + 7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12 + 7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1 Normative References . . . . . . . . . . . . . . . . . . 13 + 9.2 Informative References . . . . . . . . . . . . . . . . . 13 + Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15 + Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 16 + 1. Introduction Usually TLS uses public key certificates [3] or Kerberos [12] for authentication. This document describes how to use symmetric keys (later called pre-shared keys or PSKs), shared in advance among the communicating parties, to establish a TLS connection. There are basically two reasons why one might want to do this: - o First, TLS may be used in performance-constrained environments - where the CPU power needed for public key operations is not - available. + o First, using pre-shared keys can, depending on the ciphersuite, + avoid the need for public key operations. This is useful if TLS + is used in performance-constrained environments with limited CPU + power. o Second, pre-shared keys may be more convenient from a key management point of view. For instance, in closed environments where the connections are mostly configured manually in advance, it may be easier to configure a PSK than to use certificates. Another case is when the parties already have a mechanism for setting up a shared secret key, and that mechanism could be used to "bootstrap" a key for authenticating a TLS connection. This document specifies three sets of new ciphersuites for TLS. @@ -191,40 +216,42 @@ struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ 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 + long, concatenate a 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..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 - detailed rationale. + is used when constructing the master secret. This was considered + more elegant from an analytical viewpoint than, for instance, + using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See + [8] for a more detailed rationale. The TLS handshake is authenticated using the Finished messages as usual. If the server does not recognize the PSK identity, it MAY respond with an "unknown_psk_identity" alert message. Alternatively, if the server wishes to hide the fact that the PSK identity was not known, it MAY continue the protocol as if the PSK identity existed but the key was incorrect: that is, respond with a "decrypt_error" alert. @@ -260,23 +287,23 @@ case diffie_hellman_psk: /* NEW */ opaque psk_identity<0..2^16-1>; ClientDiffieHellmanPublic public; } exchange_keys; } ClientKeyExchange; The premaster secret is formed as follows. First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman based ciphersuites in [3]. Let Z be the value produced by this computation (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. + other Diffie-Hellman based ciphersuites). Concatenate a uint16 + containing the length of Z (in octets), Z itself, a 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. @@ -299,22 +326,22 @@ case rsa_psk: /* NEW */ 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 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 + parties as follows: concatenate a uint16 with the value 48, the + 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.) 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 @@ -484,23 +511,24 @@ Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as well. 8. Acknowledgments The protocol defined in this document is heavily based on work by Tim Dierks and Peter Gutmann, and borrows some text from [7] and [2]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in [6]. - Valuable feedback was also provided by Bernard Aboba, Philip - Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, Nikos - Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika Tervonen. + Valuable feedback was also provided by Bernard Aboba, Lakshminath + Dondeti, Philip Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, + Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika + Tervonen. When the first version of this draft was almost ready, the authors learned that something similar had been proposed already in 1996 [13]. However, this draft is not intended for web password authentication, but rather for other uses of TLS. 9. References 9.1 Normative References @@ -534,33 +562,32 @@ http://www.imc.org/ietf-tls/mail-archive/msg04098.html. [9] Zeilenga, K., "LDAP: String Representation of Distinguished Names", draft-ietf-ldapbis-dn-15 (work in progress), October 2004. [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-09 (work in progress), December - 2004. + draft-ietf-tls-rfc2246-bis-10 (work in progress), April 2005. [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 (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. + SRP for TLS Authentication", draft-ietf-tls-srp-09 (work in + progress), March 2005. Authors' and Contributors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com @@ -596,20 +623,32 @@ 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 -07 to -08: + + o Added table of contents and updated I-D boilerplate. + + o Small clarification to motivation in Section 1. + + o Small clarification to note 2 in Section 2. + + o Corrected all instances of "an uint16" to "a uint16". + + o Updated references to latest versions. + Changes from -06 to -07: o Small clarifications to management interface requirements. Changes from -05 to -06: o Small clarifications to how the premaster secret is formed. o Added a section about conformance requirements, and moved existing text about identity formats there. @@ -708,18 +747,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.