This section describes the modifications to the operation of the Digest mechanism as specified in [RFC 3261
] in order to support the algorithms defined in the "Hash Algorithms for HTTP Digest Authentication" IANA registry described in [RFC 7616
It replaces the reference used in [RFC 3261
] for Digest Access Authentication, substituting [RFC 7616
] for the obsolete [RFC 2617
], and describes the modifications to the usage of the Digest mechanism in [RFC 3261
] resulting from that reference update. It adds support for the SHA-256 and SHA-512/256 algorithms [SHA2
]. It adds required support for the "qop" parameter. It provides additional User Agent Client (UAC) and User Agent Server (UAS) procedures regarding usage of multiple SIP Authorization, WWW-Authenticate, 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.
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 [RFC 3261
] 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 Section 2.3
and parallels the process used in HTTP specified by [RFC 7616
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.
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.
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.
of RFC 3261
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.
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 Section 22.4
of RFC 3261
; 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" [RFC 7616
] replaced by "SIP/2.0" in addition to the following differences:
The URI included in the challenge has the following ABNF [RFC 5234]:
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 [RFC 7234] regarding cache operation does not apply to SIP.
[RFC 7616] 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):
For example, when the chosen algorithm is SHA-256, then:
H(entity-body) = <algorithm>("")
H(entity-body) = SHA-256("") =
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 [RFC 3261] 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.
This document updates the ABNF [RFC 5234
] 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-512-256" / "SHA-512-256-sess" / token )