[Users] Re: qop="auth" with uac_auth

[Andreas Heise]

Hi Bogdan,

yes it will be a good workaround for a lot of users, but we still hope 
for real qop support in the future ;-) 

best regards,
Andreas


Bogdan-Andrei Iancu schrieb:
> Hi Andreas, Hi Thomas,
>
> unfortunately there was not enough time to include QOP support in uac 
> module, but what we can do is to just remove the error (as Thomas 
> suggested). If the auth server can fallback and ignore the lack of qop 
> in response, ok, otherwise it wil not work anyhow....so no harm done, 
> but some more cases will work.
>
> regards,
> bogdan
>
> Andreas Heise wrote:
>>
>> Thomas Gelf schrieb:
>>> Same problem here. As I make intensive use of uac_auth() and need to
>>> authenticate against Proxies sending me the qop parameter in their
>>> authentication challenge, in the meantime I helped myself by simply
>>> commenting out the "goto error" section in modules/uac/auth_hdr.c.
>>>
>>> I just changed
>>>
>>>>             case QOP_STATE:
>>>>                 /* TODO - add qop support */
>>>>                 LOG(L_ERR,"ERROR:uac:parse_authenticate_body: no 
>>>> qop support "
>>>>                     "for the moment :-(\n");
>>>>                 goto error;
>>>>                 auth->qop = val;
>>>>                 break;
>>>
>>> to
>>>
>>>>             case QOP_STATE:
>>>>                 /* TODO - add qop support */
>>>>                 break;
>>>
>>> somewhere around line 215.
>>>
>>
>> I already used this "fix" to ignore the qop value and from my opinion
>> it should be OK if qop=auth, because the result of the digest should
>> be the same for qop = "auth" or unspecified see page 14 in the
>> following draft of an example
>>
>> http://www.softarmor.com/wgdb/docs/draft-smith-sip-auth-examples-00.txt
>>
>> but! by this way the Authenticated Request from OpenSER does not
>> contains qop="auth" in the response which is maybe a problem for
>> some gateways.
>>
>>
>>> Sure, that's not the way things should be solved - but at the moment
>>> it fits my needs. And as of RFC 2617 I should be fine - not sure about
>>> RFC3261. Section 22.4(.8) states that "the 'qop' parameter must unfor-
>>> tunately remain optional for clients and servers to receive" - so imo
>>> it should be ok. (?)
>>>
>>> To be sincere I did never REALLY understand this whole qop thingy. 
>>> Afaik
>>> OpenSER isn't able to increment cseq in it's UAC module as this module
>>> doesn't have any dialog support. And in my believes that's why the UAC
>>> module has been designed to fail if it recieves a challenge containing
>>> qop (because it isn't able to do it the right way).
>>>
>> I believe that the fail is wanted to be able to forward the 401|407 
>> to the
>> calling client which is maybe able to answer a challenge which 
>> contains qop
>>
>>> Nonetheless with my little "patch" everything "just works":
>>>
>>> -> UAC module sends an INVITE request
>>> -> remote sends it's 407 message, containing nonce and qop (but no
>>>    cnonce)
>>> -> 407 gets acknowledged
>>> -> UAC module ignores the qop (as error handling is commented out) and
>>>    sends a new INVITE request with the correct nonce (and is therefore
>>>    doing correct digest authentication) but with wrong cseq (eg same
>>>    cseq as previous INVITE = cseq supplied from client)
>> but the response does not contains the chosen qop value
>>>  -> remote party (proxy asking for authentication) accepts my INVITE
>>>
>>> I'm doing so since AVP support has been added to uac_auth() - see also
>>> http://www.openser.org/pipermail/devel/2006-March/002162.html and it
>>> worked fine with all versions of OpenSER I compiled since this date.
>>>
>>> It would be great if (unless cseq incrementation support will once be
>>> added to UAC) upstream sources could comment out this section (as I
>>> showed above).
>>>
>>> I don't see any grave issues in doing so - and it would probably help
>>> people who need this feature. Would such a modification be an option 
>>> for
>>> OpenSER 1.2? You could also add an optional swich like
>>>
>>> > modparam("uac","ignore_qop",1);
>>>
>> I think we can save the time to build a modparam, this time could be 
>> better used
>> for a final solution, because it's still not working with 
>> qoq="auth-int" or qop="auth-int, auth"
>> and if it's really needed everybody can uncomment and compile it self.
>>
>> I found an answer from Bogdan in the devel list that the cseq  and qop
>> limits will not be removed with 1.2
>>
>>    http://www.mail-archive.com/devel@openser.org/msg04951.html
>>
>> but I hope in the next roadmap for 1.3 it can be changed for optional to
>> todo to get this feature......
>>
>>> Please let me know if you like my proposal or if I'm talking 
>>> bullshit :)
>> no it's not bullshit ;-) as the problem is really old.......
>>
>> regards,
>> Andreas
>>>
>>> Kind regards,
>>> Thomas Gelf
>>>
>>>
>>> Andreas Heise schrieb:
>>>>
>>>> Hello,
>>>> since a lot of providers has change there authentication to qop="auth"
>>>> the uac_auth(); function of the uac module can't use anymore.
>>>>
>>>> by google I found a lot of requests for qop with uac_auth and also
>>>> the official feature request 1345887.
>>>> Is a target date known for a solution, maybe it's possible with 1.2.0?
>>>>
>>>> Feature Request [ 1345887 ] Implement qop functionality in uac module
>>>>
>>>> p.s.: I know it's on the road map, but it is needed so often......
>>>>
>>>> thanks.
>>>> Andreas
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>