Add.

1 files changed, 900 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-psk-05.txt b/doc/protocol/draft-ietf-tls-psk-05.txt
new file mode 100644
index 0000000000..a9e5403564
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-psk-05.txt
@@ -0,0 +1,900 @@
+
+
+TLS Working Group                                         P. Eronen, Ed.
+Internet-Draft                                                     Nokia
+Expires: June 17, 2005                                H. Tschofenig, Ed.
+                                                                 Siemens
+                                                       December 17, 2004
+
+
+     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
+                       draft-ietf-tls-psk-05.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   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.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 17, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies three sets of new ciphersuites for the
+   Transport Layer Security (TLS) protocol to support authentication
+   based on pre-shared keys.  These pre-shared keys are symmetric keys,
+   shared in advance among the communicating parties.  The first set of
+   ciphersuites uses only symmetric key operations for authentication.
+   The second set uses a Diffie-Hellman exchange authenticated with a
+   pre-shared key; and the third set combines public key authentication
+   of the server with pre-shared key authentication of the client.
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 1]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+1.  Introduction
+
+   Usually TLS uses public key certificates [3] or Kerberos [12] for
+   authentication.  This document describes how to use symmetric keys
+   (later called pre-shared keys or PSKs), shared in advance among the
+   communicating parties, to establish a TLS connection.
+
+   There are basically two reasons why one might want to do this:
+
+   o  First, TLS may be used in performance-constrained environments
+      where the CPU power needed for public key operations is not
+      available.
+
+   o  Second, pre-shared keys may be more convenient from a key
+      management point of view.  For instance, in closed environments
+      where the connections are mostly configured manually in advance,
+      it may be easier to configure a PSK than to use certificates.
+      Another case is when the parties already have a mechanism for
+      setting up a shared secret key, and that mechanism could be used
+      to "bootstrap" a key for authenticating a TLS connection.
+
+   This document specifies three sets of new ciphersuites for TLS.
+   These ciphersuites use new key exchange algorithms, and re-use
+   existing cipher and MAC algorithms from [3] and [2].  A summary of
+   these ciphersuites is shown below.
+
+      CipherSuite                        Key Exchange  Cipher       Hash
+
+      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
+      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
+      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
+      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
+      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
+      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
+      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
+      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
+      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       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_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
+
+   The first set of ciphersuites (with PSK key exchange algorithm),
+   defined in Section 2 use only symmetric key algorithms, and are thus
+   especially suitable for performance-constrained environments.
+
+   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
+   use a PSK to authenticate a Diffie-Hellman exchange.  These
+   ciphersuites protect against dictionary attacks by passive
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 2]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   eavesdroppers (but not active attackers), and also provide Perfect
+   Forward Secrecy (PFS).
+
+   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
+   defined in Section 4, combine public key based authentication of the
+   server (using RSA and certificates) with mutual authentication using
+   a PSK.
+
+1.1  Applicability statement
+
+   The ciphersuites defined in this document are intended for a rather
+   limited set of applications, usually involving only a very small
+   number of clients and servers.  Even in such environments, other
+   alternatives may be more appropriate.
+
+   If the main goal is to avoid PKIs, another possibility worth
+   considering is to use self-signed certificates with public key
+   fingerprints.  Instead of manually configuring a shared secret in,
+   for instance, some configuration file, a fingerprint (hash) of the
+   other party's public key (or certificate) could be placed there
+   instead.
+
+   It is also possible to use the SRP (Secure Remote Password)
+   ciphersuites for shared secret authentication [14].  SRP was designed
+   to be used with passwords, and incorporates protection against
+   dictionary attacks.  However, it is computationally more expensive
+   than the PSK ciphersuites in Section 2.
+
+1.2  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 3]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+2.  PSK key exchange algorithm
+
+   This section defines the PSK key exchange algorithm and associated
+   ciphersuites.  These ciphersuites use only symmetric key algorithms.
+
+   It is assumed that the reader is familiar with ordinary TLS
+   handshake, shown below.  The elements in parenthesis are not included
+   when PSK key exchange algorithm is used, and "*" indicates a
+   situation-dependent message that is not always sent.
+
+      Client                                               Server
+      ------                                               ------
+
+      ClientHello                  -------->
+                                                      ServerHello
+                                                    (Certificate)
+                                               ServerKeyExchange*
+                                             (CertificateRequest)
+                                   <--------      ServerHelloDone
+      (Certificate)
+      ClientKeyExchange
+      (CertificateVerify)
+      ChangeCipherSpec
+      Finished                     -------->
+                                                 ChangeCipherSpec
+                                   <--------             Finished
+      Application Data             <------->     Application Data
+
+
+   The client indicates its willingness to use pre-shared key
+   authentication by including one or more PSK ciphersuites in the
+   ClientHello message.  If the TLS server also wants to use pre-shared
+   keys, it selects one of the PSK ciphersuites, places the selected
+   ciphersuite in the ServerHello message, and includes an appropriate
+   ServerKeyExchange message (see below).  The Certificate and
+   CertificateRequest payloads are omitted from the response.
+
+   Both clients and servers may have pre-shared keys with several
+   different parties.  The client indicates which key to use by
+   including a "PSK identity" in the ClientKeyExchange message (note
+   that unlike in [7], the session_id field in ClientHello message keeps
+   its usual meaning).  To help the client in selecting which identity
+   to use, the server can provide a "PSK identity hint" in the
+   ServerKeyExchange message.  If no hint is provided, the
+   ServerKeyExchange message is omitted.
+
+   It is expected that different types of identities are useful for
+   different applications running over TLS.  This document does not
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 4]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   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
+   shown below.
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case psk:  /* NEW */
+                  opaque psk_identity_hint<0..2^16-1>;
+          };
+      } ServerKeyExchange;
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case psk:   /* NEW */
+                  opaque psk_identity<0..2^16-1>;
+          } exchange_keys;
+      } ClientKeyExchange;
+
+
+
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 5]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   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.
+
+      Note 1: All the ciphersuites in this document share the same
+      general structure for the premaster secret, namely
+
+         struct {
+             opaque other_secret<0..2^16-1>;
+             opaque psk<0..2^16-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
+   usual.
+
+   If the server does not recognize the PSK identity, it MAY respond
+   with an "unknown_psk_identity" alert message.  Alternatively, if the
+   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
+   key was incorrect: that is, respond with a "decrypt_error" alert.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 6]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+3.  DHE_PSK key exchange algorithm
+
+   This section defines additional ciphersuites that use a PSK to
+   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
+   additional protection against dictionary attacks, and also provide
+   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
+   related security considerations.
+
+   When these ciphersuites are used, the ServerKeyExchange and
+   ClientKeyExchange messages also include the Diffie-Hellman
+   parameters.  The PSK identity and identity hint fields have the same
+   meaning as in the previous section (note that the ServerKeyExchange
+   message is always sent even if no PSK identity hint is provided).
+
+   The format of the ServerKeyExchange and ClientKeyExchange messages is
+   shown below.
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case diffie_hellman_psk:  /* NEW */
+                  opaque psk_identity_hint<0..2^16-1>;
+                  ServerDHParams params;
+          };
+      } ServerKeyExchange;
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case diffie_hellman_psk:   /* NEW */
+                  opaque psk_identity<0..2^16-1>;
+                  ClientDiffieHellmanPublic public;
+          } exchange_keys;
+      } ClientKeyExchange;
+
+   The premaster secret is formed as follows.  Let Z be the value
+   produced by the Diffie-Hellman exchange (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.
+
+   This corresponds to the general structure for the premaster secrets
+   (see Note 1 in Section 2) in this document, with "other_secret"
+   containing Z.
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 7]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+4.  RSA_PSK key exchange algorithm
+
+   The ciphersuites in this section use RSA and certificates to
+   authenticate the server, in addition to using a PSK.
+
+   As in normal RSA ciphersuites, the server must send a Certificate
+   message.  The format of the ServerKeyExchange and ClientKeyExchange
+   messages is shown below.  If no PSK identity hint is provided, the
+   ServerKeyExchange message is omitted.
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case rsa_psk:  /* NEW */
+                  opaque psk_identity_hint<0..2^16-1>;
+          };
+      } ServerKeyExchange;
+
+      struct {
+          select (KeyExchangeAlgorithm) {
+              /* other cases for rsa, diffie_hellman, etc. */
+              case rsa_psk:   /* NEW */
+                  opaque psk_identity<0..2^16-1>;
+                  EncryptedPreMasterSecret;
+          } exchange_keys;
+      } ClientKeyExchange;
+
+   The EncryptedPreMasterSecret field sent from the client to the server
+   contains a 2-byte version number and a 46-byte random value,
+   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
+   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.
+
+   This corresponds to the general structure for the premaster secrets
+   (see Note 1 in Section 2) in this document, with "other_secret"
+   containing both the 2-byte version number and the 46-byte random
+   value.
+
+   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 3.
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 8]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+5.  IANA considerations
+
+   IANA does not currently have a registry for TLS-related numbers, so
+   there are no IANA actions associated with this document.
+
+   For easier reference in the future, the ciphersuite numbers defined
+   in this document are summarized below.
+
+      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
+      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_256_CBC_SHA      = { 0x00, 0x8D };
+      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
+      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
+      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_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
+
+   This document also defines a new TLS alert message,
+   unknown_psk_identity(115).
+
+6.  Security Considerations
+
+   As with all schemes involving shared keys, special care should be
+   taken to protect the shared values and to limit their exposure over
+   time.
+
+6.1  Perfect forward secrecy (PFS)
+
+   The PSK and RSA_PSK ciphersuites defined in this document do not
+   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
+   key (in PSK ciphersuites), or both the shared secret key and the RSA
+   private key (in RSA_PSK ciphersuites), is somehow compromised, an
+   attacker can decrypt old conversations.
+
+   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
+   DH private key is generated for each handshake.
+
+6.2  Brute-force and dictionary attacks
+
+   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
+   contain less entropy than its length would imply) may allow an
+   attacker to perform a brute-force or dictionary attack to recover the
+   secret.  This may be either an off-line attack (against a captured
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                 [Page 9]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   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
+   required for an off-line attack by eavesdropping a TLS handshake, or
+   by getting a valid client to attempt connection with the attacker (by
+   tricking the client to connect to wrong address, or intercepting a
+   connection attempt to the correct address, for instance).
+
+   For the DHE_PSK ciphersuites, an attacker can obtain the information
+   by getting a valid client to attempt connection with the attacker.
+   Passive eavesdropping alone is not sufficient.
+
+   For the RSA_PSK ciphersuites, only the server (authenticated using
+   RSA and certificates) can obtain sufficient information for an
+   off-line attack.
+
+   It is RECOMMENDED that implementations that allow the administrator
+   to manually configure the PSK also provide a functionality for
+   generating a new random PSK, taking [4] into account.
+
+6.3  Identity privacy
+
+   The PSK identity is sent in cleartext.  While using a user name or
+   other similar string as the PSK identity is the most straightforward
+   option, it may lead to problems in some environments since an
+   eavesdropper is able to identify the communicating parties.  Even
+   when the identity does not reveal any information itself, reusing the
+   same identity over time may eventually allow an attacker to perform
+   traffic analysis to identify the parties.  It should be noted that
+   this is no worse than client certificates, since they are also sent
+   in cleartext.
+
+6.4  Implementation notes
+
+   The implementation notes in [11] about correct implementation and use
+   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
+   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
+   well.
+
+7.  Acknowledgments
+
+   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].
+   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
+   [6].
+
+   Valuable feedback was also provided by Philip Ginzboorg, Peter
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 10]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
+   Rescorla, and Mika Tervonen.
+
+   When the first version of this draft was almost ready, the authors
+   learned that something similar had been proposed already in 1996
+   [13].  However, this draft is not intended for web password
+   authentication, but rather for other uses of TLS.
+
+8.  References
+
+8.1  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", RFC 2119, March 1997.
+
+   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
+         for Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+         2246, January 1999.
+
+   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+         Recommendations for Security", RFC 1750, December 1994.
+
+   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+         3629, November 2003.
+
+8.2  Informative References
+
+   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
+         "Pre-Shared-Key key Exchange methods for TLS",
+         draft-badra-tls-key-exchange-00 (work in progress), August
+         2004.
+
+   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
+         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
+
+   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
+         ietf-tls@lists.certicom.com mailing list 2004-01-13,
+         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
+
+   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
+         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
+         2004.
+
+   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
+         Strings ("stringprep")", RFC 3454, December 2002.
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 11]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
+         draft-ietf-tls-rfc2246-bis-09 (work in progress), December
+         2004.
+
+   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
+         to Transport Layer Security (TLS)", RFC 2712, October 1999.
+
+   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
+         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
+         November 1996.
+
+   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
+         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
+         progress), August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 12]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+Authors' and Contributors' Addresses
+
+   Pasi Eronen
+   Nokia Research Center
+   P.O. Box 407
+   FIN-00045 Nokia Group
+   Finland
+   Email: pasi.eronen@nokia.com
+
+
+   Hannes Tschofenig
+   Siemens
+   Otto-Hahn-Ring 6
+   Munich, Bayern  81739
+   Germany
+   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
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 13]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+Appendix A.  Changelog
+
+   (This section should be removed by the RFC Editor before
+   publication.)
+
+   Changes from -04 to -05:
+
+   o  Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
+      identity hint is provided.
+
+   Changes from -03 to -04:
+
+   o  Added a note about premaster secret "general structure" in
+      Sections 3 and 4.
+
+   o  Something in the I-D submission procedure had removed all
+         circumflexes from -03 version, turning e.g. "2^16" (two-to-
+         the sixteenth power) to "216" (two hundred and sixteen).
+         Let's try again.
+
+   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:
+
+   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:
+
+   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
+      other text accordingly
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 14]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+   o  Removed SHA-1 hash from PSK key exchange premaster secret
+      construction (since premaster secret doesn't need to be 48 bytes).
+
+   o  Added unknown_psk_identity alert message.
+
+   o  Updated IANA considerations section.
+
+   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
+
+   o  Updated dictionary attack considerations based on comments from
+      David Jablon.
+
+   o  Added a recommendation about using UTF-8 in the identity field.
+
+   o  Removed Appendix A comparing this document with
+      draft-ietf-tls-sharedkeys-02.
+
+   o  Removed IPR comment about SPR.
+
+   o  Minor editorial changes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 15]
+
+Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Eronen & Tschofenig       Expires June 17, 2005                [Page 16]
+
+