The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (22)
MD5, the default hash algorithm in RFC 3261's Digest Access Authentication, has been demonstrated to be non-collision-resistant and is now considered a bad choice for a hash function. This document extends SIP to support stronger algorithms from the 'Hash Algorithms for HTTP Digest Authentication' IANA registry, such as SHA-256 and SHA-512/256.
RFC 7616 requires a server to verify that the URI in the request line and the URI in the Authorization header point to the same resource. In SIP, these two URIs may refer to different users due to proxy forwarding, so the requirement is relaxed to allow acceptance even when they differ.
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'.
This document replaces the reference to RFC 2617 (obsolete) in RFC 3261 with RFC 7616 for Digest Access Authentication, while maintaining backward compatibility. The HTTP Digest rules apply to SIP with 'HTTP/1.1' replaced by 'SIP/2.0' and several SIP-specific modifications.
A UAS MAY add multiple WWW-Authenticate/Proxy-Authenticate header fields to allow the UAS to utilize the best available algorithm supported by the client.
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.
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.
If a request is forked, 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.
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.
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.
SIP clients and servers MUST NOT accept or request Basic authentication.
The UAS MUST add multiple WWW-Authenticate/Proxy-Authenticate 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 'uri' parameter of the Authorization header field MUST be enclosed in quotation marks.
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.
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.
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.
The A2 value calculation for message integrity in Digest Access Authentication: when the entity-body is empty (SIP messages with no body), the hash of the entity-body resolves to the hash of an empty string, e.g., SHA-256("") = 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'.
RFC 7616 defines the 'Hash Algorithms for HTTP Digest Authentication' IANA registry. This document specifies that algorithms defined in that registry may be used in SIP digest authentication, extending SIP beyond the single MD5 algorithm specified in RFC 3261.
The MD5 algorithm remains supported only for backward compatibility with RFC 2617, but its use is NOT RECOMMENDED. Supporting MD5 alongside stronger algorithms opens the system to a potential downgrade attack by an on-path attacker. Mitigations include validating the client and challenging accordingly, or removing MD5 support entirely.
Digest values are encoded in lowercase hexadecimal. For SHA-256 or SHA-512/256, the digest is represented as 64 hexadecimal characters, converting bits from most significant to least significant, four bits at a time.
The algorithm parameter is extended to: algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" / "SHA-256-sess" / "SHA-512-256" / "SHA-512-256-sess" / token ), allowing any algorithm in the IANA registry.
The request-digest field is extended to allow for different digest sizes: 'request-digest = LDQUOT *LHEX RDQUOT'. The number of hex digits is implied by the algorithm used, with a minimum size of 32. An empty value is allowed when the UAC has not yet received a challenge.