idnits 2.17.1
draft-ietf-httpbis-auth-info-02.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 lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 10, 2015) is 3361 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-13
-- 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 HTTPbis Working Group J. Reschke
3 Internet-Draft greenbytes
4 Updates: 2617 (if approved) February 10, 2015
5 Intended status: Standards Track
6 Expires: August 14, 2015
8 The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-
9 Authentication-Info Response Header Fields
10 draft-ietf-httpbis-auth-info-02
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 additional information
17 during or after authentication.
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.3.
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 August 14, 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 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
68 3. The Authentication-Info Response Header Field . . . . . . . . . 3
69 3.1. Parameter Value Format . . . . . . . . . . . . . . . . . . 3
70 4. The Proxy-Authentication-Info Response Header Field . . . . . . 4
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
76 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
77 Appendix A. Change Log (to be removed by RFC Editor before
78 publication) . . . . . . . . . . . . . . . . . . . . . 5
79 A.1. draft-reschke-httpauth-auth-info-00 . . . . . . . . . . . . 5
80 A.2. draft-ietf-httpbis-auth-info-00 . . . . . . . . . . . . . . 6
81 A.3. draft-ietf-httpbis-auth-info-01 . . . . . . . . . . . . . . 6
83 1. Introduction
85 This specification defines the "Authentication-Info" and "Proxy-
86 Authentication-Info" response header fields for use in HTTP
87 authentication schemes ([RFC7235]) which need to return additional
88 information during or after authentication.
90 Both were previously defined in Section 3 of [RFC2617], defining the
91 HTTP "Digest" authentication scheme. This document generalizes the
92 description for use not only in "Digest" ([DIGEST]), but also other
93 future schemes that might have the same requirements for carrying
94 additional information during authentication.
96 2. Notational Conventions
98 This specification uses the Augmented Backus-Naur Form (ABNF)
99 notation of [RFC5234] with a list extension, defined in Section 7 of
100 [RFC7230], that allows for compact definition of comma-separated
101 lists using a '#' operator (similar to how the '*' operator indicates
102 repetition). The ABNF production for "auth-param" is defined in
103 Section 2.1 of [RFC7235].
105 3. The Authentication-Info Response Header Field
107 HTTP authentication schemes can use the Authentication-Info response
108 header field to communicate additional information regarding the
109 successful authentication.
111 The field value is a list of parameters (name/value pairs), using the
112 "auth-param" syntax defined in Section 2.1 of [RFC7235]. This
113 specification only describes the generic format; authentication
114 schemes using "Authentication-Info" will define the individual
115 parameters. The "Digest" Authentication Scheme, for instance,
116 defines multiple parameters in Section 3.5 of [DIGEST].
118 Authentication-Info = #auth-param
120 The Authentication-Info header field can be used in any HTTP
121 response, independently of request method and status code. Its
122 semantics are defined by the applicable authentication scheme.
123 Intermediaries are not allowed to modify the field value in any way.
124 Authentication-Info can be used inside trailers ([RFC7230], Section
125 4.1.2) when the authentication scheme explicitly allows this.
127 3.1. Parameter Value Format
129 Parameter values can be expressed either as "token" or as "quoted-
130 string" (Section 3.2.6 of [RFC7230]).
132 Authentication scheme definitions need to allow both notations, both
133 for senders and recipients. This allows recipients to use generic
134 parsing components, independent of the authentication scheme in use.
136 For backwards compatibility, authentication scheme definitions can
137 restrict the format for senders to one of the two variants. This can
138 be important when it is known that deployed implementations will fail
139 when encountering one of the two formats.
141 4. The Proxy-Authentication-Info Response Header Field
143 The Proxy-Authentication-Info response header field is equivalent to
144 Authentication-Info, except that it applies to proxy authentication
145 ([RFC7235]):
147 Proxy-Authentication-Info = #auth-param
149 5. Security Considerations
151 Adding information to HTTP responses that are sent over an
152 unencrypted channel can affect security and privacy. The presence of
153 the header fields alone indicates that HTTP authentication is in use.
154 Additional information could be exposed by the contents of the
155 authentication-scheme specific parameters; this will have to be
156 considered in the definitions of these schemes.
158 6. IANA Considerations
160 HTTP header fields are registered within the "Message Headers"
161 registry located at
162 , as defined by
163 [BCP90].
165 This document updates the definitions of the "Authentication-Info"
166 and "Proxy-Authentication-Info" header fields, so the "Permanent
167 Message Header Field Names" registry shall be updated accordingly:
169 +---------------------------+----------+----------+-----------------+
170 | Header Field Name | Protocol | Status | Reference |
171 +---------------------------+----------+----------+-----------------+
172 | Authentication-Info | http | standard | Section 3 of |
173 | | | | this document |
174 | Proxy-Authentication-Info | http | standard | Section 4 of |
175 | | | | this document |
176 +---------------------------+----------+----------+-----------------+
178 7. Acknowledgements
180 This document is based on the header field definitions in RFCs 2069
181 and 2617, whose authors are: John Franks, Phillip M. Hallam-Baker,
182 Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen,
183 Eric W. Sink, and Lawrence C. Stewart.
185 Additional thanks go to the members of the HTTPAuth and HTTPbis
186 Working Groups, namely Amos Jeffries, Benjamin Kaduk, Alexey
187 Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and
188 Martin Thomson.
190 8. References
192 8.1. Normative References
194 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
195 Specifications: ABNF", STD 68, RFC 5234, January 2008.
197 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
198 Protocol (HTTP/1.1): Message Syntax and Routing",
199 RFC 7230, June 2014.
201 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
202 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
204 8.2. Informative References
206 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
207 Procedures for Message Header Fields", BCP 90, RFC 3864,
208 September 2004.
210 [DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
211 Digest Access Authentication",
212 draft-ietf-httpauth-digest-13 (work in progress),
213 February 2015.
215 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
216 Leach, P., Luotonen, A., and L. Stewart, "HTTP
217 Authentication: Basic and Digest Access Authentication",
218 RFC 2617, June 1999.
220 Appendix A. Change Log (to be removed by RFC Editor before publication)
222 A.1. draft-reschke-httpauth-auth-info-00
224 Changed boilerplate to make this an HTTPbis WG draft. Added
225 Acknowledgements.
227 In the Security Considerations, remind people that those apply to
228 unencryped channels.
230 Make it clearer that these are really just response header fields.
232 A.2. draft-ietf-httpbis-auth-info-00
234 Rephrase introduction of header field to be closer to what RFC 2617
235 said ("successful authentication").
237 Update DIGEST reference.
239 A.3. draft-ietf-httpbis-auth-info-01
241 State that scheme definitions need to define whether the header field
242 can be used in trailers.
244 Add "updates: 2617" to boilerplate.
246 Author's Address
248 Julian F. Reschke
249 greenbytes GmbH
250 Hafenweg 16
251 Muenster, NW 48155
252 Germany
254 EMail: julian.reschke@greenbytes.de
255 URI: http://greenbytes.de/tech/webdav/