idnits 2.17.1 draft-reschke-httpauth-auth-info-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2015) is 3380 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-12 -- 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Standards Track January 24, 2015 5 Expires: July 28, 2015 7 The Hypertext Transfer Protocol (HTTP) Authentication-Info Header Field 8 draft-reschke-httpauth-auth-info-00 10 Abstract 12 This specification defines the "Authentication-Info" and "Proxy- 13 Authentication-Info" header fields for use in HTTP authentication 14 schemes which need to return additional information during or after 15 authentication. 17 Editorial Note (To be removed by RFC Editor before publication) 19 Distribution of this document is unlimited. Although this is not a 20 work item of the HTTPAuth Working Group, comments should be sent to 21 the HTTPAuth mailing list (http-auth@ietf.org), which is archived at 22 . 25 XML versions and latest edits for this document are available from 26 . 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 28, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 64 3. The Authentication-Info Header Field . . . . . . . . . . . . . 3 65 3.1. Parameter Value Format . . . . . . . . . . . . . . . . . . 3 66 4. The Proxy-Authentication-Info Header Field . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 This specification defines the "Authentication-Info" and "Proxy- 76 Authentication-Info" header fields for use in HTTP authentication 77 schemes ([RFC7235]) which need to return additional information 78 during or after authentication. 80 Both were previously defined in Section 3 of [RFC2617], defining the 81 HTTP "Digest" authentication scheme. This document generalizes the 82 description for use not only in "Digest" ([DIGEST]), but also other 83 future schemes that might have the same requirements for carrying 84 additional information during authentication. 86 2. Notational Conventions 88 This specification uses the Augmented Backus-Naur Form (ABNF) 89 notation of [RFC5234] with a list extension, defined in Section 7 of 90 [RFC7230], that allows for compact definition of comma-separated 91 lists using a '#' operator (similar to how the '*' operator indicates 92 repetition). The ABNF production for "auth-param" is defined in 93 Section 2.1 of [RFC7235]. 95 3. The Authentication-Info Header Field 97 HTTP authentication schemes can use the Authentication-Info response 98 header field to return additional information applicable to the 99 authentication currently in use. 101 The field value is a list of parameters (name/value pairs), using the 102 "auth-param" syntax defined in Section 2.1 of [RFC7235]. This 103 specification only describes the generic format; authentication 104 schemes using "Authentication-Info" will define the individual 105 parameters. The "Digest" Authentication Scheme, for instance, 106 defines multiple parameters in Section 3.5.1 of [DIGEST]. 108 Authentication-Info = #auth-param 110 The Authentication-Info header field can be used in any HTTP 111 response, independently of request method and status code. Its 112 semantics are defined by the applicable authentication scheme. 113 Intermediaries are not allowed to modify the field value in any way. 114 Authentication-Info can be used inside trailers ([RFC7230], Section 115 4.1.2). 117 3.1. Parameter Value Format 119 Parameter values can be expressed either as "token" or as "quoted- 120 string" (Section 3.2.6 of [RFC7230]). 122 Authentication scheme definitions need to allow both notations, both 123 for senders and recipients. This allows recipients to use generic 124 parsing components, independent of the authentication scheme in use. 126 For backwards compatibility, authentication scheme definitions can 127 restrict the format for senders to one of the two variants. This can 128 be important when it is known that deployed implementations will fail 129 when encountering one of the two formats. 131 4. The Proxy-Authentication-Info Header Field 133 The Proxy-Authentication-Info header field is equivalent to 134 Authentication-Info, except that it applies to proxy authentication 135 ([RFC7235]): 137 Proxy-Authentication-Info = #auth-param 139 5. Security Considerations 141 Adding information to HTTP responses can affect security and privacy. 142 The presence of the header fields alone indicates that HTTP 143 authentication is in use. Additional information could be exposed by 144 the contents of the authentication-scheme specific parameters; this 145 will have to be considered in the definitions of these schemes. 147 6. IANA Considerations 149 HTTP header fields are registered within the "Message Headers" 150 registry located at 151 , as defined by 152 [BCP90]. 154 This document updates the definitions of the "Authentication-Info" 155 and "Proxy-Authentication-Info" header fields, so the "Permanent 156 Message Header Field Names" registry shall be updated accordingly: 158 +---------------------------+----------+----------+-----------------+ 159 | Header Field Name | Protocol | Status | Reference | 160 +---------------------------+----------+----------+-----------------+ 161 | Authentication-Info | http | standard | Section 3 of | 162 | | | | this document | 163 | Proxy-Authentication-Info | http | standard | Section 4 of | 164 | | | | this document | 165 +---------------------------+----------+----------+-----------------+ 167 7. References 168 7.1. Normative References 170 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 171 Specifications: ABNF", STD 68, RFC 5234, January 2008. 173 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 174 Protocol (HTTP/1.1): Message Syntax and Routing", 175 RFC 7230, June 2014. 177 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 178 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 180 7.2. Informative References 182 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 183 Procedures for Message Header Fields", BCP 90, RFC 3864, 184 September 2004. 186 [DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 187 Digest Access Authentication", 188 draft-ietf-httpauth-digest-12 (work in progress), 189 January 2015. 191 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 192 Leach, P., Luotonen, A., and L. Stewart, "HTTP 193 Authentication: Basic and Digest Access Authentication", 194 RFC 2617, June 1999. 196 Author's Address 198 Julian F. Reschke 199 greenbytes GmbH 200 Hafenweg 16 201 Muenster, NW 48155 202 Germany 204 EMail: julian.reschke@greenbytes.de 205 URI: http://greenbytes.de/tech/webdav/