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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu Feb 8 10:12:47 CET 2007


Hi Andreas,

ok - I made the fix on CVS head. I say qop support will definitely be in 
the 1.3.x release ;).

regards,
bogdan

Andreas Heise wrote:
> 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
>>>
>>
>
>





More information about the Users mailing list