idnits 2.17.1
draft-ietf-httpbis-auth-info-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC2617, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2617, updated by this document, for
RFC5378 checks: 1997-12-01)
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 7, 2015) is 3308 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110)
== Outdated reference: A later version (-19) exists of
draft-ietf-httpauth-digest-15
-- Obsolete informational reference (is this intentional?): RFC 2617
(Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTP Working Group J. Reschke
3 Internet-Draft greenbytes
4 Updates: 2617 (if approved) April 7, 2015
5 Intended status: Standards Track
6 Expires: October 9, 2015
8 The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-
9 Authentication-Info Response Header Fields
10 draft-ietf-httpbis-auth-info-05
12 Abstract
14 This specification defines the "Authentication-Info" and "Proxy-
15 Authentication-Info" response header fields for use in HTTP
16 authentication schemes which need to return information once the
17 client's authentication credentials have been accepted.
19 Editorial Note (To be removed by RFC Editor)
21 Discussion of this draft takes place on the HTTPBIS working group
22 mailing list (ietf-http-wg@w3.org), which is archived at
23 .
25 Working Group information can be found at
26 and ;
27 source code and issues list for this draft can be found at
28 .
30 The changes in this draft are summarized in Appendix A.6.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on October 9, 2015.
49 Copyright Notice
51 Copyright (c) 2015 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 This document may contain material from IETF Documents or IETF
65 Contributions published or made publicly available before November
66 10, 2008. The person(s) controlling the copyright in some of this
67 material may not have granted the IETF Trust the right to allow
68 modifications of such material outside the IETF Standards Process.
69 Without obtaining an adequate license from the person(s) controlling
70 the copyright in such materials, this document may not be modified
71 outside the IETF Standards Process, and derivative works of it may
72 not be created outside the IETF Standards Process, except to format
73 it for publication as an RFC or to translate it into languages other
74 than English.
76 Table of Contents
78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
79 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
80 3. The Authentication-Info Response Header Field . . . . . . . . . 3
81 3.1. Parameter Value Format . . . . . . . . . . . . . . . . . . 4
82 4. The Proxy-Authentication-Info Response Header Field . . . . . . 4
83 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
87 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
88 Appendix A. Change Log (to be removed by RFC Editor before
89 publication) . . . . . . . . . . . . . . . . . . . . . 6
90 A.1. draft-reschke-httpauth-auth-info-00 . . . . . . . . . . . . 6
91 A.2. Since draft-ietf-httpbis-auth-info-00 . . . . . . . . . . . 6
92 A.3. Since draft-ietf-httpbis-auth-info-01 . . . . . . . . . . . 6
93 A.4. Since draft-ietf-httpbis-auth-info-02 . . . . . . . . . . . 6
94 A.5. Since draft-ietf-httpbis-auth-info-03 . . . . . . . . . . . 7
95 A.6. Since draft-ietf-httpbis-auth-info-04 . . . . . . . . . . . 7
96 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
98 1. Introduction
100 This specification defines the "Authentication-Info" and "Proxy-
101 Authentication-Info" response header fields for use in HTTP
102 authentication schemes ([RFC7235]) which need to return information
103 once the client's authentication credentials have been accepted.
105 Both were previously defined in Section 3 of [RFC2617], defining the
106 HTTP "Digest" authentication scheme. This document generalizes the
107 description for use not only in "Digest" ([DIGEST]), but also in
108 other future schemes that might have the same requirements for
109 carrying additional information during authentication.
111 2. Notational Conventions
113 This specification uses the Augmented Backus-Naur Form (ABNF)
114 notation of [RFC5234] with a list extension, defined in Section 7 of
115 [RFC7230], that allows for compact definition of comma-separated
116 lists using a '#' operator (similar to how the '*' operator indicates
117 repetition). The ABNF production for "auth-param" is defined in
118 Section 2.1 of [RFC7235].
120 3. The Authentication-Info Response Header Field
122 HTTP authentication schemes can use the Authentication-Info response
123 header field to communicate information after the client's
124 authentication credentials have been accepted. This information can
125 include a finalization message from the server (e.g., it can contain
126 the server authentication).
128 The field value is a list of parameters (name/value pairs), using the
129 "auth-param" syntax defined in Section 2.1 of [RFC7235]. This
130 specification only describes the generic format; authentication
131 schemes using "Authentication-Info" will define the individual
132 parameters. The "Digest" Authentication Scheme, for instance,
133 defines multiple parameters in Section 3.5 of [DIGEST].
135 Authentication-Info = #auth-param
137 The Authentication-Info header field can be used in any HTTP
138 response, independently of request method and status code. Its
139 semantics are defined by the authentication scheme indicated by the
140 Authorization header field ([RFC7235], Section 4.2) of the
141 corresponding request.
143 A proxy forwarding a response is not allowed to modify the field
144 value in any way.
146 Authentication-Info can be used inside trailers ([RFC7230], Section
147 4.1.2) when the authentication scheme explicitly allows this.
149 3.1. Parameter Value Format
151 Parameter values can be expressed either as "token" or as "quoted-
152 string" (Section 3.2.6 of [RFC7230]).
154 Authentication scheme definitions need to allow both notations, both
155 for senders and recipients. This allows recipients to use generic
156 parsing components, independent of the authentication scheme in use.
158 For backwards compatibility, authentication scheme definitions can
159 restrict the format for senders to one of the two variants. This can
160 be important when it is known that deployed implementations will fail
161 when encountering one of the two formats.
163 4. The Proxy-Authentication-Info Response Header Field
165 The Proxy-Authentication-Info response header field is equivalent to
166 Authentication-Info, except that its semantics are defined by the
167 authentication scheme indicated by the Proxy-Authorization header
168 field ([RFC7235], Section 4.4) of the corresponding request, and
169 applies to proxy authentication ([RFC7235], Section 2):
171 Proxy-Authentication-Info = #auth-param
173 However, unlike Authentication-Info, the Proxy-Authentication-Info
174 header field applies only to the next outbound client on the response
175 chain. This is because only the client that chose a given proxy is
176 likely to have the credentials necessary for authentication.
177 However, when multiple proxies are used within the same
178 administrative domain, such as office and regional caching proxies
179 within a large corporate network, it is common for credentials to be
180 generated by the user agent and passed through the hierarchy until
181 consumed. Hence, in such a configuration, it will appear as if
182 Proxy-Authentication-Info is being forwarded because each proxy will
183 send the same field value.
185 5. Security Considerations
187 Adding information to HTTP responses that are sent over an
188 unencrypted channel can affect security and privacy. The presence of
189 the header fields alone indicates that HTTP authentication is in use.
190 Additional information could be exposed by the contents of the
191 authentication-scheme specific parameters; this will have to be
192 considered in the definitions of these schemes.
194 6. IANA Considerations
196 HTTP header fields are registered within the "Message Headers"
197 registry located at
198 , as defined by
199 [BCP90].
201 This document updates the definitions of the "Authentication-Info"
202 and "Proxy-Authentication-Info" header fields, so the "Permanent
203 Message Header Field Names" registry shall be updated accordingly:
205 +---------------------------+----------+----------+-----------------+
206 | Header Field Name | Protocol | Status | Reference |
207 +---------------------------+----------+----------+-----------------+
208 | Authentication-Info | http | standard | Section 3 of |
209 | | | | this document |
210 | Proxy-Authentication-Info | http | standard | Section 4 of |
211 | | | | this document |
212 +---------------------------+----------+----------+-----------------+
214 7. References
216 7.1. Normative References
218 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
219 Specifications: ABNF", STD 68, RFC 5234, January 2008,
220 .
222 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
223 Protocol (HTTP/1.1): Message Syntax and Routing",
224 RFC 7230, June 2014,
225 .
227 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
228 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014,
229 .
231 7.2. Informative References
233 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
234 Procedures for Message Header Fields", BCP 90, RFC 3864,
235 September 2004, .
237 [DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
238 Digest Access Authentication",
239 draft-ietf-httpauth-digest-15 (work in progress),
240 March 2015.
242 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
243 Leach, P., Luotonen, A., and L. Stewart, "HTTP
244 Authentication: Basic and Digest Access Authentication",
245 RFC 2617, June 1999,
246 .
248 Appendix A. Change Log (to be removed by RFC Editor before publication)
250 A.1. draft-reschke-httpauth-auth-info-00
252 Changed boilerplate to make this an HTTPbis WG draft. Added
253 Acknowledgements.
255 In the Security Considerations, remind people that those apply to
256 unencryped channels.
258 Make it clearer that these are really just response header fields.
260 A.2. Since draft-ietf-httpbis-auth-info-00
262 Rephrase introduction of header field to be closer to what RFC 2617
263 said ("successful authentication").
265 Update DIGEST reference.
267 A.3. Since draft-ietf-httpbis-auth-info-01
269 State that scheme definitions need to define whether the header field
270 can be used in trailers.
272 Add "updates: 2617" to boilerplate.
274 A.4. Since draft-ietf-httpbis-auth-info-02
276 Updated DIGEST reference.
278 Clarify purpose of header consistently
279 ().
281 The do-not-modify rule does not include proxies that consume
282 Authentication-Info
283 ().
285 Borrow more proxy auth related considerations from RFC 7235 for the
286 description of Proxy-Authentication-Info
287 ().
289 A.5. Since draft-ietf-httpbis-auth-info-03
291 Updated DIGEST reference.
293 Clarify how the applicable auth scheme is determined (it is present
294 in the request's (Proxy-)Authorization header field).
296 Adjust the IPR boilerplate because we are using some text from RFC
297 2617.
299 A.6. Since draft-ietf-httpbis-auth-info-04
301 Add another clarification about how the applicable scheme for Proxy-
302 Authentication-Info is determined.
304 Appendix B. Acknowledgements
306 This document is based on the header field definitions in RFCs 2069
307 and 2617, whose authors are: John Franks, Phillip M. Hallam-Baker,
308 Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen,
309 Eric W. Sink, and Lawrence C. Stewart.
311 Additional thanks go to the members of the HTTPAuth and HTTPbis
312 Working Groups, namely Amos Jeffries, Benjamin Kaduk, Alexey
313 Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and
314 Martin Thomson.
316 Author's Address
318 Julian F. Reschke
319 greenbytes GmbH
320 Hafenweg 16
321 Muenster, NW 48155
322 Germany
324 EMail: julian.reschke@greenbytes.de
325 URI: http://greenbytes.de/tech/webdav/