diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-00.txt | 504 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-01.txt | 728 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-02.txt | 730 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-03.txt | 730 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-04.txt | 730 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-05.txt | 1122 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-06.txt | 1231 | ||||
-rw-r--r-- | doc/protocol/draft-ietf-tls-srp-07.txt | 1179 |
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] + + +
+
|