1 |
|
2 |
HTTP Working Group John Franks |
3 |
INTERNET-DRAFT Philip Hallam-Baker |
4 |
<draft-ietf-http-digest-aa-04.txt> Jeffery L. Hostetler |
5 |
Paul Leach |
6 |
Ari Luotonen |
7 |
Eric W. Sink |
8 |
Lawrence C. Stewart |
9 |
|
10 |
Expires SIX MONTHS FROM---> June 6, 1996 |
11 |
|
12 |
|
13 |
A Proposed Extension to HTTP : Digest Access Authentication |
14 |
|
15 |
|
16 |
Status of this Memo |
17 |
|
18 |
This document is an Internet-Draft. Internet-Drafts are working |
19 |
documents of the Internet Engineering Task Force (IETF), its areas, |
20 |
and its working groups. Note that other groups may also distribute |
21 |
working documents as Internet-Drafts. |
22 |
|
23 |
Internet-Drafts are draft documents valid for a maximum of six months |
24 |
and may be updated, replaced, or obsoleted by other documents at any |
25 |
time. It is inappropriate to use Internet-Drafts as reference |
26 |
material or to cite them other than as "work in progress." |
27 |
|
28 |
To learn the current status of any Internet-Draft, please check the |
29 |
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |
30 |
Directories on ds.internic.net (US East Coast), nic.nordu.net |
31 |
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific |
32 |
Rim). |
33 |
|
34 |
Distribution of this document is unlimited. Please send comments to |
35 |
the HTTP working group at <http-wg@cuckoo.hpl.hp.com>. |
36 |
Discussions of the working group are archived at |
37 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions |
38 |
about HTTP and the applications which use HTTP should take place on |
39 |
the <www-talk@www10.w3.org> mailing list. |
40 |
|
41 |
|
42 |
Abstract |
43 |
|
44 |
The protocol referred to as "HTTP/1.0" includes specification for a |
45 |
Basic Access Authentication scheme. This scheme is not considered to |
46 |
be a secure method of user authentication, as the user name and |
47 |
password are passed over the network in an unencrypted form. A |
48 |
specification for a new authentication scheme is needed for future |
49 |
versions of the HTTP protocol. This document provides specification |
50 |
for such a scheme, referred to as "Digest Access Authentication". |
51 |
The digesting method used by default is the RSA Data Security, Inc. |
52 |
MD5 Message-Digest Algorithm [3]. |
53 |
|
54 |
|
55 |
|
56 |
|
57 |
Table of Contents |
58 |
|
59 |
STATUS OF THIS MEMO.................................................... |
60 |
|
61 |
|
62 |
ABSTRACT............................................................... |
63 |
|
64 |
|
65 |
TABLE OF CONTENTS...................................................... |
66 |
|
67 |
|
68 |
INTRODUCTION........................................................... |
69 |
|
70 |
1.1 PURPOSE ......................................................... |
71 |
1.2 OVERALL OPERATION ............................................... |
72 |
1.3 REPRESENTATION OF DIGEST VALUES ................................. |
73 |
1.4 LIMITATIONS ..................................................... |
74 |
|
75 |
2. DIGEST ACCESS AUTHENTICATION SCHEME................................. |
76 |
|
77 |
2.1 SPECIFICATION OF DIGEST HEADERS .................................. |
78 |
2.1.1 THE WWW-AUTHENTICATE RESPONSE HEADER .......................... |
79 |
2.1.2 THE AUTHORIZATION REQUEST HEADER .............................. |
80 |
2.1.3 THE AUTHENTICATION-INFO HEADER ................................ |
81 |
2.2 DIGEST OPERATION ................................................. |
82 |
2.3 SECURITY PROTOCOL NEGOTIATION .................................... |
83 |
2.4 EXAMPLE .......................................................... |
84 |
2.5 PROXY-AUTHENTICATION AND PROXY-AUTHORIZATION ..................... |
85 |
|
86 |
3. SECURITY CONSIDERATIONS............................................ |
87 |
|
88 |
3.1 COMPARISON WITH BASIC AUTHENTICATION ............................ |
89 |
3.2 REPLAY ATTACKS .................................................. |
90 |
3.3 MAN IN THE MIDDLE ............................................... |
91 |
3.4 SPOOFING BY COUNTERFEIT SERVERS ................................. |
92 |
3.5 STORING PASSWORDS ............................................... |
93 |
3.6 SUMMARY ......................................................... |
94 |
|
95 |
4. ACKNOWLEDGMENTS................................................... |
96 |
|
97 |
|
98 |
5. REFERENCES......................................................... |
99 |
|
100 |
|
101 |
6. AUTHORS ADDRESSES.................................................. |
102 |
|
103 |
|
104 |
|
105 |
Introduction |
106 |
|
107 |
|
108 |
1.1 Purpose |
109 |
|
110 |
The protocol referred to as "HTTP/1.0" includes specification for a |
111 |
Basic Access Authentication scheme[1]. This scheme is not considered |
112 |
to be a secure method of user authentication, as the user name and |
113 |
password are passed over the network in an unencrypted form. A |
114 |
specification for a new authentication scheme is needed for future |
115 |
versions of the HTTP protocol. This document provides specification |
116 |
for such a scheme, referred to as "Digest Access Authentication". |
117 |
|
118 |
The Digest Access Authentication scheme is not intended to be a |
119 |
complete answer to the need for security in the World Wide Web. This |
120 |
scheme provides no encryption of object content. The intent is |
121 |
simply to facilitate secure access authentication. |
122 |
|
123 |
It is proposed that this access authentication scheme be included in |
124 |
the proposed HTTP/1.1 specification. |
125 |
|
126 |
|
127 |
1.2 Overall Operation |
128 |
|
129 |
Like Basic Access Authentication, the Digest scheme is based on a |
130 |
simple challenge-response paradigm. The Digest scheme challenges |
131 |
using a nonce value. A valid response contains a checksum (by |
132 |
default the MD5 checksum) of the username, the password, the given |
133 |
|
134 |
nonce value, the HTTP method, and the requested URI. In this way, the |
135 |
password is never sent in the clear. Just as with the Basic scheme, |
136 |
the username and password must be prearranged in some fashion which is |
137 |
not addressed by this document. |
138 |
|
139 |
|
140 |
1.3 Representation of digest values |
141 |
|
142 |
An optional header allows the server to specify the algorithm used to |
143 |
create the checksum or digest. By default the MD5 algorithm is used |
144 |
and that is the only algorithm described in this document. |
145 |
|
146 |
For the purposes of this document, an MD5 digest of 128 bits is |
147 |
represented as 32 ASCII printable characters. The bits in the 128 |
148 |
bit digest are converted from most significant to least significant |
149 |
bit, four bits at a time to their ASCII presentation as follows. |
150 |
Each four bits is represented by its familiar hexadecimal notation |
151 |
from the characters 0123456789abcdef. That is, binary 0000 gets |
152 |
represented by the character '0', 0001, by '1', and so on up to the |
153 |
representation of 1111 as 'f'. |
154 |
|
155 |
|
156 |
1.4 Limitations |
157 |
|
158 |
The digest authentication scheme described in this document suffers |
159 |
from many known limitations. It is intended as a replacement for |
160 |
basic authentication and nothing more. It is a password-based system |
161 |
and (on the server side) suffers from all the same problems of any |
162 |
password system. In particular, no provision is made in this protocol |
163 |
for the initial secure arrangement between user and server to |
164 |
establish the user's password. |
165 |
|
166 |
Users and implementors should be aware that this protocol is not as |
167 |
secure as kerberos, and not as secure as any client-side private-key |
168 |
scheme. Nevertheless it is better than nothing, better than what is |
169 |
commonly used with telnet and ftp, and better than Basic |
170 |
authentication. |
171 |
|
172 |
Some keyword-value pairs occurring in headers described below are |
173 |
required to have values which are of the type "quoted-string" as |
174 |
defined in section 2.2 of the HTTP/1.1 specification [2]. A |
175 |
consequence is that these values represent strings in the US-ASCII |
176 |
character set. An unfortunate side effect of this is that digest |
177 |
authentication is not capable of handling either user names or realm |
178 |
names (see 2.1.1 below) which are not expressed in this character set. |
179 |
|
180 |
|
181 |
|
182 |
2. Digest Access Authentication Scheme |
183 |
|
184 |
|
185 |
2.1 Specification of Digest Headers |
186 |
|
187 |
The Digest Access Authentication scheme is conceptually similar to |
188 |
the Basic scheme. The formats of the modified WWW-Authenticate |
189 |
header line and the Authorization header line are specified below, |
190 |
using the extended BNF defined in the HTTP/1.1 specification, section |
191 |
2.1. In addition, a new header, Authentication-info, is specified. |
192 |
|
193 |
|
194 |
|
195 |
2.1.1 The WWW-Authenticate Response Header |
196 |
|
197 |
If a server receives a request for an access-protected object, and an |
198 |
acceptable Authorization header is not sent, the server responds with |
199 |
a "401 Unauthorized" status code, and a WWW-Authenticate header, |
200 |
which is defined as follows: |
201 |
|
202 |
WWW-Authenticate = "WWW-Authenticate" ":" "Digest" |
203 |
digest-challenge |
204 |
|
205 |
digest-challenge = 1#( realm | [ domain ] | nonce | |
206 |
[ digest-opaque ] |[ stale ] | [ algorithm ] ) |
207 |
|
208 |
realm = "realm" "=" realm-value |
209 |
realm-value = quoted-string |
210 |
domain = "domain" "=" <"> 1#URI <"> |
211 |
nonce = "nonce" "=" nonce-value |
212 |
nonce-value = quoted-string |
213 |
opaque = "opaque" "=" quoted-string |
214 |
stale = "stale" "=" ( "true" | "false" ) |
215 |
algorithm = "algorithm" "=" ( "MD5" | token ) |
216 |
|
217 |
The meanings of the values of the parameters used above are as |
218 |
follows: |
219 |
|
220 |
realm |
221 |
A string to be displayed to users so they know which username and |
222 |
password to use. This string should contain at least the name of |
223 |
the host performing the authentication and might additionally |
224 |
indicate the collection of users who might have access. An example |
225 |
might be "registered_users@gotham.news.com". The realm is a |
226 |
"quoted-string" as specified in section 2.2 of the HTTP/1.1 |
227 |
specification [2]. |
228 |
|
229 |
domain |
230 |
A comma-separated list of URIs, as specified for HTTP/1.0. The |
231 |
intent is that the client could use this information to know the |
232 |
set of URIs for which the same authentication information should be |
233 |
sent. The URIs in this list may exist on different servers. If |
234 |
this keyword is omitted or empty, the client should assume that the |
235 |
domain consists of all URIs on the responding server. |
236 |
|
237 |
nonce |
238 |
A server-specified data string which may be uniquely generated each |
239 |
time a 401 response is made. It is recommended that this string be |
240 |
base64 or hexadecimal data. Specifically, since the string is |
241 |
passed in the header lines as a quoted string, the double-quote |
242 |
character is not allowed. |
243 |
|
244 |
The contents of the nonce are implementation dependent. The |
245 |
quality of the implementation depends on a good choice. A |
246 |
recommended nonce would include |
247 |
|
248 |
H(client-IP ":" time-stamp ":" private-key ) |
249 |
|
250 |
Where client-IP is the dotted quad IP address of the client making |
251 |
the request, time-stamp is a server-generated time value, private- |
252 |
key is data known only to the server. With a nonce of this form a |
253 |
server would normally recalculate the nonce after receiving the |
254 |
client authentication header and reject the request if it did not |
255 |
match the nonce from that header. In this way the server can limit |
256 |
the reuse of a nonce to the IP address to which it was issued and |
257 |
limit the time of the nonce's validity. Further discussion of the |
258 |
rationale for nonce construction is in section 3.2 below. |
259 |
|
260 |
An implementation might choose not to accept a previously used |
261 |
nonce or a previously used digest to protect against a replay |
262 |
attack. Or, an implementation might choose to use one-time nonces |
263 |
or digests for POST or PUT requests and a time-stamp for GET |
264 |
requests. For more details on the issues involved see section 3. |
265 |
of this document. |
266 |
|
267 |
The nonce is opaque to the client. |
268 |
|
269 |
opaque |
270 |
A string of data, specified by the server, which should be returned by |
271 |
the client unchanged. It is recommended that this string be base64 |
272 |
or hexadecimal data. This field is a "quoted-string" as specified |
273 |
in section 2.2 of the HTTP/1.1 specification [2]. |
274 |
|
275 |
stale |
276 |
A flag, indicating that the previous request from the client was |
277 |
rejected because the nonce value was stale. If stale is TRUE (in |
278 |
upper or lower case), the client may wish to simply retry the |
279 |
request with a new encrypted response, without reprompting the user |
280 |
for a new username and password. The server should only set stale |
281 |
to true if it receives a request for which the nonce is invalid but |
282 |
with a valid digest for that nonce (indicating that the client knows |
283 |
the correct username/password). |
284 |
|
285 |
algorithm |
286 |
|
287 |
A string indicating a pair of algorithms used to produce the digest |
288 |
and a checksum. If this not present it is assumed to be "MD5". In |
289 |
this document the string obtained by applying the digest algorithm to |
290 |
the data "data" with secret "secret" will be denoted by KD(secret, |
291 |
data), and the string obtained by applying the checksum algorithm to |
292 |
the data "data" will be denoted H(data). |
293 |
|
294 |
For the "MD5" algorithm |
295 |
|
296 |
H(data) = MD5(data) |
297 |
|
298 |
and |
299 |
|
300 |
KD(secret, data) = H(concat(secret, ":", data)) |
301 |
|
302 |
i.e., the digest is the MD5 of the secret concatenated with a colon |
303 |
concatenated with the data. |
304 |
|
305 |
|
306 |
|
307 |
|
308 |
|
309 |
2.1.2 The Authorization Request Header |
310 |
|
311 |
The client is expected to retry the request, passing an Authorization |
312 |
header line, which is defined as follows. |
313 |
|
314 |
Authorization = "Authorization" ":" "Digest" digest-response |
315 |
|
316 |
digest-response = 1#( username | realm | nonce | digest-uri | |
317 |
response | [ digest ] | [ algorithm ] | |
318 |
opaque ) |
319 |
|
320 |
username = "username" "=" username-value |
321 |
username-value = quoted-string |
322 |
digest-uri = "uri" "=" digest-uri-value |
323 |
digest-uri-value = request-uri ; As specified by HTTP/1.1 |
324 |
response = "response" "=" response-digest |
325 |
digest = "digest" "=" entity-digest |
326 |
|
327 |
response-digest = <"> *LHEX <"> |
328 |
entity-digest = <"> *LHEX <"> |
329 |
LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | |
330 |
"8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" |
331 |
|
332 |
|
333 |
The definitions of response-digest and entity-digest above indicate |
334 |
the encoding for their values. The following definitions show how the value |
335 |
is computed: |
336 |
|
337 |
response-digest = |
338 |
<"> < KD ( H(A1), unquoted nonce-value ":" H(A2) > <"> |
339 |
|
340 |
A1 = unquoted username-value ":" unquoted realm-value |
341 |
":" password |
342 |
password = < user's password > |
343 |
A2 = Method ":" digest-uri-value |
344 |
|
345 |
|
346 |
|
347 |
The "username-value" field is a "quoted-string" as specified in section |
348 |
2.2 of the HTTP/1.1 specification [2]. However, the surrounding quotation |
349 |
marks are removed in forming the string A1. Thus if the Authorization |
350 |
header includes the fields |
351 |
|
352 |
username="Mufasa", realm="myhost@testrealm.com" |
353 |
|
354 |
and the user Mufasa has password "CircleOfLife" then H(A1) would be |
355 |
H(Mufasa:myhost@testrealm.com:CircleOfLife) with no quotation marks in |
356 |
the digested string. |
357 |
|
358 |
No white space is allowed in any of the strings to which the digest |
359 |
function H() is applied unless that white space exists in the quoted |
360 |
strings or entity body whose contents make up the string to be |
361 |
digested. For example, the string A1 in the illustrated above must be |
362 |
Mufasa:myhost@testrealm.com:CircleOfLife with no white space on either |
363 |
side of the colons. Likewise, the other strings digested by H() must |
364 |
not have white space on either side of the colons which delimit their |
365 |
fields unless that white space was in the quoted strings or entity |
366 |
body being digested. |
367 |
|
368 |
"Method" is the HTTP request method as specified in section 5.1 of |
369 |
[2]. The "request-uri" value is the Request-URI from the request line |
370 |
as specified in section 5.1 of [2]. This may be "*", an "absoluteURL" |
371 |
or an "abs_path" as specified in section 5.1.2 of [2], but it MUST |
372 |
agree with the Request-URI. In particular, it MUST be an "absoluteURL" |
373 |
if the Request-URI is an "absoluteURL". |
374 |
|
375 |
The authenticating server must assure that the document designated |
376 |
by the "uri" parameter is the same as the document served. The |
377 |
purpose of duplicating information from the request URL in this |
378 |
field is to deal with the possibility that an intermediate proxy may |
379 |
alter the client's request. This altered (but presumably semantically |
380 |
equivalent) request would not result in the same digest as that |
381 |
calculated by the client. |
382 |
|
383 |
The optional "digest" field contains a digest of the entity body and |
384 |
some of the associated entity headers. This digest can be useful in |
385 |
both request and response transactions. In a request it can insure the |
386 |
integrity of POST data or data being PUT to the server. In a response |
387 |
it insures the integrity of the served document. The value of the |
388 |
"digest" field is an <entity-digest> which is defined as follows. |
389 |
|
390 |
entity-digest = <"> KD (H(A1), unquoted nonce-value ":" Method ":" |
391 |
date ":" entity-info ":" H(entity-body)) <"> |
392 |
; format is <"> *LHEX <"> |
393 |
|
394 |
date = = rfc1123-date ; see section 3.3.1 of [2] |
395 |
entity-info = H( |
396 |
digest-uri-value ":" |
397 |
media-type ":" ; Content-type, see section 3.7 of [2] |
398 |
*DIGIT ":" ; Content length, see 10.12 of [2] |
399 |
content-coding ":" ; Content-encoding, see 3.5 of [2] |
400 |
last-modified ":" ; last modified date, see 10.25 of [2] |
401 |
expires ; expiration date; see 10.19 of [2] |
402 |
) |
403 |
|
404 |
last-modified = rfc1123-date ; see section 3.3.1 of [2] |
405 |
expires = rfc1123-date |
406 |
|
407 |
|
408 |
The entity-info elements incorporate the values of the URI used to |
409 |
request the entity as well as the associated entity headers |
410 |
Content-type, Content-length, Content-encoding, Last-modified, and |
411 |
Expires. These headers are all end-to-end headers (see section TBS of [2]) |
412 |
which must not be modified by proxy caches. The "entity-body" is as |
413 |
specified by section 10.13 of [2] or RFC 1864. |
414 |
|
415 |
Note that not all entities will have an associated URI or all of |
416 |
these headers. For example, an entity which is the data of a |
417 |
POST request will typically not have a digest-uri-value or |
418 |
Last-modified or Expires headers. If an entity does not have a |
419 |
digest-uri-value or a header corresponding to one of the entity-info |
420 |
fields, then that field is left empty in the computation of |
421 |
entity-info. All the colons specified above are present, however. |
422 |
For example the value of the entity-info associated with POST data |
423 |
which has content-type "text/plain", no content-encoding and a length |
424 |
of 255 bytes would be H(:text/plain:255:::). Similarly a request may |
425 |
not have a "Date" header. In this case the date field of the |
426 |
entity-digest should be empty. |
427 |
|
428 |
In the entity-info and entity-digest computations, except for the |
429 |
blank after the comma in "rfc1123-date", there must be no white space |
430 |
between "words" and "tspecials", and exactly one blank between "words" |
431 |
(see section 2.2 of [2]). |
432 |
|
433 |
Implementors should be aware of how authenticated transactions |
434 |
interact with proxy caches. The HTTP/1.1 protocol specifies that when |
435 |
a shared cache (see section 13.10 of [2]) has received a request |
436 |
containing an Authorization header and a response from relaying that |
437 |
request, it MUST NOT return that response as a reply to any other |
438 |
request, unless one of two Cache-control (see TBS) directives was |
439 |
present in the response. If the original response included the |
440 |
``must-revalidate'' Cache-control directive, the cache MAY use the |
441 |
entity of that response in replying to a subsequent request, but MUST |
442 |
first revalidate it with the origin server, using the request headers |
443 |
from the new request to allow the origin server to authenticate the |
444 |
new request. Alternatively, if the original response included the |
445 |
``public'' Cache-control directive, the response entity MAY be |
446 |
returned in reply to any subsequent request. |
447 |
|
448 |
|
449 |
|
450 |
2.1.3 The AuthenticationInfo Header |
451 |
|
452 |
When authentication succeeds, the Server may optionally provide a |
453 |
Authentication-info header indicating that the server wants to |
454 |
communicate some information regarding the successful authentication |
455 |
(such as an entity digest or a new nonce to be used for the next |
456 |
transaction). It has two fields, digest and nextnonce. Both |
457 |
are optional. |
458 |
|
459 |
|
460 |
AuthenticationInfo = "Authentication-info" ":" |
461 |
1#( digest | nextnonce ) |
462 |
|
463 |
nextnonce = "nextnonce" "=" nonce-value |
464 |
|
465 |
digest = "digest" "=" entity-digest |
466 |
|
467 |
|
468 |
|
469 |
The optional digest allows the client to verify that the body |
470 |
of the response has not been changed en-route. The server would |
471 |
probably only send this when it has the document and can compute it. |
472 |
The server would probably not bother generating this header for CGI |
473 |
output. The value of the "digested-entity" is an <entity-digest> which |
474 |
is computed as described above. |
475 |
|
476 |
The value of the nextnonce parameter is the nonce the server wishes |
477 |
the client to use for the next authentication response. Note that |
478 |
either field is optional. In particular the server may send the |
479 |
Authentication-info header with only the nextnonce field as a means of |
480 |
implementing one-time nonces. If the nextnonce field is present the |
481 |
client is strongly encouraged to use it for the next WWW-Authenticate |
482 |
header. Failure of the client to do so may result in a request to |
483 |
re-authenticate from the server with the "stale=TRUE." |
484 |
|
485 |
|
486 |
|
487 |
|
488 |
|
489 |
2.2 Digest Operation |
490 |
|
491 |
Upon receiving the Authorization header, the server may check |
492 |
its validity by looking up its known password which corresponds to |
493 |
the submitted username. Then, the server must perform the same MD5 |
494 |
operation performed by the client, and compare the result to the |
495 |
given response-digest. |
496 |
|
497 |
Note that the HTTP server does not actually need to know the user's |
498 |
clear text password. As long as H(A1) is available to the server, |
499 |
the validity of an Authorization header may be verified. |
500 |
|
501 |
A client may remember the username, password and nonce values, so |
502 |
that future requests within the specified <domain> may include the |
503 |
Authorization header preemptively. The server may choose to accept the |
504 |
old Authorization header information, even though the nonce value |
505 |
included might not be fresh. Alternatively, the server could return a |
506 |
401 response with a new nonce value, causing the client to retry the |
507 |
request. By specifying stale=TRUE with this response, the server |
508 |
hints to the client that the request should be retried with the new |
509 |
nonce, without reprompting the user for a new username and password. |
510 |
|
511 |
The opaque data is useful for transporting state information around. |
512 |
For example, a server could be responsible for authenticating content |
513 |
which actually sits on another server. The first 401 response would |
514 |
include a domain field which includes the URI on the second server, |
515 |
and the opaque field for specifying state information. The client |
516 |
will retry the request, at which time the server may respond with a |
517 |
301/302 redirection, pointing to the URI on the second server. The |
518 |
client will follow the redirection, and pass the same Authorization |
519 |
header, including the <opaque> data which the second server may |
520 |
require. |
521 |
|
522 |
As with the basic scheme, proxies must be completely transparent in |
523 |
the Digest access authentication scheme. That is, they must forward |
524 |
the WWW-Authenticate, Authentication-info and Authorization headers |
525 |
untouched. If a proxy wants to authenticate a client before a request |
526 |
is forwarded to the server, it can be done using the Proxy- |
527 |
Authenticate and Proxy-Authorization headers described in section |
528 |
2.5 below.. |
529 |
|
530 |
|
531 |
2.3 Security Protocol Negotiation |
532 |
|
533 |
It is useful for a server to be able to know which security schemes a |
534 |
client is capable of handling. |
535 |
|
536 |
If this proposal is accepted as a required part of the HTTP/1.1 |
537 |
specification, then a server may assume Digest support when a client |
538 |
identifies itself as HTTP/1.1 compliant. |
539 |
|
540 |
It is possible that a server may want to require Digest as its |
541 |
authentication method, even if the server does not know that the |
542 |
client supports it. A client is encouraged to fail gracefully if the |
543 |
server specifies any authentication scheme it cannot handle. |
544 |
|
545 |
|
546 |
|
547 |
|
548 |
|
549 |
2.4 Example |
550 |
|
551 |
The following example assumes that an access-protected document is |
552 |
being requested from the server. The URI of the document is |
553 |
"http://www.nowhere.org/dir/index.html". Both client and server know |
554 |
that the username for this document is "Mufasa", and the password is |
555 |
"CircleOfLife". |
556 |
|
557 |
The first time the client requests the document, no Authorization |
558 |
header is sent, so the server responds with: |
559 |
|
560 |
HTTP/1.1 401 Unauthorized |
561 |
WWW-Authenticate: Digest realm="testrealm@host.com", |
562 |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
563 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
564 |
|
565 |
The client may prompt the user for the username and password, after |
566 |
which it will respond with a new request, including the following |
567 |
Authorization header: |
568 |
|
569 |
Authorization: Digest username="Mufasa", |
570 |
realm="testrealm@host.com", |
571 |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
572 |
uri="/dir/index.html", |
573 |
response="e966c932a9242554e42c8ee200cec7f6", |
574 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
575 |
|
576 |
|
577 |
|
578 |
2.5 Proxy-Authentication and Proxy-Authorization |
579 |
|
580 |
The digest authentication scheme may also be used for authenticating |
581 |
users to proxies, proxies to proxies, or proxies to end servers by use |
582 |
of the Proxy-Authenticate and Proxy-Authorization headers. These headers |
583 |
are instances of the general Proxy-Authenticate and Proxy-Authorization |
584 |
headers specified in sections 10.30 and 10.31 of the HTTP/1.1 |
585 |
specification [2] and their behavior is subject to restrictions |
586 |
described there. The transactions for proxy authentication are very |
587 |
similar to those already described. Upon receiving a request which |
588 |
requires authentication, the proxy/server must issue the "HTTP/1.1 401 |
589 |
Unauthorized" header followed by a "Proxy-Authenticate" header of the |
590 |
form |
591 |
|
592 |
Proxy-Authentication = "Proxy-Authentication" ":" "Digest" |
593 |
digest-challenge |
594 |
|
595 |
where digest-challenge is as defined above in section 2.1. The |
596 |
client/proxy must then re-issue the request with a Proxy-Authenticate |
597 |
header of the form |
598 |
|
599 |
Proxy-Authorization = "Proxy-Authorization" ":" |
600 |
digest-response |
601 |
|
602 |
where digest-response is as defined above in section 2.1. When |
603 |
authentication succeeds, the Server may optionally provide a Proxy- |
604 |
Authentication-info header of the form |
605 |
|
606 |
Proxy-Authentication-info = "Proxy-Authentication-info" ":" nextnonce |
607 |
|
608 |
where nextnonce has the same semantics as the nextnonce field in the |
609 |
Authentication-info header described above in section 2.1. |
610 |
|
611 |
Note that in principle a client could be asked to authenticate itself |
612 |
to both a proxy and an end-server. It might receive an "HTTP/1.1 401 |
613 |
Unauthorized" header followed by both a WWW-Authenticate and a Proxy- |
614 |
Authenticate header. However, it can never receive more than one |
615 |
Proxy-Authenticate header since such headers are only for immediate |
616 |
connections and must not be passed on by proxies. If the client |
617 |
receives both headers, it must respond with both the Authorization and |
618 |
Proxy-Authorization headers as described above, which will likely |
619 |
involve different combinations of username, password, nonce, etc. |
620 |
|
621 |
|
622 |
3. Security Considerations |
623 |
|
624 |
Digest Authentication does not provide a strong authentication |
625 |
mechanism. That is not its intent. It is intended solely to replace |
626 |
a much weaker and even more dangerous authentication mechanism: Basic |
627 |
Authentication. An important design constraint is that the new |
628 |
authentication scheme be free of patent and export restrictions. |
629 |
|
630 |
Most needs for secure HTTP transactions cannot be met by Digest |
631 |
Authentication. For those needs SSL or SHTTP are more appropriate |
632 |
protocols. In particular digest authentication cannot be used for |
633 |
any transaction requiring encrypted content. Nevertheless many |
634 |
functions remain for which digest authentication is both useful and |
635 |
appropriate. |
636 |
|
637 |
|
638 |
3.1 Comparison with Basic Authentication |
639 |
|
640 |
Both Digest and Basic Authentication are very much on the weak end of |
641 |
the security strength spectrum. But a comparison between the two |
642 |
points out the utility, even necessity, of replacing Basic by Digest. |
643 |
|
644 |
The greatest threat to the type of transactions for which these |
645 |
protocols are used is network snooping. This kind of transaction |
646 |
might involve, for example, online access to a database whose use is |
647 |
restricted to paying subscribers. With Basic authentication an |
648 |
eavesdropper can obtain the password of the user. This not only |
649 |
permits him to access anything in the database, but, often worse, |
650 |
will permit access to anything else the user protects with the same |
651 |
password. |
652 |
|
653 |
By contrast, with Digest Authentication the eavesdropper only gets |
654 |
access to the transaction in question and not to the user's password. |
655 |
The information gained by the eavesdropper would permit a replay |
656 |
attack, but only with a request for the same document, and even that |
657 |
might be difficult. |
658 |
|
659 |
|
660 |
3.2 Replay Attacks |
661 |
|
662 |
A replay attack against digest authentication would usually be |
663 |
pointless for a simple GET request since an eavesdropper would |
664 |
already have seen the only document he could obtain with a replay. |
665 |
This is because the URI of the requested document is digested in the |
666 |
client response and the server will only deliver that document. By |
667 |
contrast under Basic Authentication once the eavesdropper has the |
668 |
user's password, any document protected by that password is open to |
669 |
him. A GET request containing form data could only be "replayed" |
670 |
with the identical data. However, this could be problematic if it |
671 |
caused a CGI script to take some action on the server. |
672 |
|
673 |
Thus, for some purposes, it is necessary to protect against replay |
674 |
attacks. A good digest implementation can do this in various ways. |
675 |
The server created "nonce" value is implementation dependent, but if |
676 |
it contains a digest of the client IP, a time-stamp, and a private |
677 |
server key (as recommended above) then a replay attack is not simple. |
678 |
An attacker must convince the server that the request is coming from |
679 |
a false IP address and must cause the server to deliver the document |
680 |
to an IP address different from the address to which it believes it |
681 |
is sending the document. An attack can only succeed in the period |
682 |
before the time-stamp expires. Digesting the client IP and time-stamp |
683 |
in the nonce permits an implementation which does not maintain state |
684 |
between transactions. |
685 |
|
686 |
For applications where no possibility of replay attack can be |
687 |
tolerated the server can use one-time response digests which will not |
688 |
be honored for a second use. This requires the overhead of the |
689 |
server remembering which digests have been used until the nonce |
690 |
time-stamp (and hence the digest built with it) has expired, but it |
691 |
effectively protects against replay attacks. Instead of maintaining a |
692 |
list of the values of used digests, a server would hash these values |
693 |
and require re-authentication whenever a hash collision occurs. |
694 |
|
695 |
An implementation must give special attention to the possibility of |
696 |
replay attacks with POST and PUT requests. A successful replay attack |
697 |
could result in counterfeit form data or a counterfeit version of a |
698 |
PUT file. The use of one-time digests or one-time nonces is |
699 |
recommended. It is also recommended that the optional <digest> be |
700 |
implemented for use with POST or PUT requests to assure the integrity |
701 |
of the posted data. Alternatively, a server may choose to allow |
702 |
digest authentication only with GET requests. Responsible server |
703 |
implementors will document the risks described here as they pertain to |
704 |
a given implementation. |
705 |
|
706 |
|
707 |
3.3 Man in the Middle |
708 |
|
709 |
Both Basic and Digest authentication are vulnerable to "man in the |
710 |
middle" attacks, for example, from a hostile or compromised proxy. |
711 |
Clearly, this would present all the problems of eavesdropping. But |
712 |
it could also offer some additional threats. |
713 |
|
714 |
A simple but effective attack would be to replace the Digest challenge |
715 |
with a Basic challenge, to spoof the client into revealing their |
716 |
password. To protect against this attack, clients should remember if a |
717 |
site has used Digest authentication in the past, and warn the user if |
718 |
the site stops using it. It might also be a good idea for the browser |
719 |
to be configured to demand Digest authentication in general, or from |
720 |
specific sites. |
721 |
|
722 |
Or, a hostile proxy might spoof the client into making a request the |
723 |
attacker wanted rather than one the client wanted. Of course, this is |
724 |
still much harder than a comparable attack against Basic |
725 |
Authentication. |
726 |
|
727 |
There are several attacks on the "digest" field in the |
728 |
Authentication-info header. A simple but effective attack is just to |
729 |
remove the field, so that the client will not be able to use it to |
730 |
detect modifications to the response entity. Sensitive applications |
731 |
may wish to allow configuration to require that the digest field be |
732 |
present when appropriate. More subtly, the attacker can alter any of |
733 |
the entity-headers not incorporated in the computation of the digest, |
734 |
The attacker can alter most of the request headers in the client's |
735 |
request, and can alter any response header in the origin-server's |
736 |
reply, except those headers whose values are incorporated into the |
737 |
"digest" field. |
738 |
|
739 |
Alteration of Accept* or User-Agent request headers can only result |
740 |
in a denial of service attack that returns content in an unacceptable |
741 |
media type or language. Alteration of cache control headers also can |
742 |
only result in denial of service. Alteration of Host will be detected, |
743 |
if the full URL is in the response-digest. Alteration of Referer or |
744 |
From is not important, as these are only hints. |
745 |
|
746 |
3.4 Spoofing by Counterfeit Servers |
747 |
|
748 |
Basic Authentication is vulnerable to spoofing by counterfeit |
749 |
servers. If a user can be led to believe that she is connecting to a |
750 |
host containing information protected by a password she knows, when in |
751 |
fact she is connecting to a hostile server, then the hostile server |
752 |
can request a password, store it away for later use, and feign an |
753 |
error. This type of attack is more difficult with Digest |
754 |
Authentication -- but the client must know to demand that Digest |
755 |
authentication be used, perhaps using some of the techniques described |
756 |
above to counter "man-in-the-middle" attacks. |
757 |
|
758 |
|
759 |
3.5 Storing passwords |
760 |
|
761 |
Digest authentication requires that the authenticating agent (usually |
762 |
the server) store some data derived from the user's name and password |
763 |
in a "password file" associated with a given realm. Normally this |
764 |
might contain pairs consisting of username and H(A1), where H(A1) is |
765 |
the digested value of the username, realm, and password as described |
766 |
above. |
767 |
|
768 |
The security implications of this are that if this password file is |
769 |
compromised, then an attacker gains immediate access to documents on |
770 |
the server using this realm. Unlike, say a standard UNIX password |
771 |
file, this information need not be decrypted in order to access |
772 |
documents in the server realm associated with this file. On the |
773 |
other hand, decryption, or more likely a brute force attack, would be |
774 |
necessary to obtain the user's password. This is the reason that the |
775 |
realm is part of the digested data stored in the password file. It |
776 |
means that if one digest authentication password file is compromised, |
777 |
it does not automatically compromise others with the same username |
778 |
and password (though it does expose them to brute force attack). |
779 |
|
780 |
There are two important security consequences of this. First the |
781 |
password file must be protected as if it contained unencrypted |
782 |
passwords, because for the purpose of accessing documents in its |
783 |
realm, it effectively does. |
784 |
|
785 |
A second consequence of this is that the realm string should be |
786 |
unique among all realms which any single user is likely to use. In |
787 |
particular a realm string should include the name of the host doing |
788 |
the authentication. The inability of the client to authenticate the |
789 |
server is a weakness of Digest Authentication. |
790 |
|
791 |
|
792 |
3.6 Summary |
793 |
|
794 |
By modern cryptographic standards Digest Authentication is weak. But |
795 |
for a large range of purposes it is valuable as a replacement for |
796 |
Basic Authentication. It remedies many, but not all, weaknesses of |
797 |
Basic Authentication. Its strength may vary depending on the |
798 |
implementation. In particular the structure of the nonce (which is |
799 |
dependent on the server implementation) may affect the ease of |
800 |
mounting a replay attack. A range of server options is appropriate |
801 |
since, for example, some implementations may be willing to accept the |
802 |
server overhead of one-time nonces or digests to eliminate the |
803 |
possibility of replay while others may satisfied with a nonce like |
804 |
the one recommended above restricted to a single IP address and with |
805 |
a limited lifetime. |
806 |
|
807 |
The bottom line is that *any* compliant implementation will be |
808 |
relatively weak by cryptographic standards, but *any* compliant |
809 |
implementation will be far superior to Basic Authentication. |
810 |
|
811 |
|
812 |
|
813 |
4. Acknowledgments |
814 |
|
815 |
In addition to the authors, valuable discussion instrumental in |
816 |
creating this document has come from Peter J. Churchyard, Ned Freed, |
817 |
and David M. Kristol. |
818 |
|
819 |
|
820 |
5. References |
821 |
|
822 |
[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. |
823 |
"Hypertext Transfer Protocol -- HTTP/1.0" |
824 |
Internet-Draft (work in progress), UC Irvine, |
825 |
<URL:http://ds.internic.net/internet-drafts/ |
826 |
draft-ietf-http-v10-spec-00.txt>, March 1995. |
827 |
|
828 |
[2] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen... |
829 |
"Hypertext Transfer Protocol -- HTTP/1.1" |
830 |
TBS |
831 |
|
832 |
|
833 |
[3] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm", |
834 |
<URL:http://ds.internic.net/rfc/rfc1321.txt>, |
835 |
April 1992. |
836 |
|
837 |
|
838 |
|
839 |
|
840 |
6. Authors Addresses |
841 |
|
842 |
John Franks |
843 |
john@math.nwu.edu |
844 |
Professor of Mathematics |
845 |
Department of Mathematics |
846 |
Northwestern University |
847 |
Evanston, IL 60208-2730, USA |
848 |
|
849 |
Phillip M. Hallam-Baker |
850 |
hallam@w3.org |
851 |
European Union Fellow |
852 |
CERN |
853 |
Geneva |
854 |
Switzerland |
855 |
|
856 |
Jeffery L. Hostetler |
857 |
jeff@spyglass.com |
858 |
Senior Software Engineer |
859 |
Spyglass, Inc. |
860 |
3200 Farber Drive |
861 |
Champaign, IL 61821, USA |
862 |
|
863 |
Paul J. Leach |
864 |
paulle@microsoft.com |
865 |
Microsoft Corporation |
866 |
1 Microsoft Way |
867 |
Redmond, WA 98052, USA |
868 |
|
869 |
Ari Luotonen |
870 |
luotonen@netscape.com |
871 |
Member of Technical Staff |
872 |
Netscape Communications Corporation |
873 |
501 East Middlefield Road |
874 |
Mountain View, CA 94043, USA |
875 |
|
876 |
Eric W. Sink |
877 |
eric@spyglass.com |
878 |
Senior Software Engineer |
879 |
Spyglass, Inc. |
880 |
3200 Farber Drive |
881 |
Champaign, IL 61821, USA |
882 |
|
883 |
Lawrence C. Stewart |
884 |
stewart@OpenMarket.com |
885 |
Open Market, Inc. |
886 |
215 First Street |
887 |
Cambridge, MA 02142, USA |
888 |
|
889 |
|
890 |
|
891 |
|