sirp 2.0.0.pre

Sign up to get free protection for your applications and to get access to all the features.
@@ -0,0 +1,1347 @@
1
+
2
+
3
+
4
+
5
+
6
+
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
15
+
16
+
17
+ Using the Secure Remote Password (SRP) Protocol for TLS Authentication
18
+
19
+ Status of This Memo
20
+
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.
24
+
25
+ Abstract
26
+
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.
30
+
31
+
32
+
33
+
34
+
35
+
36
+
37
+
38
+
39
+
40
+
41
+
42
+
43
+
44
+
45
+
46
+
47
+
48
+
49
+
50
+
51
+
52
+
53
+
54
+
55
+
56
+
57
+
58
+ Taylor, et al. Informational [Page 1]
59
+
60
+ RFC 5054 Using SRP for TLS Authentication November 2007
61
+
62
+
63
+ Table of Contents
64
+
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
95
+
96
+
97
+
98
+
99
+
100
+
101
+
102
+
103
+
104
+
105
+
106
+
107
+
108
+
109
+
110
+
111
+
112
+
113
+
114
+ Taylor, et al. Informational [Page 2]
115
+
116
+ RFC 5054 Using SRP for TLS Authentication November 2007
117
+
118
+
119
+ 1. Introduction
120
+
121
+ At the time of writing TLS [TLS] uses public key certificates, pre-
122
+ shared keys, or Kerberos for authentication.
123
+
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.
129
+
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.
135
+
136
+ This document describes the use of the SRP authentication method for
137
+ TLS.
138
+
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].
142
+
143
+ 2. SRP Authentication in TLS
144
+
145
+ 2.1. Notation and Terminology
146
+
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.
152
+
153
+
154
+
155
+
156
+
157
+
158
+
159
+
160
+
161
+
162
+
163
+
164
+
165
+
166
+
167
+
168
+
169
+
170
+ Taylor, et al. Informational [Page 3]
171
+
172
+ RFC 5054 Using SRP for TLS Authentication November 2007
173
+
174
+
175
+ This document uses the variable names defined in [SRP-6]:
176
+
177
+ N, g: group parameters (prime and generator)
178
+
179
+ s: salt
180
+
181
+ B, b: server's public and private values
182
+
183
+ A, a: client's public and private values
184
+
185
+ I: user name (aka "identity")
186
+
187
+ P: password
188
+
189
+ v: verifier
190
+
191
+ k: SRP-6 multiplier
192
+
193
+ The | symbol indicates string concatenation, the ^ operator is the
194
+ exponentiation operation, and the % operator is the integer remainder
195
+ operation.
196
+
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.
206
+
207
+ 2.2. Handshake Protocol Overview
208
+
209
+ The advent of [SRP-6] allows the SRP protocol to be implemented using
210
+ the standard sequence of handshake messages defined in [TLS].
211
+
212
+ The parameters to various messages are given in the following
213
+ diagram.
214
+
215
+
216
+
217
+
218
+
219
+
220
+
221
+
222
+
223
+
224
+
225
+
226
+ Taylor, et al. Informational [Page 4]
227
+
228
+ RFC 5054 Using SRP for TLS Authentication November 2007
229
+
230
+
231
+ Client Server
232
+
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
243
+
244
+ Application Data <-------> Application Data
245
+
246
+ * Indicates an optional message that is not always sent.
247
+
248
+ Figure 1
249
+
250
+ 2.3. Text Preparation
251
+
252
+ The user name and password strings SHALL be UTF-8 encoded Unicode,
253
+ prepared using the [SASLPREP] profile of [STRINGPREP].
254
+
255
+ 2.4. SRP Verifier Creation
256
+
257
+ The verifier is calculated as described in Section 3 of [SRP-RFC].
258
+ We give the algorithm here for convenience.
259
+
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:
263
+
264
+ x = SHA1(s | SHA1(I | ":" | P))
265
+ v = g^x % N
266
+
267
+ 2.5. Changes to the Handshake Message Contents
268
+
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.
273
+
274
+
275
+
276
+
277
+
278
+
279
+
280
+
281
+
282
+ Taylor, et al. Informational [Page 5]
283
+
284
+ RFC 5054 Using SRP for TLS Authentication November 2007
285
+
286
+
287
+ 2.5.1. Client Hello
288
+
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.
293
+
294
+ 2.5.1.1. Session Resumption
295
+
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.
300
+
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.
306
+
307
+ 2.5.1.2. Missing SRP Extension
308
+
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.
314
+
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.
320
+
321
+ 2.5.1.3. Unknown SRP User Name
322
+
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.
330
+
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
335
+
336
+
337
+
338
+ Taylor, et al. Informational [Page 6]
339
+
340
+ RFC 5054 Using SRP for TLS Authentication November 2007
341
+
342
+
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.
348
+
349
+ 2.5.2. Server Certificate
350
+
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.
356
+
357
+ 2.5.3. Server Key Exchange
358
+
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.
362
+
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)).
367
+
368
+ If the server has sent a certificate message, the server key exchange
369
+ message MUST be signed.
370
+
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.
377
+
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.
382
+
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.
390
+
391
+
392
+
393
+
394
+ Taylor, et al. Informational [Page 7]
395
+
396
+ RFC 5054 Using SRP for TLS Authentication November 2007
397
+
398
+
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).
402
+
403
+ The client MUST abort the handshake with an "illegal_parameter" alert
404
+ if B % N = 0.
405
+
406
+ 2.5.4. Client Key Exchange
407
+
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.
411
+
412
+ The server MUST abort the handshake with an "illegal_parameter" alert
413
+ if A % N = 0.
414
+
415
+ 2.6. Calculating the Premaster Secret
416
+
417
+ The premaster secret is calculated by the client as follows:
418
+
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
427
+
428
+ The premaster secret is calculated by the server as follows:
429
+
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
437
+
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.
443
+
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.
447
+
448
+
449
+
450
+ Taylor, et al. Informational [Page 8]
451
+
452
+ RFC 5054 Using SRP for TLS Authentication November 2007
453
+
454
+
455
+ 2.7. Ciphersuite Definitions
456
+
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].
460
+
461
+ CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
462
+
463
+ CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
464
+
465
+ CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
466
+
467
+ CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
468
+
469
+ CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
470
+
471
+ CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
472
+
473
+ CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
474
+
475
+ CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
476
+
477
+ CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
478
+
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.
483
+
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.
487
+
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.
492
+
493
+ 2.8. New Message Structures
494
+
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].
498
+
499
+
500
+
501
+
502
+
503
+
504
+
505
+
506
+ Taylor, et al. Informational [Page 9]
507
+
508
+ RFC 5054 Using SRP for TLS Authentication November 2007
509
+
510
+
511
+ 2.8.1. Client Hello
512
+
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.
516
+
517
+ The "extension_data" field of the SRP extension SHALL contain:
518
+
519
+ opaque srp_I<1..2^8-1>;
520
+
521
+ where srp_I is the user name, encoded per Section 2.3.
522
+
523
+ 2.8.2. Server Key Exchange
524
+
525
+ A new value, "srp", has been added to the enumerated
526
+ KeyExchangeAlgorithm originally defined in [TLS].
527
+
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.
531
+
532
+ If a certificate is sent to the client, the server key exchange
533
+ message must be signed.
534
+
535
+ enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
536
+
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;
550
+
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 */
557
+
558
+
559
+
560
+
561
+
562
+ Taylor, et al. Informational [Page 10]
563
+
564
+ RFC 5054 Using SRP for TLS Authentication November 2007
565
+
566
+
567
+ 2.8.3. Client Key Exchange
568
+
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.
572
+
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;
580
+
581
+ struct {
582
+ opaque srp_A<1..2^16-1>;
583
+ } ClientSRPPublic;
584
+
585
+ 2.9. Error Alerts
586
+
587
+ This document introduces four new uses of alerts:
588
+
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.
593
+
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.
597
+
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.
601
+
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.
606
+
607
+ The "insufficient_security" and "illegal_parameter" alerts are
608
+ defined in [TLS]. The "unknown_psk_identity" alert is defined in
609
+ [PSK].
610
+
611
+
612
+
613
+
614
+
615
+
616
+
617
+
618
+ Taylor, et al. Informational [Page 11]
619
+
620
+ RFC 5054 Using SRP for TLS Authentication November 2007
621
+
622
+
623
+ 3. Security Considerations
624
+
625
+ 3.1. General Considerations for Implementors
626
+
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.
630
+
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.
635
+
636
+ 3.2. Accepting Group Parameters
637
+
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.
643
+
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.
653
+
654
+ 3.3. Protocol Characteristics
655
+
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.
660
+
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.
665
+
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.
671
+
672
+
673
+
674
+ Taylor, et al. Informational [Page 12]
675
+
676
+ RFC 5054 Using SRP for TLS Authentication November 2007
677
+
678
+
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.
683
+
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.
689
+
690
+ 3.4. Hash Function Considerations
691
+
692
+ This protocol uses SHA-1 to derive several values:
693
+
694
+ o u prevents an attacker who learns a user's verifier from being
695
+ able to authenticate as that user (see [SRP-6]).
696
+
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]).
699
+
700
+ o x contains the user's password mixed with a salt.
701
+
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.
706
+
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.
711
+
712
+ 4. IANA Considerations
713
+
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].
717
+
718
+ This document defines nine new cipher suites, whose values have been
719
+ assigned from the TLS Ciphersuite registry defined in [TLS].
720
+
721
+ CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
722
+
723
+ CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
724
+
725
+ CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
726
+
727
+
728
+
729
+
730
+ Taylor, et al. Informational [Page 13]
731
+
732
+ RFC 5054 Using SRP for TLS Authentication November 2007
733
+
734
+
735
+ CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
736
+
737
+ CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
738
+
739
+ CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
740
+
741
+ CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
742
+
743
+ CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
744
+
745
+ CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
746
+
747
+ 5. References
748
+
749
+ 5.1. Normative References
750
+
751
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate
752
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
753
+
754
+ [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol version
755
+ 1.1", RFC 4346, April 2006.
756
+
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.
760
+
761
+ [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
762
+ Internationalized Strings ("stringprep")", RFC 3454,
763
+ December 2002.
764
+
765
+ [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user
766
+ names and passwords", RFC 4013, February 2005.
767
+
768
+ [SRP-RFC] Wu, T., "The SRP Authentication and Key Exchange
769
+ System", RFC 2945, September 2000.
770
+
771
+ [SHA1] "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
772
+
773
+ [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
774
+ Keyed-Hashing for Message Authentication", RFC 2104,
775
+ February 1997.
776
+
777
+ [AESCIPH] Chown, P., "Advanced Encryption Standard (AES)
778
+ Ciphersuites for Transport Layer Security (TLS)",
779
+ RFC 3268, June 2002.
780
+
781
+
782
+
783
+
784
+
785
+
786
+ Taylor, et al. Informational [Page 14]
787
+
788
+ RFC 5054 Using SRP for TLS Authentication November 2007
789
+
790
+
791
+ [PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key
792
+ Ciphersuites for Transport Layer Security (TLS)",
793
+ RFC 4279, December 2005.
794
+
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.
798
+
799
+ 5.2. Informative References
800
+
801
+ [IMAP] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
802
+ RFC 2595, June 1999.
803
+
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/>.
808
+
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.
813
+
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.
817
+
818
+
819
+
820
+
821
+
822
+
823
+
824
+
825
+
826
+
827
+
828
+
829
+
830
+
831
+
832
+
833
+
834
+
835
+
836
+
837
+
838
+
839
+
840
+
841
+
842
+ Taylor, et al. Informational [Page 15]
843
+
844
+ RFC 5054 Using SRP for TLS Authentication November 2007
845
+
846
+
847
+ Appendix A. SRP Group Parameters
848
+
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].
854
+
855
+ The 1024-bit and 1536-bit groups MUST be supported.
856
+
857
+ 1. 1024-bit Group
858
+
859
+ The hexadecimal value for the prime is:
860
+
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
866
+
867
+ The generator is: 2.
868
+
869
+ 2. 1536-bit Group
870
+
871
+ The hexadecimal value for the prime is:
872
+
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
880
+
881
+ The generator is: 2.
882
+
883
+
884
+
885
+
886
+
887
+
888
+
889
+
890
+
891
+
892
+
893
+
894
+
895
+
896
+
897
+
898
+ Taylor, et al. Informational [Page 16]
899
+
900
+ RFC 5054 Using SRP for TLS Authentication November 2007
901
+
902
+
903
+ 3. 2048-bit Group
904
+
905
+ The hexadecimal value for the prime is:
906
+
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
917
+
918
+ The generator is: 2.
919
+
920
+ 4. 3072-bit Group
921
+
922
+ This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
923
+ 1690314 }
924
+
925
+ Its hexadecimal value is:
926
+
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
941
+
942
+ The generator is: 5.
943
+
944
+
945
+
946
+
947
+
948
+
949
+
950
+
951
+
952
+
953
+
954
+ Taylor, et al. Informational [Page 17]
955
+
956
+ RFC 5054 Using SRP for TLS Authentication November 2007
957
+
958
+
959
+ 5. 4096-bit Group
960
+
961
+ This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
962
+ 240904 }
963
+
964
+ Its hexadecimal value is:
965
+
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
985
+
986
+ The generator is: 5.
987
+
988
+
989
+
990
+
991
+
992
+
993
+
994
+
995
+
996
+
997
+
998
+
999
+
1000
+
1001
+
1002
+
1003
+
1004
+
1005
+
1006
+
1007
+
1008
+
1009
+
1010
+ Taylor, et al. Informational [Page 18]
1011
+
1012
+ RFC 5054 Using SRP for TLS Authentication November 2007
1013
+
1014
+
1015
+ 6. 6144-bit Group
1016
+
1017
+ This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
1018
+ 929484 }
1019
+
1020
+ Its hexadecimal value is:
1021
+
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
1050
+
1051
+ The generator is: 5.
1052
+
1053
+
1054
+
1055
+
1056
+
1057
+
1058
+
1059
+
1060
+
1061
+
1062
+
1063
+
1064
+
1065
+
1066
+ Taylor, et al. Informational [Page 19]
1067
+
1068
+ RFC 5054 Using SRP for TLS Authentication November 2007
1069
+
1070
+
1071
+ 7. 8192-bit Group
1072
+
1073
+ This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
1074
+ 4743158 }
1075
+
1076
+ Its hexadecimal value is:
1077
+
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
1115
+
1116
+ The generator is: 19 (decimal).
1117
+
1118
+
1119
+
1120
+
1121
+
1122
+ Taylor, et al. Informational [Page 20]
1123
+
1124
+ RFC 5054 Using SRP for TLS Authentication November 2007
1125
+
1126
+
1127
+ Appendix B. SRP Test Vectors
1128
+
1129
+ The following test vectors demonstrate calculation of the verifier
1130
+ and premaster secret.
1131
+
1132
+ I = "alice"
1133
+
1134
+ P = "password123"
1135
+
1136
+ s = BEB25379 D1A8581E B5A72767 3A2441EE
1137
+
1138
+ N, g = <1024-bit parameters from Appendix A>
1139
+
1140
+ k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
1141
+
1142
+ x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
1143
+
1144
+ v =
1145
+
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
1151
+
1152
+ a =
1153
+
1154
+ 60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
1155
+ DA2D4393
1156
+
1157
+ b =
1158
+
1159
+ E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
1160
+ 05284D20
1161
+
1162
+ A =
1163
+
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
1169
+
1170
+
1171
+
1172
+
1173
+
1174
+
1175
+
1176
+
1177
+
1178
+ Taylor, et al. Informational [Page 21]
1179
+
1180
+ RFC 5054 Using SRP for TLS Authentication November 2007
1181
+
1182
+
1183
+ B =
1184
+
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
1190
+
1191
+ u =
1192
+
1193
+ CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
1194
+
1195
+ <premaster secret> =
1196
+
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
1202
+
1203
+ Appendix C. Acknowledgements
1204
+
1205
+ Thanks to all on the IETF TLS mailing list for ideas and analysis.
1206
+
1207
+
1208
+
1209
+
1210
+
1211
+
1212
+
1213
+
1214
+
1215
+
1216
+
1217
+
1218
+
1219
+
1220
+
1221
+
1222
+
1223
+
1224
+
1225
+
1226
+
1227
+
1228
+
1229
+
1230
+
1231
+
1232
+
1233
+
1234
+ Taylor, et al. Informational [Page 22]
1235
+
1236
+ RFC 5054 Using SRP for TLS Authentication November 2007
1237
+
1238
+
1239
+ Authors' Addresses
1240
+
1241
+ David Taylor
1242
+ Independent
1243
+
1244
+ EMail: dtaylor@gnutls.org
1245
+
1246
+
1247
+ Tom Wu
1248
+ Cisco
1249
+
1250
+ EMail: thomwu@cisco.com
1251
+
1252
+
1253
+ Nikos Mavrogiannopoulos
1254
+ Independent
1255
+
1256
+ EMail: nmav@gnutls.org
1257
+ URI: http://www.gnutls.org/
1258
+
1259
+
1260
+ Trevor Perrin
1261
+ Independent
1262
+
1263
+ EMail: trevp@trevp.net
1264
+ URI: http://trevp.net/
1265
+
1266
+
1267
+
1268
+
1269
+
1270
+
1271
+
1272
+
1273
+
1274
+
1275
+
1276
+
1277
+
1278
+
1279
+
1280
+
1281
+
1282
+
1283
+
1284
+
1285
+
1286
+
1287
+
1288
+
1289
+
1290
+ Taylor, et al. Informational [Page 23]
1291
+
1292
+ RFC 5054 Using SRP for TLS Authentication November 2007
1293
+
1294
+
1295
+ Full Copyright Statement
1296
+
1297
+ Copyright (C) The IETF Trust (2007).
1298
+
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.
1302
+
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.
1310
+
1311
+ Intellectual Property
1312
+
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.
1321
+
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.
1328
+
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.
1334
+
1335
+
1336
+
1337
+
1338
+
1339
+
1340
+
1341
+
1342
+
1343
+
1344
+
1345
+
1346
+ Taylor, et al. Informational [Page 24]
1347
+