source: draft-ietf-httpbis/01/draft-ietf-httpbis-p7-auth-01.txt @ 166

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

generated draft 01

  • Property svn:eol-style set to native
File size: 22.9 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2617 (if approved)                         One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: July 15, 2008                                                HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                        January 12, 2008
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-01
27
28Status of this Memo
29
30   By submitting this Internet-Draft, each author represents that any
31   applicable patent or other IPR claims of which he or she is aware
32   have been or will be disclosed, and any of which he or she becomes
33   aware will be disclosed, in accordance with Section 6 of BCP 79.
34
35   Internet-Drafts are working documents of the Internet Engineering
36   Task Force (IETF), its areas, and its working groups.  Note that
37   other groups may also distribute working documents as Internet-
38   Drafts.
39
40   Internet-Drafts are draft documents valid for a maximum of six months
41   and may be updated, replaced, or obsoleted by other documents at any
42   time.  It is inappropriate to use Internet-Drafts as reference
43   material or to cite them other than as "work in progress."
44
45   The list of current Internet-Drafts can be accessed at
46   http://www.ietf.org/ietf/1id-abstracts.txt.
47
48   The list of Internet-Draft Shadow Directories can be accessed at
49   http://www.ietf.org/shadow.html.
50
51   This Internet-Draft will expire on July 15, 2008.
52
53
54
55Fielding, et al.          Expires July 15, 2008                 [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                January 2008
58
59
60Copyright Notice
61
62   Copyright (C) The IETF Trust (2008).
63
64Abstract
65
66   The Hypertext Transfer Protocol (HTTP) is an application-level
67   protocol for distributed, collaborative, hypermedia information
68   systems.  HTTP has been in use by the World Wide Web global
69   information initiative since 1990.  This document is Part 7 of the
70   seven-part specification that defines the protocol referred to as
71   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
72   HTTP Authentication.
73
74Editorial Note (To be removed by RFC Editor)
75
76   Discussion of this draft should take place on the HTTPBIS working
77   group mailing list (ietf-http-wg@w3.org).  The current issues list is
78   at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
79   documents (including fancy diffs) can be found at
80   <http://www.tools.ietf.org/wg/httpbis/>.
81
82   This draft incorporates those issue resolutions that were either
83   collected in the original RFC2616 errata list
84   (<http://purl.org/NET/http-errata>), or which were agreed upon on the
85   mailing list between October 2006 and November 2007 (as published in
86   "draft-lafon-rfc2616bis-03").
87
88
89
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 July 15, 2008                 [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                January 2008
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120   2.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  4
121     2.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  4
122     2.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  5
123   3.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
124     3.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  5
125     3.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  6
126     3.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  6
127     3.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
128   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
129   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
130     5.1.  Authentication Credentials and Idle Clients  . . . . . . .  7
131   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
132   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
133     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
134     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
135   Appendix A.  Compatibility with Previous Versions  . . . . . . . .  9
136     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . .  9
137   Appendix B.  Change Log (to be removed by RFC Editor before
138                publication)  . . . . . . . . . . . . . . . . . . . .  9
139     B.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . .  9
140     B.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . .  9
141   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
142   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
143   Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 July 15, 2008                 [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                January 2008
170
171
1721.  Introduction
173
174   This document defines HTTP/1.1 access control and authentication.
175   Right now it includes the extracted relevant sections of RFC 2616
176   with only minor changes.  The intention is to move the general
177   framework for HTTP authentication here, as currently specified in
178   [RFC2617], and allow the individual authentication mechanisms to be
179   defined elsewhere.  This introduction will be rewritten when that
180   occurs.
181
182   HTTP provides several OPTIONAL challenge-response authentication
183   mechanisms which can be used by a server to challenge a client
184   request and by a client to provide authentication information.  The
185   general framework for access authentication, and the specification of
186   "basic" and "digest" authentication, are specified in "HTTP
187   Authentication: Basic and Digest Access Authentication" [RFC2617].
188   This specification adopts the definitions of "challenge" and
189   "credentials" from that specification.
190
1911.1.  Requirements
192
193   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195   document are to be interpreted as described in [RFC2119].
196
197   An implementation is not compliant if it fails to satisfy one or more
198   of the MUST or REQUIRED level requirements for the protocols it
199   implements.  An implementation that satisfies all the MUST or
200   REQUIRED level and all the SHOULD level requirements for its
201   protocols is said to be "unconditionally compliant"; one that
202   satisfies all the MUST level requirements but not all the SHOULD
203   level requirements for its protocols is said to be "conditionally
204   compliant."
205
206
2072.  Status Code Definitions
208
2092.1.  401 Unauthorized
210
211   The request requires user authentication.  The response MUST include
212   a WWW-Authenticate header field (Section 3.4) containing a challenge
213   applicable to the requested resource.  The client MAY repeat the
214   request with a suitable Authorization header field (Section 3.1).  If
215   the request already included Authorization credentials, then the 401
216   response indicates that authorization has been refused for those
217   credentials.  If the 401 response contains the same challenge as the
218   prior response, and the user agent has already attempted
219   authentication at least once, then the user SHOULD be presented the
220
221
222
223Fielding, et al.          Expires July 15, 2008                 [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                January 2008
226
227
228   entity that was given in the response, since that entity might
229   include relevant diagnostic information.  HTTP access authentication
230   is explained in "HTTP Authentication: Basic and Digest Access
231   Authentication" [RFC2617].
232
2332.2.  407 Proxy Authentication Required
234
235   This code is similar to 401 (Unauthorized), but indicates that the
236   client must first authenticate itself with the proxy.  The proxy MUST
237   return a Proxy-Authenticate header field (Section 3.2) containing a
238   challenge applicable to the proxy for the requested resource.  The
239   client MAY repeat the request with a suitable Proxy-Authorization
240   header field (Section 3.3).  HTTP access authentication is explained
241   in "HTTP Authentication: Basic and Digest Access Authentication"
242   [RFC2617].
243
244
2453.  Header Field Definitions
246
247   This section defines the syntax and semantics of HTTP/1.1 header
248   fields related to authentication.
249
2503.1.  Authorization
251
252   A user agent that wishes to authenticate itself with a server--
253   usually, but not necessarily, after receiving a 401 response--does so
254   by including an Authorization request-header field with the request.
255   The Authorization field value consists of credentials containing the
256   authentication information of the user agent for the realm of the
257   resource being requested.
258
259     Authorization  = "Authorization" ":" credentials
260
261   HTTP access authentication is described in "HTTP Authentication:
262   Basic and Digest Access Authentication" [RFC2617].  If a request is
263   authenticated and a realm specified, the same credentials SHOULD be
264   valid for all other requests within this realm (assuming that the
265   authentication scheme itself does not require otherwise, such as
266   credentials that vary according to a challenge value or using
267   synchronized clocks).
268
269   When a shared cache (see Section 8 of [Part6]) receives a request
270   containing an Authorization field, it MUST NOT return the
271   corresponding response as a reply to any other request, unless one of
272   the following specific exceptions holds:
273
274
275
276
277
278
279Fielding, et al.          Expires July 15, 2008                 [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                January 2008
282
283
284   1.  If the response includes the "s-maxage" cache-control directive,
285       the cache MAY use that response in replying to a subsequent
286       request.  But (if the specified maximum age has passed) a proxy
287       cache MUST first revalidate it with the origin server, using the
288       request-headers from the new request to allow the origin server
289       to authenticate the new request.  (This is the defined behavior
290       for s-maxage.)  If the response includes "s-maxage=0", the proxy
291       MUST always revalidate it before re-using it.
292
293   2.  If the response includes the "must-revalidate" cache-control
294       directive, the cache MAY use that response in replying to a
295       subsequent request.  But if the response is stale, all caches
296       MUST first revalidate it with the origin server, using the
297       request-headers from the new request to allow the origin server
298       to authenticate the new request.
299
300   3.  If the response includes the "public" cache-control directive, it
301       MAY be returned in reply to any subsequent request.
302
3033.2.  Proxy-Authenticate
304
305   The Proxy-Authenticate response-header field MUST be included as part
306   of a 407 (Proxy Authentication Required) response.  The field value
307   consists of a challenge that indicates the authentication scheme and
308   parameters applicable to the proxy for this Request-URI.
309
310     Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
311
312   The HTTP access authentication process is described in "HTTP
313   Authentication: Basic and Digest Access Authentication" [RFC2617].
314   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
315   only to the current connection and SHOULD NOT be passed on to
316   downstream clients.  However, an intermediate proxy might need to
317   obtain its own credentials by requesting them from the downstream
318   client, which in some circumstances will appear as if the proxy is
319   forwarding the Proxy-Authenticate header field.
320
3213.3.  Proxy-Authorization
322
323   The Proxy-Authorization request-header field allows the client to
324   identify itself (or its user) to a proxy which requires
325   authentication.  The Proxy-Authorization field value consists of
326   credentials containing the authentication information of the user
327   agent for the proxy and/or realm of the resource being requested.
328
329     Proxy-Authorization     = "Proxy-Authorization" ":" credentials
330
331   The HTTP access authentication process is described in "HTTP
332
333
334
335Fielding, et al.          Expires July 15, 2008                 [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                January 2008
338
339
340   Authentication: Basic and Digest Access Authentication" [RFC2617].
341   Unlike Authorization, the Proxy-Authorization header field applies
342   only to the next outbound proxy that demanded authentication using
343   the Proxy-Authenticate field.  When multiple proxies are used in a
344   chain, the Proxy-Authorization header field is consumed by the first
345   outbound proxy that was expecting to receive credentials.  A proxy
346   MAY relay the credentials from the client request to the next proxy
347   if that is the mechanism by which the proxies cooperatively
348   authenticate a given request.
349
3503.4.  WWW-Authenticate
351
352   The WWW-Authenticate response-header field MUST be included in 401
353   (Unauthorized) response messages.  The field value consists of at
354   least one challenge that indicates the authentication scheme(s) and
355   parameters applicable to the Request-URI.
356
357     WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
358
359   The HTTP access authentication process is described in "HTTP
360   Authentication: Basic and Digest Access Authentication" [RFC2617].
361   User agents are advised to take special care in parsing the WWW-
362   Authenticate field value as it might contain more than one challenge,
363   or if more than one WWW-Authenticate header field is provided, the
364   contents of a challenge itself can contain a comma-separated list of
365   authentication parameters.
366
367
3684.  IANA Considerations
369
370   TBD.
371
372
3735.  Security Considerations
374
375   This section is meant to inform application developers, information
376   providers, and users of the security limitations in HTTP/1.1 as
377   described by this document.  The discussion does not include
378   definitive solutions to the problems revealed, though it does make
379   some suggestions for reducing security risks.
380
3815.1.  Authentication Credentials and Idle Clients
382
383   Existing HTTP clients and user agents typically retain authentication
384   information indefinitely.  HTTP/1.1 does not provide a method for a
385   server to direct clients to discard these cached credentials.  This
386   is a significant defect that requires further extensions to HTTP.
387   Circumstances under which credential caching can interfere with the
388
389
390
391Fielding, et al.          Expires July 15, 2008                 [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                January 2008
394
395
396   application's security model include but are not limited to:
397
398   o  Clients which have been idle for an extended period following
399      which the server might wish to cause the client to reprompt the
400      user for credentials.
401
402   o  Applications which include a session termination indication (such
403      as a `logout' or `commit' button on a page) after which the server
404      side of the application `knows' that there is no further reason
405      for the client to retain the credentials.
406
407   This is currently under separate study.  There are a number of work-
408   arounds to parts of this problem, and we encourage the use of
409   password protection in screen savers, idle time-outs, and other
410   methods which mitigate the security problems inherent in this
411   problem.  In particular, user agents which cache credentials are
412   encouraged to provide a readily accessible mechanism for discarding
413   cached credentials under user control.
414
415
4166.  Acknowledgments
417
418   TBD.
419
420
4217.  References
422
4237.1.  Normative References
424
425   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
426              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
427              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
428              draft-ietf-httpbis-p6-cache-01 (work in progress),
429              January 2008.
430
431   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
432              Requirement Levels", BCP 14, RFC 2119, March 1997.
433
434   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
435              Leach, P., Luotonen, A., and L. Stewart, "HTTP
436              Authentication: Basic and Digest Access Authentication",
437              RFC 2617, June 1999.
438
4397.2.  Informative References
440
441   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
442              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
443              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
444
445
446
447Fielding, et al.          Expires July 15, 2008                 [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                January 2008
450
451
452Appendix A.  Compatibility with Previous Versions
453
454A.1.  Changes from RFC 2616
455
456
457Appendix B.  Change Log (to be removed by RFC Editor before publication)
458
459B.1.  Since RFC2616
460
461   Extracted relevant partitions from [RFC2616].
462
463B.2.  Since draft-ietf-httpbis-p7-auth-00
464
465   Closed issues:
466
467   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
468      and Informative references"
469
470
471Index
472
473   4
474      401 Unauthorized (status code)  4
475      407 Proxy Authentication Required (status code)  5
476
477   A
478      Authorization header  5
479
480   G
481      Grammar
482         Authorization  5
483         Proxy-Authenticate  6
484         Proxy-Authorization  6
485         WWW-Authenticate  7
486
487   H
488      Headers
489         Authorization  5
490         Proxy-Authenticate  6
491         Proxy-Authorization  6
492         WWW-Authenticate  7
493
494   P
495      Proxy-Authenticate header  6
496      Proxy-Authorization header  6
497
498   S
499      Status Codes
500
501
502
503Fielding, et al.          Expires July 15, 2008                 [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                January 2008
506
507
508         401 Unauthorized  4
509         407 Proxy Authentication Required  5
510
511   W
512      WWW-Authenticate header  7
513
514
515Authors' Addresses
516
517   Roy T. Fielding (editor)
518   Day Software
519   23 Corporate Plaza DR, Suite 280
520   Newport Beach, CA  92660
521   USA
522
523   Phone: +1-949-706-5300
524   Fax:   +1-949-706-5305
525   Email: fielding@gbiv.com
526   URI:   http://roy.gbiv.com/
527
528
529   Jim Gettys
530   One Laptop per Child
531   21 Oak Knoll Road
532   Carlisle, MA  01741
533   USA
534
535   Email: jg@laptop.org
536   URI:   http://www.laptop.org/
537
538
539   Jeffrey C. Mogul
540   Hewlett-Packard Company
541   HP Labs, Large Scale Systems Group
542   1501 Page Mill Road, MS 1177
543   Palo Alto, CA  94304
544   USA
545
546   Email: JeffMogul@acm.org
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.          Expires July 15, 2008                [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                January 2008
562
563
564   Henrik Frystyk Nielsen
565   Microsoft Corporation
566   1 Microsoft Way
567   Redmond, WA  98052
568   USA
569
570   Email: henrikn@microsoft.com
571
572
573   Larry Masinter
574   Adobe Systems, Incorporated
575   345 Park Ave
576   San Jose, CA  95110
577   USA
578
579   Email: LMM@acm.org
580   URI:   http://larry.masinter.net/
581
582
583   Paul J. Leach
584   Microsoft Corporation
585   1 Microsoft Way
586   Redmond, WA  98052
587
588   Email: paulle@microsoft.com
589
590
591   Tim Berners-Lee
592   World Wide Web Consortium
593   MIT Computer Science and Artificial Intelligence Laboratory
594   The Stata Center, Building 32
595   32 Vassar Street
596   Cambridge, MA  02139
597   USA
598
599   Email: timbl@w3.org
600   URI:   http://www.w3.org/People/Berners-Lee/
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615Fielding, et al.          Expires July 15, 2008                [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                January 2008
618
619
620   Yves Lafon (editor)
621   World Wide Web Consortium
622   W3C / ERCIM
623   2004, rte des Lucioles
624   Sophia-Antipolis, AM  06902
625   France
626
627   Email: ylafon@w3.org
628   URI:   http://www.raubacapeu.net/people/yves/
629
630
631   Julian F. Reschke (editor)
632   greenbytes GmbH
633   Hafenweg 16
634   Muenster, NW  48155
635   Germany
636
637   Phone: +49 251 2807760
638   Fax:   +49 251 2807761
639   Email: julian.reschke@greenbytes.de
640   URI:   http://greenbytes.de/tech/webdav/
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671Fielding, et al.          Expires July 15, 2008                [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                January 2008
674
675
676Full Copyright Statement
677
678   Copyright (C) The IETF Trust (2008).
679
680   This document is subject to the rights, licenses and restrictions
681   contained in BCP 78, and except as set forth therein, the authors
682   retain all their rights.
683
684   This document and the information contained herein are provided on an
685   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
686   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
687   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
688   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
689   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
690   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
691
692
693Intellectual Property
694
695   The IETF takes no position regarding the validity or scope of any
696   Intellectual Property Rights or other rights that might be claimed to
697   pertain to the implementation or use of the technology described in
698   this document or the extent to which any license under such rights
699   might or might not be available; nor does it represent that it has
700   made any independent effort to identify any such rights.  Information
701   on the procedures with respect to rights in RFC documents can be
702   found in BCP 78 and BCP 79.
703
704   Copies of IPR disclosures made to the IETF Secretariat and any
705   assurances of licenses to be made available, or the result of an
706   attempt made to obtain a general license or permission for the use of
707   such proprietary rights by implementers or users of this
708   specification can be obtained from the IETF on-line IPR repository at
709   http://www.ietf.org/ipr.
710
711   The IETF invites any interested party to bring to its attention any
712   copyrights, patents or patent applications, or other proprietary
713   rights that may cover technology that may be required to implement
714   this standard.  Please address the information to the IETF at
715   ietf-ipr@ietf.org.
716
717
718Acknowledgment
719
720   Funding for the RFC Editor function is provided by the IETF
721   Administrative Support Activity (IASA).
722
723
724
725
726
727Fielding, et al.          Expires July 15, 2008                [Page 13]
728
Note: See TracBrowser for help on using the repository browser.