Network Working Group D. Taylor Request for Comments: 5054 Independent Category: Informational T. Wu Cisco N. Mavrogiannopoulos T. Perrin Independent November 2007
Using the Secure Remote Password (SRP) Protocol for TLS Authentication
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol.
Taylor, et al. Informational [Page 1]
RFC 5054 Using SRP for TLS Authentication November 2007
At the time of writing TLS [TLS] uses public key certificates, pre- shared keys, or Kerberos for authentication.
These authentication methods do not seem well suited to certain applications now being adapted to use TLS ([IMAP], for example). Given that many 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 [REQ].
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 [SRP-RFC]. For convenience, this document and [SRP-RFC] include the details necessary to implement SRP-6; [SRP-6] is cited for informative purposes only.
Taylor, et al. Informational [Page 3]
RFC 5054 Using SRP for TLS Authentication November 2007
This document uses the variable names defined in [SRP-6]:
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 [SRP-RFC]. In the following text, if a conversion from integer to byte-string is implicit, the most significant byte in the resultant byte-string MUST be non-zero. If a conversion is explicitly specified with the operator PAD(), the integer will first be implicitly converted, then the resultant byte-string will be left-padded with zeros (if necessary) until its length equals the implicitly-converted length of N.
The verifier is calculated as described in Section 3 of [SRP-RFC]. 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:
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.
Taylor, et al. Informational [Page 5]
RFC 5054 Using SRP for TLS Authentication November 2007
The user name is appended to the standard client hello message using the extension mechanism defined in [TLSEXT] (see Section 2.8.1). This user name extension is henceforth called the "SRP extension". The following subsections give details of its use.
When a client attempts to resume a session that uses SRP authentication, the client MUST include the SRP 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 that attackers cannot replace the authenticated identity without supplying the proper authentication information.
The client may offer SRP cipher suites in the hello message but omit the SRP extension. If the server would like to select an SRP cipher suite in this case, the server SHOULD return a fatal "unknown_psk_identity" alert (see Section 2.9) immediately after processing the client hello message.
A client receiving this alert MAY choose to reconnect and 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.
If the server doesn't have a verifier for the user name in the SRP extension, the server MAY abort the handshake with an "unknown_psk_identity" 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
Taylor, et al. Informational [Page 6]
RFC 5054 Using SRP for TLS Authentication November 2007
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.
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 cipher suites defined in this document require a server certificate to be sent.
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 that SHOULD be at least 256 bits in length and k = SHA1(N | PAD(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. In addition, the group parameters MUST NOT be specially chosen to allow efficient computation of discrete logarithms.
The SRP group parameters in Appendix A satisfy the above requirements, so the client SHOULD accept any parameters from this appendix that have large enough N values to meet her security requirements.
The client MAY accept other group parameters from the server, if the client has reason to believe that these parameters satisfy the above requirements, and the parameters have large enough N values. For example, if the parameters transmitted by the server match parameters on a "known-good" list, the client may choose to accept them. See Section 3 for additional security considerations relevant to the acceptance of the group parameters.
Taylor, et al. Informational [Page 7]
RFC 5054 Using SRP for TLS Authentication November 2007
Group parameters that are not accepted via one of the above methods MUST be rejected with an "insufficient_security" alert (see Section 2.9).
The client MUST abort the handshake with an "illegal_parameter" alert if B % N = 0.
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 that SHOULD be at least 256 bits in length.
The server MUST abort the handshake with an "illegal_parameter" alert if A % N = 0.
The premaster 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(PAD(A) | PAD(B)) k = SHA1(N | PAD(g)) x = SHA1(s | SHA1(I | ":" | P)) <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
The premaster secret is calculated by the server as follows:
N, g, s, v = <read from password file> b = random() k = SHA1(N | PAD(g)) B = k*v + g^b % N A = <read from client> u = SHA1(PAD(A) | PAD(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 [SRP-RFC]. If either the client or the server calculates 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.
Taylor, et al. Informational [Page 8]
RFC 5054 Using SRP for TLS Authentication November 2007
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 that the server is authenticated by its possession of the SRP verifier.
Implementations conforming to this specification MUST implement the TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA cipher suite, SHOULD implement the TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA cipher suites, and MAY implement the remaining cipher suites.
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].
Taylor, et al. Informational [Page 9]
RFC 5054 Using SRP for TLS Authentication November 2007
A new extension "srp", with value 12, 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.3.
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 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.
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;
o "unknown_psk_identity" (115) - this alert MAY be sent by a server that would like to select an offered SRP cipher suite, if the SRP extension is absent from the client's hello message. This alert is always fatal. See Section 2.5.1.2 for details.
o "unknown_psk_identity" (115) - 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 "insufficient_security" (71) - 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.
o "illegal_parameter" (47) - this alert MUST be sent by a client or server that receives a key exchange message with A % N = 0 or B % N = 0. This alert is always fatal. See Section 2.5.3 and Section 2.5.4 and for details.
The "insufficient_security" and "illegal_parameter" alerts are defined in [TLS]. The "unknown_psk_identity" alert is defined in [PSK].
Taylor, et al. Informational [Page 11]
RFC 5054 Using SRP for TLS Authentication November 2007
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. See [TLS], Section D.1, for advice on choosing cryptographically secure random numbers.
An attacker who could calculate discrete logarithms % N could compromise user passwords, and could also compromise the confidentiality and integrity of TLS sessions. Clients MUST ensure that the received parameter N is large enough to make calculating discrete logarithms computationally infeasible.
An attacker may try to send a prime value N that is large enough to be secure, but that has a special form for which the attacker can more easily compute discrete logarithms (e.g., using the algorithm discussed in [TRAPDOOR]). If the client executes the protocol using such a prime, the client's password could be compromised. Because of the difficulty of checking for such primes in real time, clients SHOULD only accept group parameters that come from a trusted source, such as those listed in Appendix A, or parameters configured locally by a trusted administrator.
If an attacker learns a user's SRP verifier (e.g., by gaining access to a server's password file), the attacker can masquerade as the real server to that user, and can also attempt a dictionary attack to recover that user's password.
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 name.
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.
Taylor, et al. Informational [Page 12]
RFC 5054 Using SRP for TLS Authentication November 2007
If the client receives an "unknown_psk_identity" alert in response to a client hello, this alert may have been inserted by an attacker. The client should be careful about making any decisions, or forming any conclusions, 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.
This protocol uses SHA-1 to derive several values:
o u prevents an attacker who learns a user's verifier from being able to authenticate as that user (see [SRP-6]).
o k prevents an attacker who can select group parameters from being able to launch a 2-for-1 guessing attack (see [SRP-6]).
o x contains the user's password mixed with a salt.
Cryptanalytic attacks against SHA-1 that only affect its collision- resistance do not compromise these uses. If attacks against SHA-1 are discovered that do compromise these uses, new cipher suites should be specified to use a different hash algorithm.
In this situation, clients could send a Client Hello message containing new and/or old SRP cipher suites along with a single SRP extension. The server could then select the appropriate cipher suite based on the type of verifier it has stored for this user.
[IMAP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the Secure Remote Password Protocol", Submission to IEEE P1363.2 working group, October 2002, <http://grouper.ieee.org/groups/1363/>.
[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.
[TRAPDOOR] Gordon, D., "Designing and Detecting Trapdoors for Discrete Log Cryptosystems", Springer-Verlag Advances in Cryptology - Crypto '92, pp. 66-75, 1993.
Taylor, et al. Informational [Page 15]
RFC 5054 Using SRP for TLS Authentication November 2007
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.
RFC 5054 Using SRP for TLS Authentication November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.