One document matched: draft-reschke-httpauth-auth-info-00.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 ipr="trust200902" docName="draft-reschke-httpauth-auth-info-00" category="std">

  

	<front>
  <title abbrev="HTTP Authentication-Info">The Hypertext Transfer Protocol (HTTP) Authentication-Info Header Field</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="January" day="24"/>
  
  <area>Security</area>
  <keyword>HTTP</keyword>
  <keyword>authentication</keyword>

<abstract>
<t>
  This specification defines the "Authentication-Info" and
  "Proxy-Authentication-Info" 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 before publication)">
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPAuth Working Group, comments should be sent to the 
      HTTPAuth mailing list (http-auth@ietf.org), which is archived at
      <eref target="http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html"/>.
    </t>
    <t>
      XML versions and latest edits for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-httpauth-auth-info"/>.
    </t>
  </note>


  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
  This specification defines the "Authentication-Info" and
  "Proxy-Authentication-Info" 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 Header Field">
  
<t>
  HTTP authentication schemes can use the Authentication-Info response header
  field to return additional information applicable to the authentication
  currently in use. 
</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.1 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).
</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 Header Field">
  
<t>
  The Proxy-Authentication-Info 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 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">
  <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="January" year="2015"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpauth-digest-12"/>
</reference>
  
</references>

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

<section title="draft-reschke-http-cice-00">
<t>
  Clarified that the information returned in Accept-Encoding is per resource, not per server.
</t>
<t>
  Added some deployment considerations.
</t>
<t>
  Updated HTTP/1.1 references.
</t>
</section>
</section>-->
  </back>

</rfc>