1 |
|
2 |
HTTP Working Group Jeffery L. Hostetler |
3 |
INTERNET-DRAFT John Franks |
4 |
<draft-ietf-http-digest-aa-02.txt> Philip Hallam-Baker |
5 |
Ari Luotonen |
6 |
Eric W. Sink |
7 |
Lawrence C. Stewart |
8 |
Expires SIX MONTHS FROM---> December 20, 1995 |
9 |
|
10 |
A Proposed Extension to HTTP : Digest Access Authentication |
11 |
|
12 |
Status of this Memo |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are working |
15 |
documents of the Internet Engineering Task Force (IETF), its areas, |
16 |
and its working groups. Note that other groups may also distribute |
17 |
working documents as Internet-Drafts. |
18 |
|
19 |
Internet-Drafts are draft documents valid for a maximum of six |
20 |
months and may be updated, replaced, or obsoleted by other |
21 |
documents at any time. It is inappropriate to use Internet- |
22 |
Drafts as reference material or to cite them other than as |
23 |
"work in progress." |
24 |
|
25 |
To learn the current status of any Internet-Draft, please check |
26 |
the "1id-abstracts.txt" listing contained in the Internet- |
27 |
Drafts Shadow Directories on ds.internic.net (US East Coast), |
28 |
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or |
29 |
munnari.oz.au (Pacific Rim). |
30 |
|
31 |
Distribution of this document is unlimited. Please send comments |
32 |
to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>. |
33 |
Discussions of the working group are archived at |
34 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions |
35 |
about HTTP and the applications which use HTTP should take place |
36 |
on the <www-talk@info.cern.ch> mailing list. |
37 |
|
38 |
Abstract |
39 |
|
40 |
The protocol referred to as "HTTP/1.0" includes specification |
41 |
for a Basic Access Authentication scheme. This scheme is not |
42 |
considered to be a secure method of user authentication, as the |
43 |
user name and password are passed over the network in an |
44 |
unencrypted form. A specification for a new authentication scheme |
45 |
is needed for future versions of the HTTP protocol. This document |
46 |
provides specification for such a scheme, referred to as "Digest |
47 |
Access Authentication". The encryption method used is the RSA Data |
48 |
Security, Inc. MD5 Message-Digest Algorithm [3]. |
49 |
|
50 |
Table of Contents |
51 |
|
52 |
1. Introduction |
53 |
1.1 Purpose |
54 |
1.2 Overall Operation |
55 |
1.3 Representation of MD5 digest values |
56 |
2. Basic Access Authentication Scheme |
57 |
2.1 Specification |
58 |
2.2 Security protocol negotiation |
59 |
2.3 Example |
60 |
3. Acknowledgments |
61 |
4. References |
62 |
5. Authors Addresses |
63 |
|
64 |
|
65 |
1. Introduction |
66 |
|
67 |
1.1 Purpose |
68 |
|
69 |
The protocol referred to as "HTTP/1.0" includes specification |
70 |
for a Basic Access Authentication scheme[1]. This scheme is not |
71 |
considered to be a secure method of user authentication, as the |
72 |
user name and password are passed over the network in an |
73 |
unencrypted form. A specification for a new authentication scheme |
74 |
is needed for future versions of the HTTP protocol. This document |
75 |
provides specification for such a scheme, referred to as "Digest |
76 |
Access Authentication". |
77 |
|
78 |
The Digest Access Authentication scheme is not intended to be |
79 |
a complete answer to the need for security in the World Wide Web. |
80 |
This scheme provides no encryption of object content. The intent |
81 |
is simply to facilitate secure access authentication. |
82 |
|
83 |
It is proposed that this access authentication scheme be included |
84 |
in the proposed HTTP/1.1 specification. |
85 |
|
86 |
1.2 Overall Operation |
87 |
|
88 |
Like Basic Access Authentication, the Digest scheme is based on |
89 |
a simple challenge-response paradigm. The Digest scheme challenges |
90 |
using a nonce value. A valid response contains the MD5 checksum of |
91 |
the password and the given nonce value. In this way, the password |
92 |
is never sent in the clear. Just as with the Basic scheme, the |
93 |
username and password must be prearranged in some fashion. |
94 |
|
95 |
1.3 Representation of MD5 digest values |
96 |
|
97 |
For the purposes of this document, an MD5 digest of 128 bits |
98 |
is represented as 32 ASCII printable characters. The bits |
99 |
in the 128 bit digest are converted from most significant |
100 |
to least significant bit, four bits at a time to their |
101 |
ASCII presentation as follows. Each four bits is |
102 |
represented by its familiar hexadecimal notation from the |
103 |
characters 0123456789abcdef. That is binary 0000 gets |
104 |
represented by the character '0', 0001, by '1', and so on |
105 |
up to the representation of 1111 as 'f'. |
106 |
|
107 |
2. Digest Access Authentication Scheme |
108 |
|
109 |
2.1 Specification |
110 |
|
111 |
The Digest Access Authentication scheme is conceptually similar to the Basic |
112 |
scheme. The formats of the modified WWW-Authenticate header line and the |
113 |
Authorization header line are specified below. In addition, a new header, |
114 |
Digest-MessageDigest, is specified as well. |
115 |
|
116 |
Due to formatting constraints, all of the headers are depicted here |
117 |
on multiple lines. In actual usage, they must follow the syntactic |
118 |
rules for HTTP/1.0 header lines [1]. Whitespace between the |
119 |
attribute-value pairs is allowed. |
120 |
|
121 |
If a server receives a request for an access-protected object, and an |
122 |
acceptable Authorizatation header is not sent, the server responds with: |
123 |
|
124 |
HTTP/1.1 401 Unauthorized |
125 |
WWW-Authenticate: Digest realm="<realm>", |
126 |
domain="<domain>", |
127 |
nonce="<nonce>", |
128 |
opaque="<opaque>", |
129 |
stale="<TRUE | FALSE>" |
130 |
|
131 |
|
132 |
|
133 |
The meanings of the identifers used above are as follows: |
134 |
|
135 |
<realm> |
136 |
A name given to users so they know which username and password |
137 |
to send. |
138 |
|
139 |
<domain> OPTIONAL |
140 |
A comma separated list of URIs, as specified for HTTP/1.0. The |
141 |
intent is that the client could use this information to know the |
142 |
set of URIs for which the same authentication information should be |
143 |
sent. The URIs in this list may exist on different servers. If |
144 |
this keyword is omitted or empty, the client should assume that |
145 |
the domain consists of all URIs on the responding server. |
146 |
|
147 |
<nonce> |
148 |
A server-specified integer value which may be uniquely generated each |
149 |
time a 401 response is made. Servers may defend themselves against |
150 |
replay attacks by refusing to reuse nonce values. The nonce should be |
151 |
considered opqaue by the client. |
152 |
|
153 |
<opaque> OPTIONAL |
154 |
A string of data, specified by the server, which should returned by |
155 |
the client unchanged. It is recommended that this string be |
156 |
base64 or hexadecimal data. Specifically, since the string is passed |
157 |
in the header lines as a quoted string, the double-quote character |
158 |
is not allowed. |
159 |
|
160 |
<stale> OPTIONAL |
161 |
A flag, indicating that the previous request from the client |
162 |
was rejected because the nonce value was stale. If stale |
163 |
is TRUE, the client may wish to simply retry the request with |
164 |
a new encrypted response, without reprompting the user for a |
165 |
new username and password. |
166 |
|
167 |
|
168 |
The client is expected to retry the request, passing an Authorization header |
169 |
line as follows: |
170 |
|
171 |
Authorization: Digest |
172 |
username="<username>", -- required |
173 |
realm="<realm>", -- required |
174 |
nonce="<nonce>", -- required |
175 |
uri="<requested-uri>", -- required |
176 |
response="<digest>", -- required |
177 |
message="<message-digest>", -- OPTIONAL |
178 |
opaque="<opaque>" -- required if provided by server |
179 |
|
180 |
where <digest> := H( H(A1) + ":" + N + ":" + H(A2) ) |
181 |
and <message-digest> := H( H(A1) + ":" + N + ":" + H(<message-body>) ) |
182 |
|
183 |
where: |
184 |
|
185 |
A1 := U + ':' + R + ':' + P |
186 |
A2 := <Method> + ':' + <requested-uri> |
187 |
|
188 |
with: |
189 |
N -- nonce value |
190 |
U -- username |
191 |
R -- realm |
192 |
P -- password |
193 |
<Method> -- from header line 0 |
194 |
<requested-uri> -- uri sans proxy/routing |
195 |
|
196 |
When authorization succeeds, the Server may optionally provide the |
197 |
following: |
198 |
|
199 |
HTTP/1.1 200 OK |
200 |
Digest-MessageDigest: |
201 |
username="<username>", |
202 |
realm="<realm>", |
203 |
nonce="<nonce>", |
204 |
message="<message-digest>" |
205 |
|
206 |
The Digest-MessageDigest header indicates that the server wants to |
207 |
communicate some info regarding the successful |
208 |
authentication (such as a message digest or a |
209 |
receipt of some kind). |
210 |
|
211 |
<message-digest> is computed as given above for |
212 |
the client. this allows the client to verify that |
213 |
the message body has not been changed en-route. |
214 |
|
215 |
(The server would probably only send this when it |
216 |
has the document and can compute it (like the |
217 |
content-length field); the server would probably |
218 |
not bother generating this header for CGI output.) |
219 |
|
220 |
|
221 |
Upon receiving the Authorization information, the server may check its |
222 |
validity by looking up its known password which corresponds to the submitted |
223 |
<username>. Then, the server must perform the same MD5 operation performed |
224 |
by the client, and compare the result to the given <response>. |
225 |
|
226 |
Note that the HTTP server does not actually need to know the user's |
227 |
clear text password. As long as H(A1) is available to the server, the |
228 |
validity of an Authorization header may be verified. |
229 |
|
230 |
All keyword-value pairs must be expressed in characters from the |
231 |
US-ASCII character set, excluding control characters. |
232 |
|
233 |
A client may remember the username, password and nonce values, so that |
234 |
future requests within the specified <domain> may include the Authorization |
235 |
line preemptively. The server may choose to accept the old Authorization |
236 |
information, even though the nonce value included might not be fresh. |
237 |
Alternatively, the server could return a 401 response with a new nonce |
238 |
value, causing the client to retry the request. By specifying stale=TRUE |
239 |
with this response, the server hints to the client that the request should |
240 |
be retried with the new nonce, without reprompting the user for a new |
241 |
username and password. |
242 |
|
243 |
The <opaque> data is useful for transporting state information around. |
244 |
For example, a server could be responsible for authenticating content |
245 |
which actual sits on another server. The first 401 response would include |
246 |
a <domain> which includes the URI on the second server, and the <opaque> |
247 |
for specifying state information. The client will retry the request, at |
248 |
which time the server may respond with a 301/302 redirection, pointing |
249 |
to the URI on the second server. The client will follow the redirection, |
250 |
and pass the same Authorization line, including the <opaque> data which |
251 |
the second server may require. |
252 |
|
253 |
As with the basic scheme, proxies must be completely transparent in |
254 |
the Digest access authentication scheme. That is, they must forward the |
255 |
WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched. |
256 |
If a proxy wants to authenticate a client before a request is forwarded to |
257 |
the server, it can be done using the Proxy-Authenticate and |
258 |
Proxy-Authorization headers. |
259 |
|
260 |
2.2 Security Protocol Negotiation |
261 |
|
262 |
It is useful for a server to be able to know which security schemes |
263 |
a client is capable of handling. It is recommended that the HTTP extension |
264 |
mechanism proposed by Dave Kristol [2] be used. If the client includes |
265 |
the following header line with the request, then a server can safely assume |
266 |
that the client can handle Digest authentication. |
267 |
|
268 |
Extension: Security/Digest |
269 |
|
270 |
If this proposal is accepted as a required part of the HTTP/1.1 |
271 |
specification, then a server may assume Digest support when a client |
272 |
identifies itself as HTTP/1.1 compliant. |
273 |
|
274 |
It is possible that a server may want to require Digest as its |
275 |
authentication method, even if the server does not know that the client |
276 |
supports it. A client is encouraged to fail gracefully if the server |
277 |
specifies any authentication scheme it cannot handle. |
278 |
|
279 |
2.3 Example |
280 |
|
281 |
The following example assumes that an access-protected document is being |
282 |
requested from the server. The URI of the document is |
283 |
"http://www.nowhere.org/simp/". |
284 |
|
285 |
Both client and server know that the username for this document is "eric", |
286 |
and the password is "spyglass". |
287 |
|
288 |
The first time the client requests the document, no Authorization header |
289 |
is sent, so the server responds with: |
290 |
|
291 |
HTTP/1.1 401 Unauthorized |
292 |
WWW-Authenticate: Digest realm="testrealm", |
293 |
nonce="72540723369", |
294 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
295 |
|
296 |
The client may prompt the user for the username and password, after which it |
297 |
will respond with a new request, including the following Authorization |
298 |
header: |
299 |
|
300 |
Authorization: Digest username="eric", |
301 |
realm="testrealm", |
302 |
nonce="72540723369", |
303 |
uri="/simp/", |
304 |
response="e966c932a9242554e42c8ee200cec7f6", |
305 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
306 |
|
307 |
3. References |
308 |
|
309 |
[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. |
310 |
"Hypertext Transfer Protocol -- HTTP/1.0" |
311 |
Internet-Draft (work in progress), UC Irvine, |
312 |
<URL:http://ds.internic.net/internet-drafts/ |
313 |
draft-ietf-http-v10-spec-00.txt>, March 1995. |
314 |
|
315 |
[2] D. Kristol. "A Proposed Extension Mechanism for HTTP" |
316 |
<URL:http://ds.internic.net/internet-drafts/ |
317 |
draft-kristol-http-extensions-00.txt>, |
318 |
December 1994. |
319 |
|
320 |
[3] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm", |
321 |
<URL:http://ds.internic.net/rfc/rfc1321.txt>, |
322 |
April 1992. |
323 |
|
324 |
4. Authors Addresses |
325 |
|
326 |
John Franks |
327 |
john@math.nwu.edu |
328 |
Professor of Mathematics |
329 |
Department of Mathematics |
330 |
Northwestern University |
331 |
Evanston, IL 60208-2730, USA |
332 |
|
333 |
Phillip M. Hallam-Baker |
334 |
hallam@w3.org |
335 |
European Union Fellow |
336 |
CERN |
337 |
Geneva |
338 |
Switzerland |
339 |
|
340 |
Jeffery L. Hostetler |
341 |
jeff@spyglass.com |
342 |
Senior Software Engineer |
343 |
Spyglass, Inc. |
344 |
3200 Farber Drive |
345 |
Champaign, IL 61821, USA |
346 |
|
347 |
Ari Luotonen |
348 |
luotonen@netscape.com |
349 |
Member of Technical Staff |
350 |
Netscape Communications Corporation |
351 |
501 East Middlefield Road |
352 |
Mountain View, CA 94043, USA |
353 |
|
354 |
Eric W. Sink |
355 |
eric@spyglass.com |
356 |
Senior Software Engineer |
357 |
Spyglass, Inc. |
358 |
3200 Farber Drive |
359 |
Champaign, IL 61821, USA |
360 |
|
361 |
Lawrence C. Stewart |
362 |
stewart@OpenMarket.com |
363 |
Open Market, Inc. |
364 |
215 First Street |
365 |
Cambridge, MA 02142, USA |
366 |
|
367 |
|
368 |
-- |
369 |
Eric W. Sink |
370 |
eric@spyglass.com |
371 |
|