draft-ietf-tls-psk-02.txt   draft-ietf-tls-psk-03.txt 
TLS Working Group P. Eronen, Ed. TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: March 29, 2005 H. Tschofenig, Ed. Expires: May 17, 2005 H. Tschofenig, Ed.
Siemens Siemens
September 28, 2004 November 16, 2004
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-psk-02.txt draft-ietf-tls-psk-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
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 March 29, 2005. This Internet-Draft will expire on May 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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,
shared in advance among the communicating parties. The first set of shared in advance among the communicating parties. The first set of
ciphersuites uses only symmetric key operations for authentication. ciphersuites uses only symmetric key operations for authentication.
The second set uses a Diffie-Hellman exchange authenticated with a The second set uses a Diffie-Hellman exchange authenticated with a
pre-shared key; and the third set combines public key authentication pre-shared key; and the third set combines public key authentication
of the server with pre-shared key authentication of the client. of the server with pre-shared key authentication of the client.
1. Introduction 1. Introduction
Usually TLS uses public key certificates [3] or Kerberos [11] for Usually TLS uses public key certificates [3] or Kerberos [12] 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, TLS may be used in performance-constrained environments o First, TLS may be used in performance-constrained environments
where the CPU power needed for public key operations is not where the CPU power needed for public key operations is not
available. available.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 [13]. SRP was designed ciphersuites for shared secret authentication [14]. SRP was designed
to be used with passwords, and incorporates protection against to be used with passwords, and incorporates protection against
dictionary attacks. However, it is computationally more expensive dictionary attacks. However, it is computationally more expensive
than the PSK ciphersuites in Section 2. 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 [1].
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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. when PSK key exchange algorithm is used.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
ServerHello ServerHello
(Certificate) (Certificate
)
ServerKeyExchange ServerKeyExchange
(CertificateRequest) (CertificateRequest)
<-------- ServerHelloDone <-------- ServerHelloDone
(Certificate) (Certificate)
ClientKeyExchange ClientKeyExchange
(CertificateVerify) (CertificateVerify)
ChangeCipherSpec ChangeCipherSpec
Finished --------> Finished -------->
ChangeCipherSpec ChangeCipherSpec
<-------- Finished <-------- Finished
skipping to change at page 4, line 43 skipping to change at page 4, 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 [6], the session_id field in ClientHello message keeps that unlike in [7], the session_id field in ClientHello message keeps
its usual meaning). To help the client in selecting which identity its usual meaning). To help the client in selecting which identity
to use, the server can provide a "PSK identity hint" in the to use, the server can provide a "PSK identity hint" in the
ServerKeyExchange message (note that if no hint is provided, a ServerKeyExchange message (note that if no hint is provided, a
ServerKeyExchange message is still sent). ServerKeyExchange message is still sent).
This document does not specify the format of the PSK identity or PSK It is expected that different types of identities are useful for
identity hint; neither is specified how exactly the client uses the different applications running over TLS. This document does not
hint (if it uses it at all). The parties have to agree on the therefore mandate the use of any particular type of identity (such as
identities when the shared secret is configured (however, see Section IPv4 address or FQDN) or identity hint; neither is specified how
6 for related security considerations). In situations where the exactly the client uses the hint (if it uses it at all).
identity is entered by a person, it is RECOMMENDED that the input is
processed using an appropriate stringprep [9] profile and encoded in To increase the chances for successful interoperation between
octets using UTF-8 encoding [14]. One possible stringprep profile is applications that do agree on what type of identity is used, the
described in [8]. 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.
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 */
opaque psk_identity_hint<0..2^16-1>; opaque psk_identity_hint<0..216-1>;
}; };
} ServerKeyExchange; } ServerKeyExchange;
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 */
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..216-1>;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } 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
uint16 with the value N, and the PSK itself.
The premaster secret is formed as follows: If the PSK is N octets Note 1: All the ciphersuites in this document share the same
long, concatenate N zero octets and the PSK. general structure for the premaster secret, namely
Note: This effectively means that only the HMAC-SHA1 part (but not struct {
the HMAC-MD5 part) of the TLS PRF is used when constructing the opaque other_secret<0..216-1>;
master secret. See [7] for a more detailed rationale. opaque psk<0..216-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.
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 6, line 18 skipping to change at page 7, line 25
PSK identity and identity hint fields have the same meaning as in the PSK identity and identity hint fields have the same meaning as in the
previous section. previous section.
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 diffie_hellman_psk: /* NEW */ case diffie_hellman_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>; opaque psk_identity_hint<0..216-1>;
ServerDHParams params; ServerDHParams params;
}; };
} ServerKeyExchange; } ServerKeyExchange;
struct { struct {
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..216-1>;
ClientDiffieHellmanPublic public; ClientDiffieHellmanPublic public;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The premaster secret is formed as follows: concatenate the value The premaster secret is formed as follows. Let Z be the value
produced by the Diffie-Hellman exchange (with leading zero bytes produced by the Diffie-Hellman exchange (with leading zero bytes
stripped as in other Diffie-Hellman based ciphersuites) and the PSK, stripped as in other Diffie-Hellman based ciphersuites). Concatenate
in this order. 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.
4. RSA_PSK key exchange algorithm 4. RSA_PSK key exchange algorithm
The ciphersuites in this section use RSA and certificates to The ciphersuites in this section use RSA and certificates to
authenticate the server, in addition to using a PSK. authenticate the server, in addition to using a PSK.
As in normal RSA ciphersuites, the server must send a Certificate As in normal RSA ciphersuites, the server must send a Certificate
message. The format of the ServerKeyExchange and ClientKeyExchange message. The format of the ServerKeyExchange and ClientKeyExchange
messages is shown below. messages is shown below.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
/* 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_hint<0..2^16-1>; opaque psk_identity_hint<0..216-1>;
}; };
} ServerKeyExchange; } ServerKeyExchange;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
/* 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..216-1>;
EncryptedPreMasterSecret; EncryptedPreMasterSecret;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The premaster secret is formed as follows: concatenate the 48-byte The EncryptedPreMasterSecret field sent from the client to the server
value generated by the client (and sent to the server in contains a 2-byte version number and a 46-byte random value,
ClientKeyExchange message) and the PSK, in this order. encrypted using the server's RSA publi
c 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.
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
themselves specify what the certificates contain (in addition to the themselves specify what the certificates contain (in addition to the
RSA public key), or how the certificates are to be validated. In RSA public key), or how the certificates are to be validated. In
particular, it is possible to use the RSA_PSK ciphersuites with particular, it is possible to use the RSA_PSK ciphersuites with
unvalidated self-signed certificates to provide somewhat similar unvalidated self-signed certificates to provide somewhat similar
protection against dictionary attacks as the DHE_PSK ciphersuites protection against dictionary attacks as the DHE_PSK ciphersuites
defined in Section 4. defined in Section 3.
5. IANA considerations 5. IANA considerations
(This depends on whether this document is published before or after IANA does not currently have a registry for TLS-related numbers, so
TLS 1.1.) there are no IANA actions associated with this document.
(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 For easier reference in the future, the ciphersuite numbers defined
document. For easier reference in the future, the ciphersuite in this document are summarized below.
numbers defined in this document are summarized below.
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };
CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D };
CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E };
CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 };
CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 };
CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 };
CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 };
CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD }; CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 };
This document also defines a new TLS alert message, This document also defines a new TLS alert message,
unknown_psk_identity(TBD). Since IANA does not maintain a registry unknown_psk_identity(115).
of TLS alert messages, no IANA action is needed for this.
6. Security Considerations 6. Security Considerations
As with all schemes involving shared keys, special care should be As with all schemes involving shared keys, special care should be
taken to protect the shared values and to limit their exposure over taken to protect the shared values and to limit their exposure over
time. time.
6.1 Perfect forward secrecy (PFS) 6.1 Perfect forward secrecy (PFS)
The PSK and RSA_PSK ciphersuites defined in this document do not The PSK and RSA_PSK ciphersuites defined in this document do not
provide Perfect Forward Secrecy (PFS). That is, if the shared secret provide Perfect Forward Secrecy (PFS). That is, if the shared secret
key (in PSK ciphersuites), or both the shared secret key and the RSA key (in PSK ciphersuites), or both the shared secret key and the RSA
private key (in RSA_PSK ciphersuites), is somehow compromised, an private key (in RSA_PSK ciphersuites), is somehow compromised, an
attacker can decrypt old conversations. attacker can decrypt old conversations.
The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
DH private key is generated for each handshake. DH private key is generated for each handshake.
6.2 Brute-force and dictionary attacks 6.2 Brute-force and dictionary attacks
Use of a fixed shared secret of limited entropy (such as a password) Use of a fixed shared secret of limited entropy (for example, a PSK
may allow an attacker to perform a brute-force or dictionary attack that is relatively short, or was chosen by a human and thus may
to recover the secret. This may be either an off-line attack contain less entropy than its length would imply) may allow an
(against a captured TLS handshake messages), or an on-line attack attacker to perform a brute-force or dictionary attack to recover the
where the attacker attempts to connect to the server and tries secret. This may be either an off-line attack (against a captured
different keys. 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 For the PSK ciphersuites, an attacker can get the information
required for an off-line attack by eavesdropping a TLS handshake, or required for an off-line attack by eavesdropping a TLS handshake, or
by getting a valid client to attempt connection with the attacker (by by getting a valid client to attempt connection with the attacker (by
tricking the client to connect to wrong address, or intercepting a tricking the client to connect to wrong address, or intercepting a
connection attempt to the correct address, for instance). connection attempt to the correct address, for instance).
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.
skipping to change at page 9, line 25 skipping to change at page 10, line 39
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.
6.4 Implementation notes 6.4 Implementation notes
The implementation notes in [10] about correct implementation and use The implementation notes in [11] about correct implementation and use
of RSA (including Section 7.4.7.1) and Diffie-Hellman (including 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.
7. Acknowledgments 7. 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 [6] and [2]. 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 The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
[5]. [6].
Valuable feedback was also provided by Philip Ginzboorg, Peter Valuable feedback was also provided by Philip Ginzboorg, Peter
Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
Rescorla, and Mika Tervonen. Rescorla, and 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
[12]. However, this draft is not intended for web password [13]. 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.
8. Open issues 8. References
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 8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
9.2 Informative References [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003.
[5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, 8.2 Informative References
[6] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
"Pre-Shared-Key key Exchange methods for TLS", "Pre-Shared-Key key Exchange methods for TLS",
draft-badra-tls-key-exchange-00 (work in progress), August draft-badra-tls-key-exchange-00 (work in progress), August
2004. 2004.
[6] Gutmann, P., "Use of Shared Keys in the TLS Protocol", [7] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
draft-ietf-tls-sharedkeys-02 (expired), October 2003. draft-ietf-tls-sharedkeys-02 (expired), October 2003.
[7] Krawczyk, H., "Re: TLS shared keys PRF", message on [8] 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.
[8] Zeilenga, K., "SASLprep: Stringprep profile for user names and [9] Zeilenga, K., "LDAP: String Representation of Distinguished
passwords", draft-ietf-sasl-saslprep-10 (work in progress), Names", draft-ietf-ldapbis-dn-15 (work in progress), October
July 2004. 2004.
[9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [10] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
[10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", [11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004. draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004.
[11] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites [12] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
to Transport Layer Security (TLS)", RFC 2712, October 1999. to Transport Layer Security (TLS)", RFC 2712, October 1999.
[12] Simon, D., "Addition of Shared Key Authentication to Transport [13] Simon, D., "Addition of Shared Key Authentication to Transport
Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), Layer Security (T
LS)", draft-ietf-tls-passauth-00 (expired),
November 1996. November 1996.
[13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using [14] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
progress), August 2004. progress), August 2004.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003.
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
Hannes Tschofenig Hannes Tschofenig
skipping to change at page 13, line 9 skipping to change at page 14, line 9
ENST Telecom ENST Telecom
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 -02 to -03:
o Aligned the way the premaster secret is derived.
o Specified that identities must be sent as human-readable UTF-8
strings, not in binary formats. Changed reference to RFC 3629
from informative to normative.
o Selected ciphersuite and alert numbers, and updated IANA
considerations section to match this.
o Reworded some text about dictionary attacks in Section 6.2.
Changes from -01 to -02: Changes from -01 to -02:
o Clarified text about DHE_PSK ciphersuites in Section 1. o Clarified text about DHE_PSK ciphersuites in Section 1.
o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2. o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
o Added note about certificate validation and self-signed o Added note about certificate validation and self-signed
certificates in Section 4. certificates in Section 4.
 End of changes. 

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