<?xml version="1.0" encoding="iso-8859-1"?>
<?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"?>
<?rfc-ext allow-markup-in-artwork="yes" ?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
]> SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902"
     docName="draft-ietf-sipcore-digest-scheme-15" category="std"
     xml:lang="en"
     updates="3261"> updates="3261" tocInclude="true" symRefs="true"
     sortRefs="true" version="3" number="8760" consensus="true"
     submissionType="IETF">

  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- ********************************** FRONT ********************************** -->
<front>
    <title abbrev="SIP Digest Authentication">
         The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
    </title>
    <seriesInfo name="RFC" value="8760"/>
    <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef">
      <organization>Avaya</organization>
      <address>
        <postal>
          <street>425 Legget Dr.</street>
          <city>Ottawa</city>
          <region>Ontario</region>
          <country>Canada</country>
        </postal>
        <phone>+1-613-595-9106</phone>
        <email>rifaat.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2019" /> month="March" year="2020"/>
    <area>RAI</area>
    <workgroup>SIP Core</workgroup>
    <keyword>Digest Auth</keyword>

  <abstract><t>
    <abstract>

<!--[rfced]] *ADs - please review and approve the following changes
    submitted by the author during EDIT state to use "SHA-512/256"
    instead of "SHA-512-256" (affects 3 sentences in the document).

*Follow-up question:  Also, please review the other
occurrence of "SHA-512-256" (in code) and
let us know if any further updates are necessary (based on use in RFCs
4868 and 7616, we believe the dash is correct in this case).

Original:

... for more secure digest algorithms, e.g., SHA-256 and SHA-512-256, to replace the...

Edited:
 ...for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to
 replace the...

Original:
...resulting from that reference update. It adds support for the SHA-256 and SHA-512-256 algorithms...

Edited:
...resulting from that reference update. It adds support for the
SHA-256 and SHA-512/256 algorithms...

Original:
...representation of 1111 as 'f'. If the SHA-256 or SHA-512-256
algorithm is...

Edited:
...representation of 1111 as 'f'. If the SHA-256 or SHA-512/256 algorithm is...
-->

      <t>
   This document updates RFC 3261 by updating modifying the Digest Access
   Authentication scheme used by the Session Initiation Protocol (SIP) to add support
   for more secure digest algorithms, e.g., SHA-256 and SHA-512-256, SHA-512/256, to replace the
   obsolete MD5 algorithm.
  </t></abstract>

      </t>
    </abstract>
  </front>
  <!-- ********************************** MIDDLE ********************************** -->
