1 |
|
2 |
HTTP Working Group Jeffery L. Hostetler |
3 |
INTERNET-DRAFT John Franks |
4 |
<draft-ietf-http-digest-aa-03.txt> Philip Hallam-Baker |
5 |
Paul Leach |
6 |
Ari Luotonen |
7 |
Eric W. Sink |
8 |
Lawrence C. Stewart |
9 |
|
10 |
Expires SIX MONTHS FROM---> March 1, 1996 |
11 |
|
12 |
A Proposed Extension to HTTP : Digest Access Authentication |
13 |
|
14 |
Status of this Memo |
15 |
|
16 |
This document is an Internet-Draft. Internet-Drafts are working |
17 |
documents of the Internet Engineering Task Force (IETF), its areas, |
18 |
and its working groups. Note that other groups may also distribute |
19 |
working documents as Internet-Drafts. |
20 |
|
21 |
Internet-Drafts are draft documents valid for a maximum of six |
22 |
months and may be updated, replaced, or obsoleted by other |
23 |
documents at any time. It is inappropriate to use Internet- |
24 |
Drafts as reference material or to cite them other than as |
25 |
"work in progress." |
26 |
|
27 |
To learn the current status of any Internet-Draft, please check |
28 |
the "1id-abstracts.txt" listing contained in the Internet- |
29 |
Drafts Shadow Directories on ds.internic.net (US East Coast), |
30 |
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or |
31 |
munnari.oz.au (Pacific Rim). |
32 |
|
33 |
Distribution of this document is unlimited. Please send comments |
34 |
to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>. |
35 |
Discussions of the working group are archived at |
36 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions |
37 |
about HTTP and the applications which use HTTP should take place |
38 |
on the <www-talk@www10.w3.org> mailing list. |
39 |
|
40 |
Abstract |
41 |
|
42 |
The protocol referred to as "HTTP/1.0" includes specification |
43 |
for a Basic Access Authentication scheme. This scheme is not |
44 |
considered to be a secure method of user authentication, as the |
45 |
user name and password are passed over the network in an |
46 |
unencrypted form. A specification for a new authentication scheme |
47 |
is needed for future versions of the HTTP protocol. This document |
48 |
provides specification for such a scheme, referred to as "Digest |
49 |
Access Authentication". The encryption method used by default is the |
50 |
RSA Data Security, Inc. MD5 Message-Digest Algorithm [2]. |
51 |
|
52 |
Table of Contents |
53 |
|
54 |
1. Introduction |
55 |
1.1 Purpose |
56 |
1.2 Overall Operation |
57 |
1.3 Representation of MD5 digest values |
58 |
2. Basic Access Authentication Scheme |
59 |
2.1 Specification of Digest Headers |
60 |
2.2 Digest Operation |
61 |
2.3 Security protocol negotiation |
62 |
2.4 Example |
63 |
3. Security Considerations |
64 |
4. Acknowledgments |
65 |
5. References |
66 |
6. Authors Addresses |
67 |
|
68 |
|
69 |
1. Introduction |
70 |
|
71 |
1.1 Purpose |
72 |
|
73 |
The protocol referred to as "HTTP/1.0" includes specification |
74 |
for a Basic Access Authentication scheme[1]. This scheme is not |
75 |
considered to be a secure method of user authentication, as the |
76 |
user name and password are passed over the network in an |
77 |
unencrypted form. A specification for a new authentication scheme |
78 |
is needed for future versions of the HTTP protocol. This document |
79 |
provides specification for such a scheme, referred to as "Digest |
80 |
Access Authentication". |
81 |
|
82 |
The Digest Access Authentication scheme is not intended to be |
83 |
a complete answer to the need for security in the World Wide Web. |
84 |
This scheme provides no encryption of object content. The intent |
85 |
is simply to facilitate secure access authentication. |
86 |
|
87 |
It is proposed that this access authentication scheme be included |
88 |
in the proposed HTTP/1.1 specification. |
89 |
|
90 |
1.2 Overall Operation |
91 |
|
92 |
Like Basic Access Authentication, the Digest scheme is based on a |
93 |
simple challenge-response paradigm. The Digest scheme challenges |
94 |
using a nonce value. A valid response contains a checksum (by default |
95 |
the MD5 checksum) of the username, the password, the given nonce |
96 |
value, and the requested URI. In this way, the password is never sent |
97 |
in the clear. Just as with the Basic scheme, the username and |
98 |
password must be prearranged in some fashion which is not addressed |
99 |
by this document. |
100 |
|
101 |
1.3 Representation of digest values |
102 |
|
103 |
An optional header allows the server to specify the algorithm |
104 |
used to create the checksum or digest. By default the MD5 |
105 |
algorithm is used and that is the only algorithm described in |
106 |
this document. |
107 |
|
108 |
For the purposes of this document, an MD5 digest of 128 bits |
109 |
is represented as 32 ASCII printable characters. The bits |
110 |
in the 128 bit digest are converted from most significant |
111 |
to least significant bit, four bits at a time to their |
112 |
ASCII presentation as follows. Each four bits is |
113 |
represented by its familiar hexadecimal notation from the |
114 |
characters 0123456789abcdef. That is binary 0000 gets |
115 |
represented by the character '0', 0001, by '1', and so on |
116 |
up to the representation of 1111 as 'f'. |
117 |
|
118 |
|
119 |
1.4 Limitations |
120 |
|
121 |
The digest authentication scheme described in this document suffers |
122 |
from many known limitations. It is intended as a replacement for |
123 |
basic authentication and nothing more. It is a password-based system |
124 |
and (on the server side) suffers from all the same problems of any |
125 |
password system. In particular no provision is made in this protocol |
126 |
for the initial secure arrangement between user and server |
127 |
establishing the user's password. |
128 |
|
129 |
Users and implementors should be aware that this protocol is not as |
130 |
secure as kerberos, and not as secure as any client-side private-key |
131 |
scheme. Nevertheless it is better than nothing, better than what is |
132 |
commonly used with telnet and ftp and better than Basic |
133 |
authentication. |
134 |
|
135 |
|
136 |
2. Digest Access Authentication Scheme |
137 |
|
138 |
2.1 Specification of Digest Headers |
139 |
|
140 |
The Digest Access Authentication scheme is conceptually similar to the Basic |
141 |
scheme. The formats of the modified WWW-Authenticate header line and the |
142 |
Authorization header line are specified below. In addition, a new header, |
143 |
Digest-MessageDigest, is specified as well. |
144 |
|
145 |
Due to formatting constraints, all of the headers are depicted here |
146 |
on multiple lines. In actual usage, they must follow the syntactic |
147 |
rules for HTTP/1.0 header lines [1]. Whitespace between the |
148 |
attribute-value pairs is allowed. |
149 |
|
150 |
If a server receives a request for an access-protected object, and an |
151 |
acceptable Authorization header is not sent, the server responds with: |
152 |
|
153 |
HTTP/1.1 401 Unauthorized |
154 |
WWW-Authenticate: Digest realm="<realm>", |
155 |
domain="<domain>", |
156 |
nonce="<nonce>", |
157 |
opaque="<opaque>", |
158 |
stale="<TRUE | FALSE>", |
159 |
algorithm="<digest-algorithm>" |
160 |
|
161 |
|
162 |
The meanings of the identifiers used above are as follows: |
163 |
|
164 |
<realm> |
165 |
A string to be displayed to users so they know which |
166 |
username and password to use. This string should contain |
167 |
at least the name of the host performing the authentication |
168 |
and might additionally indicate the collection of users who |
169 |
might have access. An example might be |
170 |
"registered users @ gotham.news.com." |
171 |
|
172 |
<domain> OPTIONAL |
173 |
A comma separated list of URIs, as specified for HTTP/1.0. The |
174 |
intent is that the client could use this information to know the |
175 |
set of URIs for which the same authentication information should be |
176 |
sent. The URIs in this list may exist on different servers. If |
177 |
this keyword is omitted or empty, the client should assume that |
178 |
the domain consists of all URIs on the responding server. |
179 |
|
180 |
<nonce> |
181 |
A server-specified data string which may be uniquely generated each |
182 |
time a 401 response is made. It is recommended that this string be |
183 |
base64 or hexadecimal data. Specifically, since the string is passed |
184 |
in the header lines as a quoted string, the double-quote character |
185 |
is not allowed. |
186 |
|
187 |
The contents of the nonce is implementation dependent. The |
188 |
quality of the implementation depends on a good choice. A |
189 |
recommended nonce would include |
190 |
|
191 |
H(<client IP> + ":" + <timestamp> + ":" + <private key> ) |
192 |
|
193 |
Where <client IP> is the dotted quad IP address of the client |
194 |
making the request, <timestamp> is a server generated time value, |
195 |
<private key> is data known only to the server. With a nonce |
196 |
of this form a server would normally recalculate the nonce |
197 |
after receiving the client authentication header and reject |
198 |
the request if it did not match the nonce from that header. |
199 |
In this way the server can limit the reuse of a nonce to |
200 |
the IP address to which it was issued and limit the time of |
201 |
the nonce's validity. A server might also wish to include |
202 |
the client request or the contents of the Host: header in |
203 |
the data digested to create the nonce. Further discussion |
204 |
of the rationale for nonce construction is in section 3.2 |
205 |
below. |
206 |
|
207 |
An implementation might choose not to accept a previously used |
208 |
<nonce> or a previously used <digest> to protect against a |
209 |
replay attack. Or, an implementation might choose to use |
210 |
one-time nonces or digests for POST or PUT requests and a |
211 |
timestamp for GET requests. For more details on the issues |
212 |
involved see section 3. of this document. |
213 |
|
214 |
The nonce is opaque to the client. |
215 |
|
216 |
<opaque> OPTIONAL |
217 |
A string of data, specified by the server, which should returned by |
218 |
the client unchanged. It is recommended that this string be |
219 |
base64 or hexadecimal data. Specifically, since the string is passed |
220 |
in the header lines as a quoted string, the double-quote character |
221 |
is not allowed. |
222 |
|
223 |
<stale> OPTIONAL |
224 |
A flag, indicating that the previous request from the client |
225 |
was rejected because the nonce value was stale. If stale |
226 |
is TRUE, the client may wish to simply retry the request with |
227 |
a new encrypted response, without reprompting the user for a |
228 |
new username and password. The server should only set stale |
229 |
to true if it receives a request for which the nonce is invalid |
230 |
but with a valid digest for that nonce (indicating the the client |
231 |
knows the correct username/password). |
232 |
|
233 |
<algorithm> OPTIONAL |
234 |
A string indicating the algorithm used to produce the digest |
235 |
or checksum. If this not present the MD5 algorithm is assumed. |
236 |
In this document the string obtained by applying this algorithm |
237 |
to the data "<data>" will be denoted by H(<data>). |
238 |
|
239 |
|
240 |
The client is expected to retry the request, passing an Authorization header |
241 |
line as follows: |
242 |
|
243 |
Authorization: Digest |
244 |
username="<username>", -- required |
245 |
realm="<realm>", -- required |
246 |
nonce="<nonce>", -- required |
247 |
uri="<requested-uri>", -- required |
248 |
response="<digest>", -- required |
249 |
message="<message-digest>", -- OPTIONAL |
250 |
algorithm="<digest-algorithm>" -- OPTIONAL |
251 |
opaque="<opaque>", -- required if provided |
252 |
by server |
253 |
|
254 |
where <digest> := H( H(A1) + ":" + N + ":" + H(A2) ) |
255 |
and <message-digest> := H( H(A1) + ":" + N + ":" + H(<entity-body>) ) |
256 |
|
257 |
where: |
258 |
|
259 |
A1 := U + ':' + R + ':' + P |
260 |
A2 := <Method> + ':' + <requested-uri> |
261 |
|
262 |
with: |
263 |
N -- nonce value |
264 |
U -- username |
265 |
R -- realm |
266 |
P -- password |
267 |
|
268 |
<Method> is the HTTP method specified at the beginning of the |
269 |
first line of the client request. <requested-uri> is the part |
270 |
of the requested URL transmitted by the client to the server |
271 |
in the first line of an HTTP request. In particular it does |
272 |
not include the "http://host:port" part of the URL but does |
273 |
include any "query" part which might, for example, include form |
274 |
data after a '?' in the URL. |
275 |
|
276 |
The purpose of the <message-digest> is to allow the server to |
277 |
ensure that the content of the request body has not been tampered |
278 |
with after leaving the client. This would normally be used with a |
279 |
POST or PUT request and would allow the server to check the validity |
280 |
of the posted data. The <entity-body> is the "entity body" as |
281 |
prescribed in the Hypertext Transfer Protocol version 1.1. |
282 |
|
283 |
When authorization succeeds, the Server may optionally provide the |
284 |
following: |
285 |
|
286 |
HTTP/1.1 200 OK |
287 |
Digest-MessageDigest: |
288 |
message="<message-digest>", |
289 |
nextnonce="<nextnonce>" |
290 |
|
291 |
The Digest-MessageDigest header indicates that the server |
292 |
wants to communicate some information regarding the |
293 |
successful authentication (such as a message digest or a |
294 |
new nonce to be used for the next transaction). |
295 |
|
296 |
<message-digest> is computed by the same algorithm given |
297 |
above for the body of the client request. This allows the |
298 |
client to verify that the body of the response has not been |
299 |
changed en-route. The server would probably only send this |
300 |
when it has the document and can compute it. The server would |
301 |
probably not bother generating this header for CGI output. |
302 |
|
303 |
<nextnonce> is the nonce the server wishes the client to use for |
304 |
the next authentication response. Either field is optional. In |
305 |
particular the server may send the Digest-MessageDigest header |
306 |
with only the nextnonce=<nextnonce> field as a means of |
307 |
implementing one-time nonces. If the nextnonce field is present |
308 |
the client is strongly encouraged to use it for the next |
309 |
WWW-Authenticate header. Failure of the client to do so may |
310 |
result in a request to re-authenticate from the server with |
311 |
the "stale=TRUE." |
312 |
|
313 |
The Digest-MessageDigest header has many limitations. Only the |
314 |
entity body is digested, not any headers. This limitation is due |
315 |
to the fact that proxy caches may (and do) alter the headers of |
316 |
documents which they relay. Future authentication schemes will |
317 |
have to deal with the complexities imposed by the behavior of |
318 |
intermediaries handling documents on their way from the origin |
319 |
server to the client, but those issues are beyond the scope of |
320 |
digest authentication, whose purpose is to replace Basic |
321 |
Authentication. Despite its limitations the Digest-MessageDigest |
322 |
can be useful. |
323 |
|
324 |
2.2 Digest Operation |
325 |
|
326 |
Upon receiving the Authorization information, the server may check |
327 |
its validity by looking up its known password which corresponds to |
328 |
the submitted <username>. Then, the server must perform the same |
329 |
MD5 operation performed by the client, and compare the result to |
330 |
the given <response>. |
331 |
|
332 |
Note that the HTTP server does not actually need to know the user's |
333 |
clear text password. As long as H(A1) is available to the server, the |
334 |
validity of an Authorization header may be verified. |
335 |
|
336 |
All keyword-value pairs must be expressed in characters from the |
337 |
US-ASCII character set, excluding control characters. |
338 |
|
339 |
A client may remember the username, password and nonce values, so that |
340 |
future requests within the specified <domain> may include the Authorization |
341 |
line preemptively. The server may choose to accept the old Authorization |
342 |
information, even though the nonce value included might not be fresh. |
343 |
Alternatively, the server could return a 401 response with a new nonce |
344 |
value, causing the client to retry the request. By specifying stale=TRUE |
345 |
with this response, the server hints to the client that the request should |
346 |
be retried with the new nonce, without reprompting the user for a new |
347 |
username and password. |
348 |
|
349 |
The <opaque> data is useful for transporting state information around. |
350 |
For example, a server could be responsible for authenticating content |
351 |
which actual sits on another server. The first 401 response would include |
352 |
a <domain> which includes the URI on the second server, and the <opaque> |
353 |
for specifying state information. The client will retry the request, at |
354 |
which time the server may respond with a 301/302 redirection, pointing |
355 |
to the URI on the second server. The client will follow the redirection, |
356 |
and pass the same Authorization line, including the <opaque> data which |
357 |
the second server may require. |
358 |
|
359 |
As with the basic scheme, proxies must be completely transparent in |
360 |
the Digest access authentication scheme. That is, they must forward the |
361 |
WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched. |
362 |
If a proxy wants to authenticate a client before a request is forwarded to |
363 |
the server, it can be done using the Proxy-Authenticate and |
364 |
Proxy-Authorization headers. |
365 |
|
366 |
2.3 Security Protocol Negotiation |
367 |
|
368 |
It is useful for a server to be able to know which security schemes |
369 |
a client is capable of handling. |
370 |
|
371 |
If this proposal is accepted as a required part of the HTTP/1.1 |
372 |
specification, then a server may assume Digest support when a client |
373 |
identifies itself as HTTP/1.1 compliant. |
374 |
|
375 |
It is possible that a server may want to require Digest as its |
376 |
authentication method, even if the server does not know that the client |
377 |
supports it. A client is encouraged to fail gracefully if the server |
378 |
specifies any authentication scheme it cannot handle. |
379 |
|
380 |
2.4 Example |
381 |
|
382 |
The following example assumes that an access-protected document is being |
383 |
requested from the server. The URI of the document is |
384 |
"http://www.nowhere.org/dir/index.html". |
385 |
|
386 |
Both client and server know that the username for this document is |
387 |
"Mufasa", and the password is "CircleOfLife". |
388 |
|
389 |
The first time the client requests the document, no Authorization header |
390 |
is sent, so the server responds with: |
391 |
|
392 |
HTTP/1.1 401 Unauthorized |
393 |
WWW-Authenticate: Digest realm="testrealm@host.com", |
394 |
nonce="72540723369", |
395 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
396 |
|
397 |
The client may prompt the user for the username and password, after which it |
398 |
will respond with a new request, including the following Authorization |
399 |
header: |
400 |
|
401 |
Authorization: Digest username="Mufasa", |
402 |
realm="testrealm@host.com", |
403 |
nonce="72540723369", |
404 |
uri="/dir/index.html", |
405 |
response="e966c932a9242554e42c8ee200cec7f6", |
406 |
opaque="5ccc069c403ebaf9f0171e9517f40e41" |
407 |
|
408 |
|
409 |
3. Security Considerations |
410 |
|
411 |
Digest Authentication does not provide provide a strong authentication |
412 |
mechanism. That is not its intent. It is intended solely to replace |
413 |
a much weaker and even dangerous authentication mechanism: Basic |
414 |
Authentication. An important design constraint is that the new |
415 |
authentication scheme be free of patent and export restrictions. |
416 |
|
417 |
Most needs for secure HTTP transactions cannot be met by Digest |
418 |
Authentication. For those needs SSL or SHTTP are more appropriate |
419 |
protocols. In particular digest authentication cannot be used for any |
420 |
transaction requiring encrypted content. Nevertheless many functions |
421 |
remain for which digest authentication is both useful and appropriate. |
422 |
|
423 |
3.1 Comparison with Basic Authentication |
424 |
|
425 |
Both Digest and Basic Authentication are very much on the weak end of |
426 |
the security strength spectrum. But a comparison between |
427 |
the two points out the utility, even necessity, of replacing Basic |
428 |
by Digest. |
429 |
|
430 |
The greatest threat to the type of transactions for which these |
431 |
protocols are used is network snooping. This kind of transaction |
432 |
might involve, for example, online access to a database whose use is |
433 |
restricted to paying subscribers. With Basic authentication an |
434 |
eavesdropper can obtain the password of the user. This not only |
435 |
permits him to access anything in the data base, but often worse, will |
436 |
permit access to anything else the user protects with the same |
437 |
password. |
438 |
|
439 |
By contrast, with Digest Authentication the eavesdropper only gets |
440 |
access to the transaction in question and not to the user's password. |
441 |
The information gained by the eavesdropper would permit a replay |
442 |
attack, but only with a request for the same document and even |
443 |
that might be difficult. |
444 |
|
445 |
3.2 Replay Attacks |
446 |
|
447 |
A replay attack against digest authentication would usually be |
448 |
pointless for a simple GET request since an eavesdropper would |
449 |
already have seen the only document he could obtain with a replay. |
450 |
This is because the URI of the requested document is digested in |
451 |
the client response and the server will only deliver that document. |
452 |
By contrast under Basic Authentication once the eavesdropper has |
453 |
the user's password any document protected by that password is open |
454 |
to him. A GET request containing form data could only be "replayed" |
455 |
with the identical data. However, this could be problematic if it |
456 |
caused a CGI script to take some action on the server. |
457 |
|
458 |
Thus, for some purposes, it is necessary to protect against replay |
459 |
attacks. A good digest implementation can do this in various ways. |
460 |
The server created "nonce" value is implementation dependent, but if |
461 |
it contains a digest of the client IP, a timestamp, and a private |
462 |
server key (as recommended above) then a replay attack is not |
463 |
simple. An attacker must convince the server that the request is |
464 |
coming from a false IP address and must cause the server to deliver |
465 |
the document to an IP address different from the address to which it |
466 |
believes it is sending the document. An attack can only succeed in |
467 |
the period before the timestamp expires. Digesting the client |
468 |
IP and timestamp in the nonce permits an implementation which does |
469 |
not maintain state between transactions. |
470 |
|
471 |
For applications where no possibility of replay attack can be |
472 |
tolerated the server can use one-time response digests which will |
473 |
not be honored for a second use. This requires the overhead of |
474 |
the server remembering which digests have been used until the |
475 |
nonce timestamp (and hence the digest built with it) has expired, |
476 |
but it effectively protects against replay attacks. Instead of |
477 |
maintaining a list of the values of used digests, a server would |
478 |
hash these values and require re-authentication whenever a hash |
479 |
collision occurs. |
480 |
|
481 |
An implementation must give special attention to the possibility of |
482 |
replay attacks with POST and PUT requests. A successful replay |
483 |
attack could result in counterfeit form data or a counterfeit |
484 |
version of a PUT file. The use of one-time digests or one-time |
485 |
nonces is recommended. It is also recommended that the optional |
486 |
<message-digest> be implemented for use with POST or PUT requests |
487 |
to assure the integrity of the posted data. Alternatively, a server |
488 |
may choose to allow digest authentication only with GET requests. |
489 |
Responsible server implementors will document the risks described |
490 |
here as they pertain to a given implementation. |
491 |
|
492 |
3.3 Man in the Middle |
493 |
|
494 |
Both Basic and Digest authentication are vulnerable to "man in the |
495 |
middle" attacks, for example, from a hostile or compromised proxy. |
496 |
Clearly, this would present all the problems of eavesdropping. But it |
497 |
could also offer some additional threats. In particular, even with |
498 |
digest authentication, a hostile proxy might spoof the client into |
499 |
making a request the attacker wanted rather than one the client |
500 |
wanted. Of course, this is still much harder than a comparable |
501 |
attack against Basic Authentication. |
502 |
|
503 |
3.4 Spoofing by Counterfeit Servers |
504 |
|
505 |
Basic Authentication is vulnerable to spoofing by counterfeit servers. |
506 |
If a user can be led to believe that she is connecting to a host |
507 |
containing information protected by a password she knows when |
508 |
in fact she is connecting to a hostile server then the hostile server |
509 |
can request a password, store it away for later use, and feign an |
510 |
error. This type of attack is not possible with Digest Authentication. |
511 |
|
512 |
3.5 Summary |
513 |
|
514 |
By modern cryptographic standards Digest Authentication is weak. But |
515 |
for a large range of purposes it is valuable as a replacement for |
516 |
Basic Authentication. It remedies many, but not all, weaknesses of |
517 |
Basic Authentication. Its strength may vary depending on the |
518 |
implementation. In particular the structure of the nonce (which is |
519 |
dependent on the server implementation) may affect the ease of |
520 |
mounting a replay attack. A range of server options is appropriate |
521 |
since, for example, some implementations may be willing to accept the |
522 |
server overhead of one-time nonces or digests to eliminate the |
523 |
possibility of replay while others may satisfied with a nonce like |
524 |
the one recommended above restricted to a single IP address and with |
525 |
a limited lifetime. |
526 |
|
527 |
The bottom line is that *any* compliant implementation will be |
528 |
relatively weak by cryptographic standards, but *any* compliant |
529 |
implementation will be far superior to Basic Authentication. |
530 |
|
531 |
|
532 |
4. Acknowledgments |
533 |
|
534 |
In addition to the authors, valuable discussion instrumental in |
535 |
creating this document have come from Peter J Churchyard, Ned Freed, |
536 |
and David Kristol. |
537 |
|
538 |
|
539 |
5. References |
540 |
|
541 |
[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. |
542 |
"Hypertext Transfer Protocol -- HTTP/1.0" |
543 |
Internet-Draft (work in progress), UC Irvine, |
544 |
<URL:http://ds.internic.net/internet-drafts/ |
545 |
draft-ietf-http-v10-spec-00.txt>, March 1995. |
546 |
|
547 |
[2] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm", |
548 |
<URL:http://ds.internic.net/rfc/rfc1321.txt>, |
549 |
April 1992. |
550 |
|
551 |
6. Authors Addresses |
552 |
|
553 |
John Franks |
554 |
john@math.nwu.edu |
555 |
Professor of Mathematics |
556 |
Department of Mathematics |
557 |
Northwestern University |
558 |
Evanston, IL 60208-2730, USA |
559 |
|
560 |
Phillip M. Hallam-Baker |
561 |
hallam@w3.org |
562 |
European Union Fellow |
563 |
CERN |
564 |
Geneva |
565 |
Switzerland |
566 |
|
567 |
Jeffery L. Hostetler |
568 |
jeff@spyglass.com |
569 |
Senior Software Engineer |
570 |
Spyglass, Inc. |
571 |
3200 Farber Drive |
572 |
Champaign, IL 61821, USA |
573 |
|
574 |
Paul J. Leach |
575 |
paulle@microsoft.com |
576 |
Microsoft Corporation |
577 |
1 Microsoft Way |
578 |
Redmond, WA 98052, USA |
579 |
|
580 |
Ari Luotonen |
581 |
luotonen@netscape.com |
582 |
Member of Technical Staff |
583 |
Netscape Communications Corporation |
584 |
501 East Middlefield Road |
585 |
Mountain View, CA 94043, USA |
586 |
|
587 |
Eric W. Sink |
588 |
eric@spyglass.com |
589 |
Senior Software Engineer |
590 |
Spyglass, Inc. |
591 |
3200 Farber Drive |
592 |
Champaign, IL 61821, USA |
593 |
|
594 |
Lawrence C. Stewart |
595 |
stewart@OpenMarket.com |
596 |
Open Market, Inc. |
597 |
215 First Street |
598 |
Cambridge, MA 02142, USA |
599 |
|
600 |
|
601 |
|