The Session Initiation Protocol (SIP) Digest Access Authentication SchemeAvaya425 Legget Dr.OttawaOntarioCanada+1-613-595-9106rifaat.ietf@gmail.com
RAI
SIP CoreDigest Auth
This document updates RFC 3261 by modifying the Digest Access
Authentication scheme used by the Session Initiation Protocol (SIP) to add support
for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the
obsolete MD5 algorithm.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Table of Contents
. Introduction
. Terminology
. Updates to the SIP Digest Access Authentication Scheme
. Hash Algorithms
. Representation of Digest Values
. UAS Behavior
. UAC Behavior
. Forking
. HTTP Digest Authentication Scheme Modifications
. ABNF for SIP
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Author's Address
Introduction
The Session Initiation Protocol uses the same mechanism
as the Hypertext Transfer Protocol (HTTP) does for authenticating
users. This mechanism is called "Digest Access Authentication". It is a simple challenge-response mechanism that allows a server
to challenge a client request and allows a client to provide
authentication information in response to that challenge. The
version of Digest Access Authentication that references
is specified in .
The default hash algorithm for Digest Access Authentication is MD5.
However, it has been demonstrated that the MD5 algorithm is not
collision resistant and is now considered a bad choice for a hash
function (see ).
The HTTP Digest Access Authentication document obsoletes
and adds stronger algorithms that can be used with
the Digest Access Authentication scheme and establishes a registry for
these algorithms, known as the "Hash Algorithms for HTTP Digest
Authentication" IANA registry, so that algorithms can be added in the
future.
This document updates the Digest Access Authentication scheme used
by SIP to support the algorithms listed in the "Hash Algorithms
for HTTP Digest Authentication" IANA registry defined by .
Terminology
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
when, and only when, they appear in all capitals, as shown here.
Updates to the SIP Digest Access Authentication Scheme
This section describes the modifications to the operation of the
Digest mechanism as specified in in order to support
the algorithms defined in the "Hash Algorithms for HTTP Digest Authentication"
IANA registry described in .
It replaces the reference used in for Digest Access Authentication,
substituting for the obsolete , and describes
the modifications to the usage of the Digest mechanism in
resulting from that reference update. It adds support for the SHA-256 and SHA-512/256 algorithms .
It adds required support for the "qop" parameter. It provides additional User Agent Client (UAC)
and User Agent Server (UAS) procedures regarding usage of multiple SIP Authorization,
WWW-Authenticate, and Proxy-Authenticate header fields, including the order
in which to insert
and process them. It provides guidance regarding forking. Finally, it updates the SIP ABNF
as required by the updates.
Hash Algorithms
The Digest Access Authentication scheme has an "algorithm" parameter that specifies the
algorithm to be used to compute the digest of the response. The "Hash
Algorithms for HTTP Digest Authentication" IANA registry specifies
the algorithms that correspond to 'algorithm' values.
specifies only one algorithm, MD5, which is used by default.
This document extends to allow use of any algorithm listed in
the "Hash Algorithms for HTTP Digest Authentication" IANA registry.
A UAS prioritizes which algorithm to use based on its policy,
which is specified in and parallels the process used in
HTTP specified by .
Representation of Digest Values
The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least
significant bit, four bits at a time, to the ASCII representation as
follows. Each set of four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef; that is, binary 0000 is
represented by the character '0', 0001 is represented by '1', and so on up 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
hexadecimal characters.
UAS Behavior
When a UAS receives a request from a UAC, and an acceptable
Authorization header field is not received, the UAS can challenge the
originator to provide credentials by rejecting the request with a
401/407 status code with the WWW-Authenticate/Proxy-Authenticate
header field, respectively. The UAS MAY add multiple WWW-Authenticate/Proxy-Authenticate
header fields to allow the UAS to utilize the best available
algorithm supported by the client.
If the UAS challenges the originator using multiple WWW-Authenticate/Proxy-Authenticate
header fields with the same realm, then each of these
header fields MUST use a different digest algorithm. The UAS 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 algorithm at the top. The UAS cannot assume that the client
will use the algorithm specified in the topmost header field.
UAC Behavior When the UAC receives a response with multiple WWW-Authenticate/Proxy-Authenticate
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.
When the UAC receives a 401 response with multiple WWW-Authenticate
header fields with different realms, it SHOULD retry and add an
Authorization header field containing credentials that match the topmost
header field of any of the realms unless a local policy dictates otherwise.
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
policy dictates otherwise, e.g., the policy might indicate the use of non-Digest mechanisms.
For example, if the UAC does not have credentials or has stale credentials for
any of the realms, the UAC will abandon the request.
Forking discusses the operation of the proxy-to-user
authentication, which describes the operation of the proxy when it
forks a request. This section clarifies that operation.
If a request is forked, various proxy servers and/or UAs may wish to
challenge the UAC. In this case, the forking proxy server is
responsible for aggregating these challenges into a single response.
Each WWW-Authenticate and Proxy-Authenticate value received in
response to the forked request MUST be placed into the single
response that is sent by the forking proxy to the UAC.
When the forking proxy places multiple WWW-Authenticate and Proxy-Authenticate header
fields received from one downstream proxy into a single response, it MUST maintain
the order of these header fields. The ordering of values received from different downstream
proxies is not significant.
HTTP Digest Authentication Scheme Modifications
This section describes the modifications and clarifications required
to apply the HTTP Digest Access Authentication scheme to SIP. The SIP scheme
usage is similar to that for HTTP. For completeness, the bullets specified
below are mostly copied from ; the
only semantic changes are specified in bullets 1, 7, and 8 below.
SIP clients and servers MUST NOT accept or request Basic
authentication.
The rules for Digest Access Authentication follow those defined in HTTP,
with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
differences:
The URI included in the challenge has the following ABNF :
URI = Request-URI ; as defined in RFC 3261, Section 25
The "uri" parameter of the Authorization header field MUST be
enclosed in quotation marks.
The ABNF for digest-uri-value is:
digest-uri-value = Request-URI
The example procedure for choosing a nonce based on ETag does not
work for SIP.
The text in regarding cache operation does not
apply to SIP.
requires that a server check that the URI in the
request line and the URI included in the Authorization header
field point to the same resource. In a SIP context, these two
URIs may refer to different users due to forwarding at some
proxy. Therefore, in SIP, a UAS MUST check if the Request-URI in the
Authorization/Proxy-Authorization header field value corresponds to a
user for whom the UAS is willing to accept forwarded or direct
requests; however, it MAY still accept it if the two fields are not equivalent.
As a clarification to the calculation of the A2 value for
message integrity assurance in the Digest Access Authentication
scheme, implementers should assume that the hash of the entity-body
resolves to the hash of an empty string when the entity-body is empty (that
is, when SIP messages have no body):
H(entity-body) = <algorithm>("")
For example, when the chosen algorithm is SHA-256, then:
H(entity-body) = SHA-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
A UAS MUST be able to properly handle a "qop" parameter received
in an Authorization/Proxy-Authorization header field, and a UAC MUST be able to
properly handle a "qop" parameter received in WWW-Authenticate and
Proxy-Authenticate header fields. However, for backward compatibility
reasons, the "qop" parameter is optional for clients and
servers based on to receive. 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 Proxy-Authenticate header field values, and a UAC MUST
send the "qop" parameter in any resulting authorization header
field.
The usage of the Authentication-Info header field continues to be
allowed, since it provides integrity checks over the bodies and
provides mutual authentication.
ABNF for SIP
This document updates the ABNF for SIP as
follows.
It extends the request-digest as follows to allow for different
digest sizes:
request-digest = LDQUOT *LHEX RDQUOT
The number of hex digits is implied by the length of the value of the algorithm used,
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.
It extends the algorithm parameter as follows to allow any algorithm
in the registry to be used:
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
"SHA-256-sess" /
"SHA-512-256" / "SHA-512-256-sess" / token )
Security Considerations
This specification adds new secure algorithms to be used with the
Digest mechanism to authenticate users. The obsolete MD5 algorithm
remains only for backward compatibility with , but its use is
NOT RECOMMENDED.
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 of attack is to either validate the
client and challenge it accordingly or remove the support for backward compatibility
by not supporting MD5.
See for a detailed security discussion of
the Digest Access Authentication scheme.
IANA Considerations defines an IANA registry named "Hash Algorithms
for HTTP Digest Authentication" to simplify the introduction of new
algorithms in the future. This document specifies that algorithms defined in
that registry may be used in SIP digest authentication.
This document has no actions for IANA.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): CachingThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.HTTP Digest Access AuthenticationThe Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Secure Hash Standard (SHS)National Institute of Standards and TechnologyInformative ReferencesHTTP Authentication: Basic and Digest Access AuthenticationThis document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK]Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 AlgorithmsThis document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.Acknowledgments
The author would like to thank the following individuals
for their careful review, comments, and suggestions: ,
, , , ,
, , , , ,
, , , , , , , and .
Author's AddressAvaya425 Legget Dr.OttawaOntarioCanada+1-613-595-9106rifaat.ietf@gmail.com