<middle>
    <section title="Introduction" anchor="introduction">
      <name>Introduction</name>
      <t>
    The Session Initiation Protocol <xref target="RFC3261"/> uses the same mechanism
    that
    as the Hypertext Transfer Protocol (HTTP) uses does for authenticating
    users. This mechanism is called Digest &quot;Digest Access Authentication, and
    it Authentication&quot;. It is a simple challenge-response mechanism that allows a server
    to challenge a client request and allows a client to provide
    authentication information in response to that challenge. The
    version of Digest Access Authentication that <xref target="RFC3261"/> references
    is specified in <xref target="RFC2617"/>.
      </t>
      <t>
    The default hash algorithm for Digest Access Authentication is MD5.
    However, it has been demonstrated that the MD5 algorithm is not
    collision resistant, resistant and is now considered a bad choice for a hash
    function (see <xref target="RFC6151"/>. target="RFC6151"/>).
      </t>
      <t>
    The HTTP Digest Access Authentication document <xref target="RFC7616"/> document obsoletes
    [RFC2617]
    <xref target="RFC2617"/> and adds stronger algorithms that can be used with
    the Digest Access Authentication scheme, scheme and establishes a registry for
    these algorithms, known as the "Hash Algorithms for HTTP Digest
    Authentication" IANA registry, so that algorithms can be added in the
    future.
      </t>
      <t>
    This document updates the Digest Access Authentication scheme used
    by SIP to support the algorithms listed in the "Hash Algorithms
    for HTTP Digest Authentication" IANA registry defined by <xref target="RFC7616"/>.
      </t>

  <t> <vspace blankLines="1" /> </t>

      <section title="Terminology" anchor="terminology">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    <t> <vspace blankLines="1" /> </t>
      </section>
    </section>

    <!-- Introduction -->

  <section title="SIP anchor="sip.digest.scheme">
      <name>Updates to the SIP Digest Access Authentication Scheme Updates"
           anchor="sip.digest.scheme"> Scheme</name>
      <t>
    This section describes the modifications to the operation of the
    Digest mechanism as specified in <xref target="RFC3261"/> in order to support
    the algorithms defined in the "Hash Algorithms for HTTP Digest Authentication"
    IANA registry described in <xref target="RFC7616"/>.
      </t>
      <t>
    It replaces the reference used in <xref target="RFC3261"/> for Digest Access Authentication,
    substituting <xref target="RFC7616"/> for the obsolete <xref target="RFC2617"/>, and describes
    the modifications to the usage of the Digest mechanism in <xref target="RFC3261"/>
    resulting from that reference update. It adds support for the SHA-256 and SHA-512-256 SHA-512/256 algorithms <xref target="SHA2"/>.
    It adds required support for the "qop" parameter. It provides additional User Agent Client (UAC)
    and User Agent Server (UAS) procedures regarding usage of multiple SIP Authorization,
    WWW-Authenticate
    WWW-Authenticate, and Proxy-Authenticate header fields, including the order
    in which order to insert
    and process them. It provides guidance regarding forking. Finally, it updates the SIP BNF ABNF
    as required by the updates.
      </t>

  <t> <vspace blankLines="1" /> </t>
      <section title="Hash Algorithms" anchor="hash.algorithms">
        <name>Hash Algorithms</name>
        <t>
      The Digest Access Authentication scheme has an 'algorithm' "algorithm" parameter that specifies the
      algorithm to be used to compute the digest of the response. The IANA
      registry named the "Hash
      Algorithms for HTTP Digest Authentication" IANA registry specifies
      the algorithms that correspond to 'algorithm' values.
        </t>
        <t>
      <xref target="RFC3261"/> specifies only one algorithm, MD5, which is used by default.
      This document extends <xref target="RFC3261"/> to allow use of any algorithm listed in
      the "Hash Algorithms for HTTP Digest Authentication" IANA registry.
        </t>
        <t>
     A UAS prioritizes which algorithm to use based on its policy,
     which is specified in section 2.3 <xref target="uas.behavior" /> and parallels the process used in
     HTTP specified by <xref target="RFC7616"/>.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>
      <!-- Hash Algorithms -->

    <section title="Representation anchor="rep.digest.values">
        <name>Representation of Digest Values" anchor="rep.digest.values"> Values</name>
        <t>
      The size of the digest depends on the algorithm used.  The bits in
      the digest are converted from the most significant to the least
      significant bit, four bits at a time time, to the ASCII representation as
      follows. Each set of four bits is represented by its familiar hexadecimal
      notation from the characters 0123456789abcdef, 0123456789abcdef; that is is, binary 0000 is
      represented by the character '0', 0001 is represented by '1' '1', and so on up to the
      representation of 1111 as 'f'. If the SHA-256 or SHA-512-256 SHA-512/256 algorithm is
      used to calculate the digest, then the digest will be represented as 64
      hexadecimal characters.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>
      <section title="UAS Behavior" anchor="uas.behavior">
        <name>UAS Behavior</name>

        <t>
      When a UAS receives a request from a UAC, and an acceptable
      Authorization header field is not received, the UAS can challenge the
      originator to provide credentials by rejecting the request with a
      401/407 status code with the WWW-Authenticate/Proxy-Authenticate
      header field field, respectively. The UAS MAY <bcp14>MAY</bcp14> add multiple WWW-Authenticate/Proxy-Authenticate
      header fields to allow the UAS to utilize the best available
      algorithm supported by the client.
        </t>
        <t>
      If the UAS challenges with the originator using multiple WWW-Authenticate/Proxy-Authenticate
      header fields with the same realm, then each one of these
      header fields MUST <bcp14>MUST</bcp14> use a different digest algorithm. The UAS MUST <bcp14>MUST</bcp14> add these
      header fields to the response in the order that in which it would prefer to see them
      used, starting with the most preferred algorithm at the top, followed
      by the less preferred algorithms. top. The UAS cannot assume that the client
      will use the algorithm specified at in the topmost header field.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>
      <section title="UAC Behavior" anchor="uac.behavior">
        <name>UAC Behavior</name>
