draft-ietf-tls-psk-07.txt   draft-ietf-tls-psk-08.txt 
TLS Working Group P. Eronen, Ed. TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: September 12, 2005 H. Tschofenig, Ed. Expires: October 25, 2005 H. Tschofenig, Ed.
Siemens Siemens
March 14, 2005 April 26, 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-psk-07.txt draft-ietf-tls-psk-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
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 June 17, 2005. This Internet-Draft will expire on October 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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,
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Applicability statement . . . . . . . . . . . . . . . . . 4
1.2 Conventions used in this document . . . . . . . . . . . . 4
2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5
3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7
4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8
5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9
5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9
5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Requirements for TLS implementations . . . . . . . . . . 10
5.4 Requirements for management interfaces . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11
7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11
7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12
7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . 13
9.2 Informative References . . . . . . . . . . . . . . . . . 13
Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15
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 [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, using pre-shared keys can, depending on the ciphersuite,
where the CPU power needed for public key operations is not avoid the need for public key operations. This is useful if TLS
available. is used in performance-constrained environments with limited CPU
power.
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.
skipping to change at page 5, line 22 skipping to change at page 6, line 22
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..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 an uint16 with the value N, N zero octets, a second long, concatenate a uint16 with the value N, N zero octets, a second
uint16 with the value N, and the PSK itself. uint16 with the value N, and the PSK itself.
Note 1: All the ciphersuites in this document share the same Note 1: All the ciphersuites in this document share the same
general structure for the premaster secret, namely general structure for the premaster secret, namely
struct { struct {
opaque other_secret<0..2^16-1>; opaque other_secret<0..2^16-1>;
opaque psk<0..2^16-1>; opaque psk<0..2^16-1>;
}; };
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. See [8] for a more is used when constructing the master secret. This was considered
detailed rationale. more elegant from an analytical viewpoint than, for instance,
using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. 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 44 skipping to change at page 7, line 44
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 [3]. 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 an uint16 other Diffie-Hellman based ciphersuites). Concatenate a uint16
containing the length of Z (in octets), Z itself, an uint16 containing the length of Z (in octets), Z itself, a uint16 containing
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
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 7, line 36 skipping to change at page 8, line 36
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 [3]. The actual premaster secret is formed by both
parties as follows: concatenate an 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, an 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.
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
skipping to change at page 11, line 51 skipping to change at page 12, line 51
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 [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 Bernard Aboba, Philip Valuable feedback was also provided by Bernard Aboba, Lakshminath
Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, Nikos Dondeti, Philip Ginzboorg, Peter Gutmann, Russ Housley, David Jablon,
Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika Tervonen. Nikos 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.
9. References 9. References
9.1 Normative References 9.1 Normative References
skipping to change at page 13, line 6 skipping to change at page 14, line 6
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 [9] Zeilenga, K., "LDAP: String Representation of Distinguished
Names", draft-ietf-ldapbis-dn-15 (work in progress), October Names", draft-ietf-ldapbis-dn-15 (work in progress), October
2004. 2004.
[10] 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.
[11] 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-09 (work in progress), December draft-ietf-tls-rfc2246-bis-10 (work in progress), April 2005.
2004.
[12] 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.
[13] 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 (TLS)", draft-ietf-tls-passauth-00 (expired),
November 1996. November 1996.
[14] 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-09 (work in
progress), August 2004. progress), March 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 15, 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 -07 to -08:
o Added table of contents and updated I-D boilerplate.
o Small clarification to motivation in Section 1.
o Small clarification to note 2 in Section 2.
o Corrected all instances of "an uint16" to "a uint16".
o Updated references to latest versions.
Changes from -06 to -07: Changes from -06 to -07:
o Small clarifications to management interface requirements. o Small clarifications to management interface requirements.
Changes from -05 to -06: Changes from -05 to -06:
o Small clarifications to how the premaster secret is formed. o Small clarifications to how the premaster secret is formed.
o Added a section about conformance requirements, and moved existing o Added a section about conformance requirements, and moved existing
text about identity formats there. text about identity formats there.
skipping to change at page 17, line 41 skipping to change at page 18, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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