draft-ietf-tls-psk-08.txt   draft-ietf-tls-psk-09.txt 
TLS Working Group P. Eronen, Ed. TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: October 25, 2005 H. Tschofenig, Ed. Expires: December 20, 2005 H. Tschofenig, Ed.
Siemens Siemens
April 26, 2005 June 21, 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-psk-08.txt draft-ietf-tls-psk-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 25, 2005. This Internet-Draft will expire on December 20, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies three sets of new ciphersuites for the This document specifies three sets of new ciphersuites for the
Transport Layer Security (TLS) protocol to support authentication Transport Layer Security (TLS) protocol to support authentication
based on pre-shared keys. These pre-shared keys are symmetric keys, based on pre-shared keys. These pre-shared keys are symmetric keys,
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Applicability statement . . . . . . . . . . . . . . . . . 4 1.1 Applicability statement . . . . . . . . . . . . . . . . . 4
1.2 Conventions used in this document . . . . . . . . . . . . 4 1.2 Conventions used in this document . . . . . . . . . . . . 4
2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5 2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5
3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7 3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7
4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8 4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8
5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9 5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9
5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9 5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9
5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Requirements for TLS implementations . . . . . . . . . . 10 5.3 Requirements for TLS implementations . . . . . . . . . . 10
5.4 Requirements for management interfaces . . . . . . . . . 10 5.4 Requirements for management interfaces . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11 7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11
7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11 7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11
7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12 7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12
7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12 7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . 13 9.1 Normative References . . . . . . . . . . . . . . . . . . 13
9.2 Informative References . . . . . . . . . . . . . . . . . 13 9.2 Informative References . . . . . . . . . . . . . . . . . 13
Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15 Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Usually TLS uses public key certificates [3] or Kerberos [12] for Usually TLS uses public key certificates [TLS] or Kerberos [KERB] for
authentication. This document describes how to use symmetric keys authentication. This document describes how to use symmetric keys
(later called pre-shared keys or PSKs), shared in advance among the (later called pre-shared keys or PSKs), shared in advance among the
communicating parties, to establish a TLS connection. communicating parties, to establish a TLS connection.
There are basically two reasons why one might want to do this: There are basically two reasons why one might want to do this:
o First, using pre-shared keys can, depending on the ciphersuite, o First, using pre-shared keys can, depending on the ciphersuite,
avoid the need for public key operations. This is useful if TLS avoid the need for public key operations. This is useful if TLS
is used in performance-constrained environments with limited CPU is used in performance-constrained environments with limited CPU
power. power.
skipping to change at page 3, line 29 skipping to change at page 3, line 29
o Second, pre-shared keys may be more convenient from a key o Second, pre-shared keys may be more convenient from a key
management point of view. For instance, in closed environments management point of view. For instance, in closed environments
where the connections are mostly configured manually in advance, where the connections are mostly configured manually in advance,
it may be easier to configure a PSK than to use certificates. it may be easier to configure a PSK than to use certificates.
Another case is when the parties already have a mechanism for Another case is when the parties already have a mechanism for
setting up a shared secret key, and that mechanism could be used setting up a shared secret key, and that mechanism could be used
to "bootstrap" a key for authenticating a TLS connection. to "bootstrap" a key for authenticating a TLS connection.
This document specifies three sets of new ciphersuites for TLS. This document specifies three sets of new ciphersuites for TLS.
These ciphersuites use new key exchange algorithms, and re-use These ciphersuites use new key exchange algorithms, and re-use
existing cipher and MAC algorithms from [3] and [2]. A summary of existing cipher and MAC algorithms from [TLS] and [AES]. A summary
these ciphersuites is shown below. of these ciphersuites is shown below.
CipherSuite Key Exchange Cipher Hash CipherSuite Key Exchange Cipher Hash
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA 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_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_128_CBC_SHA PSK AES_128_CBC SHA
TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_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_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_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_128_CBC_SHA DHE_PSK AES_128_CBC SHA
skipping to change at page 4, line 28 skipping to change at page 4, line 28
alternatives may be more appropriate. alternatives may be more appropriate.
If the main goal is to avoid PKIs, another possibility worth If the main goal is to avoid PKIs, another possibility worth
considering is to use self-signed certificates with public key considering is to use self-signed certificates with public key
fingerprints. Instead of manually configuring a shared secret in, fingerprints. Instead of manually configuring a shared secret in,
for instance, some configuration file, a fingerprint (hash) of the for instance, some configuration file, a fingerprint (hash) of the
other party's public key (or certificate) could be placed there other party's public key (or certificate) could be placed there
instead. instead.
It is also possible to use the SRP (Secure Remote Password) It is also possible to use the SRP (Secure Remote Password)
ciphersuites for shared secret authentication [14]. SRP was designed ciphersuites for shared secret authentication [SRP]. SRP was
to be used with passwords, and incorporates protection against designed to be used with passwords, and incorporates protection
dictionary attacks. However, it is computationally more expensive against dictionary attacks. However, it is computationally more
than the PSK ciphersuites in Section 2. expensive than the PSK ciphersuites in Section 2.
1.2 Conventions used in this document 1.2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [KEYWORDS].
2. PSK key exchange algorithm 2. PSK key exchange algorithm
This section defines the PSK key exchange algorithm and associated This section defines the PSK key exchange algorithm and associated
ciphersuites. These ciphersuites use only symmetric key algorithms. ciphersuites. These ciphersuites use only symmetric key algorithms.
It is assumed that the reader is familiar with ordinary TLS It is assumed that the reader is familiar with ordinary TLS
handshake, shown below. The elements in parenthesis are not included handshake, shown below. The elements in parenthesis are not included
when PSK key exchange algorithm is used, and "*" indicates a when PSK key exchange algorithm is used, and "*" indicates a
situation-dependent message that is not always sent. situation-dependent message that is not always sent.
skipping to change at page 5, line 44 skipping to change at page 5, line 44
authentication by including one or more PSK ciphersuites in the authentication by including one or more PSK ciphersuites in the
ClientHello message. If the TLS server also wants to use pre-shared ClientHello message. If the TLS server also wants to use pre-shared
keys, it selects one of the PSK ciphersuites, places the selected keys, it selects one of the PSK ciphersuites, places the selected
ciphersuite in the ServerHello message, and includes an appropriate ciphersuite in the ServerHello message, and includes an appropriate
ServerKeyExchange message (see below). The Certificate and ServerKeyExchange message (see below). The Certificate and
CertificateRequest payloads are omitted from the response. CertificateRequest payloads are omitted from the response.
Both clients and servers may have pre-shared keys with several Both clients and servers may have pre-shared keys with several
different parties. The client indicates which key to use by different parties. The client indicates which key to use by
including a "PSK identity" in the ClientKeyExchange message (note including a "PSK identity" in the ClientKeyExchange message (note
that unlike in [7], the session_id field in ClientHello message keeps that unlike in [SHAREDKEYS], the session_id field in ClientHello
its usual meaning). To help the client in selecting which identity message keeps its usual meaning). To help the client in selecting
to use, the server can provide a "PSK identity hint" in the which identity to use, the server can provide a "PSK identity hint"
ServerKeyExchange message. If no hint is provided, the in the ServerKeyExchange message. If no hint is provided, the
ServerKeyExchange message is omitted. See Section 5 for more ServerKeyExchange message is omitted. See Section 5 for more
detailed description of these fields. detailed description of these fields.
The format of the ServerKeyExchange and ClientKeyExchange messages is The format of the ServerKeyExchange and ClientKeyExchange messages is
shown below. shown below.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */ /* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */ case psk: /* NEW */
skipping to change at page 6, line 43 skipping to change at page 6, line 43
Here "other_secret" is either zeroes (plain PSK case), or comes Here "other_secret" is either zeroes (plain PSK case), or comes
from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
respectively). See Sections 3 and 4 for a more detailed respectively). See Sections 3 and 4 for a more detailed
description. description.
Note 2: Using zeroes for "other_secret" effectively means that 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 only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
is used when constructing the master secret. This was considered is used when constructing the master secret. This was considered
more elegant from an analytical viewpoint than, for instance, more elegant from an analytical viewpoint than, for instance,
using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See
[8] for a more detailed rationale. [KRAWCZYK] for a more detailed rationale.
The TLS handshake is authenticated using the Finished messages as The TLS handshake is authenticated using the Finished messages as
usual. usual.
If the server does not recognize the PSK identity, it MAY respond If the server does not recognize the PSK identity, it MAY respond
with an "unknown_psk_identity" alert message. Alternatively, if the with an "unknown_psk_identity" alert message. Alternatively, if the
server wishes to hide the fact that the PSK identity was not known, 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 it MAY continue the protocol as if the PSK identity existed but the
key was incorrect: that is, respond with a "decrypt_error" alert. key was incorrect: that is, respond with a "decrypt_error" alert.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */ /* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */ case diffie_hellman_psk: /* NEW */
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..2^16-1>;
ClientDiffieHellmanPublic public; ClientDiffieHellmanPublic public;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The premaster secret is formed as follows. First, perform the The premaster secret is formed as follows. First, perform the
Diffie-Hellman computation in the same way as for other Diffie-Hellman computation in the same way as for other
Diffie-Hellman based ciphersuites in [3]. Let Z be the value Diffie-Hellman based ciphersuites in [TLS]. Let Z be the value
produced by this computation (with leading zero bytes stripped as in produced by this computation (with leading zero bytes stripped as in
other Diffie-Hellman based ciphersuites). Concatenate a uint16 other Diffie-Hellman based ciphersuites). Concatenate a uint16
containing the length of Z (in octets), Z itself, a uint16 containing containing the length of Z (in octets), Z itself, a uint16 containing
the length of the PSK (in octets), and the PSK itself. the length of the PSK (in octets), and the PSK itself.
This corresponds to the general structure for the premaster secrets This corresponds to the general structure for the premaster secrets
(see Note 1 in Section 2) in this document, with "other_secret" (see Note 1 in Section 2) in this document, with "other_secret"
containing Z. containing Z.
4. RSA_PSK key exchange algorithm 4. RSA_PSK key exchange algorithm
skipping to change at page 8, line 35 skipping to change at page 8, line 35
/* other cases for rsa, diffie_hellman, etc. */ /* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */ case rsa_psk: /* NEW */
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..2^16-1>;
EncryptedPreMasterSecret; EncryptedPreMasterSecret;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The EncryptedPreMasterSecret field sent from the client to the server The EncryptedPreMasterSecret field sent from the client to the server
contains a 2-byte version number and a 46-byte random value, contains a 2-byte version number and a 46-byte random value,
encrypted using the server's RSA public 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 7.4.7.1 of [TLS]. The actual premaster secret is formed by both
parties as follows: concatenate a uint16 with the value 48, the parties as follows: concatenate a uint16 with the value 48, the
2-byte version number and the 46-byte random value, a uint16 2-byte version number and the 46-byte random value, a uint16
containing the length of the PSK (in octets), and the PSK itself. containing the length of the PSK (in octets), and the PSK itself.
(The premaster secret is thus 52 octets longer than the PSK.) (The premaster secret is thus 52 octets longer than the PSK.)
This corresponds to the general structure for the premaster secrets This corresponds to the general structure for the premaster secrets
(see Note 1 in Section 2) in this document, with "other_secret" (see Note 1 in Section 2) in this document, with "other_secret"
containing both the 2-byte version number and the 46-byte random containing both the 2-byte version number and the 46-byte random
value. value.
skipping to change at page 9, line 25 skipping to change at page 9, line 25
protocol, and what kinds of identities and keys implementations have protocol, and what kinds of identities and keys implementations have
to support. to support.
The requirements for implementations are divided to two categories, The requirements for implementations are divided to two categories,
requirements for TLS implementations and management interfaces. In requirements for TLS implementations and management interfaces. In
this context, "TLS implementation" refers to a TLS library or module this context, "TLS implementation" refers to a TLS library or module
that is intended to be used for several different purposes, while that is intended to be used for several different purposes, while
"management interface" would typically be implemented by a particular "management interface" would typically be implemented by a particular
application that uses TLS. application that uses TLS.
This document does not specify how the server stores the keys and
identities, or how exactly it finds the key corresponding to the
identity it receives. For instance, if the identity is a domain
name, it might be appropriate to do a case-insensitive lookup. It is
RECOMMENDED that before looking up the key, the server processes the
PSK identity with a stringprep profile [STRINGPREP] appropriate for
the identity in question (such as Nameprep [NAMEPREP] for components
of domain names or SASLprep for usernames [SASLPREP]).
5.1 PSK identity encoding 5.1 PSK identity encoding
The PSK identity MUST be first converted to a character string, and The PSK identity MUST be first converted to a character string, and
then encoded to octets using UTF-8 [5]. For instance, then encoded to octets using UTF-8 [UTF8]. For instance,
o IPv4 addresses are sent as dotted-decimal strings (e.g., o IPv4 addresses are sent as dotted-decimal strings (e.g.,
"192.0.1.2"), not as 32-bit integers in network byte order. "192.0.2.1"), not as 32-bit integers in network byte order.
o Domain names are sent in their usual text form (e.g., o Domain names are sent in their usual text form (e.g.,
"www.example.com" or "embedded.dot.example.net"), not in DNS "www.example.com" or "embedded.dot.example.net"), not in DNS
protocol format. protocol format.
o X.500 Distinguished Names are sent in their string representation o X.500 Distinguished Names are sent in their string representation
[9], not as BER-encoded ASN.1. [LDAPDN], not as BER-encoded ASN.1.
This encoding is clearly not optimal for many types of identities. This encoding is clearly not optimal for many types of identities.
It was chosen to avoid identity type specific parsing and encoding It was chosen to avoid identity type specific parsing and encoding
code in implementations where the identity is configured by a person code in implementations where the identity is configured by a person
using some kind of management interface. Requiring such identity using some kind of management interface. Requiring such identity
type specific code would also increase the chances for type specific code would also increase the chances for
interoperability problems resulting from different implementations interoperability problems resulting from different implementations
supporting different identity types. supporting different identity types.
5.2 Identity hint 5.2 Identity hint
skipping to change at page 10, line 22 skipping to change at page 10, line 31
keys is RECOMMENDED. keys is RECOMMENDED.
5.4 Requirements for management interfaces 5.4 Requirements for management interfaces
In the absence of an application profile specification specifying In the absence of an application profile specification specifying
otherwise, a management interface for entering the PSK and/or PSK otherwise, a management interface for entering the PSK and/or PSK
identity MUST support the following: identity MUST support the following:
o Entering PSK identities consisting of up to 128 printable Unicode o Entering PSK identities consisting of up to 128 printable Unicode
characters. Supporting as wide character repertoire and as long characters. Supporting as wide character repertoire and as long
identities as feasible is RECOMMENDED, as is processing the identities as feasible is RECOMMENDED.
character string with an appropriate stringprep [10] profile.
o Entering PSKs up to 64 octets in length as ASCII strings and in o Entering PSKs up to 64 octets in length as ASCII strings and in
hexadecimal encoding. hexadecimal encoding.
6. IANA considerations 6. IANA considerations
IANA does not currently have a registry for TLS-related numbers, so IANA does not currently have a registry for TLS ciphersuite or alert
there are no IANA actions associated with this document. numbers, so there are no IANA actions associated with this document.
For easier reference in the future, the ciphersuite numbers defined For easier reference in the future, the ciphersuite numbers defined
in this document are summarized below. in this document are summarized below.
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A }; CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B }; CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };
CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C }; CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D }; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D };
CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E }; CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E };
CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F }; CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
skipping to change at page 12, line 23 skipping to change at page 12, line 23
For the DHE_PSK ciphersuites, an attacker can obtain the information For the DHE_PSK ciphersuites, an attacker can obtain the information
by getting a valid client to attempt connection with the attacker. by getting a valid client to attempt connection with the attacker.
Passive eavesdropping alone is not sufficient. Passive eavesdropping alone is not sufficient.
For the RSA_PSK ciphersuites, only the server (authenticated using For the RSA_PSK ciphersuites, only the server (authenticated using
RSA and certificates) can obtain sufficient information for an RSA and certificates) can obtain sufficient information for an
off-line attack. off-line attack.
It is RECOMMENDED that implementations that allow the administrator It is RECOMMENDED that implementations that allow the administrator
to manually configure the PSK also provide a functionality for to manually configure the PSK also provide a functionality for
generating a new random PSK, taking [4] into account. generating a new random PSK, taking [RANDOMNESS] into account.
7.3 Identity privacy 7.3 Identity privacy
The PSK identity is sent in cleartext. While using a user name or The PSK identity is sent in cleartext. While using a user name or
other similar string as the PSK identity is the most straightforward other similar string as the PSK identity is the most straightforward
option, it may lead to problems in some environments since an option, it may lead to problems in some environments since an
eavesdropper is able to identify the communicating parties. Even eavesdropper is able to identify the communicating parties. Even
when the identity does not reveal any information itself, reusing the when the identity does not reveal any information itself, reusing the
same identity over time may eventually allow an attacker to perform same identity over time may eventually allow an attacker to perform
traffic analysis to identify the parties. It should be noted that traffic analysis to identify the parties. It should be noted that
this is no worse than client certificates, since they are also sent this is no worse than client certificates, since they are also sent
in cleartext. in cleartext.
7.4 Implementation notes 7.4 Implementation notes
The implementation notes in [11] about correct implementation and use The implementation notes in [TLS11] about correct implementation and
of RSA (including Section 7.4.7.1) and Diffie-Hellman (including 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 Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
well. well.
8. Acknowledgments 8. Acknowledgments
The protocol defined in this document is heavily based on work by Tim 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]. Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and
The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in [AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier
[6]. work in [KEYEX].
Valuable feedback was also provided by Bernard Aboba, Lakshminath Valuable feedback was also provided by Bernard Aboba, Lakshminath
Dondeti, Philip Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,
Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and
Tervonen. Mika Tervonen.
When the first version of this draft was almost ready, the authors When the first version of this draft was almost ready, the authors
learned that something similar had been proposed already in 1996 learned that something similar had been proposed already in 1996
[13]. However, this draft is not intended for web password [PASSAUTH]. However, this draft is not intended for web password
authentication, but rather for other uses of TLS. authentication, but rather for other uses of TLS.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [AES] Chown, P., "Advanced Encryption Standard (AES)
Levels", RFC 2119, March 1997. Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
for Transport Layer Security (TLS)", RFC 3268, June 2002. Requirement Levels", RFC 2119, March 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [RANDOMNESS]
2246, January 1999. Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
Recommendations for Security", RFC 1750, December 1994. RFC 2246, January 1999.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
3629, November 2003. 10646", RFC 3629, November 2003.
9.2 Informative References 9.2 Informative References
[6] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
"Pre-Shared-Key key Exchange methods for TLS", Suites to Transport Layer Security (TLS)", RFC 2712,
draft-badra-tls-key-exchange-00 (work in progress), August October 1999.
2004.
[7] Gutmann, P., "Use of Shared Keys in the TLS Protocol", [KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
draft-ietf-tls-sharedkeys-02 (expired), October 2003. "Pre-Shared-Key key Exchange methods for TLS",
draft-badra-tls-key-exchange-00 (expired), August 2004.
[8] Krawczyk, H., "Re: TLS shared keys PRF", message on [KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF", message on
ietf-tls@lists.certicom.com mailing list 2004-01-13, ietf-tls@lists.certicom.com mailing list 2004-01-13,
http://www.imc.org/ietf-tls/mail-archive/msg04098.html. http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
[9] Zeilenga, K., "LDAP: String Representation of Distinguished [LDAPDN] Zeilenga, K., "LDAP: String Representation of
Names", draft-ietf-ldapbis-dn-15 (work in progress), October Distinguished Names", draft-ietf-ldapbis-dn-16 (work in
2004. progress), February 2005.
[10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Strings ("stringprep")", RFC 3454, December 2002. Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", [PASSAUTH] Simon, D., "Addition of Shared Key Authentication to
draft-ietf-tls-rfc2246-bis-10 (work in progress), April 2005. Transport Layer Security (TLS)",
draft-ietf-tls-passauth-00 (expired), November 1996.
[12] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
to Transport Layer Security (TLS)", RFC 2712, October 1999. and Passwords", RFC 4013, February 2005.
[13] Simon, D., "Addition of Shared Key Authentication to Transport [SHAREDKEYS]
Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), Gutmann, P., "Use of Shared Keys in the TLS Protocol",
November 1996. draft-ietf-tls-sharedkeys-02 (expired), October 2003.
[14] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using [SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
SRP for TLS Authentication", draft-ietf-tls-srp-09 (work in "Using SRP for TLS Authentication", draft-ietf-tls-srp-09
progress), March 2005. (work in progress), March 2005.
[STRINGPREP]
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-12 (work in progress),
June 2005.
Authors' and Contributors' Addresses Authors' and Contributors' Addresses
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
skipping to change at page 16, line 10 skipping to change at page 16, line 10
46 rue Barrault 46 rue Barrault
75634 Paris 75634 Paris
France France
Email: Ahmed.Serhrouchni@enst.fr Email: Ahmed.Serhrouchni@enst.fr
Appendix A. Changelog Appendix A. Changelog
(This section should be removed by the RFC Editor before (This section should be removed by the RFC Editor before
publication.) publication.)
Changes from -08 to -09:
o Clarified internationalization of PSK identities in Section 5.
o Corrected the example IP address in Section 5.1.
o Small clarification to IANA considerations on Section 6.
o Editorial: changed numeric references to symbolic ones, updated
references to latest versions.
Changes from -07 to -08: Changes from -07 to -08:
o Added table of contents and updated I-D boilerplate. o Added table of contents and updated I-D boilerplate.
o Small clarification to motivation in Section 1. o Small clarification to motivation in Section 1.
o Small clarification to note 2 in Section 2. o Small clarification to note 2 in Section 2.
o Corrected all instances of "an uint16" to "a uint16". o Corrected all instances of "an uint16" to "a uint16".
skipping to change at page 16, line 44 skipping to change at page 17, line 6
o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
identity hint is provided. identity hint is provided.
Changes from -03 to -04: Changes from -03 to -04:
o Added a note about premaster secret "general structure" in o Added a note about premaster secret "general structure" in
Sections 3 and 4. Sections 3 and 4.
o Something in the I-D submission procedure had removed all o Something in the I-D submission procedure had removed all
circumflexes from -03 version, turning e.g. "2^16" (two-to- circumflexes from -03 version, turning e.g. "2^16" (two-to- the
the sixteenth power) to "216" (two hundred and sixteen). sixteenth power) to "216" (two hundred and sixteen). Let's try
Let's try again. again.
Changes from -02 to -03: Changes from -02 to -03:
o Aligned the way the premaster secret is derived. o Aligned the way the premaster secret is derived.
o Specified that identities must be sent as human-readable UTF-8 o Specified that identities must be sent as human-readable UTF-8
strings, not in binary formats. Changed reference to RFC 3629 strings, not in binary formats. Changed reference to RFC 3629
from informative to normative. from informative to normative.
o Selected ciphersuite and alert numbers, and updated IANA o Selected ciphersuite and alert numbers, and updated IANA
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/