1 |
|
2 |
|
3 |
|
4 |
HTTP Working Group J. Franks, Northwestern University |
5 |
INTERNET DRAFT P. Hallam-Baker, M.I.T. |
6 |
<draft-ietf-http-authentication-01> J. Hostetler, Spyglass, Inc. |
7 |
P. Leach, Microsoft Corporation |
8 |
A. Luotonen, Netscape Communications Corporation |
9 |
E. Sink, Spyglass, Inc. |
10 |
L. Stewart, Open Market, Inc. |
11 |
S. Lawrence, Agranat, Inc. |
12 |
Expires: September 13, 1998 March 13, 1998 |
13 |
|
14 |
|
15 |
|
16 |
HTTP Authentication: Basic and Digest Access Authentication |
17 |
|
18 |
|
19 |
|
20 |
Status of this Memo |
21 |
|
22 |
This document is an Internet-Draft. Internet-Drafts are working |
23 |
documents of the Internet Engineering Task Force (IETF), its areas, and |
24 |
its working groups. Note that other groups may also distribute working |
25 |
documents as Internet-Drafts. |
26 |
|
27 |
Internet-Drafts are draft documents valid for a maximum of six months |
28 |
and may be updated, replaced, or made obsolete by other documents at any |
29 |
time. It is inappropriate to use Internet-Drafts as reference material |
30 |
or to cite them other than as "work in progress". |
31 |
|
32 |
To learn the current status of any Internet-Draft, please check the |
33 |
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |
34 |
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
35 |
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or |
36 |
ftp.isi.edu (US West Coast). |
37 |
|
38 |
Distribution of this document is unlimited. Please send comments to the |
39 |
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the |
40 |
working group are archived at |
41 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about |
42 |
HTTP and the applications which use HTTP should take place on the <www- |
43 |
talk@w3.org> mailing list. |
44 |
|
45 |
Abstract |
46 |
|
47 |
''HTTP/1.0'' includes the specification for a Basic Access Authentication |
48 |
scheme. This scheme is not considered to be a secure method of user |
49 |
authentication (unless used in conjunction with some external secure |
50 |
system such as SSL [5]), as the user name and password are passed over |
51 |
the network as cleartext. |
52 |
|
53 |
This document also provides the specification for HTTP's authentication |
54 |
framework, the original Basic authentication scheme and a scheme based |
55 |
on cryptographic hashes, referred to as ''Digest Access Authentication''. |
56 |
It is therefore also intended to serve as a replacement for RFC 2069 |
57 |
[6]. Some optional elements specified by RFC 2069 have been removed |
58 |
from this specification due to problems found since its publication; |
59 |
other new elements have been added -for compatibility, those new |
60 |
elements have been made optional, but are strongly recommended. |
61 |
|
62 |
Like Basic, Digest access authentication verifies that both parties to a |
63 |
communication know a shared secret (a password); unlike Basic, this
|
64 |
|
65 |
|
66 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
67 |
|
68 |
verification can be done without sending the password in the clear, |
69 |
which is Basic's biggest weakness. As with most other authentication |
70 |
protocols, the greatest sources of risks are usually found not in the |
71 |
core protocol itself but in policies and procedures surrounding its use. |
72 |
|
73 |
|
74 |
|
75 |
|
76 |
|
77 |
|
78 |
|
79 |
|
80 |
|
81 |
|
82 |
|
83 |
|
84 |
|
85 |
|
86 |
|
87 |
|
88 |
|
89 |
|
90 |
|
91 |
|
92 |
|
93 |
|
94 |
|
95 |
|
96 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 |
|
112 |
|
113 |
|
114 |
|
115 |
|
116 |
|
117 |
|
118 |
|
119 |
|
120 |
|
121 |
|
122 |
|
123 |
|
124 |
Franks, et al. [Page 2]
|
125 |
|
126 |
|
127 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
128 |
|
129 |
Table of Contents |
130 |
|
131 |
|
132 |
|
133 |
HTTP AUTHENTICATION: BASIC AND DIGEST ACCESS AUTHENTICATION1 |
134 |
|
135 |
Status of this Memo........................................1 |
136 |
|
137 |
Abstract...................................................1 |
138 |
|
139 |
Table of Contents..........................................3 |
140 |
|
141 |
1 Access Authentication .................................5 |
142 |
1.1 Reliance on the HTTP/1.1 Specification ..............5 |
143 |
1.2 Access Authentication Framework .....................5 |
144 |
|
145 |
2 Basic Authentication Scheme ...........................6 |
146 |
|
147 |
3 Digest Access Authentication Scheme ...................7 |
148 |
3.1 Introduction ........................................7 |
149 |
3.1.1 Purpose ..........................................7 |
150 |
3.1.2 Overall Operation ................................8 |
151 |
3.1.3 Representation of digest values ..................8 |
152 |
3.1.4 Limitations ......................................8 |
153 |
3.2 Specification of Digest Headers .....................8 |
154 |
3.2.1 The WWW-Authenticate Response Header .............9 |
155 |
3.2.2 The Authorization Request Header ................11 |
156 |
3.2.3 The Authentication-Info Header ..................15 |
157 |
3.3 Digest Operation ...................................16 |
158 |
3.4 Security Protocol Negotiation ......................16 |
159 |
3.5 Example ............................................17 |
160 |
3.6 Proxy-Authentication and Proxy-Authorization .......17 |
161 |
|
162 |
4 Security Considerations ..............................18 |
163 |
4.1 Authentication of Clients using Basic Authentication18 |
164 |
4.2 Authentication of Clients using Digest Authentication 19 |
165 |
4.3 Limited Use Nonce Values ...........................19 |
166 |
4.4 Comparison of Digest with Basic Authentication .....20 |
167 |
4.5 Replay Attacks .....................................20 |
168 |
4.6 Weakness Created by Multiple Authentication Schemes 21 |
169 |
4.7 Online dictionary attacks ..........................21 |
170 |
4.8 Man in the Middle ..................................22 |
171 |
4.9 Chosen plaintext attacks ...........................22 |
172 |
4.10 Precomputed dictionary attacks .....................23 |
173 |
4.11 Batch brute force attacks ..........................23 |
174 |
4.12 Spoofing by Counterfeit Servers ....................23 |
175 |
4.13 Storing passwords ..................................23 |
176 |
4.14 Summary ............................................24 |
177 |
|
178 |
5 Acknowledgments ......................................24 |
179 |
|
180 |
6 References ...........................................25 |
181 |
|
182 |
7 Authors' Addresses ...................................25 |
183 |
|
184 |
|
185 |
Franks, et al. [Page 3]
|
186 |
|
187 |
|
188 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
189 |
|
190 |
|
191 |
1 Access Authentication |
192 |
|
193 |
|
194 |
1.1 Reliance on the HTTP/1.1 Specification |
195 |
|
196 |
This specification is a companion to the HTTP/1.1 specification [2]. It |
197 |
uses using the extended BNF section 2.1 of that document, and relies on |
198 |
both the BNF defined in that document and other aspects of the HTTP/1.1 |
199 |
specification. |
200 |
|
201 |
|
202 |
1.2 Access Authentication Framework |
203 |
|
204 |
HTTP provides a simple challenge-response authentication mechanism which |
205 |
MAY be used by a server to challenge a client request and by a client to |
206 |
provide authentication information. It uses an extensible, case- |
207 |
insensitive token to identify the authentication scheme, followed by a |
208 |
comma-separated list of attribute-value pairs which carry the parameters |
209 |
necessary for achieving authentication via that scheme. |
210 |
|
211 |
auth-scheme = token |
212 |
auth-param = token "=" ( token | quoted-string ) |
213 |
|
214 |
|
215 |
The 401 (Unauthorized) response message is used by an origin server to |
216 |
challenge the authorization of a user agent. This response MUST include |
217 |
a WWW-Authenticate header field containing at least one challenge |
218 |
applicable to the requested resource. The 407 (Proxy Authentication |
219 |
Required) response message is used by a proxy to challenge the |
220 |
authorization of a client and MUST include a Proxy-Authenticate header |
221 |
field containing a challenge applicable to the proxy for the requested |
222 |
resource. |
223 |
|
224 |
challenge = auth-scheme 1*SP 1#auth-param |
225 |
The authentication parameter realm is defined for all authentication |
226 |
schemes: |
227 |
|
228 |
realm = "realm" "=" realm-value |
229 |
realm-value = quoted-string |
230 |
|
231 |
|
232 |
The realm attribute (case-insensitive) is required for all |
233 |
authentication schemes which issue a challenge. The realm value (case- |
234 |
sensitive), in combination with the canonical root URL (see section |
235 |
5.1.2 of [2]) of the server being accessed, defines the protection |
236 |
space. These realms allow the protected resources on a server to be |
237 |
partitioned into a set of protection spaces, each with its own |
238 |
authentication scheme and/or authorization database. The realm value is |
239 |
a string, generally assigned by the origin server, which may have |
240 |
additional semantics specific to the authentication scheme. |
241 |
|
242 |
A user agent that wishes to authenticate itself with an origin server-- |
243 |
usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY |
244 |
do so by including an Authorization header field with the request. A |
245 |
client that wishes to authenticate itself with a proxy--usually, but not |
246 |
Franks, et al. [Page 5]
|
247 |
|
248 |
|
249 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
250 |
|
251 |
necessarily, after receiving a 407 (Proxy Authentication Required)--MAY |
252 |
do so by including a Proxy-Authorization header field with the request. |
253 |
Both the Authorization field value and the Proxy-Authorization field |
254 |
value consist of credentials containing the authentication information |
255 |
of the client for the realm of the resource being requested. |
256 |
|
257 |
credentials = basic-credentials | auth-scheme #auth-param |
258 |
|
259 |
The protection space determines the domain over which credentials can be |
260 |
automatically applied. If a prior request has been authorized, the same |
261 |
credentials MAY be reused for all other requests within that protection |
262 |
space for a period of time determined by the authentication scheme, |
263 |
parameters, and/or user preference. Unless otherwise defined by the |
264 |
authentication scheme, a single protection space cannot extend outside |
265 |
the scope of its server. |
266 |
|
267 |
If the origin server does not wish to accept the credentials sent with a |
268 |
request, it SHOULD return a 401 (Unauthorized) response. The response |
269 |
MUST include a WWW-Authenticate header field containing at least one |
270 |
(possibly new) challenge applicable to the requested resource. If a |
271 |
proxy does not accept the credentials sent with a request, it SHOULD |
272 |
return a 407 (Proxy Authentication Required). The response MUST include |
273 |
a Proxy-Authenticate header field containing a (possibly new) challenge |
274 |
applicable to the proxy for the requested resource. |
275 |
|
276 |
The HTTP protocol does not restrict applications to this simple |
277 |
challenge-response mechanism for access authentication. Additional |
278 |
mechanisms MAY be used, such as encryption at the transport level or via |
279 |
message encapsulation, and with additional header fields specifying |
280 |
authentication information. However, these additional mechanisms are not |
281 |
defined by this specification. |
282 |
|
283 |
Proxies MUST be completely transparent regarding user agent |
284 |
authentication by origin servers. That is, they must forward the WWW- |
285 |
Authenticate and Authorization headers untouched, and follow the rules |
286 |
found in section 14.8 of [2]. Both the Proxy-Authenticate and the Proxy- |
287 |
Authorization header fields are hop-by-hop headers (see section 13.5.1 |
288 |
of [2]). |
289 |
|
290 |
|
291 |
2 Basic Authentication Scheme |
292 |
|
293 |
The "basic" authentication scheme is based on the model that the client |
294 |
must authenticate itself with a user-ID and a password for each realm. |
295 |
The realm value should be considered an opaque string which can only be |
296 |
compared for equality with other realms on that server. The server will |
297 |
service the request only if it can validate the user-ID and password for |
298 |
the protection space of the Request-URI. There are no optional |
299 |
authentication parameters. |
300 |
|
301 |
For Basic, the framework above is utilized as follows: |
302 |
|
303 |
credentials = basic-credentials |
304 |
challenge = "Basic" realm |
305 |
|
306 |
|
307 |
Franks, et al. [Page 6]
|
308 |
|
309 |
|
310 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
311 |
|
312 |
Upon receipt of an unauthorized request for a URI within the protection |
313 |
space, the origin server MAY respond with a challenge like the |
314 |
following: |
315 |
|
316 |
WWW-Authenticate: Basic realm="WallyWorld" |
317 |
|
318 |
where "WallyWorld" is the string assigned by the server to identify the |
319 |
protection space of the Request-URI. A proxy may respond with the same |
320 |
challenge using the Proxy-Authenticate header field. |
321 |
|
322 |
To receive authorization, the client sends the userid and password, |
323 |
separated by a single colon (":") character, within a base64 [7]encoded |
324 |
string in the credentials. |
325 |
|
326 |
basic-credentials = "Basic" SP base64-user-pass |
327 |
base64-user-pass = <base64 [4] encoding of user-pass, |
328 |
except not limited to 76 char/line> |
329 |
user-pass = userid ":" password |
330 |
userid = *<TEXT excluding ":"> |
331 |
password = *TEXT |
332 |
|
333 |
Userids might be case sensitive. |
334 |
|
335 |
If the user agent wishes to send the userid "Aladdin" and password "open |
336 |
sesame", it would use the following header field: |
337 |
|
338 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
339 |
|
340 |
|
341 |
A client SHOULD assume that all paths at or deeper than the depth of the |
342 |
last symbolic element in the path field of the Request-URI also are |
343 |
within the protection space specified by the Basic realm value of the |
344 |
current challenge. A client MAY send the corresponding Authorization |
345 |
header with requests for resources in that space without receipt of |
346 |
another challenge from the server. |
347 |
|
348 |
If a client wishes to send the same userid and password to a proxy, it |
349 |
would use the Proxy-Authorization header field. See section 4 for |
350 |
security considerations associated with Basic authentication. |
351 |
|
352 |
|
353 |
3 Digest Access Authentication Scheme |
354 |
|
355 |
|
356 |
3.1 Introduction |
357 |
|
358 |
|
359 |
3.1.1 Purpose |
360 |
|
361 |
The protocol referred to as "HTTP/1.0" includes the specification for a |
362 |
Basic Access Authentication scheme[1]. This scheme is not considered to |
363 |
be a secure method of user authentication, as the user name and password |
364 |
are passed over the network in an unencrypted form. This document |
365 |
provides the specification for such a scheme, which does not send the |
366 |
password in cleartext. It is referred to as "Digest Access |
367 |
Authentication". |
368 |
Franks, et al. [Page 7]
|
369 |
|
370 |
|
371 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
372 |
|
373 |
The Digest Access Authentication scheme is not intended to be a complete |
374 |
answer to the need for security in the World Wide Web. This scheme |
375 |
provides no encryption of message content. The intent is simply to |
376 |
create an access authentication method which avoids the most serious |
377 |
flaws of Basic authentication. |
378 |
|
379 |
|
380 |
3.1.2 Overall Operation |
381 |
|
382 |
Like Basic Access Authentication, the Digest scheme is based on a simple |
383 |
challenge-response paradigm. The Digest scheme challenges using a nonce |
384 |
value. A valid response contains a checksum (by default the MD5 |
385 |
checksum) of the username, the password, the given nonce value, the HTTP |
386 |
method, and the requested URI. In this way, the password is never sent |
387 |
in the clear. Just as with the Basic scheme, the username and password |
388 |
must be prearranged in some fashion not addressed by this document. |
389 |
|
390 |
|
391 |
3.1.3 Representation of digest values |
392 |
|
393 |
An optional header allows the server to specify the algorithm used to |
394 |
create the checksum or digest. By default the MD5 algorithm is used and |
395 |
that is the only algorithm described in this document. |
396 |
|
397 |
For the purposes of this document, an MD5 digest of 128 bits is |
398 |
represented as 32 ASCII printable characters. The bits in the 128 bit |
399 |
digest are converted from most significant to least significant bit, |
400 |
four bits at a time to their ASCII presentation as follows. Each four |
401 |
bits is represented by its familiar hexadecimal notation from the |
402 |
characters 0123456789abcdef. That is, binary 0000 gets represented by |
403 |
the character '0', 0001, by '1', and so on up to the representation of |
404 |
1111 as 'f'. |
405 |
|
406 |
|
407 |
3.1.4 Limitations |
408 |
|
409 |
The Digest authentication scheme described in this document suffers from |
410 |
many known limitations. It is intended as a replacement for Basic |
411 |
authentication and nothing more. It is a password-based system and (on |
412 |
the server side) suffers from all the same problems of any password |
413 |
system. In particular, no provision is made in this protocol for the |
414 |
initial secure arrangement between user and server to establish the |
415 |
user's password. |
416 |
|
417 |
Users and implementors should be aware that this protocol is not as |
418 |
secure as Kerberos, and not as secure as any client-side private-key |
419 |
scheme. Nevertheless it is better than nothing, better than what is |
420 |
commonly used with telnet and ftp, and better than Basic authentication. |
421 |
|
422 |
|
423 |
3.2 Specification of Digest Headers |
424 |
|
425 |
The Digest Access Authentication scheme is conceptually similar to the |
426 |
Basic scheme. The formats of the modified WWW-Authenticate header line |
427 |
and the Authorization header line are specified below. In addition, a |
428 |
new header, Authentication-Info, is specified. |
429 |
Franks, et al. [Page 8]
|
430 |
|
431 |
|
432 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
433 |
|
434 |
3.2.1 The WWW-Authenticate Response Header |
435 |
|
436 |
If a server receives a request for an access-protected object, and an |
437 |
acceptable Authorization header is not sent, the server responds with a |
438 |
"401 Unauthorized" status code, and a WWW-Authenticate header as per the |
439 |
framework defined above, which for the digest scheme is utilized as |
440 |
follows : |
441 |
|
442 |
challenge = "Digest" digest-challenge |
443 |
|
444 |
digest-challenge = 1#( realm | [ domain ] | nonce | |
445 |
[ opaque ] |[ stale ] | [ algorithm ] | |
446 |
[ qop-options ] ) |
447 |
|
448 |
|
449 |
domain = "domain" "=" <"> URI ( 1*SP URI ) <"> |
450 |
nonce = "nonce" "=" nonce-value |
451 |
nonce-value = quoted-string |
452 |
opaque = "opaque" "=" quoted-string |
453 |
stale = "stale" "=" ( "true" | "false" ) |
454 |
algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" ) |
455 |
qop-options = "qop" "=" <"> 1#qop-value <"> |
456 |
qop-value = "auth" | "auth-int" | token |
457 |
|
458 |
|
459 |
The meanings of the values of the parameters used above are as follows: |
460 |
|
461 |
realm |
462 |
A string to be displayed to users so they know which username and |
463 |
password to use. This string should contain at least the name of the |
464 |
host performing the authentication and might additionally indicate |
465 |
the collection of users who might have access. An example might be |
466 |
"registered_users@gotham.news.com". |
467 |
|
468 |
domain |
469 |
A space-separated list of URIs, as specified in RFC XURI [7]. The |
470 |
intent is that the client could use this information to know the set |
471 |
of URIs for which the same authentication information should be sent. |
472 |
The URIs in this list may exist on different servers. If this keyword |
473 |
is omitted or empty, the client should assume that the domain |
474 |
consists of all URIs on the responding server. |
475 |
|
476 |
nonce |
477 |
A server-specified data string which may be uniquely generated each |
478 |
time a 401 response is made. It is recommended that this string be |
479 |
base64 or hexadecimal data. Specifically, since the string is passed |
480 |
in the header lines as a quoted string, the double-quote character is |
481 |
not allowed. |
482 |
|
483 |
The contents of the nonce are implementation dependent. The quality |
484 |
of the implementation depends on a good choice. A nonce might, for |
485 |
example, be constructed as the base 64 encoding of |
486 |
|
487 |
time-stamp H(time-stamp ":" ETag ":" private-key) |
488 |
where time-stamp is a server-generated time or other non-repeating |
489 |
value, ETag is the value of the HTTP ETag header associated with the |
490 |
Franks, et al. [Page 9]
|
491 |
|
492 |
|
493 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
494 |
|
495 |
requested entity, and private-key is data known only to the server. |
496 |
With a nonce of this form a server would recalculate the hash portion |
497 |
after receiving the client authentication header and reject the |
498 |
request if it did not match the nonce from that header or if the |
499 |
time-stamp value is not recent enough. In this way the server can |
500 |
limit the time of the nonce's validity. The inclusion of the ETag |
501 |
prevents a replay request for an updated version of the resource. |
502 |
(Note: including the IP address of the client in the nonce would |
503 |
appear to offer the server the ability to limit the reuse of the |
504 |
nonce to the same client that originally got it. However, that would |
505 |
break proxy farms, where requests from a single user often go through |
506 |
different proxies in the farm. Also, IP address spoofing is not that |
507 |
hard.) |
508 |
|
509 |
An implementation might choose not to accept a previously used nonce |
510 |
or a previously used digest to protect against a replay attack. Or, |
511 |
an implementation might choose to use one-time nonces or digests for |
512 |
POST or PUT requests and a time-stamp for GET requests. For more |
513 |
details on the issues involved see section 4. of this document. |
514 |
|
515 |
The nonce is opaque to the client. |
516 |
|
517 |
opaque |
518 |
A string of data, specified by the server, which should be returned |
519 |
by the client unchanged. It is recommended that this string be base64 |
520 |
or hexadecimal data. |
521 |
|
522 |
stale |
523 |
A flag, indicating that the previous request from the client was |
524 |
rejected because the nonce value was stale. If stale is TRUE (case- |
525 |
insensitive), the client may wish to simply retry the request with a |
526 |
new encrypted response, without reprompting the user for a new |
527 |
username and password. The server should only set stale to true if it |
528 |
receives a request for which the nonce is invalid but with a valid |
529 |
digest for that nonce (indicating that the client knows the correct |
530 |
username/password). |
531 |
|
532 |
algorithm |
533 |
A string indicating a pair of algorithms used to produce the digest |
534 |
and a checksum. If this is not present it is assumed to be "MD5". In |
535 |
this document the string obtained by applying the digest algorithm to |
536 |
the data "data" with secret "secret" will be denoted by KD(secret, |
537 |
data), and the string obtained by applying the checksum algorithm to |
538 |
the data "data" will be denoted H(data). The notation unq(X) means |
539 |
the value of the quoted-string X without the surrounding quotes. |
540 |
|
541 |
|
542 |
For the "MD5" and "MD5-sess" algorithms |
543 |
|
544 |
H(data) = MD5(data) |
545 |
and |
546 |
|
547 |
KD(secret, data) = H(concat(secret, ":", data)) |
548 |
i.e., the digest is the MD5 of the secret concatenated with a |
549 |
colon concatenated with the data. The "MD5-sess" algorithm is |
550 |
|
551 |
Franks, et al. [Page 10]
|
552 |
|
553 |
|
554 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
555 |
|
556 |
intended to allow efficient 3rd party authentication servers; |
557 |
for the difference in usage, see the description . |
558 |
|
559 |
qop-options |
560 |
This attribute is optional, but is made so only for backward |
561 |
compatibility with RFC 2069 [6]; it SHOULD be used by all |
562 |
implementations compliant with this version of the Digest scheme. |
563 |
If present, it is a quoted string of one or more tokens indicating |
564 |
the "quality of protection" values supported by the server. The |
565 |
value "auth" indicates authentication; the value "auth-int" indicates |
566 |
authentication with integrity protection; see the descriptions below |
567 |
for calculating the response attribute value for the application of |
568 |
this choice. |
569 |
|
570 |
|
571 |
3.2.2 The Authorization Request Header |
572 |
|
573 |
The client is expected to retry the request, passing an |
574 |
Authorization header line, which is defined according to the |
575 |
framework above, utilized as follows. |
576 |
|
577 |
credentials = "Digest" digest-response |
578 |
|
579 |
digest-response = 1#( username | realm | nonce | digest-uri | |
580 |
response | [ algorithm ] | [cnonce] | |
581 |
[opaque] | [server] | [message-qop] | |
582 |
[ nonce-count ] ) |
583 |
|
584 |
username = "username" "=" username-value |
585 |
username-value = quoted-string |
586 |
digest-uri = "uri" "=" digest-uri-value |
587 |
digest-uri-value = request-uri ; As specified by HTTP/1.1 |
588 |
message-qop = "qop" "=" qop-value |
589 |
cnonce = "cnonce" "=" cnonce-value |
590 |
cnonce-value = nonce-value |
591 |
nonce-count = "nc" "=" nc-value |
592 |
nc-value = 8LHEX |
593 |
response = "response" "=" request-digest |
594 |
LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
595 |
|"8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" |
596 |
|
597 |
|
598 |
The values of the opaque and algorithm fields must be those |
599 |
supplied in the WWW-Authenticate response header for the entity |
600 |
being requested. |
601 |
|
602 |
response |
603 |
A string of 32 hex digits computed as defined below, which proves |
604 |
that the user knows a password |
605 |
|
606 |
username |
607 |
The user's name in the specified realm. |
608 |
Franks, et al. [Page 11]
|
609 |
|
610 |
|
611 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
612 |
|
613 |
digest-uri |
614 |
The URI from Request-URI of the Request-Line; duplicated here because |
615 |
proxies are allowed to change the Request-Line in transit. |
616 |
|
617 |
qop |
618 |
Indicates what "quality of protection" the client has applied to the |
619 |
message. If present, its value MUST be one of the alternatives the |
620 |
server indicated it supports in the WWW-Authenticate header. These |
621 |
values affect the computation of the request-digest. Note that this |
622 |
is a single token, not a quoted list of alternatives as in WWW- |
623 |
Authenticate. This attribute is optional in order to preserve |
624 |
backward compatibility with a minimal implementation of RFC 2069 [6], |
625 |
but SHOULD be used if the server indicated that it is supported by |
626 |
providing a qop attribute in the WWW-Authenticate header field. |
627 |
|
628 |
cnonce |
629 |
An opaque quoted string value provided by the client and used by both |
630 |
client and server to avoid chosen plaintext attacks, to provide |
631 |
mutual authentication, and to provide some message integrity |
632 |
protection. See the descriptions below of the calculation of the |
633 |
response-digest and request-digest values. |
634 |
|
635 |
nonce-count |
636 |
This MUST be specified if a qop attribute is sent (see above), and |
637 |
MUST NOT be specified if the server did not send a qop attribute in |
638 |
the WWW-Authenticate header field. The nc-value is the hexadecimal |
639 |
count of the number of requests (including the current request) that |
640 |
the client has sent with the nonce value in this request. For |
641 |
example, in the first request sent in response to a given nonce |
642 |
value, the client sends "nc=0001". The purpose of this attribute is |
643 |
to allow the server to detect request replays by maintaining its own |
644 |
copy of this count - if the same nc-value is seen twice, then the |
645 |
request is a replay. See the description below of the construction |
646 |
of the request-digest value. |
647 |
|
648 |
The definition of request-digest above indicates the encoding for |
649 |
its value. The following definitions show how the value is |
650 |
computed. |
651 |
|
652 |
If the "algorithm" directive is not present, or its value is |
653 |
"MD5", then response-digest is computed as follows. |
654 |
|
655 |
If the "qop" directive is not present (this construction is for |
656 |
compatibility with RFC 2069): |
657 |
|
658 |
request-digest = |
659 |
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > |
660 |
<"> |
661 |
|
662 |
see below for the defintions for A1 and A2. |
663 |
|
664 |
If the "qop" value is "auth": |
665 |
|
666 |
request-digest = <"> < KD ( H(A1), unq(nonce-value) |
667 |
":" nc-value |
668 |
":" unq(cnonce-value) |
669 |
Franks, et al. [Page 12]
|
670 |
|
671 |
|
672 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
673 |
|
674 |
":" unq(qop-value) |
675 |
":" H(A2) |
676 |
) <"> |
677 |
where |
678 |
|
679 |
passwd = < user's password > |
680 |
|
681 |
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 |
682 |
is: |
683 |
|
684 |
A1 = unq(username-value) ":" unq(realm-value) ":" passwd |
685 |
|
686 |
|
687 |
If the "algorithm" directive's value is "MD5-sess", then A1 is |
688 |
calculated only once - on the first request by the client |
689 |
following receipt of a WWW-Authenticate challenge from the |
690 |
server. It uses the server nonce from that challenge, and the |
691 |
first client nonce value to construct A1 as follows: |
692 |
|
693 |
A1 = H( unq(username-value) ":" unq(realm-value) ":" |
694 |
passwd ) |
695 |
":" unq(nonce-value) ":" unq(cnonce-value) |
696 |
|
697 |
This creates a 'session key' for the authentication of subsequent |
698 |
requests and responses which is different for each session, thus |
699 |
limiting the amount of material hashed with any one key. Because the |
700 |
server need only use the hash of the user credentials in order to create |
701 |
the A1 value, this construction could be used as part of authentication |
702 |
using a third party service so that the web server would not need the |
703 |
actual password value. The specification of such a protocol is beyond |
704 |
the scope of this specification. |
705 |
|
706 |
If the "qop" directive's value is "auth" or is unspecified, then A2 is: |
707 |
|
708 |
A2 = Method ":" digest-uri-value |
709 |
|
710 |
If the "qop" value is "auth-int", then A2 is: |
711 |
|
712 |
A2 = Method ":" digest-uri-value ":" H(entity-body) |
713 |
|
714 |
Note that many of the fields, such as the "username-value" field, |
715 |
are defined as a "quoted-string". However, the "unq" notation |
716 |
indicates that surrounding quotation marks are removed in forming |
717 |
the string A1. Thus if the Authorization header includes the |
718 |
fields |
719 |
|
720 |
username="Mufasa", realm=myhost@testrealm.com |
721 |
|
722 |
and the user Mufasa has password "Circle Of Life" then H(A1) |
723 |
would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no |
724 |
quotation marks in the digested string. |
725 |
|
726 |
No white space is allowed in any of the strings to which the |
727 |
digest function H() is applied unless that white space exists in |
728 |
the quoted strings or entity body whose contents make up the |
729 |
|
730 |
Franks, et al. [Page 13]
|
731 |
|
732 |
|
733 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
734 |
|
735 |
string to be digested. For example, the string A1 illustrated |
736 |
above must be |
737 |
|
738 |
Mufasa:myhost@testrealm.com:Circle Of Life |
739 |
|
740 |
with no white space on either side of the colons, but with the |
741 |
white space between the words used in the password value. |
742 |
Likewise, the other strings digested by H() must not have white |
743 |
space on either side of the colons which delimit their fields |
744 |
unless that white space was in the quoted strings or entity body |
745 |
being digested. |
746 |
|
747 |
Also note that if integrity protection is applied (qop=auth-int), |
748 |
the H(entity-body) is the hash of the entity body, not the |
749 |
message body - it is computed before any transfer encoding is |
750 |
applied by the sender and after it has been removed by the |
751 |
recipient. |
752 |
|
753 |
The "method" value is the HTTP request method as specified in |
754 |
section 5.1 of [2]. The "request-uri" value is the Request-URI |
755 |
from the request line as specified in section 5.1 of [2]. This |
756 |
may be "*", an "absoluteURL" or an "abs_path" as specified in |
757 |
section 5.1.2 of [2], but it MUST agree with the Request-URI. In |
758 |
particular, it MUST be an "absoluteURL" if the Request-URI is an |
759 |
"absoluteURL". The "cnonce-value" is an optional client-chosen |
760 |
value whose purpose is to foil chosen plaintext attacks. |
761 |
|
762 |
The authenticating server must assure that the document |
763 |
designated by the "uri" parameter is the same as the document |
764 |
served. The purpose of duplicating information from the request |
765 |
URL in this field is to deal with the possibility that an |
766 |
intermediate proxy may alter the client's request. This altered |
767 |
(but presumably semantically equivalent) request would not result |
768 |
in the same digest as that calculated by the client. |
769 |
|
770 |
Implementers should be aware of how authenticated transactions |
771 |
interact with shared caches. The HTTP/1.1 protocol specifies that |
772 |
when a shared cache (see section 13.10 of [2]) has received a |
773 |
request containing an Authorization header and a response from |
774 |
relaying that request, it MUST NOT return that response as a |
775 |
reply to any other request, unless one of two Cache-Control (see |
776 |
section 14.9 of [2]) directives was present in the response. If |
777 |
the original response included the "must-revalidate" Cache- |
778 |
Control directive, the cache MAY use the entity of that response |
779 |
in replying to a subsequent request, but MUST first revalidate it |
780 |
with the origin server, using the request headers from the new |
781 |
request to allow the origin server to authenticate the new |
782 |
request. Alternatively, if the original response included the |
783 |
"public" Cache-Control directive, the response entity MAY be |
784 |
returned in reply to any subsequent request. |
785 |
|
786 |
|
787 |
|
788 |
|
789 |
|
790 |
|
791 |
Franks, et al. [Page 14]
|
792 |
|
793 |
|
794 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
795 |
|
796 |
3.2.3 The Authentication-Info Header |
797 |
|
798 |
The Authentication-Info header is used by the server to |
799 |
communicate some information regarding the successful |
800 |
authentication in the response. |
801 |
|
802 |
AuthenticationInfo = "Authentication-Info" ":" auth-info |
803 |
auth-info = 1#(nextnonce | [ message-qop ] |
804 |
| [ response-auth ] | [ cnonce ] |
805 |
| [nonce-count] ) |
806 |
nextnonce = "nextnonce" "=" nonce-value |
807 |
response-auth = "rspauth" "=" response-digest |
808 |
response-digest = <"> *LHEX <"> |
809 |
|
810 |
The value of the nextnonce parameter is the nonce the server |
811 |
wishes the client to use for a future authentication response. |
812 |
The server may send the Authentication-Info header with a |
813 |
nextnonce field as a means of implementing one-time or otherwise |
814 |
changing nonces. If the nextnonce field is present the client |
815 |
SHOULD use it when constructing the Authorization header for its |
816 |
next request. Failure of the client to do so may result in a |
817 |
request to re-authenticate from the server with the "stale=TRUE". |
818 |
|
819 |
Server implementations should carefully consider the |
820 |
performance implications of the use of this mechanism; |
821 |
pipelined requests will not be possible if every response |
822 |
includes a nextnonce attribute which must be used on the next |
823 |
request received by the server. Consideration should be given |
824 |
to the performance vs. security tradeoffs of allowing an old |
825 |
nonce value to be used for a limited time to permit request |
826 |
pipelining. |
827 |
|
828 |
qop |
829 |
Indicates the "quality of protection" options applied to the |
830 |
response by the server. The value "auth" indicates authentication; |
831 |
the value "auth-int" indicates authentication with integrity |
832 |
protection. The server SHOULD use the same value for the qop |
833 |
directive in the response as was sent by the client in the |
834 |
corresponding request. |
835 |
|
836 |
The optional response digest in the "rspauth" directive supports |
837 |
mutual authentication -- the server proves that it knows the |
838 |
user's secret, and with qop=auth-int also provides limited |
839 |
integrity protection of the response. The response-digest value |
840 |
is calculated as for the request-digest in the Authorization |
841 |
header, except that if "qop=auth" or is not specified in the |
842 |
Authorization header for the request, A2 is |
843 |
|
844 |
A2 = Status-Code ":" digest-uri-value |
845 |
|
846 |
and if "qop=auth-int", then A2 is |
847 |
|
848 |
A2 = Status-Code ":" digest-uri-value ":" H(entity-body) |
849 |
|
850 |
where "Status-Code" is the status code (e.g., "200") from the |
851 |
"Status-Line" of the response, as defined in section 6.1 of [2], |
852 |
Franks, et al. [Page 15]
|
853 |
|
854 |
|
855 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
856 |
|
857 |
and "digest-uri-value" is the value of the "uri" directive on the |
858 |
Authorization header in the request. The "cnonce-value" MUST be |
859 |
one for the client request to which this message is the response. |
860 |
|
861 |
The Authentication-Info header is allowed in the trailer of an |
862 |
HTTP message transferred via chunked transfer-coding. |
863 |
|
864 |
|
865 |
3.3 Digest Operation |
866 |
|
867 |
Upon receiving the Authorization header, the server may check its |
868 |
validity by looking up its known password which corresponds to |
869 |
the submitted username. Then, the server must perform the same |
870 |
digest operation (e.g., MD5) performed by the client, and compare |
871 |
the result to the given request-digest value. |
872 |
|
873 |
Note that the HTTP server does not actually need to know the |
874 |
user's cleartext password. As long as H(A1) is available to the |
875 |
server, the validity of an Authorization header may be verified. |
876 |
|
877 |
A client may remember the username, password and nonce values, so |
878 |
that future requests within the specified <domain> may include |
879 |
the Authorization header preemptively. The server may choose to |
880 |
accept the old Authorization header information, even though the |
881 |
nonce value included might not be fresh. Alternatively, the |
882 |
server could return a 401 response with a new nonce value, |
883 |
causing the client to retry the request. By specifying stale=TRUE |
884 |
with this response, the server hints to the client that the |
885 |
request should be retried with the new nonce, without reprompting |
886 |
the user for a new username and password. |
887 |
|
888 |
The opaque data is useful for transporting state information. For |
889 |
example, a server could be responsible for authenticating content |
890 |
which actually sits on another server. The first 401 response |
891 |
would include a domain field which includes the URI on the second |
892 |
server, and the opaque field for specifying state information. |
893 |
The client will retry the request, at which time the server may |
894 |
respond with a 301/302 redirection, pointing to the URI on the |
895 |
second server. The client will follow the redirection, and pass |
896 |
the same Authorization header, including the <opaque> data which |
897 |
the second server may require. |
898 |
|
899 |
As with the basic scheme, proxies must be completely transparent |
900 |
in the Digest access authentication scheme. That is, they must |
901 |
forward the WWW-Authenticate, Authentication-Info and |
902 |
Authorization headers untouched. If a proxy wants to authenticate |
903 |
a client before a request is forwarded to the server, it can be |
904 |
done using the Proxy-Authenticate and Proxy-Authorization headers |
905 |
described in section 3.6 below. |
906 |
|
907 |
|
908 |
3.4 Security Protocol Negotiation |
909 |
|
910 |
It is useful for a server to be able to know which security |
911 |
schemes a client is capable of handling. |
912 |
|
913 |
Franks, et al. [Page 16]
|
914 |
|
915 |
|
916 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
917 |
|
918 |
It is possible that a server may want to require Digest as its |
919 |
authentication method, even if the server does not know that the |
920 |
client supports it. A client is encouraged to fail gracefully if |
921 |
the server specifies only authentication schemes it cannot |
922 |
handle. |
923 |
|
924 |
|
925 |
3.5 Example |
926 |
|
927 |
The following example assumes that an access-protected document |
928 |
is being requested from the server. The URI of the document is |
929 |
"http://www.nowhere.org/dir/index.html". Both client and server |
930 |
know that the username for this document is "Mufasa", and the |
931 |
password is "Circle Of Life" (with one space between each of the |
932 |
three words). |
933 |
|
934 |
The first time the client requests the document, no Authorization |
935 |
header is sent, so the server responds with: |
936 |
|
937 |
HTTP/1.1 401 Unauthorized |
938 |
WWW-Authenticate: Digest |
939 |
realm="testrealm@host.com", |
940 |
qop="auth,auth-int", |
941 |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
942 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
943 |
|
944 |
|
945 |
The client may prompt the user for the username and password, |
946 |
after which it will respond with a new request, including the |
947 |
following Authorization header: |
948 |
|
949 |
Authorization: Digest username="Mufasa", |
950 |
realm="testrealm@host.com", |
951 |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
952 |
uri="/dir/index.html", |
953 |
qop=auth, |
954 |
nc=0001, |
955 |
cnonce="0a4f113b", |
956 |
response="96d2de7d9b47e2a6c0eccb6f7ef3548f", |
957 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
958 |
|
959 |
3.6 Proxy-Authentication and Proxy-Authorization |
960 |
|
961 |
The digest authentication scheme may also be used for |
962 |
authenticating users to proxies, proxies to proxies, or proxies |
963 |
to origin servers by use of the Proxy-Authenticate and Proxy- |
964 |
Authorization headers. These headers are instances of the general |
965 |
Proxy-Authenticate and Proxy-Authorization headers specified in |
966 |
sections 10.30 and 10.31 of the HTTP/1.1 specification [2] and |
967 |
their behavior is subject to restrictions described there. The |
968 |
transactions for proxy authentication are very similar to those |
969 |
already described. Upon receiving a request which requires |
970 |
authentication, the proxy/server must issue the "HTTP/1.1 401 |
971 |
Unauthorized " response with a "Proxy-Authenticate" header. The |
972 |
digest-challenge used in the Proxy-Authenticate header is the |
973 |
|
974 |
Franks, et al. [Page 17]
|
975 |
|
976 |
|
977 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
978 |
|
979 |
same as that for the WWW-Authenticate header as defined above in |
980 |
section 2.1. |
981 |
|
982 |
The client/proxy must then re-issue the request with a Proxy- |
983 |
Authorization header, with attributes as specified for the Authorization |
984 |
header in section TBD above. |
985 |
|
986 |
On subsequent responses, the server sends Proxy-Authentication-Info with |
987 |
attributes the same as those for the Authentication-Info header field. |
988 |
|
989 |
Note that in principle a client could be asked to authenticate |
990 |
itself to both a proxy and an end-server. It might receive an |
991 |
"HTTP/1.1 401 Unauthorized" header followed by both a WWW- |
992 |
Authenticate and a Proxy-Authenticate header. However, it can |
993 |
never receive more than one Proxy-Authenticate header since such |
994 |
headers are only for immediate connections and must not be passed |
995 |
on by proxies. If the client receives both headers, it must |
996 |
respond with both the Authorization and Proxy-Authorization |
997 |
headers as described above, which will likely involve different |
998 |
combinations of username, password, nonce, etc. |
999 |
|
1000 |
|
1001 |
4 Security Considerations |
1002 |
|
1003 |
|
1004 |
4.1 Authentication of Clients using Basic Authentication |
1005 |
|
1006 |
The Basic authentication scheme is not a secure method of user |
1007 |
authentication, nor does it in any way protect the entity, which is |
1008 |
transmitted in cleartext across the physical network used as the |
1009 |
carrier. HTTP does not prevent additional authentication schemes and |
1010 |
encryption mechanisms from being employed to increase security or the |
1011 |
addition of enhancements (such as schemes to use one-time passwords) to |
1012 |
Basic authentication. |
1013 |
|
1014 |
The most serious flaw in Basic authentication is that it results in the |
1015 |
essentially cleartext transmission of the user's password over the |
1016 |
physical network. It is this problem which Digest Authentication |
1017 |
attempts to address. |
1018 |
|
1019 |
Because Basic authentication involves the cleartext transmission of |
1020 |
passwords it SHOULD NOT be used (without enhancements) to protect |
1021 |
sensitive or valuable information. |
1022 |
|
1023 |
A common use of Basic authentication is for identification purposes -- |
1024 |
requiring the user to provide a user name and password as a means of |
1025 |
identification, for example, for purposes of gathering accurate usage |
1026 |
statistics on a server. When used in this way it is tempting to think |
1027 |
that there is no danger in its use if illicit access to the protected |
1028 |
documents is not a major concern. This is only correct if the server |
1029 |
issues both user name and password to the users and in particular does |
1030 |
not allow the user to choose his or her own password. The danger arises |
1031 |
because naive users frequently reuse a single password to avoid the task |
1032 |
of maintaining multiple passwords. |
1033 |
|
1034 |
|
1035 |
Franks, et al. [Page 18]
|
1036 |
|
1037 |
|
1038 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1039 |
|
1040 |
If a server permits users to select their own passwords, then the threat |
1041 |
is not only illicit access to documents on the server but also illicit |
1042 |
access to the accounts of all users who have chosen to use their account |
1043 |
password. If users are allowed to choose their own password that also |
1044 |
means the server must maintain files containing the (presumably |
1045 |
encrypted) passwords. Many of these may be the account passwords of |
1046 |
users perhaps at distant sites. The owner or administrator of such a |
1047 |
system could conceivably incur liability if this information is not |
1048 |
maintained in a secure fashion. |
1049 |
|
1050 |
Basic Authentication is also vulnerable to spoofing by counterfeit |
1051 |
servers. If a user can be led to believe that he is connecting to a host |
1052 |
containing information protected by Basic authentication when, in fact, |
1053 |
he is connecting to a hostile server or gateway, then the attacker can |
1054 |
request a password, store it for later use, and feign an error. This |
1055 |
type of attack is not possible with Digest Authentication. Server |
1056 |
implementers SHOULD guard against the possibility of this sort of |
1057 |
counterfeiting by gateways or CGI scripts. In particular it is very |
1058 |
dangerous for a server to simply turn over a connection to a gateway. |
1059 |
That gateway can then use the persistent connection mechanism to engage |
1060 |
in multiple transactions with the client while impersonating the |
1061 |
original server in a way that is not detectable by the client. |
1062 |
|
1063 |
|
1064 |
4.2 Authentication of Clients using Digest Authentication |
1065 |
|
1066 |
Digest Authentication does not provide a strong authentication |
1067 |
mechanism. That is not its intent. It is intended solely to |
1068 |
replace the much weaker and even more dangerous Basic mechanism. |
1069 |
|
1070 |
Digest Authentication offers no confidentiality protection beyond |
1071 |
protecting the actual password. All of the rest of the request |
1072 |
and response are available to an eavesdropper. |
1073 |
|
1074 |
Digest Authentication offers only limited integrity protection |
1075 |
for the messages in either direction. If qop=auth-int mechanism |
1076 |
is used, those parts of the message used in the calculation of |
1077 |
the WWW-Authenticate and Authorization header field response |
1078 |
attribute values (see section 3.2.2) are protected. Most header |
1079 |
fields and their values could be modified as a part of a man-in- |
1080 |
the-middle attack. |
1081 |
|
1082 |
Many needs for secure HTTP transactions cannot be met by Digest |
1083 |
Authentication. For those needs TLS or SHTTP are more appropriate |
1084 |
protocols. In particular Digest authentication cannot be used for |
1085 |
any transaction requiring confidentiality protection. |
1086 |
Nevertheless many functions remain for which Digest |
1087 |
authentication is both useful and appropriate (any service in |
1088 |
present use that uses Basic should be switched to Digest as soon |
1089 |
as practical). |
1090 |
|
1091 |
|
1092 |
4.3 Limited Use Nonce Values |
1093 |
|
1094 |
The Digest scheme uses a server-specified nonce to seed the generation |
1095 |
of the response-digest value (as specified in section 3.2.2). As shown |
1096 |
Franks, et al. [Page 19]
|
1097 |
|
1098 |
|
1099 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1100 |
|
1101 |
in the example in 3.2.2, the server is free to construct the nonce such |
1102 |
that it may only be used from a particular client, for a particular |
1103 |
resource, for a limited period of time or number of uses, or any other |
1104 |
restrictions. Doing so strengthens the protection provided against, for |
1105 |
example, replay attacks (see 4.5). However, it should be noted that the |
1106 |
method chosen for generating and checking the nonce also has performance |
1107 |
and resource implications. For example, a server may choose to allow |
1108 |
each nonce value to be used only once by maintaining a record of whether |
1109 |
or not each recently issued nonce has been returned and sending a next- |
1110 |
nonce attribute in the Authentication-Info header field of every |
1111 |
response. This protects against even an immediate replay attack, but has |
1112 |
a high cost checking nonce values, and perhaps more important will cause |
1113 |
authentication failures for any pipelined requests (presumably returning |
1114 |
a stale nonce indication). Similarly, incorporating a request-specific |
1115 |
element such as the Etag value for a resource limits the use of the |
1116 |
nonce to that version of the resource and also defeats pipelining. Thus |
1117 |
it may be useful to do so for methods with side effects but have |
1118 |
unacceptable performance for those that do not. |
1119 |
|
1120 |
|
1121 |
4.4 Comparison of Digest with Basic Authentication |
1122 |
|
1123 |
Both Digest and Basic Authentication are very much on the weak |
1124 |
end of the security strength spectrum. But a comparison between |
1125 |
the two points out the utility, even necessity, of replacing |
1126 |
Basic by Digest. |
1127 |
|
1128 |
The greatest threat to the type of transactions for which these |
1129 |
protocols are used is network snooping. This kind of transaction |
1130 |
might involve, for example, online access to a database whose use |
1131 |
is restricted to paying subscribers. With Basic authentication an |
1132 |
eavesdropper can obtain the password of the user. This not only |
1133 |
permits him to access anything in the database, but, often worse, |
1134 |
will permit access to anything else the user protects with the |
1135 |
same password. |
1136 |
|
1137 |
By contrast, with Digest Authentication the eavesdropper only gets |
1138 |
access to the transaction in question and not to the user's password. |
1139 |
The information gained by the eavesdropper would permit a replay attack, |
1140 |
but only with a request for the same document, and even that may be |
1141 |
limited by the servers choice of nonce. |
1142 |
|
1143 |
|
1144 |
4.5 Replay Attacks |
1145 |
|
1146 |
A replay attack against Digest authentication would usually be |
1147 |
pointless for a simple GET request since an eavesdropper would |
1148 |
already have seen the only document he could obtain with a |
1149 |
replay. This is because the URI of the requested document is |
1150 |
digested in the client request and the server will only deliver |
1151 |
that document. By contrast under Basic Authentication once the |
1152 |
eavesdropper has the user's password, any document protected by |
1153 |
that password is open to him. |
1154 |
|
1155 |
Thus, for some purposes, it is necessary to protect against |
1156 |
replay attacks. A good Digest implementation can do this in |
1157 |
Franks, et al. [Page 20]
|
1158 |
|
1159 |
|
1160 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1161 |
|
1162 |
various ways. The server created "nonce" value is implementation |
1163 |
dependent, but if it contains a digest of the client IP, a time- |
1164 |
stamp, the resource ETag, and a private server key (as |
1165 |
recommended above) then a replay attack is not simple. An |
1166 |
attacker must convince the server that the request is coming from |
1167 |
a false IP address and must cause the server to deliver the |
1168 |
document to an IP address different from the address to which it |
1169 |
believes it is sending the document. An attack can only succeed |
1170 |
in the period before the time-stamp expires. Digesting the client |
1171 |
IP and time-stamp in the nonce permits an implementation which |
1172 |
does not maintain state between transactions. |
1173 |
|
1174 |
For applications where no possibility of replay attack can be |
1175 |
tolerated the server can use one-time nonce values which will not |
1176 |
be honored for a second use. This requires the overhead of the |
1177 |
server remembering which nonce values have been used until the |
1178 |
nonce time-stamp (and hence the digest built with it) has |
1179 |
expired, but it effectively protects against replay attacks. |
1180 |
|
1181 |
An implementation must give special attention to the possibility |
1182 |
of replay attacks with POST and PUT requests. Unless the server |
1183 |
employs one-time or otherwise limited-use nonces and/or insists |
1184 |
on the use of the integrity protection of qop=auth-int, an |
1185 |
attacker could replay valid credentials from a successful request |
1186 |
with counterfeit form data or other message body. Even with the |
1187 |
use of integrity protection most metadata in header fields is |
1188 |
not protected. Proper nonce generation and checking provides some |
1189 |
protection against replay of previously used valid credentials, |
1190 |
but see 4.8. |
1191 |
|
1192 |
|
1193 |
4.6 Weakness Created by Multiple Authentication Schemes |
1194 |
|
1195 |
An HTTP/1.1 server may return multiple challenges with a 401 |
1196 |
(Authenticate) response, and each challenge may use a different scheme. |
1197 |
The order of the challenges returned to the user agent is the order that |
1198 |
the server would prefer they be chosen. The server should order its |
1199 |
challenges with the "most secure" authentication scheme first. A user |
1200 |
agent should choose to use the first challenge it understands and |
1201 |
request credentials from the user based upon that challenge. |
1202 |
|
1203 |
When the server offers choices of authentication schemes using the WWW- |
1204 |
Authenticate header, the strength of the resulting authentication is |
1205 |
only as good as that of the of the weakest of the authentication |
1206 |
schemes. See section 4.8 below for discussion of particular attack |
1207 |
scenarios which exploit multiple authentication schemes. Thus, the |
1208 |
ordering serves more to protect the user's credentials than the server's |
1209 |
information. |
1210 |
|
1211 |
|
1212 |
4.7 Online dictionary attacks |
1213 |
|
1214 |
If the attacker can eavesdrop, then it can test any overheard |
1215 |
nonce/response pairs against a list of common words. Such a list is |
1216 |
usually much smaller than the total number of possible passwords. The |
1217 |
|
1218 |
Franks, et al. [Page 21]
|
1219 |
|
1220 |
|
1221 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1222 |
|
1223 |
cost of computing the response for each password on the list is paid |
1224 |
once for each challenge. |
1225 |
|
1226 |
This attack can be mitigated by checking the password against a |
1227 |
dictionary when a user tries to change it and disallowing passwords that |
1228 |
are in the dictionary. |
1229 |
|
1230 |
|
1231 |
4.8 Man in the Middle |
1232 |
|
1233 |
Both Basic and Digest authentication are vulnerable to "man in the |
1234 |
middle" (MITM) attacks, for example, from a hostile or compromised |
1235 |
proxy. Clearly, this would present all the problems of eavesdropping. |
1236 |
But it also offers some additional opportunities to the attacker. |
1237 |
|
1238 |
A possible man-in-the-middle attack would be to add a weak |
1239 |
authentication scheme to the set of choices, hoping that the client will |
1240 |
use one that exposes the user's credentials (e.g. password). For this |
1241 |
reason, the client should always use the strongest scheme that it |
1242 |
understands from the choices offered. |
1243 |
|
1244 |
An even better MITM attack would be to remove all offered choices, |
1245 |
replacing them with a challenge that requests only Basic authentication, |
1246 |
then uses the cleartext credentials from the Basic authentication to |
1247 |
authenticate to the origin server using the stronger scheme it |
1248 |
requested. A particularly insidious way to mount such a MITM attack |
1249 |
would be to offer a "free" proxy caching service to gullible users. |
1250 |
|
1251 |
User agents should consider measures such as presenting a visual |
1252 |
indication at the time of the credentials request of what authentication |
1253 |
scheme is to be used, or remembering the strongest authentication scheme |
1254 |
ever requested by a server and produce a warning message before using a |
1255 |
weaker one. It might also be a good idea for the user agent to be |
1256 |
configured to demand Digest authentication in general, or from specific |
1257 |
sites. |
1258 |
|
1259 |
Or, a hostile proxy might spoof the client into making a request the |
1260 |
attacker wanted rather than one the client wanted. Of course, this is |
1261 |
still much harder than a comparable attack against Basic Authentication. |
1262 |
|
1263 |
|
1264 |
4.9 Chosen plaintext attacks |
1265 |
|
1266 |
With Digest authentication, a MITM or a malicious server can arbitrarily |
1267 |
choose the nonce that the client will use to compute the response. This |
1268 |
is called a "chosen plaintext" attack. The ability to choose the nonce |
1269 |
is known to make cryptanalysis much easier [8]. |
1270 |
|
1271 |
However, no way to analyze the MD5 one-way function used by Digest using |
1272 |
chosen plaintext is currently known. |
1273 |
|
1274 |
The countermeasure against this attack is to for clients to be |
1275 |
configured to require the use of the optional "cnonce" directive; this |
1276 |
allows the client to vary the input to the hash in a way not chosen by |
1277 |
the attacker. |
1278 |
|
1279 |
Franks, et al. [Page 22]
|
1280 |
|
1281 |
|
1282 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1283 |
|
1284 |
4.10 Precomputed dictionary attacks |
1285 |
|
1286 |
With Digest authentication, if the attacker can execute a chosen |
1287 |
plaintext attack, the attacker can precompute the response for many |
1288 |
common words to a nonce of its choice, and store a dictionary of |
1289 |
(response, password) pairs. Such precomputation can often be done in |
1290 |
parallel on many machines. It can then use the chosen plaintext attack |
1291 |
to acquire a response corresponding to that challenge, and just look up |
1292 |
the password in the dictionary. Even if most passwords are not in the |
1293 |
dictionary, some might be. Since the attacker gets to pick the |
1294 |
challenge, the cost of computing the response for each password on the |
1295 |
list can be amortized over finding many passwords. A dictionary with 100 |
1296 |
million password/response pairs would take about 3.2 gigabytes of disk |
1297 |
storage. |
1298 |
|
1299 |
The countermeasure against this attack is to for clients to be |
1300 |
configured to require the use of the optional "cnonce" directive. |
1301 |
|
1302 |
|
1303 |
4.11 Batch brute force attacks |
1304 |
|
1305 |
With Digest authentication, a MITM can execute a chosen plaintext |
1306 |
attack, and can gather responses from many users to the same nonce. It |
1307 |
can then find all the passwords within any subset of password space that |
1308 |
would generate one of the nonce/response pairs in a single pass over |
1309 |
that space. It also reduces the time to find the first password by a |
1310 |
factor equal to the number of nonce/response pairs gathered. This search |
1311 |
of the password space can often be done in parallel on many machines, |
1312 |
and even a single machine can search large subsets of the password space |
1313 |
very quickly _ reports exist of searching all passwords with six or |
1314 |
fewer letters in a few hours. |
1315 |
|
1316 |
The countermeasure against this attack is to for clients to be |
1317 |
configured to require the use of the optional "cnonce" directive. |
1318 |
|
1319 |
|
1320 |
4.12 Spoofing by Counterfeit Servers |
1321 |
|
1322 |
Basic Authentication is vulnerable to spoofing by counterfeit servers. |
1323 |
If a user can be led to believe that she is connecting to a host |
1324 |
containing information protected by a password she knows, when in fact |
1325 |
she is connecting to a hostile server, then the hostile server can |
1326 |
request a password, store it away for later use, and feign an error. |
1327 |
This type of attack is more difficult with Digest Authentication -- but |
1328 |
the client must know to demand that Digest authentication be used, |
1329 |
perhaps using some of the techniques described above to counter "man-in- |
1330 |
the-middle" attacks. Again, the user can be helped in detecting this |
1331 |
attack by a visual indication of the authentication mechanism in use |
1332 |
with appropriate guidance in interpreting the implications of each |
1333 |
scheme. |
1334 |
|
1335 |
|
1336 |
4.13 Storing passwords |
1337 |
|
1338 |
Digest authentication requires that the authenticating agent (usually |
1339 |
the server) store some data derived from the user's name and password in |
1340 |
Franks, et al. [Page 23]
|
1341 |
|
1342 |
|
1343 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1344 |
|
1345 |
a "password file" associated with a given realm. Normally this might |
1346 |
contain pairs consisting of username and H(A1), where H(A1) is the |
1347 |
digested value of the username, realm, and password as described above. |
1348 |
|
1349 |
The security implications of this are that if this password file is |
1350 |
compromised, then an attacker gains immediate access to documents on the |
1351 |
server using this realm. Unlike, say a standard UNIX password file, this |
1352 |
information need not be decrypted in order to access documents in the |
1353 |
server realm associated with this file. On the other hand, decryption, |
1354 |
or more likely a brute force attack, would be necessary to obtain the |
1355 |
user's password. This is the reason that the realm is part of the |
1356 |
digested data stored in the password file. It means that if one Digest |
1357 |
authentication password file is compromised, it does not automatically |
1358 |
compromise others with the same username and password (though it does |
1359 |
expose them to brute force attack). |
1360 |
|
1361 |
There are two important security consequences of this. First the |
1362 |
password file must be protected as if it contained unencrypted |
1363 |
passwords, because for the purpose of accessing documents in its realm, |
1364 |
it effectively does. |
1365 |
|
1366 |
A second consequence of this is that the realm string should be unique |
1367 |
among all realms which any single user is likely to use. In particular a |
1368 |
realm string should include the name of the host doing the |
1369 |
authentication. The inability of the client to authenticate the server |
1370 |
is a weakness of Digest Authentication. |
1371 |
|
1372 |
|
1373 |
4.14 Summary |
1374 |
|
1375 |
By modern cryptographic standards Digest Authentication is weak. But for |
1376 |
a large range of purposes it is valuable as a replacement for Basic |
1377 |
Authentication. It remedies some, but not all, weaknesses of Basic |
1378 |
Authentication. Its strength may vary depending on the implementation. |
1379 |
In particular the structure of the nonce (which is dependent on the |
1380 |
server implementation) may affect the ease of mounting a replay attack. |
1381 |
A range of server options is appropriate since, for example, some |
1382 |
implementations may be willing to accept the server overhead of one-time |
1383 |
nonces or digests to eliminate the possibility of replay. Others may |
1384 |
satisfied with a nonce like the one recommended above restricted to a |
1385 |
single IP address and a single ETag or with a limited lifetime. |
1386 |
|
1387 |
The bottom line is that *any* compliant implementation will be |
1388 |
relatively weak by cryptographic standards, but *any* compliant |
1389 |
implementation will be far superior to Basic Authentication. |
1390 |
|
1391 |
|
1392 |
5 Acknowledgments |
1393 |
|
1394 |
In addition to the authors, valuable discussion instrumental in creating |
1395 |
this document has come from Peter J. Churchyard, Ned Freed, and David M. |
1396 |
Kristol. |
1397 |
|
1398 |
Jim Gettys and Larry Masinter edited this document for its update. |
1399 |
|
1400 |
|
1401 |
Franks, et al. [Page 24]
|
1402 |
|
1403 |
|
1404 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1405 |
|
1406 |
6 References |
1407 |
|
1408 |
[1] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer |
1409 |
Protocol -- HTTP/1.0", RFC 1945, May 1996. |
1410 |
|
1411 |
[2] Fielding, R., Gettys, J., Mogul, J. C., Frysyk, H, Berners-Lee, |
1412 |
T., " Hypertext Transfer Protocol -- HTTP/1.1", Work In Progress of |
1413 |
the HTTP working group, November 1997. |
1414 |
|
1415 |
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April |
1416 |
1992. |
1417 |
|
1418 |
|
1419 |
[4] Freed, N., and N. Borenstein. "Multipurpose Internet Mail |
1420 |
Extensions (MIME) Part One: Format of Internet Message Bodies." RFC |
1421 |
2045, Innosoft, First Virtual, November 1996. |
1422 |
|
1423 |
|
1424 |
[5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0," Work In |
1425 |
Progress of the TLS working group, November, 1997. |
1426 |
|
1427 |
|
1428 |
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, |
1429 |
A., Sink, E., Stewart, L.,"An Extension to HTTP : Digest Access |
1430 |
Authentication." RFC 2069, January, 1997. |
1431 |
|
1432 |
[7] Berners Lee, T, Fielding, R., Masinter, L., "Uniform Resource |
1433 |
Identifiers (URI): Generic Syntax and Semantics," Work in Progress, |
1434 |
November, 1997. |
1435 |
|
1436 |
[8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", |
1437 |
CryptoBytes, Sping 1995, RSA Inc, |
1438 |
(http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) |
1439 |
|
1440 |
|
1441 |
|
1442 |
|
1443 |
7 Authors' Addresses |
1444 |
|
1445 |
John Franks |
1446 |
Professor of Mathematics |
1447 |
Department of Mathematics |
1448 |
Northwestern University |
1449 |
Evanston, IL 60208-2730, USA |
1450 |
|
1451 |
EMail: john@math.nwu.edu |
1452 |
|
1453 |
Phillip M. Hallam-Baker |
1454 |
Principal Consultant |
1455 |
Verisign Inc. |
1456 |
One Alewife Center |
1457 |
Cambridge, MA 02138, USA |
1458 |
|
1459 |
EMail: pbaker@verisign.com |
1460 |
|
1461 |
|
1462 |
Franks, et al. [Page 25]
|
1463 |
|
1464 |
|
1465 |
INTERNET-DRAFT HTTP Authentication Friday 13 March 1998 |
1466 |
|
1467 |
Jeffery L. Hostetler |
1468 |
Senior Software Engineer |
1469 |
Spyglass, Inc. |
1470 |
3200 Farber Drive |
1471 |
Champaign, IL 61821, USA |
1472 |
|
1473 |
EMail: jeff@spyglass.com |
1474 |
|
1475 |
Paul J. Leach |
1476 |
Microsoft Corporation |
1477 |
1 Microsoft Way |
1478 |
Redmond, WA 98052, USA |
1479 |
|
1480 |
EMail: paulle@microsoft.com |
1481 |
|
1482 |
Ari Luotonen |
1483 |
Member of Technical Staff |
1484 |
Netscape Communications Corporation |
1485 |
501 East Middlefield Road |
1486 |
Mountain View, CA 94043, USA |
1487 |
|
1488 |
EMail: luotonen@netscape.com |
1489 |
|
1490 |
Eric W. Sink |
1491 |
Senior Software Engineer |
1492 |
Spyglass, Inc. |
1493 |
3200 Farber Drive |
1494 |
Champaign, IL 61821, USA |
1495 |
|
1496 |
EMail: eric@spyglass.com |
1497 |
|
1498 |
Lawrence C. Stewart |
1499 |
Open Market, Inc. |
1500 |
215 First Street |
1501 |
Cambridge, MA 02142, USA |
1502 |
|
1503 |
EMail: stewart@OpenMarket.com |
1504 |
|
1505 |
Scott D. Lawrence |
1506 |
Agranat Systems, Inc. |
1507 |
1345 Main St. |
1508 |
Waltham, MA 02154, USA |
1509 |
|
1510 |
EMail: stewart@OpenMarket.com |
1511 |
|
1512 |
|
1513 |
|
1514 |
|
1515 |
|
1516 |
|
1517 |
|
1518 |
|
1519 |
|
1520 |
|
1521 |
|
1522 |
|
1523 |
Franks, et al. [Page 26] |