draft-ietf-sipcore-digest-scheme-15.txt   rfc8760.txt 
SIP Core R. Shekh-Yusef Internet Engineering Task Force (IETF) R. Shekh-Yusef
Internet-Draft Avaya Request for Comments: 8760 Avaya
Updates: 3261 (if approved) November 3, 2019 Updates: 3261 March 2020
Intended status: Standards Track Category: Standards Track
Expires: May 6, 2020 ISSN: 2070-1721
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Access Authentication
draft-ietf-sipcore-digest-scheme-15 Scheme
Abstract Abstract
This document updates RFC 3261 by updating the Digest Access This document updates RFC 3261 by modifying the Digest Access
Authentication scheme used by the Session Initiation Protocol (SIP) Authentication scheme used by the Session Initiation Protocol (SIP)
to add support for more secure digest algorithms, e.g., SHA-256 and to add support for more secure digest algorithms, e.g., SHA-256 and
SHA-512-256, to replace the obsolete MD5 algorithm. SHA-512/256, to replace the obsolete MD5 algorithm.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 6, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8760.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at line 61
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3 2. Updates to the SIP Digest Access Authentication Scheme
2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 2.1. Hash Algorithms
2.2. Representation of Digest Values . . . . . . . . . . . . . 4 2.2. Representation of Digest Values
2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.3. UAS Behavior
2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.4. UAC Behavior
2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Forking
2.6. HTTP Digest Authentication Scheme Modifications . . . . . 5 2.6. HTTP Digest Authentication Scheme Modifications
2.7. Augmented BNF for SIP . . . . . . . . . . . . . . . . . . 7 2.7. ABNF for SIP
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5. References
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References
6.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address
1. Introduction 1. Introduction
The Session Initiation Protocol [RFC3261] uses the same mechanism The Session Initiation Protocol [RFC3261] uses the same mechanism as
that the Hypertext Transfer Protocol (HTTP) uses for authenticating the Hypertext Transfer Protocol (HTTP) does for authenticating users.
users. This mechanism is called Digest Access Authentication, and it This mechanism is called "Digest Access Authentication". It is a
is a simple challenge-response mechanism that allows a server to simple challenge-response mechanism that allows a server to challenge
challenge a client request and allows a client to provide a client request and allows a client to provide authentication
authentication information in response to that challenge. The information in response to that challenge. The version of Digest
version of Digest Access Authentication that [RFC3261] references is Access Authentication that [RFC3261] references is specified in
specified in [RFC2617]. [RFC2617].
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 collision resistant and is now considered a bad choice for a hash
function [RFC6151]. function (see [RFC6151]).
The HTTP Digest Access Authentication [RFC7616] document obsoletes The HTTP Digest Access Authentication document [RFC7616] obsoletes
[RFC2617] and adds stronger algorithms that can be used with the [RFC2617] and adds stronger algorithms that can be used with the
Digest Authentication scheme, and establishes a registry for these Digest Access Authentication scheme and establishes a registry for
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.
This document updates the Digest Access Authentication scheme used by This document updates the Digest Access Authentication scheme used by
SIP to support the algorithms listed in the "Hash Algorithms for HTTP SIP to support the algorithms listed in the "Hash Algorithms for HTTP
Digest Authentication" registry defined by [RFC7616]. Digest Authentication" IANA registry defined by [RFC7616].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SIP Digest Authentication Scheme Updates 2. Updates to the SIP Digest Access Authentication Scheme
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 [RFC3261] in order to support the Digest mechanism as specified in [RFC3261] in order to support the
algorithms defined in the "Hash Algorithms for HTTP Digest algorithms defined in the "Hash Algorithms for HTTP Digest
Authentication" registry described in [RFC7616]. Authentication" IANA registry described in [RFC7616].
It replaces the reference used in [RFC3261] for Digest Access It replaces the reference used in [RFC3261] for Digest Access
Authentication, substituting [RFC7616] for the obsolete [RFC2617], Authentication, substituting [RFC7616] for the obsolete [RFC2617],
and describes the modifications to the usage of the Digest mechanism and describes the modifications to the usage of the Digest mechanism
in [RFC3261] resulting from that reference update. It adds support in [RFC3261] resulting from that reference update. It adds support
for the SHA-256 and SHA-512-256 algorithms [SHA2]. It adds required for the SHA-256 and SHA-512/256 algorithms [SHA2]. It adds required
support for the "qop" parameter. It provides additional User Agent support for the "qop" parameter. It provides additional User Agent
Client (UAC) and User Agent Server (UAS) procedures regarding usage Client (UAC) and User Agent Server (UAS) procedures regarding usage
of multiple SIP Authorization, WWW-Authenticate and Proxy- of multiple SIP Authorization, WWW-Authenticate, and Proxy-
Authenticate header fields, including in which order to insert and Authenticate header fields, including the order in which to insert
process them. It provides guidance regarding forking. Finally, it and process them. It provides guidance regarding forking. Finally,
updates the SIP BNF as required by the updates. it updates the SIP ABNF as required by the updates.
2.1. Hash Algorithms 2.1. Hash Algorithms
The Digest scheme has an 'algorithm' parameter that specifies the The Digest Access Authentication scheme has an "algorithm" parameter
algorithm to be used to compute the digest of the response. The IANA that specifies the algorithm to be used to compute the digest of the
registry named the "Hash Algorithms for HTTP Digest Authentication" response. The "Hash Algorithms for HTTP Digest Authentication" IANA
specifies the algorithms that correspond to 'algorithm' values. registry specifies the algorithms that correspond to 'algorithm'
values.
[RFC3261] specifies only one algorithm, MD5, which is used by [RFC3261] specifies only one algorithm, MD5, which is used by
default. This document extends [RFC3261] to allow use of any default. This document extends [RFC3261] to allow use of any
algorithm listed in the "Hash Algorithms for HTTP Digest algorithm listed in the "Hash Algorithms for HTTP Digest
Authentication" registry. Authentication" IANA registry.
A UAS prioritizes which algorithm to use based on its policy, which A UAS prioritizes which algorithm to use based on its policy, which
is specified in section 2.3 and parallels the process used in HTTP is specified in Section 2.3 and parallels the process used in HTTP
specified by [RFC7616]. specified by [RFC7616].
2.2. Representation of Digest Values 2.2. Representation of Digest Values
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
notation from the characters 0123456789abcdef, that is binary 0000 is hexadecimal notation from the characters 0123456789abcdef; that is,
represented by the character '0', 0001 by '1' and so on up to the binary 0000 is represented by the character '0', 0001 is represented
representation of 1111 as 'f'. If the SHA-256 or SHA-512-256 by '1', and so on up to the representation of 1111 as 'f'. If the
algorithm is used to calculate the digest, then the digest will be SHA-256 or SHA-512/256 algorithm is used to calculate the digest,
represented as 64 hexadecimal characters. then the digest will be represented as 64 hexadecimal characters.
2.3. UAS Behavior 2.3. UAS Behavior
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- header field, respectively. The UAS MAY add multiple WWW-
Authenticate/Proxy-Authenticate header fields to allow the UAS to Authenticate/Proxy-Authenticate header fields to allow the UAS to
utilize the best available algorithm supported by the client. utilize the best available algorithm supported by the client.
If the UAS challenges with multiple WWW-Authenticate/Proxy- If the UAS challenges the originator using multiple WWW-Authenticate/
Authenticate header fields with the same realm, then each one of Proxy-Authenticate header fields with the same realm, then each of
these header fields MUST use a different digest algorithm. The UAS these header fields MUST use a different digest algorithm. The UAS
MUST add these header fields to the response in the order that it MUST add these header fields to the response in the order in which it
would prefer to see them used, starting with the most preferred would prefer to see them used, starting with the most preferred
algorithm at the top, followed by the less preferred algorithms. The algorithm at the top. The UAS cannot assume that the client will use
UAS cannot assume that the client will use the algorithm specified at the algorithm specified in the topmost header field.
the topmost header field.
2.4. UAC Behavior 2.4. UAC Behavior
When the UAC receives a response with multiple WWW-Authenticate/ When the UAC receives a response with multiple WWW-Authenticate/
Proxy-Authenticate header fields with the same realm it SHOULD use Proxy-Authenticate header fields with the same realm, it SHOULD use
the topmost header field that it supports, unless a local policy the topmost header field that it supports unless a local policy
dictates otherwise. The client MUST ignore any challenge it does not dictates otherwise. The client MUST ignore any challenge it does not
understand. understand.
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 SHOULD retry and add an
Authorization header field containing credentials that match the Authorization header field containing credentials that match the
topmost header field of any one of the realms, unless a local policy topmost header field of any of the realms unless a local policy
dictates otherwise. dictates otherwise.
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 SHOULD abandon attempts to send the request unless a local
policy dictates otherwise, e.g. the policy might indicate the use of policy dictates otherwise, e.g., the policy might indicate the use of
non-Digest mechanisms. For example, if the UAC does not have non-Digest mechanisms. For example, if the UAC does not have
credentials or has stale credentials for any of the realms, the UAC credentials or has stale credentials for any of the realms, the UAC
will abandon the request. will abandon the request.
2.5. Forking 2.5. Forking
Section 22.3 of [RFC3261] discusses the operation of the proxy-to- Section 22.3 of [RFC3261] discusses the operation of the proxy-to-
user authentication, which describes the operation of the proxy when user authentication, which describes the operation of the proxy when
it forks a request. This section clarifies that operation. it forks a request. This section clarifies that operation.
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 MUST be placed into the single
response that is sent by the forking proxy to the UAC. response that is sent by the forking proxy to the UAC.
When the forking proxy places multiple WWW-Authenticate and Proxy- When the forking proxy places multiple WWW-Authenticate and Proxy-
Authenticate header fields received from one downstream proxy into a Authenticate header fields received from one downstream proxy into a
single response, it MUST maintain the order of these header fields. single response, it MUST maintain the order of these header fields.
The ordering of values received from different downstream proxies is The ordering of values received from different downstream proxies is
not significant. not significant.
2.6. HTTP Digest Authentication Scheme Modifications 2.6. HTTP Digest Authentication Scheme Modifications
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 to apply the HTTP Digest Access Authentication scheme to SIP. The
scheme usage is similar to that for HTTP. For completeness, the SIP scheme usage is similar to that for HTTP. For completeness, the
bullets specified below are mostly copied from section 22.4 of bullets specified below are mostly copied from Section 22.4 of
[RFC3261]; the only semantic changes are specified in bullets 1, 7, [RFC3261]; the only semantic changes are specified in bullets 1, 7,
and 8 below. and 8 below.
SIP clients and servers MUST NOT accept or request Basic SIP clients and servers MUST NOT accept or request Basic
authentication. authentication.
The rules for Digest authentication follow those defined in HTTP, The rules for Digest Access Authentication follow those defined in
with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the HTTP, with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to
following differences: the following differences:
1. The URI included in the challenge has the following BNF 1. The URI included in the challenge has the following ABNF
[RFC5234]: [RFC5234]:
URI = Request-URI ; as defined in [RFC3261], Section 25 URI = Request-URI ; as defined in RFC 3261, Section 25
2. The 'uri' parameter of the Authorization header field MUST be 2. The "uri" parameter of the Authorization header field MUST be
enclosed in quotation marks. enclosed in quotation marks.
3. The BNF for digest-uri-value is: 3. The ABNF for digest-uri-value is:
digest-uri-value = Request-URI digest-uri-value = Request-URI
4. 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.
5. The text in [RFC7234] regarding cache operation does not apply to 5. The text in [RFC7234] regarding cache operation does not apply to
SIP. SIP.
6. [RFC7616] requires that a server check that the URI in the 6. [RFC7616] requires that a server check that the URI in the
request line and the URI included in the Authorization header field request line and the URI included in the Authorization header
point to the same resource. In a SIP context, these two URIs may field point to the same resource. In a SIP context, these two
refer to different users, due to forwarding at some proxy. URIs may refer to different users due to forwarding at some
Therefore, in SIP, a UAS MUST check if the Request-URI in the proxy. Therefore, in SIP, a UAS MUST check if the Request-URI in
Authorization/Proxy-Authorization header field value corresponds to a the Authorization/Proxy-Authorization header field value
user for whom the UAS is willing to accept forwarded or direct corresponds to a user for whom the UAS is willing to accept
requests, but MAY still accept it if the two fields are not forwarded or direct requests; however, it MAY still accept it if
equivalent. the two fields are not equivalent.
7. As a clarification to the calculation of the A2 value for message 7. As a clarification to the calculation of the A2 value for message
integrity assurance in the Digest authentication scheme, implementers integrity assurance in the Digest Access Authentication scheme,
should assume, when the entity-body is empty (that is, when SIP implementers should assume that the hash of the entity-body
messages have no body) that the hash of the entity-body resolves to resolves to the hash of an empty string when the entity-body is
the hash of an empty string: empty (that is, when SIP messages have no body):
H(entity-body) = <algorithm>("") H(entity-body) = <algorithm>("")
For example, when the chosen algorithm is SHA-256, then: For example, when the chosen algorithm is SHA-256, then:
H(entity-body) = SHA-256("") = H(entity-body) = SHA-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
8. A UAS MUST be able to properly handle "qop" parameter received in 8. A UAS MUST be able to properly handle a "qop" parameter received
an Authorization/Proxy-Authorization header field, and a UAC MUST be in an Authorization/Proxy-Authorization header field, and a UAC
able to properly handle "qop" parameter received in WWW-Authenticate MUST be able to properly handle a "qop" parameter received in
and Proxy-Authenticate header fields. However, for backward WWW-Authenticate and Proxy-Authenticate header fields. However,
compatibility reasons, the "qop" parameter is optional for for backward compatibility reasons, the "qop" parameter is
RFC3261-based clients and servers to receive. If the "qop" parameter optional for clients and servers based on [RFC3261] to receive.
is not specified, then the default value is "auth". If the "qop" parameter is not specified, then the default value
is "auth".
A UAS MUST always send a "qop" parameter in WWW-Authenticate and A UAS MUST always send a "qop" parameter in WWW-Authenticate and
Proxy-Authenticate header field values, and a UAC MUST send the "qop" Proxy-Authenticate header field values, and a UAC MUST send the
parameter in any resulting authorization header field. "qop" parameter in any resulting authorization header field.
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.
2.7. Augmented BNF for SIP 2.7. ABNF for SIP
This document updates the Augmented BNF [RFC5234] for SIP as follows. This document updates the ABNF [RFC5234] for SIP as follows.
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:
request-digest = LDQUOT *LHEX RDQUOT request-digest = LDQUOT *LHEX RDQUOT
The number of hex digits is implied by the length of the value of the The number of hex digits is implied by the length of the value of the
algorithm used, with the minimum size of 32. A parameter with an algorithm used, with a minimum size of 32. A parameter with an empty
empty value (empty string) is allowed when the UAC has not yet value (empty string) is allowed when the UAC has not yet received a
received a challenge. challenge.
It extends the algorithm parameter as follows to allow for any It extends the algorithm parameter as follows to allow any algorithm
algorithm in the registry to be used: in the registry to be used:
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" / algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
"SHA-256-sess" / "SHA-512-256" / "SHA-512-256-sess" / token ) "SHA-256-sess" /
"SHA-512-256" / "SHA-512-256-sess" / token )
3. Security Considerations 3. Security Considerations
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 [RFC2617] but its use is remains only for backward compatibility with [RFC2617], but its use
NOT RECOMMENDED. is NOT RECOMMENDED.
This opens the system to the potential of a downgrade attack by an This opens the system to the potential for a downgrade attack by an
on-path attacker. The most effective way of dealing with this type on-path attacker. The most effective way of dealing with this type
of attack is to either validate the client and challenge it of attack is to either validate the client and challenge it
accordingly, or remove the support for backward compatibility by not accordingly or remove the support for backward compatibility by not
supporting MD5. supporting MD5.
See section 5 of [RFC7616] for a detailed security discussion of the See Section 5 of [RFC7616] for a detailed security discussion of the
Digest scheme. Digest Access Authentication scheme.
4. IANA Considerations 4. IANA Considerations
[RFC7616] defines an IANA registry named "Hash Algorithms for HTTP [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP
Digest Authentication" to simplify the introduction of new algorithms Digest Authentication" to simplify the introduction of new algorithms
in the future. This document specifies that algorithms defined in 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.
This document has no actions for IANA. This document has no actions for IANA.
5. Acknowledgments 5. References
The author would like to thank the following individuals for their
careful reviews, comments, and suggestions: Paul Kyzivat, Olle
Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga
Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,
Barry Leiba, Roni Even, Eric Vyncke, Benjamin Kaduk, Alissa Cooper,
Roman Danyliw, and Alexey Melnikov, and Maxim Sobolev. .
6. References
6.1. Normative References 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2014. RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Access Authentication", RFC 7616, September 2015. Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA2] "SHA: SECURE HASH STANDARD, FIPS 180-2", August 2002. [SHA2] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
FIPS 180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
6.2. Informative References 5.2. Informative References
[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Lawrence, S., J. Leach, P., Luotonen, A., and L. C. Leach, P., Luotonen, A., and L. Stewart, "HTTP
Stewart, "HTTP Authentication: Basic and Digest Access Authentication: Basic and Digest Access Authentication",
Authentication", RFC 2617, June 1999. RFC 2617, DOI 10.17487/RFC2617, June 1999,
<https://www.rfc-editor.org/info/rfc2617>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
Acknowledgments
The author would like to thank the following individuals for their
careful review, comments, and suggestions: Paul Kyzivat, Olle
Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga
Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,
Barry Leiba, Roni Even, Eric Vyncke, Benjamin Kaduk, Alissa Cooper,
Roman Danyliw, Alexey Melnikov, and Maxim Sobolev.
Author's Address Author's Address
Rifaat Shekh-Yusef Rifaat Shekh-Yusef
Avaya Avaya
425 Legget Dr. 425 Legget Dr.
Ottawa, Ontario Ottawa Ontario
Canada Canada
Phone: +1-613-595-9106 Phone: +1-613-595-9106
EMail: rifaat.ietf@gmail.com Email: rifaat.ietf@gmail.com
 End of changes. 70 change blocks. 
172 lines changed or deleted 179 lines changed or added

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