One document matched: draft-ietf-httpbis-auth-info-05.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc updates="2617" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-auth-info-05" category="std">

  

	<front>
  <title abbrev="HTTP Authentication-Info">The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>
      <uri>http://greenbytes.de/tech/webdav/</uri>
    </address>
  </author>

  <date year="2015" month="April" day="7"/>

  <area>Applications</area>
  <workgroup>HTTP Working Group</workgroup>
  <keyword>HTTP</keyword>
  <keyword>authentication</keyword>

  <abstract>
    <t>
      This specification defines the "Authentication-Info" and
      "Proxy-Authentication-Info" response header fields for use in HTTP authentication
      schemes which need to return information once the client's
      authentication credentials have been accepted.
    </t>
  </abstract>

  <note title="Editorial Note (To be removed by RFC Editor)">
    <t>
      Discussion of this draft takes place on the HTTPBIS working group mailing list
      (ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    </t>
    <t>
      Working Group information can be found at <eref target="https://tools.ietf.org/wg/httpbis/"/>
      and <eref target="http://httpwg.github.io/"/>; source code and issues
      list for this draft can be found at
      <eref target="https://github.com/httpwg/http-extensions"/>.
    </t>
    <t>
      The changes in this draft are summarized in <xref target="since.04"/>.
    </t>
  </note>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
  This specification defines the "Authentication-Info" and
  "Proxy-Authentication-Info" response header fields for use in HTTP authentication
  schemes (<xref target="RFC7235"/>) which need to return
  information once the client's authentication credentials have been accepted.
</t>
<t>
  Both were previously defined in Section 3 of <xref target="RFC2617"/>, defining
  the HTTP "Digest" authentication scheme. This document generalizes
  the description for use not only in "Digest" (<xref target="DIGEST"/>), but
  also in other future schemes that might have the same requirements for carrying
  additional information during authentication.
</t>
</section>

<section anchor="notational.conventions" title="Notational Conventions">
  
<!--<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.
</t>-->
<t>
   This specification uses the Augmented Backus-Naur Form (ABNF) notation of
   <xref target="RFC5234"/> with a list extension, defined in
   Section 7 of <xref target="RFC7230"/>, that allows for compact definition of
   comma-separated lists using a '#' operator (similar to how the '*' operator
   indicates repetition).
   The ABNF production for "auth-param" is defined in Section 2.1 of <xref target="RFC7235"/>.
</t>
</section>

<section anchor="authentication-info" title="The Authentication-Info Response Header Field">
  
<t>
  HTTP authentication schemes can use the Authentication-Info response header
  field to communicate information after the client's authentication credentials have been accepted.
  This information can include a finalization message from the server (e.g., it can contain the
  server authentication).
</t>
<t>
  The field value is a list of parameters (name/value pairs), using the "auth-param"
  syntax defined in Section 2.1 of <xref target="RFC7235"/>.
  This specification only describes the generic format; authentication schemes
  using "Authentication-Info" will define the individual parameters. The "Digest"
  Authentication Scheme, for instance, defines multiple parameters in
  Section 3.5 of <xref target="DIGEST"/>.
</t>
<figure><artwork type="abnf2616"><![CDATA[
  Authentication-Info = #auth-param
]]></artwork></figure>
<t>
  The Authentication-Info header field can be used in any HTTP response,
  independently of request method and status code. Its semantics are defined
  by the authentication scheme indicated by the Authorization header field
  (<xref target="RFC7235"/>, Section 4.2)
  of the corresponding request.
</t>
<t>
  A proxy forwarding a response is not allowed to modify the field value in any
  way. 
</t>
<t>  
  Authentication-Info can be used inside trailers
  (<xref target="RFC7230"/>, Section 4.1.2) when the
  authentication scheme explicitly allows this.
</t>

<section title="Parameter Value Format">
<t>
  Parameter values can be expressed either as "token" or as "quoted-string"
  (Section 3.2.6 of <xref target="RFC7230"/>).
</t>
<t>
  Authentication scheme definitions need to allow both notations, both for
  senders and recipients. This allows recipients to use generic parsing
  components, independent of the authentication scheme in use.
</t>
<t>
  For backwards compatibility, authentication scheme definitions can restrict
  the format for senders to one of the two variants. This can be important
  when it is known that deployed implementations will fail when encountering
  one of the two formats.
</t>
</section>
</section>

<section anchor="proxy-authentication-info" title="The Proxy-Authentication-Info Response Header Field">
  
<t>
  The Proxy-Authentication-Info response header field is equivalent to
  Authentication-Info, except that its semantics are defined by the
  authentication scheme indicated by the Proxy-Authorization header field
  (<xref target="RFC7235"/>, Section 4.4)
  of the corresponding request, and applies to proxy authentication (<xref target="RFC7235"/>, Section 2):
</t>
<t>
<figure><artwork type="abnf2616"><![CDATA[
  Proxy-Authentication-Info = #auth-param
]]></artwork></figure>
</t>
<t>
  However, unlike Authentication-Info, the Proxy-Authentication-Info header
  field applies only to the next outbound client on the response chain. This is
  because only the client that chose a given proxy is likely to have the
  credentials necessary for authentication. However, when multiple proxies are
  used within the same administrative domain, such as office and regional
  caching proxies within a large corporate network, it is common for
  credentials to be generated by the user agent and passed through the
  hierarchy until consumed. Hence, in such a configuration, it will appear as
  if Proxy-Authentication-Info is being forwarded because each proxy will send
  the same field value.
</t>
</section>

<section anchor="security.considerations" title="Security Considerations">
<t>
  Adding information to HTTP responses that are sent over an unencrypted
  channel can affect security and privacy. The presence of the header fields
  alone indicates that HTTP authentication is in use. Additional information
  could be exposed by the contents of the authentication-scheme specific
  parameters; this will have to be considered in the definitions of these
  schemes.
</t>
</section>

<section anchor="iana.considerations" title="IANA Considerations">
<t>
   HTTP header fields are registered within the "Message Headers" registry
   located at <eref target="http://www.iana.org/assignments/message-headers"/>,
   as defined by <xref target="BCP90"/>.
</t>
<t>
   This document updates the definitions of the "Authentication-Info" and
   "Proxy-Authentication-Info" header fields,
   so the "Permanent Message Header Field Names" registry shall be updated
   accordingly:
</t>
<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
   <ttcol>Header Field Name</ttcol>
   <ttcol>Protocol</ttcol>
   <ttcol>Status</ttcol>
   <ttcol>Reference</ttcol>

   <c>Authentication-Info</c>
   <c>http</c>
   <c>standard</c>
   <c>
    <xref target="authentication-info"/> of this document
   </c>
   <c>Proxy-Authentication-Info</c>
   <c>http</c>
   <c>standard</c>
   <c>
    <xref target="proxy-authentication-info"/> of this document
   </c>
</texttable>
</section>

  </middle>
  <back>

<references title="Normative References">

<!--<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>-->

<reference anchor="RFC5234" target="http://www.rfc-editor.org/info/rfc5234">
  <front>
    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"/>
    <author initials="P." surname="Overell" fullname="Paul Overell"/>
    <date month="January" year="2008"/>
  </front>
  <seriesInfo name="STD" value="68"/>
  <seriesInfo name="RFC" value="5234"/>
</reference>

<reference anchor="RFC7230" target="http://www.rfc-editor.org/info/rfc7230">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7230"/>
  
</reference>

<reference anchor="RFC7235" target="http://www.rfc-editor.org/info/rfc7235">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"/>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7235"/>
  
</reference>


<!--<reference anchor="RFC7231">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7231"/>
  <x:source href="rfc7231.xml" basename="rfc7231"/>
</reference>-->

</references>

<references title="Informative References">

<reference anchor="BCP90" target="http://www.rfc-editor.org/info/rfc3864">
  <front>
    <title>Registration Procedures for Message Header Fields</title>
    <author initials="G." surname="Klyne" fullname="G. Klyne"/>
    <author initials="M." surname="Nottingham" fullname="M. Nottingham"/>
    <author initials="J." surname="Mogul" fullname="J. Mogul"/>
    <date year="2004" month="September"/>
  </front>
  <seriesInfo name="BCP" value="90"/>
  <seriesInfo name="RFC" value="3864"/>
</reference>

<reference anchor="RFC2617" target="http://www.rfc-editor.org/info/rfc2617">
  <front>
    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
    <author initials="J." surname="Franks" fullname="John Franks"/>
    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"/>
    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"/>
    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"/>
    <author initials="P.J." surname="Leach" fullname="Paul J. Leach"/>
    <author initials="A." surname="Luotonen" fullname="Ari Luotonen"/>
    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"/>
    <date month="June" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2617"/>
</reference>

<reference anchor="DIGEST">
  <front>
    <title>HTTP Digest Access Authentication</title>
    <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef" role="editor"/>
    <author initials="D." surname="Ahrens" fullname="David Ahrens"/>
    <author initials="S." surname="Bremer" fullname="Sophie Bremer"/>
    <date month="March" year="2015"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpauth-digest-15"/>
</reference>

</references>

<section anchor="change.log" title="Change Log (to be removed by RFC Editor before publication)">

<section title="draft-reschke-httpauth-auth-info-00">
<t>
  Changed boilerplate to make this an HTTPbis WG draft. Added Acknowledgements.
</t>
<t>
  In the Security Considerations, remind people that those apply to unencryped
  channels.
</t>
<t>
  Make it clearer that these are really just response header fields.
</t>
</section>

<section anchor="since.00" title="Since draft-ietf-httpbis-auth-info-00">
<t>
  Rephrase introduction of header field to be closer to what RFC 2617
  said ("successful authentication").
</t>
<t>
  Update DIGEST reference.
</t>
</section>
<section anchor="since.01" title="Since draft-ietf-httpbis-auth-info-01">
<t>
  State that scheme definitions need to define whether the header field can
  be used in trailers.
</t>
<t>
  Add "updates: 2617" to boilerplate.
</t>
</section>
<section anchor="since.02" title="Since draft-ietf-httpbis-auth-info-02">
<t>
  Updated DIGEST reference.
</t>
<t>
  Clarify purpose of header consistently (<eref target="https://github.com/httpwg/http-extensions/issues/49"/>).
</t>
<t>
  The do-not-modify rule does not include proxies that consume Authentication-Info (<eref target="https://github.com/httpwg/http-extensions/issues/50"/>).
</t>
<t>
  Borrow more proxy auth related considerations from RFC 7235 for the description of Proxy-Authentication-Info (<eref target="https://github.com/httpwg/http-extensions/issues/51"/>).
</t>
</section>
<section anchor="since.03" title="Since draft-ietf-httpbis-auth-info-03">
<t>
  Updated DIGEST reference.
</t>
<t>
  Clarify how the applicable auth scheme is determined (it is present
  in the request's (Proxy-)Authorization header field).
</t>
<t>
  Adjust the IPR boilerplate because we are using some text from RFC 2617.
</t>
</section>
<section anchor="since.04" title="Since draft-ietf-httpbis-auth-info-04">
<t>
  Add another clarification about how the applicable scheme for Proxy-Authentication-Info 
  is determined.
</t>
</section>
</section>

<section title="Acknowledgements">
<t>
  This document is based on the header field definitions in RFCs 2069 and 2617,
  whose authors are: John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler,
  Scott D. Lawrence, Paul J. Leach, Ari Luotonen, Eric W. Sink, and
  Lawrence C. Stewart.
</t>
<t>
  Additional thanks go to the members of the HTTPAuth and HTTPbis
  Working Groups, namely Amos Jeffries, Benjamin Kaduk, Alexey Melnikov,
  Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and Martin Thomson.
</t>
</section>

  </back>

</rfc>