| blob | 86e391cf77839a88075d37d56a2f02f2480cb945 |
7 Network Working Group D. Taylor
8 Request for Comments: 5054 Independent
9 Category: Informational T. Wu
10 Cisco
11 N. Mavrogiannopoulos
12 T. Perrin
13 Independent
14 November 2007
17 Using the Secure Remote Password (SRP) Protocol for TLS Authentication
19 Status of This Memo
21 This memo provides information for the Internet community. It does
22 not specify an Internet standard of any kind. Distribution of this
23 memo is unlimited.
25 Abstract
27 This memo presents a technique for using the Secure Remote Password
28 protocol as an authentication method for the Transport Layer Security
29 protocol.
58 Taylor, et al. Informational [Page 1]
59 \f
60 RFC 5054 Using SRP for TLS Authentication November 2007
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . . 3
67 2.1. Notation and Terminology . . . . . . . . . . . . . . . . . 3
68 2.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 4
69 2.3. Text Preparation . . . . . . . . . . . . . . . . . . . . . 5
70 2.4. SRP Verifier Creation . . . . . . . . . . . . . . . . . . 5
71 2.5. Changes to the Handshake Message Contents . . . . . . . . 5
72 2.5.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 6
73 2.5.2. Server Certificate . . . . . . . . . . . . . . . . . . 7
74 2.5.3. Server Key Exchange . . . . . . . . . . . . . . . . . 7
75 2.5.4. Client Key Exchange . . . . . . . . . . . . . . . . . 8
76 2.6. Calculating the Premaster Secret . . . . . . . . . . . . . 8
77 2.7. Ciphersuite Definitions . . . . . . . . . . . . . . . . . 9
78 2.8. New Message Structures . . . . . . . . . . . . . . . . . . 9
79 2.8.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 10
80 2.8.2. Server Key Exchange . . . . . . . . . . . . . . . . . 10
81 2.8.3. Client Key Exchange . . . . . . . . . . . . . . . . . 11
82 2.9. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
83 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
84 3.1. General Considerations for Implementors . . . . . . . . . 12
85 3.2. Accepting Group Parameters . . . . . . . . . . . . . . . . 12
86 3.3. Protocol Characteristics . . . . . . . . . . . . . . . . . 12
87 3.4. Hash Function Considerations . . . . . . . . . . . . . . . 13
88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
89 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
90 5.1. Normative References . . . . . . . . . . . . . . . . . . . 14
91 5.2. Informative References . . . . . . . . . . . . . . . . . . 15
92 Appendix A. SRP Group Parameters . . . . . . . . . . . . . . . . 16
93 Appendix B. SRP Test Vectors . . . . . . . . . . . . . . . . . . 21
94 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 22
114 Taylor, et al. Informational [Page 2]
115 \f
116 RFC 5054 Using SRP for TLS Authentication November 2007
119 1. Introduction
121 At the time of writing TLS [TLS] uses public key certificates, pre-
122 shared keys, or Kerberos for authentication.
124 These authentication methods do not seem well suited to certain
125 applications now being adapted to use TLS ([IMAP], for example).
126 Given that many protocols are designed to use the user name and
127 password method of authentication, being able to safely use user
128 names and passwords provides an easier route to additional security.
130 SRP ([SRP], [SRP-6]) is an authentication method that allows the use
131 of user names and passwords over unencrypted channels without
132 revealing the password to an eavesdropper. SRP also supplies a
133 shared secret at the end of the authentication sequence that can be
134 used to generate encryption keys.
136 This document describes the use of the SRP authentication method for
137 TLS.
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141 document are to be interpreted as described in RFC 2119 [REQ].
143 2. SRP Authentication in TLS
145 2.1. Notation and Terminology
147 The version of SRP used here is sometimes referred to as "SRP-6"
148 [SRP-6]. This version is a slight improvement over "SRP-3", which
149 was described in [SRP] and [SRP-RFC]. For convenience, this document
150 and [SRP-RFC] include the details necessary to implement SRP-6;
151 [SRP-6] is cited for informative purposes only.
170 Taylor, et al. Informational [Page 3]
171 \f
172 RFC 5054 Using SRP for TLS Authentication November 2007
175 This document uses the variable names defined in [SRP-6]:
177 N, g: group parameters (prime and generator)
179 s: salt
181 B, b: server's public and private values
183 A, a: client's public and private values
185 I: user name (aka "identity")
187 P: password
189 v: verifier
191 k: SRP-6 multiplier
193 The | symbol indicates string concatenation, the ^ operator is the
194 exponentiation operation, and the % operator is the integer remainder
195 operation.
197 Conversion between integers and byte-strings assumes the most
198 significant bytes are stored first, as per [TLS] and [SRP-RFC]. In
199 the following text, if a conversion from integer to byte-string is
200 implicit, the most significant byte in the resultant byte-string MUST
201 be non-zero. If a conversion is explicitly specified with the
202 operator PAD(), the integer will first be implicitly converted, then
203 the resultant byte-string will be left-padded with zeros (if
204 necessary) until its length equals the implicitly-converted length of
205 N.
207 2.2. Handshake Protocol Overview
209 The advent of [SRP-6] allows the SRP protocol to be implemented using
210 the standard sequence of handshake messages defined in [TLS].
212 The parameters to various messages are given in the following
213 diagram.
226 Taylor, et al. Informational [Page 4]
227 \f
228 RFC 5054 Using SRP for TLS Authentication November 2007
231 Client Server
233 Client Hello (I) -------->
234 Server Hello
235 Certificate*
236 Server Key Exchange (N, g, s, B)
237 <-------- Server Hello Done
238 Client Key Exchange (A) -------->
239 [Change cipher spec]
240 Finished -------->
241 [Change cipher spec]
242 <-------- Finished
244 Application Data <-------> Application Data
246 * Indicates an optional message that is not always sent.
248 Figure 1
250 2.3. Text Preparation
252 The user name and password strings SHALL be UTF-8 encoded Unicode,
253 prepared using the [SASLPREP] profile of [STRINGPREP].
255 2.4. SRP Verifier Creation
257 The verifier is calculated as described in Section 3 of [SRP-RFC].
258 We give the algorithm here for convenience.
260 The verifier (v) is computed based on the salt (s), user name (I),
261 password (P), and group parameters (N, g). The computation uses the
262 [SHA1] hash algorithm:
264 x = SHA1(s | SHA1(I | ":" | P))
265 v = g^x % N
267 2.5. Changes to the Handshake Message Contents
269 This section describes the changes to the TLS handshake message
270 contents when SRP is being used for authentication. The definitions
271 of the new message contents and the on-the-wire changes are given in
272 Section 2.8.
282 Taylor, et al. Informational [Page 5]
283 \f
284 RFC 5054 Using SRP for TLS Authentication November 2007
287 2.5.1. Client Hello
289 The user name is appended to the standard client hello message using
290 the extension mechanism defined in [TLSEXT] (see Section 2.8.1).
291 This user name extension is henceforth called the "SRP extension".
292 The following subsections give details of its use.
294 2.5.1.1. Session Resumption
296 When a client attempts to resume a session that uses SRP
297 authentication, the client MUST include the SRP extension in the
298 client hello message, in case the server cannot or will not allow
299 session resumption, meaning a full handshake is required.
301 If the server does agree to resume an existing session, the server
302 MUST ignore the information in the SRP extension of the client hello
303 message, except for its inclusion in the finished message hashes.
304 This is to ensure that attackers cannot replace the authenticated
305 identity without supplying the proper authentication information.
307 2.5.1.2. Missing SRP Extension
309 The client may offer SRP cipher suites in the hello message but omit
310 the SRP extension. If the server would like to select an SRP cipher
311 suite in this case, the server SHOULD return a fatal
312 "unknown_psk_identity" alert (see Section 2.9) immediately after
313 processing the client hello message.
315 A client receiving this alert MAY choose to reconnect and resend the
316 hello message, this time with the SRP extension. This allows the
317 client to advertise that it supports SRP, but not have to prompt the
318 user for his user name and password, nor expose the user name in the
319 clear, unless necessary.
321 2.5.1.3. Unknown SRP User Name
323 If the server doesn't have a verifier for the user name in the SRP
324 extension, the server MAY abort the handshake with an
325 "unknown_psk_identity" alert (see Section 2.9). Alternatively, if
326 the server wishes to hide the fact that this user name doesn't have a
327 verifier, the server MAY simulate the protocol as if a verifier
328 existed, but then reject the client's finished message with a
329 "bad_record_mac" alert, as if the password was incorrect.
331 To simulate the existence of an entry for each user name, the server
332 must consistently return the same salt (s) and group (N, g) values
333 for the same user name. For example, the server could store a secret
334 "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
338 Taylor, et al. Informational [Page 6]
339 \f
340 RFC 5054 Using SRP for TLS Authentication November 2007
343 generate the salts [HMAC]. For B, the server can return a random
344 value between 1 and N-1 inclusive. However, the server should take
345 care to simulate computation delays. One way to do this is to
346 generate a fake verifier using the "seed key" approach, and then
347 proceed with the protocol as usual.
349 2.5.2. Server Certificate
351 The server MUST send a certificate if it agrees to an SRP cipher
352 suite that requires the server to provide additional authentication
353 in the form of a digital signature. See Section 2.7 for details of
354 which cipher suites defined in this document require a server
355 certificate to be sent.
357 2.5.3. Server Key Exchange
359 The server key exchange message contains the prime (N), the generator
360 (g), and the salt value (s) read from the SRP password file based on
361 the user name (I) received in the client hello extension.
363 The server key exchange message also contains the server's public
364 value (B). The server calculates this value as B = k*v + g^b % N,
365 where b is a random number that SHOULD be at least 256 bits in length
366 and k = SHA1(N | PAD(g)).
368 If the server has sent a certificate message, the server key exchange
369 message MUST be signed.
371 The group parameters (N, g) sent in this message MUST have N as a
372 safe prime (a prime of the form N=2q+1, where q is also prime). The
373 integers from 1 to N-1 will form a group under multiplication % N,
374 and g MUST be a generator of this group. In addition, the group
375 parameters MUST NOT be specially chosen to allow efficient
376 computation of discrete logarithms.
378 The SRP group parameters in Appendix A satisfy the above
379 requirements, so the client SHOULD accept any parameters from this
380 appendix that have large enough N values to meet her security
381 requirements.
383 The client MAY accept other group parameters from the server, if the
384 client has reason to believe that these parameters satisfy the above
385 requirements, and the parameters have large enough N values. For
386 example, if the parameters transmitted by the server match parameters
387 on a "known-good" list, the client may choose to accept them. See
388 Section 3 for additional security considerations relevant to the
389 acceptance of the group parameters.
394 Taylor, et al. Informational [Page 7]
395 \f
396 RFC 5054 Using SRP for TLS Authentication November 2007
399 Group parameters that are not accepted via one of the above methods
400 MUST be rejected with an "insufficient_security" alert (see
401 Section 2.9).
403 The client MUST abort the handshake with an "illegal_parameter" alert
404 if B % N = 0.
406 2.5.4. Client Key Exchange
408 The client key exchange message carries the client's public value
409 (A). The client calculates this value as A = g^a % N, where a is a
410 random number that SHOULD be at least 256 bits in length.
412 The server MUST abort the handshake with an "illegal_parameter" alert
413 if A % N = 0.
415 2.6. Calculating the Premaster Secret
417 The premaster secret is calculated by the client as follows:
419 I, P = <read from user>
420 N, g, s, B = <read from server>
421 a = random()
422 A = g^a % N
423 u = SHA1(PAD(A) | PAD(B))
424 k = SHA1(N | PAD(g))
425 x = SHA1(s | SHA1(I | ":" | P))
426 <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
428 The premaster secret is calculated by the server as follows:
430 N, g, s, v = <read from password file>
431 b = random()
432 k = SHA1(N | PAD(g))
433 B = k*v + g^b % N
434 A = <read from client>
435 u = SHA1(PAD(A) | PAD(B))
436 <premaster secret> = (A * v^u) ^ b % N
438 The finished messages perform the same function as the client and
439 server evidence messages (M1 and M2) specified in [SRP-RFC]. If
440 either the client or the server calculates an incorrect premaster
441 secret, the finished messages will fail to decrypt properly, and the
442 other party will return a "bad_record_mac" alert.
444 If a client application receives a "bad_record_mac" alert when
445 performing an SRP handshake, it should inform the user that the
446 entered user name and password are incorrect.
450 Taylor, et al. Informational [Page 8]
451 \f
452 RFC 5054 Using SRP for TLS Authentication November 2007
455 2.7. Ciphersuite Definitions
457 The following cipher suites are added by this document. The usage of
458 Advanced Encryption Standard (AES) cipher suites is as defined in
459 [AESCIPH].
461 CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
463 CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
465 CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
467 CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
469 CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
471 CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
473 CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
475 CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
477 CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
479 Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
480 require the server to send a certificate message containing a
481 certificate with the specified type of public key, and to sign the
482 server key exchange message using a matching private key.
484 Cipher suites that do not include a digital signature algorithm
485 identifier assume that the server is authenticated by its possession
486 of the SRP verifier.
488 Implementations conforming to this specification MUST implement the
489 TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA cipher suite, SHOULD implement the
490 TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
491 cipher suites, and MAY implement the remaining cipher suites.
493 2.8. New Message Structures
495 This section shows the structure of the messages passed during a
496 handshake that uses SRP for authentication. The representation
497 language used is the same as that used in [TLS].
506 Taylor, et al. Informational [Page 9]
507 \f
508 RFC 5054 Using SRP for TLS Authentication November 2007
511 2.8.1. Client Hello
513 A new extension "srp", with value 12, has been added to the
514 enumerated ExtensionType defined in [TLSEXT]. This value MUST be
515 used as the extension number for the SRP extension.
517 The "extension_data" field of the SRP extension SHALL contain:
519 opaque srp_I<1..2^8-1>;
521 where srp_I is the user name, encoded per Section 2.3.
523 2.8.2. Server Key Exchange
525 A new value, "srp", has been added to the enumerated
526 KeyExchangeAlgorithm originally defined in [TLS].
528 When the value of KeyExchangeAlgorithm is set to "srp", the server's
529 SRP parameters are sent in the server key exchange message, encoded
530 in a ServerSRPParams structure.
532 If a certificate is sent to the client, the server key exchange
533 message must be signed.
535 enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
537 struct {
538 select (KeyExchangeAlgorithm) {
539 case diffie_hellman:
540 ServerDHParams params;
541 Signature signed_params;
542 case rsa:
543 ServerRSAParams params;
544 Signature signed_params;
545 case srp: /* new entry */
546 ServerSRPParams params;
547 Signature signed_params;
548 };
549 } ServerKeyExchange;
551 struct {
552 opaque srp_N<1..2^16-1>;
553 opaque srp_g<1..2^16-1>;
554 opaque srp_s<1..2^8-1>;
555 opaque srp_B<1..2^16-1>;
556 } ServerSRPParams; /* SRP parameters */
562 Taylor, et al. Informational [Page 10]
563 \f
564 RFC 5054 Using SRP for TLS Authentication November 2007
567 2.8.3. Client Key Exchange
569 When the value of KeyExchangeAlgorithm is set to "srp", the client's
570 public value (A) is sent in the client key exchange message, encoded
571 in a ClientSRPPublic structure.
573 struct {
574 select (KeyExchangeAlgorithm) {
575 case rsa: EncryptedPreMasterSecret;
576 case diffie_hellman: ClientDiffieHellmanPublic;
577 case srp: ClientSRPPublic; /* new entry */
578 } exchange_keys;
579 } ClientKeyExchange;
581 struct {
582 opaque srp_A<1..2^16-1>;
583 } ClientSRPPublic;
585 2.9. Error Alerts
587 This document introduces four new uses of alerts:
589 o "unknown_psk_identity" (115) - this alert MAY be sent by a server
590 that would like to select an offered SRP cipher suite, if the SRP
591 extension is absent from the client's hello message. This alert
592 is always fatal. See Section 2.5.1.2 for details.
594 o "unknown_psk_identity" (115) - this alert MAY be sent by a server
595 that receives an unknown user name. This alert is always fatal.
596 See Section 2.5.1.3 for details.
598 o "insufficient_security" (71) - this alert MUST be sent by a client
599 that receives unknown or untrusted (N, g) values. This alert is
600 always fatal. See Section 2.5.3 for details.
602 o "illegal_parameter" (47) - this alert MUST be sent by a client or
603 server that receives a key exchange message with A % N = 0 or B %
604 N = 0. This alert is always fatal. See Section 2.5.3 and
605 Section 2.5.4 and for details.
607 The "insufficient_security" and "illegal_parameter" alerts are
608 defined in [TLS]. The "unknown_psk_identity" alert is defined in
609 [PSK].
618 Taylor, et al. Informational [Page 11]
619 \f
620 RFC 5054 Using SRP for TLS Authentication November 2007
623 3. Security Considerations
625 3.1. General Considerations for Implementors
627 The checks described in Section 2.5.3 and Section 2.5.4 on the
628 received values for A and B are CRUCIAL for security and MUST be
629 performed.
631 The private values a and b SHOULD be at least 256-bit random numbers,
632 to give approximately 128 bits of security against certain methods of
633 calculating discrete logarithms. See [TLS], Section D.1, for advice
634 on choosing cryptographically secure random numbers.
636 3.2. Accepting Group Parameters
638 An attacker who could calculate discrete logarithms % N could
639 compromise user passwords, and could also compromise the
640 confidentiality and integrity of TLS sessions. Clients MUST ensure
641 that the received parameter N is large enough to make calculating
642 discrete logarithms computationally infeasible.
644 An attacker may try to send a prime value N that is large enough to
645 be secure, but that has a special form for which the attacker can
646 more easily compute discrete logarithms (e.g., using the algorithm
647 discussed in [TRAPDOOR]). If the client executes the protocol using
648 such a prime, the client's password could be compromised. Because of
649 the difficulty of checking for such primes in real time, clients
650 SHOULD only accept group parameters that come from a trusted source,
651 such as those listed in Appendix A, or parameters configured locally
652 by a trusted administrator.
654 3.3. Protocol Characteristics
656 If an attacker learns a user's SRP verifier (e.g., by gaining access
657 to a server's password file), the attacker can masquerade as the real
658 server to that user, and can also attempt a dictionary attack to
659 recover that user's password.
661 An attacker could repeatedly contact an SRP server and try to guess a
662 legitimate user's password. Servers SHOULD take steps to prevent
663 this, such as limiting the rate of authentication attempts from a
664 particular IP address or against a particular user name.
666 The client's user name is sent in the clear in the Client Hello
667 message. To avoid sending the user name in the clear, the client
668 could first open a conventional anonymous or server-authenticated
669 connection, then renegotiate an SRP-authenticated connection with the
670 handshake protected by the first connection.
674 Taylor, et al. Informational [Page 12]
675 \f
676 RFC 5054 Using SRP for TLS Authentication November 2007
679 If the client receives an "unknown_psk_identity" alert in response to
680 a client hello, this alert may have been inserted by an attacker.
681 The client should be careful about making any decisions, or forming
682 any conclusions, based on receiving this alert.
684 It is possible to choose a (user name, password) pair such that the
685 resulting verifier will also match other, related, (user name,
686 password) pairs. Thus, anyone using verifiers should be careful not
687 to assume that only a single (user name, password) pair matches the
688 verifier.
690 3.4. Hash Function Considerations
692 This protocol uses SHA-1 to derive several values:
694 o u prevents an attacker who learns a user's verifier from being
695 able to authenticate as that user (see [SRP-6]).
697 o k prevents an attacker who can select group parameters from being
698 able to launch a 2-for-1 guessing attack (see [SRP-6]).
700 o x contains the user's password mixed with a salt.
702 Cryptanalytic attacks against SHA-1 that only affect its collision-
703 resistance do not compromise these uses. If attacks against SHA-1
704 are discovered that do compromise these uses, new cipher suites
705 should be specified to use a different hash algorithm.
707 In this situation, clients could send a Client Hello message
708 containing new and/or old SRP cipher suites along with a single SRP
709 extension. The server could then select the appropriate cipher suite
710 based on the type of verifier it has stored for this user.
712 4. IANA Considerations
714 This document defines a new TLS extension "srp" (value 12), whose
715 value has been assigned from the TLS ExtensionType Registry defined
716 in [TLSEXT].
718 This document defines nine new cipher suites, whose values have been
719 assigned from the TLS Ciphersuite registry defined in [TLS].
721 CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
723 CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
725 CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
730 Taylor, et al. Informational [Page 13]
731 \f
732 RFC 5054 Using SRP for TLS Authentication November 2007
735 CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
737 CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
739 CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
741 CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
743 CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
745 CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
747 5. References
749 5.1. Normative References
751 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
752 Requirement Levels", BCP 14, RFC 2119, March 1997.
754 [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol version
755 1.1", RFC 4346, April 2006.
757 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
758 J., and T. Wright, "Transport Layer Security (TLS)
759 Extensions", RFC 4366, April 2006.
761 [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
762 Internationalized Strings ("stringprep")", RFC 3454,
763 December 2002.
765 [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user
766 names and passwords", RFC 4013, February 2005.
768 [SRP-RFC] Wu, T., "The SRP Authentication and Key Exchange
769 System", RFC 2945, September 2000.
771 [SHA1] "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
773 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
774 Keyed-Hashing for Message Authentication", RFC 2104,
775 February 1997.
777 [AESCIPH] Chown, P., "Advanced Encryption Standard (AES)
778 Ciphersuites for Transport Layer Security (TLS)",
779 RFC 3268, June 2002.
786 Taylor, et al. Informational [Page 14]
787 \f
788 RFC 5054 Using SRP for TLS Authentication November 2007
791 [PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key
792 Ciphersuites for Transport Layer Security (TLS)",
793 RFC 4279, December 2005.
795 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponentiation
796 (MODP) Diffie-Hellman groups for Internet Key Exchange
797 (IKE)", RFC 3526, May 2003.
799 5.2. Informative References
801 [IMAP] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
802 RFC 2595, June 1999.
804 [SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the
805 Secure Remote Password Protocol", Submission to IEEE
806 P1363.2 working group, October 2002,
807 <http://grouper.ieee.org/groups/1363/>.
809 [SRP] Wu, T., "The Secure Remote Password Protocol",
810 Proceedings of the 1998 Internet Society Network and
811 Distributed System Security Symposium pp. 97-111,
812 March 1998.
814 [TRAPDOOR] Gordon, D., "Designing and Detecting Trapdoors for
815 Discrete Log Cryptosystems", Springer-Verlag Advances
816 in Cryptology - Crypto '92, pp. 66-75, 1993.
842 Taylor, et al. Informational [Page 15]
843 \f
844 RFC 5054 Using SRP for TLS Authentication November 2007
847 Appendix A. SRP Group Parameters
849 The 1024-, 1536-, and 2048-bit groups are taken from software
850 developed by Tom Wu and Eugene Jhong for the Stanford SRP
851 distribution, and subsequently proven to be prime. The larger primes
852 are taken from [MODP], but generators have been calculated that are
853 primitive roots of N, unlike the generators in [MODP].
855 The 1024-bit and 1536-bit groups MUST be supported.
857 1. 1024-bit Group
859 The hexadecimal value for the prime is:
861 EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
862 9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
863 8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
864 7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
865 FD5138FE 8376435B 9FC61D2F C0EB06E3
867 The generator is: 2.
869 2. 1536-bit Group
871 The hexadecimal value for the prime is:
873 9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
874 4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
875 80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
876 E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
877 6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
878 F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
879 8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
881 The generator is: 2.
898 Taylor, et al. Informational [Page 16]
899 \f
900 RFC 5054 Using SRP for TLS Authentication November 2007
903 3. 2048-bit Group
905 The hexadecimal value for the prime is:
907 AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
908 3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
909 CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
910 D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
911 7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
912 436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
913 5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
914 03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
915 94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
916 9E4AFF73
918 The generator is: 2.
920 4. 3072-bit Group
922 This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
923 1690314 }
925 Its hexadecimal value is:
927 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
928 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
929 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
930 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
931 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
932 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
933 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
934 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
935 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
936 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
937 B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
938 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
939 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
940 E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
942 The generator is: 5.
954 Taylor, et al. Informational [Page 17]
955 \f
956 RFC 5054 Using SRP for TLS Authentication November 2007
959 5. 4096-bit Group
961 This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
962 240904 }
964 Its hexadecimal value is:
966 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
967 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
968 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
969 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
970 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
971 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
972 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
973 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
974 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
975 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
976 B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
977 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
978 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
979 E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
980 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
981 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
982 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
983 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
984 FFFFFFFF FFFFFFFF
986 The generator is: 5.
1010 Taylor, et al. Informational [Page 18]
1011 \f
1012 RFC 5054 Using SRP for TLS Authentication November 2007
1015 6. 6144-bit Group
1017 This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
1018 929484 }
1020 Its hexadecimal value is:
1022 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1023 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1024 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1025 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1026 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1027 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1028 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1029 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1030 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1031 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1032 B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1033 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1034 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1035 E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
1036 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
1037 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
1038 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
1039 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
1040 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
1041 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
1042 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
1043 2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
1044 F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
1045 BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
1046 CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
1047 B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
1048 387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
1049 6DCC4024 FFFFFFFF FFFFFFFF
1051 The generator is: 5.
1066 Taylor, et al. Informational [Page 19]
1067 \f
1068 RFC 5054 Using SRP for TLS Authentication November 2007
1071 7. 8192-bit Group
1073 This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
1074 4743158 }
1076 Its hexadecimal value is:
1078 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
1079 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
1080 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
1081 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
1082 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
1083 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
1084 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
1085 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
1086 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
1087 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
1088 B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1089 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
1090 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
1091 E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
1092 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
1093 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
1094 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
1095 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
1096 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
1097 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
1098 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
1099 2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
1100 F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
1101 BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
1102 CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
1103 B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
1104 387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
1105 6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
1106 3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
1107 5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
1108 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
1109 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
1110 6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
1111 0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
1112 359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
1113 FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
1114 60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
1116 The generator is: 19 (decimal).
1122 Taylor, et al. Informational [Page 20]
1123 \f
1124 RFC 5054 Using SRP for TLS Authentication November 2007
1127 Appendix B. SRP Test Vectors
1129 The following test vectors demonstrate calculation of the verifier
1130 and premaster secret.
1132 I = "alice"
1134 P = "password123"
1136 s = BEB25379 D1A8581E B5A72767 3A2441EE
1138 N, g = <1024-bit parameters from Appendix A>
1140 k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
1142 x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
1144 v =
1146 7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
1147 9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
1148 C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
1149 EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
1150 E955A5E2 9E7AB245 DB2BE315 E2099AFB
1152 a =
1154 60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
1155 DA2D4393
1157 b =
1159 E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
1160 05284D20
1162 A =
1164 61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
1165 4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
1166 8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
1167 BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
1168 B349EF5D 76988A36 72FAC47B 0769447B
1178 Taylor, et al. Informational [Page 21]
1179 \f
1180 RFC 5054 Using SRP for TLS Authentication November 2007
1183 B =
1185 BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
1186 BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
1187 6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
1188 37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
1189 EB4012B7 D7665238 A8E3FB00 4B117B58
1191 u =
1193 CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
1195 <premaster secret> =
1197 B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
1198 233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
1199 41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
1200 3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
1201 C346D7E4 74B29EDE 8A469FFE CA686E5A
1203 Appendix C. Acknowledgements
1205 Thanks to all on the IETF TLS mailing list for ideas and analysis.
1234 Taylor, et al. Informational [Page 22]
1235 \f
1236 RFC 5054 Using SRP for TLS Authentication November 2007
1239 Authors' Addresses
1241 David Taylor
1242 Independent
1244 EMail: dtaylor@gnutls.org
1247 Tom Wu
1248 Cisco
1250 EMail: thomwu@cisco.com
1253 Nikos Mavrogiannopoulos
1254 Independent
1256 EMail: nmav@gnutls.org
1257 URI: http://www.gnutls.org/
1260 Trevor Perrin
1261 Independent
1263 EMail: trevp@trevp.net
1264 URI: http://trevp.net/
1290 Taylor, et al. Informational [Page 23]
1291 \f
1292 RFC 5054 Using SRP for TLS Authentication November 2007
1295 Full Copyright Statement
1297 Copyright (C) The IETF Trust (2007).
1299 This document is subject to the rights, licenses and restrictions
1300 contained in BCP 78, and except as set forth therein, the authors
1301 retain all their rights.
1303 This document and the information contained herein are provided on an
1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1311 Intellectual Property
1313 The IETF takes no position regarding the validity or scope of any
1314 Intellectual Property Rights or other rights that might be claimed to
1315 pertain to the implementation or use of the technology described in
1316 this document or the extent to which any license under such rights
1317 might or might not be available; nor does it represent that it has
1318 made any independent effort to identify any such rights. Information
1319 on the procedures with respect to rights in RFC documents can be
1320 found in BCP 78 and BCP 79.
1322 Copies of IPR disclosures made to the IETF Secretariat and any
1323 assurances of licenses to be made available, or the result of an
1324 attempt made to obtain a general license or permission for the use of
1325 such proprietary rights by implementers or users of this
1326 specification can be obtained from the IETF on-line IPR repository at
1327 http://www.ietf.org/ipr.
1329 The IETF invites any interested party to bring to its attention any
1330 copyrights, patents or patent applications, or other proprietary
1331 rights that may cover technology that may be required to implement
1332 this standard. Please address the information to the IETF at
1333 ietf-ipr@ietf.org.
1346 Taylor, et al. Informational [Page 24]
1347 \f