powered by Jive Software

SIP registration issues (missing cnonce)

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

Hey, haven’‘t seen any responses here… is this the right place to post issues? I’'m continuing to test and have other issues to report… where should I be sending them?

Aside from signaling problems, the audio quality has been fairly poor on calls that I’'ve been able to successfully connect. What underlying media library is being used?

Cheers,

Dan

Hello,

I couldn’t notice the difference between both negotiations as both has “nonce” attribute especified.

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;transport=udp”,response=“dd2cc3756a5c6b8ee4ce359405 d0ddf3”,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="b1a07fd5d80fb8fb4c9c6898f

Are you refering to cnonce?

$cnonce = md5_hex("$useragent:$clientpassword:$retsrequestid:$nonce"); Cheers,
Thiago