draft-ietf-tls-psk-05.txt   draft-ietf-tls-psk-06.txt 
TLS Working Group P. Eronen, Ed. TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: June 17, 2005 H. Tschofenig, Ed. Expires: August 22, 2005 H. Tschofenig, Ed.
Siemens Siemens
December 17, 2004 February 21, 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) 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 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 4, line 48 skipping to change at page 4, line 48
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 [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. If no hint is provided, the ServerKeyExchange message. If no hint is provided, the
ServerKeyExchange message is omitted. ServerKeyExchange message is omitted. See Section 5 for more
detailed description of these fields.
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.
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..2^16-1>;
}; };
skipping to change at page 7, line 10 skipping to change at page 6, line 10
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.
3. DHE_PSK key exchange algorithm 3. DHE_PSK key exchange algorithm
This section defines additional ciphersuites that use a PSK to This section defines additional ciphersuites that use a PSK to
authenticate a Diffie-Hellman exchange. These ciphersuites give some authenticate a Diffie-Hellman exchange. These ciphersuites give some
additional protection against dictionary attacks, and also provide 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. related security considerations.
When these ciphersuites are used, the ServerKeyExchange and When these ciphersuites are used, the ServerKeyExchange and
ClientKeyExchange messages also include the Diffie-Hellman ClientKeyExchange messages also include the Diffie-Hellman
parameters. The PSK identity and identity hint fields have the same parameters. The PSK identity and identity hint fields have the same
meaning as in the previous section (note that the ServerKeyExchange meaning as in the previous section (note that the ServerKeyExchange
message is always sent even if no PSK identity hint is provided). message is always sent even if no PSK identity hint is provided).
The format of the ServerKeyExchange and ClientKeyExchange messages is The format of the ServerKeyExchange and ClientKeyExchange messages is
shown below. shown below.
skipping to change at page 7, line 40 skipping to change at page 6, line 40
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..2^16-1>;
ClientDiffieHellmanPublic public; ClientDiffieHellmanPublic public;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The premaster secret is formed as follows. Let Z be the value The premaster secret is formed as follows. First, perform the
produced by the Diffie-Hellman exchange (with leading zero bytes Diffie-Hellman computation in the same way as for other
stripped as in other Diffie-Hellman based ciphersuites). Concatenate Diffie-Hellman based ciphersuites in [3]. Let Z be the value
an uint16 containing the length of Z (in octets), Z itself, an uint16 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. containing 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
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.
skipping to change at page 8, line 39 skipping to change at page 7, line 39
} 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 [3]. The actual premaster secret is formed by both
parties as follows: concatenate an uint16 with the value 48, the parties as follows: concatenate an uint16 with the value 48, the
2-byte version number and the 46-byte random value, an uint16 2-byte version number and the 46-byte random value, an 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.)
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.
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 3. 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 IANA does not currently have a registry for TLS-related numbers, so
there are no IANA actions associated with this document. 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 };
skipping to change at page 9, line 29 skipping to change at page 10, line 29
CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 }; CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 };
CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 }; 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_RC4_128_SHA = { 0x00, 0x92 };
CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 }; 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_128_CBC_SHA = { 0x00, 0x94 };
CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 }; 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(115). unknown_psk_identity(115).
6. Security Considerations 7. 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) 7.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 7.2 Brute-force and dictionary attacks
Use of a fixed shared secret of limited entropy (for example, a PSK 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 that is relatively short, or was chosen by a human and thus may
contain less entropy than its length would imply) may allow an contain less entropy than its length would imply) may allow an
attacker to perform a brute-force or dictionary attack to recover the attacker to perform a brute-force or dictionary attack to recover the
secret. This may be either an off-line attack (against a captured secret. This may be either an off-line attack (against a captured
TLS handshake messages), or an on-line attack where the attacker TLS handshake messages), or an on-line attack where the attacker
attempts to connect to the server and tries different keys. 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
skipping to change at page 10, line 25 skipping to change at page 11, line 25
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 [4] into account.
6.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.
6.4 Implementation notes 7.4 Implementation notes
The implementation notes in [11] 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 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 [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
[6]. [6].
Valuable feedback was also provided by Philip Ginzboorg, Peter Valuable feedback was also provided by Bernard Aboba, Philip
Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, Nikos
Rescorla, and Mika Tervonen. Mavroyanopoulos, Bodo Moeller, Eric 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
[13]. 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. References 9. References
8.1 Normative References 9.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.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003. 3629, November 2003.
8.2 Informative References 9.2 Informative References
[6] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, [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.
[7] 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.
[8] Krawczyk, H., "Re: TLS shared keys PRF", message on [8] Krawczyk, H., "Re: TLS shared keys PRF", message on
skipping to change at page 14, line 10 skipping to change at page 15, 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 -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: Changes from -04 to -05:
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.
 End of changes. 

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