Digest authentication

13.1 Challenge and response

A SIP server must know who sends a request before it accepts a registration or connects a call. SIP does not send the password to prove this. It uses digest authentication, the same method as HTTP.

The idea is simple:

1. The server sends a challengechallenge. A 401 or 407 response that asks the UAC for credentials.: a random value called a noncenonce. A one-time value from the server. It stops an attacker from reusing an old response..
2. The client mixes the nonce with the password and makes a hash.
3. The client sends only the hash, called the digest responsedigest response. The final hash that proves the UAC knows the password..
4. The server makes the same hash with its copy of the password. If the two hashes are equal, the client knows the password.

An attacker who captures the request sees the hash, but cannot get the password back from it. The nonce changes, so an old hash does not work again.

13.2 Two challenges: 401 and 407

SIP has two challenge responses. They work the same way, but they use different headers. A trace with the wrong pair is a common source of failures.

13.3 The parameters

A challenge and its credentials carry these parameters. The calculator in 13.6 uses all of them.

13.4 The REGISTER challenge

Alice turns on her phone. The phone sends REGISTER to the Registrar for atlanta.example. Step through the flow, then select a line in the inspector to see what it means. The inspector also marks every line that changed since the previous message of the same kind.

Look at F3 and compare it with F1:

• CSeq goes from 1 REGISTER to 2 REGISTER. The retry is a new request.
• The Via branch is new. The retry is a new transaction.
• Call-ID and the From tag do not change. The Registrar can link the two requests.
• The Authorization header is new. It is the only proof of identity.

13.5 The INVITE challenge, step by step

Now Alice calls Bob. Proxy A, the outbound proxy for atlanta.example, wants to know who Alice is before it connects the call. This flow follows RFC 3665 §3.2, with two corrections that RFC 3261 requires (see the note after the flow).

Scroll through the story. The ladder follows the text.

Explore every message

The same flow, with the full inspector. Use ← and → on your keyboard, or select any arrow.

13.6 The calculation

The digest response is three hashes. For MD5 with qop=auth:

HA1      = MD5( username : realm : password )
HA2      = MD5( method : digest-uri )
response = MD5( HA1 : nonce : nc : cnonce : qop : HA2 )

The calculator starts with the values from F4 of the INVITE flow. Change any value and watch the response change. Point at a field to see where it is used.

Things to try:

• Change the method to ACK. The response changes. An ACK copies the INVITE credentials unchanged, so its response was calculated with INVITE, not ACK. RFC 3261 tells the server to accept it anyway.
• Change one letter of the password. Every hash after HA1 changes completely.
• Switch the algorithm to SHA-256. The response is longer: 64 hexadecimal digits.

13.7 Nonces, nonce count, and stale

• The server chooses a new nonce for each challenge. Many servers put a timestamp in it, so they can reject old nonces.
• The client can reuse a nonce for more requests. Each time, it increments nc (00000001, 00000002, …). A server that remembers the last nc can detect a replayed request.
• When a nonce is too old, the server sends a new challenge with stale=true. This means “the password was correct, the nonce was not”. The client retries at once and does not ask the user for the password again.

13.8 Algorithms: MD5, SHA-256, SHA-512-256

RFC 3261 uses MD5 only. RFC 8760 adds SHA-256 and SHA-512-256 for SIP. A server can offer more than one algorithm by sending more than one challenge header for the same realm. It puts them in order of preference.

Many devices still support only MD5. If a server offers only SHA-256 and the phone supports only MD5, the phone cannot answer the challenge, and registration fails.

13.9 More than one challenge

A request can pass through more than one proxy that wants credentials. Proxy A can accept Alice’s credentials, and then Proxy B can challenge too. Proxy A forwards that 407 to Alice. Alice retries with two Proxy-Authorization headers, one for each realm. Each proxy uses only the credentials with its own realm.

Common mistakes

Summary

• Digest authentication proves that the UAC knows the password. The password is never sent.
• 401 + WWW-Authenticate / Authorization comes from a registrar or UAS. 407 + Proxy-Authenticate / Proxy-Authorization comes from a proxy.
• After a challenge, the UAC sends a new request: CSeq + 1, a new branch, the same Call-ID and From tag, and the credentials.
• Every final response to an INVITE needs an ACK. The ACK for a 401 or 407 reuses the INVITE branch.
• response = H(HA1 : nonce : nc : cnonce : qop : HA2), with HA1 = H(username : realm : password) and HA2 = H(method : uri).