draft-ietf-sipcore-digest-scheme-05.txt   draft-ietf-sipcore-digest-scheme-06.txt 
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) May 30, 2019 Updates: 3261 (if approved) July 2, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: December 1, 2019 Expires: January 3, 2020
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-ietf-sipcore-digest-scheme-05 draft-ietf-sipcore-digest-scheme-06
Abstract Abstract
This document updates the Digest Access Authentication scheme used by This document updates [RFC3261] by updating the Digest Access
the Session Initiation Protocol (SIP) to add support for more secure Authentication scheme used by the Session Initiation Protocol (SIP)
digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the to add support for more secure digest algorithms, e.g. SHA-256 and
broken MD5 algorithm. SHA-512-256, to replace the broken MD5 algorithm, which might be used
for backward compatibility reasons only.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2019. This Internet-Draft will expire on January 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 25 skipping to change at page 2, line 27
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3 2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3
2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3
2.2. Representation of Digest Values . . . . . . . . . . . . . 4 2.2. Representation of Digest Values . . . . . . . . . . . . . 4
2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4
2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 2.6. HTTP Digest Authentication Scheme Modifications . . . . . 5
2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 7 2.7. Augmented BNF for the SIP . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The SIP protocol [RFC3261] uses the same mechanism used by the HTTP The Session Initiation Protocol [RFC3261] uses the same mechanism
protocol for authenticating users, which is a simple challenge- that the Hypertext Transfer Protocol (HTTP) uses for authenticating
response authentication mechanism that allows a server to challenge a users. This mechanism is called Digest Access Authentication, and it
client request and allows a client to provide authentication is a simple challenge-response mechanism that allows a server to
information in response to that challenge. challenge a client request and allows a client to provide
authentication information in response to that challenge. The
version of Digest Access Authentication that [RFC3261] references is
specified in [RFC2617].
The SIP protocol uses the Digest Authentication scheme that is used The default hash algorithm for Digest Access Authentication is MD5.
with the HTTP authentication mechanism, which uses MD5 as the default However, it has been demonstrated that the MD5 algorithm is not
algorithm. collision resistant, and is now considered a bad choice for a hash
function [RFC6151].
The HTTP Digest Access Authentication [RFC7616] document defines the The HTTP Digest Access Authentication [RFC7616] document obsoletes
Digest Authentication scheme and defines a few algorithms that could [RFC2617] and adds stronger algorithms that can be used with the
be used with the Digest Authentication scheme, and establishes a Digest Authentication scheme, and establishes a registry for these
registry for these algorithms to allow for additional algorithms to algorithms, known as the "Hash Algorithms for HTTP Digest
be added in the future. Authentication" registry, so that algorithms can be added in the
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 defined in the "Hash Algorithms for SIP to support the algorithms listed in the "Hash Algorithms for HTTP
HTTP Digest Authentication" registry defined by [RFC7616]. Digest Authentication" 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. SIP Digest Authentication Scheme Updates 2. SIP Digest Authentication Scheme Updates
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" registry described in [RFC7616].
It replaces the reference to [RFC2617] with a reference to [RFC7616] It replaces the reference to [RFC2617] with a reference to [RFC7616]
in [RFC3261], and describes the modifications to the usage of the in [RFC3261], and describes the modifications to the usage of the
Digest mechanism in [RFC3261] resulting from that reference update. Digest mechanism in [RFC3261] resulting from that reference update.
It adds support for the SHA-256 and SHA-512/256 algorithms. It adds It adds support for the SHA-256 and SHA-512/256 algorithms. It adds
required support for the "qop" option. It provides additional UAC required support for the "qop" parameter. It provides additional
and UAS procedures regarding usage of multiple SIP Authorization, User Agent Client (UAC) and User Agent Server (UAS) procedures
WWW-Authenticate and Proxy-Authenticate header fields, including in regarding usage of multiple SIP Authorization, WWW-Authenticate and
which order to insert and process them. It provides guidance Proxy-Authenticate header fields, including in which order to insert
regarding forking. Finally, it updates the SIP protocol BNF as and process them. It provides guidance regarding forking. Finally,
required by the updates. it updates the SIP BNF 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 scheme has an 'algorithm' parameter that specifies the
algorithm to be used to compute the digest of the response. The IANA algorithm to be used to compute the digest of the response. The IANA
registry named "HTTP Digest Hash Algorithms" specifies the algorithms registry named "HTTP Digest Hash Algorithms" specifies the algorithms
that correspond to 'algorithm' values. 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
registered algorithm. algorithm listed in the "Hash Algorithms for HTTP Digest
Authentication" registry.
A UAS prioritizes which algorithm to use based on the ordering of the A UAS prioritizes which algorithm to use based on the ordering of the
challenge header fields in the response it is processing. That challenge header fields in the response it is processing. That
process is specified in section 2.3 and parallels the process used in process is specified in section 2.3 and parallels the process used in
HTTP specified by [RFC7616]. HTTP 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
skipping to change at page 4, line 42 skipping to change at page 5, line 8
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 that 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, followed by the less preferred algorithms. The
UAS cannot assume that the client will use the algorithm specified at UAS cannot assume that the client will use the algorithm specified at
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. topmost header field of any one of the realms.
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, e.g. if the UAC then it SHOULD abandon attempts to send the request, e.g. if the UAC
does not have credentials or has stale credentials for any of the does not have credentials or has stale credentials for any of the
realms, unless a local policy dictates otherwise. realms, unless a local policy dictates otherwise.
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 introduces some clarification to it forks a request. This section clarifies that operation.
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 responses to the forked request MUST be placed into the single
response that is sent by the forking proxy to the UA. 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 from one received response into the single Authenticate header fields from one received response into the single
response it MUST maintain the order of these header fields. The response it MUST maintain the order of these header fields. The
ordering of the header field values from the various proxies is not ordering of the header field values from the various proxies is not
significant. significant.
2.6. HTTP 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 authentication scheme to SIP. The SIP
scheme usage is similar to that for HTTP. For completeness, the 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 7 and 8 [RFC3261]; the only semantic changes are specified in bullets 7 and 8
below. 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 authentication follow those defined in HTTP,
with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the
differences: following differences:
1. The URI included in the challenge has the following BNF: 1. The URI included in the challenge has the following BNF:
URI = Request-URI ; as defined in [RFC3261], Section 25 URI = Request-URI ; as defined in [RFC3261], 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 BNF for digest-uri-value is:
skipping to change at page 6, line 24 skipping to change at page 6, line 33
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 field
point to the same resource. In a SIP context, these two URIs may point to the same resource. In a SIP context, these two URIs may
refer to different users, due to forwarding at some proxy. refer to different users, due to forwarding at some proxy.
Therefore, in SIP, a server MAY check that the Request-URI in the Therefore, in SIP, a UAS MAY check that the Request-URI in the
Authorization header field value corresponds to a user for whom the Authorization/Proxy-Authorization header field value corresponds to a
server is willing to accept forwarded or direct requests, but it is user for whom the UAS is willing to accept forwarded or direct
not necessarily a failure if the two fields are not equivalent. requests, but it is not necessarily a failure if 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 authentication scheme, implementers
should assume, when the entity-body is empty (that is, when SIP should assume, when the entity-body is empty (that is, when SIP
messages have no body) that the hash of the entity-body resolves to messages have no body) that the hash of the entity-body resolves to
the hash of an empty string: the hash of an empty string:
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. Servers MUST be able to properly handle "qop" parameter received 8. A UAS MUST be able to properly handle "qop" parameter received in
in an authorization header field, and clients MUST be able to an Authorization/Proxy-Authorization header field, and a UAC MUST be
properly handle "qop" parameter received in WWW-Authenticate and able to properly handle "qop" parameter received in WWW-Authenticate
Proxy-Authenticate header fields. However, for backward and Proxy-Authenticate header fields. However, for backward
compatibility reasons, the "qop" parameter is optional for compatibility reasons, the "qop" parameter is optional for
RFC3261-based clients and servers to receive. RFC3261-based clients and servers to receive.
Servers 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 clients MUST send the Proxy-Authenticate header field values, and a UAC MUST send the "qop"
"qop" parameter in any resulting authorization header field. parameter in any resulting authorization header field.
The usage of the Authentication-Info header field continue 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 the SIP Protocol 2.7. Augmented BNF for the SIP
This document updates the Augmented BNF for the SIP Protocol as This document updates the Augmented BNF [RFC5234] for SIP as follows.
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. algorithm used.
It extends the algorithm parameter as follows to allow for any It extends the algorithm parameter as follows to allow for any
algorithm in the registry to be used: algorithm in the registry to be used:
algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256"
/ token ) / token )
3. Security Considerations 3. Security Considerations
This specification adds new secure algorithms to be used to with the This specification adds new secure algorithms to be used with the
Digest mechanism to authenticate users, but leaves the broken MD5 Digest mechanism to authenticate users, but leaves the broken MD5
algorithm for backward compatibility. algorithm for backward compatibility.
This opens the system to the potential of a downgrade attack by man- This opens the system to the potential of a downgrade attack by man-
in-the-middle. The most effective way of dealing with this type of in-the-middle. The most effective way of dealing with this type of
attack is to either validate the client and challenge it accordingly, attack is to either validate the client and challenge it accordingly,
or remove the support for backward compatibility by not supporting or remove the support for backward compatibility by not supporting
MD5. 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 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.
5. Acknowledgments 5. Acknowledgments
The author would like to thank the following individuals for their The author would like to thank the following individuals for their
careful reviews, comments, and suggestions: Paul Kyzivat, Olle careful reviews, comments, and suggestions: Paul Kyzivat, Olle
Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga
Asveren, Christer Holmberg, and Brian Rosen. Asveren, Christer Holmberg, and Brian Rosen.
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 8, line 38 skipping to change at page 9, line 5
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", RFC 7616, September 2015. Access Authentication", RFC 7616, September 2015.
6.2. Informative References 6.2. Informative References
[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D.
Lawrence, S., J. Leach, P., Luotonen, A., and L. C. Lawrence, S., J. Leach, P., Luotonen, A., and L. C.
Stewart, "HTTP Authentication: Basic and Digest Access Stewart, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
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. 29 change blocks. 
58 lines changed or deleted 76 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/