Summary:ASTERISK-04700: [patch] chan_sip.c: qop=auth syntax error
Reporter:claas (claas)Labels:
Date Opened:2005-07-27 06:24:03Date Closed:2008-01-15 15:43:23.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk.log
( 1) qop.r796.txt
Description:The current cvs version sets qop="auth", which is wrong.
It has to be qop=auth (without double quotes).

This prevents me to register at my registrar.


In the Basic Rules of RFC3261, the auth parameter is defined like this:

Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
message-qop = "qop" EQUAL qop-value
qop-value = "auth" / "auth-int" / token

That means there should be no double quote around the qop-value. An
example of the Authorization header field is :

Authorization: Digest username="bob",
Comments:By: Olle Johansson (oej) 2005-07-27 10:24:23

From RFC2617:
        HTTP/1.1 401 Unauthorized
        WWW-Authenticate: Digest

The client may prompt the user for the username and password, after which it will respond with a new request, including the following Authorization header:

        Authorization: Digest username="Mufasa",

Seems like both examples are used. This is the RFC for HTTP Digest authentication that RFC 3261 refers to... Let's dig deeper into this.

By: Olle Johansson (oej) 2005-07-27 10:30:22

From the same RFC:
    This directive is optional, but is made so only for backward
    compatibility with RFC 2069(-> 2617draft) [6]; it SHOULD be used by all
    implementations compliant with this version of the Digest scheme.
    If present, it is a quoted string of one or more tokens indicating
    the "quality of protection" values supported by the server.  The
    value "auth" indicates authentication; the value "auth-int"
    indicates authentication with integrity protection; see the

    descriptions below for calculating the response directive value for
    the application of this choice. Unrecognized options MUST be
A quoted string means we're doing it right and your registrar's software is doing it wrong - or?

By: claas (claas) 2005-07-27 13:16:11

Okay, i see, that both examples are used in RFC, with and without double quotes.
I don't know which is the right way, yet.
The confusing thing is that I have got both ways in the syslog of my sipura:

When my Sipura ATA (client) sends messages, it uses qop=auth and all responses
from the providers SER are containing qop="auth" (sip.qsc.de).

With another provider (iphone.freenet.de), also the SER sends qop=auth.

By: Olle Johansson (oej) 2005-07-28 02:38:34

Seems like a lot of developers had a problem finding the proper RFC, and since RFC3261 copied the bad example from RFC2617 it's even more confusing. RFC 3261 says very clear that RFC2617 is the standard for Digest Auth that should be used, and RFC2617 defines qop as a quoted string.

Regardless of standard stuff, there's an implementation that is broken here and requires no quotation mark. I am hesitant to change Asterisk, since other implementations may require the quotation mark (which is correct). Can you give me a SIP debug of the dialog, so I see what happens, what error message we get from the other side?

By: claas (claas) 2005-07-28 05:11:42

Sorry, but where does RFC2617 define qop as a quoted string?

There is a difference between qop in a WWW-Authenticate block and in an Authorization block. In the first place, there have to be quotes around (qop="auth,auth-int") and in the second place it has to be a single token,
e.g.: qop=auth or qop=noauth or qop= .

From RFC2617:
    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 [6], but SHOULD be used if the server indicated that qop
    is supported by providing a qop directive in the WWW-Authenticate
    header field.

By: Frank Sautter (xylome) 2005-07-28 08:13:27

added patch adressing this problem.
disclaimer is on file

By: Olle Johansson (oej) 2005-07-28 09:25:01

So qop-options that I found is wrong, and the qop definition you found is correct. I stand corrected :-)

Thank's for helping to read the RFCs! It's messy, but usually we get there by working together.

By: Olle Johansson (oej) 2005-07-28 09:26:21

Recommended for CVS.

By: claas (claas) 2005-07-28 10:56:40

Yeah, reading RFC is sometimes a pain.
Nice that we solved it together.

Thanks to you, too :)

By: Mark Spencer (markster) 2005-08-02 22:32:06

Fixed in CVS head.

By: Digium Subversion (svnbot) 2008-01-15 15:43:23.000-0600

Repository: asterisk
Revision: 6260

U   trunk/channels/chan_sip.c

r6260 | markster | 2008-01-15 15:43:23 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix qop syntax (bug ASTERISK-4700)