I’'ve been testing Spark (SiPark) with a number of proxy registrars, and it seems to be having trouble with registrars that are based on the NIST SIP stack (which I believe is what is embedded in Spark). The issue seems to be a missing cnonce value on the authenticate line.
Here are the relevant headers from the failed scenario:
The challenge from the registrar (packaged in a 401):
WWW-Authenticate: Digest realm=“proximiti”,nonce=“156730866”,qop=“auth”,algorithm=MD5
The response from SiPark (note the missing cnonce):
Authorization: Digest username=“23”,realm=“proximiti”,nonce=“156730866”,uri=“sip:208.38.169.93:5060;t ransport=udp”,response=“dd2cc3756a5c6b8ee4ce359405d0ddf3”,algorithm=MD5
After this, the registrar responds with a 403 forbidden.
Here’'s an example of another client that successfully registered with the same registrar:
The challenge from the registrar (packaged in a 401):
WWW-Authenticate: Digest realm=“proximiti”,nonce=“1110991143”,qop=“auth”,algorithm=MD5
The response from the client (note the cnonce):
Authorization: Digest username=“23”,realm=“proximiti”,nonce=“1110991143”,response=“b1a07fd5d80fb8fb4c 9c6898fed8bfe2”,uri=“sip:208.38.169.93”,qop=auth,cnonce=“1110991143”,nc=00000001,algorithm=MD5
I am by no means an expert in SIP or MD5 authentication, so I might be chasing a red herring. On the other hand, this is what the RFC has to say:
RFC 2617:
qop
Indicates what “quality of protection” the client has applied to
the message. If present, its value MUST be one of the alternatives
the server indicated it supports in the WWW-Authenticate header.
These values affect the computation of the request-digest. Note
that this is a single token, not a quoted list of alternatives as
in WWW- Authenticate. This directive is optional in order to
preserve backward compatibility with a minimal implementation of
RFC 2069 , but SHOULD be used if the server indicated that qop
is supported by providing a qop directive in the WWW-Authenticate
header field.
cnonce
This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The cnonce-value is an opaque
quoted string value provided by the client and used by both client
and server to avoid chosen plaintext attacks, to provide mutual
authentication, and to provide some message integrity protection.
See the descriptions below of the calculation of the response-
digest and request-digest values.
In this case, you’'ll note the qop is present in the challenge, so by the RFC, the softphone should be sending a cnonce.
Cheers,
Dan