draft-ietf-tls-psk-01.txt   draft-ietf-tls-psk-02.txt 
TLS Working Group P. Eronen TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: February 16, 2005 H. Tschofenig Expires: March 29, 2005 H. Tschofenig, Ed.
Siemens Siemens
August 18, 2004 September 28, 2004
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-psk-01.txt draft-ietf-tls-psk-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 February 16, 2005. This Internet-Draft will expire on March 29, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 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
skipping to change at page 2, line 52 skipping to change at page 2, line 52
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
The first set of ciphersuites (with PSK key exchange algorithm), The first set of ciphersuites (with PSK key exchange algorithm),
defined in Section 2 use only symmetric key algorithms, and are thus defined in Section 2 use only symmetric key algorithms, and are thus
especially suitable for performance-constrained environments. especially suitable for performance-constrained environments.
The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
use a PSK to authenticate a Diffie-Hellman exchange. These use a PSK to authenticate a Diffie-Hellman exchange. These
ciphersuites give some additional protection against dictionary ciphersuites protect against dictionary attacks by passive
attacks, and also provide Perfect Forward Secrecy (PFS). eavesdroppers (but not active attackers), and also provide Perfect
Forward Secrecy (PFS).
The third set of ciphersuites (with RSA_PSK key exchange algorithm), The third set of ciphersuites (with RSA_PSK key exchange algorithm),
defined in Section 4, combine public key based authentication of the defined in Section 4, combine public key based authentication of the
server (using RSA and certificates) with mutual authentication using server (using RSA and certificates) with mutual authentication using
a PSK. a PSK.
1.1 Applicability statement 1.1 Applicability statement
The ciphersuites defined in this document are intended for a rather The ciphersuites defined in this document are intended for a rather
limited set of applications, usually involving only a very small limited set of applications, usually involving only a very small
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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..2^16-1>;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
The premaster secret is formed as follows: If the PSK is N octets The premaster secret is formed as follows: If the PSK is N octets
long, concatenate N zero octets and the PSK. long, concatenate N zero octets and the PSK.
Note: This effectively means that only the HMAC-SHA1 part of the Note: This effectively means that only the HMAC-SHA1 part (but not
TLS PRF is used, and the HMAC-MD5 part is not used. See [7] for a the HMAC-MD5 part) of the TLS PRF is used when constructing the
more detailed rationale. master secret. See [7] 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 26 skipping to change at page 7, line 26
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 premaster secret is formed as follows: concatenate the 48-byte The premaster secret is formed as follows: concatenate the 48-byte
value generated by the client (and sent to the server in value generated by the client (and sent to the server in
ClientKeyExchange message) and the PSK, in this order. ClientKeyExchange message) and the PSK, in this order.
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
themselves specify what the certificates contain (in addition to the
RSA public key), or how the certificates are to be validated. In
particular, it is possible to use the RSA_PSK ciphersuites with
unvalidated self-signed certificates to provide somewhat similar
protection against dictionary attacks as the DHE_PSK ciphersuites
defined in Section 4.
5. IANA considerations 5. IANA considerations
(This depends on whether this document is published before or after (This depends on whether this document is published before or after
TLS 1.1.) TLS 1.1.)
(If after 1.1) This document does not create any new namespaces to be (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 maintained by IANA, but it requires new values in the ciphersuite
namespace defined in TLS 1.1 specification. namespace defined in TLS 1.1 specification.
(If before 1.1) There are no IANA actions associated with this (If before 1.1) There are no IANA actions associated with this
skipping to change at page 9, line 28 skipping to change at page 9, line 34
The implementation notes in [10] about correct implementation and use The implementation notes in [10] 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 [6] and [2].
The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
[5].
Valuable feedback was also provided by Philip Ginzboorg, Peter Valuable feedback was also provided by Philip Ginzboorg, Peter
Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, and Mika Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
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 [12]. 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.
The DHE_PSK and RSA_PSK ciphersuites borrow heavily from [5].
8. Open issues 8. Open issues
o Identity privacy could be provided (in DHE_PSK/RSA_PSK versions) o Identity privacy could be provided (in DHE_PSK/RSA_PSK versions)
by encrypting the psk_identity payload with keys derived from the by encrypting the psk_identity payload with keys derived from the
DH value/RSA-encrypted random (but not PSK). But perhaps this DH value/RSA-encrypted random (but not PSK). But perhaps this
would be an unnecessary complication. would be an unnecessary complication.
o The way the PSK is combined with DH value (and is then used to o The way the PSK is combined with DH value (and is then used to
calculate the Finished message) is not exactly the traditional calculate the Finished message) is not exactly the traditional
way. It should be OK with TLS-PRF, though. way. It should be OK with TLS-PRF, though.
9. References 9. References
9.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 for [2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
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 9.2 Informative References
[5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, [5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
skipping to change at page 11, line 4 skipping to change at page 11, line 8
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 [11] 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 [12] Simon, D., "Addition of Shared Key Authentication to Transport
Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired), Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired),
November 1996. November 1996.
[13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using [13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
SRP for TLS Authentication", draft-ietf-tls-srp-07 (work in SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
progress), June 2004. progress), August 2004.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003. 3629, November 2003.
Authors' 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
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bayern 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com Mohamad Badra
ENST Telecom
46 rue Barrault
75634 Paris
France
Email: Mohamad.Badra@enst.fr
Omar Cherkaoui
UQAM University
Montreal (Quebec)
Canada
Email: cherkaoui.omar@uqam.ca
Ibrahim Hajjeh
ENST Telecom
46 rue Barrault
75634 Paris
France
Email: Ibrahim.Hajjeh@enst.fr
Ahmed Serhrouchni
ENST Telecom
46 rue Barrault
75634 Paris
France
Email: Ahmed.Serhrouchni@enst.fr
Appendix A. Changelog 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 -01 to -02:
o Clarified text about DHE_PSK ciphersuites in Section 1.
o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
o Added note about certificate validation and self-signed
certificates in Section 4.
o Added Mohamad Badra et al. as contributors.
Changes from draft-ietf-tls-psk-00 to -01: Changes from draft-ietf-tls-psk-00 to -01:
o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
other text accordingly other text accordingly
o Removed SHA-1 hash from PSK key exchange premaster secret o Removed SHA-1 hash from PSK key exchange premaster secret
construction (since premaster secret doesn't need to be 48 bytes). construction (since premaster secret doesn't need to be 48 bytes).
o Added unknown_psk_identity alert message. o Added unknown_psk_identity alert message.
 End of changes. 

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