source: draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.xml @ 27

Last change on this file since 27 was 27, checked in by julian.reschke@…, 8 years ago

fix svn properties

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 15.4 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="yes"?>
5<?rfc sortrefs="yes"?>
6<?rfc compact="yes"?>
7<?rfc comments="yes"?>
8<?rfc inline="yes"?>
9<?rfc subcompact="no"?>
10<?rfc rfcedstyle="yes"?>
11<?rfc-ext allow-markup-in-artwork="yes" ?>
12
13<!DOCTYPE rfc [
14  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
15  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
16  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
17  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
18  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
19  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
20  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
21  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
22  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
23  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
24  <!ENTITY mdash "&#8212;">
25]>
26
27<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" xmlns:ed="http://greenbytes.de/2002/rfcedit" ipr="pre5378Trust200902" docName="draft-ietf-httpauth-basicauth-update-latest" category="std" xml:lang="en" updates="2617" x:maturity-level="proposed">
28
29  <x:feedback template="mailto:http-auth@ietf.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
30
31        <front>
32  <title abbrev="'Basic' HTTP Authentication Scheme">The 'Basic' HTTP Authentication Scheme</title>
33  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
34    <organization abbrev="greenbytes">greenbytes GmbH</organization>
35    <address>
36      <postal>
37        <street>Hafenweg 16</street>
38        <city>Muenster</city><region>NW</region><code>48155</code>
39        <country>Germany</country>
40      </postal>
41      <email>julian.reschke@greenbytes.de</email>       
42      <uri>http://greenbytes.de/tech/webdav/</uri>     
43    </address>
44  </author>
45
46  <date month="September" year="2013"/>
47 
48  <area>Applications</area>
49  <workgroup>HTTPAuth Working Group</workgroup>
50 
51  <abstract>
52    <t>
53      This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
54      Authentication Scheme.
55    </t>
56  </abstract>
57 
58  <note title="Editorial Note (To be removed by RFC Editor before publication)">
59    <t>
60      Discussion of this draft takes place on the HTTPAuth working group
61      mailing list (http-auth@ietf.org), which is archived at
62      <eref target="http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html"/>.
63    </t>
64    <t>
65      XML versions, latest edits and the issues list for this document
66      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-ietf-httpauth-basicauth-update"/>.
67    </t>
68    <t>
69      The changes in this draft are summarized in <xref target="changes.since.00"/>.
70    </t>
71  </note>
72  </front>
73
74  <middle>
75
76
77<ed:issue name="edit" type="edit" status="open">
78  <ed:item entered-by="julian.reschke@greenbytes.de" date="2013-09-11">
79    Umbrella issue for editorial fixes/enhancements.
80  </ed:item>
81</ed:issue>
82
83<section title="Introduction" anchor="introduction">
84<t>
85  This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
86  Authentication Scheme (<xref target="draft-ietf-httpbis-p7-auth"/>).
87  This scheme is not considered to be a secure method of user authentication
88  unless used in conjunction with some external secure system such as TLS
89  (Transport Layer Security, <xref target="RFC5246"/>), as the user name and
90  password are passed over the network as cleartext.
91</t>
92<t>
93  The "Basic" scheme previously was defined in <xref target="RFC2617" x:fmt="of" x:sec="2"/>.
94  This document updates the definition, and also addresses internationalization issues.
95</t>
96<t>
97  Other documents updating RFC 2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication"
98  (<xref target="draft-ietf-httpbis-p7-auth"/>, defining the authentication framework) and
99  "HTTP Digest Update" (<xref target="draft-ietf-httpauth-digest-update"/>,
100  updating the definition of the '"Digest" authentication scheme).
101</t>
102</section> 
103
104<section title="Notational Conventions">
105<t>
106  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
107  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
108  are to be interpreted as described in <xref target="RFC2119"/>.
109</t>
110</section> 
111
112<section title="The 'Basic' Authentication Scheme" anchor="basic.authentication.scheme">
113<ed:issue name="upd" type="change" status="open">
114  <ed:item entered-by="julian.reschke@greenbytes.de" date="2013-09-12">
115    Update the definition to reflect underlying changes (RFC2616->httpbis,
116    RFC2396->2616, other references).
117  </ed:item>
118</ed:issue>
119<ed:issue name="enc" type="change" status="open">
120  <ed:item entered-by="julian.reschke@greenbytes.de" date="2013-09-12">
121    Fix the encoding issue, by pulling in draft-ietf-httpauth-basicauth-enc.
122  </ed:item>
123</ed:issue>
124<t>
125   The "basic" authentication scheme is based on the model that the
126   client must authenticate itself with a user-ID and a password for
127   each realm.  The realm value should be considered an opaque string
128   which can only be compared for equality with other realms on that
129   server. The server will service the request only if it can validate
130   the user-ID and password for the protection space of the Request-URI.
131   There are no optional authentication parameters.
132</t>
133<t>
134   For Basic, the framework above is utilized as follows:
135</t>
136<figure><artwork type="abnf2616"><iref item="challenge"/><iref item="credentials"/>
137   challenge   = "Basic" realm
138   credentials = "Basic" basic-credentials
139</artwork></figure>
140<t>
141   Upon receipt of an unauthorized request for a URI within the
142   protection space, the origin server &MAY; respond with a challenge like
143   the following:
144</t>
145<figure><artwork type="example">
146   WWW-Authenticate: Basic realm="WallyWorld"
147</artwork></figure>
148<t>
149   where "WallyWorld" is the string assigned by the server to identify
150   the protection space of the Request-URI. A proxy may respond with the
151   same challenge using the Proxy-Authenticate header field.
152</t>
153<t>
154   To receive authorization, the client sends the userid and password,
155   separated by a single colon (":") character, within a base64
156   encoded string in the credentials (<xref target="RFC4648" x:fmt="," x:sec="4"/>).
157</t>
158<figure><artwork type="abnf2616"><iref item="basic-credentials" primary="true"
159/><iref item="base64-user-pass" primary="true"
160/><iref item="user-pass" primary="true"
161/><iref item="userid" primary="true"
162/><iref item="password" primary="true"/>
163   basic-credentials = base64-user-pass
164   base64-user-pass  = &lt;base64 <xref target="RFC4648"/> encoding of user-pass,
165                    except not limited to 76 char/line>
166   user-pass   = userid ":" password
167   userid      = *&lt;TEXT excluding ":">
168   password    = *TEXT
169</artwork></figure>
170<t>
171   Userids might be case sensitive.
172</t>
173<t>
174   If the user agent wishes to send the userid "Aladdin" and password
175   "open sesame", it would use the following header field:
176</t>
177<figure><artwork type="example">
178   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
179</artwork></figure>
180<t>
181   A client &SHOULD; assume that all paths at or deeper than the depth of
182   the last symbolic element in the path field of the Request-URI also
183   are within the protection space specified by the Basic realm value of
184   the current challenge. A client &MAY; preemptively send the
185   corresponding Authorization header with requests for resources in
186   that space without receipt of another challenge from the server.
187   Similarly, when a client sends a request to a proxy, it may reuse a
188   userid and password in the Proxy-Authorization header field without
189   receiving another challenge from the proxy server. See <xref target="security.considerations"/> for
190   security considerations associated with Basic authentication.
191</t>
192</section> 
193
194<section title="Security Considerations" anchor="security.considerations">
195<t>
196   The Basic authentication scheme is not a secure method of user
197   authentication, nor does it in any way protect the entity, which is
198   transmitted in cleartext across the physical network used as the
199   carrier. HTTP does not prevent the addition of enhancements (such as
200   schemes to use one-time passwords) to Basic authentication.
201</t>
202<t>
203   The most serious flaw in Basic authentication is that it results in
204   the essentially cleartext transmission of the user's password over
205   the physical network. Many other authentication schemes address this
206   problem.
207</t>
208<t>
209   Because Basic authentication involves the cleartext transmission of
210   passwords it &SHOULD-NOT; be used (without enhancements) to protect
211   sensitive or valuable information.
212</t>
213<t>
214   A common use of Basic authentication is for identification purposes
215   &mdash; requiring the user to provide a user name and password as a means
216   of identification, for example, for purposes of gathering accurate
217   usage statistics on a server. When used in this way it is tempting to
218   think that there is no danger in its use if illicit access to the
219   protected documents is not a major concern. This is only correct if
220   the server issues both user name and password to the users and in
221   particular does not allow the user to choose his or her own password.
222   The danger arises because naive users frequently reuse a single
223   password to avoid the task of maintaining multiple passwords.
224</t>
225<t>
226   If a server permits users to select their own passwords, then the
227   threat is not only unauthorized access to documents on the server but
228   also unauthorized access to any other resources on other systems that
229   the user protects with the same password. Furthermore, in the
230   server's password database, many of the passwords may also be users'
231   passwords for other sites. The owner or administrator of such a
232   system could therefore expose all users of the system to the risk of
233   unauthorized access to all those sites if this information is not
234   maintained in a secure fashion.
235</t>
236<t>
237   Basic Authentication is also vulnerable to spoofing by counterfeit
238   servers. If a user can be led to believe that he is connecting to a
239   host containing information protected by Basic authentication when,
240   in fact, he is connecting to a hostile server or gateway, then the
241   attacker can request a password, store it for later use, and feign an
242   error. This type of attack is not possible with Digest
243   Authentication. Server implementers &SHOULD; guard against the
244   possibility of this sort of counterfeiting by gateways or CGI
245   scripts. In particular it is very dangerous for a server to simply
246   turn over a connection to a gateway.  That gateway can then use the
247   persistent connection mechanism to engage in multiple transactions
248   with the client while impersonating the original server in a way that
249   is not detectable by the client.
250</t>
251</section> 
252
253<section title="IANA Considerations" anchor="iana.considerations">
254<t>
255  IANA maintains the registry of HTTP Authentication Schemes (<xref target="draft-ietf-httpbis-p7-auth"/>)
256  at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
257</t>
258<t>
259  The entry for the "Basic" Authentication Scheme shall be updated with a pointer
260  to this specification. 
261</t>
262</section> 
263
264<section title="Acknowledgements">
265<t>
266  This specification takes over the definition of the "Basic" HTTP Authentication
267  Scheme, previously defined in RFC 2617. We thank John Franks,
268  Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
269  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on
270  that specification, from which significant amounts of text was borrowed.
271  See <xref target="RFC2617" x:fmt="of" x:sec="6"/> for further acknowledgements.
272</t>
273</section> 
274  </middle>
275  <back>
276 
277<references title="Normative References">
278 
279  <reference anchor="RFC2119">
280    <front>
281      <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
282      <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
283      <date month="March" year="1997"/>
284    </front>
285    <seriesInfo name="BCP" value="14"/>
286    <seriesInfo name="RFC" value="2119"/>
287  </reference>
288
289  <reference anchor="RFC4648">
290    <front>
291      <title>The Base16, Base32, and Base64 Data Encodings</title>
292      <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
293      <date year="2006" month="October"/>
294    </front>
295    <seriesInfo value="4648" name="RFC"/>
296  </reference>
297 
298  <reference anchor="draft-ietf-httpbis-p7-auth">
299    <front>
300      <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
301      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"/>
302      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"/>
303      <date month="July" year="2013"/>
304    </front>
305    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-23"/>
306  </reference>
307
308</references>
309
310<references title="Informative References"> 
311
312  <reference anchor="RFC2617">
313    <front>
314      <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
315      <author initials="J." surname="Franks" fullname="John Franks"/>
316      <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"/>
317      <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"/>
318      <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"/>
319      <author initials="P.J." surname="Leach" fullname="Paul J. Leach"/>
320      <author initials="A." surname="Luotonen" fullname="Ari Luotonen"/>
321      <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"/>
322      <date month="June" year="1999"/>
323    </front>
324    <seriesInfo name="RFC" value="2617"/>
325  </reference>
326
327  <reference anchor="RFC5246">
328     <front>
329        <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
330        <author initials="T." surname="Dierks" fullname="T. Dierks"/>
331        <author initials="E." surname="Rescorla" fullname="E. Rescorla"/>
332        <date year="2008" month="August" />
333     </front>
334     <seriesInfo name="RFC" value="5246" />
335  </reference>
336
337  <reference anchor="draft-ietf-httpauth-digest-update">
338    <front>
339      <title>HTTP Digest Update</title>
340      <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef"/>
341      <author initials="D." surname="Ahrens" fullname="David Ahrens"/>
342      <date month="September" day="2" year="2013"/>
343    </front>
344    <seriesInfo name="Internet-Draft" value="draft-ietf-httpauth-digest-update-05"/>
345  </reference>
346
347</references>
348
349<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
350<section title="Since RFC 2617" anchor="changes.since.rfc2617">
351<t>
352  This draft acts as a baseline for tracking subsequent changes to the
353  specification. As such, it extracts the definition of "Basic", plus the related Security
354  Considerations, and also adds the IANA registration of the scheme.
355  Changes to the actual definition will be made in subsequent drafts.
356</t>
357</section>
358<section title="Since draft-ietf-httpauth-basicauth-update-00" anchor="changes.since.00">
359<t>
360  Fixed Base64 reference to point to an actual definition of Base64.
361</t>
362</section>
363</section>
364
365  </back>
366</rfc>
Note: See TracBrowser for help on using the repository browser.