rfc8760xml2.original.xml   rfc8760.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<?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" ?>
<!DOCTYPE rfc [
]>
<rfc ipr="pre5378Trust200902" <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
docName="draft-ietf-sipcore-digest-scheme-15"
category="std"
xml:lang="en"
updates="3261">
<!-- ********************************** FRONT ********************************** <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" tocInclude="true" symRefs="true"
sortRefs="true" version="3" number="8760" consensus="true"
submissionType="IETF">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- ********************************** FRONT ********************************
** -->
<front> <front>
<title abbrev="SIP Digest Authentication">
The Session Initiation Protocol (SIP) Digest Access Authentication Sche
me
</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 month="March" year="2020"/>
<area>RAI</area>
<workgroup>SIP Core</workgroup>
<keyword>Digest Auth</keyword>
<abstract>
<title abbrev="SIP Digest Authentication"> <!--[rfced]] *ADs - please review and approve the following changes
The Session Initiation Protocol (SIP) Digest Authentication Scheme submitted by the author during EDIT state to use "SHA-512/256"
</title> instead of "SHA-512-256" (affects 3 sentences in the document).
<author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef"> *Follow-up question: Also, please review the other
<organization>Avaya</organization> occurrence of "SHA-512-256" (in code) and
<address> let us know if any further updates are necessary (based on use in RFCs
<postal> 4868 and 7616, we believe the dash is correct in this case).
<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" /> Original:
<area>RAI</area>
<workgroup>SIP Core</workgroup>
<keyword>Digest Auth</keyword>
<abstract><t> ... for more secure digest algorithms, e.g., SHA-256 and SHA-512-256, to replace
This document updates RFC 3261 by updating the Digest Access the...
Authentication scheme used by the Session Initiation Protocol (SIP) to add su
pport
for more secure digest algorithms, e.g., SHA-256 and SHA-512-256, to replace
the
obsolete MD5 algorithm.
</t></abstract>
</front> Edited:
...for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to
replace the...
<!-- ********************************** MIDDLE ********************************* Original:
* --> ...resulting from that reference update. It adds support for the SHA-256 and SHA
<middle> -512-256 algorithms...
<section title="Introduction" anchor="introduction"> Edited:
...resulting from that reference update. It adds support for the
SHA-256 and SHA-512/256 algorithms...
<t> 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 modifying the Digest Access
Authentication scheme used by the Session Initiation Protocol (SIP) to add su
pport
for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace
the
obsolete MD5 algorithm.
</t>
</abstract>
</front>
<!-- ********************************** MIDDLE *******************************
*** -->
<middle>
<section anchor="introduction">
<name>Introduction</name>
<t>
The Session Initiation Protocol <xref target="RFC3261"/> uses the same mecha nism The Session Initiation Protocol <xref target="RFC3261"/> uses the same mecha nism
that the Hypertext Transfer Protocol (HTTP) uses for authenticating as the Hypertext Transfer Protocol (HTTP) does for authenticating
users. This mechanism is called Digest Access Authentication, and users. This mechanism is called &quot;Digest Access Authentication&quot;. It
it is a simple challenge-response mechanism that allows a server is a simple challenge-response mechanism that allows a server
to challenge a client request and allows a client to provide to challenge a client request and allows a client to provide
authentication information in response to that challenge. The authentication information in response to that challenge. The
version of Digest Access Authentication that <xref target="RFC3261"/> refere nces version of Digest Access Authentication that <xref target="RFC3261"/> refere nces
is specified in <xref target="RFC2617"/>. is specified in <xref target="RFC2617"/>.
</t> </t>
<t>
<t>
The default hash algorithm for Digest Access Authentication is MD5. The default hash algorithm for Digest Access Authentication is MD5.
However, it has been demonstrated that the MD5 algorithm is not However, it has been demonstrated that the MD5 algorithm is not
collision resistant, and is now considered a bad choice for a hash function collision resistant and is now considered a bad choice for a hash
<xref target="RFC6151"/>. function (see <xref target="RFC6151"/>).
</t> </t>
<t>
<t> The HTTP Digest Access Authentication document <xref target="RFC7616"/> obso
The HTTP Digest Access Authentication <xref target="RFC7616"/> document obso letes
letes <xref target="RFC2617"/> and adds stronger algorithms that can be used with
[RFC2617] and adds stronger algorithms that can be used with the Digest Access Authentication scheme and establishes a registry for
the Digest Authentication scheme, and establishes a registry for
these algorithms, known as the "Hash Algorithms for HTTP Digest these algorithms, known as the "Hash Algorithms for HTTP Digest
Authentication" registry, so that algorithms can be added in the Authentication" IANA registry, so that algorithms can be added in the
future. future.
</t> </t>
<t>
<t>
This document updates the Digest Access Authentication scheme used This document updates the Digest Access Authentication scheme used
by SIP to support the algorithms listed in the "Hash Algorithms by SIP to support the algorithms listed in the "Hash Algorithms
for HTTP Digest Authentication" registry defined by <xref target="RFC7616"/> for HTTP Digest Authentication" IANA registry defined by <xref target="RFC76
. 16"/>.
</t> </t>
<t> <vspace blankLines="1" /> </t>
<section title="Terminology" anchor="terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> wh
en,
and only when, they appear in all capitals, as shown here.
</t>
<t> <vspace blankLines="1" /> </t>
</section>
</section> <!-- Introduction --> <section anchor="terminology">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section title="SIP Digest Authentication Scheme Updates" <!-- Introduction -->
anchor="sip.digest.scheme">
<t> <section anchor="sip.digest.scheme">
<name>Updates to the SIP Digest Access Authentication Scheme</name>
<t>
This section describes the modifications to the operation of the This section describes the modifications to the operation of the
Digest mechanism as specified in <xref target="RFC3261"/> in order to suppor t Digest mechanism as specified in <xref target="RFC3261"/> in order to suppor t
the algorithms defined in the "Hash Algorithms for HTTP Digest Authenticatio n" the algorithms defined in the "Hash Algorithms for HTTP Digest Authenticatio n"
registry described in <xref target="RFC7616"/>. IANA registry described in <xref target="RFC7616"/>.
</t> </t>
<t>
<t>
It replaces the reference used in <xref target="RFC3261"/> for Digest Access Authentication, 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 substituting <xref target="RFC7616"/> for the obsolete <xref target="RFC2617 "/>, and describes
the modifications to the usage of the Digest mechanism in <xref target="RFC3 261"/> the modifications to the usage of the Digest mechanism in <xref target="RFC3 261"/>
resulting from that reference update. It adds support for the SHA-256 and SH A-512-256 algorithms <xref target="SHA2"/>. resulting from that reference update. It adds support for the SHA-256 and SH A-512/256 algorithms <xref target="SHA2"/>.
It adds required support for the "qop" parameter. It provides additional Use r Agent Client (UAC) It adds required support for the "qop" parameter. It provides additional Use r Agent Client (UAC)
and User Agent Server (UAS) procedures regarding usage of multiple SIP Autho rization, and User Agent Server (UAS) procedures regarding usage of multiple SIP Autho rization,
WWW-Authenticate and Proxy-Authenticate header fields, including in which or WWW-Authenticate, and Proxy-Authenticate header fields, including the order
der to insert in which to insert
and process them. It provides guidance regarding forking. Finally, it update and process them. It provides guidance regarding forking. Finally, it update
s the SIP BNF s the SIP ABNF
as required by the updates. as required by the updates.
</t> </t>
<section anchor="hash.algorithms">
<t> <vspace blankLines="1" /> </t> <name>Hash Algorithms</name>
<t>
<section title="Hash Algorithms" anchor="hash.algorithms"> The Digest Access Authentication scheme has an "algorithm" parameter that
specifies the
<t> algorithm to be used to compute the digest of the response. The "Hash
The Digest scheme has an 'algorithm' parameter that specifies the Algorithms for HTTP Digest Authentication" IANA registry specifies
algorithm to be used to compute the digest of the response. The IANA
registry named the "Hash Algorithms for HTTP Digest Authentication" specif
ies
the algorithms that correspond to 'algorithm' values. the algorithms that correspond to 'algorithm' values.
</t> </t>
<t>
<t>
<xref target="RFC3261"/> specifies only one algorithm, MD5, which is used by default. <xref target="RFC3261"/> specifies only one algorithm, MD5, which is used by default.
This document extends <xref target="RFC3261"/> to allow use of any algorit hm listed in This document extends <xref target="RFC3261"/> to allow use of any algorit hm listed in
the "Hash Algorithms for HTTP Digest Authentication" registry. the "Hash Algorithms for HTTP Digest Authentication" IANA registry.
</t> </t>
<t>
<t>
A UAS prioritizes which algorithm to use based on its policy, A UAS prioritizes which algorithm to use based on its policy,
which is specified in section 2.3 and parallels the process used in which is specified in <xref target="uas.behavior" /> and parallels the proc ess used in
HTTP specified by <xref target="RFC7616"/>. HTTP specified by <xref target="RFC7616"/>.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section> <!-- Hash Algorithms -->
<section title="Representation of Digest Values" anchor="rep.digest.values"> </section>
<!-- Hash Algorithms -->
<t> <section anchor="rep.digest.values">
<name>Representation of Digest Values</name>
<t>
The size of the digest depends on the algorithm used. The bits in The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least the digest are converted from the most significant to the least
significant bit, four bits at a time to the ASCII representation as significant bit, four bits at a time, to the ASCII representation as
follows. Each four bits is represented by its familiar hexadecimal follows. Each set of four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef, that is binary 0000 is notation from the characters 0123456789abcdef; that is, binary 0000 is
represented by the character '0', 0001 by '1' and so on up to the represented by the character '0', 0001 is represented by '1', and so on up
representation of 1111 as 'f'. If the SHA-256 or SHA-512-256 algorithm is to the
representation of 1111 as 'f'. If the SHA-256 or SHA-512/256 algorithm is
used to calculate the digest, then the digest will be represented as 64 used to calculate the digest, then the digest will be represented as 64
hexadecimal characters. hexadecimal characters.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section>
<section title="UAS Behavior" anchor="uas.behavior"> </section>
<section anchor="uas.behavior">
<name>UAS Behavior</name>
<t> <t>
When a UAS receives a request from a UAC, and an acceptable When a UAS receives a request from a UAC, and an acceptable
Authorization header field is not received, the UAS can challenge the Authorization header field is not received, the UAS can challenge the
originator to provide credentials by rejecting the request with a originator to provide credentials by rejecting the request with a
401/407 status code with the WWW-Authenticate/Proxy-Authenticate 401/407 status code with the WWW-Authenticate/Proxy-Authenticate
header field respectively. The UAS MAY add multiple WWW-Authenticate/Proxy -Authenticate header field, respectively. The UAS <bcp14>MAY</bcp14> add multiple WWW-Au thenticate/Proxy-Authenticate
header fields to allow the UAS to utilize the best available header fields to allow the UAS to utilize the best available
algorithm supported by the client. algorithm supported by the client.
</t> </t>
<t>
<t> If the UAS challenges the originator using multiple WWW-Authenticate/Proxy
If the UAS challenges with multiple WWW-Authenticate/Proxy-Authenticate -Authenticate
header fields with the same realm, then each one of these header fields with the same realm, then each of these
header fields MUST use a different digest algorithm. The UAS MUST add thes header fields <bcp14>MUST</bcp14> use a different digest algorithm. The UA
e S <bcp14>MUST</bcp14> add these
header fields to the response in the order that it would prefer to see the header fields to the response in the order in which it would prefer to see
m them
used, starting with the most preferred algorithm at the top, followed used, starting with the most preferred algorithm at the top. The UAS canno
by the less preferred algorithms. The UAS cannot assume that the client t assume that the client
will use the algorithm specified at the topmost header field. will use the algorithm specified in the topmost header field.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section>
<section title="UAC Behavior" anchor="uac.behavior">
<t>
When the UAC receives a response with multiple WWW-Authenticate/Proxy-Auth
enticate
header fields with the same realm it SHOULD use the topmost
header field that it supports, unless a local policy dictates otherwise.
The client MUST ignore any challenge it does not understand.
</t>
<t> </section>
<section anchor="uac.behavior">
<name>UAC Behavior</name>
<t> When the UAC receives a response with multiple WWW-Authenticate/Proxy-A
uthenticate
header fields with the same realm, it <bcp14>SHOULD</bcp14> use the topmos
t
header field that it supports unless a local policy dictates otherwise.
The client <bcp14>MUST</bcp14> ignore any challenge it does not understand
.
</t>
<t>
When the UAC receives a 401 response with multiple WWW-Authenticate When the UAC receives a 401 response with multiple WWW-Authenticate
header fields with different realms it SHOULD retry and add an header fields with different realms, it <bcp14>SHOULD</bcp14> retry and ad d an
Authorization header field containing credentials that match the topmost Authorization header field containing credentials that match the topmost
header field of any one of the realms, unless a local policy dictates othe header field of any of the realms unless a local policy dictates otherwise
rwise. .
</t> </t>
<t>
<t>
If the UAC cannot respond to any of the challenges in the response, If the UAC cannot respond to any of the challenges in the response,
then it SHOULD abandon attempts to send the request, unless a local then it <bcp14>SHOULD</bcp14> abandon attempts to send the request unless a
policy dictates otherwise, e.g. the policy might indicate the use of non-Dig local
est mechanisms. policy dictates otherwise, e.g., the policy might indicate the use of non-Di
gest mechanisms.
For example, if the UAC does not have credentials or has stale credentials f or For example, if the UAC does not have credentials or has stale credentials f or
any of the realms, the UAC will abandon the request. any of the realms, the UAC will abandon the request.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section>
<section title="Forking" anchor="forking">
<t> </section>
Section 22.3 of <xref target="RFC3261"/> discusses the operation of the pr <section anchor="forking">
oxy-to-user <name>Forking</name>
<t>
<xref target="RFC3261" sectionFormat="of" section="22.3"/> discusses the o
peration of the proxy-to-user
authentication, which describes the operation of the proxy when it authentication, which describes the operation of the proxy when it
forks a request. This section clarifies that operation. forks a request. This section clarifies that operation.
</t> </t>
<t>
<t>
If a request is forked, various proxy servers and/or UAs may wish to 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 challenge the UAC. In this case, the forking proxy server is
responsible for aggregating these challenges into a single response. responsible for aggregating these challenges into a single response.
Each WWW-Authenticate and Proxy-Authenticate value received in Each WWW-Authenticate and Proxy-Authenticate value received in
responses to the forked request MUST be placed into the single response to the forked request <bcp14>MUST</bcp14> be placed into the sing le
response that is sent by the forking proxy to the UAC. response that is sent by the forking proxy to the UAC.
</t> </t>
<t>
<t>
When the forking proxy places multiple WWW-Authenticate and Proxy-Authentica te header When the forking proxy places multiple WWW-Authenticate and Proxy-Authentica te header
fields received from one downstream proxy into a single response, it MUST ma intain fields received from one downstream proxy into a single response, it <bcp14> MUST</bcp14> maintain
the order of these header fields. The ordering of values received from diff erent downstream the order of these header fields. The ordering of values received from diff erent downstream
proxies is not significant. proxies is not significant.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section> <!-- Forking -->
<section title="HTTP Digest Authentication Scheme Modifications" anchor="htt </section>
p.modifications"> <!-- Forking -->
<t> <section anchor="http.modifications">
<name>HTTP Digest Authentication Scheme Modifications</name>
<t>
This section describes the modifications and clarifications required This section describes the modifications and clarifications required
to apply the HTTP Digest authentication scheme to SIP. The SIP scheme to apply the HTTP Digest Access Authentication scheme to SIP. The SIP sche me
usage is similar to that for HTTP. For completeness, the bullets specified usage is similar to that for HTTP. For completeness, the bullets specified
below are mostly copied from section 22.4 of <xref target="RFC3261"/>; the below are mostly copied from <xref target="RFC3261"
sectionFormat="of" section="22.4"/>; the
only semantic changes are specified in bullets 1, 7, and 8 below. only semantic changes are specified in bullets 1, 7, and 8 below.
</t> </t>
<t>
<t> SIP clients and servers <bcp14>MUST NOT</bcp14> accept or request Basic
SIP clients and servers MUST NOT accept or request Basic
authentication. authentication.
</t> </t>
<t>
<t> The rules for Digest Access Authentication follow those defined in HTTP,
The rules for Digest authentication follow those defined in HTTP,
with "HTTP/1.1" <xref target="RFC7616"/> replaced by "SIP/2.0" in addition to the following with "HTTP/1.1" <xref target="RFC7616"/> replaced by "SIP/2.0" in addition to the following
differences: differences:
</t> </t>
<ol>
<li>
<t> <t>
1. The URI included in the challenge has the following BNF <xref target="R The URI included in the challenge has the following ABNF <xref target="RFC5234"/
FC5234"/>: >:
<list><t>
URI = Request-URI ; as defined in <xref target="RFC3261"/>, Section 25
</t></list>
</t> </t>
<sourcecode name="" type="abnf"><![CDATA[
<t> URI = Request-URI ; as defined in RFC 3261, Section 25
2. The 'uri' parameter of the Authorization header field MUST be ]]></sourcecode>
</li>
<li>
The "uri" parameter of the Authorization header field <bcp14>MUST</bcp14> be
enclosed in quotation marks. enclosed in quotation marks.
</t> </li>
<li><t>
<t> The ABNF for digest-uri-value is:</t>
3. The BNF for digest-uri-value is: <sourcecode name="" type="abnf"><![CDATA[
<list><t>
digest-uri-value = Request-URI digest-uri-value = Request-URI
</t></list> ]]></sourcecode>
</t> </li>
<li>
<t> The example procedure for choosing a nonce based on ETag does not
4. The example procedure for choosing a nonce based on Etag does not
work for SIP. work for SIP.
</t> </li>
<li>
<t> The text in <xref target="RFC7234"/> regarding cache operation does not
5. The text in <xref target="RFC7234"/> regarding cache operation does not
apply to SIP. apply to SIP.
</t> </li>
<li>
<t> <xref target="RFC7616"/> requires that a server check that the URI in the
6. <xref target="RFC7616"/> requires that a server check that the URI in t
he
request line and the URI included in the Authorization header request line and the URI included in the Authorization header
field point to the same resource. In a SIP context, these two field point to the same resource. In a SIP context, these two
URIs may refer to different users, due to forwarding at some URIs may refer to different users due to forwarding at some
proxy. Therefore, in SIP, a UAS MUST check if the Request-URI in the proxy. Therefore, in SIP, a UAS <bcp14>MUST</bcp14> check if the Requ
est-URI in the
Authorization/Proxy-Authorization header field value corresponds to a Authorization/Proxy-Authorization header field value corresponds to a
user for whom the UAS is willing to accept forwarded or direct user for whom the UAS is willing to accept forwarded or direct
requests, but MAY still accept it if the two fields are not equivalent requests; however, it <bcp14>MAY</bcp14> still accept it if the two fi
. elds are not equivalent.
</t> </li>
<li>
<t> <t>As a clarification to the calculation of the A2 value for
7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest Access Authentication
message integrity assurance in the Digest authentication scheme, implementers should assume that the hash of the entity-body
scheme, implementers should assume, when the entity-body is resolves to the hash of an empty string when the entity-body is empty (that
empty (that is, when SIP messages have no body) that the hash is, when SIP messages have no body):</t>
of the entity-body resolves to the hash of an empty
string:
<list><t> <sourcecode name="" type=""><![CDATA[
H(entity-body) = &lt;algorithm>("") H(entity-body) = <algorithm>("")
</t></list> ]]></sourcecode>
For example, when the chosen algorithm is SHA-256, then: <t>For example, when the chosen algorithm is SHA-256, then:</t>
<list><t>
H(entity-body) = SHA-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
</t></list>
</t>
<t> <sourcecode name="" type=""><![CDATA[
8. A UAS MUST be able to properly handle "qop" parameter received H(entity-body) = SHA-256("") =
in an Authorization/Proxy-Authorization header field, and a UAC MUST be "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
able to ]]> </sourcecode>
properly handle "qop" parameter received in WWW-Authenticate and </li>
<li>
<t>
A UAS <bcp14>MUST</bcp14> be able to properly handle a "qop" parameter received
in an Authorization/Proxy-Authorization header field, and a UAC <bcp14>
MUST</bcp14> be able to
properly handle a "qop" parameter received in WWW-Authenticate and
Proxy-Authenticate header fields. However, for backward compatibility Proxy-Authenticate header fields. However, for backward compatibility
reasons, the "qop" parameter is optional for RFC3261-based clients and reasons, the "qop" parameter is optional for clients and
servers to receive. If the "qop" parameter is not specified, then the d servers based on <xref target="RFC3261" /> to receive. If the "qop" para
efault meter is not specified, then the default
value is "auth". value is "auth".
</t> </t>
<t>
A UAS MUST always send a "qop" parameter in WWW-Authenticate <t>
and Proxy-Authenticate header field values, and a UAC MUST A UAS <bcp14>MUST</bcp14> always send a "qop" parameter in WWW-Authenti
cate
and Proxy-Authenticate header field values, and a UAC <bcp14>MUST</bcp1
4>
send the "qop" parameter in any resulting authorization header send the "qop" parameter in any resulting authorization header
field. field.
</t> </t>
</li>
<t> <vspace blankLines="1" /> </t> </ol>
<t> <t>
The usage of the Authentication-Info header field continues to be The usage of the Authentication-Info header field continues to be
allowed, since it provides integrity checks over the bodies and allowed, since it provides integrity checks over the bodies and
provides mutual authentication. provides mutual authentication.
</t> </t>
<t> <vspace blankLines="1" /> </t> </section>
</section> <!-- HTTP Modifications --> <!-- HTTP Modifications -->
<section title="Augmented BNF for SIP" anchor="abnf"> <section anchor="abnf">
<t> <name>ABNF for SIP</name>
This document updates the Augmented BNF <xref target="RFC5234"/> for SIP a <t>
s This document updates the ABNF <xref target="RFC5234"/> for SIP as
follows. follows.
</t> </t>
<t>
<t>
It extends the request-digest as follows to allow for different It extends the request-digest as follows to allow for different
digest sizes: digest sizes:
</t> </t>
<t> <sourcecode name="" type="abnf"><![CDATA[
<list><t>
request-digest = LDQUOT *LHEX RDQUOT request-digest = LDQUOT *LHEX RDQUOT
</t></list> ]]></sourcecode>
</t> <t>
<t>
The number of hex digits is implied by the length of the value of the algo rithm used, The number of hex digits is implied by the length of the value of the algo rithm used,
with the minimum size of 32. A parameter with an empty value (empty string ) with a minimum size of 32. A parameter with an empty value (empty string)
is allowed when the UAC has not yet received a challenge. is allowed when the UAC has not yet received a challenge.
</t> </t>
<t>
<t> It extends the algorithm parameter as follows to allow any algorithm
It extends the algorithm parameter as follows to allow for any algorithm
in the registry to be used: in the registry to be used:
</t> </t>
<!-- [rfced] Please note that we updated the document in order to fit
<t> within the 72-character line limit. Please review these changes
<list><t> to the indentation of code snippets and let us know if you have
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" / "SHA-256 any concerns.
-sess" / -->
"SHA-512-256" / "SHA-512-256-sess" / token )
</t></list>
</t>
<t> <vspace blankLines="1" /> </t> <sourcecode name="" type=""><![CDATA[
</section> <!-- Augmented BNF for the SIP Protocol--> algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
</section> <!-- The SIP Digest Authentication Scheme --> "SHA-256-sess" /
"SHA-512-256" / "SHA-512-256-sess" / token )
]]></sourcecode>
</section>
<!-- Augmented BNF for the SIP Protocol-->
</section>
<!-- The SIP Digest Authentication Scheme -->
<section title="Security Considerations" anchor="security.considerations"> <section anchor="security.considerations">
<t> <name>Security Considerations</name>
<t>
This specification adds new secure algorithms to be used with the This specification adds new secure algorithms to be used with the
Digest mechanism to authenticate users. The obsolete MD5 algorithm Digest mechanism to authenticate users. The obsolete MD5 algorithm
remains only for backward compatibility with <xref target="RFC2617"/> but it remains only for backward compatibility with <xref target="RFC2617"/>, but i
s use is ts use is
NOT RECOMMENDED. <bcp14>NOT RECOMMENDED</bcp14>.
</t> </t>
<t>
<t> This opens the system to the potential for a downgrade attack by an on-path
This opens the system to the potential of a downgrade attack by an on-path a attacker.
ttacker.
The most effective way of dealing with this type of attack is to either vali date the The most effective way of dealing with this type of attack is to either vali date the
client and challenge it accordingly, or remove the support for backward comp atibility client and challenge it accordingly or remove the support for backward compa tibility
by not supporting MD5. by not supporting MD5.
</t> </t>
<t>
<t> See <xref target="RFC7616" sectionFormat="of" section="5"/> for a detailed sec
See section 5 of <xref target="RFC7616"/> for a detailed security discussion o urity discussion of
f the Digest Access Authentication scheme.
the Digest scheme. </t>
</t>
<t> <vspace blankLines="1" /> </t> </section>
</section> <!-- Security Considerations --> <!-- Security Considerations -->
<section title="IANA Considerations" anchor="iana.considerations"> <section anchor="iana.considerations">
<t> <name>IANA Considerations</name>
<t>
<xref target="RFC7616"/> defines an IANA registry named "Hash Algorithms <xref target="RFC7616"/> defines an IANA registry named "Hash Algorithms
for HTTP Digest Authentication" to simplify the introduction of new for HTTP Digest Authentication" to simplify the introduction of new
algorithms in the future. This document specifies that algorithms defined in algorithms in the future. This document specifies that algorithms defined in
that registry may be used in SIP digest authentication. that registry may be used in SIP digest authentication.
</t> </t>
<t> <t>
This document has no actions for IANA. This document has no actions for IANA.
</t> </t>
<t> <vspace blankLines="1" /> </t>
</section> <!-- IANA Considerations -->
<section title="Acknowledgments" anchor="acknowledgments"> </section>
<t> <!-- IANA Considerations -->
The author would like to thank the following individuals
for their careful reviews, comments, and suggestions: Paul Kyzivat,
Olle Johansson, Dale Worley, Michael Procter, Iaki Baz Castillo,
Tolga Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,
Barry Leiba, Roni Even, ric Vyncke, Benjamin Kaduk, Alissa Cooper, Roman Dan
yliw,
and Alexey Melnikov, and Maxim Sobolev.
.
</t>
<t> <vspace blankLines="1" /> </t>
</section> <!-- Acknowledgments -->
</middle> <!-- Acknowledgments -->
<!-- ********************************** BACK ********************************** </middle>
--> <!-- ********************************** BACK *********************************
* -->
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7234.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.x
ml"/>
<references title="Normative References"> <reference anchor="SHA2">
<front>
<?rfc include="reference.RFC.8174.xml"?> <title abbrev="SHA">Secure Hash Standard (SHS)</title>
<?rfc include="reference.RFC.2119.xml"?> <seriesInfo name="FIPS" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
<reference anchor="RFC3261"> <author><organization>National Institute of Standards and
<front> Technology</organization></author>
<title abbrev="SIP">SIP: Session Initiation Protocol</title> <date month="August" year="2015"/>
<author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg" </front>
/> </reference>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinn </references>
e" /> <references>
<author initials="H." surname="Camarillo" fullname="Gonzalo Camarillo" / <name>Informative References</name>
>
<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>
<reference anchor="RFC7234">
<front>
<title abbrev="HTTP Caching">Hypertext Transfer Protocol (HTTP/1.1): Cac
hing</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>
<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>
<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="" />
<date month="August" year="2002" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2617">
<front>
<title abbrev="HTTP Basic and Digest">HTTP Authentication: Basic and Dig
est Access Authentication</title>
<author initials="J." surname="Franks" fullname="John Franks" />
<author initials="P." surname="M. Hallam-Baker" fullname="Phillip M. Hal
lam-Baker" />
<author initials="J." surname="L. Hostetler" fullname="Jeffery L. Hostet
ler" />
<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"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.5234.xml"?> FC.2617.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6151.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.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"/>, <co
ntact fullname="Michael Procter"/>, <contact fullname="Inaki Baz Castillo"/>,
<contact fullname="Tolga Asveren"/>, <contact fullname="Christer Holmberg"/>
, <contact fullname="Brian Rosen"/>, <contact fullname="Jean Mahoney"/>, <contac
t fullname="Adam Roach"/>,
<contact fullname="Barry Leiba"/>, <contact fullname="Roni Even"/>, <contact
fullname="Eric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullna
me="Alissa Cooper"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Al
exey Melnikov"/>, and <contact fullname="Maxim Sobolev"/>.
</t>
</references> <!--[rfced] Terminology: Throughout the document, we noted the
following similar terms. Should these uses be reviewed for
uniformity?
</back> Digest Access Authentication scheme vs. Digest Authentication scheme
vs. Digest scheme vs Digest authentication (scheme)
-->
</section>
</back>
</rfc> </rfc>
 End of changes. 97 change blocks. 
439 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/