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