source: draft-ietf-httpbis/00/draft-ietf-httpbis-p7-auth-00.txt

Last change on this file was 63, checked in by fielding@…, 12 years ago

Update issues list URI and draft names

  • Property svn:eol-style set to native
File size: 20.3 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2068, 2616                                          J. Gettys
7(if approved)                                       One Laptop per Child
8Updates: 2617 (if approved)                                     J. Mogul
9Intended status: Standards Track                                      HP
10Expires: June 22, 2008                                        H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                       December 20, 2007
19
20
21                    HTTP/1.1, part 7: Authentication
22                     draft-ietf-httpbis-p7-auth-00
23
24Status of this Memo
25
26   By submitting this Internet-Draft, each author represents that any
27   applicable patent or other IPR claims of which he or she is aware
28   have been or will be disclosed, and any of which he or she becomes
29   aware will be disclosed, in accordance with Section 6 of BCP 79.
30
31   Internet-Drafts are working documents of the Internet Engineering
32   Task Force (IETF), its areas, and its working groups.  Note that
33   other groups may also distribute working documents as Internet-
34   Drafts.
35
36   Internet-Drafts are draft documents valid for a maximum of six months
37   and may be updated, replaced, or obsoleted by other documents at any
38   time.  It is inappropriate to use Internet-Drafts as reference
39   material or to cite them other than as "work in progress."
40
41   The list of current Internet-Drafts can be accessed at
42   http://www.ietf.org/ietf/1id-abstracts.txt.
43
44   The list of Internet-Draft Shadow Directories can be accessed at
45   http://www.ietf.org/shadow.html.
46
47   This Internet-Draft will expire on June 22, 2008.
48
49Copyright Notice
50
51   Copyright (C) The IETF Trust (2007).
52
53
54
55Fielding, et al.          Expires June 22, 2008                 [Page 1]
56
57Internet-Draft                  HTTP/1.1                   December 2007
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 7 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
68   HTTP Authentication.
69
70Editorial Note (To be removed by RFC Editor)
71
72   This version of the HTTP specification contains only minimal
73   editorial changes from [RFC2616] (abstract, introductory paragraph,
74   and authors' addresses).  All other changes are due to partitioning
75   the original into seven mostly independent parts.  The intent is for
76   readers of future drafts to able to use draft 00 as the basis for
77   comparison when the WG makes later changes to the specification text.
78   This draft will shortly be followed by draft 01 (containing the first
79   round of changes that have already been agreed to on the mailing
80   list).  There is no point in reviewing this draft other than to
81   verify that the partitioning has been done correctly.  Roy T.
82   Fielding, Yves Lafon, and Julian Reschke will be the editors after
83   draft 00 is submitted.
84
85   Discussion of this draft should take place on the HTTPBIS working
86   group mailing list (ietf-http-wg@w3.org).  The current issues list is
87   at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related
88   documents (including fancy diffs) can be found at
89   <http://www3.tools.ietf.org/wg/httpbis/>.
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires June 22, 2008                 [Page 2]
112
113Internet-Draft                  HTTP/1.1                   December 2007
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119   2.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  4
120     2.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  4
121     2.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  4
122   3.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
123     3.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  5
124     3.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  6
125     3.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  6
126     3.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  6
127   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
128   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
129     5.1.  Authentication Credentials and Idle Clients  . . . . . . .  7
130   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
131   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
132   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
133   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
134   Intellectual Property and Copyright Statements . . . . . . . . . . 11
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.          Expires June 22, 2008                 [Page 3]
168
169Internet-Draft                  HTTP/1.1                   December 2007
170
171
1721.  Introduction
173
174   This document will define aspects of HTTP related to access control
175   and authentication.  Right now it only includes the extracted
176   relevant sections of RFC 2616 [RFC2616] with only minor edits.
177
178   HTTP provides several OPTIONAL challenge-response authentication
179   mechanisms which can be used by a server to challenge a client
180   request and by a client to provide authentication information.  The
181   general framework for access authentication, and the specification of
182   "basic" and "digest" authentication, are specified in "HTTP
183   Authentication: Basic and Digest Access Authentication" [RFC2617].
184   This specification adopts the definitions of "challenge" and
185   "credentials" from that specification.
186
187
1882.  Status Code Definitions
189
1902.1.  401 Unauthorized
191
192   The request requires user authentication.  The response MUST include
193   a WWW-Authenticate header field (Section 3.4) containing a challenge
194   applicable to the requested resource.  The client MAY repeat the
195   request with a suitable Authorization header field (Section 3.1).  If
196   the request already included Authorization credentials, then the 401
197   response indicates that authorization has been refused for those
198   credentials.  If the 401 response contains the same challenge as the
199   prior response, and the user agent has already attempted
200   authentication at least once, then the user SHOULD be presented the
201   entity that was given in the response, since that entity might
202   include relevant diagnostic information.  HTTP access authentication
203   is explained in "HTTP Authentication: Basic and Digest Access
204   Authentication" [RFC2617].
205
2062.2.  407 Proxy Authentication Required
207
208   This code is similar to 401 (Unauthorized), but indicates that the
209   client must first authenticate itself with the proxy.  The proxy MUST
210   return a Proxy-Authenticate header field (Section 3.2) containing a
211   challenge applicable to the proxy for the requested resource.  The
212   client MAY repeat the request with a suitable Proxy-Authorization
213   header field (Section 3.3).  HTTP access authentication is explained
214   in "HTTP Authentication: Basic and Digest Access Authentication"
215   [RFC2617].
216
217
218
219
220
221
222
223Fielding, et al.          Expires June 22, 2008                 [Page 4]
224
225Internet-Draft                  HTTP/1.1                   December 2007
226
227
2283.  Header Field Definitions
229
230   This section defines the syntax and semantics of all standard
231   HTTP/1.1 header fields.  For entity-header fields, both sender and
232   recipient refer to either the client or the server, depending on who
233   sends and who receives the entity.
234
2353.1.  Authorization
236
237   A user agent that wishes to authenticate itself with a server--
238   usually, but not necessarily, after receiving a 401 response--does so
239   by including an Authorization request-header field with the request.
240   The Authorization field value consists of credentials containing the
241   authentication information of the user agent for the realm of the
242   resource being requested.
243
244          Authorization  = "Authorization" ":" credentials
245
246   HTTP access authentication is described in "HTTP Authentication:
247   Basic and Digest Access Authentication" [RFC2617].  If a request is
248   authenticated and a realm specified, the same credentials SHOULD be
249   valid for all other requests within this realm (assuming that the
250   authentication scheme itself does not require otherwise, such as
251   credentials that vary according to a challenge value or using
252   synchronized clocks).
253
254   When a shared cache (see Section 2.7 of [Part6]) receives a request
255   containing an Authorization field, it MUST NOT return the
256   corresponding response as a reply to any other request, unless one of
257   the following specific exceptions holds:
258
259   1.  If the response includes the "s-maxage" cache-control directive,
260       the cache MAY use that response in replying to a subsequent
261       request.  But (if the specified maximum age has passed) a proxy
262       cache MUST first revalidate it with the origin server, using the
263       request-headers from the new request to allow the origin server
264       to authenticate the new request.  (This is the defined behavior
265       for s-maxage.)  If the response includes "s-maxage=0", the proxy
266       MUST always revalidate it before re-using it.
267
268   2.  If the response includes the "must-revalidate" cache-control
269       directive, the cache MAY use that response in replying to a
270       subsequent request.  But if the response is stale, all caches
271       MUST first revalidate it with the origin server, using the
272       request-headers from the new request to allow the origin server
273       to authenticate the new request.
274
275
276
277
278
279Fielding, et al.          Expires June 22, 2008                 [Page 5]
280
281Internet-Draft                  HTTP/1.1                   December 2007
282
283
284   3.  If the response includes the "public" cache-control directive, it
285       MAY be returned in reply to any subsequent request.
286
2873.2.  Proxy-Authenticate
288
289   The Proxy-Authenticate response-header field MUST be included as part
290   of a 407 (Proxy Authentication Required) response.  The field value
291   consists of a challenge that indicates the authentication scheme and
292   parameters applicable to the proxy for this Request-URI.
293
294       Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
295
296   The HTTP access authentication process is described in "HTTP
297   Authentication: Basic and Digest Access Authentication" [RFC2617].
298   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
299   only to the current connection and SHOULD NOT be passed on to
300   downstream clients.  However, an intermediate proxy might need to
301   obtain its own credentials by requesting them from the downstream
302   client, which in some circumstances will appear as if the proxy is
303   forwarding the Proxy-Authenticate header field.
304
3053.3.  Proxy-Authorization
306
307   The Proxy-Authorization request-header field allows the client to
308   identify itself (or its user) to a proxy which requires
309   authentication.  The Proxy-Authorization field value consists of
310   credentials containing the authentication information of the user
311   agent for the proxy and/or realm of the resource being requested.
312
313       Proxy-Authorization     = "Proxy-Authorization" ":" credentials
314
315   The HTTP access authentication process is described in "HTTP
316   Authentication: Basic and Digest Access Authentication" [RFC2617].
317   Unlike Authorization, the Proxy-Authorization header field applies
318   only to the next outbound proxy that demanded authentication using
319   the Proxy-Authenticate field.  When multiple proxies are used in a
320   chain, the Proxy-Authorization header field is consumed by the first
321   outbound proxy that was expecting to receive credentials.  A proxy
322   MAY relay the credentials from the client request to the next proxy
323   if that is the mechanism by which the proxies cooperatively
324   authenticate a given request.
325
3263.4.  WWW-Authenticate
327
328   The WWW-Authenticate response-header field MUST be included in 401
329   (Unauthorized) response messages.  The field value consists of at
330   least one challenge that indicates the authentication scheme(s) and
331   parameters applicable to the Request-URI.
332
333
334
335Fielding, et al.          Expires June 22, 2008                 [Page 6]
336
337Internet-Draft                  HTTP/1.1                   December 2007
338
339
340       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
341
342   The HTTP access authentication process is described in "HTTP
343   Authentication: Basic and Digest Access Authentication" [RFC2617].
344   User agents are advised to take special care in parsing the WWW-
345   Authenticate field value as it might contain more than one challenge,
346   or if more than one WWW-Authenticate header field is provided, the
347   contents of a challenge itself can contain a comma-separated list of
348   authentication parameters.
349
350
3514.  IANA Considerations
352
353   TBD.
354
355
3565.  Security Considerations
357
358   This section is meant to inform application developers, information
359   providers, and users of the security limitations in HTTP/1.1 as
360   described by this document.  The discussion does not include
361   definitive solutions to the problems revealed, though it does make
362   some suggestions for reducing security risks.
363
3645.1.  Authentication Credentials and Idle Clients
365
366   Existing HTTP clients and user agents typically retain authentication
367   information indefinitely.  HTTP/1.1. does not provide a method for a
368   server to direct clients to discard these cached credentials.  This
369   is a significant defect that requires further extensions to HTTP.
370   Circumstances under which credential caching can interfere with the
371   application's security model include but are not limited to:
372
373   o  Clients which have been idle for an extended period following
374      which the server might wish to cause the client to reprompt the
375      user for credentials.
376
377   o  Applications which include a session termination indication (such
378      as a `logout' or `commit' button on a page) after which the server
379      side of the application `knows' that there is no further reason
380      for the client to retain the credentials.
381
382   This is currently under separate study.  There are a number of work-
383   arounds to parts of this problem, and we encourage the use of
384   password protection in screen savers, idle time-outs, and other
385   methods which mitigate the security problems inherent in this
386   problem.  In particular, user agents which cache credentials are
387   encouraged to provide a readily accessible mechanism for discarding
388
389
390
391Fielding, et al.          Expires June 22, 2008                 [Page 7]
392
393Internet-Draft                  HTTP/1.1                   December 2007
394
395
396   cached credentials under user control.
397
398
3996.  Acknowledgments
400
401   Based on an XML translation of RFC 2616 by Julian Reschke.
402
403
4047.  References
405
406   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
407              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
408              part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in
409              progress), December 2007.
410
411   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
412              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
413              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
414
415   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
416              Leach, P., Luotonen, A., and L. Stewart, "HTTP
417              Authentication: Basic and Digest Access Authentication",
418              RFC 2617, June 1999.
419
420
421Index
422
423   4
424      401 Unauthorized (status code)  4
425      407 Proxy Authentication Required (status code)  4
426
427   A
428      Authorization header  5
429
430   G
431      Grammar
432         Authorization  5
433         Proxy-Authenticate  6
434         Proxy-Authorization  6
435         WWW-Authenticate  7
436
437   H
438      Headers
439         Authorization  5
440         Proxy-Authenticate  6
441         Proxy-Authorization  6
442         WWW-Authenticate  6
443
444
445
446
447Fielding, et al.          Expires June 22, 2008                 [Page 8]
448
449Internet-Draft                  HTTP/1.1                   December 2007
450
451
452   P
453      Proxy-Authenticate header  6
454      Proxy-Authorization header  6
455
456   S
457      Status Codes
458         401 Unauthorized  4
459         407 Proxy Authentication Required  4
460
461   W
462      WWW-Authenticate header  6
463
464
465Authors' Addresses
466
467   Roy T. Fielding (editor)
468   Day Software
469   23 Corporate Plaza DR, Suite 280
470   Newport Beach, CA  92660
471   USA
472
473   Phone: +1-949-706-5300
474   Fax:   +1-949-706-5305
475   Email: fielding@gbiv.com
476   URI:   http://roy.gbiv.com/
477
478
479   Jim Gettys
480   One Laptop per Child
481   21 Oak Knoll Road
482   Carlisle, MA  01741
483   USA
484
485   Email: jg@laptop.org
486   URI:   http://www.laptop.org/
487
488
489   Jeffrey C. Mogul
490   Hewlett-Packard Company
491   HP Labs, Large Scale Systems Group
492   1501 Page Mill Road, MS 1177
493   Palo Alto, CA  94304
494   USA
495
496   Email: JeffMogul@acm.org
497
498
499
500
501
502
503Fielding, et al.          Expires June 22, 2008                 [Page 9]
504
505Internet-Draft                  HTTP/1.1                   December 2007
506
507
508   Henrik Frystyk Nielsen
509   Microsoft Corporation
510   1 Microsoft Way
511   Redmond, WA  98052
512   USA
513
514   Email: henrikn@microsoft.com
515
516
517   Larry Masinter
518   Adobe Systems, Incorporated
519   345 Park Ave
520   San Jose, CA  95110
521   USA
522
523   Email: LMM@acm.org
524   URI:   http://larry.masinter.net/
525
526
527   Paul J. Leach
528   Microsoft Corporation
529   1 Microsoft Way
530   Redmond, WA  98052
531
532   Email: paulle@microsoft.com
533
534
535   Tim Berners-Lee
536   World Wide Web Consortium
537   MIT Computer Science and Artificial Intelligence Laboratory
538   The Stata Center, Building 32
539   32 Vassar Street
540   Cambridge, MA  02139
541   USA
542
543   Email: timbl@w3.org
544   URI:   http://www.w3.org/People/Berners-Lee/
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.          Expires June 22, 2008                [Page 10]
560
561Internet-Draft                  HTTP/1.1                   December 2007
562
563
564Full Copyright Statement
565
566   Copyright (C) The IETF Trust (2007).
567
568   This document is subject to the rights, licenses and restrictions
569   contained in BCP 78, and except as set forth therein, the authors
570   retain all their rights.
571
572   This document and the information contained herein are provided on an
573   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
574   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
575   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
576   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
577   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
578   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
579
580
581Intellectual Property
582
583   The IETF takes no position regarding the validity or scope of any
584   Intellectual Property Rights or other rights that might be claimed to
585   pertain to the implementation or use of the technology described in
586   this document or the extent to which any license under such rights
587   might or might not be available; nor does it represent that it has
588   made any independent effort to identify any such rights.  Information
589   on the procedures with respect to rights in RFC documents can be
590   found in BCP 78 and BCP 79.
591
592   Copies of IPR disclosures made to the IETF Secretariat and any
593   assurances of licenses to be made available, or the result of an
594   attempt made to obtain a general license or permission for the use of
595   such proprietary rights by implementers or users of this
596   specification can be obtained from the IETF on-line IPR repository at
597   http://www.ietf.org/ipr.
598
599   The IETF invites any interested party to bring to its attention any
600   copyrights, patents or patent applications, or other proprietary
601   rights that may cover technology that may be required to implement
602   this standard.  Please address the information to the IETF at
603   ietf-ipr@ietf.org.
604
605
606Acknowledgment
607
608   Funding for the RFC Editor function is provided by the IETF
609   Administrative Support Activity (IASA).
610
611
612
613
614
615Fielding, et al.          Expires June 22, 2008                [Page 11]
616
Note: See TracBrowser for help on using the repository browser.