--- 1/draft-ietf-tls-psk-05.txt 2006-02-05 02:01:17.000000000 +0100 +++ 2/draft-ietf-tls-psk-06.txt 2006-02-05 02:01:17.000000000 +0100 @@ -1,19 +1,19 @@ TLS Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: June 17, 2005 H. Tschofenig, Ed. +Expires: August 22, 2005 H. Tschofenig, Ed. Siemens - December 17, 2004 + February 21, 2005 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) - draft-ietf-tls-psk-05.txt + draft-ietf-tls-psk-06.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. @@ -168,46 +168,22 @@ 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 [7], 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. If no hint is provided, the - ServerKeyExchange message is omitted. - - It is expected that different types of identities are useful for - different applications running over TLS. This document does not - therefore mandate the use of any particular type of identity (such as - IPv4 address or FQDN) or identity hint; neither is specified how - exactly the client uses the hint (if it uses it at all). - - To increase the chances for successful interoperation between - applications that do agree on what type of identity is used, the - identity MUST be first converted to a character string, and then - encoded to octets using UTF-8 [5]. For instance, - - o IPv4 addresses are sent as dotted-decimal strings (e.g., - "192.0.1.2"), not as 32-bit integers in network byte order. - - o Domain names are sent in their usual text form (e.g., - "www.example.com" or "embedded\.dot.example.net"), not in DNS - protocol wire format. - - o X.500 Distinguished Names are sent in their string representation - [9], not as BER-encoded ASN.1. - - In situations where the identity is entered by a person, processing - the character string with an appropriate stringprep [10] profile is - RECOMMENDED. + ServerKeyExchange message is omitted. See Section 5 for more + detailed description of these fields. 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>; }; @@ -249,21 +226,21 @@ 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 + Perfect Forward Secrecy (PFS). See Section 7 for discussion of related security considerations. When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange messages also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section (note that the ServerKeyExchange message is always sent even if no PSK identity hint is provided). The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. @@ -279,24 +256,26 @@ 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. 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 + 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. 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. @@ -323,35 +302,106 @@ } 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 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 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 +5. Conformance requirements + + It is expected that different types of identities are useful for + different applications running over TLS. This document does not + therefore mandate the use of any particular type of identity (such as + IPv4 address or FQDN). + + However, the TLS client and server clearly have to agree on the + identities and keys to be used. To improve interoperability, this + document places requirements on how the identity is encoded on the + wire, and what kinds of identities and keys implementations have to + support. + + The requirements for implementations are divided to two categories, + requirements for TLS implementations and management interfaces. In + this context, "TLS implementation" refers to a TLS library or module + that is intended to be used for several different purposes, while + "management interface" would typically be implemented by a particular + application that uses TLS. + +5.1 PSK identity encoding + + The PSK identity MUST be first converted to a character string, and + then encoded to octets using UTF-8 [5]. For instance, + + o IPv4 addresses are sent as dotted-decimal strings (e.g., + "192.0.1.2"), not as 32-bit integers in network byte order. + + o Domain names are sent in their usual text form (e.g., + "www.example.com" or "embedded.dot.example.net"), not in DNS + protocol wire format. + + o X.500 Distinguished Names are sent in their string representation + [9], not as BER-encoded ASN.1. + + This encoding is clearly not optimal for many types of identities. + It was chosen to avoid identity type specific parsing and encoding + code in implementations where the identity is configured by a person + using some kind of management interface. Requiring such identity + type specific code would also increase the chances for + interoperability problems resulting from different implementations + supporting different identity types. + +5.2 Identity hint + + In the absence of an application profile specification specifying + otherwise, servers SHOULD NOT provide an identity hint and clients + MUST ignore the identity hint field. Applications that do use this + field MUST specify its contents, how the value is chosen by the TLS + server, and what the TLS client is expected to do with the value. + +5.3 Requirements for TLS implementations + + TLS implementations supporting these ciphersuites MUST support + arbitrary PSK identities up to 128 octets in length, and arbitrary + PSKs up to 64 octets in length. Supporting longer identities and + keys is RECOMMENDED. + +5.4 Requirements for management interfaces + + In the absence of an application profile specification specifying + otherwise, a management interface for entering the PSK and/or PSK + identity MUST support entering PSK identities consisting of up to 128 + printable ASCII characters, and MUST support entering PSKs up to 64 + octets in length as ASCII strings and in hexadecimal encoding. + + Supporting as wide character repertoire and as long identities and + keys as feasible is RECOMMENDED, as is processing the character + string with an appropriate stringprep [10] profile. + +6. IANA considerations IANA does not currently have a registry for TLS-related numbers, so 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, 0x8A }; CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B }; CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C }; @@ -361,38 +411,38 @@ CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 }; CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 }; CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 }; CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 }; CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 }; CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 }; This document also defines a new TLS alert message, unknown_psk_identity(115). -6. Security Considerations +7. 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) +7.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 +7.2 Brute-force and dictionary attacks Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) 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 @@ -406,75 +456,75 @@ Passive eavesdropping alone is not sufficient. For the RSA_PSK ciphersuites, only the server (authenticated using 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 +7.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 +7.4 Implementation notes The implementation notes in [11] 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 +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 Philip Ginzboorg, Peter - Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric - Rescorla, and Mika Tervonen. + 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. 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. -8. References +9. References -8.1 Normative 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. [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. -8.2 Informative References +9.2 Informative References [6] 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. [7] Gutmann, P., "Use of Shared Keys in the TLS Protocol", draft-ietf-tls-sharedkeys-02 (expired), October 2003. [8] Krawczyk, H., "Re: TLS shared keys PRF", message on @@ -544,20 +594,27 @@ 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 -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. + Changes from -04 to -05: o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no identity hint is provided. Changes from -03 to -04: o Added a note about premaster secret "general structure" in Sections 3 and 4.