source: draft-ietf-httpbis/orig/rfc2617.xml

Last change on this file was 2564, checked in by julian.reschke@…, 6 years ago

update rfc2617.xml (ABNF alignment was off from published version), regen all HTML

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 87.5 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
3<?rfc toc="yes"?>
4<?rfc symrefs="no"?>
5<?rfc sortrefs="no"?>
6<?rfc compact="yes"?>
7<?rfc subcompact="no"?>
8<?rfc-ext allow-markup-in-artwork="yes"?>
9<?rfc-ext include-references-in-index="yes" ?>
10
11<!DOCTYPE rfc [
12  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
13  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
14  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
15  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
16  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
17  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
18  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
19  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
20  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
21  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
22]>
23<rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation='rfc2629grddl.xslt'>
24  <front>
25    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
26    <author initials="J." surname="Franks" fullname="John Franks">
27      <organization>Northwestern University, Department of Mathematics</organization>
28      <address>
29        <postal>
30          <street>Northwestern University</street>
31          <city>Evanston</city>
32          <region>IL</region>
33          <code>60208-2730</code>
34          <country>USA</country>
35        </postal>
36        <email>john@math.nwu.edu</email>
37      </address>
38    </author>
39    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
40      <organization>Verisign Inc.</organization>
41      <address>
42        <postal>
43          <street>301 Edgewater Place</street>
44          <street>Suite 210</street>
45          <city>Wakefield</city>
46          <region>MA</region>
47          <code>01880</code>
48          <country>USA</country>
49        </postal>
50        <email>pbaker@verisign.com</email>
51      </address>
52    </author>
53    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
54    <organization>AbiSource, Inc.</organization>
55      <address>
56        <postal>
57          <street>6 Dunlap Court</street>
58          <city>Savoy</city>
59          <region>IL</region>
60          <code>61874</code>
61          <country>USA</country>
62        </postal>
63        <email>jeff@AbiSource.com</email>
64      </address>
65    </author>
66    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
67      <organization>Agranat Systems, Inc.</organization>
68      <address>
69        <postal>
70          <street>5 Clocktower Place</street>
71          <street>Suite 400</street>
72          <city>Maynard</city>
73          <region>MA</region>
74          <code>01754</code>
75          <country>USA</country>
76        </postal>
77        <email>lawrence@agranat.com</email>
78      </address>
79    </author>
80    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
81      <organization>Microsoft Corporation</organization>
82      <address>
83        <postal>
84          <street>1 Microsoft Way</street>
85          <city>Redmond</city>
86          <region>WA</region>
87          <code>98052</code>
88          <country>USA</country>
89        </postal>
90        <email>paulle@microsoft.com</email>
91      </address>
92    </author>
93    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
94      <organization>Netscape Communications Corporation</organization>
95      <address>
96        <postal>
97          <street>501 East Middlefield Road</street>
98          <city>Mountain View</city>
99          <region>CA</region>
100          <code>94043</code>
101          <country>USA</country>
102        </postal>
103      </address>
104    </author>
105    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
106      <organization>Open Market, Inc.</organization>
107      <address>
108        <postal>
109          <street>215 First Street</street>
110          <city>Cambridge</city>
111          <region>MA</region>
112          <code>02142</code>
113          <country>USA</country>
114        </postal>
115        <email>stewart@OpenMarket.com</email>
116      </address>
117    </author>
118    <date month="June" year="1999"/>
119       
120    <abstract>
121      <t>
122   "HTTP/1.0", includes the specification for a Basic Access
123   Authentication scheme. This scheme is not considered to be a secure
124   method of user authentication (unless used in conjunction with some
125   external secure system such as SSL <xref target="RFC2246"/>), as the user name and
126   password are passed over the network as cleartext.
127      </t><t>
128   This document also provides the specification for HTTP's
129   authentication framework, the original Basic authentication scheme
130   and a scheme based on cryptographic hashes, referred to as "Digest
131   Access Authentication".  It is therefore also intended to serve as a
132   replacement for RFC 2069 <xref target="RFC2069"/>.  Some optional elements specified by
133   RFC 2069 have been removed from this specification due to problems
134   found since its publication; other new elements have been added for
135   compatibility, those new elements have been made optional, but are
136   strongly recommended.
137      </t><t>
138   Like Basic, Digest access authentication verifies that both parties
139   to a communication know a shared secret (a password); unlike Basic,
140   this verification can be done without sending the password in the
141   clear, which is Basic's biggest weakness. As with most other
142   authentication protocols, the greatest sources of risks are usually
143   found not in the core protocol itself but in policies and procedures
144   surrounding its use.
145    </t>
146    </abstract>
147  </front>
148  <middle>
149 
150<section title="Access Authentication">
151
152<section title="Reliance on the HTTP/1.1 Specification">
153<t>
154   This specification is a companion to the HTTP/1.1 specification <xref target="RFC2616"/>.
155   It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x:rel="#notation.abnf"/> of that document, and relies on
156   both the non-terminals defined in that document and other aspects of
157   the HTTP/1.1 specification.
158</t>
159</section>
160
161<section title="Access Authentication Framework" anchor="access.authentication.framework">
162<t>
163   HTTP provides a simple challenge-response authentication mechanism
164   that &MAY; be used by a server to challenge a client request and by a
165   client to provide authentication information. It uses an extensible,
166   case-insensitive token to identify the authentication scheme,
167   followed by a comma-separated list of attribute-value pairs which
168   carry the parameters necessary for achieving authentication via that
169   scheme.
170</t>
171<figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/>
172   auth-scheme    = token
173   auth-param     = token "=" ( token | quoted-string )
174</artwork></figure>
175<t>
176   The 401 (Unauthorized) response message is used by an origin server
177   to challenge the authorization of a user agent. This response &MUST;
178   include a WWW-Authenticate header field containing at least one
179   challenge applicable to the requested resource. The 407 (Proxy
180   Authentication Required) response message is used by a proxy to
181   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
182   header field containing at least one challenge
183   applicable to the proxy for the requested resource.
184</t>
185<figure><artwork type="abnf2616"><iref item="challenge" primary="true"/>
186   challenge   = auth-scheme 1*SP 1#auth-param
187</artwork></figure>
188<t>
189   Note: User agents will need to take special care in parsing the WWW-Authenticate
190   or Proxy-Authenticate header field value if it contains
191   more than one challenge, or if more than one WWW-Authenticate header
192   field is provided, since the contents of a challenge may itself
193   contain a comma-separated list of authentication parameters.
194</t>
195<t>
196   The authentication parameter realm is defined for all authentication
197   schemes:
198</t>
199<figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/>
200   realm       = "realm" "=" realm-value
201   realm-value = quoted-string
202</artwork></figure>
203<t>
204   The realm directive (case-insensitive) is required for all
205   authentication schemes that issue a challenge. The realm value
206   (case-sensitive), in combination with the canonical root URL (the
207   absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/>
208   of <xref target="RFC2616"/>) of the server being accessed, defines the protection space.
209   These realms allow the protected resources on a server to be
210   partitioned into a set of protection spaces, each with its own
211   authentication scheme and/or authorization database. The realm value
212   is a string, generally assigned by the origin server, which may have
213   additional semantics specific to the authentication scheme. Note that
214   there may be multiple challenges with the same auth-scheme but
215   different realms.
216</t>
217<t>
218   A user agent that wishes to authenticate itself with an origin
219   server--usually, but not necessarily, after receiving a 401
220   (Unauthorized)--&MAY; do so by including an Authorization header field
221   with the request. A client that wishes to authenticate itself with a
222   proxy--usually, but not necessarily, after receiving a 407 (Proxy
223   Authentication Required)--&MAY; do so by including a Proxy-Authorization
224   header field with the request.  Both the Authorization
225   field value and the Proxy-Authorization field value consist of
226   credentials containing the authentication information of the client
227   for the realm of the resource being requested. The user agent &MUST;
228   choose to use one of the challenges with the strongest auth-scheme it
229   understands and request credentials from the user based upon that
230   challenge.
231</t>
232<figure><artwork type="abnf2616"><iref item="credentials" primary="true"/>
233   credentials = auth-scheme #auth-param
234</artwork></figure>
235<t>
236  <list><t>
237      Note that many browsers will only recognize Basic and will require
238      that it be the first auth-scheme presented. Servers should only
239      include Basic if it is minimally acceptable.
240  </t></list>
241</t>
242<t>
243   The protection space determines the domain over which credentials can
244   be automatically applied. If a prior request has been authorized, the
245   same credentials &MAY; be reused for all other requests within that
246   protection space for a period of time determined by the
247   authentication scheme, parameters, and/or user preference. Unless
248   otherwise defined by the authentication scheme, a single protection
249   space cannot extend outside the scope of its server.
250</t>
251<t>
252   If the origin server does not wish to accept the credentials sent
253   with a request, it &SHOULD; return a 401 (Unauthorized) response. The
254   response &MUST; include a WWW-Authenticate header field containing at
255   least one (possibly new) challenge applicable to the requested
256   resource. If a proxy does not accept the credentials sent with a
257   request, it &SHOULD; return a 407 (Proxy Authentication Required). The
258   response &MUST; include a Proxy-Authenticate header field containing a
259   (possibly new) challenge applicable to the proxy for the requested
260   resource.
261</t>
262<t>
263   The HTTP protocol does not restrict applications to this simple
264   challenge-response mechanism for access authentication. Additional
265   mechanisms &MAY; be used, such as encryption at the transport level or
266   via message encapsulation, and with additional header fields
267   specifying authentication information. However, these additional
268   mechanisms are not defined by this specification.
269</t>
270<t>
271   Proxies &MUST; be completely transparent regarding user agent
272   authentication by origin servers. That is, they must forward the
273   WWW-Authenticate and Authorization headers untouched, and follow the
274   rules found in section <xref target="RFC2616" x:fmt="number" x:rel="#header.authorization"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and
275   the Proxy-Authorization header fields are hop-by-hop headers (see
276   section <xref target="RFC2616" x:fmt="number" x:rel="#end-to-end.and.hop-by-hop.headers"/> of <xref target="RFC2616"/>).
277</t>
278</section>
279</section>
280   
281<section title="Basic Authentication Scheme">
282<t>
283   The "basic" authentication scheme is based on the model that the
284   client must authenticate itself with a user-ID and a password for
285   each realm.  The realm value should be considered an opaque string
286   which can only be compared for equality with other realms on that
287   server. The server will service the request only if it can validate
288   the user-ID and password for the protection space of the Request-URI.
289   There are no optional authentication parameters.
290</t>
291<t>
292   For Basic, the framework above is utilized as follows:
293</t>
294<figure><artwork type="abnf2616"><iref item="challenge"/><iref item="credentials"/>
295   challenge   = "Basic" realm
296   credentials = "Basic" basic-credentials
297</artwork></figure>
298<t>
299   Upon receipt of an unauthorized request for a URI within the
300   protection space, the origin server &MAY; respond with a challenge like
301   the following:
302</t>
303<figure><artwork type="example">
304   WWW-Authenticate: Basic realm="WallyWorld"
305</artwork></figure>
306<t>
307   where "WallyWorld" is the string assigned by the server to identify
308   the protection space of the Request-URI. A proxy may respond with the
309   same challenge using the Proxy-Authenticate header field.
310</t>
311<t>
312   To receive authorization, the client sends the userid and password,
313   separated by a single colon (":") character, within a base64 <xref target="RFC2396"/>
314   encoded string in the credentials.
315</t>
316<figure><artwork type="abnf2616"><iref item="basic-credentials" primary="true"
317/><iref item="base64-user-pass" primary="true"
318/><iref item="user-pass" primary="true"
319/><iref item="userid" primary="true"
320/><iref item="password" primary="true"/>
321   basic-credentials = base64-user-pass
322   base64-user-pass  = &lt;base64 <xref target="RFC2045"/> encoding of user-pass,
323                    except not limited to 76 char/line>
324   user-pass   = userid ":" password
325   userid      = *&lt;TEXT excluding ":">
326   password    = *TEXT
327</artwork></figure>
328<t>
329   Userids might be case sensitive.
330</t>
331<t>
332   If the user agent wishes to send the userid "Aladdin" and password
333   "open sesame", it would use the following header field:
334</t>
335<figure><artwork type="example">
336   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
337</artwork></figure>
338<t>
339   A client &SHOULD; assume that all paths at or deeper than the depth of
340   the last symbolic element in the path field of the Request-URI also
341   are within the protection space specified by the Basic realm value of
342   the current challenge. A client &MAY; preemptively send the
343   corresponding Authorization header with requests for resources in
344   that space without receipt of another challenge from the server.
345   Similarly, when a client sends a request to a proxy, it may reuse a
346   userid and password in the Proxy-Authorization header field without
347   receiving another challenge from the proxy server. See <xref target="security.considerations"/> for
348   security considerations associated with Basic authentication.
349</t>
350</section>
351   
352<section title="Digest Access Authentication Scheme">
353
354<section title="Introduction">
355
356<section title="Purpose">
357<t>
358   The protocol referred to as "HTTP/1.0" includes the specification for
359   a Basic Access Authentication scheme<xref target="RFC1945"/>. That scheme is not
360   considered to be a secure method of user authentication, as the user
361   name and password are passed over the network in an unencrypted form.
362   This section provides the specification for a scheme that does not
363   send the password in cleartext,  referred to as "Digest Access
364   Authentication".
365</t>
366<t>
367   The Digest Access Authentication scheme is not intended to be a
368   complete answer to the need for security in the World Wide Web. This
369   scheme provides no encryption of message content. The intent is
370   simply to create an access authentication method that avoids the most
371   serious flaws of Basic authentication.
372</t>
373</section>
374
375<section title="Overall Operation">
376<t>
377   Like Basic Access Authentication, the Digest scheme is based on a
378   simple challenge-response paradigm. The Digest scheme challenges
379   using a nonce value. A valid response contains a checksum (by
380   default, the MD5 checksum) of the username, the password, the given
381   nonce value, the HTTP method, and the requested URI. In this way, the
382   password is never sent in the clear. Just as with the Basic scheme,
383   the username and password must be prearranged in some fashion not
384   addressed by this document.
385</t>
386</section>
387
388<section title="Representation of digest values">
389<t>
390   An optional header allows the server to specify the algorithm used to
391   create the checksum or digest. By default the MD5 algorithm is used
392   and that is the only algorithm described in this document.
393</t>
394<t>
395   For the purposes of this document, an MD5 digest of 128 bits is
396   represented as 32 ASCII printable characters. The bits in the 128 bit
397   digest are converted from most significant to least significant bit,
398   four bits at a time to their ASCII presentation as follows. Each four
399   bits is represented by its familiar hexadecimal notation from the
400   characters 0123456789abcdef. That is, binary 0000 gets represented by
401   the character '0', 0001, by '1', and so on up to the representation
402   of 1111 as 'f'.
403</t>
404</section>
405
406<section title="Limitations">
407<t>
408   The Digest authentication scheme described in this document suffers
409   from many known limitations. It is intended as a replacement for
410   Basic authentication and nothing more. It is a password-based system
411   and (on the server side) suffers from all the same problems of any
412   password system. In particular, no provision is made in this protocol
413   for the initial secure arrangement between user and server to
414   establish the user's password.
415</t>
416<t>
417   Users and implementors should be aware that this protocol is not as
418   secure as Kerberos, and not as secure as any client-side private-key
419   scheme. Nevertheless it is better than nothing, better than what is
420   commonly used with telnet and ftp, and better than Basic
421   authentication.
422</t>
423</section>
424</section>
425
426<section title="Specification of Digest Headers" anchor="specification.of.digest.headers">
427<t>
428   The Digest Access Authentication scheme is conceptually similar to
429   the Basic scheme. The formats of the modified WWW-Authenticate header
430   line and the Authorization header line are specified below. In
431   addition, a new header, Authentication-Info, is specified.
432</t>
433
434<section title="The WWW-Authenticate Response Header" anchor="the.www-authenticate.response.header">
435<iref item="Headers" subitem="WWW-Authenticate" primary="true"/>
436<iref item="WWW-Authenticate header" primary="true"/>
437<t>
438   If a server receives a request for an access-protected object, and an
439   acceptable Authorization header is not sent, the server responds with
440   a "401 Unauthorized" status code, and a WWW-Authenticate header as
441   per the framework defined above, which for the digest scheme is
442   utilized as follows:
443</t>
444<figure><artwork type="abnf2616"><iref item="challenge"/><iref item="digest-challenge" primary="true"
445/><iref item="domain" primary="true"
446/><iref item="URI" primary="true"
447/><iref item="nonce" primary="true"
448/><iref item="nonce-value" primary="true"
449/><iref item="opaque" primary="true"
450/><iref item="stale" primary="true"
451/><iref item="algorithm" primary="true"
452/><iref item="qop-options" primary="true"
453/><iref item="qop-value" primary="true"/>
454   challenge        =  "Digest" digest-challenge
455 
456   digest-challenge  = 1#( realm | [ domain ] | nonce |
457                       [ opaque ] |[ stale ] | [ algorithm ] |
458                       [ qop-options ] | [auth-param] )
459 
460 
461   domain            = "domain" "=" &lt;"> URI ( 1*SP URI ) &lt;">
462   URI               = absoluteURI | abs_path
463   nonce             = "nonce" "=" nonce-value
464   nonce-value       = quoted-string
465   opaque            = "opaque" "=" quoted-string
466   stale             = "stale" "=" ( "true" | "false" )
467   algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
468                        token )
469   qop-options       = "qop" "=" &lt;"> 1#qop-value &lt;">
470   qop-value         = "auth" | "auth-int" | token
471</artwork></figure>
472<t>
473   The meanings of the values of the directives used above are as
474   follows:
475</t>
476<t>
477   realm
478   <list><t>
479     A string to be displayed to users so they know which username and
480     password to use. This string should contain at least the name of
481     the host performing the authentication and might additionally
482     indicate the collection of users who might have access. An example
483     might be "registered_users@gotham.news.com".
484   </t></list>
485</t>
486<t>
487   domain
488   <list><t>
489     A quoted, space-separated list of URIs, as specified in RFC XURI
490     <xref target="RFC2396"/>, that define the protection space.  If a URI is an abs_path, it
491     is relative to the canonical root URL (see <xref target="access.authentication.framework"/> above) of
492     the server being accessed. An absoluteURI in this list may refer to
493     a different server than the one being accessed. The client can use
494     this list to determine the set of URIs for which the same
495     authentication information may be sent: any URI that has a URI in
496     this list as a prefix (after both have been made absolute) may be
497     assumed to be in the same protection space. If this directive is
498     omitted or its value is empty, the client should assume that the
499     protection space consists of all URIs on the responding server.
500     This directive is not meaningful in Proxy-Authenticate headers, for
501     which the protection space is always the entire proxy; if present
502     it should be ignored.
503   </t></list>
504</t>
505<t>
506   nonce
507   <list><t>
508     A server-specified data string which should be uniquely generated
509     each time a 401 response is made. It is recommended that this
510     string be base64 or hexadecimal data. Specifically, since the
511     string is passed in the header lines as a quoted string, the
512     double-quote character is not allowed.
513  </t>
514  <t>
515     The contents of the nonce are implementation dependent. The quality
516     of the implementation depends on a good choice. A nonce might, for
517     example, be constructed as the base 64 encoding of
518  </t>
519  <t><figure><artwork type="code" x:indent-with="   ">
520   time-stamp H(time-stamp ":" ETag ":" private-key)
521</artwork></figure></t>
522  <t>
523     where time-stamp is a server-generated time or other non-repeating
524     value, ETag is the value of the HTTP ETag header associated with
525     the requested entity, and private-key is data known only to the
526     server.  With a nonce of this form a server would recalculate the
527     hash portion after receiving the client authentication header and
528     reject the request if it did not match the nonce from that header
529     or if the time-stamp value is not recent enough. In this way the
530     server can limit the time of the nonce's validity. The inclusion of
531     the ETag prevents a replay request for an updated version of the
532     resource.  (Note: including the IP address of the client in the
533     nonce would appear to offer the server the ability to limit the
534     reuse of the nonce to the same client that originally got it.
535     However, that would break proxy farms, where requests from a single
536     user often go through different proxies in the farm. Also, IP
537     address spoofing is not that hard.)
538  </t>
539  <t>
540     An implementation might choose not to accept a previously used
541     nonce or a previously used digest, in order to protect against a
542     replay attack. Or, an implementation might choose to use one-time
543     nonces or digests for POST or PUT requests and a time-stamp for GET
544     requests.  For more details on the issues involved see <xref target="security.considerations"/>
545     of this document.
546  </t>
547  <t>
548     The nonce is opaque to the client.
549   </t></list></t>
550<t>
551   opaque
552   <list><t>
553     A string of data, specified by the server, which should be returned
554     by the client unchanged in the Authorization header of subsequent
555     requests with URIs in the same protection space. It is recommended
556     that this string be base64 or hexadecimal data.
557   </t></list>
558</t>
559<t>
560   stale
561   <list><t>
562     A flag, indicating that the previous request from the client was
563     rejected because the nonce value was stale. If stale is TRUE
564     (case-insensitive), the client may wish to simply retry the request
565     with a new encrypted response, without reprompting the user for a
566     new username and password. The server should only set stale to TRUE
567     if it receives a request for which the nonce is invalid but with a
568     valid digest for that nonce (indicating that the client knows the
569     correct username/password). If stale is FALSE, or anything other
570     than TRUE, or the stale directive is not present, the username
571     and/or password are invalid, and new values must be obtained.
572   </t></list>
573</t>
574<t>
575   algorithm
576   <list><t>
577     A string indicating a pair of algorithms used to produce the digest
578     and a checksum. If this is not present it is assumed to be "MD5".
579     If the algorithm is not understood, the challenge should be ignored
580     (and a different one used, if there is more than one).
581    </t>
582    <t>
583     In this document the string obtained by applying the digest
584     algorithm to the data "data" with secret "secret" will be denoted
585     by KD(secret, data), and the string obtained by applying the
586     checksum algorithm to the data "data" will be denoted H(data). The
587     notation unq(X) means the value of the quoted-string X without the
588     surrounding quotes.
589    </t>
590    <t>
591     For the "MD5" and "MD5-sess" algorithms
592    </t>
593    <t><figure><artwork type="code" x:indent-with="    ">
594       H(data) = MD5(data)
595</artwork></figure></t>
596    <t>
597     and
598    </t>
599    <t><figure><artwork type="code" x:indent-with="    ">
600       KD(secret, data) = H(concat(secret, ":", data))
601</artwork></figure></t>
602    <t>
603     i.e., the digest is the MD5 of the secret concatenated with a colon
604     concatenated with the data. The "MD5-sess" algorithm is intended to
605     allow efficient 3rd party authentication servers; for the
606     difference in usage, see the description in <xref target="A1"/>.
607   </t></list>
608</t>
609<t>
610   qop-options
611   <list><t>
612     This directive is optional, but is made so only for backward
613     compatibility with RFC 2069 <xref target="RFC2069"/>; it &SHOULD; be used by all
614     implementations compliant with this version of the Digest scheme.
615     If present, it is a quoted string of one or more tokens indicating
616     the "quality of protection" values supported by the server.  The
617     value "auth" indicates authentication; the value "auth-int"
618     indicates authentication with integrity protection; see the
619     descriptions below for calculating the response directive value for
620     the application of this choice. Unrecognized options &MUST; be
621     ignored.
622   </t></list>
623</t>
624<t>
625   auth-param
626   <list><t>
627     This directive allows for future extensions. Any unrecognized
628     directive &MUST; be ignored.
629   </t></list>
630</t>
631</section>
632
633<section title="The Authorization Request Header" anchor="the.authorization.request.header">
634<iref item="Headers" subitem="Authorization" primary="true"/>
635<iref item="Authorization header" primary="true"/>
636<t>
637   The client is expected to retry the request, passing an Authorization
638   header line, which is defined according to the framework above,
639   utilized as follows.
640</t>
641<figure><artwork type="abnf2616"><iref item="credentials"
642/><iref item="digest-response" primary="true"
643/><iref item="username" primary="true"
644/><iref item="username-value" primary="true"
645/><iref item="digest-uri" primary="true"
646/><iref item="digest-uri-value" primary="true"
647/><iref item="message-qop" primary="true"
648/><iref item="cnonce" primary="true"
649/><iref item="cnonce-value" primary="true"
650/><iref item="nonce-count" primary="true"
651/><iref item="nc-value" primary="true"
652/><iref item="response" primary="true"
653/><iref item="request-digest" primary="true"
654/><iref item="LHEX" primary="true"/>
655    credentials      = "Digest" digest-response
656    digest-response  = 1#( username | realm | nonce | digest-uri
657                    | response | [ algorithm ] | [cnonce] |
658                    [opaque] | [message-qop] |
659                       [nonce-count]  | [auth-param] )
660   
661    username         = "username" "=" username-value
662    username-value   = quoted-string
663    digest-uri       = "uri" "=" digest-uri-value
664    digest-uri-value = request-uri   ; As specified by HTTP/1.1
665    message-qop      = "qop" "=" qop-value
666    cnonce           = "cnonce" "=" cnonce-value
667    cnonce-value     = nonce-value
668    nonce-count      = "nc" "=" nc-value
669    nc-value         = 8LHEX
670    response         = "response" "=" request-digest
671    request-digest = &lt;"> 32LHEX &lt;">
672    LHEX             =  "0" | "1" | "2" | "3" |
673                       "4" | "5" | "6" | "7" |
674                       "8" | "9" | "a" | "b" |
675                       "c" | "d" | "e" | "f"
676</artwork></figure>
677<t>
678   The values of the opaque and algorithm fields must be those supplied
679   in the WWW-Authenticate response header for the entity being
680   requested.
681</t>
682<t>
683   response
684   <list><t>
685     A string of 32 hex digits computed as defined below, which proves
686     that the user knows a password
687   </t></list>
688</t>
689<t>
690   username
691   <list><t>
692     The user's name in the specified realm.
693   </t></list>
694</t>
695<t>
696   digest-uri
697   <list><t>
698     The URI from Request-URI of the Request-Line; duplicated here
699     because proxies are allowed to change the Request-Line in transit.
700   </t></list>
701</t>
702<t>
703   qop
704   <list><t>
705     Indicates what "quality of protection" the client has applied to
706     the message. If present, its value &MUST; be one of the alternatives
707     the server indicated it supports in the WWW-Authenticate header.
708     These values affect the computation of the request-digest. Note
709     that this is a single token, not a quoted list of alternatives as
710     in WWW-Authenticate.  This directive is optional in order to
711     preserve backward compatibility with a minimal implementation of
712     RFC 2069 <xref target="RFC2069"/>, but &SHOULD; be used if the server indicated that qop
713     is supported by providing a qop directive in the WWW-Authenticate
714     header field.
715   </t></list>
716</t>
717<t>
718   cnonce
719   <list><t>
720     This &MUST; be specified if a qop directive is sent (see above), and
721     &MUST-NOT; be specified if the server did not send a qop directive in
722     the WWW-Authenticate header field.  The cnonce-value is an opaque
723     quoted string value provided by the client and used by both client
724     and server to avoid chosen plaintext attacks, to provide mutual
725     authentication, and to provide some message integrity protection.
726     See the descriptions below of the calculation of the response-digest
727     and request-digest values.
728   </t></list>
729</t>
730<t>
731   nonce-count
732   <list><t>
733     This &MUST; be specified if a qop directive is sent (see above), and
734     &MUST-NOT; be specified if the server did not send a qop directive in
735     the WWW-Authenticate header field.  The nc-value is the hexadecimal
736     count of the number of requests (including the current request)
737     that the client has sent with the nonce value in this request.  For
738     example, in the first request sent in response to a given nonce
739     value, the client sends "nc=00000001".  The purpose of this
740     directive is to allow the server to detect request replays by
741     maintaining its own copy of this count - if the same nc-value is
742     seen twice, then the request is a replay.   See the description
743     below of the construction of the request-digest value.
744   </t></list>
745</t>
746<t>
747   auth-param
748   <list><t>
749     This directive allows for future extensions. Any unrecognized
750     directive &MUST; be ignored.
751   </t></list>
752</t>
753<t>
754   If a directive or its value is improper, or required directives are
755   missing, the proper response is 400 Bad Request. If the request-digest
756   is invalid, then a login failure should be logged, since
757   repeated login failures from a single client may indicate an attacker
758   attempting to guess passwords.
759</t>
760<t>
761   The definition of request-digest above indicates the encoding for its
762   value. The following definitions show how the value is computed.
763</t>
764
765<section title="Request-Digest" anchor="request-digest">
766<t>
767   If the "qop" value is "auth" or "auth-int":
768</t>
769<figure><artwork type="abnf2616">
770   request-digest  = &lt;"> &lt; KD ( H(A1),     unq(nonce-value)
771                                       ":" nc-value
772                                       ":" unq(cnonce-value)
773                                       ":" unq(qop-value)
774                                       ":" H(A2)
775                               ) &lt;">
776</artwork></figure>
777<t>
778   If the "qop" directive is not present (this construction is for
779   compatibility with RFC 2069):
780</t>
781<figure><artwork type="abnf2616">
782  request-digest  =
783             &lt;"> &lt; KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
784&lt;">
785</artwork></figure>
786<t>
787   See below for the definitions for A1 and A2.
788</t>
789</section>
790
791<section title="A1" anchor="A1">
792<t>
793   If the "algorithm" directive's value is "MD5" or is unspecified, then
794   A1 is:
795</t>
796<figure><artwork type="abnf2616">
797   A1       = unq(username-value) ":" unq(realm-value) ":" passwd
798</artwork></figure>
799<t>
800   where
801</t>
802<figure><artwork type="abnf2616">
803   passwd   = &lt; user's password >
804</artwork></figure>
805<t>
806   If the "algorithm" directive's value is "MD5-sess", then A1 is
807   calculated only once - on the first request by the client following
808   receipt of a WWW-Authenticate challenge from the server.  It uses the
809   server nonce from that challenge, and the first client nonce value to
810   construct A1 as follows:
811</t>
812<figure><artwork type="abnf2616">
813   A1       = H( unq(username-value) ":" unq(realm-value)
814                  ":" passwd )
815                  ":" unq(nonce-value) ":" unq(cnonce-value)
816</artwork></figure>
817<t>
818   This creates a 'session key' for the authentication of subsequent
819   requests and responses which is different for each "authentication
820   session", thus limiting the amount of material hashed with any one
821   key.  (Note: see further discussion of the authentication session in
822   <xref target="digest.operation"/>) Because the server need only use the hash of the user
823   credentials in order to create the A1 value, this construction could
824   be used in conjunction with a third party authentication service so
825   that the web server would not need the actual password value.  The
826   specification of such a protocol is beyond the scope of this
827   specification.
828</t>
829</section>
830
831<section title="A2">
832<t>
833   If the "qop" directive's value is "auth" or is unspecified, then A2
834   is:
835</t>
836<figure><artwork type="abnf2616">
837   A2       = Method ":" digest-uri-value
838</artwork></figure>
839<t>
840   If the "qop" value is "auth-int", then A2 is:
841</t>
842<figure><artwork type="abnf2616">
843   A2       = Method ":" digest-uri-value ":" H(entity-body)
844</artwork></figure>
845</section>
846
847
848<section title="Directive values and quoted-string">
849<t>
850   Note that the value of many of the directives, such as "username-value",
851   are defined as a "quoted-string". However, the "unq" notation
852   indicates that surrounding quotation marks are removed in forming the
853   string A1. Thus if the Authorization header includes the fields
854</t>
855<figure><artwork type="example">
856  username="Mufasa", realm=myhost@testrealm.com
857</artwork></figure>
858<t>
859   and the user Mufasa has password "Circle Of Life" then H(A1) would be
860   H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks
861   in the digested string.
862</t>
863<t>
864   No white space is allowed in any of the strings to which the digest
865   function H() is applied unless that white space exists in the quoted
866   strings or entity body whose contents make up the string to be
867   digested. For example, the string A1 illustrated above must be
868</t>
869<figure><artwork type="example">
870     Mufasa:myhost@testrealm.com:Circle Of Life
871</artwork></figure>
872<t>
873   with no white space on either side of the colons, but with the white
874   space between the words used in the password value.  Likewise, the
875   other strings digested by H() must not have white space on either
876   side of the colons which delimit their fields unless that white space
877   was in the quoted strings or entity body being digested.
878</t>
879<t>
880   Also note that if integrity protection is applied (qop=auth-int), the
881   H(entity-body) is the hash of the entity body, not the message body -
882   it is computed before any transfer encoding is applied by the sender
883   and after it has been removed by the recipient. Note that this
884   includes multipart boundaries and embedded headers in each part of
885   any multipart content-type.
886</t>
887</section>
888
889<section title="Various considerations">
890<t>
891   The "Method" value is the HTTP request method as specified in section
892   <xref target="RFC2616" x:fmt="number" x:rel="#method"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the
893   request line as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of <xref target="RFC2616"/>. This may be "*",
894   an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of
895   <xref target="RFC2616"/>, but it &MUST; agree with the Request-URI. In particular, it &MUST;
896   be an "absoluteURL" if the Request-URI is an "absoluteURL". The
897   "cnonce-value" is an optional  client-chosen value whose purpose is
898   to foil chosen plaintext attacks.
899</t>
900<t>
901   The authenticating server must assure that the resource designated by
902   the "uri" directive is the same as the resource specified in the
903   Request-Line; if they are not, the server &SHOULD; return a 400 Bad
904   Request error. (Since this may be a symptom of an attack, server
905   implementers may want to consider logging such errors.) The purpose
906   of duplicating information from the request URL in this field is to
907   deal with the possibility that an intermediate proxy may alter the
908   client's Request-Line. This altered (but presumably semantically
909   equivalent) request would not result in the same digest as that
910   calculated by the client.
911</t>
912<t>
913   Implementers should be aware of how authenticated transactions
914   interact with shared caches. The HTTP/1.1 protocol specifies that
915   when a shared cache (see section <xref target="RFC2616" x:fmt="number" x:rel="#shared.and.non-shared.caches"/> of <xref target="RFC2616"/>) has received a request
916   containing an Authorization header and a response from relaying that
917   request, it &MUST-NOT; return that response as a reply to any other
918   request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x:rel="#header.cache-control"/> of <xref target="RFC2616"/>)
919   directives was present in the response. If the original response
920   included the "must-revalidate" Cache-Control directive, the cache &MAY;
921   use the entity of that response in replying to a subsequent request,
922   but &MUST; first revalidate it with the origin server, using the
923   request headers from the new request to allow the origin server to
924   authenticate the new request. Alternatively, if the original response
925   included the "public" Cache-Control directive, the response entity
926   &MAY; be returned in reply to any subsequent request.
927</t>
928</section>
929</section>
930
931<section title="The Authentication-Info Header">
932<iref item="Headers" subitem="Authentication-Info" primary="true"/>
933<iref item="Authentication-Info header" primary="true"/>
934<t>
935   The Authentication-Info header is used by the server to communicate
936   some information regarding the successful authentication in the
937   response.
938</t>
939<figure><artwork type="abnf2616"><iref item="Authentication-Info" primary="true"
940/><iref item="auth-info" primary="true"
941/><iref item="nextnonce" primary="true"
942/><iref item="response-auth" primary="true"
943/><iref item="response-digest" primary="true"/>
944     AuthenticationInfo = "Authentication-Info" ":" auth-info
945     auth-info          = 1#(nextnonce | [ message-qop ]
946                            | [ response-auth ] | [ cnonce ]
947                            | [nonce-count] )
948     nextnonce          = "nextnonce" "=" nonce-value
949     response-auth      = "rspauth" "=" response-digest
950     response-digest    = &lt;"> *LHEX &lt;">
951</artwork></figure>
952<t>
953   The value of the nextnonce directive is the nonce the server wishes
954   the client to use for a future authentication response.  The server
955   may send the Authentication-Info header with a nextnonce field as a
956   means of implementing one-time or otherwise changing  nonces. If the
957   nextnonce field is present the client &SHOULD; use it when constructing
958   the Authorization header for its next request. Failure of the client
959   to do so may result in a request to re-authenticate from the server
960   with the "stale=TRUE".
961</t>
962<t>
963  <list><t>
964     Server implementations should carefully consider the performance
965     implications of the use of this mechanism; pipelined requests will
966     not be possible if every response includes a nextnonce directive
967     that must be used on the next request received by the server.
968     Consideration should be given to the performance vs. security
969     tradeoffs of allowing an old nonce value to be used for a limited
970     time to permit request pipelining.  Use of the nonce-count can
971     retain most of the security advantages of a new server nonce
972     without the deleterious affects on pipelining.
973  </t></list>
974</t>
975<t>
976   message-qop
977</t>
978<t><list><t>
979     Indicates the "quality of protection" options applied to the
980     response by the server.  The value "auth" indicates authentication;
981     the value "auth-int" indicates authentication with integrity
982     protection. The server &SHOULD; use the same value for the message-qop
983     directive in the response as was sent by the client in the
984     corresponding request.
985</t></list></t>
986<t>
987   The optional response digest in the "response-auth" directive
988   supports mutual authentication -- the server proves that it knows the
989   user's secret, and with qop=auth-int also provides limited integrity
990   protection of the response. The "response-digest" value is calculated
991   as for the "request-digest" in the Authorization header, except that
992   if "qop=auth" or is not specified in the Authorization header for the
993   request, A2 is
994</t>
995<figure><artwork type="abnf2616">
996   A2       = ":" digest-uri-value
997</artwork></figure>
998<t>
999   and if "qop=auth-int", then A2 is
1000</t>
1001<figure><artwork type="abnf2616">
1002   A2       = ":" digest-uri-value ":" H(entity-body)
1003</artwork></figure>
1004<t>
1005   where "digest-uri-value" is the value of the "uri" directive on the
1006   Authorization header in the request. The "cnonce-value" and "nc-value"
1007   &MUST; be the ones for the client request to which this message
1008   is the response. The "response-auth", "cnonce", and "nonce-count"
1009   directives &MUST; BE present if "qop=auth" or "qop=auth-int" is
1010   specified.
1011</t>
1012<t>
1013   The Authentication-Info header is allowed in the trailer of an HTTP
1014   message transferred via chunked transfer-coding.
1015</t>
1016</section>
1017</section>
1018
1019<section title="Digest Operation" anchor="digest.operation">
1020<t>
1021   Upon receiving the Authorization header, the server may check its
1022   validity by looking up the password that corresponds to the submitted
1023   username. Then, the server must perform the same digest operation
1024   (e.g., MD5) performed by the client, and compare the result to the
1025   given request-digest value.
1026</t>
1027<t>
1028   Note that the HTTP server does not actually need to know the user's
1029   cleartext password. As long as H(A1) is available to the server, the
1030   validity of an Authorization header may be verified.
1031</t>
1032<t>
1033   The client response to a WWW-Authenticate challenge for a protection
1034   space starts an authentication session with that protection space.
1035   The authentication session lasts until the client receives another
1036   WWW-Authenticate challenge from any server in the protection space. A
1037   client should remember the username, password, nonce, nonce count and
1038   opaque values associated with an authentication session to use to
1039   construct the Authorization header in future requests within that
1040   protection space. The Authorization header may be included
1041   preemptively; doing so improves server efficiency and avoids extra
1042   round trips for authentication challenges. The server may choose to
1043   accept the old Authorization header information, even though the
1044   nonce value included might not be fresh. Alternatively, the server
1045   may return a 401 response with a new nonce value, causing the client
1046   to retry the request; by specifying stale=TRUE with this response,
1047   the server tells the client to retry with the new nonce, but without
1048   prompting for a new username and password.
1049</t>
1050<t>
1051   Because the client is required to return the value of the opaque
1052   directive given to it by the server for the duration of a session,
1053   the opaque data may be used to transport authentication session state
1054   information. (Note that any such use can also be accomplished more
1055   easily and safely by including the state in the nonce.) For example,
1056   a server could be responsible for authenticating content that
1057   actually sits on another server. It would achieve this by having the
1058   first 401 response include a domain directive whose value includes a
1059   URI on the second server, and an opaque directive whose value
1060   contains the state information. The client will retry the request, at
1061   which time the server might respond with a 301/302 redirection,
1062   pointing to the URI on the second server. The client will follow the
1063   redirection, and pass an Authorization header , including the
1064   &lt;opaque> data.
1065</t>
1066<t>
1067   As with the basic scheme, proxies must be completely transparent in
1068   the Digest access authentication scheme. That is, they must forward
1069   the WWW-Authenticate, Authentication-Info and Authorization headers
1070   untouched. If a proxy wants to authenticate a client before a request
1071   is forwarded to the server, it can be done using the Proxy-Authenticate
1072   and Proxy-Authorization headers described in <xref target="proxy-authentication.and.proxy-authorization"/>
1073   below.
1074</t>
1075</section>
1076
1077<section title="Security Protocol Negotiation">
1078<t>
1079   It is useful for a server to be able to know which security schemes a
1080   client is capable of handling.
1081</t>
1082<t>
1083   It is possible that a server may want to require Digest as its
1084   authentication method, even if the server does not know that the
1085   client supports it. A client is encouraged to fail gracefully if the
1086   server specifies only authentication schemes it cannot handle.
1087</t>
1088</section>
1089
1090<section title="Example" anchor="specification.of.digest.headers.example">
1091<t>
1092   The following example assumes that an access-protected document is
1093   being requested from the server via a GET request. The URI of the
1094   document is "http://www.nowhere.org/dir/index.html". Both client and
1095   server know that the username for this document is "Mufasa", and the
1096   password is "Circle Of Life" (with one space between each of the
1097   three words).
1098</t>
1099<t>
1100   The first time the client requests the document, no Authorization
1101   header is sent, so the server responds with:
1102</t>
1103<figure><artwork type='message/http; msgytpe="response"'>
1104      HTTP/1.1 401 Unauthorized
1105      WWW-Authenticate: Digest
1106              realm="testrealm@host.com",
1107              qop="auth,auth-int",
1108              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
1109              opaque="5ccc069c403ebaf9f0171e9517f40e41"
1110</artwork></figure>
1111<t>
1112   The client may prompt the user for the username and password, after
1113   which it will respond with a new request, including the following
1114   Authorization header:
1115</t>
1116<figure><artwork type="example">
1117      Authorization: Digest username="Mufasa",
1118              realm="testrealm@host.com",
1119              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
1120              uri="/dir/index.html",
1121              qop=auth,
1122              nc=00000001,
1123              cnonce="0a4f113b",
1124              response="6629fae49393a05397450978507c4ef1",
1125              opaque="5ccc069c403ebaf9f0171e9517f40e41"
1126</artwork></figure>
1127</section>
1128
1129<section title="Proxy-Authentication and Proxy-Authorization" anchor="proxy-authentication.and.proxy-authorization">
1130<t>
1131   The digest authentication scheme may also be used for authenticating
1132   users to proxies, proxies to proxies, or proxies to origin servers by
1133   use of the Proxy-Authenticate and Proxy-Authorization headers. These
1134   headers are instances of the Proxy-Authenticate and Proxy-Authorization
1135   headers specified in sections <xref target="RFC2616" x:fmt="number" x:sec="10.33"/> and <xref target="RFC2616" x:fmt="number" x:sec="10.34"/> of the
1136   HTTP/1.1 specification <xref target="RFC2616"/> and their behavior is subject to
1137   restrictions described there. The transactions for proxy
1138   authentication are very similar to those already described. Upon
1139   receiving a request which requires authentication, the proxy/server
1140   must issue the "407 Proxy Authentication Required" response with a
1141   "Proxy-Authenticate" header.  The digest-challenge used in the
1142   Proxy-Authenticate header is the same as that for the WWW-Authenticate
1143   header as defined above in <xref target="the.www-authenticate.response.header"/>.
1144</t>
1145<t>
1146   The client/proxy must then re-issue the request with a Proxy-Authorization
1147   header, with directives as specified for the
1148   Authorization header in <xref target="the.authorization.request.header"/> above.
1149</t>
1150<t>
1151   On subsequent responses, the server sends Proxy-Authentication-Info
1152   with directives the same as those for the Authentication-Info header
1153   field.
1154</t>
1155<t>
1156   Note that in principle a client could be asked to authenticate itself
1157   to both a proxy and an end-server, but never in the same response.
1158</t>
1159</section>
1160</section>
1161   
1162<section title="Security Considerations" anchor="security.considerations">
1163
1164<section title="Authentication of Clients using Basic Authentication">
1165<t>
1166   The Basic authentication scheme is not a secure method of user
1167   authentication, nor does it in any way protect the entity, which is
1168   transmitted in cleartext across the physical network used as the
1169   carrier. HTTP does not prevent additional authentication schemes and
1170   encryption mechanisms from being employed to increase security or the
1171   addition of enhancements (such as schemes to use one-time passwords)
1172   to Basic authentication.
1173</t>
1174<t>
1175   The most serious flaw in Basic authentication is that it results in
1176   the essentially cleartext transmission of the user's password over
1177   the physical network. It is this problem which Digest Authentication
1178   attempts to address.
1179</t>
1180<t>
1181   Because Basic authentication involves the cleartext transmission of
1182   passwords it &SHOULD-NOT; be used (without enhancements) to protect
1183   sensitive or valuable information.
1184</t>
1185<t>
1186   A common use of Basic authentication is for identification purposes
1187   -- requiring the user to provide a user name and password as a means
1188   of identification, for example, for purposes of gathering accurate
1189   usage statistics on a server. When used in this way it is tempting to
1190   think that there is no danger in its use if illicit access to the
1191   protected documents is not a major concern. This is only correct if
1192   the server issues both user name and password to the users and in
1193   particular does not allow the user to choose his or her own password.
1194   The danger arises because naive users frequently reuse a single
1195   password to avoid the task of maintaining multiple passwords.
1196</t>
1197<t>
1198   If a server permits users to select their own passwords, then the
1199   threat is not only unauthorized access to documents on the server but
1200   also unauthorized access to any other resources on other systems that
1201   the user protects with the same password. Furthermore, in the
1202   server's password database, many of the passwords may also be users'
1203   passwords for other sites. The owner or administrator of such a
1204   system could therefore expose all users of the system to the risk of
1205   unauthorized access to all those sites if this information is not
1206   maintained in a secure fashion.
1207</t>
1208<t>
1209   Basic Authentication is also vulnerable to spoofing by counterfeit
1210   servers. If a user can be led to believe that he is connecting to a
1211   host containing information protected by Basic authentication when,
1212   in fact, he is connecting to a hostile server or gateway, then the
1213   attacker can request a password, store it for later use, and feign an
1214   error. This type of attack is not possible with Digest
1215   Authentication. Server implementers &SHOULD; guard against the
1216   possibility of this sort of counterfeiting by gateways or CGI
1217   scripts. In particular it is very dangerous for a server to simply
1218   turn over a connection to a gateway.  That gateway can then use the
1219   persistent connection mechanism to engage in multiple transactions
1220   with the client while impersonating the original server in a way that
1221   is not detectable by the client.
1222</t>
1223</section>
1224
1225<section title="Authentication of Clients using Digest Authentication">
1226<t>
1227   Digest Authentication does not provide a strong authentication
1228   mechanism, when compared to public key based mechanisms, for example.
1229   However, it is significantly stronger than (e.g.) CRAM-MD5, which has
1230   been proposed for use with LDAP <xref target="ref10"/>, POP and IMAP (see RFC 2195
1231   <xref target="RFC2195"/>).  It is intended to replace the much weaker and even more
1232   dangerous Basic mechanism.
1233</t>
1234<t>
1235   Digest Authentication offers no confidentiality protection beyond
1236   protecting the actual password. All of the rest of the request and
1237   response are available to an eavesdropper.
1238</t>
1239<t>
1240   Digest Authentication offers only limited integrity protection for
1241   the messages in either direction. If  qop=auth-int mechanism is used,
1242   those parts of the message used in the calculation of the WWW-Authenticate
1243   and Authorization header field response directive values
1244   (see <xref target="specification.of.digest.headers"/> above) are  protected.  Most header fields and their
1245   values could be modified as a part of a man-in-the-middle attack.
1246</t>
1247<t>
1248   Many needs for secure HTTP transactions cannot be met by Digest
1249   Authentication. For those needs TLS or SHTTP are more appropriate
1250   protocols. In particular Digest authentication cannot be used for any
1251   transaction requiring confidentiality protection.  Nevertheless many
1252   functions remain for which Digest authentication is both useful and
1253   appropriate.  Any service in present use that uses Basic should be
1254   switched to Digest as soon as practical.
1255</t>
1256</section>
1257
1258<section title="Limited Use Nonce Values">
1259<t>
1260   The Digest scheme uses a server-specified nonce to seed the
1261   generation of the request-digest value (as specified in <xref target="request-digest"/>
1262   above).  As shown in the example nonce in <xref target="the.www-authenticate.response.header"/>, the
1263   server is free to construct the nonce such that it may only be used
1264   from a particular client, for a particular resource, for a limited
1265   period of time or number of uses, or any other restrictions.  Doing
1266   so strengthens the protection provided against, for example, replay
1267   attacks (see <xref target="replay.attacks" format="counter"/>).  However, it should be noted that the method
1268   chosen for generating and checking the nonce also has performance and
1269   resource implications.  For example, a server may choose to allow
1270   each nonce value to be used only once by maintaining a record of
1271   whether or not each recently issued nonce has been returned and
1272   sending a next-nonce directive in the Authentication-Info header
1273   field of every response. This protects against even an immediate
1274   replay attack, but has a high cost checking nonce values, and perhaps
1275   more important will cause authentication failures for any pipelined
1276   requests (presumably returning a stale nonce indication).  Similarly,
1277   incorporating a request-specific element such as the Etag value for a
1278   resource limits the use of the nonce to that version of the resource
1279   and also defeats pipelining. Thus it may be useful to do so for
1280   methods with side effects but have unacceptable performance for those
1281   that do not.
1282</t>
1283</section>
1284
1285<section title="Comparison of Digest with Basic Authentication">
1286<t>
1287   Both Digest and Basic Authentication are very much on the weak end of
1288   the security strength spectrum. But a comparison between the two
1289   points out the utility, even necessity, of replacing Basic by Digest.
1290</t>
1291<t>
1292   The greatest threat to the type of transactions for which these
1293   protocols are used is network snooping. This kind of transaction
1294   might involve, for example, online access to a database whose use is
1295   restricted to paying subscribers. With Basic authentication an
1296   eavesdropper can obtain the password of the user. This not only
1297   permits him to access anything in the database, but, often worse,
1298   will permit access to anything else the user protects with the same
1299   password.
1300</t>
1301<t>
1302   By contrast, with Digest Authentication the eavesdropper only gets
1303   access to the transaction in question and not to the user's password.
1304   The information gained by the eavesdropper would permit a replay
1305   attack, but only with a request for the same document, and even that
1306   may be limited by the server's choice of nonce.
1307</t>
1308</section>
1309
1310<section title="Replay Attacks" anchor="replay.attacks">
1311<t>
1312   A replay attack against Digest authentication would usually be
1313   pointless for a simple GET request since an eavesdropper would
1314   already have seen the only document he could obtain with a replay.
1315   This is because the URI of the requested document is digested in the
1316   client request and the server will only deliver that document. By
1317   contrast under Basic Authentication once the eavesdropper has the
1318   user's password, any document protected by that password is open to
1319   him.
1320</t>
1321<t>
1322   Thus, for some purposes, it is necessary to protect against replay
1323   attacks. A good Digest implementation can do this in various ways.
1324   The server created "nonce" value is implementation dependent, but if
1325   it contains a digest of the client IP, a time-stamp, the resource
1326   ETag, and a private server key (as recommended above) then a replay
1327   attack is not simple. An attacker must convince the server that the
1328   request is coming from a false IP address and must cause the server
1329   to deliver the document to an IP address different from the address
1330   to which it believes it is sending the document. An attack can only
1331   succeed in the period before the time-stamp expires. Digesting the
1332   client IP and time-stamp in the nonce permits an implementation which
1333   does not maintain state between transactions.
1334</t>
1335<t>
1336   For applications where no possibility of replay attack can be
1337   tolerated the server can use one-time nonce values which will not be
1338   honored for a second use. This requires the overhead of the server
1339   remembering which nonce values have been used until the nonce time-stamp
1340   (and hence the digest built with it) has expired, but it
1341   effectively protects against replay attacks.
1342</t>
1343<t>
1344   An implementation must give special attention to the possibility of
1345   replay attacks with POST and PUT requests. Unless the server employs
1346   one-time or otherwise limited-use nonces and/or insists on the use of
1347   the integrity protection of qop=auth-int, an attacker could replay
1348   valid credentials from a successful request with counterfeit form
1349   data or other message body. Even with the use of integrity protection
1350   most metadata in header fields is not protected. Proper nonce
1351   generation and checking provides some protection against replay of
1352   previously used valid credentials, but see 4.8.
1353</t>
1354</section>
1355
1356<section title="Weakness Created by Multiple Authentication Schemes">
1357<t>
1358   An HTTP/1.1 server may return multiple challenges with a 401
1359   (Authenticate) response, and each challenge may use a different
1360   auth-scheme. A user agent &MUST; choose to use the strongest auth-scheme
1361   it understands and request credentials from the user based
1362   upon that challenge.
1363</t>
1364<t>
1365  <list><t>
1366      Note that many browsers will only recognize Basic and will require
1367      that it be the first auth-scheme presented. Servers should only
1368      include Basic if it is minimally acceptable.
1369  </t></list>
1370</t>
1371<t>
1372   When the server offers choices of authentication schemes using the
1373   WWW-Authenticate header, the strength of the resulting authentication
1374   is only as good as that of the of the weakest of the authentication
1375   schemes. See <xref target="man.in.the.middle"/> below for discussion of particular attack
1376   scenarios that exploit multiple authentication schemes.
1377</t>
1378</section>
1379
1380<section title="Online dictionary attacks">
1381<t>
1382   If the attacker can eavesdrop, then it can test any overheard
1383   nonce/response pairs against a list of common words. Such a list is
1384   usually much smaller than the total number of possible passwords. The
1385   cost of computing the response for each password on the list is paid
1386   once for each challenge.
1387</t>
1388<t>
1389   The server can mitigate this attack by not allowing users to select
1390   passwords that are in a dictionary.
1391</t>
1392</section>
1393
1394<section title="Man in the Middle" anchor="man.in.the.middle">
1395<t>
1396   Both Basic and Digest authentication are vulnerable to "man in the
1397   middle" (MITM) attacks, for example, from a hostile or compromised
1398   proxy. Clearly, this would present all the problems of eavesdropping.
1399   But it also offers some additional opportunities to the attacker.
1400</t>
1401<t>
1402   A possible man-in-the-middle attack would be to add a weak
1403   authentication scheme to the set of choices, hoping that the client
1404   will use one that exposes the user's credentials (e.g. password). For
1405   this reason, the client should always use the strongest scheme that
1406   it understands from the choices offered.
1407</t>
1408<t>
1409   An even better MITM attack would be to remove all offered choices,
1410   replacing them with a challenge that requests only Basic
1411   authentication, then uses the cleartext credentials from the Basic
1412   authentication to authenticate to the origin server using the
1413   stronger scheme it requested. A particularly insidious way to mount
1414   such a MITM attack would be to offer a "free" proxy caching service
1415   to gullible users.
1416</t>
1417<t>
1418   User agents should consider measures such as presenting a visual
1419   indication at the time of the credentials request of what
1420   authentication scheme is to be used, or remembering the strongest
1421   authentication scheme ever requested by a server and produce a
1422   warning message before using a weaker one. It might also be a good
1423   idea for the user agent to be configured to demand Digest
1424   authentication in general, or from specific sites.
1425</t>
1426<t>
1427   Or, a hostile proxy might spoof the client into making a request the
1428   attacker wanted rather than one the client wanted. Of course, this is
1429   still much harder than a comparable attack against Basic
1430   Authentication.
1431</t>
1432</section>
1433
1434<section title="Chosen plaintext attacks">
1435<t>
1436   With Digest authentication, a MITM or a malicious server can
1437   arbitrarily choose the nonce that the client will use to compute the
1438   response. This is called a "chosen plaintext" attack. The ability to
1439   choose the nonce is known to make cryptanalysis much easier <xref target="ref8"/>.
1440</t>
1441<t>
1442   However, no way to analyze the MD5 one-way function used by Digest
1443   using chosen plaintext is currently known.
1444</t>
1445<t>
1446   The countermeasure against this attack is for clients to be
1447   configured to require the use of the optional "cnonce" directive;
1448   this allows the client to vary the input to the hash in a way not
1449   chosen by the attacker.
1450</t>
1451</section>
1452
1453<section title="Precomputed dictionary attacks">
1454<t>
1455   With Digest authentication, if the attacker can execute a chosen
1456   plaintext attack, the attacker can precompute the response for many
1457   common words to a nonce of its choice, and store a dictionary of
1458   (response, password) pairs. Such precomputation can often be done in
1459   parallel on many machines. It can then use the chosen plaintext
1460   attack to acquire a response corresponding to that challenge, and
1461   just look up the password in the dictionary. Even if most passwords
1462   are not in the dictionary, some might be. Since the attacker gets to
1463   pick the challenge, the cost of computing the response for each
1464   password on the list can be amortized over finding many passwords. A
1465   dictionary with 100 million password/response pairs would take about
1466   3.2 gigabytes of disk storage.
1467</t>
1468<t>
1469   The countermeasure against this attack is to for clients to be
1470   configured to require the use of the optional "cnonce" directive.
1471</t>
1472</section>
1473
1474<section title="Batch brute force attacks">
1475<t>
1476   With Digest authentication, a MITM can execute a chosen plaintext
1477   attack, and can gather responses from many users to the same nonce.
1478   It can then find all the passwords within any subset of password
1479   space that would generate one of the nonce/response pairs in a single
1480   pass over that space. It also reduces the time to find the first
1481   password by a factor equal to the number of nonce/response pairs
1482   gathered. This search of the password space can often be done in
1483   parallel on many machines, and even a single machine can search large
1484   subsets of the password space very quickly -- reports exist of
1485   searching all passwords with six or fewer letters in a few hours.
1486</t>
1487<t>
1488   The countermeasure against this attack is to for clients to be
1489   configured to require the use of the optional "cnonce" directive.
1490</t>
1491</section>
1492
1493<section title="Spoofing by Counterfeit Servers">
1494<t>
1495   Basic Authentication is vulnerable to spoofing by counterfeit
1496   servers.  If a user can be led to believe that she is connecting to a
1497   host containing information protected by a password she knows, when
1498   in fact she is connecting to a hostile server, then the hostile
1499   server can request a password, store it away for later use, and feign
1500   an error.  This type of attack is more difficult with Digest
1501   Authentication -- but the client must know to demand that Digest
1502   authentication be used, perhaps using some of the techniques
1503   described above to counter "man-in-the-middle" attacks.  Again, the
1504   user can be helped in detecting this attack by a visual indication of
1505   the authentication mechanism in use with appropriate guidance in
1506   interpreting the implications of each scheme.
1507</t>
1508</section>
1509
1510<section title="Storing passwords">
1511<t>
1512   Digest authentication requires that the authenticating agent (usually
1513   the server) store some data derived from the user's name and password
1514   in a "password file" associated with a given realm. Normally this
1515   might contain pairs consisting of username and H(A1), where H(A1) is
1516   the digested value of the username, realm, and password as described
1517   above.
1518</t>
1519<t>
1520   The security implications of this are that if this password file is
1521   compromised, then an attacker gains immediate access to documents on
1522   the server using this realm. Unlike, say a standard UNIX password
1523   file, this information need not be decrypted in order to access
1524   documents in the server realm associated with this file. On the other
1525   hand, decryption, or more likely a brute force attack, would be
1526   necessary to obtain the user's password. This is the reason that the
1527   realm is part of the digested data stored in the password file. It
1528   means that if one Digest authentication password file is compromised,
1529   it does not automatically compromise others with the same username
1530   and password (though it does expose them to brute force attack).
1531</t>
1532<t>
1533   There are two important security consequences of this. First the
1534   password file must be protected as if it contained unencrypted
1535   passwords, because for the purpose of accessing documents in its
1536   realm, it effectively does.
1537</t>
1538<t>
1539   A second consequence of this is that the realm string should be
1540   unique among all realms which any single user is likely to use. In
1541   particular a realm string should include the name of the host doing
1542   the authentication. The inability of the client to authenticate the
1543   server is a weakness of Digest Authentication.
1544</t>
1545</section>
1546
1547<section title="Summary">
1548<t>
1549   By modern cryptographic standards Digest Authentication is weak. But
1550   for a large range of purposes it is valuable as a replacement for
1551   Basic Authentication. It remedies some, but not all, weaknesses of
1552   Basic Authentication. Its strength may vary depending on the
1553   implementation.  In particular the structure of the nonce (which is
1554   dependent on the server implementation) may affect the ease of
1555   mounting a replay attack.  A range of server options is appropriate
1556   since, for example, some implementations may be willing to accept the
1557   server overhead of one-time nonces or digests to eliminate the
1558   possibility of replay. Others may satisfied with a nonce like the one
1559   recommended above restricted to a single IP address and a single ETag
1560   or with a limited lifetime.
1561</t>
1562<t>
1563   The bottom line is that *any* compliant implementation will be
1564   relatively weak by cryptographic standards, but *any* compliant
1565   implementation will be far superior to Basic Authentication.
1566</t>
1567</section>
1568</section>
1569   
1570<section title="Sample implementation">
1571<t>
1572   The following code implements the calculations of H(A1), H(A2),
1573   request-digest and response-digest, and a test program which computes
1574   the values used in the example of <xref target="specification.of.digest.headers.example"/>. It uses the MD5
1575   implementation from RFC 1321.
1576</t>
1577<figure><preamble>
1578   File "digcalc.h":
1579</preamble><artwork type="code" name="digcalc.h">
1580#define HASHLEN 16
1581typedef char HASH[HASHLEN];
1582#define HASHHEXLEN 32
1583typedef char HASHHEX[HASHHEXLEN+1];
1584#define IN
1585#define OUT
1586
1587/* calculate H(A1) as per HTTP Digest spec */
1588void DigestCalcHA1(
1589    IN char * pszAlg,
1590    IN char * pszUserName,
1591    IN char * pszRealm,
1592    IN char * pszPassword,
1593    IN char * pszNonce,
1594    IN char * pszCNonce,
1595    OUT HASHHEX SessionKey
1596    );
1597
1598/* calculate request-digest/response-digest as per HTTP Digest spec */
1599void DigestCalcResponse(
1600    IN HASHHEX HA1,           /* H(A1) */
1601    IN char * pszNonce,       /* nonce from server */
1602    IN char * pszNonceCount,  /* 8 hex digits */
1603    IN char * pszCNonce,      /* client nonce */
1604    IN char * pszQop,         /* qop-value: "", "auth", "auth-int" */
1605    IN char * pszMethod,      /* method from the request */
1606    IN char * pszDigestUri,   /* requested URL */
1607    IN HASHHEX HEntity,       /* H(entity body) if qop="auth-int" */
1608    OUT HASHHEX Response      /* request-digest or response-digest */
1609    );
1610</artwork></figure>
1611<figure><preamble>
1612File "digcalc.c":
1613</preamble><artwork type="example" name="digcalc.c">
1614#include &lt;global.h>
1615#include &lt;md5.h>
1616#include &lt;string.h>
1617#include "digcalc.h"
1618
1619void CvtHex(
1620    IN HASH Bin,
1621    OUT HASHHEX Hex
1622    )
1623{
1624    unsigned short i;
1625    unsigned char j;
1626
1627    for (i = 0; i &lt; HASHLEN; i++) {
1628        j = (Bin[i] >> 4) &amp; 0xf;
1629        if (j &lt;= 9)
1630            Hex[i*2] = (j + '0');
1631         else
1632            Hex[i*2] = (j + 'a' - 10);
1633        j = Bin[i] &amp; 0xf;
1634        if (j &lt;= 9)
1635            Hex[i*2+1] = (j + '0');
1636         else
1637            Hex[i*2+1] = (j + 'a' - 10);
1638    };
1639    Hex[HASHHEXLEN] = '\0';
1640};
1641
1642/* calculate H(A1) as per spec */
1643void DigestCalcHA1(
1644    IN char * pszAlg,
1645    IN char * pszUserName,
1646    IN char * pszRealm,
1647    IN char * pszPassword,
1648    IN char * pszNonce,
1649    IN char * pszCNonce,
1650    OUT HASHHEX SessionKey
1651    )
1652{
1653      MD5_CTX Md5Ctx;
1654      HASH HA1;
1655
1656      MD5Init(&amp;Md5Ctx);
1657      MD5Update(&amp;Md5Ctx, pszUserName, strlen(pszUserName));
1658      MD5Update(&amp;Md5Ctx, ":", 1);
1659      MD5Update(&amp;Md5Ctx, pszRealm, strlen(pszRealm));
1660      MD5Update(&amp;Md5Ctx, ":", 1);
1661      MD5Update(&amp;Md5Ctx, pszPassword, strlen(pszPassword));
1662      MD5Final(HA1, &amp;Md5Ctx);
1663      if (stricmp(pszAlg, "md5-sess") == 0) {
1664            MD5Init(&amp;Md5Ctx);
1665            MD5Update(&amp;Md5Ctx, HA1, HASHLEN);
1666            MD5Update(&amp;Md5Ctx, ":", 1);
1667            MD5Update(&amp;Md5Ctx, pszNonce, strlen(pszNonce));
1668            MD5Update(&amp;Md5Ctx, ":", 1);
1669            MD5Update(&amp;Md5Ctx, pszCNonce, strlen(pszCNonce));
1670            MD5Final(HA1, &amp;Md5Ctx);
1671      };
1672      CvtHex(HA1, SessionKey);
1673};
1674
1675/* calculate request-digest/response-digest as per HTTP Digest spec */
1676void DigestCalcResponse(
1677    IN HASHHEX HA1,           /* H(A1) */
1678    IN char * pszNonce,       /* nonce from server */
1679    IN char * pszNonceCount,  /* 8 hex digits */
1680    IN char * pszCNonce,      /* client nonce */
1681    IN char * pszQop,         /* qop-value: "", "auth", "auth-int" */
1682    IN char * pszMethod,      /* method from the request */
1683    IN char * pszDigestUri,   /* requested URL */
1684    IN HASHHEX HEntity,       /* H(entity body) if qop="auth-int" */
1685    OUT HASHHEX Response      /* request-digest or response-digest */
1686    )
1687{
1688      MD5_CTX Md5Ctx;
1689      HASH HA2;
1690      HASH RespHash;
1691       HASHHEX HA2Hex;
1692
1693      // calculate H(A2)
1694      MD5Init(&amp;Md5Ctx);
1695      MD5Update(&amp;Md5Ctx, pszMethod, strlen(pszMethod));
1696      MD5Update(&amp;Md5Ctx, ":", 1);
1697      MD5Update(&amp;Md5Ctx, pszDigestUri, strlen(pszDigestUri));
1698      if (stricmp(pszQop, "auth-int") == 0) {
1699            MD5Update(&amp;Md5Ctx, ":", 1);
1700            MD5Update(&amp;Md5Ctx, HEntity, HASHHEXLEN);
1701      };
1702      MD5Final(HA2, &amp;Md5Ctx);
1703       CvtHex(HA2, HA2Hex);
1704
1705      // calculate response
1706      MD5Init(&amp;Md5Ctx);
1707      MD5Update(&amp;Md5Ctx, HA1, HASHHEXLEN);
1708      MD5Update(&amp;Md5Ctx, ":", 1);
1709      MD5Update(&amp;Md5Ctx, pszNonce, strlen(pszNonce));
1710      MD5Update(&amp;Md5Ctx, ":", 1);
1711      if (*pszQop) {
1712          MD5Update(&amp;Md5Ctx, pszNonceCount, strlen(pszNonceCount));
1713          MD5Update(&amp;Md5Ctx, ":", 1);
1714          MD5Update(&amp;Md5Ctx, pszCNonce, strlen(pszCNonce));
1715          MD5Update(&amp;Md5Ctx, ":", 1);
1716          MD5Update(&amp;Md5Ctx, pszQop, strlen(pszQop));
1717          MD5Update(&amp;Md5Ctx, ":", 1);
1718      };
1719      MD5Update(&amp;Md5Ctx, HA2Hex, HASHHEXLEN);
1720      MD5Final(RespHash, &amp;Md5Ctx);
1721      CvtHex(RespHash, Response);
1722};
1723</artwork></figure>
1724<figure><preamble>
1725File "digtest.c":
1726</preamble><artwork type="example" name="digtest.c">
1727#include &lt;stdio.h>
1728#include "digcalc.h"
1729
1730void main(int argc, char ** argv) {
1731
1732      char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
1733      char * pszCNonce = "0a4f113b";
1734      char * pszUser = "Mufasa";
1735      char * pszRealm = "testrealm@host.com";
1736      char * pszPass = "Circle Of Life";
1737      char * pszAlg = "md5";
1738      char szNonceCount[9] = "00000001";
1739      char * pszMethod = "GET";
1740      char * pszQop = "auth";
1741      char * pszURI = "/dir/index.html";
1742      HASHHEX HA1;
1743      HASHHEX HA2 = "";
1744      HASHHEX Response;
1745
1746      DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
1747pszCNonce, HA1);
1748      DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
1749       pszMethod, pszURI, HA2, Response);
1750      printf("Response = %s\n", Response);
1751};
1752</artwork></figure>
1753</section>
1754   
1755<section title="Acknowledgments">
1756<t>
1757   Eric W. Sink, of AbiSource, Inc., was one of the original authors
1758   before the specification underwent substantial revision.
1759</t>
1760<t>
1761   In addition to the authors, valuable discussion instrumental in
1762   creating this document has come from Peter J. Churchyard, Ned Freed,
1763   and David M.  Kristol.
1764</t>
1765<t>
1766   Jim Gettys and Larry Masinter edited this document for update.
1767</t>
1768</section>
1769  </middle>
1770  <back>
1771   
1772<references>
1773
1774<reference anchor='RFC1945'>
1775<front>
1776<title abbrev='HTTP/1.0'>Hypertext Transfer Protocol -- HTTP/1.0</title>
1777<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
1778<organization>MIT, Laboratory for Computer Science</organization>
1779<address>
1780<postal>
1781<street>545 Technology Square</street>
1782<city>Cambridge</city>
1783<region>MA</region>
1784<code>02139</code>
1785<country>US</country></postal>
1786<facsimile>+1 617 258 8682</facsimile>
1787<email>timbl@w3.org</email></address></author>
1788<author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
1789<organization>University of California, Irvine, Department of Information and Computer Science</organization>
1790<address>
1791<postal>
1792<street />
1793<city>Irvine</city>
1794<region>CA</region>
1795<code>92717-3425</code>
1796<country>US</country></postal>
1797<facsimile>+1 714 824 4056</facsimile>
1798<email>fielding@ics.uci.edu</email></address></author>
1799<author initials='H.F.' surname='Nielsen' fullname='Henrik Frystyk Nielsen'>
1800<organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
1801<address>
1802<postal>
1803<street>545 Technology Square</street>
1804<city>Cambridge</city>
1805<region>MA</region>
1806<code>02139</code>
1807<country>US</country></postal>
1808<facsimile>+1 617 258 8682</facsimile>
1809<email>frystyk@w3.org</email></address></author>
1810<date year='1996' month='May' />
1811</front>
1812<seriesInfo name='RFC' value='1945' />
1813</reference>
1814
1815<reference anchor="RFC2616">
1816
1817<front>
1818<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
1819<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
1820<organization>University of California, Irvine, Information and Computer Science</organization>
1821<address>
1822<postal>
1823<street/>
1824<city>Irvine</city>
1825<region>CA</region>
1826<code>92697-3425</code>
1827<country>US</country></postal>
1828<phone>+1 949 824 1715</phone>
1829<email>fielding@ics.uci.edu</email></address></author>
1830<author initials="J." surname="Gettys" fullname="James Gettys">
1831<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
1832<address>
1833<postal>
1834<street>545 Technology Square</street>
1835<city>Cambridge</city>
1836<region>MA</region>
1837<code>02139</code>
1838<country>US</country></postal>
1839<phone/>
1840<facsimile>+1 617 258 8682</facsimile>
1841<email>jg@w3.org</email></address></author>
1842<author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
1843<organization>Compaq Computer Corporation, Western Research Laboratory</organization>
1844<address>
1845<postal>
1846<street>250 University Avenue</street>
1847<city>Palo Alto</city>
1848<region>CA</region>
1849<code>94301</code>
1850<country>US</country></postal>
1851<phone/>
1852<email>mogul@wrl.dec.com</email></address></author>
1853<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
1854<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
1855<address>
1856<postal>
1857<street>545 Technology Square</street>
1858<city>Cambridge</city>
1859<region>MA</region>
1860<code>02139</code>
1861<country>US</country></postal>
1862<phone/>
1863<facsimile>+1 617 258 8682</facsimile>
1864<email>frystyk@w3.org</email></address></author>
1865<author initials="L." surname="Masinter" fullname="Larry Masinter">
1866<organization>Xerox Corporation</organization>
1867<address>
1868<postal>
1869<street>3333 Coyote Hill Road</street>
1870<city>Palo Alto</city>
1871<region>CA</region>
1872<code>94034</code>
1873<country>US</country></postal>
1874<phone/>
1875<email>masinter@parc.xerox.com</email></address></author>
1876<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
1877<organization>Microsoft Corporation</organization>
1878<address>
1879<postal>
1880<street>1 Microsoft Way</street>
1881<city>Redmond</city>
1882<region>WA</region>
1883<code>98052</code>
1884<country>US</country></postal>
1885<phone/>
1886<email>paulle@microsoft.com</email></address></author>
1887<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1888<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
1889<address>
1890<postal>
1891<street>545 Technology Square</street>
1892<city>Cambridge</city>
1893<region>MA</region>
1894<code>02139</code>
1895<country>US</country></postal>
1896<phone>+1 617 258 8682</phone>
1897<facsimile/>
1898<email>timbl@w3.org</email></address></author>
1899<date month="June" year="1999"/>
1900</front>
1901<seriesInfo name="RFC" value="2616"/>
1902
1903  <x:source href="rfc2616.xml"/>
1904</reference>
1905
1906<reference anchor='RFC1321'>
1907<front>
1908<title abbrev='MD5 Message-Digest Algorithm'>The MD5 Message-Digest Algorithm</title>
1909<author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
1910<organization>Massachusetts Institute of Technology, (MIT) Laboratory for Computer Science</organization>
1911<address>
1912<postal>
1913<street>545 Technology Square</street>
1914<street>NE43-324</street>
1915<city>Cambridge</city>
1916<region>MA</region>
1917<code>02139-1986</code>
1918<country>US</country></postal>
1919<phone>+1 617 253 5880</phone>
1920<email>rivest@theory.lcs.mit.edu</email></address></author>
1921<date year='1992' month='April' /></front>
1922<seriesInfo name='RFC' value='1321' />
1923</reference>
1924
1925<reference anchor='RFC2045'>
1926<front>
1927<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
1928<author initials='N.' surname='Freed' fullname='Ned Freed'>
1929<organization>Innosoft International, Inc.</organization>
1930<address>
1931<postal>
1932<street>1050 East Garvey Avenue South</street>
1933<city>West Covina</city>
1934<region>CA</region>
1935<code>91790</code>
1936<country>US</country></postal>
1937<phone>+1 818 919 3600</phone>
1938<facsimile>+1 818 919 3614</facsimile>
1939<email>ned@innosoft.com</email></address></author>
1940<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
1941<organization>First Virtual Holdings</organization>
1942<address>
1943<postal>
1944<street>25 Washington Avenue</street>
1945<city>Morristown</city>
1946<region>NJ</region>
1947<code>07960</code>
1948<country>US</country></postal>
1949<phone>+1 201 540 8967</phone>
1950<facsimile>+1 201 993 3032</facsimile>
1951<email>nsb@nsb.fv.com</email></address></author>
1952<date year='1996' month='November' />
1953</front>
1954<seriesInfo name='RFC' value='2045' />
1955</reference>
1956
1957<reference anchor='RFC2246'>
1958<front>
1959<title>The TLS Protocol Version 1.0</title>
1960<author initials='T.' surname='Dierks' fullname='Tim Dierks'>
1961<organization>Certicom</organization>
1962<address>
1963<email>tdierks@certicom.com</email></address></author>
1964<author initials='C.' surname='Allen' fullname='Christopher Allen'>
1965<organization>Certicom</organization>
1966<address>
1967<email>callen@certicom.com</email></address></author>
1968<date year='1999' month='January' />
1969</front>
1970<seriesInfo name='RFC' value='2246' />
1971<format type='TXT' octets='170401' target='ftp://ftp.isi.edu/in-notes/rfc2246.txt' />
1972</reference>
1973
1974
1975<reference anchor='RFC2069'>
1976<front>
1977<title abbrev='Digest Access Authentication'>An Extension to HTTP : Digest Access Authentication</title>
1978<author initials='J.' surname='Franks' fullname='John Franks'>
1979<organization>Northwestern University,  Department of Mathematics</organization>
1980<address>
1981<postal>
1982<street />
1983<city>Evanston</city>
1984<region>IL</region>
1985<code>60208-2730</code>
1986<country>US</country></postal>
1987<email>john@math.nwu.edu</email></address></author>
1988<author initials='P.' surname='Hallam-Baker' fullname='Phillip M. Hallam-Baker'>
1989<organization>CERN</organization>
1990<address>
1991<postal>
1992<street />
1993<city>Geneva</city>
1994<country>CH</country></postal>
1995<email>hallam@w3.org</email></address></author>
1996<author initials='J.' surname='Hostetler' fullname='Jeffery L. Hostetler'>
1997<organization>Spyglass, Inc.</organization>
1998<address>
1999<postal>
2000<street>3200 Farber Drive</street>
2001<city>Champaign</city>
2002<region>IL</region>
2003<code>61821</code>
2004<country>US</country></postal>
2005<email>jeff@spyglass.com</email></address></author>
2006<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
2007<organization>Microsoft Corporation</organization>
2008<address>
2009<postal>
2010<street>1 Microsoft Way</street>
2011<city>Redmond</city>
2012<region>WA</region>
2013<code>98052</code>
2014<country>US</country></postal>
2015<email>paulle@microsoft.com</email></address></author>
2016<author initials='A.' surname='Luotonen' fullname='Ari Luotonen'>
2017<organization>Netscape Communications Corporation</organization>
2018<address>
2019<postal>
2020<street>501 East Middlefield Road</street>
2021<city>Mountain View</city>
2022<region>CA</region>
2023<code>94043</code>
2024<country>US</country></postal>
2025<email>luotonen@netscape.com</email></address></author>
2026<author initials='E.' surname='Sink' fullname='Eric W. Sink'>
2027<organization>Spyglass, Inc.</organization>
2028<address>
2029<postal>
2030<street>3200 Farber Drive</street>
2031<city>Champaign</city>
2032<region>IL</region>
2033<code>61821</code>
2034<country>US</country></postal>
2035<email>eric@spyglass.com</email></address></author>
2036<author initials='L.' surname='Stewart' fullname='Lawrence C. Stewart'>
2037<organization>Open Market, Inc.</organization>
2038<address>
2039<postal>
2040<street>215 First Street</street>
2041<city>Cambridge</city>
2042<region>MA</region>
2043<code>02142</code>
2044<country>US</country></postal>
2045<email>stewart@OpenMarket.com</email></address></author>
2046<date year='1997' month='January' />
2047</front>
2048<seriesInfo name='RFC' value='2069' />
2049</reference>
2050
2051<reference anchor="RFC2396">
2052  <front>
2053    <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
2054    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2055      <organization>World Wide Web Consortium</organization>
2056      <address>
2057      <email>timbl@w3.org</email></address>
2058    </author>
2059    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
2060      <organization>Department of Information and Computer Science</organization>
2061      <address>
2062        <email>fielding@ics.uci.edu</email>
2063      </address>
2064    </author>
2065    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2066      <organization>Xerox PARC</organization>
2067      <address>
2068        <email>masinter@parc.xerox.com</email>
2069      </address>
2070    </author>
2071    <date month="August" year="1998"/>
2072  </front>
2073  <seriesInfo name="RFC" value="2396"/>
2074</reference>
2075
2076<reference anchor="ref8" target="http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm">
2077  <front>
2078    <title>Message Authentication with MD5</title>
2079    <author initials="B." surname="Kaliski">
2080      <organization/>
2081    </author>
2082    <author initials="M." surname="Robshaw">
2083      <organization/>
2084    </author>
2085    <date year="1995"/>
2086  </front>
2087  <annotation>CryptoBytes, Spring 1995</annotation>
2088</reference>
2089
2090<reference anchor='RFC2195'>
2091<front>
2092<title abbrev='IMAP/POP AUTHorize Extension'>IMAP/POP AUTHorize Extension for Simple Challenge/Response</title>
2093<author initials='J.C.' surname='Klensin' fullname='John C. Klensin'>
2094<organization>MCI</organization>
2095<address>
2096<postal>
2097<street>800 Boylston</street>
2098<street>7th floor</street>
2099<street>Boston</street>
2100<street>MA 02199</street>
2101<country>USA</country></postal>
2102<phone>+1 617 960 1011</phone>
2103<email>klensin@mci.net</email></address></author>
2104<author initials='R.' surname='Catoe' fullname='Randy Catoe'>
2105<organization>MCI</organization>
2106<address>
2107<postal>
2108<street>2100 Reston Parkway</street>
2109<street>Reston</street>
2110<street>VA 22091</street>
2111<country>USA</country></postal>
2112<phone>+1 703 715 7366</phone>
2113<email>randy@mci.net</email></address></author>
2114<author initials='P.' surname='Krumviede' fullname='Paul Krumviede'>
2115<organization>MCI</organization>
2116<address>
2117<postal>
2118<street>2100 Reston Parkway</street>
2119<street>Reston</street>
2120<street>VA 22091</street>
2121<country>USA</country></postal>
2122<phone>+1 703 715 7251</phone>
2123<email>paul@mci.net</email></address></author>
2124<date year='1997' month='September' />
2125<area>Applications</area>
2126<keyword>IMAP</keyword>
2127<keyword>authentication</keyword>
2128<keyword>internet message access protocol</keyword>
2129<keyword>post office protocol</keyword>
2130<keyword>security</keyword>
2131</front>
2132<seriesInfo name='RFC' value='2195' />
2133</reference>
2134
2135<reference anchor="ref10">
2136  <front>
2137    <title>Authentication Methods for LDAP</title>
2138    <author initials="B." surname="Morgan">
2139      <organization/>
2140    </author>
2141    <author initials="H." surname="Alvestrand">
2142      <organization/>
2143    </author>
2144    <author initials="J." surname="Hodges">
2145      <organization/>
2146    </author>
2147    <author initials="M." surname="Wahl">
2148      <organization/>
2149    </author>
2150    <date/>
2151  </front>
2152  <annotation>Work in progress.</annotation>
2153</reference>
2154</references> 
2155 
2156</back>
2157</rfc>
Note: See TracBrowser for help on using the repository browser.