<t>      When the UAC receives a response with multiple WWW-Authenticate/Proxy-Authenticate
      header fields with the same realm realm, it SHOULD <bcp14>SHOULD</bcp14> use the topmost
      header field that it supports, supports unless a local policy dictates otherwise.
      The client MUST <bcp14>MUST</bcp14> ignore any challenge it does not understand.
        </t>
        <t>
      When the UAC receives a 401 response with multiple WWW-Authenticate
      header fields with different realms realms, it SHOULD <bcp14>SHOULD</bcp14> retry and add an
      Authorization header field containing credentials that match the topmost
      header field of any one of the realms, realms unless a local policy dictates otherwise.
        </t>
        <t>
    If the UAC cannot respond to any of the challenges in the response,
    then it SHOULD <bcp14>SHOULD</bcp14> abandon attempts to send the request, request unless a local
    policy dictates otherwise, e.g. e.g., the policy might indicate the use of non-Digest mechanisms.
    For example, if the UAC does not have credentials or has stale credentials for
    any of the realms, the UAC will abandon the request.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>
      <section title="Forking" anchor="forking">
        <name>Forking</name>
        <t>
      Section 22.3 of
      <xref target="RFC3261"/> target="RFC3261" sectionFormat="of" section="22.3"/> discusses the operation of the proxy-to-user
      authentication, which describes the operation of the proxy when it
      forks a request. This section clarifies that operation.
        </t>
        <t>
      If a request is forked, various proxy servers and/or UAs may wish to
      challenge the UAC. In this case, the forking proxy server is
      responsible for aggregating these challenges into a single response.
      Each WWW-Authenticate and Proxy-Authenticate value received in
      responses
      response to the forked request MUST <bcp14>MUST</bcp14> be placed into the single
      response that is sent by the forking proxy to the UAC.
        </t>
        <t>
    When the forking proxy places multiple WWW-Authenticate and Proxy-Authenticate header
    fields received from one downstream proxy into a single response, it MUST <bcp14>MUST</bcp14> maintain
    the order of these header fields.  The ordering of values received from different downstream
    proxies is not significant.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>
      <!-- Forking -->

    <section title="HTTP anchor="http.modifications">
        <name>HTTP Digest Authentication Scheme Modifications" anchor="http.modifications"> Modifications</name>
        <t>
      This section describes the modifications and clarifications required
      to apply the HTTP Digest authentication Access Authentication scheme to SIP. The SIP scheme
      usage is similar to that for HTTP. For completeness, the bullets specified
      below are mostly copied from section 22.4 of <xref target="RFC3261"/>; target="RFC3261"
      sectionFormat="of" section="22.4"/>; the
      only semantic changes are specified in bullets 1, 7, and 8 below.
        </t>
        <t>
      SIP clients and servers MUST NOT <bcp14>MUST NOT</bcp14> accept or request Basic
      authentication.
        </t>
        <t>
      The rules for Digest authentication Access Authentication follow those defined in HTTP,
      with "HTTP/1.1" <xref target="RFC7616"/> replaced by "SIP/2.0" in addition to the following
      differences:
        </t>
<ol>
    <li>

    <t>
      1.
The URI included in the challenge has the following BNF ABNF <xref target="RFC5234"/>:
    <list><t>
    </t>
