TLS Working Group P. Eronen, Ed. Internet-Draft Nokia Expires: March 29, 2005 H. Tschofenig, Ed. Siemens September 28, 2004 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) draft-ietf-tls-psk-02.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. 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 March 29, 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, 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. Eronen & Tschofenig Expires March 29, 2005 [Page 1] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 1. Introduction Usually TLS uses public key certificates [3] or Kerberos [11] 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 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. These ciphersuites use new key exchange algorithms, and re-use existing cipher and MAC algorithms from [3] and [2]. A summary of these ciphersuites is shown below. CipherSuite Key Exchange Cipher Hash TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA The first set of ciphersuites (with PSK key exchange algorithm), defined in Section 2 use only symmetric key algorithms, and are thus especially suitable for performance-constrained environments. The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites protect against dictionary attacks by passive Eronen & Tschofenig Expires March 29, 2005 [Page 2] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 eavesdroppers (but not active attackers), and also provide Perfect Forward Secrecy (PFS). The third set of ciphersuites (with RSA_PSK key exchange algorithm), defined in Section 4, combine public key based authentication of the server (using RSA and certificates) with mutual authentication using a PSK. 1.1 Applicability statement The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. If the main goal is to avoid PKIs, another possibility worth considering is to use self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead. It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [13]. SRP was designed to be used with passwords, and incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2. 1.2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Eronen & Tschofenig Expires March 29, 2005 [Page 3] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 2. PSK key exchange algorithm This section defines the PSK key exchange algorithm and associated ciphersuites. These ciphersuites use only symmetric key algorithms. 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) ServerKeyExchange (CertificateRequest) <-------- ServerHelloDone (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished Application Data <-------> Application Data The client indicates its willingness to use pre-shared key authentication by including one or more PSK ciphersuites in the ClientHello message. If the TLS server also wants to use pre-shared keys, it selects one of the PSK ciphersuites, places the selected ciphersuite in the ServerHello message, and includes an appropriate ServerKeyExchange message (see below). The Certificate and CertificateRequest payloads are omitted from the response. Both clients and servers may have pre-shared keys with several different parties. The client indicates which key to use by including a "PSK identity" in the ClientKeyExchange message (note that unlike in [6], the session_id field in ClientHello message keeps its usual meaning). To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message (note that if no hint is provided, a ServerKeyExchange message is still sent). This document does not specify the format of the PSK identity or PSK identity hint; neither is specified how exactly the client uses the hint (if it uses it at all). The parties have to agree on the Eronen & Tschofenig Expires March 29, 2005 [Page 4] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 identities when the shared secret is configured (however, see Section 6 for related security considerations). In situations where the identity is entered by a person, it is RECOMMENDED that the input is processed using an appropriate stringprep [9] profile and encoded in octets using UTF-8 encoding [14]. One possible stringprep profile is described in [8]. 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..2^16-1>; }; } ServerKeyExchange; 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 N zero octets and the PSK. Note: This 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 [7] 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. 3. DHE_PSK key exchange algorithm This section defines additional ciphersuites that use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks, and also provide Perfect Forward Secrecy (PFS). See Section 6 for discussion of Eronen & Tschofenig Expires March 29, 2005 [Page 5] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 related security considerations. When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange also include the Diffie-Hellman parameters. The 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..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..2^16-1>; ClientDiffieHellmanPublic public; } exchange_keys; } ClientKeyExchange; The premaster secret is formed as follows: concatenate the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites) and the PSK, in this order. 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. Eronen & Tschofenig Expires March 29, 2005 [Page 6] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ 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..2^16-1>; EncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange; The premaster secret is formed as follows: concatenate the 48-byte value generated by the client (and sent to the server in ClientKeyExchange message) and the PSK, in this order. 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 4. 5. IANA considerations (This depends on whether this document is published before or after TLS 1.1.) (If after 1.1) This document does not create any new namespaces to be maintained by IANA, but it requires new values in the ciphersuite namespace defined in TLS 1.1 specification. (If before 1.1) There are no IANA actions associated with this document. For easier reference in the future, the ciphersuite numbers defined in this document are summarized below. CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; Eronen & Tschofenig Expires March 29, 2005 [Page 7] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; This document also defines a new TLS alert message, unknown_psk_identity(TBD). Since IANA does not maintain a registry of TLS alert messages, no IANA action is needed for this. 6. Security Considerations As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time. 6.1 Perfect forward secrecy (PFS) The PSK and RSA_PSK ciphersuites defined in this document do not provide Perfect Forward Secrecy (PFS). That is, if the shared secret key (in PSK ciphersuites), or both the shared secret key and the RSA private key (in RSA_PSK ciphersuites), is somehow compromised, an attacker can decrypt old conversations. The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh DH private key is generated for each handshake. 6.2 Brute-force and dictionary attacks Use of a fixed shared secret of limited entropy (such as a password) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. This may be either an off-line attack (against a captured TLS handshake messages), or an on-line attack where the attacker attempts to connect to the server and tries different keys. For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to wrong address, or intercepting a connection attempt to the correct address, for instance). For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient. For the RSA_PSK ciphersuites, only the server (authenticated using Eronen & Tschofenig Expires March 29, 2005 [Page 8] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 RSA and certificates) can obtain sufficient information for an off-line attack. It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking [4] into account. 6.3 Identity privacy The PSK identity is sent in cleartext. While using a user name or other similar string as the PSK identity is the most straightforward option, it may lead to problems in some environments since an eavesdropper is able to identify the communicating parties. Even when the identity does not reveal any information itself, reusing the same identity over time may eventually allow an attacker to perform traffic analysis to identify the parties. It should be noted that this is no worse than client certificates, since they are also sent in cleartext. 6.4 Implementation notes The implementation notes in [10] about correct implementation and use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as well. 7. Acknowledgments The protocol defined in this document is heavily based on work by Tim Dierks and Peter Gutmann, and borrows some text from [6] and [2]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in [5]. Valuable feedback was also provided by Philip Ginzboorg, Peter Gutmann, 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 [12]. However, this draft is not intended for web password authentication, but rather for other uses of TLS. 8. Open issues o Identity privacy could be provided (in DHE_PSK/RSA_PSK versions) by encrypting the psk_identity payload with keys derived from the DH value/RSA-encrypted random (but not PSK). But perhaps this would be an unnecessary complication. Eronen & Tschofenig Expires March 29, 2005 [Page 9] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 o The way the PSK is combined with DH value (and is then used to calculate the Finished message) is not exactly the traditional way. It should be OK with TLS-PRF, though. 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. 9.2 Informative References [5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, "Pre-Shared-Key key Exchange methods for TLS", draft-badra-tls-key-exchange-00 (work in progress), August 2004. [6] Gutmann, P., "Use of Shared Keys in the TLS Protocol", draft-ietf-tls-sharedkeys-02 (expired), October 2003. [7] Krawczyk, H., "Re: TLS shared keys PRF", message on ietf-tls@lists.certicom.com mailing list 2004-01-13, http://www.imc.org/ietf-tls/mail-archive/msg04098.html. [8] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", draft-ietf-sasl-saslprep-10 (work in progress), July 2004. [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004. [11] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [12] Simon, D., "Addition of Shared Key Authentication to Transport Eronen & Tschofenig Expires March 29, 2005 [Page 10] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), November 1996. [13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in progress), August 2004. [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. Eronen & Tschofenig Expires March 29, 2005 [Page 11] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 Authors' and Contributors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Mohamad Badra ENST Telecom 46 rue Barrault 75634 Paris France Email: Mohamad.Badra@enst.fr Omar Cherkaoui UQAM University Montreal (Quebec) Canada Email: cherkaoui.omar@uqam.ca Ibrahim Hajjeh ENST Telecom 46 rue Barrault 75634 Paris France Email: Ibrahim.Hajjeh@enst.fr Ahmed Serhrouchni ENST Telecom 46 rue Barrault 75634 Paris France Email: Ahmed.Serhrouchni@enst.fr Eronen & Tschofenig Expires March 29, 2005 [Page 12] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 Appendix A. Changelog (This section should be removed by the RFC Editor before publication.) Changes from -01 to -02: o Clarified text about DHE_PSK ciphersuites in Section 1. o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2. o Added note about certificate validation and self-signed certificates in Section 4. o Added Mohamad Badra et al. as contributors. Changes from draft-ietf-tls-psk-00 to -01: o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated other text accordingly o Removed SHA-1 hash from PSK key exchange premaster secret construction (since premaster secret doesn't need to be 48 bytes). o Added unknown_psk_identity alert message. o Updated IANA considerations section. Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00: o Updated dictionary attack considerations based on comments from David Jablon. o Added a recommendation about using UTF-8 in the identity field. o Removed Appendix A comparing this document with draft-ietf-tls-sharedkeys-02. o Removed IPR comment about SPR. o Minor editorial changes. Eronen & Tschofenig Expires March 29, 2005 [Page 13] Internet-Draft PSK Ciphersuites for TLS September 28, 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Eronen & Tschofenig Expires March 29, 2005 [Page 14]