idnits 2.17.1 draft-ietf-httpbis-auth-info-04.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 (March 11, 2015) is 3331 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) March 11, 2015 5 Intended status: Standards Track 6 Expires: September 12, 2015 8 The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- 9 Authentication-Info Response Header Fields 10 draft-ietf-httpbis-auth-info-04 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.5. 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 September 12, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 89 Appendix A. Change Log (to be removed by RFC Editor before 90 publication) . . . . . . . . . . . . . . . . . . . . . 6 91 A.1. draft-reschke-httpauth-auth-info-00 . . . . . . . . . . . . 6 92 A.2. draft-ietf-httpbis-auth-info-00 . . . . . . . . . . . . . . 6 93 A.3. draft-ietf-httpbis-auth-info-01 . . . . . . . . . . . . . . 6 94 A.4. draft-ietf-httpbis-auth-info-02 . . . . . . . . . . . . . . 6 95 A.5. draft-ietf-httpbis-auth-info-03 . . . . . . . . . . . . . . 7 97 1. Introduction 99 This specification defines the "Authentication-Info" and "Proxy- 100 Authentication-Info" response header fields for use in HTTP 101 authentication schemes ([RFC7235]) which need to return information 102 once the client's authentication credentials have been accepted. 104 Both were previously defined in Section 3 of [RFC2617], defining the 105 HTTP "Digest" authentication scheme. This document generalizes the 106 description for use not only in "Digest" ([DIGEST]), but also in 107 other future schemes that might have the same requirements for 108 carrying additional information during authentication. 110 2. Notational Conventions 112 This specification uses the Augmented Backus-Naur Form (ABNF) 113 notation of [RFC5234] with a list extension, defined in Section 7 of 114 [RFC7230], that allows for compact definition of comma-separated 115 lists using a '#' operator (similar to how the '*' operator indicates 116 repetition). The ABNF production for "auth-param" is defined in 117 Section 2.1 of [RFC7235]. 119 3. The Authentication-Info Response Header Field 121 HTTP authentication schemes can use the Authentication-Info response 122 header field to communicate information after the client's 123 authentication credentials have been accepted. This information can 124 include a finalization message from the server (e.g., it can contain 125 the server authentication). 127 The field value is a list of parameters (name/value pairs), using the 128 "auth-param" syntax defined in Section 2.1 of [RFC7235]. This 129 specification only describes the generic format; authentication 130 schemes using "Authentication-Info" will define the individual 131 parameters. The "Digest" Authentication Scheme, for instance, 132 defines multiple parameters in Section 3.5 of [DIGEST]. 134 Authentication-Info = #auth-param 136 The Authentication-Info header field can be used in any HTTP 137 response, independently of request method and status code. Its 138 semantics are defined by the authentication scheme indicated by the 139 Authorization header field of the corresponding request. 141 A proxy forwarding a response is not allowed to modify the field 142 value in any way. 144 Authentication-Info can be used inside trailers ([RFC7230], Section 145 4.1.2) when the authentication scheme explicitly allows this. 147 3.1. Parameter Value Format 149 Parameter values can be expressed either as "token" or as "quoted- 150 string" (Section 3.2.6 of [RFC7230]). 152 Authentication scheme definitions need to allow both notations, both 153 for senders and recipients. This allows recipients to use generic 154 parsing components, independent of the authentication scheme in use. 156 For backwards compatibility, authentication scheme definitions can 157 restrict the format for senders to one of the two variants. This can 158 be important when it is known that deployed implementations will fail 159 when encountering one of the two formats. 161 4. The Proxy-Authentication-Info Response Header Field 163 The Proxy-Authentication-Info response header field is equivalent to 164 Authentication-Info, except that it applies to proxy authentication 165 ([RFC7235]): 167 Proxy-Authentication-Info = #auth-param 169 However, unlike Authentication-Info, the Proxy-Authentication-Info 170 header field applies only to the next outbound client on the response 171 chain. This is because only the client that chose a given proxy is 172 likely to have the credentials necessary for authentication. 173 However, when multiple proxies are used within the same 174 administrative domain, such as office and regional caching proxies 175 within a large corporate network, it is common for credentials to be 176 generated by the user agent and passed through the hierarchy until 177 consumed. Hence, in such a configuration, it will appear as if 178 Proxy-Authentication-Info is being forwarded because each proxy will 179 send the same field value. 181 5. Security Considerations 183 Adding information to HTTP responses that are sent over an 184 unencrypted channel can affect security and privacy. The presence of 185 the header fields alone indicates that HTTP authentication is in use. 186 Additional information could be exposed by the contents of the 187 authentication-scheme specific parameters; this will have to be 188 considered in the definitions of these schemes. 190 6. IANA Considerations 192 HTTP header fields are registered within the "Message Headers" 193 registry located at 194 , as defined by 195 [BCP90]. 197 This document updates the definitions of the "Authentication-Info" 198 and "Proxy-Authentication-Info" header fields, so the "Permanent 199 Message Header Field Names" registry shall be updated accordingly: 201 +---------------------------+----------+----------+-----------------+ 202 | Header Field Name | Protocol | Status | Reference | 203 +---------------------------+----------+----------+-----------------+ 204 | Authentication-Info | http | standard | Section 3 of | 205 | | | | this document | 206 | Proxy-Authentication-Info | http | standard | Section 4 of | 207 | | | | this document | 208 +---------------------------+----------+----------+-----------------+ 210 7. Acknowledgements 212 This document is based on the header field definitions in RFCs 2069 213 and 2617, whose authors are: John Franks, Phillip M. Hallam-Baker, 214 Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, 215 Eric W. Sink, and Lawrence C. Stewart. 217 Additional thanks go to the members of the HTTPAuth and HTTPbis 218 Working Groups, namely Amos Jeffries, Benjamin Kaduk, Alexey 219 Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and 220 Martin Thomson. 222 8. References 224 8.1. Normative References 226 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 227 Specifications: ABNF", STD 68, RFC 5234, January 2008. 229 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 230 Protocol (HTTP/1.1): Message Syntax and Routing", 231 RFC 7230, June 2014. 233 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 234 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 236 8.2. Informative References 238 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 239 Procedures for Message Header Fields", BCP 90, RFC 3864, 240 September 2004. 242 [DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 243 Digest Access Authentication", 244 draft-ietf-httpauth-digest-15 (work in progress), 245 March 2015. 247 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 248 Leach, P., Luotonen, A., and L. Stewart, "HTTP 249 Authentication: Basic and Digest Access Authentication", 250 RFC 2617, June 1999. 252 Appendix A. Change Log (to be removed by RFC Editor before publication) 254 A.1. draft-reschke-httpauth-auth-info-00 256 Changed boilerplate to make this an HTTPbis WG draft. Added 257 Acknowledgements. 259 In the Security Considerations, remind people that those apply to 260 unencryped channels. 262 Make it clearer that these are really just response header fields. 264 A.2. draft-ietf-httpbis-auth-info-00 266 Rephrase introduction of header field to be closer to what RFC 2617 267 said ("successful authentication"). 269 Update DIGEST reference. 271 A.3. draft-ietf-httpbis-auth-info-01 273 State that scheme definitions need to define whether the header field 274 can be used in trailers. 276 Add "updates: 2617" to boilerplate. 278 A.4. draft-ietf-httpbis-auth-info-02 280 Updated DIGEST reference. 282 Clarify purpose of header consistently 283 (). 285 The do-not-modify rule does not include proxies that consume 286 Authentication-Info 287 (). 289 Borrow more proxy auth related considerations from RFC 7235 for the 290 description of Proxy-Authentication-Info 291 (). 293 A.5. draft-ietf-httpbis-auth-info-03 295 Updated DIGEST reference. 297 Clarify how the applicable auth scheme is determined (it is present 298 in the request's (Proxy-)Authorization header field). 300 Adjust the IPR boilerplate because we are using some text from RFC 301 2617. 303 Author's Address 305 Julian F. Reschke 306 greenbytes GmbH 307 Hafenweg 16 308 Muenster, NW 48155 309 Germany 311 EMail: julian.reschke@greenbytes.de 312 URI: http://greenbytes.de/tech/webdav/