<sourcecode name="" type="abnf"><![CDATA[
      URI  =  Request-URI ; as defined in <xref target="RFC3261"/>, RFC 3261, Section 25
    </t></list>
    </t>

    <t>
      2.
]]></sourcecode>
    </li>
<li>
The 'uri' "uri" parameter of the Authorization header field MUST <bcp14>MUST</bcp14> be
         enclosed in quotation marks.
    </t>

    <t>
      3.
</li>
<li><t>
The BNF ABNF for digest-uri-value is:
    <list><t> is:</t>
<sourcecode name="" type="abnf"><![CDATA[
         digest-uri-value  =  Request-URI
    </t></list>
    </t>

    <t>
      4.
]]></sourcecode>
</li>
<li>
The example procedure for choosing a nonce based on Etag ETag does not
         work for SIP.
    </t>

    <t>
      5.
</li>
<li>
The text in <xref target="RFC7234"/> regarding cache operation does not
         apply to SIP.
    </t>

    <t>
      6.
        </li>
        <li>
<xref target="RFC7616"/> requires that a server check that the URI in the
          request line and the URI included in the Authorization header
          field point to the same resource.  In a SIP context, these two
          URIs may refer to different users, users due to forwarding at some
          proxy.  Therefore, in SIP, a UAS MUST <bcp14>MUST</bcp14> check if the Request-URI in the
          Authorization/Proxy-Authorization header field value corresponds to a
          user for whom the UAS is willing to accept forwarded or direct
          requests, but MAY
          requests; however, it <bcp14>MAY</bcp14> still accept it if the two fields are not equivalent.
    </t>

    <t>
      7.  As
        </li>
	 <li>
<t>As a clarification to the calculation of the A2 value for
	   message integrity assurance in the Digest authentication Access Authentication
	   scheme, implementers should assume, when the entity-body is
          empty (that is, when SIP messages have no body) assume that the hash of the entity-body
resolves to the hash of an empty
          string:

    <list><t> string when the entity-body is empty (that
is, when SIP messages have no body):</t>

<sourcecode name="" type=""><![CDATA[
 H(entity-body) = &lt;algorithm>("")
    </t></list>
              For <algorithm>("")
]]></sourcecode>
<t>For example, when the chosen algorithm is SHA-256, then:
    <list><t> then:</t>

<sourcecode name="" type=""><![CDATA[
 H(entity-body) = SHA-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    </t></list>
    </t>
]]> </sourcecode>
</li>
<li>
<t>
      8.
A UAS MUST <bcp14>MUST</bcp14> be able to properly handle a "qop" parameter received
         in an Authorization/Proxy-Authorization header field, and a UAC MUST <bcp14>MUST</bcp14> be able to
         properly handle a "qop" parameter received in WWW-Authenticate and
         Proxy-Authenticate header fields. However, for backward compatibility
         reasons, the "qop" parameter is optional for RFC3261-based clients and
	 servers based on <xref target="RFC3261" /> to receive. If the "qop" parameter is not specified, then the default
         value is "auth".
</t>

        <t>
         A UAS MUST <bcp14>MUST</bcp14> always send a "qop" parameter in WWW-Authenticate
         and Proxy-Authenticate header field values, and a UAC MUST <bcp14>MUST</bcp14>
         send the "qop" parameter in any resulting authorization header
         field.
        </t>

    <t> <vspace blankLines="1" /> </t>
</li>
</ol>
        <t>
      The usage of the Authentication-Info header field continues to be
      allowed, since it provides integrity checks over the bodies and
      provides mutual authentication.
        </t>

    <t> <vspace blankLines="1" /> </t>

      </section>

      <!-- HTTP Modifications -->

  <section title="Augmented BNF for SIP" anchor="abnf">
        <name>ABNF for SIP</name>
        <t>
      This document updates the Augmented BNF ABNF <xref target="RFC5234"/> for SIP as
      follows.
        </t>
        <t>
      It extends the request-digest as follows to allow for different
      digest sizes:
        </t>

    <t>
    <list><t>

