Add.

8 files changed, 6954 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-srp-00.txt b/doc/protocol/draft-ietf-tls-srp-00.txt
new file mode 100644
index 0000000000..814b9205e7
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-00.txt
@@ -0,0 +1,504 @@
+
+
+Network Working Group                                          D. Taylor
+Internet-Draft                                    Forge Research Pty Ltd
+Expires: August 6, 2001                                 February 5, 2001
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-00.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 August 6, 2001.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP (Secure Remote
+   Password) protocol as an authentication method for the TLS
+   (Transport Layer Security) protocol. 
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+1. Introduction
+
+   At the time of writing, TLS[1] uses public key certificiates with
+   RSA/DSA digital signatures, or Kerberos, for authentication. 
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP[3], FTP[4], or
+   TELNET[5], for example). Given these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to use user names and passwords to
+   authenticate the TLS connection seems to be a useful feature. 
+
+   SRP[2] is an authentication method that allows the use of user names
+   and passwords in a safe manner. 
+
+   This document describes the use of the SRP authentication method for
+   TLS. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The SRP protocol can not be implemented using the sequence of
+   handshake messages defined in [1] due to the sequence in which the
+   SRP messages must be sent. 
+
+   This document proposes a new sequence of handshake messages for
+   handshakes using the SRP authentication method. 
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (U) ------------------------>  |
+            |  <---------------------------- Server Hello
+            |  <---------------------------- Server Key Exchange (g, N, s)
+       Client Key Exchange (A) ----------------->  |
+            |  <---------------------------- Server Key Exchange (B)
+            |  <---------------------------- Server Hello Done
+       change cipher spec                          |
+       Finished -------------------------------->  |
+            |                                change cipher spec
+            |  <---------------------------- Finished
+            |                                      |
+
+   The identifiers given after each message name refer to variables
+   defined in [2] that are sent in that message.
+
+   This new handshake sequence has a number of differences from the
+   standard TLS handshake sequence: 
+
+   o  The client hello message has the user name appended to the
+      message. This is allowable as stated in section 7.4.1.2 of [1]. 
+
+   o  The client cannot generate its its public key (A) until after it
+      has received the (g) and (N) paramters from the server, and the
+      client must send its public key before it receives the servers
+      public key (B) (as stated in section 3 of [2]). This means the
+      client must wait for a server key exchange message containing (g)
+      and (N), send a client key exchange message containing (A), and
+      then wait for another server key exchange message containing (B). 
+
+   o  There is no server identification in this version of a TLS
+      handshake. If an attacker gets the SRP password file, they can
+      masquerade as the real system. 
+
+
+Taylor                   Expires August 6, 2001                 [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+2.2 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication. The details of
+   the on-the-wire changes are given in Section 2.5. 
+
+2.2.1 The Client Hello Message
+
+   The user name is appended to the standard client hello message. The
+   extra data is included in the handshake message hashes. 
+
+2.2.2 The First Server Key Exchange Message
+
+   The server key exchange message in the first round contains the
+   generator (g), the prime (N), and the salt value (s) read from the
+   SRP password file. 
+
+2.2.3 The Client Key Exchange Message
+
+   The client key exchange message carries the clients public key (A),
+   which is calculated using both information known locally, and
+   information received in the first server key exchange message. This
+   message MUST be sent between the first and second server key
+   exchange messages. 
+
+2.2.4 The Second Server Key Exchange Message
+
+   The server key exchange message in the second round contains the
+   servers public key (B). 
+
+2.3 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) is used as
+   the pre-master secret. 
+
+   The finished messages perform the same function as the client and
+   server evidence messages specified in [2]. If either the client or
+   the server calculate an incorrect value, the finished messages will
+   not be understood, and the connection will be dropped as specified
+   in [1]. 
+
+2.4 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft. The numbers
+   have been left blank until a suitable range has been selected. 
+
+      CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_SHA       = { ?,? };
+
+      CipherSuite     TLS_SRP_WITH_RC4_128_SHA            = { ?,? };
+
+
+Taylor                   Expires August 6, 2001                 [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+      CipherSuite     TLS_SRP_WITH_IDEA_CBC_SHA           = { ?,? };
+
+      CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_MD5       = { ?,? };
+
+      CipherSuite     TLS_SRP_WITH_RC4_128_MD5            = { ?,? };
+
+      CipherSuite     TLS_SRP_WITH_IDEA_CBC_MD5           = { ?,? };
+
+2.5 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication. The representation
+   language used is that used in [1]. 
+
+   opaque Username<1..2^8-1>;
+
+   enum { non_srp, srp } CipherSuiteType;
+
+   struct {
+      ProtocolVersion client_version;
+      Random random;
+      SessionID session_id;
+      CipherSuite cipher_suites<2..2^16-1>;
+
+      /* Need a better way to show the optional user_name field */
+      select (CipherSuiteType) {
+         case non_srp:
+            CompressionMethod compression_methods<1..2^8-1>;
+         case srp:
+            CompressionMethod compression_methods<1..2^8-1>;
+            Username user_name;   /* new entry */
+      };
+   } ClientHello;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   enum { first, second } KeyExchangeRound;
+
+   struct {
+      select (KeyExchangeRound) {
+         case first:
+            opaque srp_s<1..2^8-1>
+            opaque srp_N<1..2^16-1>;
+            opaque srp_g<1..2^16-1>;
+         case second:
+            opaque srp_B<1..2^16-1>;
+      };
+   } ServerSRPParams;     /* SRP parameters */
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:
+            ServerSRPParams params;   /* new entry */
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } SRPClientEphemeralPublic;
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: SRPClientEphemeralPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+3. Security Considerations
+
+   There is no server identification in this version of a TLS
+   handshake. If an attacker gets the SRP password file, they can
+   masquerade as the real system. 
+
+   What are the security issues of this new handshake sequence? Are the
+   SRP parameters passed in a safe order? Is it a problem having the
+   username appended to the client hello message? 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+References
+
+   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+        June 1999.
+
+   [4]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+        V. Wiegand, "Securing FTP with TLS",
+        draft-murray-auth-ftp-ssl-06 (work in progress), September 2000.
+
+   [5]  Boe, M. and J. Altman, "TLS-based Telnet Security",
+        draft-ietf-tn3270e-telnet-tls-05 (work in progress), October
+        2000.
+
+
+Author's Address
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.protekt.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication       February 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires August 6, 2001                 [Page 9]
+
diff --git a/doc/protocol/draft-ietf-tls-srp-01.txt b/doc/protocol/draft-ietf-tls-srp-01.txt
new file mode 100644
index 0000000000..f122ddd944
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-01.txt
@@ -0,0 +1,728 @@
+
+
+Network Working Group                                          D. Taylor
+Internet-Draft                                    Forge Research Pty Ltd
+Expires: December 28, 2001                                 June 29, 2001
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-01
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 December 28, 2001.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP (Secure Remote
+   Password) protocol as an authentication method for the TLS (Transport
+   Layer Security) protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1.2 Session re-use . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
+   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
+   2.3.1 The Client Hello Message . . . . . . . . . . . . . . . . . .  6
+   2.3.2 The Server Hello Message . . . . . . . . . . . . . . . . . .  6
+   2.3.3 The Client Key Exchange Message  . . . . . . . . . . . . . .  6
+   2.3.4 The Server Key Exchange Message  . . . . . . . . . . . . . .  6
+   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
+   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
+   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
+   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+1. Introduction
+
+   At the time of writing, TLS [1] uses public key certificiates with
+   RSA/DSA digital signatures, or Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP [3], FTP [4], or
+   TELNET [5], for example).  Given these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to use user names and passwords to
+   authenticate the TLS connection seems to be a useful feature.
+
+   SRP [2] is an authentication method that allows the use of user names
+   and passwords over unencrypted channels without revealing the
+   password to an eavesdropper.  SRP also supplies a shared secret at
+   the end of the authetication sequence that can be used to generate
+   encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The SRP protocol can not be implemented using the sequence of
+   handshake messages defined in [1] due to the sequence in which the
+   SRP messages must be sent.
+
+   This document proposes a new sequence of handshake messages for
+   handshakes using the SRP authentication method.
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (U, mds)-------------------->  |
+            |  <---------------------------- Server Hello (md, g, N, s)
+       Client Key Exchange (A) ----------------->  |
+            |  <---------------------------- Server Key Exchange (B)
+            |  <---------------------------- Server Hello Done
+       change cipher spec                          |
+       Finished -------------------------------->  |
+            |                                change cipher spec
+            |  <---------------------------- Finished
+            |                                      |
+
+   The identifiers given after each message name refer to the SRP
+   variables included in that message.  The variables are defined in
+   [2], except for (mds) and (md) which are defined in this document.
+
+   Extended client and server hello messages, as defined in [6], are
+   used to to send the initial client and server values.
+
+   The client key exchange message is sent during the sequence of server
+   messages.  This modification is required because the client must send
+   its public key (A) before it receives the servers public key (B), as
+   stated in Section 3 of [2].
+
+2.1.2 Session re-use
+
+   The short handshake mechanism for re-using sessions for new
+   connections, and renegotiating keys for existing connections will
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+   authentication, it MUST still include the SRP extension carrying the
+
+
+
+Taylor                  Expires December 28, 2001               [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+   user name (U) in the client hello message, in case the server cannot
+   or will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If a client requests an existing session and the server agrees to use
+   it (meaning the short handshake will be used), the server MAY omit
+   the SRP extension from the server hello message, as the information
+   it contains is not used in the short handshake.
+
+2.2 SRP Verifier Message Digest Selection
+
+   SRP uses a message digest algorithm when creating password verifiers,
+   and when performing calculations during authentication.  At the time
+   of writing, SHA-1 is the only algorithm that has been defined for use
+   with SRP.  However, there is no reason other message digest
+   algorithms cannot be used, and the handshake messages and extensions
+   defined by this draft include a message digest algorithm selection
+   mechanism.
+
+   The passwordMessageDigest enumerated, the srp_mds vector, and srp_md
+   value are used to determine which message digest alorithm is to be
+   used by the client when it is performing the SRP calculation.  The
+   server determines which message digest algorithm to use based on the
+   list of message digest algorithms requested by the client, and the
+   list of available SRP verifiers known by the server.
+
+   The client sends a list of message digest algorithms it can use for
+   the SRP calculation using the srp_mds vector.  The server MUST select
+   a message digest algorithm that is in the list supplied by the
+   client, and the server MUST have access to an SRP verifier calculated
+   with the selected message digest algorithm.
+
+   If the server has access to multiple SRP verifiers for the given user
+   (each calculated using a different message disgest algorithm), the
+   server may select whichever matching message digest algorithm it
+   chooses, so long as the selected message digest algorithm appears in
+   the list sent by the client.
+
+   If the server does not have an SRP verifier calculated with any of
+   the message digest algorithms suggested by the client, the server
+   must send a handshake failure alert.
+
+2.3 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication.  The definitons
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.6.
+
+
+
+Taylor                  Expires December 28, 2001               [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+2.3.1 The Client Hello Message
+
+   The user name is appended to the standard client hello message using
+   the client hello extension mechanism defined in [6].
+
+   The list of message digests the client can use is also included.
+   This list represents all the message digests the client can use for
+   the SRP calculations.
+
+2.3.2 The Server Hello Message
+
+   The message digest selected by the server (md), the generator (g),
+   the prime (N), and the salt value (s) read from the SRP password file
+   are appended to the server hello message using the client hello
+   extension mechanism defined in [6].
+
+2.3.3 The Client Key Exchange Message
+
+   The client key exchange message carries the client's public key (A),
+   which is calculated using both information known locally, and
+   information received in the server hello message.  This message MUST
+   be sent before the server key exchange message.
+
+2.3.4 The Server Key Exchange Message
+
+   The server key exchange message contains the servers public key (B).
+   The server key exchange message MUST be sent after the client key
+   exchange message.
+
+2.4 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) (defined in
+   [2]) is used as the pre-master secret.
+
+   The finished messages perform the same function as the client and
+   server evidence messages specified in [2].  If either the client or
+   the server calculate an incorrect value, the finished messages will
+   not be understood, and the connection will be dropped as specified in
+   [1].
+
+2.5 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft.  The numbers
+   have been selected based on other RFCs and Internet Drafts that were
+   current at the time of writing, so may need to be changed in future.
+
+      CipherSuite   TLS_SRP_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x5B };
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+      CipherSuite   TLS_SRP_WITH_RC4_128_SHA          = { 0x00,0x5C };
+
+      CipherSuite   TLS_SRP_WITH_IDEA_CBC_SHA         = { 0x00,0x5D };
+
+      CipherSuite   TLS_SRP_WITH_3DES_EDE_CBC_MD5     = { 0x00,0x5E };
+
+      CipherSuite   TLS_SRP_WITH_RC4_128_MD5          = { 0x00,0x5F };
+
+      CipherSuite   TLS_SRP_WITH_IDEA_CBC_MD5         = { 0x00,0x60 };
+
+
+2.6 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication.  The representation
+   language used is the same as that used in [1].
+
+   When encoding the numbers g, N, A, and B as opaque types, if the most
+   significant bit is set, an extra byte of value 0x00 (all bits
+   cleared) MUST be added as the most significant byte.  This is done as
+   a safeguard against implementations that do not assume these numbers
+   are positive.
+
+2.6.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [6].  This value is used as the extension
+   number for the extensions in both the client hello message and the
+   server hello message.  This value was chosen based on the version of
+   defined in [6] that was current at the time of writing, so may be
+   changed in future.
+
+2.6.2 Client Hello
+
+   The user name (U) and a list of message digests (srp_mds) are encoded
+   in an SRPExtension structure, and sent in an extended client hello
+   message, using an extension of type "srp".
+
+   The list of message digests represents the list of message digests
+   the client can use for the SRP calculations.
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+   enum { client, server } ClientOrServerExtension;
+
+   enum  { sha-1(0), (255) } PasswordMessageDigest;
+
+   struct {
+      select(ClientOrServerExtension) {
+         case client:
+            opaque srp_U<1..2^8-1>;
+            PasswordMessageDigest srp_mds<1..2^8-1>;
+         case server:
+            PasswordMessageDigest srp_md;
+            opaque srp_s<1..2^8-1>
+            opaque srp_N<1..2^16-1>;
+            opaque srp_g<1..2^16-1>;
+      }
+   } SRPExtension;
+
+
+2.6.3 Server Hello
+
+   The message digest selected by the server (md), the generator (g),
+   the prime (N), and the salt value (s) are encoded in an SRPExtension
+   structure, which is sent in an extended server hello message, using
+   an extension of type "srp".
+
+   The SRPParams structure is defined above.
+
+2.6.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   ephemeral public key (A) is sent in the client key exchange message,
+   encoded in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in TLS [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: ClientSRPPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } ClientSRPPublic;
+
+
+2.6.5 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   ephemeral public key (B) is sent in the server key exchange message,
+   encoded in an ServerSRPPublic structure.
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:
+            ServerSRPPublic;   /* new entry */
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_B<1..2^16-1>;
+   } ServerSRPPublic;     /* SRP parameters */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001               [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real host.  Filesystem based X.509 certificate
+   installations are vulnerable to a similar attack unless the servers
+   certificate is issued from a PKI that maintains revocation lists, and
+   the client TLS code can both contact the PKI and make use of the
+   revocation list.
+
+   Not all clients and servers will be able to interoperate once the
+   number of message digest algorithms used for creating password
+   verifiers is increased.  For example, a client may only support SHA-
+   1, whereas the verifiers on the server were created with a different
+   message digest algoritm.
+
+   Because the initial handshake messages are unprotected, an attacker
+   can modify the list of message digests in the client hello message.
+   For example, an attacker could rewrite the message to remove all but
+   the weakest message digest.  There is no way to know this has
+   happened until the finished messages are compared.
+
+   An attacker can also modify the server hello message to use a
+   different message digest than that selected by the server.  If this
+   happens, the handshake will fail after the change cipher spec
+   messages are sent, as the client and server will have calculated
+   different pre-master secret vales.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001              [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+References
+
+   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
+        1999.
+
+   [4]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
+        06 (work in progress), September 2000.
+
+   [5]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
+        tn3270e-telnet-tls-05 (work in progress), October 2000.
+
+   [6]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+        Wright, "TLS Extensions", draft-ietf-tls-extensions-00 (work in
+        progress), June 2001.
+
+
+Author's Address
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001              [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+Appendix A. Acknowledgements
+
+   The following people have contributed ideas and time to this draft:
+   Raif Naffah, Tom  Wu, Nikos Mavroyanopoulos
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001              [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                  Expires December 28, 2001              [Page 13]
+
diff --git a/doc/protocol/draft-ietf-tls-srp-02.txt b/doc/protocol/draft-ietf-tls-srp-02.txt
new file mode 100644
index 0000000000..1a438dc7c3
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-02.txt
@@ -0,0 +1,730 @@
+
+
+
+Transport Layer Security Working                               D. Taylor
+Group                                             Forge Research Pty Ltd
+Internet-Draft                                           August 21, 2002
+Expires: February 19, 2003
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-02
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 February 19, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP [2] (Secure Remote
+   Password) protocol as an authentication method for the TLS
+   [1](Transport Layer Security) protocol.
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
+   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
+   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.3.5 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
+   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
+   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
+   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+1. Introduction
+
+   At the time of writing, TLS uses public key certificiates with RSA/
+   DSA digital signatures, or Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP [3], FTP [5], or
+   TELNET [6], for example).  Given these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to safely use user names and passwords to
+   authenticate the TLS connection provides a much easier route to
+   additional security than implementing a public key infrastructure in
+   certain situations.
+
+   SRP is an authentication method that allows the use of user names and
+   passwords over unencrypted channels without revealing the password to
+   an eavesdropper.  SRP also supplies a shared secret at the end of the
+   authetication sequence that can be used to generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The SRP protocol can not be implemented using the sequence of
+   handshake messages defined in [1] due to the sequence in which the
+   SRP messages must be sent.
+
+   This document presents a new sequence of handshake messages for
+   handshakes using the SRP authentication method.
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (U) ------------------------>  |
+            |  <---------------------------- Server Hello (g, N, s)
+            |  <---------------------------- Certificate*
+       Client Key Exchange (A) ----------------->  |
+            |  <---------------------------- Server Key Exchange (B)
+            |  <---------------------------- Server Hello Done
+       change cipher spec                          |
+       Finished -------------------------------->  |
+            |                                change cipher spec
+            |  <---------------------------- Finished
+            |                                      |
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+   The identifiers given after each message name refer to the SRP
+   variables included in that message.  The variables U, g, N, s, A, and
+   B are defined in [2].
+
+   Extended client and server hello messages, as defined in [7], are
+   used to to send the initial client and server values.
+
+   The client key exchange message is sent during the sequence of server
+   messages.  This modification is required because the client must send
+   its public key (A) before it receives the servers public key (B), as
+   stated in Section 3 of [2].
+
+2.1.2 Session Re-use
+
+   The short handshake mechanism for re-using sessions for new
+   connections, and renegotiating keys for existing connections will
+
+
+
+Taylor                 Expires February 19, 2003                [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+   authentication, it MUST still include the SRP extension carrying the
+   user name (U) in the client hello message, in case the server cannot
+   or will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If a client requests an existing session and the server agrees to use
+   it (meaning the short handshake will be used), the server MAY omit
+   the SRP extension from the server hello message, as the information
+   it contains is not used in the short handshake.
+
+2.2 SRP Verifier Message Digest Selection
+
+   The cipher suites defined in this document use the SHA-1 message
+   digest with the SRP algorithm, as specified in [2].  Implementations
+   conforming to this document MUST use the SHA-1 message digest.
+
+   Future documents may define other cipher suites that use different
+   message digests, or other similar functions, with the SRP algorithm.
+
+2.3 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication.  The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.6.
+
+2.3.1 Client hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [7].
+
+2.3.2 Server hello
+
+   The the generator (g), the prime (N), and the salt value (s) read
+   from the SRP password file are appended to the server hello message
+   using the hello message extension mechanism defined in [7].
+
+2.3.3 Server certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature.  See Section 2.5 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+   Because the server's certificate is only used for generating a
+   digital signature in SRP cipher suites, the certificate sent MUST
+   contain a public key that can be used for generating digital
+   signatures.
+
+2.3.4 Client key exchange
+
+   The client key exchange message carries the client's public key (A),
+   which is calculated using both information known locally, and
+   information received in the server hello message.  This message MUST
+   be sent before the server key exchange message.
+
+2.3.5 Server key exchange
+
+   The server key exchange message contains the server's public key (B).
+   The server key exchange message MUST be sent after the client key
+   exchange message.
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+2.4 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) (defined in
+   [2]) is used as the pre-master secret.
+
+   The finished messages perform the same function as the client and
+   server evidence messages specified in [2].  If either the client or
+   the server calculate an incorrect value, the finished messages will
+   not be understood, and the connection will be dropped as specified in
+   [1].
+
+2.5 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft.  The usage of
+   AES ciphersuites is as defined in [4].
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+
+
+
+Taylor                 Expires February 19, 2003                [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that do not include a digitial signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP database.
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.6 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication.  The representation
+   language used is the same as that used in [1].
+
+   When encoding the numbers g, N, A, and B as opaque types, if the most
+   significant bit is set, an extra byte of value 0x00 (all bits
+   cleared) MUST be added as the most significant byte.  This is done as
+   a safeguard against implementations that do not assume these numbers
+   are positive.
+
+2.6.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [7].  This value is used as the extension
+   number for the extensions in both the client hello message and the
+   server hello message.
+
+2.6.2 Client Hello
+
+   The user name (U) is encoded in an SRPExtension structure, and sent
+   in an extended client hello message, using an extension of type
+   "srp".
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+   enum { client, server } ClientOrServerExtension;
+
+   struct {
+      select(ClientOrServerExtension) {
+         case client:
+            opaque srp_U<1..2^8-1>;
+         case server:
+            opaque srp_s<1..2^8-1>
+            opaque srp_N<1..2^16-1>;
+            opaque srp_g<1..2^16-1>;
+      }
+   } SRPExtension;
+
+
+2.6.3 Server Hello
+
+   The generator (g), the prime (N), and the salt value (s) are encoded
+   in an SRPExtension structure, which is sent in an extended server
+   hello message, using an extension of type "srp".
+
+2.6.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   ephemeral public key (A) is sent in the client key exchange message,
+   encoded in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in TLS [1].
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: ClientSRPPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } ClientSRPPublic;
+
+
+2.6.5 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   ephemeral public key (B) is sent in the server key exchange message,
+
+
+
+Taylor                 Expires February 19, 2003                [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+   encoded in an ServerSRPPublic structure.
+
+   The following table gives the SignatureAlgorithm value to be used for
+   each ciphersuite.
+
+      Ciphersuite                            SignatureAlgorithm
+
+      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
+
+      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
+
+      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
+
+      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
+
+      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:   /* new entry */
+            ServerSRPPublic params;
+            Signature signed_params;
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_B<1..2^16-1>;
+   } ServerSRPPublic;     /* SRP parameters */
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003                [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real host.  Filesystem based X.509 certificate
+   installations are vulnerable to a similar attack unless the server's
+   certificate is issued from a PKI that maintains revocation lists, and
+   the client TLS code can both contact the PKI and make use of the
+   revocation list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003               [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+References
+
+   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
+        1999.
+
+   [4]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+        Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [5]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
+        09 (work in progress), April 2002.
+
+   [6]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
+        tn3270e-telnet-tls-06 (work in progress), April 2002.
+
+   [7]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
+        progress), July 2002.
+
+
+Author's Address
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003               [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+Appendix A. Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003               [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication         August 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                 Expires February 19, 2003               [Page 13]
+
+
diff --git a/doc/protocol/draft-ietf-tls-srp-03.txt b/doc/protocol/draft-ietf-tls-srp-03.txt
new file mode 100644
index 0000000000..65ee1660e1
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-03.txt
@@ -0,0 +1,730 @@
+
+
+
+Transport Layer Security Working                               D. Taylor
+Group                                             Forge Research Pty Ltd
+Internet-Draft                                         September 4, 2002
+Expires: March 5, 2003
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-03
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 March 5, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP [2] (Secure Remote
+   Password) protocol as an authentication method for the TLS
+   [1](Transport Layer Security) protocol.
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
+   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
+   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.3.5 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
+   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
+   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
+   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+1. Introduction
+
+   At the time of writing, TLS uses public key certificiates with RSA/
+   DSA digital signatures, or Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP [3], FTP [5], or
+   TELNET [6], for example).  Given these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to safely use user names and passwords to
+   authenticate the TLS connection provides a much easier route to
+   additional security than implementing a public key infrastructure in
+   certain situations.
+
+   SRP is an authentication method that allows the use of user names and
+   passwords over unencrypted channels without revealing the password to
+   an eavesdropper.  SRP also supplies a shared secret at the end of the
+   authetication sequence that can be used to generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+   Changes in this version:
+
+      Changed the order of the s, N, and g parameters for the Server
+      Hello message in the handshake sequence diagram to conform to the
+      SRPExtension structure.
+
+      Removed the requirement to add leading zeros to encoded numbers
+      whose most significant bit is set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The SRP protocol can not be implemented using the sequence of
+   handshake messages defined in [1] due to the sequence in which the
+   SRP messages must be sent.
+
+   This document presents a new sequence of handshake messages for
+   handshakes using the SRP authentication method.
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (U) ------------------------>  |
+            |  <---------------------------- Server Hello (s, N, g)
+            |  <---------------------------- Certificate*
+       Client Key Exchange (A) ----------------->  |
+            |  <---------------------------- Server Key Exchange (B)
+            |  <---------------------------- Server Hello Done
+       change cipher spec                          |
+       Finished -------------------------------->  |
+            |                                change cipher spec
+            |  <---------------------------- Finished
+            |                                      |
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+   The identifiers given after each message name refer to the SRP
+   variables included in that message.  The variables U, g, N, s, A, and
+   B are defined in [2].
+
+   Extended client and server hello messages, as defined in [7], are
+   used to to send the initial client and server values.
+
+   The client key exchange message is sent during the sequence of server
+   messages.  This modification is required because the client must send
+   its public key (A) before it receives the servers public key (B), as
+   stated in Section 3 of [2].
+
+2.1.2 Session Re-use
+
+   The short handshake mechanism for re-using sessions for new
+   connections, and renegotiating keys for existing connections will
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+   authentication, it MUST still include the SRP extension carrying the
+   user name (U) in the client hello message, in case the server cannot
+   or will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If a client requests an existing session and the server agrees to use
+   it (meaning the short handshake will be used), the server MAY omit
+   the SRP extension from the server hello message, as the information
+   it contains is not used in the short handshake.
+
+2.2 SRP Verifier Message Digest Selection
+
+   The cipher suites defined in this document use the SHA-1 message
+   digest with the SRP algorithm, as specified in [2].  Implementations
+   conforming to this document MUST use the SHA-1 message digest.
+
+   Future documents may define other cipher suites that use different
+   message digests, or other similar functions, with the SRP algorithm.
+
+2.3 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication.  The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.6.
+
+2.3.1 Client hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [7].
+
+2.3.2 Server hello
+
+   The the generator (g), the prime (N), and the salt value (s) read
+   from the SRP password file are appended to the server hello message
+   using the hello message extension mechanism defined in [7].
+
+2.3.3 Server certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature.  See Section 2.5 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+   Because the server's certificate is only used for generating a
+   digital signature in SRP cipher suites, the certificate sent MUST
+   contain a public key that can be used for generating digital
+   signatures.
+
+2.3.4 Client key exchange
+
+   The client key exchange message carries the client's public key (A),
+   which is calculated using both information known locally, and
+   information received in the server hello message.  This message MUST
+   be sent before the server key exchange message.
+
+2.3.5 Server key exchange
+
+   The server key exchange message contains the server's public key (B).
+   The server key exchange message MUST be sent after the client key
+   exchange message.
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+2.4 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) (defined in
+   [2]) is used as the pre-master secret.
+
+   The finished messages perform the same function as the client and
+   server evidence messages specified in [2].  If either the client or
+   the server calculate an incorrect value, the finished messages will
+   not be understood, and the connection will be dropped as specified in
+   [1].
+
+2.5 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft.  The usage of
+   AES ciphersuites is as defined in [4].
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that do not include a digitial signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP database.
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.6 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication.  The representation
+   language used is the same as that used in [1].
+
+2.6.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [7].  This value is used as the extension
+   number for the extensions in both the client hello message and the
+   server hello message.
+
+2.6.2 Client Hello
+
+   The user name (U) is encoded in an SRPExtension structure, and sent
+   in an extended client hello message, using an extension of type
+   "srp".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+   enum { client, server } ClientOrServerExtension;
+
+   struct {
+      select(ClientOrServerExtension) {
+         case client:
+            opaque srp_U<1..2^8-1>;
+         case server:
+            opaque srp_s<1..2^8-1>
+            opaque srp_N<1..2^16-1>;
+            opaque srp_g<1..2^16-1>;
+      }
+   } SRPExtension;
+
+
+2.6.3 Server Hello
+
+   The generator (g), the prime (N), and the salt value (s) are encoded
+   in an SRPExtension structure, which is sent in an extended server
+   hello message, using an extension of type "srp".
+
+2.6.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   ephemeral public key (A) is sent in the client key exchange message,
+   encoded in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in TLS [1].
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: ClientSRPPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } ClientSRPPublic;
+
+
+2.6.5 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   ephemeral public key (B) is sent in the server key exchange message,
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+   encoded in an ServerSRPPublic structure.
+
+   The following table gives the SignatureAlgorithm value to be used for
+   each ciphersuite.
+
+      Ciphersuite                            SignatureAlgorithm
+
+      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
+
+      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
+
+      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
+
+      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
+
+      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:   /* new entry */
+            ServerSRPPublic params;
+            Signature signed_params;
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_B<1..2^16-1>;
+   } ServerSRPPublic;     /* SRP parameters */
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                  [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real host.  Filesystem based X.509 certificate
+   installations are vulnerable to a similar attack unless the server's
+   certificate is issued from a PKI that maintains revocation lists, and
+   the client TLS code can both contact the PKI and make use of the
+   revocation list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                 [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+References
+
+   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
+        1999.
+
+   [4]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+        Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [5]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
+        09 (work in progress), April 2002.
+
+   [6]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
+        tn3270e-telnet-tls-06 (work in progress), April 2002.
+
+   [7]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
+        progress), July 2002.
+
+
+Author's Address
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                 [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+Appendix A. Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                 [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication      September 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                   Expires March 5, 2003                 [Page 13]
+
+
diff --git a/doc/protocol/draft-ietf-tls-srp-04.txt b/doc/protocol/draft-ietf-tls-srp-04.txt
new file mode 100644
index 0000000000..093f9ec87f
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-04.txt
@@ -0,0 +1,730 @@
+
+
+
+Transport Layer Security Working                               D. Taylor
+Group                                             Forge Research Pty Ltd
+Internet-Draft                                         November 29, 2002
+Expires: May 30, 2003
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-04
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 May 30, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP [2] (Secure Remote
+   Password) protocol as an authentication method for the TLS
+   [1](Transport Layer Security) protocol.
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
+   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
+   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
+   2.3.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  5
+   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
+   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
+   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
+   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.6.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  7
+   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+1. Introduction
+
+   At the time of writing, TLS uses public key certificiates with RSA/
+   DSA digital signatures, or Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP [4], FTP [6], or
+   TELNET [7], for example).  Given these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to safely use user names and passwords to
+   authenticate the TLS connection provides a much easier route to
+   additional security than implementing a public key infrastructure in
+   certain situations.
+
+   SRP is an authentication method that allows the use of user names and
+   passwords over unencrypted channels without revealing the password to
+   an eavesdropper.  SRP also supplies a shared secret at the end of the
+   authetication sequence that can be used to generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The advent of SRP-6 [3] allows the SRP protocol to be implemented
+   using the standard sequence of handshake messages defined in [1].
+
+   The parameters to various messages are given in the following
+   diagram.
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (I) ------------------------>  |
+            |  <---------------------------- Server Hello
+            |  <---------------------------- Certificate*
+            |  <---------------------------- Server Key Exchange (N, g, s, B)
+            |  <---------------------------- Server Hello Done
+       Client Key Exchange (A) ----------------->  |
+       [Change cipher spec]                        |
+       Finished -------------------------------->  |
+            |                        [Change cipher spec]
+            |  <---------------------------- Finished
+            |                                      |
+       Application Data  <--------------> Application Data
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+   The identifiers given after each message name refer to the SRP
+   variables included in that message.  The variables I, N, g, s, A, and
+   B are defined in [3].
+
+   An extended client hello message, as defined in [8], is used to send
+   the client identifier (the user name).
+
+   Servers MAY add an SRP extension to the server hello message.  For
+   the cipher suites defined in this document no information is carried
+   in the SRP extension in the server hello message.  The option to add
+   an SRP extension to the server hello message is given in case it is
+   required in future.
+
+2.1.2 Session Re-use
+
+   The short handshake mechanism for re-using sessions for new
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+   connections, and renegotiating keys for existing connections will
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+   authentication, it MUST include the SRP extension carrying the user
+   name (I) in the client hello message, in case the server cannot or
+   will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If the server does agree to re-use an existing session the server
+   MUST ignore the information in the SRP extension of the client hello
+   message, except for its inclusion in the finished message hashes.
+   This is to ensure attackers cannot replace the authenticated identity
+   without supplying the proper authentication information.
+
+2.2 SRP Verifier Message Digest Selection
+
+   Implementations conforming to this document MUST use the SHA-1
+   message digest with the SRP algorithm.
+
+2.3 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication.  The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.6.
+
+2.3.1 Client hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [8].
+
+2.3.2 Server certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature.  See Section 2.5 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+   Because the server's certificate is only used for generating a
+   digital signature in SRP cipher suites, the certificate sent MUST
+   contain a public key that can be used for generating digital
+   signatures.
+
+2.3.3 Server key exchange
+
+   The server key exchange message contains the prime (N), the generator
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+   (g), and the salt value (s) read from the SRP password file based on
+   the value of (I) received in the client hello extension.  The server
+   key exchange message also contains the server's public key (B).
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+2.3.4 Client key exchange
+
+   The client key exchange message carries the client's public key (A).
+
+2.4 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) (defined in
+   [2]) is used as the pre-master secret.
+
+   The finished messages perform the same function as the client and
+   server evidence messages (M1 and M2) specified in [2].  If either the
+   client or the server calculate an incorrect value, the finished
+   messages will not be understood, and the connection will be dropped
+   as specified in [1].
+
+2.5 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft.  The usage of
+   AES ciphersuites is as defined in [5].
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that do not include a digitial signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP database.
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.6 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication.  The representation
+   language used is the same as that used in [1].
+
+2.6.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [8].  This value MUST be used as the
+   extension number for the SRP extension.
+
+2.6.2 Client Hello
+
+   The user name (I) is encoded in an SRPExtension structure, and sent
+   in an extended client hello message, using an extension of type
+   "srp".
+
+
+   enum { client, server } ClientOrServerExtension;
+
+   struct {
+      select(ClientOrServerExtension) {
+         case client:
+            opaque srp_I<1..2^8-1>;
+         case server:
+            /* empty struct */
+      }
+   } SRPExtension;
+
+
+2.6.3 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   SRP parameters are sent in the server key exchange message, encoded
+   in a ServerSRPParams structure.
+
+   If a certificate is sent to the client the server key exchange
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+   message must be signed.  The following table gives the
+   SignatureAlgorithm value to be used for each ciphersuite.
+
+      Ciphersuite                            SignatureAlgorithm
+
+      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
+
+      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
+
+      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
+
+      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
+
+      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:   /* new entry */
+            ServerSRPParams params;
+            Signature signed_params;
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_N<1..2^16-1>;
+      opaque srp_g<1..2^16-1>;
+      opaque srp_s<1..2^8-1>
+      opaque srp_B<1..2^16-1>;
+   } ServerSRPParams;     /* SRP parameters */
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+2.6.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   ephemeral public key (A) is sent in the client key exchange message,
+   encoded in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in TLS [1].
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: ClientSRPPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } ClientSRPPublic;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real host.  Filesystem based X.509 certificate
+   installations are vulnerable to a similar attack unless the server's
+   certificate is issued from a PKI that maintains revocation lists, and
+   the client TLS code can both contact the PKI and make use of the
+   revocation list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                 [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+References
+
+   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+   [3]  Wu, T., "SRP-6: Improvements and Refinements to the Secure
+        Remote Password Protocol", October 2002.
+
+   [4]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
+        1999.
+
+   [5]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+        Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [6]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
+        09 (work in progress), April 2002.
+
+   [7]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
+        tn3270e-telnet-tls-06 (work in progress), April 2002.
+
+   [8]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
+        progress), July 2002.
+
+
+Author's Address
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                 [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+Appendix A. Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+   Thanks to Tom Wu for adapting the SRP protocol so it fits the
+   standard TLS handshake message sequence.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                 [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                 [Page 13]
+
+
diff --git a/doc/protocol/draft-ietf-tls-srp-05.txt b/doc/protocol/draft-ietf-tls-srp-05.txt
new file mode 100644
index 0000000000..a90491d6d9
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-05.txt
@@ -0,0 +1,1122 @@
+
+
+
+TLS Working Group                                              D. Taylor
+Internet-Draft                                    Forge Research Pty Ltd
+Expires: December 16, 2003                                         T. Wu
+                                                           Arcot Systems
+                                                      N. Mavroyanopoulos
+                                                               T. Perrin
+                                                           June 17, 2003
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-05
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 December 16, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP [2] (Secure Remote
+   Password) protocol as an authentication method for the TLS
+   [1](Transport Layer Security) protocol.
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   Text Preparation . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3   SRP Verifier Creation  . . . . . . . . . . . . . . . . . . .  5
+   2.4   Changes to the Handshake Message Contents  . . . . . . . . .  5
+   2.4.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.4.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  6
+   2.4.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
+   2.4.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  7
+   2.5   Calculating the Pre-master Secret  . . . . . . . . . . . . .  7
+   2.6   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  7
+   2.7   New Message Structures . . . . . . . . . . . . . . . . . . .  8
+   2.7.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.7.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.7.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
+   2.7.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
+   2.8   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 10
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 12
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
+   A.    SRP Group Parameters . . . . . . . . . . . . . . . . . . . . 14
+   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
+         Intellectual Property and Copyright Statements . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+1. Introduction
+
+   At the time of writing TLS uses public key certificates, or Kerberos,
+   for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS (IMAP [4], FTP [8], or
+   TELNET [9], for example). Given that these protocols (and others like
+   them) are designed to use the user name and password method of
+   authentication, being able to safely use user names and passwords to
+   authenticate the TLS connection provides a much easier route to
+   additional security than implementing a public key infrastructure in
+   certain situations.
+
+   SRP is an authentication method that allows the use of user names and
+   passwords over unencrypted channels without revealing the password to
+   an eavesdropper. SRP also supplies a shared secret at the end of the
+   authentication sequence that can be used to generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+2. SRP Authentication in TLS
+
+2.1 Modifications to the TLS Handshake Sequence
+
+   The advent of SRP-6 [3] allows the SRP protocol to be implemented
+   using the standard sequence of handshake messages defined in [1].
+
+   The parameters to various messages are given in the following
+   diagram.
+
+2.1.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (I) ------------------------>  |
+            |  <---------------------------- Server Hello
+            |  <---------------------------- Certificate*
+            |  <---------------------------- Server Key Exchange (N, g, s, B)
+            |  <---------------------------- Server Hello Done
+       Client Key Exchange (A) ----------------->  |
+       [Change cipher spec]                        |
+       Finished -------------------------------->  |
+            |                        [Change cipher spec]
+            |  <---------------------------- Finished
+            |                                      |
+       Application Data  <--------------> Application Data
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+                                Figure 1
+
+   The identifiers given after each message name refer to the SRP
+   variables included in that message. The variables I, N, g, s, A, and
+   B are defined in [3].
+
+   An extended client hello message, as defined in [10], is used to send
+   the client identifier (the user name).
+
+2.1.2 Session Re-use
+
+   The short handshake mechanism for re-using sessions for new
+   connections, and renegotiating keys for existing connections will
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   authentication, it MUST include the SRP extension carrying the user
+   name (I) in the client hello message, in case the server cannot or
+   will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If the server does agree to re-use an existing session the server
+   MUST ignore the information in the SRP extension of the client hello
+   message, except for its inclusion in the finished message hashes.
+   This is to ensure attackers cannot replace the authenticated identity
+   without supplying the proper authentication information.
+
+2.2 Text Preparation
+
+   The user name and password strings shall be UTF-8 encoded Unicode,
+   prepared using the "SASLprep" [7] profile of "stringprep" [6].
+
+2.3 SRP Verifier Creation
+
+   The verifier is created by applying the SRP-SHA1 mechanism as
+   described in RFC 2945 [2] to the user name and password.
+
+2.4 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication. The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.7.
+
+2.4.1 Client hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [10].
+
+   The client may offer SRP ciphersuites in the hello message but omit
+   the SRP extension.  If the server would like to select an SRP
+   ciphersuite in this case, the server will return a
+   missing_srp_username alert (see Section 2.8) immediately after
+   processing the client hello message.  This alert signals the client
+   to resend the hello message, this time with the SRP extension.
+   Through this idiom, the client can advertise that it supports SRP,
+   but not have to prompt the user for his user name and password, nor
+   expose the user name in the clear, unless necessary.
+
+   If the server doesn't have a verifier for the given user name, the
+   server MAY abort the handshake with an unknown_srp_username alert
+   (see Section 2.8).  Alternatively, if the server wishes to hide the
+   fact that this user name doesn't have a verifier, the server MAY
+   simulate the protocol as if a verifier existed, but then reject the
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   client's finished message as if the password was incorrect.
+
+   To simulate the existence of an entry for each user name, the server
+   must consistently return the same salt (s) and group (g, N) values
+   for the same user name.  For example, the server could store a secret
+   "seed key" and then use hmac-sha1(seed_key, "salt" || user_name) to
+   generate the salts.  For B, the server can return a random value
+   between 2 and N-2 inclusive.  However, the server should take care to
+   simulate computation delays.  One way to do this is to generate a
+   fake verifier using the "seed key" approach, and then proceed with
+   the protocol as usual.
+
+2.4.2 Server certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature. See Section 2.6 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+   Because the server's certificate is only used for generating a
+   digital signature in SRP cipher suites, the certificate sent MUST
+   contain a public key that can be used for verifying digital
+   signatures.
+
+2.4.3 Server key exchange
+
+   The server key exchange message contains the prime (N), the generator
+   (g), and the salt value (s) read from the SRP password file based on
+   the value of (I) received in the client hello extension. The server
+   key exchange message also contains the server's public value (B).
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+   The group parameters (g, N) sent in this message MUST have N as a
+   safe prime (a prime of the form N=2q+1, where q is also prime), and g
+   as a generator % N.  The SRP group parameters in Appendix A are
+   proven to have these properties, so the client SHOULD accept any
+   parameters from this Appendix which have large enough moduli to meet
+   his security requirements.  The client MAY accept other group
+   parameters from the server, either by prior arrangement, or by
+   checking the parameters himself.
+
+   To check that N is a safe prime, the client should use some method
+   such as performing 64 iterations of the Miller-Rabin test with random
+   bases (selected from 2 to N-2) on both N and q (by performing 64
+   iterations, the probability of a false positive is no more than
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   2^-128).  To check that g is a generator % N, the client can check
+   that g^q equals -1 % N.  Performing these checks may be
+   time-consuming: after checking new parameters, the client may want to
+   add them to a known-good list.
+
+   Group parameters that are not accepted via one of the above methods
+   MUST be rejected with an illegal_parameter alert.
+
+   The client MUST abort the handshake with an illegal_parameter alert
+   if B % N is equal to zero.
+
+2.4.4 Client key exchange
+
+   The client key exchange message carries the client's public value
+   (A).
+
+   The server MUST abort the handshake with an illegal_parameter alert
+   if A % N is equal to zero, 1, or -1.
+
+2.5 Calculating the Pre-master Secret
+
+   The shared secret resulting from the SRP calculations (S) (defined in
+   [2]) is used as the pre-master secret.
+
+   The finished messages perform the same function as the client and
+   server evidence messages (M1 and M2) specified in [2]. If either the
+   client or the server calculate an incorrect value, the finished
+   messages will not be understood, and the connection will be dropped
+   as specified in [1].
+
+2.6 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft. The usage of AES
+   ciphersuites is as defined in [5].
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that do not include a digital signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP verifier.
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.7 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication. The representation
+   language used is the same as that used in [1].
+
+2.7.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [10].  This value MUST be used as the
+   extension number for the SRP extension.
+
+2.7.2 Client Hello
+
+   The "extension_data" field of the srp extension SHALL contain: opaque
+   srp_I<1..2^8-1> where srp_I is the user name.
+
+2.7.3 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   SRP parameters are sent in the server key exchange message, encoded
+   in a ServerSRPParams structure.
+
+   If a certificate is sent to the client the server key exchange
+   message must be signed. The following table gives the
+   SignatureAlgorithm value to be used for each ciphersuite.
+
+      Ciphersuite                            SignatureAlgorithm
+
+      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
+
+      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
+
+      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
+
+      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case diffie_hellman:
+            ServerDHParams params;
+            Signature signed_params;
+         case rsa:
+            ServerRSAParams params;
+            Signature signed_params;
+         case srp:   /* new entry */
+            ServerSRPParams params;
+            Signature signed_params;
+      };
+   } ServerKeyExchange;
+
+   struct {
+      opaque srp_N<1..2^16-1>;
+      opaque srp_g<1..2^16-1>;
+      opaque srp_s<1..2^8-1>
+      opaque srp_B<1..2^16-1>;
+   } ServerSRPParams;     /* SRP parameters */
+
+
+2.7.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   public value (A) is sent in the client key exchange message, encoded
+   in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in TLS [1].
+
+
+
+
+Taylor, et al.         Expires December 16, 2003                [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   struct {
+      select (KeyExchangeAlgorithm) {
+         case rsa: EncryptedPreMasterSecret;
+         case diffie_hellman: ClientDiffieHellmanPublic;
+         case srp: ClientSRPPublic;   /* new entry */
+      } exchange_keys;
+   } ClientKeyExchange;
+
+   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+   struct {
+      opaque srp_A<1..2^16-1>;
+   } ClientSRPPublic;
+
+
+2.8 Error Alerts
+
+   Two new error alerts are defined:
+
+   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
+      that receives an unknown user name.  This message is always fatal.
+
+   o  "missing_srp_username" (121) - this alert MUST be sent by a server
+      which would like to select an offered SRP ciphersuite, if the SRP
+      extension is absent from the client's hello message.  This alert
+      may be fatal or a warning.  If it is a warning, the server MUST
+      restart its handshake protocol without closing the TLS session,
+      and the client MAY either treat the warning as fatal and close the
+      session, or send the server a new hello message on the same
+      session.  By sending a new hello on the same session, the client
+      can use the idiom described in 2.3.1 without terminating a current
+      TLS session which might be protecting the handshake (and thus the
+      user name).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real server, and can also use dictionary
+   attacks to recover client passwords. Filesystem based X.509
+   certificate installations are vulnerable to a similar attack unless
+   the server's certificate is issued from a PKI that maintains
+   revocation lists, and the client TLS code can both contact the PKI
+   and make use of the revocation list.
+
+   The client's user name is sent in the clear in the Client Hello
+   message.  To avoid sending the user name in the clear, the client
+   could first open a conventional anonymous, or server-authenticated
+   session, then renegotiate an SRP-authenticated session with the
+   handshake protected by the first session.
+
+   The checks described in Section 2.4.3 and Section 2.4.4 on the
+   received values for A and B are crucial for security and MUST be
+   performed.
+
+   The private exponentials (a and b in [2]) SHOULD be at least 256 bit
+   random numbers, to give approximately 128 bits of security against
+   certain methods of calculating discrete logarithms [12].  Increasing
+   the length of these exponentials may increase security, but it also
+   increases the computation cost."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+References
+
+   [1]   Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+         1999.
+
+   [2]   Wu, T., "The SRP Authentication and Key Exchange System", RFC
+         2945, September 2000.
+
+   [3]   Wu, T., "SRP-6: Improvements and Refinements to the Secure
+         Remote Password Protocol", October 2002.
+
+   [4]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+         June 1999.
+
+   [5]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+         Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [6]   Hoffman, P. and M. Blanchet, "Preparation of Internationalized
+         Strings ("stringprep")", RFC 3454, December 2002.
+
+   [7]   Zeilenga, K., "SASLprep: Stringprep profile for user names and
+         passwords", draft-ietf-tn3270e-telnet-tls-06 (work in
+         progress), February 2003.
+
+   [8]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+         V. Wiegand, "Securing FTP with TLS",
+         draft-murray-auth-ftp-ssl-09 (work in progress), April 2002.
+
+   [9]   Boe, M. and J. Altman, "TLS-based Telnet Security",
+         draft-ietf-sasl-saslprep-00 (work in progress), April 2002.
+
+   [10]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
+         T. Wright, "TLS Extensions", draft-ietf-tls-extensions-06 (work
+         in progress), February 2003.
+
+   [11]  Kivinen, T. and M. Kojo, "More Modular Exponentiation (MODP)
+         Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
+         3526, May 2003.
+
+   [12]  van Oorschot, P. and M. Wiener, "On Diffie-Hellman Key
+         Agreement with Short Exponents", 1996.
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+Authors' Addresses
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+   Tom Wu
+   Arcot Systems
+
+   EMail: tom@arcot.com
+   URI:   http://www.arcot.com/
+
+
+   Nikos Mavroyanopoulos
+
+   EMail: nmav@gnutls.org
+   URI:   http://www.gnutls.org/
+
+
+   Trevor Perrin
+
+   EMail: trevp@trevp.net
+   URI:   http://trevp.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 13]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+Appendix A. SRP Group Parameters
+
+   The 1024, 1536, and 2048-bit groups are taken from software developed
+   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
+   subsequently proven to be prime.  The larger primes are taken from
+   [11], but generators have been calculated that are primitive roots of
+   N, unlike the generators in [11].
+
+   The 1024, 1536, and 2048-bit groups MUST be supported.
+
+   1.  1024-bit Group
+
+       The hexadecimal value is:
+
+          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
+          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
+          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
+          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
+          FD5138FE 8376435B 9FC61D2F C0EB06E3
+
+       The generator is: 2.
+
+   2.  1536-bit Group
+
+       The hexadecimal value is:
+
+          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
+          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
+          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
+          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
+          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
+          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
+          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
+
+       The generator is: 2.
+
+   3.  2048-bit Group
+
+       The hexadecimal value is:
+
+          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
+          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
+          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
+          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
+          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
+          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
+          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
+          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 14]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
+          9E4AFF73
+
+       The generator is: 2.
+
+   4.  3072-bit Group
+
+       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
+       1690314 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+   5.  4096-bit Group
+
+       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
+       240904 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 15]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
+          FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+   6.  6144-bit Group
+
+       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
+       929484 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DCC4024 FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 16]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   7.  8192-bit Group
+
+       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
+       4743158 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
+          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
+          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
+          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
+          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
+          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
+          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
+          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
+          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
+          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
+
+       The generator is: 19 (decimal).
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 17]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+Appendix B. Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 18]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 19]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.         Expires December 16, 2003               [Page 20]
+
+
diff --git a/doc/protocol/draft-ietf-tls-srp-06.txt b/doc/protocol/draft-ietf-tls-srp-06.txt
new file mode 100644
index 0000000000..38af5c08f5
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-06.txt
@@ -0,0 +1,1231 @@
+
+
+TLS Working Group                                              D. Taylor
+Internet-Draft                                    Forge Research Pty Ltd
+Expires: July 27, 2004                                             T. Wu
+                                                           Arcot Systems
+                                                      N. Mavroyanopoulos
+                                                               T. Perrin
+                                                        January 27, 2004
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-06
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 July 27, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the SRP (Secure Remote
+   Password) protocol ([SRP], [SRP-6]) as an authentication method for
+   the TLS (Transport Layer Security) protocol [TLS].
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
+   2.1   Notations and Terminology  . . . . . . . . . . . . . . . . .  4
+   2.2   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
+   2.2.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  5
+   2.2.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . . .  5
+   2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . . .  6
+   2.5   Changes to the Handshake Message Contents  . . . . . . . . .  6
+   2.5.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  6
+   2.5.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  7
+   2.5.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  7
+   2.5.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  8
+   2.6   Calculating the Pre-master Secret  . . . . . . . . . . . . .  8
+   2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  9
+   2.8   New Message Structures . . . . . . . . . . . . . . . . . . . 10
+   2.8.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . . 10
+   2.8.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 10
+   2.8.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . . 10
+   2.8.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . . 11
+   2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 12
+   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
+         Normative References . . . . . . . . . . . . . . . . . . . . 14
+         Informative References . . . . . . . . . . . . . . . . . . . 15
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
+   A.    SRP Group Parameters . . . . . . . . . . . . . . . . . . . . 16
+   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
+         Intellectual Property and Copyright Statements . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+1. Introduction
+
+   At the time of writing TLS [TLS] uses public key certificates, or
+   Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS ([IMAP] or [FTP], for
+   example). Given that these protocols (and others like them) are
+   designed to use the user name and password method of authentication,
+   being able to safely use user names and passwords to authenticate the
+   TLS connection provides a much easier route to additional security
+   than implementing a public key infrastructure in certain situations.
+
+   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
+   of user names and passwords over unencrypted channels without
+   revealing the password to an eavesdropper. SRP also supplies a shared
+   secret at the end of the authentication sequence that can be used to
+   generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+2. SRP Authentication in TLS
+
+2.1 Notations and Terminology
+
+   The version of SRP used here is sometimes referred to as "SRP-6"
+   [SRP-6].  This particular version is a slight improvement over
+   "SRP-3", which was described in [SRP] and [RFC2945].
+
+   This document uses the variable names defined in [SRP-6]:
+
+      N, g: group parameters (prime and generator)
+
+      s: salt
+
+      B, b: server's public and private values
+
+      A, a: client's public and private values
+
+      I: user name (aka "identity")
+
+      p: password
+
+      v: verifier
+
+   The | symbol indicates string concatenation, the ^ operator is the
+   exponentiation operation, and the % operator is the integer remainder
+   operation.  Conversion between integers and byte-strings assumes the
+   most-significant bytes are stored first, as per [TLS] and [RFC2945].
+
+2.2 Modifications to the TLS Handshake Sequence
+
+   The advent of [SRP-6] allows the SRP protocol to be implemented using
+   the standard sequence of handshake messages defined in [TLS].
+
+   The parameters to various messages are given in the following
+   diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+2.2.1 Message Sequence
+
+   Handshake Message Flow for SRP Authentication
+
+          Client                                 Server
+            |                                      |
+       Client Hello (I) ------------------------>  |
+            |  <---------------------------- Server Hello
+            |  <---------------------------- Certificate*
+            |  <---------------------------- Server Key Exchange (N, g, s, B)
+            |  <---------------------------- Server Hello Done
+       Client Key Exchange (A) ----------------->  |
+       [Change cipher spec]                        |
+       Finished -------------------------------->  |
+            |                        [Change cipher spec]
+            |  <---------------------------- Finished
+            |                                      |
+       Application Data  <--------------> Application Data
+
+   * Indicates an optional message which is not always sent.
+
+                                Figure 1
+
+   An extended client hello message, as defined in [TLSEXT], is used to
+   send the client identifier (the user name).
+
+2.2.2 Session Re-use
+
+   The short handshake mechanism for re-using sessions for new
+   connections, and renegotiating keys for existing connections will
+   still work with the SRP authentication mechanism and handshake.
+
+   When a client attemps to re-use a session that uses SRP
+   authentication, it MUST include the SRP extension carrying the user
+   name (I) in the client hello message, in case the server cannot or
+   will not allow re-use of the session, meaning a full handshake
+   sequence is required.
+
+   If the server does agree to re-use an existing session the server
+   MUST ignore the information in the SRP extension of the client hello
+   message, except for its inclusion in the finished message hashes.
+   This is to ensure attackers cannot replace the authenticated identity
+   without supplying the proper authentication information.
+
+2.3 Text Preparation
+
+   The user name and password strings shall be UTF-8 encoded Unicode,
+   prepared using the [SASLPrep] profile of [StringPrep].
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+2.4 SRP Verifier Creation
+
+   The verifier is calculated as described in section 3 of [RFC2945]. We
+   give the algorithm here for convenience.
+
+   The verifier (v) is computed based on the salt (s), user name (I),
+   password (p), and group parameters (N, g).  The computation uses the
+   [SHA1] hash algorithm:
+
+        x = SHA1(s | SHA1(I | ":" | p))
+        v = g^x % N
+
+2.5 Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication. The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.8.
+
+2.5.1 Client hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [TLSEXT].
+
+   The client may offer SRP ciphersuites in the hello message but omit
+   the SRP extension.  If the server would like to select an SRP
+   ciphersuite in this case, the server MAY return a
+   missing_srp_username alert (see Section 2.9) immediately after
+   processing the client hello message.  This alert signals the client
+   to resend the hello message, this time with the SRP extension.
+   Through this idiom, the client can advertise that it supports SRP,
+   but not have to prompt the user for his user name and password, nor
+   expose the user name in the clear, unless necessary.
+
+   After sending the missing_srp_username alert, the server MUST leave
+   the TLS connection open, yet reset its handshake protocol state so it
+   is prepared to receive a second client hello message.  Upon receiving
+   the missing_srp_username alert, the client MUST either send a second
+   client hello message, or send a fatal user_cancelled alert.
+
+   If the client sends a second hello message, the second hello message
+   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
+   the server MUST choose one of the SRP ciphersuites.  Both client
+   hello messages MUST be treated as handshake messages and included in
+   the hash calculations for the TLS Finished message.  The premaster
+   and master secret calculations will use the random value from the
+   second client hello message, not the first.
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+   If the server doesn't have a verifier for the given user name, the
+   server MAY abort the handshake with an unknown_srp_username alert
+   (see Section 2.9).  Alternatively, if the server wishes to hide the
+   fact that this user name doesn't have a verifier, the server MAY
+   simulate the protocol as if a verifier existed, but then reject the
+   client's finished message with a bad_record_mac alert, as if the
+   password was incorrect.
+
+   To simulate the existence of an entry for each user name, the server
+   must consistently return the same salt (s) and group (N, g) values
+   for the same user name.  For example, the server could store a secret
+   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
+   generate the salts [HMAC].  For B, the server can return a random
+   value between 1 and N-1 inclusive.  However, the server should take
+   care to simulate computation delays.  One way to do this is to
+   generate a fake verifier using the "seed key" approach, and then
+   proceed with the protocol as usual.
+
+2.5.2 Server certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature. See Section 2.7 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+   Because the server's certificate is only used for generating a
+   digital signature in SRP cipher suites, the certificate sent MUST
+   contain a public key that can be used for verifying digital
+   signatures.
+
+2.5.3 Server key exchange
+
+   The server key exchange message contains the prime (N), the generator
+   (g), and the salt value (s) read from the SRP password file based on
+   the user name (I) received in the client hello extension.
+
+   The server key exchange message also contains the server's public
+   value (B).  The server calculates this value as B = 3*v + g^b % N,
+   where b is a random number which SHOULD be at least 256 bits in
+   length.
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+   The group parameters (N, g) sent in this message MUST have N as a
+   safe prime (a prime of the form N=2q+1, where q is also prime).  The
+   integers from 1 to N-1 will form a group under multiplication % N,
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+   and g MUST be a generator of this group.  The SRP group parameters in
+   Appendix A are proven to have these properties, so the client SHOULD
+   accept any parameters from this Appendix which have large enough N
+   values to meet his security requirements.  The client MAY accept
+   other group parameters from the server, either by prior arrangement,
+   or by checking the parameters himself.
+
+   To check that N is a safe prime, the client should use some method
+   such as performing 64 iterations of the Miller-Rabin test with random
+   bases (selected from 2 to N-2) on both N and q (by performing 64
+   iterations, the probability of a false positive is no more than
+   2^-128).  To check that g is a generator of the group, the client can
+   check that 1 < g < N-1, and g^q % N equals N-1. Performing these
+   checks may be time-consuming; after checking new parameters, the
+   client may want to add them to a known-good list.
+
+   Group parameters that are not accepted via one of the above methods
+   MUST be rejected with an insufficient_security alert.
+
+   The client MUST abort the handshake with an illegal_parameter alert
+   if B % N = 0.
+
+2.5.4 Client key exchange
+
+   The client key exchange message carries the client's public value
+   (A).  The client calculates this value as A = g^a % N, where a is a
+   random number which SHOULD be at least 256 bits in length.
+
+   The server MUST abort the handshake with an illegal_parameter alert
+   if A % N = 0, 1, or N-1.
+
+2.6 Calculating the Pre-master Secret
+
+   The pre-master secret is calculated by the client as follows:
+
+        I, p = <read from user>
+        N, g, s, B = <read from server>
+        a = random()
+        A = g^a % N
+        u = SHA1(A | B)
+        x = SHA1(s | SHA1(I | ":" | p))
+        <premaster secret> = (B - (3 * g^x)) ^ (a + (u * x)) % N
+
+   The pre-master secret is calculated by the server as follows:
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+        N, g, s, v = <read from password file>
+        b = random()
+        B = 3*v + g^b % N
+        A = <read from client>
+        u = SHA1(A | B)
+        <premaster secret> = (A * v^u) ^ b % N
+
+   The finished messages perform the same function as the client and
+   server evidence messages (M1 and M2) specified in [RFC2945]. If
+   either the client or the server calculate an incorrect premaster
+   secret, the finished messages will fail to decrypt properly, and the
+   other party will return a bad_record_mac alert.
+
+   If a client application receives a bad_record_mac alert when
+   performing an SRP handshake, it should inform the user that the
+   entered user name and password are incorrect.
+
+2.7 Cipher Suite Definitions
+
+   The following cipher suites are added by this draft. The usage of AES
+   ciphersuites is as defined in [RFC3268].
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that do not include a digital signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP verifier.
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+
+
+Taylor, et al.           Expires July 27, 2004                  [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.8 New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication. The representation
+   language used is the same as that used in [TLS].
+
+2.8.1 ExtensionType
+
+   A new value, "srp(6)", has been added to the enumerated
+   ExtensionType, defined in [TLSEXT].  This value MUST be used as the
+   extension number for the SRP extension.
+
+2.8.2 Client Hello
+
+   The "extension_data" field of the srp extension SHALL contain:
+
+   opaque srp_I<1..2^8-1>
+
+   where srp_I is the user name, encoded per .
+
+2.8.3 Server Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+   SRP parameters are sent in the server key exchange message, encoded
+   in a ServerSRPParams structure.
+
+   If a certificate is sent to the client the server key exchange
+   message must be signed. The following table gives the
+   SignatureAlgorithm value to be used for each ciphersuite.
+
+      Ciphersuite                            SignatureAlgorithm
+
+      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
+
+      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
+
+      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
+
+      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
+
+      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
+
+      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
+
+
+        struct {
+           select (KeyExchangeAlgorithm) {
+              case diffie_hellman:
+                 ServerDHParams params;
+                 Signature signed_params;
+              case rsa:
+                 ServerRSAParams params;
+                 Signature signed_params;
+              case srp:   /* new entry */
+                 ServerSRPParams params;
+                 Signature signed_params;
+           };
+        } ServerKeyExchange;
+
+        struct {
+           opaque srp_N<1..2^16-1>;
+           opaque srp_g<1..2^16-1>;
+           opaque srp_s<1..2^8-1>
+           opaque srp_B<1..2^16-1>;
+        } ServerSRPParams;     /* SRP parameters */
+
+2.8.4 Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   public value (A) is sent in the client key exchange message, encoded
+   in an ClientSRPPublic structure.
+
+   An extra value, srp, has been added to the enumerated
+   KeyExchangeAlgorithm, originally defined in [TLS].
+
+        struct {
+           select (KeyExchangeAlgorithm) {
+              case rsa: EncryptedPreMasterSecret;
+              case diffie_hellman: ClientDiffieHellmanPublic;
+              case srp: ClientSRPPublic;   /* new entry */
+           } exchange_keys;
+        } ClientKeyExchange;
+
+        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+        struct {
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+           opaque srp_A<1..2^16-1>;
+        } ClientSRPPublic;
+
+2.9 Error Alerts
+
+   Two new error alerts are defined:
+
+   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
+      that receives an unknown user name.  This message is always fatal.
+
+   o  "missing_srp_username" (121) - this alert MAY be sent by a server
+      which would like to select an offered SRP ciphersuite, if the SRP
+      extension is absent from the client's hello message.  This alert
+      is always a warning. Upon receiving this alert, the client MAY
+      send a new hello message on the same connection, this time
+      including the SRP extension.  See Section 2.5.1 for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+3. Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real server, and can also use dictionary
+   attacks to recover client passwords. Filesystem based X.509
+   certificate installations are vulnerable to a similar attack unless
+   the server's certificate is issued from a PKI that maintains
+   revocation lists, and the client TLS code can both contact the PKI
+   and make use of the revocation list.
+
+   The client's user name is sent in the clear in the Client Hello
+   message.  To avoid sending the user name in the clear, the client
+   could first open a conventional anonymous, or server-authenticated
+   session, then renegotiate an SRP-authenticated session with the
+   handshake protected by the first session.
+
+   The checks described in Section 2.5.3 and Section 2.5.4 on the
+   received values for A and B are crucial for security and MUST be
+   performed.
+
+   The private values a and b SHOULD be at least 256 bit random numbers,
+   to give approximately 128 bits of security against certain methods of
+   calculating discrete logarithms.
+
+   If the client receives a missing_srp_username alert, the client
+   should be aware that unless the handshake protocol is run to
+   completion, this alert may have been inserted by an attacker.  If the
+   handshake protocol is not run to completion, the client should not
+   make any decisions, nor form any assumptions, based on receiving this
+   alert.
+
+   It is possible to choose a (user name, password) pair such that the
+   resulting verifier will also match other, related, (user name,
+   password) pairs.  Thus, anyone using verifiers should be careful not
+   to assume that only a single (user name, password) pair matches the
+   verifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 13]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Normative References
+
+   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
+              January 1999.
+
+   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
+              Remote Password Protocol", October 2002, <http://
+              srp.stanford.edu/srp6.ps>.
+
+   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
+              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
+
+   [StringPrep]
+              Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
+
+   [SASLPrep]
+              Zeilenga, K., "SASLprep: Stringprep profile for user names
+              and passwords", draft-ietf-sasl-saslprep-04 (work in
+              progress), October 2003.
+
+   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
+              RFC 2945, September 2000.
+
+   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
+              September 2000.
+
+   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+              Keyed-Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
+              Ciphersuites for Transport Layer Security (TLS)", RFC
+              3268, June 2002.
+
+   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
+              (MODP) Diffie-Hellman groups for Internet Key Exchange
+              (IKE)", RFC 3526, May 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 14]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Informative References
+
+   [IMAP]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+           June 1999.
+
+   [FTP]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E.
+           and V. Wiegand, "Securing FTP with TLS",
+           draft-murray-auth-ftp-ssl-12 (work in progress), August 2003.
+
+   [SRP]   Wu, T., "The Secure Remote Password Protocol", Proceedings of
+           the 1998 Internet Society Network and Distributed System
+           Security Symposium pp. 97-111, March 1998.
+
+
+Authors' Addresses
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+   Tom Wu
+   Arcot Systems
+
+   EMail: tom@arcot.com
+   URI:   http://www.arcot.com/
+
+
+   Nikos Mavroyanopoulos
+
+   EMail: nmav@gnutls.org
+   URI:   http://www.gnutls.org/
+
+
+   Trevor Perrin
+
+   EMail: trevp@trevp.net
+   URI:   http://trevp.net/
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 15]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Appendix A. SRP Group Parameters
+
+   The 1024, 1536, and 2048-bit groups are taken from software developed
+   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
+   subsequently proven to be prime.  The larger primes are taken from
+   [MODP], but generators have been calculated that are primitive roots
+   of N, unlike the generators in [MODP].
+
+   The 1024-bit and 1536-bit groups MUST be supported.
+
+   1.  1024-bit Group
+
+       The hexadecimal value is:
+
+          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
+          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
+          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
+          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
+          FD5138FE 8376435B 9FC61D2F C0EB06E3
+
+       The generator is: 2.
+
+   2.  1536-bit Group
+
+       The hexadecimal value is:
+
+          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
+          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
+          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
+          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
+          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
+          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
+          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
+
+       The generator is: 2.
+
+   3.  2048-bit Group
+
+       The hexadecimal value is:
+
+          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
+          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
+          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
+          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
+          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
+          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
+          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
+          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 16]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
+          9E4AFF73
+
+       The generator is: 2.
+
+   4.  3072-bit Group
+
+       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
+       1690314 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+   5.  4096-bit Group
+
+       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
+       240904 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 17]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
+          FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+   6.  6144-bit Group
+
+       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
+       929484 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DCC4024 FFFFFFFF FFFFFFFF
+
+       The generator is: 5.
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 18]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+   7.  8192-bit Group
+
+       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
+       4743158 }
+
+       Its hexadecimal value is:
+
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
+          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
+          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
+          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
+          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
+          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
+          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
+          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
+          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
+          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
+
+       The generator is: 19 (decimal).
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 19]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Appendix B. Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 20]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 21]
+
+Internet-Draft      Using SRP for TLS Authentication        January 2004
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.           Expires July 27, 2004                 [Page 22]
diff --git a/doc/protocol/draft-ietf-tls-srp-07.txt b/doc/protocol/draft-ietf-tls-srp-07.txt
new file mode 100644
index 0000000000..b6f3255194
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-srp-07.txt
@@ -0,0 +1,1179 @@
+
+
+TLS Working Group                                              D. Taylor
+Internet-Draft                                    Forge Research Pty Ltd
+Expires: December 6, 2004                                          T. Wu
+                                                           Arcot Systems
+                                                      N. Mavroyanopoulos
+                                                               T. Perrin
+                                                            June 7, 2004
+
+
+                    Using SRP for TLS Authentication
+                         draft-ietf-tls-srp-07
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 December 6, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This memo presents a technique for using the Secure Remote Password
+   protocol ([SRP], [SRP-6]) as an authentication method for the
+   Transport Layer Security protocol [TLS].
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 1]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
+     2.1   Notation and Terminology . . . . . . . . . . . . . . . . .  4
+     2.2   Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
+     2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
+     2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
+     2.5   Changes to the Handshake Message Contents  . . . . . . . .  5
+       2.5.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  5
+       2.5.2   Server Certificate . . . . . . . . . . . . . . . . . .  7
+       2.5.3   Server Key Exchange  . . . . . . . . . . . . . . . . .  7
+       2.5.4   Client Key Exchange  . . . . . . . . . . . . . . . . .  8
+     2.6   Calculating the Pre-master Secret  . . . . . . . . . . . .  8
+     2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . .  8
+     2.8   New Message Structures . . . . . . . . . . . . . . . . . .  9
+       2.8.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  9
+       2.8.2   Server Key Exchange  . . . . . . . . . . . . . . . . .  9
+       2.8.3   Client Key Exchange  . . . . . . . . . . . . . . . . . 10
+     2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
+   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   4.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
+   4.2   Informative References . . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+   A.  SRP Group Parameters . . . . . . . . . . . . . . . . . . . . . 15
+   B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 2]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+1.  Introduction
+
+   At the time of writing TLS [TLS] uses public key certificates, or
+   Kerberos, for authentication.
+
+   These authentication methods do not seem well suited to the
+   applications now being adapted to use TLS ([IMAP] or [FTP], for
+   example).  Given that these protocols are designed to use the user
+   name and password method of authentication, being able to safely use
+   user names and passwords provides an easier route to additional
+   security.
+
+   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
+   of user names and passwords over unencrypted channels without
+   revealing the password to an eavesdropper.  SRP also supplies a
+   shared secret at the end of the authentication sequence that can be
+   used to generate encryption keys.
+
+   This document describes the use of the SRP authentication method for
+   TLS.
+
+   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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 3]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+2.  SRP Authentication in TLS
+
+2.1  Notation and Terminology
+
+   The version of SRP used here is sometimes referred to as "SRP-6"
+   [SRP-6].  This version is a slight improvement over "SRP-3", which
+   was described in [SRP] and [RFC2945].
+
+   This document uses the variable names defined in [SRP-6]:
+
+      N, g: group parameters (prime and generator)
+      s: salt
+      B, b: server's public and private values
+      A, a: client's public and private values
+      I: user name (aka "identity")
+      P: password
+      v: verifier
+
+   The | symbol indicates string concatenation, the ^ operator is the
+   exponentiation operation, and the % operator is the integer remainder
+   operation.  Conversion between integers and byte-strings assumes the
+   most-significant bytes are stored first, as per [TLS] and [RFC2945].
+
+2.2  Handshake Protocol Overview
+
+   The advent of [SRP-6] allows the SRP protocol to be implemented using
+   the standard sequence of handshake messages defined in [TLS].
+
+   The parameters to various messages are given in the following
+   diagram.
+
+          Client                                 Server
+            |                                      |
+       Client Hello (I) ------------------------>  |
+            |  <---------------------------- Server Hello
+            |  <---------------------------- Certificate*
+            |  <---------------------------- Server Key Exchange (N, g, s, B)
+            |  <---------------------------- Server Hello Done
+       Client Key Exchange (A) ----------------->  |
+       [Change cipher spec]                        |
+       Finished -------------------------------->  |
+            |                        [Change cipher spec]
+            |  <---------------------------- Finished
+            |                                      |
+       Application Data  <--------------> Application Data
+
+   * Indicates an optional message which is not always sent.
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 4]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+                                Figure 1
+
+
+2.3  Text Preparation
+
+   The user name and password strings shall be UTF-8 encoded Unicode,
+   prepared using the [SASLPrep] profile of [StringPrep].
+
+2.4  SRP Verifier Creation
+
+   The verifier is calculated as described in section 3 of [RFC2945].
+   We give the algorithm here for convenience.
+
+   The verifier (v) is computed based on the salt (s), user name (I),
+   password (P), and group parameters (N, g).  The computation uses the
+   [SHA1] hash algorithm:
+
+        x = SHA1(s | SHA1(I | ":" | P))
+        v = g^x % N
+
+2.5  Changes to the Handshake Message Contents
+
+   This section describes the changes to the TLS handshake message
+   contents when SRP is being used for authentication.  The definitions
+   of the new message contents and the on-the-wire changes are given in
+   Section 2.8.
+
+2.5.1  Client Hello
+
+   The user name is appended to the standard client hello message using
+   the hello message extension mechanism defined in [TLSEXT] (see
+   Section 2.8.1).
+
+2.5.1.1  Session Resumption
+
+   When a client attempts to resume a session that uses SRP
+   authentication, the client MUST include the user name extension in
+   the client hello message, in case the server cannot or will not allow
+   session resumption, meaning a full handshake is required.
+
+   If the server does agree to resume an existing session the server
+   MUST ignore the information in the SRP extension of the client hello
+   message, except for its inclusion in the finished message hashes.
+   This is to ensure attackers cannot replace the authenticated identity
+   without supplying the proper authentication information.
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 5]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+2.5.1.2  Missing SRP Username
+
+   The client may offer SRP ciphersuites in the hello message but omit
+   the SRP extension.  If the server would like to select an SRP
+   ciphersuite in this case, the server MAY return a
+   missing_srp_username alert (see Section 2.9) immediately after
+   processing the client hello message.  This alert signals the client
+   to resend the hello message, this time with the SRP extension.  This
+   allows the client to advertise that it supports SRP, but not have to
+   prompt the user for his user name and password, nor expose the user
+   name in the clear, unless necessary.
+
+   After sending the missing_srp_username alert, the server MUST leave
+   the TLS connection open, yet reset its handshake protocol state so it
+   is prepared to receive a second client hello message.  Upon receiving
+   the missing_srp_username alert, the client MUST either send a second
+   client hello message, or send a fatal user_cancelled alert.
+
+   If the client sends a second hello message, the second hello message
+   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
+   the server MUST choose one of the SRP ciphersuites.  Both client
+   hello messages MUST be treated as handshake messages and included in
+   the hash calculations for the TLS Finished message.  The premaster
+   and master secret calculations will use the random value from the
+   second client hello message, not the first.
+
+2.5.1.3  Unknown SRP Username
+
+   If the server doesn't have a verifier for the given user name, the
+   server MAY abort the handshake with an unknown_srp_username alert
+   (see Section 2.9).  Alternatively, if the server wishes to hide the
+   fact that this user name doesn't have a verifier, the server MAY
+   simulate the protocol as if a verifier existed, but then reject the
+   client's finished message with a bad_record_mac alert, as if the
+   password was incorrect.
+
+   To simulate the existence of an entry for each user name, the server
+   must consistently return the same salt (s) and group (N, g) values
+   for the same user name.  For example, the server could store a secret
+   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
+   generate the salts [HMAC].  For B, the server can return a random
+   value between 1 and N-1 inclusive.  However, the server should take
+   care to simulate computation delays.  One way to do this is to
+   generate a fake verifier using the "seed key" approach, and then
+   proceed with the protocol as usual.
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 6]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+2.5.2  Server Certificate
+
+   The server MUST send a certificate if it agrees to an SRP cipher
+   suite that requires the server to provide additional authentication
+   in the form of a digital signature.  See Section 2.7 for details of
+   which ciphersuites defined in this document require a server
+   certificate to be sent.
+
+2.5.3  Server Key Exchange
+
+   The server key exchange message contains the prime (N), the generator
+   (g), and the salt value (s) read from the SRP password file based on
+   the user name (I) received in the client hello extension.
+
+   The server key exchange message also contains the server's public
+   value (B).  The server calculates this value as B = k*v + g^b % N,
+   where b is a random number which SHOULD be at least 256 bits in
+   length, and k = SHA1(N | g).
+
+   If the server has sent a certificate message, the server key exchange
+   message MUST be signed.
+
+   The group parameters (N, g) sent in this message MUST have N as a
+   safe prime (a prime of the form N=2q+1, where q is also prime).  The
+   integers from 1 to N-1 will form a group under multiplication % N,
+   and g MUST be a generator of this group.  The SRP group parameters in
+   Appendix A are proven to have these properties, so the client SHOULD
+   accept any parameters from this Appendix which have large enough N
+   values to meet his security requirements.  The client MAY accept
+   other group parameters from the server, either by prior arrangement,
+   or by checking the parameters himself.
+
+   To check that N is a safe prime, the client should use some method
+   such as performing 64 iterations of the Miller-Rabin test with random
+   bases (selected from 2 to N-2) on both N and q (by performing 64
+   iterations, the probability of a false positive is no more than
+   2^-128).  To check that g is a generator of the group, the client can
+   check that 1 < g < N-1, and g^q % N equals N-1.  Performing these
+   checks may be time-consuming; after checking new parameters, the
+   client may want to add them to a known-good list.
+
+   Group parameters that are not accepted via one of the above methods
+   MUST be rejected with an untrusted_srp_parameters alert (see Section
+   2.9).
+
+   The client MUST abort the handshake with an illegal_parameter alert
+   if B % N = 0.
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 7]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+2.5.4  Client Key Exchange
+
+   The client key exchange message carries the client's public value
+   (A).  The client calculates this value as A = g^a % N, where a is a
+   random number which SHOULD be at least 256 bits in length.
+
+   The server MUST abort the handshake with an illegal_parameter alert
+   if A % N = 0.
+
+2.6  Calculating the Pre-master Secret
+
+   The pre-master secret is calculated by the client as follows:
+
+        I, P = <read from user>
+        N, g, s, B = <read from server>
+        a = random()
+        A = g^a % N
+        u = SHA1(A | B)
+        k = SHA1(N | g)
+        x = SHA1(s | SHA1(I | ":" | P))
+        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
+
+   The pre-master secret is calculated by the server as follows:
+
+        N, g, s, v = <read from password file>
+        b = random()
+        k = SHA1(N | g)
+        B = k*v + g^b % N
+        A = <read from client>
+        u = SHA1(A | B)
+        <premaster secret> = (A * v^u) ^ b % N
+
+   The finished messages perform the same function as the client and
+   server evidence messages (M1 and M2) specified in [RFC2945].  If
+   either the client or the server calculate an incorrect premaster
+   secret, the finished messages will fail to decrypt properly, and the
+   other party will return a bad_record_mac alert.
+
+   If a client application receives a bad_record_mac alert when
+   performing an SRP handshake, it should inform the user that the
+   entered user name and password are incorrect.
+
+2.7  Cipher Suite Definitions
+
+   The following cipher suites are added by this draft.  The usage of
+   AES ciphersuites is as defined in [RFC3268].
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 8]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
+      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
+      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
+      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
+      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
+      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
+      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
+
+   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
+   require the server to send a certificate message containing a
+   certificate with the specified type of public key, and to sign the
+   server key exchange message using a matching private key.
+
+   Cipher suites that do not include a digital signature algorithm
+   identifier assume the server is authenticated by its possesion of the
+   SRP verifier.
+
+   Implementations conforming to this specification MUST implement the
+   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
+   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+   ciphersuites, and MAY implement the remaining ciphersuites.
+
+2.8  New Message Structures
+
+   This section shows the structure of the messages passed during a
+   handshake that uses SRP for authentication.  The representation
+   language used is the same as that used in [TLS].
+
+2.8.1  Client Hello
+
+   A new value, "srp(6)", has been added to the enumerated ExtensionType
+   defined in [TLSEXT].  This value MUST be used as the extension number
+   for the SRP extension.
+
+   The "extension_data" field of the SRP extension SHALL contain:
+
+        opaque srp_I<1..2^8-1>
+
+   where srp_I is the user name, encoded per Section 2.4.
+
+2.8.2  Server Key Exchange
+
+   A new value, "srp", has been added to the enumerated
+   KeyExchangeAlgorithm originally defined in [TLS].
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the server's
+
+
+
+Taylor, et al.          Expires December 6, 2004                [Page 9]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+   SRP parameters are sent in the server key exchange message, encoded
+   in a ServerSRPParams structure.
+
+   If a certificate is sent to the client the server key exchange
+   message must be signed.
+
+        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
+
+        struct {
+           select (KeyExchangeAlgorithm) {
+              case diffie_hellman:
+                 ServerDHParams params;
+                 Signature signed_params;
+              case rsa:
+                 ServerRSAParams params;
+                 Signature signed_params;
+              case srp:   /* new entry */
+                 ServerSRPParams params;
+                 Signature signed_params;
+           };
+        } ServerKeyExchange;
+
+        struct {
+           opaque srp_N<1..2^16-1>;
+           opaque srp_g<1..2^16-1>;
+           opaque srp_s<1..2^8-1>
+           opaque srp_B<1..2^16-1>;
+        } ServerSRPParams;     /* SRP parameters */
+
+2.8.3  Client Key Exchange
+
+   When the value of KeyExchangeAlgorithm is set to "srp", the client's
+   public value (A) is sent in the client key exchange message, encoded
+   in a ClientSRPPublic structure.
+
+        struct {
+           select (KeyExchangeAlgorithm) {
+              case rsa: EncryptedPreMasterSecret;
+              case diffie_hellman: ClientDiffieHellmanPublic;
+              case srp: ClientSRPPublic;   /* new entry */
+           } exchange_keys;
+        } ClientKeyExchange;
+
+        struct {
+           opaque srp_A<1..2^16-1>;
+        } ClientSRPPublic;
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 10]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+2.9  Error Alerts
+
+   Three new error alerts are defined:
+
+   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
+      that receives an unknown user name.  This alert is always fatal.
+      See Section 2.5.1.3 for details.
+   o  "missing_srp_username" (121) - this alert MAY be sent by a server
+      that would like to select an offered SRP ciphersuite, if the SRP
+      extension is absent from the client's hello message.  This alert
+      is always a warning.  Upon receiving this alert, the client MAY
+      send a new hello message on the same connection, this time
+      including the SRP extension.  See Section 2.5.1.2 for details.
+   o  "untrusted_srp_parameters" (122) - this alert MUST be sent by a
+      client that receives unknown or untrusted (N, g) values.  This
+      alert is always fatal.  See Section 2.5.3 for details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 11]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+3.  Security Considerations
+
+   If an attacker is able to steal the SRP verifier file, the attacker
+   can masquerade as the real server, and can also use dictionary
+   attacks to recover client passwords.
+
+   An attacker could repeatedly contact an SRP server and try to guess a
+   legitimate user's password.  Servers SHOULD take steps to prevent
+   this, such as limiting the rate of authentication attempts from a
+   particular IP address, or against a particular user account, or
+   locking the user account once a threshold of failed attempts is
+   reached.
+
+   The client's user name is sent in the clear in the Client Hello
+   message.  To avoid sending the user name in the clear, the client
+   could first open a conventional anonymous, or server-authenticated
+   connection, then renegotiate an SRP-authenticated connection with the
+   handshake protected by the first connection.
+
+   The checks described in Section 2.5.3 and Section 2.5.4 on the
+   received values for A and B are crucial for security and MUST be
+   performed.
+
+   The private values a and b SHOULD be at least 256 bit random numbers,
+   to give approximately 128 bits of security against certain methods of
+   calculating discrete logarithms.
+
+   If the client receives a missing_srp_username alert, the client
+   should be aware that unless the handshake protocol is run to
+   completion, this alert may have been inserted by an attacker.  If the
+   handshake protocol is not run to completion, the client should not
+   make any decisions, nor form any assumptions, based on receiving this
+   alert.
+
+   It is possible to choose a (user name, password) pair such that the
+   resulting verifier will also match other, related, (user name,
+   password) pairs.  Thus, anyone using verifiers should be careful not
+   to assume that only a single (user name, password) pair matches the
+   verifier.
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 12]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+4.  References
+
+4.1  Normative References
+
+   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
+              January 1999.
+
+   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
+              Remote Password Protocol", October 2002,
+              <http://srp.stanford.edu/srp6.ps>.
+
+   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
+              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
+
+   [StringPrep]
+              Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
+
+   [SASLPrep]
+              Zeilenga, K., "SASLprep: Stringprep profile for user names
+              and passwords", draft-ietf-sasl-saslprep-09 (work in
+              progress), April 2004.
+
+   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
+              RFC 2945, September 2000.
+
+   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
+              September 2000.
+
+   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+              Keyed-Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
+              Ciphersuites for Transport Layer Security (TLS)", RFC
+              3268, June 2002.
+
+   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
+              (MODP) Diffie-Hellman groups for Internet Key Exchange
+              (IKE)", RFC 3526, May 2003.
+
+4.2  Informative References
+
+   [IMAP]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+           June 1999.
+
+   [FTP]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E.
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 13]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+           and V. Wiegand, "Securing FTP with TLS",
+           draft-murray-auth-ftp-ssl-13 (work in progress), March 2004.
+
+   [SRP]   Wu, T., "The Secure Remote Password Protocol", Proceedings of
+           the 1998 Internet Society Network and Distributed System
+           Security Symposium pp. 97-111, March 1998.
+
+
+Authors' Addresses
+
+   David Taylor
+   Forge Research Pty Ltd
+
+   EMail: DavidTaylor@forge.com.au
+   URI:   http://www.forge.com.au/
+
+
+   Tom Wu
+   Arcot Systems
+
+   EMail: tom@arcot.com
+   URI:   http://www.arcot.com/
+
+
+   Nikos Mavroyanopoulos
+
+   EMail: nmav@gnutls.org
+   URI:   http://www.gnutls.org/
+
+
+   Trevor Perrin
+
+   EMail: trevp@trevp.net
+   URI:   http://trevp.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 14]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+Appendix A.  SRP Group Parameters
+
+   The 1024, 1536, and 2048-bit groups are taken from software developed
+   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
+   subsequently proven to be prime.  The larger primes are taken from
+   [MODP], but generators have been calculated that are primitive roots
+   of N, unlike the generators in [MODP].
+
+   The 1024-bit and 1536-bit groups MUST be supported.
+
+   1.  1024-bit Group
+
+       The hexadecimal value is:
+          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
+          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
+          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
+          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
+          FD5138FE 8376435B 9FC61D2F C0EB06E3
+       The generator is: 2.
+   2.  1536-bit Group
+
+       The hexadecimal value is:
+          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
+          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
+          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
+          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
+          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
+          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
+          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
+       The generator is: 2.
+   3.  2048-bit Group
+
+       The hexadecimal value is:
+          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
+          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
+          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
+          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
+          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
+          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
+          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
+          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
+          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
+          9E4AFF73
+       The generator is: 2.
+   4.  3072-bit Group
+
+       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
+       1690314 }
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 15]
+
+
+       Its hexadecimal value is:
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
+       The generator is: 5.
+   5.  4096-bit Group
+
+       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
+       240904 }
+
+       Its hexadecimal value is:
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
+          FFFFFFFF FFFFFFFF
+       The generator is: 5.
+   6.  6144-bit Group
+
+       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
+       929484 }
+
+       Its hexadecimal value is:
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 16]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DCC4024 FFFFFFFF FFFFFFFF
+       The generator is: 5.
+   7.  8192-bit Group
+
+       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
+       4743158 }
+
+       Its hexadecimal value is:
+          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
+          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
+          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
+          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
+          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
+          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
+          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
+          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
+          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
+          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
+          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
+          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
+          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
+          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 17]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
+          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
+          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
+          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
+          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
+          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
+          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
+          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
+          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
+          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
+          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
+          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
+          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
+          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
+          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
+          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
+          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
+          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
+          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
+          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
+          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
+          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
+       The generator is: 19 (decimal).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 18]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+Appendix B.  Acknowledgements
+
+   Thanks to all on the IETF tls mailing list for ideas and analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 19]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 20]
+
+Internet-Draft      Using SRP for TLS Authentication           June 2004
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taylor, et al.          Expires December 6, 2004               [Page 21]
+
+
+

+