One document matched: draft-ietf-httpbis-auth-info-02.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="trust200902" docName="draft-ietf-httpbis-auth-info-02" 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="February" day="10"/>
  
  <area>Applications</area>
  <workgroup>HTTPbis 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 additional information during or after
      authentication.
    </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.01"/>.
    </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 additional
  information during or after authentication.
</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 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 additional information regarding the successful 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 applicable authentication scheme. Intermediaries are not allowed
  to modify the field value in any way. 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 it applies to proxy authentication (<xref target="RFC7235"/>):
</t>
<t>
<figure><artwork type="abnf2616"><![CDATA[
  Proxy-Authentication-Info = #auth-param
]]></artwork></figure>
</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>

<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>

  </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">
  <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">
  <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">
  <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">
  <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">
  <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="February" year="2015"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpauth-digest-13"/>
</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="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="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>
  </back>

</rfc>