<sourcecode name="" type="abnf"><![CDATA[
      request-digest = LDQUOT *LHEX RDQUOT
    </t></list>
    </t>
]]></sourcecode>
        <t>
      The number of hex digits is implied by the length of the value of the algorithm used,
      with the a minimum size of 32. A parameter with an empty value (empty string)
      is allowed when the UAC has not yet received a challenge.
        </t>
        <t>
      It extends the algorithm parameter as follows to allow for any algorithm
      in the registry to be used:
        </t>

    <t>
    <list><t>
<!-- [rfced] Please note that we updated the document in order to fit
     within the 72-character line limit.  Please review these changes
     to the indentation of code snippets and let us know if you have
     any concerns.
-->

<sourcecode name="" type=""><![CDATA[
algorithm =  "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
"SHA-256-sess" /
"SHA-512-256" /  "SHA-512-256-sess" / token )
    </t></list>
    </t>

<t> <vspace blankLines="1" /> </t>
]]></sourcecode>
      </section>
      <!-- Augmented BNF for the SIP Protocol-->
</section>
    <!-- The SIP Digest Authentication Scheme -->

  <section title="Security Considerations" anchor="security.considerations">
      <name>Security Considerations</name>
      <t>
    This specification adds new secure algorithms to be used with the
    Digest mechanism to authenticate users. The obsolete MD5 algorithm
    remains only for backward compatibility with <xref target="RFC2617"/> target="RFC2617"/>, but its use is
    NOT RECOMMENDED.
    <bcp14>NOT RECOMMENDED</bcp14>.
      </t>
      <t>
    This opens the system to the potential of for a downgrade attack by an on-path attacker.
    The most effective way of dealing with this type of attack is to either validate the
    client and challenge it accordingly, accordingly or remove the support for backward compatibility
    by not supporting MD5.
      </t>
      <t>
  See section 5 of <xref target="RFC7616"/> target="RFC7616" sectionFormat="of" section="5"/> for a detailed security discussion of
  the Digest Access Authentication scheme.
      </t>

  <t> <vspace blankLines="1" /> </t>

    </section>
    <!-- Security Considerations -->

  <section title="IANA Considerations" anchor="iana.considerations">
      <name>IANA Considerations</name>
      <t>
   <xref target="RFC7616"/> defines an IANA registry named "Hash Algorithms
   for HTTP Digest Authentication" to simplify the introduction of new
   algorithms in the future. This document specifies that algorithms defined in
   that registry may be used in SIP digest authentication.
      </t>
      <t>
  This document has no actions for IANA.
      </t>
  <t> <vspace blankLines="1" /> </t>

    </section>
    <!-- IANA Considerations -->

  <section title="Acknowledgments" anchor="acknowledgments">
  <t>
    The author would like to thank the following individuals
    for their careful reviews, comments, and suggestions: Paul Kyzivat,
    Olle Johansson, Dale Worley, Michael Procter, Iñaki Baz Castillo,
    Tolga Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,
    Barry Leiba, Roni Even, Éric Vyncke, Benjamin Kaduk, Alissa Cooper, Roman Danyliw,
    and Alexey Melnikov, and Maxim Sobolev.
    .
  </t>
  <t> <vspace blankLines="1" /> </t>
  </section>

    <!-- Acknowledgments -->

</middle>
  <!-- ********************************** BACK ********************************** -->
