--- 1/draft-ietf-tls-psk-01.txt 2006-02-05 02:01:13.000000000 +0100 +++ 2/draft-ietf-tls-psk-02.txt 2006-02-05 02:01:13.000000000 +0100 @@ -1,48 +1,50 @@ -TLS Working Group P. Eronen +TLS Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: February 16, 2005 H. Tschofenig +Expires: March 29, 2005 H. Tschofenig, Ed. Siemens - August 18, 2004 + September 28, 2004 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-psk-01.txt + draft-ietf-tls-psk-02.txt Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with + 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 February 16, 2005. + This Internet-Draft will expire on March 29, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + 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 @@ -88,22 +90,23 @@ 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 give some additional protection against dictionary - attacks, and also provide Perfect Forward Secrecy (PFS). + ciphersuites protect against dictionary attacks by passive + 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 @@ -198,23 +201,23 @@ 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 of the - TLS PRF is used, and the HMAC-MD5 part is not used. See [7] for a - more detailed rationale. + 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. @@ -280,20 +283,28 @@ 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 @@ -377,51 +388,52 @@ 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, and Mika - Tervonen. + 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. - The DHE_PSK and RSA_PSK ciphersuites borrow heavily from [5]. - 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. 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. + [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, @@ -447,49 +459,85 @@ 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 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-07 (work in - progress), June 2004. + 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. -Authors' Addresses +Authors' and Contributors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland - - EMail: pasi.eronen@nokia.com + Email: pasi.eronen@nokia.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany + Email: Hannes.Tschofenig@siemens.com - 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 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.