sirp 2.0.0.pre
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- checksums.yaml.gz.sig +0 -0
- data.tar.gz.sig +1 -0
- data/.coco.yml +7 -0
- data/.gitignore +11 -0
- data/.rubocop.yml +32 -0
- data/.travis.yml +6 -0
- data/CHANGELOG.md +7 -0
- data/Gemfile +4 -0
- data/LICENSE.txt +24 -0
- data/README.md +231 -0
- data/RELEASE.md +101 -0
- data/Rakefile +8 -0
- data/bin/console +14 -0
- data/bin/setup +8 -0
- data/certs/gem-public_cert_grempe.pem +21 -0
- data/docs/rfc2945.txt +406 -0
- data/docs/rfc5054.txt +1347 -0
- data/examples/Gemfile +6 -0
- data/examples/README.md +34 -0
- data/examples/clients/javascript/.gitignore +1 -0
- data/examples/clients/javascript/app.js +59 -0
- data/examples/clients/javascript/index.html +23 -0
- data/examples/clients/javascript/package.json +15 -0
- data/examples/clients/ruby/client.rb +48 -0
- data/examples/server.rb +88 -0
- data/lib/sirp.rb +8 -0
- data/lib/sirp/client.rb +50 -0
- data/lib/sirp/sirp.rb +283 -0
- data/lib/sirp/verifier.rb +72 -0
- data/lib/sirp/version.rb +3 -0
- data/sirp.gemspec +48 -0
- metadata +226 -0
- metadata.gz.sig +0 -0
data/docs/rfc5054.txt
ADDED
@@ -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
|
+
|