├── .gitignore
├── DEV.md
├── HTTP2中英对照版(06-29).md
├── Makefile
├── README.md
├── SUBMITTING.md
├── draft-ietf-httpbis-header-compression.xml
├── draft-ietf-httpbis-http2-zh.xml
├── draft-ietf-httpbis-http2.xml
├── lib
├── clean-for-DTD.xslt
├── myxml2rfc.xslt
├── rfc2629.xslt
├── saxonb9-1-0-8j
│ ├── saxon9-dom.jar
│ ├── saxon9-dom4j.jar
│ ├── saxon9-jdom.jar
│ ├── saxon9-s9api.jar
│ ├── saxon9-sql.jar
│ ├── saxon9-xom.jar
│ ├── saxon9-xpath.jar
│ ├── saxon9-xqj.jar
│ └── saxon9.jar
└── style.css
└── refs
├── draft-ietf-httpbis-p1-messaging-22.xml
├── draft-ietf-httpbis-p1-messaging-23.xml
├── draft-ietf-httpbis-p1-messaging-24.xml
├── draft-ietf-httpbis-p1-messaging-25.xml
├── draft-ietf-httpbis-p1-messaging-26.xml
├── draft-ietf-httpbis-p2-semantics-22.xml
├── draft-ietf-httpbis-p2-semantics-23.xml
├── draft-ietf-httpbis-p2-semantics-24.xml
├── draft-ietf-httpbis-p2-semantics-25.xml
├── draft-ietf-httpbis-p2-semantics-26.xml
├── draft-ietf-httpbis-p6-cache-24.xml
├── draft-ietf-httpbis-p6-cache-25.xml
├── draft-ietf-httpbis-p6-cache-26.xml
├── draft-ietf-httpbis-p7-auth-22.xml
├── draft-ietf-httpbis-p7-auth-23.xml
├── draft-ietf-httpbis-p7-auth-24.xml
├── draft-ietf-httpbis-p7-auth-25.xml
└── draft-ietf-httpbis-p7-auth-26.xml
/.gitignore:
--------------------------------------------------------------------------------
1 | *.redxml
2 | *.txt
3 | *.html
4 | *~
5 | *-[0-9][0-9].xml
6 | issues.json
7 |
8 |
--------------------------------------------------------------------------------
/DEV.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ## 生成 html 的方法
4 |
5 | 在命令行下运行
6 |
7 | java -classpath lib/saxonb9-1-0-8j/saxon9.jar net.sf.saxon.Transform -s:draft-ietf-httpbis-http2-zh.xml -xsl:lib/rfc2629.xslt -o:draft-ietf-httpbis-http2-zh.html
--------------------------------------------------------------------------------
/Makefile:
--------------------------------------------------------------------------------
1 | xml2rfc ?= "/usr/local/bin/xml2rfc"
2 | saxpath ?= "$(HOME)/java/saxon-8-9-j/saxon8.jar"
3 | saxon ?= java -classpath $(saxpath) net.sf.saxon.Transform -novw -l
4 |
5 | names := http2 header-compression
6 | drafts := $(addprefix draft-ietf-httpbis-,$(names))
7 | current_ver = $(shell git tag | grep "$(draft)" | sort | tail -1 | awk -F- '{print $$NF}')
8 | next_ver := $(foreach draft, $(drafts), -$(shell printf "%.2d" $$((1$(current_ver)-99)) ) )
9 | next := $(join $(drafts),$(next_ver))
10 |
11 | TARGETS := $(addsuffix .txt,$(drafts)) \
12 | $(addsuffix .html,$(drafts))
13 |
14 | .PHONY: latest submit idnits clean issues $(names) hpack
15 | .INTERMEDIATE: $(addsuffix .redxml,$(drafts))
16 |
17 | latest: $(TARGETS)
18 |
19 | # build rules for specific targets
20 | makerule = $(join $(addsuffix :: ,$(names)),$(addsuffix .$(1),$(drafts)))
21 | $(foreach rule,$(call makerule,txt) $(call makerule,html),$(eval $(rule)))
22 | hpack: header-compression
23 |
24 | submit: $(addsuffix .txt,$(next))
25 |
26 | idnits: $(addsuffix .txt,$(next))
27 | idnits $<
28 |
29 | clean:
30 | -rm -f $(addsuffix .redxml,$(drafts))
31 | -rm -f $(addsuffix *.txt,$(drafts))
32 | -rm -f $(addsuffix *-[0-9][0-9].xml,$(drafts))
33 | -rm -f $(addsuffix *.html,$(drafts))
34 |
35 | define makerule_submit_xml =
36 | $(1)
37 | sed -e"s/$$(basename $$<)-latest/$$(basename $$@)/" $$< > $$@
38 | endef
39 | submit_deps := $(join $(addsuffix .xml: ,$(next)),$(addsuffix .redxml,$(drafts)))
40 | $(foreach rule,$(submit_deps),$(eval $(call makerule_submit_xml,$(rule))))
41 |
42 | $(addsuffix .txt,$(next)): %.txt: %.xml
43 | $(xml2rfc) $< $@
44 |
45 | %.txt: %.redxml
46 | $(xml2rfc) $< $@
47 |
48 | stylesheet := lib/myxml2rfc.xslt
49 | extra_css := lib/style.css
50 | css_content = $(shell cat $(extra_css))
51 | %.htmltmp: %.xml $(stylesheet) $(extra_css)
52 | $(saxon) $< $(stylesheet) > $@
53 |
54 | %.html: %.htmltmp
55 | sed -e's~~~' $< > $@
56 |
57 | reduction := lib/clean-for-DTD.xslt
58 | %.redxml: %.xml $(reduction)
59 | $(saxon) $< $(reduction) > $@
60 |
61 | %.xhtml: %.xml ../../rfc2629xslt/rfc2629toXHTML.xslt
62 | $(saxon) $< ../../rfc2629xslt/rfc2629toXHTML.xslt > $@
63 |
64 | # backup issues
65 | issues:
66 | curl https://api.github.com/repos/http2/http2-spec/issues?state=open > issues.json
67 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 | HTTP/2 Draft Specifications
3 | =============================
4 |
5 | This is the working area for the [IETF HTTPbis Working
6 | Group](http://trac.tools.ietf.org/wg/httpbis/trac/wiki) draft of
7 | [HTTP/2](http://http2.github.io/).
8 |
9 | HTTP/2 specification:
10 | * [Editor's copy](http://http2.github.com/http2-spec/index.html) (HTML)
11 | * [Editor's copy](http://http2.github.com/http2-spec/index.txt) (plain text)
12 | * [Working Group Draft](http://tools.ietf.org/html/draft-ietf-httpbis-http2) (less recent, more official)
13 |
14 | Header Compression (HPACK) specification:
15 | * [Editor's copy](http://http2.github.com/http2-spec/compression.html) (HTML)
16 | * [Editor's copy](http://http2.github.com/http2-spec/compression.txt) (plain text)
17 | * [Working Group Draft](http://tools.ietf.org/html/draft-ietf-httpbis-header-compression) (less recent, more official)
18 |
19 | Alternative Services specification:
20 | * [Editor's copy](http://http2.github.com/http2-spec/alt-svc.html) (HTML)
21 | * [Editor's copy](http://http2.github.com/http2-spec/alt-svc.txt) (plain text)
22 | * [Working Group Draft](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc) (less recent, more official)
23 |
24 |
25 | Contributing
26 | ------------
27 |
28 | Before submitting feedback, please familiarize yourself with our current issues
29 | list and review the [HTTP/2 page](http://http2.github.io/) and the [working
30 | group home page](http://trac.tools.ietf.org/wg/httpbis/trac/wiki). If you're
31 | new to this, you may also want to read the [Tao of the
32 | IETF](http://www.ietf.org/tao.html).
33 |
34 | Be aware that all contributions to the specification fall under the "NOTE WELL"
35 | terms outlined below.
36 |
37 | 1. The best way to provide feedback (editorial or design) and ask questions is
38 | sending an e-mail to [our mailing
39 | list](http://lists.w3.org/Archives/Public/ietf-http-wg/). This will assure that
40 | the entire Working Group sees your input in a timely fashion.
41 |
42 | 2. If you have **editorial** suggestions (i.e., those that do not change the
43 | meaning of the specification), you can either:
44 |
45 | a) Fork this repository and submit a pull request; this is the lowest
46 | friction way to get editorial changes in.
47 |
48 | b) Submit a new issue to Github, and mention that you believe it is editorial
49 | in the issue body. It is not necessary to notify the mailing list for
50 | editorial issues.
51 |
52 | c) Make comments on individual commits in Github. Note that this feedback is
53 | processed only with best effort by the editors, so it should only be used for
54 | quick editorial suggestions or questions.
55 |
56 | 3. For non-editorial (i.e., **design**) issues, you can also create an issue on
57 | Github. However, you **must notify the mailing list** when creating such issues,
58 | providing a link to the issue in the message body.
59 |
60 | Note that **github issues are not for substantial discussions**; the only
61 | appropriate place to discuss design issues is on the mailing list itself.
62 |
63 |
64 | Working With the Drafts
65 | -----------------------
66 |
67 | The source for our current draft is
68 | [draft-ietf-httpbis-http2.xml](draft-ietf-httpbis-http2.xml), using the
69 | [RFC2629 format](http://xml.resource.org/public/rfc/html/rfc2629.html).
70 |
71 | If you're an editor, or forking a copy of the draft, a few things to know:
72 |
73 | * Pushing to the master branch will automatically generate the HTML on the
74 | gh-pages branch.
75 | * You'll need xml2rfc, Java and Saxon-HE available. You can override the
76 | default locations in the environment. On a Mac with
77 | [Homebrew](http://mxcl.github.io/homebrew/), "saxon-b" is the right package.
78 | * Some of the make targets require GNU Make 4.0
79 | * Making the txt and html for the latest drafts is done with "make".
80 | * Output for a specific draft can be made using "make http2" or
81 | "make hpack".
82 |
83 |
84 | NOTE WELL
85 | ---------
86 |
87 | Any submission to the [IETF](http://www.ietf.org/) intended by the Contributor
88 | for publication as all or part of an IETF Internet-Draft or RFC and any
89 | statement made within the context of an IETF activity is considered an "IETF
90 | Contribution". Such statements include oral statements in IETF sessions, as
91 | well as written and electronic communications made at any time or place, which
92 | are addressed to:
93 |
94 | * The IETF plenary session
95 | * The IESG, or any member thereof on behalf of the IESG
96 | * Any IETF mailing list, including the IETF list itself, any working group
97 | or design team list, or any other list functioning under IETF auspices
98 | * Any IETF working group or portion thereof
99 | * Any Birds of a Feather (BOF) session
100 | * The IAB or any member thereof on behalf of the IAB
101 | * The RFC Editor or the Internet-Drafts function
102 | * All IETF Contributions are subject to the rules of
103 | [RFC 5378](http://tools.ietf.org/html/rfc5378) and
104 | [RFC 3979](http://tools.ietf.org/html/rfc3979)
105 | (updated by [RFC 4879](http://tools.ietf.org/html/rfc4879)).
106 |
107 | Statements made outside of an IETF session, mailing list or other function,
108 | that are clearly not intended to be input to an IETF activity, group or
109 | function, are not IETF Contributions in the context of this notice.
110 |
111 | Please consult [RFC 5378](http://tools.ietf.org/html/rfc5378) and [RFC
112 | 3979](http://tools.ietf.org/html/rfc3979) for details.
113 |
114 | A participant in any IETF activity is deemed to accept all IETF rules of
115 | process, as documented in Best Current Practices RFCs and IESG Statements.
116 |
117 | A participant in any IETF activity acknowledges that written, audio and video
118 | records of meetings may be made and may be available to the public.
119 |
--------------------------------------------------------------------------------
/SUBMITTING.md:
--------------------------------------------------------------------------------
1 | Submitting
2 | ==========
3 |
4 | When you're ready to submit a new version of a draft:
5 |
6 | 0. git status <-- all changes should be committed and pushed.
7 |
8 | 1. Double-check the year on the date element to make sure it's current.
9 |
10 | 2. Check the "Changes" section for this draft to make sure it's appropriate
11 | (e.g., replace "None yet" with "None").
12 |
13 | 3. make submit
14 |
15 | 4. Submit draft-ietf-httpbis--NN to https://datatracker.ietf.org/submit/
16 |
17 | 5. make clean
18 |
19 | 6. git tag draft-ietf-httpbis--NN;
20 | git push --tags
21 |
22 | 7. Add "Since draft-ietf-httpbis--...-NN" subsection to "Changes".
23 |
24 | 8. Add/remove any "implementation draft" notices from the abstract.
25 |
--------------------------------------------------------------------------------
/lib/clean-for-DTD.xslt:
--------------------------------------------------------------------------------
1 |
31 |
32 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 | This XML document is the output of clean-for-DTD.xslt; a tool that strips
56 | extensions to RFC2629(bis) from documents for processing with xml2rfc.
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 | Issues that were either rejected or resolved in this version of this
98 | document.
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 |
124 | %x
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 | Converted from rfc2629.xslt x:prose extension
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 | FATAL: multiple x:ref targets found for .
165 |
166 |
167 |
168 |
169 |
170 |
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 |
179 |
180 | couldn't create the link as does not support the anchor attribute.
181 |
182 |
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 |
192 |
193 | internal link target for '' does not exist.
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 |
209 |
210 |
211 |
212 |
213 |
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 | "
236 |
237 | "
238 |
239 |
240 |
241 |
242 |
246 |
247 |
248 |
249 |
250 | ^
251 |
252 |
253 |
254 |
255 |
256 |
257 |
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 | (see Authors Section)
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
289 |
290 |
291 |
292 | Appendix
293 | Section
294 |
295 |
296 |
297 |
298 |
299 |
300 | ,
301 | of
302 |
303 |
304 |
305 |
306 |
307 |
308 |
309 |
310 | ,
311 |
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 |
320 |
321 |
322 |
323 |
324 |
325 |
326 |
327 | (
328 |
329 |
330 |
331 | )
332 |
333 |
334 |
335 |
336 |
337 | of
338 |
339 |
340 |
341 |
342 |
343 |
344 |
345 |
346 |
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 |
356 |
357 |
358 |
359 |
360 |
361 |
362 |
363 |
364 |
365 |
366 |
367 |
368 |
369 |
370 |
371 |
372 | Unsupported x:fmt attribute.
373 |
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 | Broken xref due to target being filtered out.
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 |
424 |
425 |
426 |
427 |
428 |
429 |
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 |
449 |
450 |
451 |
452 |
453 |
454 |
455 |
456 |
457 |
458 |
459 |
460 | In Section :
461 |
462 |
463 |
464 |
465 | Type:
466 |
467 |
468 |
469 |
470 |
471 | <
472 |
473 | >
474 |
475 | , <
476 |
477 | >
478 |
479 |
480 |
481 |
482 |
483 |
484 |
485 |
486 |
487 |
488 |
489 |
490 |
491 |
492 |
493 |
494 |
495 |
496 |
497 |
498 |
499 |
500 |
501 |
502 |
503 |
504 |
505 |
506 |
507 |
508 |
509 |
510 |
511 |
512 |
513 |
514 |
515 |
516 |
517 |
518 |
519 |
520 |
521 |
522 |
523 |
524 | Resolution
525 | ()
526 | :
527 |
528 |
529 |
530 |
531 |
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 |
540 |
541 |
542 |
543 | "
544 |
545 | "
546 |
547 | --
548 |
549 |
550 |
551 |
552 |
553 |
554 |
555 |
556 |
557 |
558 | <del>
559 |
560 | </del>
561 |
562 |
563 |
564 |
565 |
566 |
567 |
568 |
569 |
570 | <ins>
571 |
572 | </ins>
573 |
574 |
575 |
576 |
577 |
578 |
579 |
580 | <
581 |
582 | >
583 |
584 |
585 |
586 |
587 |
588 |
589 |
590 |
591 |
592 |
593 |
594 |
595 |
596 |
597 |
598 |
599 |
600 |
601 |
602 |
603 |
604 |
605 |
606 |
607 |
608 |
609 |
610 |
611 |
612 |
613 |
614 |
615 |
616 |
617 |
618 |
619 |
620 |
621 |
622 |
623 |
624 |
625 |
626 |
627 |
628 |
629 |
630 |
631 |
632 |
633 |
634 |
635 |
636 |
637 |
638 |
639 |
640 |
641 |
642 |
643 |
644 |
645 | <CODE BEGINS>
646 |
647 |
648 |
649 |
650 |
651 |
652 |
653 |
654 |
655 |
656 |
657 |
658 |
659 |
660 |
661 |
662 |
<CODE ENDS>
663 |
664 |
665 |
666 |
667 |
668 |
669 |
670 |
671 |
672 |
673 |
674 |
675 |
676 |
677 |
678 |
679 |
680 |
681 |
682 |
683 |
684 |
685 |
686 |
687 |
688 |
689 |
690 |
691 |
692 |
693 |
694 |
695 |
696 |
697 | ,
698 |
699 |
700 |
701 |
702 |
703 |
704 |
705 |
706 | <
707 |
708 | >
709 |
710 |
711 |
712 |
713 |
714 |
715 |
716 |
717 |
718 |
719 |
720 |
721 |
722 |
723 |
724 |
725 | Dropping annotation on element.
726 |
727 |
728 |
729 |
730 |
731 |
732 |
733 |
734 |
735 |
736 |
737 |
738 |
739 |
740 |
741 |
742 |
743 |
744 |
745 |
746 |
747 |
748 |
749 |
750 |
751 |
752 |
753 |
754 |
755 |
756 |
757 |
758 |
759 |
760 |
761 |
762 |
763 |
764 |
--------------------------------------------------------------------------------
/lib/myxml2rfc.xslt:
--------------------------------------------------------------------------------
1 |
3 |
4 |
5 |
6 |
8 |
9 |
10 |
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-dom.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-dom.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-dom4j.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-dom4j.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-jdom.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-jdom.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-s9api.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-s9api.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-sql.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-sql.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-xom.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-xom.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-xpath.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-xpath.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9-xqj.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9-xqj.jar
--------------------------------------------------------------------------------
/lib/saxonb9-1-0-8j/saxon9.jar:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fex-team/http2-spec/d269b36a3caac4fbcc605773cc85ad0b18e38388/lib/saxonb9-1-0-8j/saxon9.jar
--------------------------------------------------------------------------------
/lib/style.css:
--------------------------------------------------------------------------------
1 | @viewport {
2 | zoom: 1.0;
3 | width: extend-to-zoom;
4 | }
5 |
6 | @-ms-viewport {
7 | width: extend-to-zoom;
8 | zoom: 1.0;
9 | }
10 |
11 | body {
12 | font: 11pt cambria, helvetica, arial, sans-serif;
13 | font-size-adjust: 0.5;
14 | line-height: 130%;
15 | margin: 1em auto;
16 | max-width: 700px;
17 | }
18 |
19 | .title, .filename, h1, h2, h3, h4 {
20 | font-family: candara, helvetica, arial, sans-serif;
21 | font-size-adjust: 0.5;
22 | }
23 | .title { font-size: 150%; }
24 | h1 { font-size: 130%; }
25 | h2 { font-size: 120%; }
26 | h3, h4 { font-size: 110%; }
27 | ul.toc >li { font-size: 95%; }
28 | ul.toc >li >ul, .figure, caption { font-size: 90%; }
29 |
30 | table {
31 | margin-left: 0em;
32 | }
33 | table.header {
34 | width: 100%;
35 | }
36 |
37 | table.header td {
38 | background-color: inherit;
39 | color: black;
40 | }
41 |
42 | samp, tt, code, pre {
43 | font: 11pt consolas, monospace;
44 | font-size-adjust: none;
45 | }
46 |
47 | pre.text, pre.text2 {
48 | width: 90%;
49 | }
50 |
51 | dt {
52 | float: left; clear: left;
53 | margin: 0.5em 0.5em 0 0;
54 | }
55 | dt:first-child {
56 | margin-top: 0;
57 | }
58 | dd {
59 | margin: 0.5em 0 0 2em;
60 | }
61 | dd p, dd ul {
62 | margin-top: 0; margin-bottom: 0;
63 | }
64 | dd *+p {
65 | margin-top: 0.5em;
66 | }
67 |
68 | ol, ul {
69 | padding: 0;
70 | margin: 0.5em 0 0.5em 2em;
71 | }
72 | ul.toc, ul.toc ul {
73 | margin: 0 0 0 1.5em;
74 | }
75 | ul.toc a:first-child {
76 | display: inline-block;
77 | min-width: 1.2em;
78 | }
--------------------------------------------------------------------------------
/refs/draft-ietf-httpbis-p7-auth-22.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 | MAY">
5 | MUST">
6 | MUST NOT">
7 | OPTIONAL">
8 | RECOMMENDED">
9 | REQUIRED">
10 | SHALL">
11 | SHALL NOT">
12 | SHOULD">
13 | SHOULD NOT">
14 |
15 |
16 |
17 |
18 | Note:">
19 | ">
20 | ">
21 | ">
22 | ">
23 | ">
24 | ">
25 | ">
26 | ">
27 | ">
28 | ">
29 | ">
30 | ">
31 | ">
32 | ">
33 | ]>
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
49 |
50 |
51 |
52 |
53 | Hypertext Transfer Protocol (HTTP/1.1): Authentication
54 |
55 |
56 | Adobe Systems Incorporated
57 |
58 |
59 | 345 Park Ave
60 | San Jose
61 | CA
62 | 95110
63 | USA
64 |
65 | fielding@gbiv.com
66 | http://roy.gbiv.com/
67 |
68 |
69 |
70 |
71 | greenbytes GmbH
72 |
73 |
74 | Hafenweg 16
75 | MuensterNW48155
76 | Germany
77 |
78 | julian.reschke@greenbytes.de
79 | http://greenbytes.de/tech/webdav/
80 |
81 |
82 |
83 |
84 | HTTPbis Working Group
85 |
86 |
87 |
88 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
89 | distributed, collaborative, hypermedia information systems. This document
90 | defines the HTTP Authentication framework.
91 |
92 |
93 |
94 |
95 |
96 | Discussion of this draft takes place on the HTTPBIS working group
97 | mailing list (ietf-http-wg@w3.org), which is archived at
98 | .
99 |
100 |
101 | The current issues list is at
102 | and related
103 | documents (including fancy diffs) can be found at
104 | .
105 |
106 |
107 | The changes in this draft are summarized in .
108 |
109 |
110 |
111 |
112 |
113 |
114 | This document defines HTTP/1.1 access control and authentication. It
115 | includes the relevant parts of RFC 2616
116 | with only minor changes (), plus the general framework for HTTP authentication,
117 | as previously defined in "HTTP Authentication: Basic and Digest Access
118 | Authentication" ().
119 |
120 |
121 | HTTP provides several &OPTIONAL; challenge-response authentication
122 | mechanisms that can be used by a server to challenge a client request and
123 | by a client to provide authentication information. The "basic" and "digest"
124 | authentication schemes continue to be specified in
125 | RFC 2617.
126 |
127 |
128 |
129 |
130 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
132 | document are to be interpreted as described in .
133 |
134 |
135 | Conformance criteria and considerations regarding error handling
136 | are defined in &conformance;.
137 |
138 |
139 |
140 |
141 |
142 | This specification uses the Augmented Backus-Naur Form (ABNF) notation
143 | of with the list rule extension defined in
144 | ¬ation;. describes rules imported from
145 | other documents. shows the collected ABNF
146 | with the list rule expanded.
147 |
148 |
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 | HTTP provides a simple challenge-response authentication mechanism
161 | that can be used by a server to challenge a client request and by a
162 | client to provide authentication information. It uses an extensible,
163 | case-insensitive token to identify the authentication scheme, followed
164 | by additional information necessary for achieving authentication via that
165 | scheme. The latter can either be a comma-separated list of parameters or a
166 | single sequence of characters capable of holding base64-encoded
167 | information.
168 |
169 |
170 | Parameters are name-value pairs where the name is matched case-insensitively,
171 | and each parameter name &MUST; only occur once per challenge.
172 |
173 |
174 | auth-scheme = token
175 |
176 | auth-param = tokenBWS "=" BWS ( token / quoted-string )
177 |
178 | token68 = 1*( ALPHA / DIGIT /
179 | "-" / "." / "_" / "~" / "+" / "/" ) *"="
180 |
181 |
182 | The "token68" syntax allows the 66 unreserved URI characters (),
183 | plus a few others, so that it can hold a base64, base64url (URL and filename
184 | safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
185 | excluding whitespace ().
186 |
187 |
188 | The 401 (Unauthorized) response message is used by an origin server
189 | to challenge the authorization of a user agent. This response &MUST;
190 | include a WWW-Authenticate header field containing at least one
191 | challenge applicable to the requested resource.
192 |
193 |
194 | The 407 (Proxy Authentication Required) response message is
195 | used by a proxy to challenge the authorization of a client and &MUST;
196 | include a Proxy-Authenticate header field containing at least
197 | one challenge applicable to the proxy for the requested resource.
198 |
199 |
200 | challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
201 |
202 |
203 |
204 | &Note; User agents will need to take special care in parsing the
205 | WWW-Authenticate and Proxy-Authenticate
206 | header field values because they can contain more than one challenge, or
207 | if more than one of each is provided, since the contents of a challenge
208 | can itself contain a comma-separated list of authentication parameters.
209 |
210 |
211 |
212 |
213 | &Note; Many clients fail to parse challenges containing unknown
214 | schemes. A workaround for this problem is to list well-supported schemes
215 | (such as "basic") first.
216 |
217 |
218 |
219 | A user agent that wishes to authenticate itself with an origin server
220 | — usually, but not necessarily, after receiving a 401 (Unauthorized)
221 | — can do so by including an Authorization header field with the
222 | request.
223 |
224 |
225 | A client that wishes to authenticate itself with a proxy — usually,
226 | but not necessarily, after receiving a 407 (Proxy Authentication Required)
227 | — can do so by including a Proxy-Authorization header field with the
228 | request.
229 |
230 |
231 | Both the Authorization field value and the Proxy-Authorization field value
232 | contain the client's credentials for the realm of the resource being
233 | requested, based upon a challenge received from the server (possibly at
234 | some point in the past). When creating their values, the user agent ought to
235 | do so by selecting the challenge with what it considers to be the most
236 | secure auth-scheme that it understands, obtaining credentials from the user
237 | as appropriate.
238 |
239 |
240 | credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
241 |
242 |
243 | Upon a request for a protected resource that omits credentials, contains
244 | invalid credentials (e.g., a bad password) or partial credentials (e.g.,
245 | when the authentication scheme requires more than one round trip), an origin
246 | server &SHOULD; send a 401 (Unauthorized) response that
247 | contains a WWW-Authenticate header field with at least one
248 | (possibly new) challenge applicable to the requested resource.
249 |
250 |
251 | Likewise, upon a request that requires authentication by proxies that omit
252 | credentials or contain invalid or partial credentials, a proxy &SHOULD;
253 | send a 407 (Proxy Authentication Required) response that
254 | contains a Proxy-Authenticate header field with a (possibly
255 | new) challenge applicable to the proxy.
256 |
257 |
258 | A server receiving credentials that are valid, but not adequate to gain
259 | access, ought to respond with the 403 (Forbidden) status code (&status.403;).
260 |
261 |
262 | The HTTP protocol does not restrict applications to this simple
263 | challenge-response mechanism for access authentication. Additional
264 | mechanisms &MAY; be used, such as encryption at the transport level or
265 | via message encapsulation, and with additional header fields
266 | specifying authentication information. However, such additional
267 | mechanisms are not defined by this specification.
268 |
269 |
270 | Proxies &MUST; forward the WWW-Authenticate and
271 | Authorization header fields unmodified and follow the rules
272 | found in .
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 | The authentication parameter realm is reserved for use by authentication
282 | schemes that wish to indicate the scope of protection.
283 |
284 |
285 | A protection space is defined by the canonical root URI (the
286 | scheme and authority components of the effective request URI; see
287 | ) of the
288 | server being accessed, in combination with the realm value if present.
289 | These realms allow the protected resources on a server to be
290 | partitioned into a set of protection spaces, each with its own
291 | authentication scheme and/or authorization database. The realm value
292 | is a string, generally assigned by the origin server, that can have
293 | additional semantics specific to the authentication scheme. Note that
294 | there can be multiple challenges with the same auth-scheme but
295 | different realms.
296 |
297 |
298 | The protection space determines the domain over which credentials can
299 | be automatically applied. If a prior request has been authorized, the
300 | same credentials &MAY; be reused for all other requests within that
301 | protection space for a period of time determined by the
302 | authentication scheme, parameters, and/or user preference. Unless
303 | otherwise defined by the authentication scheme, a single protection
304 | space cannot extend outside the scope of its server.
305 |
306 |
307 | For historical reasons, senders &MUST; only use the quoted-string syntax.
308 | Recipients might have to support both token and quoted-string syntax for
309 | maximum interoperability with existing clients that have been accepting both
310 | notations for a long time.
311 |
312 |
313 |
314 |
315 |
316 | The HTTP Authentication Scheme Registry defines the name space for the
317 | authentication schemes in challenges and credentials.
318 |
319 |
320 | Registrations &MUST; include the following fields:
321 |
322 | Authentication Scheme Name
323 | Pointer to specification text
324 | Notes (optional)
325 |
326 |
327 |
328 | Values to be added to this name space require IETF Review
329 | (see ).
330 |
331 |
332 | The registry itself is maintained at .
333 |
334 |
335 |
336 |
337 | There are certain aspects of the HTTP Authentication Framework that put
338 | constraints on how new authentication schemes can work:
339 |
340 |
341 |
342 |
343 |
344 | HTTP authentication is presumed to be stateless: all of the information
345 | necessary to authenticate a request &MUST; be provided in the request,
346 | rather than be dependent on the server remembering prior requests.
347 | Authentication based on, or bound to, the underlying connection is
348 | outside the scope of this specification and inherently flawed unless
349 | steps are taken to ensure that the connection cannot be used by any
350 | party other than the authenticated user
351 | (see &msg-orient-and-buffering;).
352 |
353 |
354 |
355 |
356 | The authentication parameter "realm" is reserved for defining Protection
357 | Spaces as defined in . New schemes
358 | &MUST-NOT; use it in a way incompatible with that definition.
359 |
360 |
361 |
362 |
363 | The "token68" notation was introduced for compatibility with existing
364 | authentication schemes and can only be used once per challenge/credentials.
365 | New schemes thus ought to use the "auth-param" syntax instead, because
366 | otherwise future extensions will be impossible.
367 |
368 |
369 |
370 |
371 | The parsing of challenges and credentials is defined by this specification,
372 | and cannot be modified by new authentication schemes. When the auth-param
373 | syntax is used, all parameters ought to support both token and
374 | quoted-string syntax, and syntactical constraints ought to be defined on
375 | the field value after parsing (i.e., quoted-string processing). This is
376 | necessary so that recipients can use a generic parser that applies to
377 | all authentication schemes.
378 |
379 |
380 | &Note; The fact that the value syntax for the "realm" parameter
381 | is restricted to quoted-string was a bad design choice not to be repeated
382 | for new parameters.
383 |
384 |
385 |
386 |
387 | Definitions of new schemes ought to define the treatment of unknown
388 | extension parameters. In general, a "must-ignore" rule is preferable
389 | over "must-understand", because otherwise it will be hard to introduce
390 | new parameters in the presence of legacy recipients. Furthermore,
391 | it's good to describe the policy for defining new parameters (such
392 | as "update the specification", or "use this registry").
393 |
394 |
395 |
396 |
397 | Authentication schemes need to document whether they are usable in
398 | origin-server authentication (i.e., using WWW-Authenticate),
399 | and/or proxy authentication (i.e., using Proxy-Authenticate).
400 |
401 |
402 |
403 |
404 | The credentials carried in an Authorization header field are specific to
405 | the User Agent, and therefore have the same effect on HTTP caches as the
406 | "private" Cache-Control response directive, within the scope of the
407 | request they appear in.
408 |
409 |
410 | Therefore, new authentication schemes that choose not to carry
411 | credentials in the Authorization header field (e.g., using a newly defined
412 | header field) will need to explicitly disallow caching, by mandating the use of
413 | either Cache-Control request directives (e.g., "no-store") or response
414 | directives (e.g., "private").
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 |
424 |
425 |
426 |
427 |
428 |
429 |
430 | The 401 (Unauthorized) status code indicates that the
431 | request has not been applied because it lacks valid authentication
432 | credentials for the target resource. The origin server &MUST; send a
433 | WWW-Authenticate header field ()
434 | containing at least one challenge applicable to the target resource.
435 | If the request included authentication credentials, then the 401 response
436 | indicates that authorization has been refused for those credentials.
437 | The client &MAY; repeat the request with a new or replaced
438 | Authorization header field ().
439 | If the 401 response contains the same challenge as the prior response, and
440 | the user agent has already attempted authentication at least once, then the
441 | user agent &SHOULD; present the enclosed representation to the user, since
442 | it usually contains relevant diagnostic information.
443 |
444 |
445 |
446 |
447 |
448 |
449 | The 407 (Proxy Authentication Required) status code is
450 | similar to 401 (Unauthorized), but indicates that the client
451 | needs to authenticate itself in order to use a proxy.
452 | The proxy &MUST; send a Proxy-Authenticate header field
453 | () containing a challenge
454 | applicable to that proxy for the target resource. The client &MAY; repeat
455 | the request with a new or replaced Proxy-Authorization
456 | header field ().
457 |
458 |
459 |
460 |
461 |
462 |
463 | This section defines the syntax and semantics of HTTP/1.1 header fields
464 | related to authentication.
465 |
466 |
467 |
468 |
469 |
470 |
471 | The "Authorization" header field allows a user agent to authenticate
472 | itself with a server — usually, but not necessarily, after receiving a 401
473 | (Unauthorized) response. Its value consists of credentials containing
474 | information of the user agent for the realm of the resource being
475 | requested.
476 |
477 |
478 | Authorization = credentials
479 |
480 |
481 | If a request is
482 | authenticated and a realm specified, the same credentials &SHOULD;
483 | be valid for all other requests within this realm (assuming that
484 | the authentication scheme itself does not require otherwise, such
485 | as credentials that vary according to a challenge value or using
486 | synchronized clocks).
487 |
488 |
489 | See &caching-authenticated-responses; for details of and requirements
490 | pertaining to handling of the Authorization field by HTTP caches.
491 |
492 |
493 |
494 |
495 |
496 |
497 |
498 | The "Proxy-Authenticate" header field consists of at least one
499 | challenge that indicates the authentication scheme(s) and parameters
500 | applicable to the proxy for this effective request URI (&effective-request-uri;).
501 | It &MUST; be included as part of a 407 (Proxy Authentication Required) response.
502 |
503 |
504 | Proxy-Authenticate = 1#challenge
505 |
506 |
507 | Unlike WWW-Authenticate, the Proxy-Authenticate header field
508 | applies only to the current connection, and intermediaries &SHOULD-NOT;
509 | forward it to downstream clients. However, an intermediate proxy might need
510 | to obtain its own credentials by requesting them from the downstream client,
511 | which in some circumstances will appear as if the proxy is forwarding the
512 | Proxy-Authenticate header field.
513 |
514 |
515 | Note that the parsing considerations for WWW-Authenticate
516 | apply to this header field as well; see
517 | for details.
518 |
519 |
520 |
521 |
522 |
523 |
524 |
525 | The "Proxy-Authorization" header field allows the client to
526 | identify itself (or its user) to a proxy that requires
527 | authentication. Its value consists of
528 | credentials containing the authentication information of the user
529 | agent for the proxy and/or realm of the resource being requested.
530 |
531 |
532 | Proxy-Authorization = credentials
533 |
534 |
535 | Unlike Authorization, the Proxy-Authorization header field applies only to
536 | the next outbound proxy that demanded authentication using the Proxy-Authenticate
537 | field. When multiple proxies are used in a chain, the
538 | Proxy-Authorization header field is consumed by the first outbound
539 | proxy that was expecting to receive credentials. A proxy &MAY; relay
540 | the credentials from the client request to the next proxy if that is
541 | the mechanism by which the proxies cooperatively authenticate a given
542 | request.
543 |
544 |
545 |
546 |
547 |
548 |
549 |
550 | The "WWW-Authenticate" header field consists of at least one
551 | challenge that indicates the authentication scheme(s) and parameters
552 | applicable to the effective request URI (&effective-request-uri;).
553 |
554 |
555 | It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
556 | included in other response messages to indicate that supplying credentials
557 | (or different credentials) might affect the response.
558 |
559 |
560 | WWW-Authenticate = 1#challenge
561 |
562 |
563 | User agents are advised to take special care in parsing the WWW-Authenticate
564 | field value as it might contain more than one challenge,
565 | or if more than one WWW-Authenticate header field is provided, the
566 | contents of a challenge itself can contain a comma-separated list of
567 | authentication parameters.
568 |
569 |
570 | For instance:
571 |
572 | WWW-Authenticate: Newauth realm="apps", type=1,
573 | title="Login to \"apps\"", Basic realm="simple"
574 |
575 |
576 | This header field contains two challenges; one for the "Newauth" scheme
577 | with a realm value of "apps", and two additional parameters "type" and
578 | "title", and another one for the "Basic" scheme with a realm value of
579 | "simple".
580 |
581 |
582 |
583 | &Note; The challenge grammar production uses the list syntax as
584 | well. Therefore, a sequence of comma, whitespace, and comma can be
585 | considered both as applying to the preceding challenge, or to be an
586 | empty entry in the list of challenges. In practice, this ambiguity
587 | does not affect the semantics of the header field value and thus is
588 | harmless.
589 |
590 |
591 |
592 |
593 |
594 |
595 |
596 |
597 |
598 |
599 | The registration procedure for HTTP Authentication Schemes is defined by
600 | of this document.
601 |
602 |
603 | The HTTP Method Authentication Scheme shall be created at .
604 |
605 |
606 |
607 |
608 |
609 | The HTTP Status Code Registry located at
610 | shall be updated with the registrations below:
611 |
612 |
613 |
614 |
615 | Value
616 | Description
617 | Reference
618 | 401
619 | Unauthorized
620 |
621 |
622 |
623 | 407
624 | Proxy Authentication Required
625 |
626 |
627 |
628 |
629 |
630 |
631 |
632 |
633 |
634 |
635 | The Message Header Field Registry located at shall be updated
636 | with the permanent registrations below (see ):
637 |
638 |
639 |
640 |
641 | Header Field Name
642 | Protocol
643 | Status
644 | Reference
645 |
646 | Authorization
647 | http
648 | standard
649 |
650 |
651 |
652 | Proxy-Authenticate
653 | http
654 | standard
655 |
656 |
657 |
658 | Proxy-Authorization
659 | http
660 | standard
661 |
662 |
663 |
664 | WWW-Authenticate
665 | http
666 | standard
667 |
668 |
669 |
670 |
671 |
672 |
673 |
674 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
675 |
676 |
677 |
678 |
679 |
680 |
681 | This section is meant to inform developers, information providers, and
682 | users of known security concerns specific to HTTP/1.1 authentication.
683 | More general security considerations are addressed in HTTP messaging
684 | &messaging; and semantics &semantics;.
685 |
686 |
687 |
688 |
689 | Existing HTTP clients and user agents typically retain authentication
690 | information indefinitely. HTTP/1.1 does not provide a method for a
691 | server to direct clients to discard these cached credentials. This is
692 | a significant defect that requires further extensions to HTTP.
693 | Circumstances under which credential caching can interfere with the
694 | application's security model include but are not limited to:
695 |
696 | Clients that have been idle for an extended period, following
697 | which the server might wish to cause the client to re-prompt the
698 | user for credentials.
699 |
700 | Applications that include a session termination indication
701 | (such as a "logout" or "commit" button on a page) after which
702 | the server side of the application "knows" that there is no
703 | further reason for the client to retain the credentials.
704 |
705 |
706 |
707 | This is currently under separate study. There are a number of work-arounds
708 | to parts of this problem, and we encourage the use of
709 | password protection in screen savers, idle time-outs, and other
710 | methods that mitigate the security problems inherent in this
711 | problem. In particular, user agents that cache credentials are
712 | encouraged to provide a readily accessible mechanism for discarding
713 | cached credentials under user control.
714 |
715 |
716 |
717 |
718 |
719 | Authentication schemes that solely rely on the "realm" mechanism for
720 | establishing a protection space will expose credentials to all resources on a
721 | server. Clients that have successfully made authenticated requests with a
722 | resource can use the same authentication credentials for other resources on
723 | the same server. This makes it possible for a different resource to harvest
724 | authentication credentials for other resources.
725 |
726 |
727 | This is of particular concern when a server hosts resources for multiple
728 | parties under the same canonical root URI ().
729 | Possible mitigation strategies include restricting direct access to
730 | authentication credentials (i.e., not making the content of the
731 | Authorization request header field available), and separating protection
732 | spaces by using a different host name for each party.
733 |
734 |
735 |
736 |
737 |
738 |
739 | This specification takes over the definition of the HTTP Authentication
740 | Framework, previously defined in RFC 2617.
741 | We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
742 | Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
743 | on that specification. See
744 | for further acknowledgements.
745 |
746 |
747 | See &acks; for the Acknowledgments related to this document revision.
748 |
749 |
750 |
751 |
752 |
753 |
754 |
755 |
756 |
757 |
758 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
759 |
760 | Adobe Systems Incorporated
761 | fielding@gbiv.com
762 |
763 |
764 | greenbytes GmbH
765 | julian.reschke@greenbytes.de
766 |
767 |
768 |
769 |
770 |
771 |
772 |
773 |
774 |
775 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
776 |
777 | Adobe Systems Incorporated
778 | fielding@gbiv.com
779 |
780 |
781 | greenbytes GmbH
782 | julian.reschke@greenbytes.de
783 |
784 |
785 |
786 |
787 |
788 | 403 (Forbidden)
789 | Location
790 |
791 |
792 |
793 |
794 |
795 | Hypertext Transfer Protocol (HTTP/1.1): Caching
796 |
797 | Adobe Systems Incorporated
798 | fielding@gbiv.com
799 |
800 |
801 | Akamai
802 | mnot@mnot.net
803 |
804 |
805 | greenbytes GmbH
806 | julian.reschke@greenbytes.de
807 |
808 |
809 |
810 |
811 |
812 |
813 |
814 |
815 |
816 | Key words for use in RFCs to Indicate Requirement Levels
817 |
818 | Harvard University
819 | sob@harvard.edu
820 |
821 |
822 |
823 |
824 |
825 |
826 |
827 |
828 |
829 | Augmented BNF for Syntax Specifications: ABNF
830 |
831 | Brandenburg InternetWorking
832 |
833 | dcrocker@bbiw.net
834 |
835 |
836 |
837 | THUS plc.
838 |
839 | paul.overell@thus.net
840 |
841 |
842 |
843 |
844 |
845 |
846 |
847 |
848 |
849 |
850 |
851 |
852 |
853 |
854 | Hypertext Transfer Protocol -- HTTP/1.1
855 |
856 | University of California, Irvine
857 | fielding@ics.uci.edu
858 |
859 |
860 | W3C
861 | jg@w3.org
862 |
863 |
864 | Compaq Computer Corporation
865 | mogul@wrl.dec.com
866 |
867 |
868 | MIT Laboratory for Computer Science
869 | frystyk@w3.org
870 |
871 |
872 | Xerox Corporation
873 | masinter@parc.xerox.com
874 |
875 |
876 | Microsoft Corporation
877 | paulle@microsoft.com
878 |
879 |
880 | W3C
881 | timbl@w3.org
882 |
883 |
884 |
885 |
886 |
887 |
888 |
889 |
890 | HTTP Authentication: Basic and Digest Access Authentication
891 |
892 | Northwestern University, Department of Mathematics
893 | john@math.nwu.edu
894 |
895 |
896 | Verisign Inc.
897 | pbaker@verisign.com
898 |
899 |
900 | AbiSource, Inc.
901 | jeff@AbiSource.com
902 |
903 |
904 | Agranat Systems, Inc.
905 | lawrence@agranat.com
906 |
907 |
908 | Microsoft Corporation
909 | paulle@microsoft.com
910 |
911 |
912 | Netscape Communications Corporation
913 |
914 |
915 | Open Market, Inc.
916 | stewart@OpenMarket.com
917 |
918 |
919 |
920 |
921 |
922 |
923 |
924 |
925 | Registration Procedures for Message Header Fields
926 |
927 | Nine by Nine
928 | GK-IETF@ninebynine.org
929 |
930 |
931 | BEA Systems
932 | mnot@pobox.com
933 |
934 |
935 | HP Labs
936 | JeffMogul@acm.org
937 |
938 |
939 |
940 |
941 |
942 |
943 |
944 |
945 |
946 | Uniform Resource Identifier (URI): Generic Syntax
947 |
948 | World Wide Web Consortium
949 |
950 | timbl@w3.org
951 | http://www.w3.org/People/Berners-Lee/
952 |
953 |
954 |
955 | Day Software
956 |
957 | fielding@gbiv.com
958 | http://roy.gbiv.com/
959 |
960 |
961 |
962 | Adobe Systems Incorporated
963 |
964 | LMM@acm.org
965 | http://larry.masinter.net/
966 |
967 |
968 |
969 |
970 |
971 |
972 |
973 |
974 |
975 |
976 | The Base16, Base32, and Base64 Data Encodings
977 |
978 |
979 |
980 |
981 |
982 |
983 |
984 |
985 | Guidelines for Writing an IANA Considerations Section in RFCs
986 |
987 | IBM
988 | narten@us.ibm.com
989 |
990 |
991 | Google
992 | Harald@Alvestrand.no
993 |
994 |
995 |
996 |
997 |
998 |
999 |
1000 |
1001 |
1002 |
1003 |
1004 | The framework for HTTP Authentication is now defined by this document,
1005 | rather than RFC 2617.
1006 |
1007 |
1008 | The "realm" parameter is no longer always required on challenges;
1009 | consequently, the ABNF allows challenges without any auth parameters.
1010 | ()
1011 |
1012 |
1013 | The "token68" alternative to auth-param lists has been added for consistency
1014 | with legacy authentication schemes such as "Basic".
1015 | ()
1016 |
1017 |
1018 | This specification introduces the Authentication Scheme Registry, along with
1019 | considerations for new authentication schemes.
1020 | ()
1021 |
1022 |
1023 |
1024 |
1025 |
1026 |
1027 |
1028 |
1029 |
1030 |
1031 |
1032 |
1033 |
1034 |
1035 |
1036 |
1037 | The following core rules are included by
1038 | reference, as defined in :
1039 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1040 | DIGIT (decimal 0-9), DQUOTE (double quote),
1041 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1042 | OCTET (any 8-bit sequence of data), SP (space), and
1043 | VCHAR (any visible US-ASCII character).
1044 |
1045 |
1046 | The rules below are defined in :
1047 |
1048 |
1049 | BWS = <BWS, defined in &whitespace;>
1050 | OWS = <OWS, defined in &whitespace;>
1051 | quoted-string = <quoted-string, defined in &field-components;>
1052 | token = <token, defined in &field-components;>
1053 |
1054 |
1055 |
1056 |
1057 |
1058 |
1059 |
1060 | Authorization = credentials
1061 |
1062 | BWS = <BWS, defined in [Part1], Section 3.2.3>
1063 |
1064 | OWS = <OWS, defined in [Part1], Section 3.2.3>
1065 |
1066 | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
1067 | challenge ] )
1068 | Proxy-Authorization = credentials
1069 |
1070 | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1071 | ] )
1072 |
1073 | auth-param = token BWS "=" BWS ( token / quoted-string )
1074 | auth-scheme = token
1075 |
1076 | challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
1077 | OWS "," [ OWS auth-param ] ) ] ) ]
1078 | credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
1079 | *( OWS "," [ OWS auth-param ] ) ] ) ]
1080 |
1081 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
1082 |
1083 | token = <token, defined in [Part1], Section 3.2.6>
1084 | token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1085 | *"="
1086 |
1087 |
1088 |
1089 |
1090 |
1091 |
1092 |
1093 | Changes up to the first Working Group Last Call draft are summarized
1094 | in .
1095 |
1096 |
1097 |
1098 |
1099 | Closed issues:
1100 |
1101 |
1102 | :
1103 | "Realms and scope"
1104 |
1105 |
1106 | :
1107 | "Strength"
1108 |
1109 |
1110 | :
1111 | "Authentication exchanges"
1112 |
1113 |
1114 | :
1115 | "ABNF requirements for recipients"
1116 |
1117 |
1118 | :
1119 | "note introduction of new IANA registries as normative changes"
1120 |
1121 |
1122 |
1123 |
1124 |
1125 |
1126 |
1127 | Closed issues:
1128 |
1129 |
1130 | :
1131 | "rename b64token for clarity"
1132 |
1133 |
1134 |
1135 |
1136 | Other changes:
1137 |
1138 |
1139 | Conformance criteria and considerations regarding error handling are
1140 | now defined in Part 1.
1141 |
1142 |
1143 |
1144 |
1145 |
1146 |
1147 |
1148 | Closed issues:
1149 |
1150 |
1151 | :
1152 | "Authentication and caching - max-age"
1153 |
1154 |
1155 |
1156 |
1157 |
1158 |
1163 |
1164 |
1165 |
1166 |
1167 |
--------------------------------------------------------------------------------
/refs/draft-ietf-httpbis-p7-auth-23.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 | MAY">
5 | MUST">
6 | MUST NOT">
7 | OPTIONAL">
8 | RECOMMENDED">
9 | REQUIRED">
10 | SHALL">
11 | SHALL NOT">
12 | SHOULD">
13 | SHOULD NOT">
14 |
15 |
16 |
17 |
18 | Note:">
19 | ">
20 | ">
21 | ">
22 | ">
23 | ">
24 | ">
25 | ">
26 | ">
27 | ">
28 | ">
29 | ">
30 | ">
31 | ">
32 | ">
33 | ">
34 | ">
35 | ]>
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
51 |
52 |
53 |
54 |
55 | Hypertext Transfer Protocol (HTTP/1.1): Authentication
56 |
57 |
58 | Adobe Systems Incorporated
59 |
60 |
61 | 345 Park Ave
62 | San Jose
63 | CA
64 | 95110
65 | USA
66 |
67 | fielding@gbiv.com
68 | http://roy.gbiv.com/
69 |
70 |
71 |
72 |
73 | greenbytes GmbH
74 |
75 |
76 | Hafenweg 16
77 | MuensterNW48155
78 | Germany
79 |
80 | julian.reschke@greenbytes.de
81 | http://greenbytes.de/tech/webdav/
82 |
83 |
84 |
85 |
86 | HTTPbis Working Group
87 |
88 |
89 |
90 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
91 | distributed, collaborative, hypermedia information systems. This document
92 | defines the HTTP Authentication framework.
93 |
94 |
95 |
96 |
97 |
98 | Discussion of this draft takes place on the HTTPBIS working group
99 | mailing list (ietf-http-wg@w3.org), which is archived at
100 | .
101 |
102 |
103 | The current issues list is at
104 | and related
105 | documents (including fancy diffs) can be found at
106 | .
107 |
108 |
109 | The changes in this draft are summarized in .
110 |
111 |
112 |
113 |
114 |
115 |
116 | This document defines HTTP/1.1 access control and authentication. It
117 | includes the relevant parts of RFC 2616
118 | with only minor changes (), plus the general framework for HTTP authentication,
119 | as previously defined in "HTTP Authentication: Basic and Digest Access
120 | Authentication" ().
121 |
122 |
123 | HTTP provides several &OPTIONAL; challenge-response authentication
124 | schemes that can be used by a server to challenge a client request and
125 | by a client to provide authentication information. The "basic" and "digest"
126 | authentication schemes continue to be specified in
127 | RFC 2617.
128 |
129 |
130 |
131 |
132 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 | document are to be interpreted as described in .
135 |
136 |
137 | Conformance criteria and considerations regarding error handling
138 | are defined in &conformance;.
139 |
140 |
141 |
142 |
143 |
144 | This specification uses the Augmented Backus-Naur Form (ABNF) notation
145 | of with the list rule extension defined in
146 | ¬ation;. describes rules imported from
147 | other documents. shows the collected ABNF
148 | with the list rule expanded.
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 | HTTP provides a simple challenge-response authentication framework
163 | that can be used by a server to challenge a client request and by a
164 | client to provide authentication information. It uses a case-insensitive
165 | token as a means to identify the authentication scheme, followed
166 | by additional information necessary for achieving authentication via that
167 | scheme. The latter can either be a comma-separated list of parameters or a
168 | single sequence of characters capable of holding base64-encoded
169 | information.
170 |
171 |
172 | Parameters are name-value pairs where the name is matched case-insensitively,
173 | and each parameter name &MUST; only occur once per challenge.
174 |
175 |
176 | auth-scheme = token
177 |
178 | auth-param = tokenBWS "=" BWS ( token / quoted-string )
179 |
180 | token68 = 1*( ALPHA / DIGIT /
181 | "-" / "." / "_" / "~" / "+" / "/" ) *"="
182 |
183 |
184 | The "token68" syntax allows the 66 unreserved URI characters (),
185 | plus a few others, so that it can hold a base64, base64url (URL and filename
186 | safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
187 | excluding whitespace ().
188 |
189 |
190 | The 401 (Unauthorized) response message is used by an origin server
191 | to challenge the authorization of a user agent. This response &MUST;
192 | include a WWW-Authenticate header field containing at least one
193 | challenge applicable to the requested resource.
194 |
195 |
196 | The 407 (Proxy Authentication Required) response message is
197 | used by a proxy to challenge the authorization of a client and &MUST;
198 | include a Proxy-Authenticate header field containing at least
199 | one challenge applicable to the proxy for the requested resource.
200 |
201 |
202 | challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
203 |
204 |
205 |
206 | &Note; User agents will need to take special care in parsing the
207 | WWW-Authenticate and Proxy-Authenticate
208 | header field values because they can contain more than one challenge, or
209 | if more than one of each is provided, since the contents of a challenge
210 | can itself contain a comma-separated list of authentication parameters.
211 |
212 |
213 |
214 |
215 | &Note; Many clients fail to parse challenges containing unknown
216 | schemes. A workaround for this problem is to list well-supported schemes
217 | (such as "basic") first.
218 |
219 |
220 |
221 | A user agent that wishes to authenticate itself with an origin server
222 | — usually, but not necessarily, after receiving a 401 (Unauthorized)
223 | — can do so by including an Authorization header field with the
224 | request.
225 |
226 |
227 | A client that wishes to authenticate itself with a proxy — usually,
228 | but not necessarily, after receiving a 407 (Proxy Authentication Required)
229 | — can do so by including a Proxy-Authorization header field with the
230 | request.
231 |
232 |
233 | Both the Authorization field value and the Proxy-Authorization field value
234 | contain the client's credentials for the realm of the resource being
235 | requested, based upon a challenge received in a response (possibly at
236 | some point in the past). When creating their values, the user agent ought to
237 | do so by selecting the challenge with what it considers to be the most
238 | secure auth-scheme that it understands, obtaining credentials from the user
239 | as appropriate.
240 |
241 |
242 | credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
243 |
244 |
245 | Upon a request for a protected resource that omits credentials, contains
246 | invalid credentials (e.g., a bad password) or partial credentials (e.g.,
247 | when the authentication scheme requires more than one round trip), an origin
248 | server &SHOULD; send a 401 (Unauthorized) response that
249 | contains a WWW-Authenticate header field with at least one
250 | (possibly new) challenge applicable to the requested resource.
251 |
252 |
253 | Likewise, upon a request that requires authentication by proxies that omit
254 | credentials or contain invalid or partial credentials, a proxy &SHOULD;
255 | send a 407 (Proxy Authentication Required) response that
256 | contains a Proxy-Authenticate header field with a (possibly
257 | new) challenge applicable to the proxy.
258 |
259 |
260 | A server receiving credentials that are valid, but not adequate to gain
261 | access, ought to respond with the 403 (Forbidden) status code (&status.403;).
262 |
263 |
264 | The HTTP protocol does not restrict applications to this simple
265 | challenge-response framework for access authentication. Additional
266 | mechanisms &MAY; be used, such as encryption at the transport level or
267 | via message encapsulation, and with additional header fields
268 | specifying authentication information. However, such additional
269 | mechanisms are not defined by this specification.
270 |
271 |
272 | Proxies &MUST; forward the WWW-Authenticate and
273 | Authorization header fields unmodified and follow the rules
274 | found in .
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 | The authentication parameter realm is reserved for use by authentication
284 | schemes that wish to indicate the scope of protection.
285 |
286 |
287 | A protection space is defined by the canonical root URI (the
288 | scheme and authority components of the effective request URI; see
289 | ) of the
290 | server being accessed, in combination with the realm value if present.
291 | These realms allow the protected resources on a server to be
292 | partitioned into a set of protection spaces, each with its own
293 | authentication scheme and/or authorization database. The realm value
294 | is a string, generally assigned by the origin server, that can have
295 | additional semantics specific to the authentication scheme. Note that a
296 | response can have multiple challenges with the same auth-scheme but
297 | different realms.
298 |
299 |
300 | The protection space determines the domain over which credentials can
301 | be automatically applied. If a prior request has been authorized, the
302 | same credentials &MAY; be reused for all other requests within that
303 | protection space for a period of time determined by the
304 | authentication scheme, parameters, and/or user preference. Unless
305 | specifically allowed by the authentication scheme, a single protection
306 | space cannot extend outside the scope of its server.
307 |
308 |
309 | For historical reasons, senders &MUST; only generate the quoted-string syntax.
310 | Recipients might have to support both token and quoted-string syntax for
311 | maximum interoperability with existing clients that have been accepting both
312 | notations for a long time.
313 |
314 |
315 |
316 |
317 |
318 |
319 |
320 |
321 |
322 |
323 | The 401 (Unauthorized) status code indicates that the
324 | request has not been applied because it lacks valid authentication
325 | credentials for the target resource. The origin server &MUST; send a
326 | WWW-Authenticate header field ()
327 | containing at least one challenge applicable to the target resource.
328 | If the request included authentication credentials, then the 401 response
329 | indicates that authorization has been refused for those credentials.
330 | The user agent &MAY; repeat the request with a new or replaced
331 | Authorization header field ().
332 | If the 401 response contains the same challenge as the prior response, and
333 | the user agent has already attempted authentication at least once, then the
334 | user agent &SHOULD; present the enclosed representation to the user, since
335 | it usually contains relevant diagnostic information.
336 |
337 |
338 |
339 |
340 |
341 |
342 | The 407 (Proxy Authentication Required) status code is
343 | similar to 401 (Unauthorized), but indicates that the client
344 | needs to authenticate itself in order to use a proxy.
345 | The proxy &MUST; send a Proxy-Authenticate header field
346 | () containing a challenge
347 | applicable to that proxy for the target resource. The client &MAY; repeat
348 | the request with a new or replaced Proxy-Authorization
349 | header field ().
350 |
351 |
352 |
353 |
354 |
355 |
356 | This section defines the syntax and semantics of HTTP/1.1 header fields
357 | related to authentication.
358 |
359 |
360 |
361 |
362 |
363 |
364 | The "Authorization" header field allows a user agent to authenticate
365 | itself with an origin server — usually, but not necessarily, after receiving a 401
366 | (Unauthorized) response. Its value consists of credentials containing
367 | information of the user agent for the realm of the resource being
368 | requested.
369 |
370 |
371 | Authorization = credentials
372 |
373 |
374 | If a request is
375 | authenticated and a realm specified, the same credentials &SHOULD;
376 | be valid for all other requests within this realm (assuming that
377 | the authentication scheme itself does not require otherwise, such
378 | as credentials that vary according to a challenge value or using
379 | synchronized clocks).
380 |
381 |
382 | See &caching-authenticated-responses; for details of and requirements
383 | pertaining to handling of the Authorization field by HTTP caches.
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 | The "Proxy-Authenticate" header field consists of at least one
392 | challenge that indicates the authentication scheme(s) and parameters
393 | applicable to the proxy for this effective request URI (&effective-request-uri;).
394 | It &MUST; be included as part of a 407 (Proxy Authentication Required) response.
395 |
396 |
397 | Proxy-Authenticate = 1#challenge
398 |
399 |
400 | Unlike WWW-Authenticate, the Proxy-Authenticate header field
401 | applies only to the current connection, and intermediaries &SHOULD-NOT;
402 | forward it to downstream clients. However, an intermediate proxy might need
403 | to obtain its own credentials by requesting them from the downstream client,
404 | which in some circumstances will appear as if the proxy is forwarding the
405 | Proxy-Authenticate header field.
406 |
407 |
408 | Note that the parsing considerations for WWW-Authenticate
409 | apply to this header field as well; see
410 | for details.
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 | The "Proxy-Authorization" header field allows the client to
419 | identify itself (or its user) to a proxy that requires
420 | authentication. Its value consists of credentials containing the
421 | authentication information of the client for the proxy and/or realm of the
422 | resource being requested.
423 |
424 |
425 | Proxy-Authorization = credentials
426 |
427 |
428 | Unlike Authorization, the Proxy-Authorization header field applies only to
429 | the next outbound proxy that demanded authentication using the Proxy-Authenticate
430 | field. When multiple proxies are used in a chain, the
431 | Proxy-Authorization header field is consumed by the first outbound
432 | proxy that was expecting to receive credentials. A proxy &MAY; relay
433 | the credentials from the client request to the next proxy if that is
434 | the mechanism by which the proxies cooperatively authenticate a given
435 | request.
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 | The "WWW-Authenticate" header field consists of at least one
444 | challenge that indicates the authentication scheme(s) and parameters
445 | applicable to the effective request URI (&effective-request-uri;).
446 |
447 |
448 | It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
449 | included in other response messages to indicate that supplying credentials
450 | (or different credentials) might affect the response.
451 |
452 |
453 | WWW-Authenticate = 1#challenge
454 |
455 |
456 | User agents are advised to take special care in parsing the WWW-Authenticate
457 | field value as it might contain more than one challenge,
458 | or if more than one WWW-Authenticate header field is provided, the
459 | contents of a challenge itself can contain a comma-separated list of
460 | authentication parameters.
461 |
462 |
463 | For instance:
464 |
465 | WWW-Authenticate: Newauth realm="apps", type=1,
466 | title="Login to \"apps\"", Basic realm="simple"
467 |
468 |
469 | This header field contains two challenges; one for the "Newauth" scheme
470 | with a realm value of "apps", and two additional parameters "type" and
471 | "title", and another one for the "Basic" scheme with a realm value of
472 | "simple".
473 |
474 |
475 |
476 | &Note; The challenge grammar production uses the list syntax as
477 | well. Therefore, a sequence of comma, whitespace, and comma can be
478 | considered both as applying to the preceding challenge, or to be an
479 | empty entry in the list of challenges. In practice, this ambiguity
480 | does not affect the semantics of the header field value and thus is
481 | harmless.
482 |
483 |
484 |
485 |
486 |
487 |
488 |
489 |
490 |
491 |
492 | The HTTP Authentication Scheme Registry defines the name space for the
493 | authentication schemes in challenges and credentials. It will be created and
494 | maintained at .
495 |
496 |
497 |
498 |
499 | Registrations &MUST; include the following fields:
500 |
501 | Authentication Scheme Name
502 | Pointer to specification text
503 | Notes (optional)
504 |
505 |
506 |
507 | Values to be added to this name space require IETF Review
508 | (see ).
509 |
510 |
511 |
512 |
513 |
514 | There are certain aspects of the HTTP Authentication Framework that put
515 | constraints on how new authentication schemes can work:
516 |
517 |
518 |
519 |
520 |
521 | HTTP authentication is presumed to be stateless: all of the information
522 | necessary to authenticate a request &MUST; be provided in the request,
523 | rather than be dependent on the server remembering prior requests.
524 | Authentication based on, or bound to, the underlying connection is
525 | outside the scope of this specification and inherently flawed unless
526 | steps are taken to ensure that the connection cannot be used by any
527 | party other than the authenticated user
528 | (see &msg-orient-and-buffering;).
529 |
530 |
531 |
532 |
533 | The authentication parameter "realm" is reserved for defining Protection
534 | Spaces as defined in . New schemes
535 | &MUST-NOT; use it in a way incompatible with that definition.
536 |
537 |
538 |
539 |
540 | The "token68" notation was introduced for compatibility with existing
541 | authentication schemes and can only be used once per challenge or credential.
542 | New schemes thus ought to use the "auth-param" syntax instead, because
543 | otherwise future extensions will be impossible.
544 |
545 |
546 |
547 |
548 | The parsing of challenges and credentials is defined by this specification,
549 | and cannot be modified by new authentication schemes. When the auth-param
550 | syntax is used, all parameters ought to support both token and
551 | quoted-string syntax, and syntactical constraints ought to be defined on
552 | the field value after parsing (i.e., quoted-string processing). This is
553 | necessary so that recipients can use a generic parser that applies to
554 | all authentication schemes.
555 |
556 |
557 | &Note; The fact that the value syntax for the "realm" parameter
558 | is restricted to quoted-string was a bad design choice not to be repeated
559 | for new parameters.
560 |
561 |
562 |
563 |
564 | Definitions of new schemes ought to define the treatment of unknown
565 | extension parameters. In general, a "must-ignore" rule is preferable
566 | over "must-understand", because otherwise it will be hard to introduce
567 | new parameters in the presence of legacy recipients. Furthermore,
568 | it's good to describe the policy for defining new parameters (such
569 | as "update the specification", or "use this registry").
570 |
571 |
572 |
573 |
574 | Authentication schemes need to document whether they are usable in
575 | origin-server authentication (i.e., using WWW-Authenticate),
576 | and/or proxy authentication (i.e., using Proxy-Authenticate).
577 |
578 |
579 |
580 |
581 | The credentials carried in an Authorization header field are specific to
582 | the User Agent, and therefore have the same effect on HTTP caches as the
583 | "private" Cache-Control response directive (&caching-rsd-private;),
584 | within the scope of the request they appear in.
585 |
586 |
587 | Therefore, new authentication schemes that choose not to carry
588 | credentials in the Authorization header field (e.g., using a newly defined
589 | header field) will need to explicitly disallow caching, by mandating the use of
590 | either Cache-Control request directives (e.g., "no-store",
591 | &caching-rqd-no-store;) or response directives (e.g., "private").
592 |
593 |
594 |
595 |
596 |
597 |
598 |
599 |
600 |
601 | The HTTP Status Code Registry located at
602 | shall be updated with the registrations below:
603 |
604 |
605 |
606 |
607 | Value
608 | Description
609 | Reference
610 | 401
611 | Unauthorized
612 |
613 |
614 |
615 | 407
616 | Proxy Authentication Required
617 |
618 |
619 |
620 |
621 |
622 |
623 |
624 |
625 |
626 |
627 | HTTP header fields are registered within the Message Header Field Registry
628 | maintained at
629 | .
630 |
631 |
632 | This document defines the following HTTP header fields, so their
633 | associated registry entries shall be updated according to the permanent
634 | registrations below (see ):
635 |
636 |
637 |
638 |
639 | Header Field Name
640 | Protocol
641 | Status
642 | Reference
643 |
644 | Authorization
645 | http
646 | standard
647 |
648 |
649 |
650 | Proxy-Authenticate
651 | http
652 | standard
653 |
654 |
655 |
656 | Proxy-Authorization
657 | http
658 | standard
659 |
660 |
661 |
662 | WWW-Authenticate
663 | http
664 | standard
665 |
666 |
667 |
668 |
669 |
670 |
671 |
672 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
673 |
674 |
675 |
676 |
677 |
678 |
679 | This section is meant to inform developers, information providers, and
680 | users of known security concerns specific to HTTP/1.1 authentication.
681 | More general security considerations are addressed in HTTP messaging
682 | &messaging; and semantics &semantics;.
683 |
684 |
685 |
686 |
687 | Existing HTTP clients and user agents typically retain authentication
688 | information indefinitely. HTTP/1.1 does not provide a method for a
689 | server to direct clients to discard these cached credentials. This is
690 | a significant defect that requires further extensions to HTTP.
691 | Circumstances under which credential caching can interfere with the
692 | application's security model include but are not limited to:
693 |
694 | Clients that have been idle for an extended period, following
695 | which the server might wish to cause the client to re-prompt the
696 | user for credentials.
697 |
698 | Applications that include a session termination indication
699 | (such as a "logout" or "commit" button on a page) after which
700 | the server side of the application "knows" that there is no
701 | further reason for the client to retain the credentials.
702 |
703 |
704 |
705 | This is currently under separate study. There are a number of work-arounds
706 | to parts of this problem, and we encourage the use of
707 | password protection in screen savers, idle time-outs, and other
708 | methods that mitigate the security problems inherent in this
709 | problem. In particular, user agents that cache credentials are
710 | encouraged to provide a readily accessible mechanism for discarding
711 | cached credentials under user control.
712 |
713 |
714 |
715 |
716 |
717 | Authentication schemes that solely rely on the "realm" mechanism for
718 | establishing a protection space will expose credentials to all resources on
719 | an origin server. Clients that have successfully made authenticated requests
720 | with a resource can use the same authentication credentials for other
721 | resources on the same origin server. This makes it possible for a different
722 | resource to harvest authentication credentials for other resources.
723 |
724 |
725 | This is of particular concern when an origin server hosts resources for multiple
726 | parties under the same canonical root URI ().
727 | Possible mitigation strategies include restricting direct access to
728 | authentication credentials (i.e., not making the content of the
729 | Authorization request header field available), and separating protection
730 | spaces by using a different host name (or port number) for each party.
731 |
732 |
733 |
734 |
735 |
736 |
737 | This specification takes over the definition of the HTTP Authentication
738 | Framework, previously defined in RFC 2617.
739 | We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
740 | Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
741 | on that specification. See
742 | for further acknowledgements.
743 |
744 |
745 | See &acks; for the Acknowledgments related to this document revision.
746 |
747 |
748 |
749 |
750 |
751 |
752 |
753 |
754 |
755 |
756 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
757 |
758 | Adobe Systems Incorporated
759 | fielding@gbiv.com
760 |
761 |
762 | greenbytes GmbH
763 | julian.reschke@greenbytes.de
764 |
765 |
766 |
767 |
768 |
769 |
770 |
771 |
772 |
773 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
774 |
775 | Adobe Systems Incorporated
776 | fielding@gbiv.com
777 |
778 |
779 | greenbytes GmbH
780 | julian.reschke@greenbytes.de
781 |
782 |
783 |
784 |
785 |
786 | 403 (Forbidden)
787 | Location
788 |
789 |
790 |
791 |
792 |
793 | Hypertext Transfer Protocol (HTTP/1.1): Caching
794 |
795 | Adobe Systems Incorporated
796 | fielding@gbiv.com
797 |
798 |
799 | Akamai
800 | mnot@mnot.net
801 |
802 |
803 | greenbytes GmbH
804 | julian.reschke@greenbytes.de
805 |
806 |
807 |
808 |
809 |
810 |
811 |
812 |
813 |
814 | Key words for use in RFCs to Indicate Requirement Levels
815 |
816 | Harvard University
817 | sob@harvard.edu
818 |
819 |
820 |
821 |
822 |
823 |
824 |
825 |
826 |
827 | Augmented BNF for Syntax Specifications: ABNF
828 |
829 | Brandenburg InternetWorking
830 |
831 | dcrocker@bbiw.net
832 |
833 |
834 |
835 | THUS plc.
836 |
837 | paul.overell@thus.net
838 |
839 |
840 |
841 |
842 |
843 |
844 |
845 |
846 |
847 |
848 |
849 |
850 |
851 |
852 | Hypertext Transfer Protocol -- HTTP/1.1
853 |
854 | University of California, Irvine
855 | fielding@ics.uci.edu
856 |
857 |
858 | W3C
859 | jg@w3.org
860 |
861 |
862 | Compaq Computer Corporation
863 | mogul@wrl.dec.com
864 |
865 |
866 | MIT Laboratory for Computer Science
867 | frystyk@w3.org
868 |
869 |
870 | Xerox Corporation
871 | masinter@parc.xerox.com
872 |
873 |
874 | Microsoft Corporation
875 | paulle@microsoft.com
876 |
877 |
878 | W3C
879 | timbl@w3.org
880 |
881 |
882 |
883 |
884 |
885 |
886 |
887 |
888 | HTTP Authentication: Basic and Digest Access Authentication
889 |
890 | Northwestern University, Department of Mathematics
891 | john@math.nwu.edu
892 |
893 |
894 | Verisign Inc.
895 | pbaker@verisign.com
896 |
897 |
898 | AbiSource, Inc.
899 | jeff@AbiSource.com
900 |
901 |
902 | Agranat Systems, Inc.
903 | lawrence@agranat.com
904 |
905 |
906 | Microsoft Corporation
907 | paulle@microsoft.com
908 |
909 |
910 | Netscape Communications Corporation
911 |
912 |
913 | Open Market, Inc.
914 | stewart@OpenMarket.com
915 |
916 |
917 |
918 |
919 |
920 |
921 |
922 |
923 | Registration Procedures for Message Header Fields
924 |
925 | Nine by Nine
926 | GK-IETF@ninebynine.org
927 |
928 |
929 | BEA Systems
930 | mnot@pobox.com
931 |
932 |
933 | HP Labs
934 | JeffMogul@acm.org
935 |
936 |
937 |
938 |
939 |
940 |
941 |
942 |
943 |
944 | Uniform Resource Identifier (URI): Generic Syntax
945 |
946 | World Wide Web Consortium
947 |
948 | timbl@w3.org
949 | http://www.w3.org/People/Berners-Lee/
950 |
951 |
952 |
953 | Day Software
954 |
955 | fielding@gbiv.com
956 | http://roy.gbiv.com/
957 |
958 |
959 |
960 | Adobe Systems Incorporated
961 |
962 | LMM@acm.org
963 | http://larry.masinter.net/
964 |
965 |
966 |
967 |
968 |
969 |
970 |
971 |
972 |
973 |
974 | The Base16, Base32, and Base64 Data Encodings
975 |
976 |
977 |
978 |
979 |
980 |
981 |
982 |
983 | Guidelines for Writing an IANA Considerations Section in RFCs
984 |
985 | IBM
986 | narten@us.ibm.com
987 |
988 |
989 | Google
990 | Harald@Alvestrand.no
991 |
992 |
993 |
994 |
995 |
996 |
997 |
998 |
999 |
1000 |
1001 |
1002 | The framework for HTTP Authentication is now defined by this document,
1003 | rather than RFC 2617.
1004 |
1005 |
1006 | The "realm" parameter is no longer always required on challenges;
1007 | consequently, the ABNF allows challenges without any auth parameters.
1008 | ()
1009 |
1010 |
1011 | The "token68" alternative to auth-param lists has been added for consistency
1012 | with legacy authentication schemes such as "Basic".
1013 | ()
1014 |
1015 |
1016 | This specification introduces the Authentication Scheme Registry, along with
1017 | considerations for new authentication schemes.
1018 | ()
1019 |
1020 |
1021 |
1022 |
1023 |
1024 |
1025 |
1026 |
1027 |
1028 |
1029 |
1030 |
1031 |
1032 |
1033 |
1034 |
1035 | The following core rules are included by
1036 | reference, as defined in :
1037 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1038 | DIGIT (decimal 0-9), DQUOTE (double quote),
1039 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1040 | OCTET (any 8-bit sequence of data), SP (space), and
1041 | VCHAR (any visible US-ASCII character).
1042 |
1043 |
1044 | The rules below are defined in :
1045 |
1046 |
1047 | BWS = <BWS, defined in &whitespace;>
1048 | OWS = <OWS, defined in &whitespace;>
1049 | quoted-string = <quoted-string, defined in &field-components;>
1050 | token = <token, defined in &field-components;>
1051 |
1052 |
1053 |
1054 |
1055 |
1056 |
1057 | In the collected ABNF below, list rules are expanded as per .
1058 |
1059 |
1060 | Authorization = credentials
1061 |
1062 | BWS = <BWS, defined in [Part1], Section 3.2.3>
1063 |
1064 | OWS = <OWS, defined in [Part1], Section 3.2.3>
1065 |
1066 | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
1067 | challenge ] )
1068 | Proxy-Authorization = credentials
1069 |
1070 | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1071 | ] )
1072 |
1073 | auth-param = token BWS "=" BWS ( token / quoted-string )
1074 | auth-scheme = token
1075 |
1076 | challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
1077 | OWS "," [ OWS auth-param ] ) ] ) ]
1078 | credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
1079 | *( OWS "," [ OWS auth-param ] ) ] ) ]
1080 |
1081 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
1082 |
1083 | token = <token, defined in [Part1], Section 3.2.6>
1084 | token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1085 | *"="
1086 |
1087 |
1088 |
1089 |
1090 |
1091 |
1092 |
1093 | Changes up to the first Working Group Last Call draft are summarized
1094 | in .
1095 |
1096 |
1097 |
1098 |
1099 | Closed issues:
1100 |
1101 |
1102 | :
1103 | "Realms and scope"
1104 |
1105 |
1106 | :
1107 | "Strength"
1108 |
1109 |
1110 | :
1111 | "Authentication exchanges"
1112 |
1113 |
1114 | :
1115 | "ABNF requirements for recipients"
1116 |
1117 |
1118 | :
1119 | "note introduction of new IANA registries as normative changes"
1120 |
1121 |
1122 |
1123 |
1124 |
1125 |
1126 |
1127 | Closed issues:
1128 |
1129 |
1130 | :
1131 | "rename b64token for clarity"
1132 |
1133 |
1134 |
1135 |
1136 | Other changes:
1137 |
1138 |
1139 | Conformance criteria and considerations regarding error handling are
1140 | now defined in Part 1.
1141 |
1142 |
1143 |
1144 |
1145 |
1146 |
1147 |
1148 | Closed issues:
1149 |
1150 |
1151 | :
1152 | "Authentication and caching - max-age"
1153 |
1154 |
1155 |
1156 |
1157 |
1158 |
1159 |
1160 | Closed issues:
1161 |
1162 |
1163 | :
1164 | "explain list expansion in ABNF appendices"
1165 |
1166 |
1167 | :
1168 | "terminology: mechanism vs framework vs scheme"
1169 |
1170 |
1171 | :
1172 | "Editorial suggestions"
1173 |
1174 |
1175 | :
1176 | "placement of extension point considerations"
1177 |
1178 |
1179 |
1180 |
1181 |
1182 |
1183 |
1184 |
1185 |
--------------------------------------------------------------------------------
/refs/draft-ietf-httpbis-p7-auth-25.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 | MAY">
5 | MUST">
6 | MUST NOT">
7 | OPTIONAL">
8 | RECOMMENDED">
9 | REQUIRED">
10 | SHALL">
11 | SHALL NOT">
12 | SHOULD">
13 | SHOULD NOT">
14 |
15 |
16 |
17 |
18 | Note:">
19 | ">
20 | ">
21 | ">
22 | ">
23 | ">
24 | ">
25 | ">
26 | ">
27 | ">
28 | ">
29 | ">
30 | ">
31 | ">
32 | ">
33 | ">
34 | ">
35 | ]>
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
51 |
52 |
53 |
54 |
55 | Hypertext Transfer Protocol (HTTP/1.1): Authentication
56 |
57 |
58 | Adobe Systems Incorporated
59 |
60 |
61 | 345 Park Ave
62 | San Jose
63 | CA
64 | 95110
65 | USA
66 |
67 | fielding@gbiv.com
68 | http://roy.gbiv.com/
69 |
70 |
71 |
72 |
73 | greenbytes GmbH
74 |
75 |
76 | Hafenweg 16
77 | MuensterNW48155
78 | Germany
79 |
80 | julian.reschke@greenbytes.de
81 | http://greenbytes.de/tech/webdav/
82 |
83 |
84 |
85 |
86 | HTTPbis Working Group
87 |
88 |
89 |
90 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
91 | distributed, collaborative, hypermedia information systems. This document
92 | defines the HTTP Authentication framework.
93 |
94 |
95 |
96 |
97 |
98 | Discussion of this draft takes place on the HTTPBIS working group
99 | mailing list (ietf-http-wg@w3.org), which is archived at
100 | .
101 |
102 |
103 | The current issues list is at
104 | and related
105 | documents (including fancy diffs) can be found at
106 | .
107 |
108 |
109 | The changes in this draft are summarized in .
110 |
111 |
112 |
113 |
114 |
115 |
116 | This document defines HTTP/1.1 access control and authentication. It
117 | includes the relevant parts of RFC 2616
118 | with only minor changes (), plus the general framework for HTTP authentication,
119 | as previously defined in "HTTP Authentication: Basic and Digest Access
120 | Authentication" ().
121 |
122 |
123 | HTTP provides several &OPTIONAL; challenge-response authentication
124 | schemes that can be used by a server to challenge a client request and
125 | by a client to provide authentication information. The "basic" and "digest"
126 | authentication schemes continue to be specified in
127 | RFC 2617.
128 |
129 |
130 |
131 |
132 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 | document are to be interpreted as described in .
135 |
136 |
137 | Conformance criteria and considerations regarding error handling
138 | are defined in &conformance;.
139 |
140 |
141 |
142 |
143 |
144 | This specification uses the Augmented Backus-Naur Form (ABNF) notation
145 | of with the list rule extension defined in
146 | &abnf-extension;. describes rules imported from
147 | other documents. shows the collected ABNF
148 | with the list rule expanded.
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 | HTTP provides a simple challenge-response authentication framework
163 | that can be used by a server to challenge a client request and by a
164 | client to provide authentication information. It uses a case-insensitive
165 | token as a means to identify the authentication scheme, followed
166 | by additional information necessary for achieving authentication via that
167 | scheme. The latter can either be a comma-separated list of parameters or a
168 | single sequence of characters capable of holding base64-encoded
169 | information.
170 |
171 |
172 | Parameters are name-value pairs where the name is matched case-insensitively,
173 | and each parameter name &MUST; only occur once per challenge.
174 |
175 |
176 | auth-scheme = token
177 |
178 | auth-param = tokenBWS "=" BWS ( token / quoted-string )
179 |
180 | token68 = 1*( ALPHA / DIGIT /
181 | "-" / "." / "_" / "~" / "+" / "/" ) *"="
182 |
183 |
184 | The "token68" syntax allows the 66 unreserved URI characters (),
185 | plus a few others, so that it can hold a base64, base64url (URL and filename
186 | safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
187 | excluding whitespace ().
188 |
189 |
190 | The 401 (Unauthorized) response message is used by an origin server
191 | to challenge the authorization of a user agent. This response &MUST;
192 | include a WWW-Authenticate header field containing at least one
193 | challenge applicable to the requested resource.
194 |
195 |
196 | The 407 (Proxy Authentication Required) response message is
197 | used by a proxy to challenge the authorization of a client and &MUST;
198 | include a Proxy-Authenticate header field containing at least
199 | one challenge applicable to the proxy for the requested resource.
200 |
201 |
202 | challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
203 |
204 |
205 |
206 | &Note; Many clients fail to parse challenges containing unknown
207 | schemes. A workaround for this problem is to list well-supported schemes
208 | (such as "basic") first.
209 |
210 |
211 |
212 | A user agent that wishes to authenticate itself with an origin server
213 | — usually, but not necessarily, after receiving a 401 (Unauthorized)
214 | — can do so by including an Authorization header field with the
215 | request.
216 |
217 |
218 | A client that wishes to authenticate itself with a proxy — usually,
219 | but not necessarily, after receiving a 407 (Proxy Authentication Required)
220 | — can do so by including a Proxy-Authorization header field with the
221 | request.
222 |
223 |
224 | Both the Authorization field value and the Proxy-Authorization field value
225 | contain the client's credentials for the realm of the resource being
226 | requested, based upon a challenge received in a response (possibly at
227 | some point in the past). When creating their values, the user agent ought to
228 | do so by selecting the challenge with what it considers to be the most
229 | secure auth-scheme that it understands, obtaining credentials from the user
230 | as appropriate.
231 |
232 |
233 | credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
234 |
235 |
236 | Upon receipt of a request for a protected resource that omits credentials,
237 | contains invalid credentials (e.g., a bad password) or partial credentials
238 | (e.g., when the authentication scheme requires more than one round trip), an
239 | origin server &SHOULD; send a 401 (Unauthorized) response that
240 | contains a WWW-Authenticate header field with at least one
241 | (possibly new) challenge applicable to the requested resource.
242 |
243 |
244 | Likewise, upon receipt of a request that requires authentication by proxies
245 | that omit credentials or contain invalid or partial credentials, a proxy
246 | &SHOULD; send a 407 (Proxy Authentication Required) response
247 | that contains a Proxy-Authenticate header field with a
248 | (possibly new) challenge applicable to the proxy.
249 |
250 |
251 | A server receiving credentials that are valid, but not adequate to gain
252 | access, ought to respond with the 403 (Forbidden) status code (&status.403;).
253 |
254 |
255 | HTTP does not restrict applications to this simple challenge-response
256 | framework for access authentication. Additional mechanisms can be used, such
257 | as authentication at the transport level or via message encapsulation, and
258 | with additional header fields specifying authentication information. However,
259 | such additional mechanisms are not defined by this specification.
260 |
261 |
262 | A proxy &MUST; forward the WWW-Authenticate and
263 | Authorization header fields unmodified and follow the rules
264 | found in .
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 | The authentication parameter realm is reserved for use by authentication
274 | schemes that wish to indicate the scope of protection.
275 |
276 |
277 | A protection space is defined by the canonical root URI (the
278 | scheme and authority components of the effective request URI; see
279 | ) of the
280 | server being accessed, in combination with the realm value if present.
281 | These realms allow the protected resources on a server to be
282 | partitioned into a set of protection spaces, each with its own
283 | authentication scheme and/or authorization database. The realm value
284 | is a string, generally assigned by the origin server, which can have
285 | additional semantics specific to the authentication scheme. Note that a
286 | response can have multiple challenges with the same auth-scheme but
287 | different realms.
288 |
289 |
290 | The protection space determines the domain over which credentials can
291 | be automatically applied. If a prior request has been authorized, the
292 | user agent &MAY; reuse the same credentials for all other requests within
293 | that protection space for a period of time determined by the authentication
294 | scheme, parameters, and/or user preferences (such as a configurable
295 | inactivity timeout). Unless specifically allowed by the authentication
296 | scheme, a single protection space cannot extend outside the scope of its
297 | server.
298 |
299 |
300 | For historical reasons, a sender &MUST; only generate the quoted-string syntax.
301 | Recipients might have to support both token and quoted-string syntax for
302 | maximum interoperability with existing clients that have been accepting both
303 | notations for a long time.
304 |
305 |
306 |
307 |
308 |
309 |
310 |
311 |
312 |
313 |
314 | The 401 (Unauthorized) status code indicates that the
315 | request has not been applied because it lacks valid authentication
316 | credentials for the target resource. The origin server &MUST; send a
317 | WWW-Authenticate header field ()
318 | containing at least one challenge applicable to the target resource.
319 | If the request included authentication credentials, then the 401 response
320 | indicates that authorization has been refused for those credentials.
321 | The user agent &MAY; repeat the request with a new or replaced
322 | Authorization header field ().
323 | If the 401 response contains the same challenge as the prior response, and
324 | the user agent has already attempted authentication at least once, then the
325 | user agent &SHOULD; present the enclosed representation to the user, since
326 | it usually contains relevant diagnostic information.
327 |
328 |
329 |
330 |
331 |
332 |
333 | The 407 (Proxy Authentication Required) status code is
334 | similar to 401 (Unauthorized), but indicates that the client
335 | needs to authenticate itself in order to use a proxy.
336 | The proxy &MUST; send a Proxy-Authenticate header field
337 | () containing a challenge
338 | applicable to that proxy for the target resource. The client &MAY; repeat
339 | the request with a new or replaced Proxy-Authorization
340 | header field ().
341 |
342 |
343 |
344 |
345 |
346 |
347 | This section defines the syntax and semantics of HTTP/1.1 header fields
348 | related to authentication.
349 |
350 |
351 |
352 |
353 |
354 |
355 | The "Authorization" header field allows a user agent to authenticate itself
356 | with an origin server — usually, but not necessarily, after receiving
357 | a 401 (Unauthorized) response. Its value consists of
358 | credentials containing the authentication information of the user agent for
359 | the realm of the resource being requested.
360 |
361 |
362 | Authorization = credentials
363 |
364 |
365 | If a request is authenticated and a realm specified, the same credentials
366 | are presumed to be valid for all other requests within this realm (assuming
367 | that the authentication scheme itself does not require otherwise, such as
368 | credentials that vary according to a challenge value or using synchronized
369 | clocks).
370 |
371 |
372 | See &caching-authenticated-responses; for details of and requirements
373 | pertaining to handling of the Authorization field by HTTP caches.
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 | The "Proxy-Authenticate" header field consists of at least one
382 | challenge that indicates the authentication scheme(s) and parameters
383 | applicable to the proxy for this effective request URI (&effective-request-uri;).
384 | It &MUST; be included as part of a 407 (Proxy Authentication Required) response.
385 |
386 |
387 | Proxy-Authenticate = 1#challenge
388 |
389 |
390 | Unlike WWW-Authenticate, the Proxy-Authenticate header field
391 | applies only to the next outbound client on the response chain that chose
392 | to direct its request to the responding proxy. If that recipient is also a
393 | proxy, it will generally consume the Proxy-Authenticate header field (and
394 | generate an appropriate Proxy-Authorization in a subsequent
395 | request) rather than forward the header field to its own outbound clients.
396 | However, if a recipient proxy needs to obtain its own credentials by
397 | requesting them from a further outbound client, it will generate its own
398 | 407 response, which might have the appearance of forwarding the
399 | Proxy-Authenticate header field if both proxies use the same challenge set.
400 |
401 |
402 | Note that the parsing considerations for WWW-Authenticate
403 | apply to this header field as well; see
404 | for details.
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 | The "Proxy-Authorization" header field allows the client to
413 | identify itself (or its user) to a proxy that requires
414 | authentication. Its value consists of credentials containing the
415 | authentication information of the client for the proxy and/or realm of the
416 | resource being requested.
417 |
418 |
419 | Proxy-Authorization = credentials
420 |
421 |
422 | Unlike Authorization, the Proxy-Authorization header field
423 | applies only to the next inbound proxy that demanded authentication using
424 | the Proxy-Authenticate field. When multiple proxies are used
425 | in a chain, the Proxy-Authorization header field is consumed by the first
426 | inbound proxy that was expecting to receive credentials. A proxy &MAY;
427 | relay the credentials from the client request to the next proxy if that is
428 | the mechanism by which the proxies cooperatively authenticate a given
429 | request.
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 | The "WWW-Authenticate" header field consists of at least one
438 | challenge that indicates the authentication scheme(s) and parameters
439 | applicable to the effective request URI (&effective-request-uri;).
440 |
441 |
442 | It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
443 | included in other response messages to indicate that supplying credentials
444 | (or different credentials) might affect the response.
445 |
446 |
447 | WWW-Authenticate = 1#challenge
448 |
449 |
450 | User agents are advised to take special care in parsing the field value, as
451 | it might contain more than one challenge, and each challenge can contain a
452 | comma-separated list of authentication parameters. Furthermore, the header
453 | field itself can occur multiple times.
454 |
455 |
456 | For instance:
457 |
458 | WWW-Authenticate: Newauth realm="apps", type=1,
459 | title="Login to \"apps\"", Basic realm="simple"
460 |
461 |
462 | This header field contains two challenges; one for the "Newauth" scheme
463 | with a realm value of "apps", and two additional parameters "type" and
464 | "title", and another one for the "Basic" scheme with a realm value of
465 | "simple".
466 |
467 |
468 |
469 | &Note; The challenge grammar production uses the list syntax as
470 | well. Therefore, a sequence of comma, whitespace, and comma can be
471 | considered either as applying to the preceding challenge, or to be an
472 | empty entry in the list of challenges. In practice, this ambiguity
473 | does not affect the semantics of the header field value and thus is
474 | harmless.
475 |
476 |
477 |
478 |
479 |
480 |
481 |
482 |
483 |
484 |
485 | The HTTP Authentication Scheme Registry defines the name space for the
486 | authentication schemes in challenges and credentials. It will be created and
487 | maintained at (the suggested URI) .
488 |
489 |
490 |
491 |
492 | Registrations &MUST; include the following fields:
493 |
494 | Authentication Scheme Name
495 | Pointer to specification text
496 | Notes (optional)
497 |
498 |
499 |
500 | Values to be added to this name space require IETF Review
501 | (see ).
502 |
503 |
504 |
505 |
506 |
507 | There are certain aspects of the HTTP Authentication Framework that put
508 | constraints on how new authentication schemes can work:
509 |
510 |
511 |
512 |
513 |
514 | HTTP authentication is presumed to be stateless: all of the information
515 | necessary to authenticate a request &MUST; be provided in the request,
516 | rather than be dependent on the server remembering prior requests.
517 | Authentication based on, or bound to, the underlying connection is
518 | outside the scope of this specification and inherently flawed unless
519 | steps are taken to ensure that the connection cannot be used by any
520 | party other than the authenticated user
521 | (see &msg-orient-and-buffering;).
522 |
523 |
524 |
525 |
526 | The authentication parameter "realm" is reserved for defining Protection
527 | Spaces as defined in . New schemes
528 | &MUST-NOT; use it in a way incompatible with that definition.
529 |
530 |
531 |
532 |
533 | The "token68" notation was introduced for compatibility with existing
534 | authentication schemes and can only be used once per challenge or credential.
535 | New schemes thus ought to use the "auth-param" syntax instead, because
536 | otherwise future extensions will be impossible.
537 |
538 |
539 |
540 |
541 | The parsing of challenges and credentials is defined by this specification,
542 | and cannot be modified by new authentication schemes. When the auth-param
543 | syntax is used, all parameters ought to support both token and
544 | quoted-string syntax, and syntactical constraints ought to be defined on
545 | the field value after parsing (i.e., quoted-string processing). This is
546 | necessary so that recipients can use a generic parser that applies to
547 | all authentication schemes.
548 |
549 |
550 | &Note; The fact that the value syntax for the "realm" parameter
551 | is restricted to quoted-string was a bad design choice not to be repeated
552 | for new parameters.
553 |
554 |
555 |
556 |
557 | Definitions of new schemes ought to define the treatment of unknown
558 | extension parameters. In general, a "must-ignore" rule is preferable
559 | over "must-understand", because otherwise it will be hard to introduce
560 | new parameters in the presence of legacy recipients. Furthermore,
561 | it's good to describe the policy for defining new parameters (such
562 | as "update the specification", or "use this registry").
563 |
564 |
565 |
566 |
567 | Authentication schemes need to document whether they are usable in
568 | origin-server authentication (i.e., using WWW-Authenticate),
569 | and/or proxy authentication (i.e., using Proxy-Authenticate).
570 |
571 |
572 |
573 |
574 | The credentials carried in an Authorization header field are specific to
575 | the User Agent, and therefore have the same effect on HTTP caches as the
576 | "private" Cache-Control response directive (&caching-rsd-private;),
577 | within the scope of the request they appear in.
578 |
579 |
580 | Therefore, new authentication schemes that choose not to carry
581 | credentials in the Authorization header field (e.g., using a newly defined
582 | header field) will need to explicitly disallow caching, by mandating the use of
583 | either Cache-Control request directives (e.g., "no-store",
584 | &caching-rqd-no-store;) or response directives (e.g., "private").
585 |
586 |
587 |
588 |
589 |
590 |
591 |
592 |
593 |
594 | The HTTP Status Code Registry located at
595 | shall be updated with the registrations below:
596 |
597 |
598 |
599 |
600 | Value
601 | Description
602 | Reference
603 | 401
604 | Unauthorized
605 |
606 |
607 |
608 | 407
609 | Proxy Authentication Required
610 |
611 |
612 |
613 |
614 |
615 |
616 |
617 |
618 |
619 |
620 | HTTP header fields are registered within the Message Header Field Registry
621 | maintained at
622 | .
623 |
624 |
625 | This document defines the following HTTP header fields, so their
626 | associated registry entries shall be updated according to the permanent
627 | registrations below (see ):
628 |
629 |
630 |
631 |
632 | Header Field Name
633 | Protocol
634 | Status
635 | Reference
636 |
637 | Authorization
638 | http
639 | standard
640 |
641 |
642 |
643 | Proxy-Authenticate
644 | http
645 | standard
646 |
647 |
648 |
649 | Proxy-Authorization
650 | http
651 | standard
652 |
653 |
654 |
655 | WWW-Authenticate
656 | http
657 | standard
658 |
659 |
660 |
661 |
662 |
663 |
664 |
665 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
666 |
667 |
668 |
669 |
670 |
671 |
672 | This section is meant to inform developers, information providers, and
673 | users of known security concerns specific to HTTP/1.1 authentication.
674 | More general security considerations are addressed in HTTP messaging
675 | &messaging; and semantics &semantics;.
676 |
677 |
678 |
679 |
680 | Existing HTTP clients and user agents typically retain authentication
681 | information indefinitely. HTTP does not provide a mechanism for the
682 | origin server to direct clients to discard these cached credentials, since
683 | the protocol has no awareness of how credentials are obtained or managed
684 | by the user agent. The mechanisms for expiring or revoking credentials can
685 | be specified as part of an authentication scheme definition.
686 |
687 |
688 | Circumstances under which credential caching can interfere with the
689 | application's security model include but are not limited to:
690 |
691 | Clients that have been idle for an extended period, following
692 | which the server might wish to cause the client to re-prompt the
693 | user for credentials.
694 |
695 | Applications that include a session termination indication
696 | (such as a "logout" or "commit" button on a page) after which
697 | the server side of the application "knows" that there is no
698 | further reason for the client to retain the credentials.
699 |
700 |
701 |
702 | User agents that cache credentials are encouraged to provide a readily
703 | accessible mechanism for discarding cached credentials under user control.
704 |
705 |
706 |
707 |
708 |
709 | Authentication schemes that solely rely on the "realm" mechanism for
710 | establishing a protection space will expose credentials to all resources on
711 | an origin server. Clients that have successfully made authenticated requests
712 | with a resource can use the same authentication credentials for other
713 | resources on the same origin server. This makes it possible for a different
714 | resource to harvest authentication credentials for other resources.
715 |
716 |
717 | This is of particular concern when an origin server hosts resources for multiple
718 | parties under the same canonical root URI ().
719 | Possible mitigation strategies include restricting direct access to
720 | authentication credentials (i.e., not making the content of the
721 | Authorization request header field available), and separating protection
722 | spaces by using a different host name (or port number) for each party.
723 |
724 |
725 |
726 |
727 |
728 |
729 | This specification takes over the definition of the HTTP Authentication
730 | Framework, previously defined in RFC 2617.
731 | We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
732 | Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
733 | on that specification. See
734 | for further acknowledgements.
735 |
736 |
737 | See &acks; for the Acknowledgments related to this document revision.
738 |
739 |
740 |
741 |
742 |
743 |
744 |
745 |
746 |
747 |
748 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
749 |
750 | Adobe Systems Incorporated
751 | fielding@gbiv.com
752 |
753 |
754 | greenbytes GmbH
755 | julian.reschke@greenbytes.de
756 |
757 |
758 |
759 |
760 |
761 |
762 |
763 |
764 |
765 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
766 |
767 | Adobe Systems Incorporated
768 | fielding@gbiv.com
769 |
770 |
771 | greenbytes GmbH
772 | julian.reschke@greenbytes.de
773 |
774 |
775 |
776 |
777 |
778 | 403 (Forbidden)
779 | Location
780 |
781 |
782 |
783 |
784 |
785 | Hypertext Transfer Protocol (HTTP/1.1): Caching
786 |
787 | Adobe Systems Incorporated
788 | fielding@gbiv.com
789 |
790 |
791 | Akamai
792 | mnot@mnot.net
793 |
794 |
795 | greenbytes GmbH
796 | julian.reschke@greenbytes.de
797 |
798 |
799 |
800 |
801 |
802 |
803 |
804 |
805 |
806 | Key words for use in RFCs to Indicate Requirement Levels
807 |
808 | Harvard University
809 | sob@harvard.edu
810 |
811 |
812 |
813 |
814 |
815 |
816 |
817 |
818 |
819 | Augmented BNF for Syntax Specifications: ABNF
820 |
821 | Brandenburg InternetWorking
822 |
823 | dcrocker@bbiw.net
824 |
825 |
826 |
827 | THUS plc.
828 |
829 | paul.overell@thus.net
830 |
831 |
832 |
833 |
834 |
835 |
836 |
837 |
838 |
839 |
840 |
841 |
842 |
843 |
844 | Hypertext Transfer Protocol -- HTTP/1.1
845 |
846 | University of California, Irvine
847 | fielding@ics.uci.edu
848 |
849 |
850 | W3C
851 | jg@w3.org
852 |
853 |
854 | Compaq Computer Corporation
855 | mogul@wrl.dec.com
856 |
857 |
858 | MIT Laboratory for Computer Science
859 | frystyk@w3.org
860 |
861 |
862 | Xerox Corporation
863 | masinter@parc.xerox.com
864 |
865 |
866 | Microsoft Corporation
867 | paulle@microsoft.com
868 |
869 |
870 | W3C
871 | timbl@w3.org
872 |
873 |
874 |
875 |
876 |
877 |
878 |
879 |
880 | HTTP Authentication: Basic and Digest Access Authentication
881 |
882 | Northwestern University, Department of Mathematics
883 | john@math.nwu.edu
884 |
885 |
886 | Verisign Inc.
887 | pbaker@verisign.com
888 |
889 |
890 | AbiSource, Inc.
891 | jeff@AbiSource.com
892 |
893 |
894 | Agranat Systems, Inc.
895 | lawrence@agranat.com
896 |
897 |
898 | Microsoft Corporation
899 | paulle@microsoft.com
900 |
901 |
902 | Netscape Communications Corporation
903 |
904 |
905 | Open Market, Inc.
906 | stewart@OpenMarket.com
907 |
908 |
909 |
910 |
911 |
912 |
913 |
914 |
915 | Registration Procedures for Message Header Fields
916 |
917 | Nine by Nine
918 | GK-IETF@ninebynine.org
919 |
920 |
921 | BEA Systems
922 | mnot@pobox.com
923 |
924 |
925 | HP Labs
926 | JeffMogul@acm.org
927 |
928 |
929 |
930 |
931 |
932 |
933 |
934 |
935 |
936 | Uniform Resource Identifier (URI): Generic Syntax
937 |
938 | World Wide Web Consortium
939 |
940 | timbl@w3.org
941 | http://www.w3.org/People/Berners-Lee/
942 |
943 |
944 |
945 | Day Software
946 |
947 | fielding@gbiv.com
948 | http://roy.gbiv.com/
949 |
950 |
951 |
952 | Adobe Systems Incorporated
953 |
954 | LMM@acm.org
955 | http://larry.masinter.net/
956 |
957 |
958 |
959 |
960 |
961 |
962 |
963 |
964 |
965 |
966 | The Base16, Base32, and Base64 Data Encodings
967 |
968 |
969 |
970 |
971 |
972 |
973 |
974 |
975 | Guidelines for Writing an IANA Considerations Section in RFCs
976 |
977 | IBM
978 | narten@us.ibm.com
979 |
980 |
981 | Google
982 | Harald@Alvestrand.no
983 |
984 |
985 |
986 |
987 |
988 |
989 |
990 |
991 |
992 |
993 |
994 | The framework for HTTP Authentication is now defined by this document,
995 | rather than RFC 2617.
996 |
997 |
998 | The "realm" parameter is no longer always required on challenges;
999 | consequently, the ABNF allows challenges without any auth parameters.
1000 | ()
1001 |
1002 |
1003 | The "token68" alternative to auth-param lists has been added for consistency
1004 | with legacy authentication schemes such as "Basic".
1005 | ()
1006 |
1007 |
1008 | This specification introduces the Authentication Scheme Registry, along with
1009 | considerations for new authentication schemes.
1010 | ()
1011 |
1012 |
1013 |
1014 |
1015 |
1016 |
1017 |
1018 |
1019 |
1020 |
1021 |
1022 |
1023 |
1024 |
1025 |
1026 |
1027 | The following core rules are included by
1028 | reference, as defined in :
1029 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1030 | DIGIT (decimal 0-9), DQUOTE (double quote),
1031 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1032 | OCTET (any 8-bit sequence of data), SP (space), and
1033 | VCHAR (any visible US-ASCII character).
1034 |
1035 |
1036 | The rules below are defined in :
1037 |
1038 |
1039 | BWS = <BWS, defined in &whitespace;>
1040 | OWS = <OWS, defined in &whitespace;>
1041 | quoted-string = <quoted-string, defined in &field-components;>
1042 | token = <token, defined in &field-components;>
1043 |
1044 |
1045 |
1046 |
1047 |
1048 |
1049 | In the collected ABNF below, list rules are expanded as per .
1050 |
1051 |
1052 | Authorization = credentials
1053 |
1054 | BWS = <BWS, defined in [Part1], Section 3.2.3>
1055 |
1056 | OWS = <OWS, defined in [Part1], Section 3.2.3>
1057 |
1058 | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
1059 | challenge ] )
1060 | Proxy-Authorization = credentials
1061 |
1062 | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1063 | ] )
1064 |
1065 | auth-param = token BWS "=" BWS ( token / quoted-string )
1066 | auth-scheme = token
1067 |
1068 | challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
1069 | OWS "," [ OWS auth-param ] ) ] ) ]
1070 | credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
1071 | *( OWS "," [ OWS auth-param ] ) ] ) ]
1072 |
1073 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
1074 |
1075 | token = <token, defined in [Part1], Section 3.2.6>
1076 | token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1077 | *"="
1078 |
1079 |
1080 |
1081 |
1082 |
1083 |
1084 |
1085 | Changes up to the IETF Last Call draft are summarized
1086 | in .
1087 |
1088 |
1089 |
1090 |
1091 | Closed issues:
1092 |
1093 |
1094 | :
1095 | "SECDIR review of draft-ietf-httpbis-p7-auth-24"
1096 |
1097 |
1098 | :
1099 | "APPSDIR review of draft-ietf-httpbis-p7-auth-24"
1100 |
1101 |
1102 | :
1103 | "note about WWW-A parsing potentially misleading"
1104 |
1105 |
1106 |
1107 |
1108 |
1109 |
1110 |
1111 |
1112 |
--------------------------------------------------------------------------------