source: draft-ietf-httpbis/latest/auth48/rfc7235.abdiff.txt @ 2678

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

add RFC7234-to-be and RFC7235-to-be (#553)

File size: 21.9 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
8 Updates: 2617 (if approved)                                   greenbytes
9 Intended status: Standards Track                            May 16, 2014
10 Expires: November 17, 2014
11
12NEW:
13
14 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
15 Request for Comments: 7235                                         Adobe
16 Obsoletes: 2616                                          J. Reschke, Ed.
17 Updates: 2617                                                 greenbytes
18 Category: Standards Track                                       May 2014
19 ISSN: 2070-1721
20
21
22INTRODUCTION, paragraph 2:
23OLD:
24
25          Hypertext Transfer Protocol (HTTP/1.1): Authentication
26                    draft-ietf-httpbis-p7-auth-latest
27
28NEW:
29
30          Hypertext Transfer Protocol (HTTP/1.1): Authentication
31
32
33INTRODUCTION, paragraph 5:
34OLD:
35
36 Editorial Note (To be removed by RFC Editor)
37 
38    Discussion of this draft takes place on the HTTPBIS working group
39    mailing list (ietf-http-wg@w3.org), which is archived at
40    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
41 
42    The current issues list is at
43    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
44    documents (including fancy diffs) can be found at
45    <http://tools.ietf.org/wg/httpbis/>.
46 
47    _This is a temporary document for the purpose of tracking the
48    editorial changes made during the AUTH48 (RFC publication) phase._
49 
50 Status of This Memo
51
52NEW:
53
54 Status of This Memo
55
56
57INTRODUCTION, paragraph 6:
58OLD:
59
60    This Internet-Draft is submitted in full conformance with the
61    provisions of BCP 78 and BCP 79.
62 
63    Internet-Drafts are working documents of the Internet Engineering
64    Task Force (IETF).  Note that other groups may also distribute
65    working documents as Internet-Drafts.  The list of current Internet-
66    Drafts is at http://datatracker.ietf.org/drafts/current/.
67
68NEW:
69
70    This is an Internet Standards Track document.
71
72
73INTRODUCTION, paragraph 7:
74OLD:
75
76    Internet-Drafts are draft documents valid for a maximum of six months
77    and may be updated, replaced, or obsoleted by other documents at any
78    time.  It is inappropriate to use Internet-Drafts as reference
79    material or to cite them other than as "work in progress."
80
81NEW:
82
83    This document is a product of the Internet Engineering Task Force
84    (IETF).  It represents the consensus of the IETF community.  It has
85    received public review and has been approved for publication by the
86    Internet Engineering Steering Group (IESG).  Further information on
87    Internet Standards is available in Section 2 of RFC 5741.
88
89
90INTRODUCTION, paragraph 8:
91OLD:
92
93    This Internet-Draft will expire on November 17, 2014.
94
95NEW:
96
97    Information about the current status of this document, any errata,
98    and how to provide feedback on it may be obtained at
99    http://www.rfc-editor.org/info/rfc7235.
100
101
102INTRODUCTION, paragraph 14:
103OLD:
104
105    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
106      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
107      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
108    2.  Access Authentication Framework  . . . . . . . . . . . . . . .  4
109      2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  4
110      2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  6
111    3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  7
112      3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  7
113      3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  7
114    4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  7
115      4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  8
116      4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
117      4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  9
118      4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  9
119    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
120      5.1.  Authentication Scheme Registry . . . . . . . . . . . . . . 10
121        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 10
122        5.1.2.  Considerations for New Authentication Schemes  . . . . 10
123      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 12
124      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 12
125    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
126      6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 13
127      6.2.  Authentication Credentials and Idle Clients  . . . . . . . 13
128      6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 14
129    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
130    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
131      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
132      8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
133    Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
134    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
135    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 16
136    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
137
138NEW:
139
140    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
141      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  3
142      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  3
143    2.  Access Authentication Framework  . . . . . . . . . . . . . . .  3
144      2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  3
145      2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  5
146    3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  6
147      3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  6
148      3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  6
149    4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  6
150      4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
151      4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
152      4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  8
153      4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  8
154    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
155      5.1.  Authentication Scheme Registry . . . . . . . . . . . . . .  9
156        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . .  9
157        5.1.2.  Considerations for New Authentication Schemes  . . . .  9
158      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 11
159      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 11
160    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
161      6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 12
162      6.2.  Authentication Credentials and Idle Clients  . . . . . . . 12
163      6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 13
164    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
165    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
166      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
167      8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
168    Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
169    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
170    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 15
171    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
172
173
174Section 1., paragraph 1:
175OLD:
176
177    HTTP provides a general framework for access control and
178    authentication, via an extensible set of challenge-response
179    authentication schemes, which can be used by a server to challenge a
180    client request and by a client to provide authentication information.
181    This document defines HTTP/1.1 authentication in terms of the
182    architecture defined in [RFC7230], including the general framework
183    previously described in RFC 2617 and the related fields and status
184    codes previously defined in RFC 2616.
185
186NEW:
187
188    HTTP provides a general framework for access control and
189    authentication, via an extensible set of challenge-response
190    authentication schemes, which can be used by a server to challenge a
191    client request and by a client to provide authentication information.
192    This document defines HTTP/1.1 authentication in terms of the
193    architecture defined in [RFC7230], including the general framework
194    previously described in [RFC2617] and the related fields and status
195    codes previously defined in [RFC2616].
196
197
198Section 2.1., paragraph 1:
199OLD:
200
201    HTTP provides a simple challenge-response authentication framework
202    that can be used by a server to challenge a client request and by a
203    client to provide authentication information.  It uses a case-
204    insensitive token as a means to identify the authentication scheme,
205    followed by additional information necessary for achieving
206    authentication via that scheme.  The latter can either be a comma-
207    separated list of parameters or a single sequence of characters
208    capable of holding base64-encoded information.
209
210NEW:
211
212    HTTP provides a simple challenge-response authentication framework
213    that can be used by a server to challenge a client request and by a
214    client to provide authentication information.  It uses a case-
215    insensitive token as a means to identify the authentication scheme,
216    followed by additional information necessary for achieving
217    authentication via that scheme.  The latter can be either a comma-
218    separated list of parameters or a single sequence of characters
219    capable of holding base64-encoded information.
220
221
222Section 2.1., paragraph 17:
223OLD:
224
225    A server that receives valid credentials which are not adequate to
226    gain access ought to respond with the 403 (Forbidden) status code
227    (Section 6.5.3 of [RFC7231]).
228
229NEW:
230
231    A server that receives valid credentials that are not adequate to
232    gain access ought to respond with the 403 (Forbidden) status code
233    (Section 6.5.3 of [RFC7231]).
234
235
236Section 5.5, paragraph 0:
237OLD:
238
239    A protection space is defined by the canonical root URI (the scheme
240    and authority components of the effective request URI; see Section
241    5.5 of [RFC7230]) of the server being accessed, in combination with
242    the realm value if present.  These realms allow the protected
243    resources on a server to be partitioned into a set of protection
244    spaces, each with its own authentication scheme and/or authorization
245    database.  The realm value is a string, generally assigned by the
246    origin server, which can have additional semantics specific to the
247    authentication scheme.  Note that a response can have multiple
248    challenges with the same auth-scheme but different realms.
249
250NEW:
251
252    A protection space is defined by the canonical root URI (the scheme
253    and authority components of the effective request URI; see Section
254    5.5 of [RFC7230]) of the server being accessed, in combination with
255    the realm value if present.  These realms allow the protected
256    resources on a server to be partitioned into a set of protection
257    spaces, each with its own authentication scheme and/or authorization
258    database.  The realm value is a string, generally assigned by the
259    origin server, that can have additional semantics specific to the
260    authentication scheme.  Note that a response can have multiple
261    challenges with the same auth-scheme but with different realms.
262
263
264Section 3.2., paragraph 1:
265OLD:
266
267    The 407 (Proxy Authentication Required) status code is similar to 401
268    (Unauthorized), but indicates that the client needs to authenticate
269    itself in order to use a proxy.  The proxy MUST send a Proxy-
270    Authenticate header field (Section 4.3) containing a challenge
271    applicable to that proxy for the target resource.  The client MAY
272    repeat the request with a new or replaced Proxy-Authorization header
273    field (Section 4.4).
274
275NEW:
276
277    The 407 (Proxy Authentication Required) status code is similar to 401
278    (Unauthorized), but it indicates that the client needs to
279    authenticate itself in order to use a proxy.  The proxy MUST send a
280    Proxy-Authenticate header field (Section 4.3) containing a challenge
281    applicable to that proxy for the target resource.  The client MAY
282    repeat the request with a new or replaced Proxy-Authorization header
283    field (Section 4.4).
284
285
286Section 5.1., paragraph 1:
287OLD:
288
289    The HTTP Authentication Scheme Registry defines the namespace for the
290    authentication schemes in challenges and credentials.  It will be
291    created and maintained at (the suggested URI)
292    <http://www.iana.org/assignments/http-authschemes>.
293
294NEW:
295
296    The "HTTP Authentication Schemes" registry defines the name space for
297    the authentication schemes in challenges and credentials.  The
298    registry has been created and is now maintained at
299    <http://www.iana.org/assignments/http-authschemes>.
300
301
302Section 5.1.2., paragraph 3:
303OLD:
304
305    o  The authentication parameter "realm" is reserved for defining
306       Protection Spaces as defined in Section 2.2.  New schemes MUST NOT
307       use it in a way incompatible with that definition.
308
309NEW:
310
311    o  The authentication parameter "realm" is reserved for defining
312       protection spaces as described in Section 2.2.  New schemes MUST
313       NOT use it in a way incompatible with that definition.
314
315
316Section 5.1.2., paragraph 4:
317OLD:
318
319    o  The "token68" notation was introduced for compatibility with
320       existing authentication schemes and can only be used once per
321       challenge or credential.  New schemes thus ought to use the "auth-
322       param" syntax instead, because otherwise future extensions will be
323       impossible.
324
325NEW:
326
327    o  The "token68" notation was introduced for compatibility with
328       existing authentication schemes and can only be used once per
329       challenge or credential.  Thus, new schemes ought to use the auth-
330       param syntax instead, because otherwise future extensions will be
331       impossible.
332
333
334Section 5.1.2., paragraph 5:
335OLD:
336
337    o  The parsing of challenges and credentials is defined by this
338       specification, and cannot be modified by new authentication
339       schemes.  When the auth-param syntax is used, all parameters ought
340       to support both token and quoted-string syntax, and syntactical
341       constraints ought to be defined on the field value after parsing
342       (i.e., quoted-string processing).  This is necessary so that
343       recipients can use a generic parser that applies to all
344       authentication schemes.
345
346NEW:
347
348    o  The parsing of challenges and credentials is defined by this
349       specification and cannot be modified by new authentication
350       schemes.  When the auth-param syntax is used, all parameters ought
351       to support both token and quoted-string syntax, and syntactical
352       constraints ought to be defined on the field value after parsing
353       (i.e., quoted-string processing).  This is necessary so that
354       recipients can use a generic parser that applies to all
355       authentication schemes.
356
357
358Section 5.1.2., paragraph 7:
359OLD:
360
361    o  Definitions of new schemes ought to define the treatment of
362       unknown extension parameters.  In general, a "must-ignore" rule is
363       preferable over "must-understand", because otherwise it will be
364       hard to introduce new parameters in the presence of legacy
365       recipients.  Furthermore, it's good to describe the policy for
366       defining new parameters (such as "update the specification", or
367       "use this registry").
368
369NEW:
370
371    o  Definitions of new schemes ought to define the treatment of
372       unknown extension parameters.  In general, a "must-ignore" rule is
373       preferable to a "must-understand" rule, because otherwise it will
374       be hard to introduce new parameters in the presence of legacy
375       recipients.  Furthermore, it's good to describe the policy for
376       defining new parameters (such as "update the specification" or
377       "use this registry").
378
379
380Section 5.1.2., paragraph 9:
381OLD:
382
383    o  The credentials carried in an Authorization header field are
384       specific to the User Agent, and therefore have the same effect on
385       HTTP caches as the "private" Cache-Control response directive
386       (Section 5.2.2.6 of [RFC7234]), within the scope of the request
387       they appear in.
388
389NEW:
390
391    o  The credentials carried in an Authorization header field are
392       specific to the user agent and, therefore, have the same effect on
393       HTTP caches as the "private" Cache-Control response directive
394       (Section 5.2.2.6 of [RFC7234]), within the scope of the request in
395       which they appear.
396
397
398Section 5.2., paragraph 1:
399OLD:
400
401    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
402    at <http://www.iana.org/assignments/http-status-codes> has been
403    updated with the registrations below:
404
405NEW:
406
407    The HTTP Status Code Registry located at
408    <http://www.iana.org/assignments/http-status-codes> shall be updated
409    with the registrations below:
410
411
412Section 5.3., paragraph 1:
413OLD:
414
415    HTTP header fields are registered within the "Message Headers"
416    registry maintained at
417    <http://www.iana.org/assignments/message-headers/>.
418
419NEW:
420
421    HTTP header fields are registered within the Message Header Field
422    Registry maintained at
423    <http://www.iana.org/assignments/message-headers>.
424
425
426Section 5.3., paragraph 2:
427OLD:
428
429    This document defines the following HTTP header fields, so the
430    "Permanent Message Header Field Names" registry has been updated
431    accordingly (see [BCP90]).
432
433NEW:
434
435    This document defines the following HTTP header fields, so their
436    associated registry entries have been updated according to the
437    permanent registrations below (see [BCP90]):
438
439
440Section 6.1., paragraph 2:
441OLD:
442
443    HTTP depends on the security properties of the underlying transport-
444    or session-level connection to provide confidential transmission of
445    header fields.  In other words, if a server limits access to
446    authenticated users using this framework, the server needs to ensure
447    that the connection is properly secured in accordance with the nature
448    of the authentication scheme used.  For example, services that depend
449    on individual user authentication often require a connection to be
450    secured with TLS ("Transport Layer Security", [RFC5246]) prior to
451    exchanging any credentials.
452
453NEW:
454
455    HTTP depends on the security properties of the underlying transport
456    or session-level connection to provide confidential transmission of
457    header fields.  In other words, if a server limits access to
458    authenticated users using this framework, the server needs to ensure
459    that the connection is properly secured in accordance with the nature
460    of the authentication scheme used.  For example, services that depend
461    on individual user authentication often require a connection to be
462    secured with TLS ("Transport Layer Security", [RFC5246]) prior to
463    exchanging any credentials.
464
465
466Section 8.1., paragraph 3:
467OLD:
468
469    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
470               Protocol (HTTP/1.1): Message Syntax and Routing",
471               draft-ietf-httpbis-p1-messaging-latest (work in progress),
472               May 2014.
473
474NEW:
475
476    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
477               Protocol (HTTP/1.1): Message Syntax and Routing",
478               RFC 7230, May 2014.
479
480
481Section 8.1., paragraph 4:
482OLD:
483
484    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
485               Protocol (HTTP/1.1): Semantics and Content",
486               draft-ietf-httpbis-p2-semantics-latest (work in progress),
487               May 2014.
488
489NEW:
490
491    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
492               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
493               May 2014.
494
495
496Section 8.1., paragraph 5:
497OLD:
498
499    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
500               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
501               draft-ietf-httpbis-p6-cache-latest (work in progress),
502               May 2014.
503
504NEW:
505
506    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
507               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
508               RFC 7234, May 2014.
509
510
511Section 1.2, paragraph 11:
512OLD:
513
514    4
515       401 Unauthorized (status code)  7
516       407 Proxy Authentication Required (status code)  7
517
518NEW:
519
520    4
521       401 Unauthorized (status code)  6
522       407 Proxy Authentication Required (status code)  6
523
524
525Section 1.2, paragraph 12:
526OLD:
527
528    A
529       Authorization header field  8
530
531NEW:
532
533    A
534       Authorization header field  7
535
536
537Section 1.2, paragraph 13:
538OLD:
539
540    C
541       Canonical Root URI  6
542
543NEW:
544
545    C
546       Canonical Root URI  5
547
548
549Section 1.2, paragraph 14:
550OLD:
551
552    G
553       Grammar
554          auth-param  5
555          auth-scheme  5
556          Authorization  8
557          challenge  5
558          credentials  6
559          Proxy-Authenticate  9
560          Proxy-Authorization  9
561          token68  5
562          WWW-Authenticate  8
563
564NEW:
565
566    G
567       Grammar
568          auth-param  4
569          auth-scheme  4
570          Authorization  7
571          challenge  4
572          credentials  5
573          Proxy-Authenticate  8
574          Proxy-Authorization  8
575          token68  4
576          WWW-Authenticate  7
577
578
579Section 1.2, paragraph 15:
580OLD:
581
582    P
583       Protection Space  6
584       Proxy-Authenticate header field  9
585       Proxy-Authorization header field  9
586
587NEW:
588
589    P
590       Protection Space  5
591       Proxy-Authenticate header field  8
592       Proxy-Authorization header field  8
593
594
595Section 1.2, paragraph 16:
596OLD:
597
598    R
599       Realm  6
600
601NEW:
602
603    R
604       Realm  5
605
606
607Section 1.2, paragraph 17:
608OLD:
609
610    W
611       WWW-Authenticate header field  8
612
613NEW:
614
615    W
616       WWW-Authenticate header field  7
617
Note: See TracBrowser for help on using the repository browser.