<back>

  <references title="Normative References">

   <?rfc include="reference.RFC.8174.xml"?>
   <?rfc include="reference.RFC.2119.xml"?>

    <reference anchor="RFC3261">
      <front>
        <title abbrev="SIP">SIP: Session Initiation Protocol</title>
        <author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg" />
        <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne" />
        <author initials="H." surname="Camarillo" fullname="Gonzalo Camarillo" />
        <author initials="A." surname="Johnston" fullname="Alan Johnston" />
        <author initials="J." surname="Peterson" fullname="Jon Peterson" />
        <author initials="R." surname="Sparks" fullname="Robert Sparks" />
        <author initials="M." surname="Handley" fullname="Mark Handley" />
        <author initials="E." surname="Schooler" fullname="Eve Schooler" />
        <date month="June" year="2002" />
      </front>
      <seriesInfo name="RFC" value="3261" />
    </reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.xml"/>

        <reference anchor="RFC7234"> anchor="SHA2">
          <front>
           <title abbrev="HTTP Caching">Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
        <author initials="R." surname="Fielding" fullname="Roy Fielding" />
        <author initials="M." surname="Nottingham" fullname="Mark Nottingham" />
        <author initials="J." surname="Reschke" fullname="Julian Reschke" />
        <date month="June" year="2014" />
      </front> abbrev="SHA">Secure Hash Standard (SHS)</title>
<seriesInfo name="RFC" value="7234" />
    </reference>

    <reference anchor="RFC7616">
      <front>
        <title abbrev="HTTP Digest">HTTP Digest Access Authentication</title>
        <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef" />
        <author initials="D." surname="Ahrens" fullname="David Ahrens" />
        <author initials="S." surname="Bremer" fullname="Sophie Bremer" />
        <date month="September" year="2015" />
      </front> name="FIPS" value="180-4"/>
<seriesInfo name="RFC" value="7616" />
    </reference>

    <reference anchor="SHA2">
      <front>
        <title abbrev="SHA">SHA: SECURE HASH STANDARD, FIPS 180-2</title>
        <author initials="" surname="" fullname="" /> name="DOI" value="10.6028/NIST.FIPS.180-4"/>
            <author><organization>National Institute of Standards and
	    Technology</organization></author>
            <date month="August" year="2002" /> year="2015"/>
          </front>
        </reference>
      </references>

    <references title="Informative References">

    <reference anchor="RFC2617">
      <front>
        <title abbrev="HTTP Basic and Digest">HTTP Authentication: Basic
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2617.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
      </references>
    </references>
  <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>
    The author would like to thank the following individuals
    for their careful review, comments, and suggestions: <contact fullname="Paul Kyzivat"/>,
    <contact fullname="Olle Johansson"/>, <contact fullname="Dale Worley"/>, <contact fullname="Michael Procter"/>, <contact fullname="Inaki Baz Castillo"/>,
    <contact fullname="Tolga Asveren"/>, <contact fullname="Christer Holmberg"/>, <contact fullname="Brian Rosen"/>, <contact fullname="Jean Mahoney"/>, <contact fullname="Adam Roach"/>,
    <contact fullname="Barry Leiba"/>, <contact fullname="Roni Even"/>, <contact fullname="Eric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Alissa Cooper"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Alexey Melnikov"/>, and <contact fullname="Maxim Sobolev"/>.
      </t>

      <!--[rfced] Terminology: Throughout the document, we noted the
	  following similar terms.  Should these uses be reviewed for
	  uniformity?

Digest Access Authentication</title>
        <author initials="J." surname="Franks" fullname="John Franks" />
        <author initials="P." surname="M. Hallam-Baker" fullname="Phillip M. Hallam-Baker" />
        <author initials="J." surname="L. Hostetler" fullname="Jeffery L. Hostetler" />
        <author initials="S." surname="D. Lawrence" fullname="Scott D. Lawrence" />
        <author initials="P." surname="J. Leach" fullname="Paul J. Leach" />
        <author initials="A." surname="Luotonen" fullname="Ari Luotonen" />
        <author initials="L." surname="C. Stewart" fullname="Lawrence C. Stewart" />
        <date month="June" year="1999" />
      </front>
      <seriesInfo name="RFC" value="2617" />
    </reference>

   <?rfc include="reference.RFC.6151.xml"?>
   <?rfc include="reference.RFC.5234.xml"?>

  </references> Authentication scheme vs. Digest Authentication scheme
vs. Digest scheme vs Digest authentication (scheme)

-->
    </section>
  </back>
</rfc>