[OpenSIPS-Devel] New contribution, uac_auth() in request route

[Bogdan-Andrei Iancu]

Hi Michael,

Michael Schloh von Bennewitz wrote:
> Hello Bogdan,
>
> On Tues., Feb. 16, 2010, Bogdan-Andrei Iancu wrote:
>   
>> 1) what if the client is really dummy or does not have support for
>> auth at all, so you cannot rely on the UAC to send a second INVITE
>> with credentials.
>>
>>     
> But this question is equally valid for regular usage of the auth
> module. If an administrator assumes that only UACs which will
> regiser are able to answer 401 or 407 replies correctly then
> he will have problems when a special case scenario appears (like
> the one you mention.) If I understand your question correctly,
> then the administrator knows to use uac_auth or proxy_challenge
> only when the client is not so dumb.
>   
Not really - is the regular usage of uac_auth(), the UAC sends an INVITE 
and opensips is doing the rest of the job (intercepting the 401 and 
generating a new INVITE), totally transparent for UAC  - here the UAC 
does not have to do anything extra.
>   
>> 2) what if the client  -  server relation is not passwd based, so again 
>> the UAC cannot generate the INVITE with credentials
>>
>>     
> Yes, the unmodified (in 1.6.X) uac_auth function only provides password
> based authentication. My changes simply extend the possible range of
> the unmodified uac_auth function to be usable from the request route
> as well. If the client must authenticate using a nonpassword based
> algorithm, then it's up to the admin to find a way to provide that.
> He won't be using uac_auth at all, so my changes are not relevant.
>   
That is correct, but my question was actually overlapping with the first 
one - about the capability of a client to send a second INVITE, in 
response to a 401/407. Only the scenario was different than in the first 
question:
    scenario 1) - there is no auth relation between UAC and opensips, so 
UAC cannot handle any auth challenge at all
    scenario 2) - there is a non-passwd auth relation between UAC and 
opensips, so UAC cannot handle any auth passwd-based challenge at all
>   
>> 3) what if the the UAC is also authenticating to the server :
>>       UAC   -> INVITE                  ->  proxy
>>       UAC   <- 407 proxy               <-  proxy
>>       UAC   -> INVITE+res_proxy        ->  proxy
>>                                            proxy  -> INVITE -> GW
>>                                            proxy  <- 407 gw <- GW
>>       UAC   <- 407 gw                  <-  proxy
>>     
>         UAC   -> INVITE+res_proxy+res_gw ->  proxy  -> INVITE -> GW
>                                              proxy  <- 200 OK <- GW
>         UAC   <- 200 OK                  <-  proxy
>
>   
>>    at this moment the uac may stop responding (as it cannot answer
>>    to the new request - unknown realm, or because it things the
>>    first auth failed)
>>
>>     
> I've tested this with only one softphone and one hardphone. Both
> Twinkle and Snom do indeed stop responding, but only if both proxy
> and gateway specify the same authentication realm. Probably this
> confuses the phone's software which thinks the authentication
> requests originated from the same server (not true.) This can be
> solved by the admin who has control over the auth module's realm
> logic.
>
> If there is no realm conflict then after the UAC tries once to
> authenticate to the SIP proxy it will accept 407 again and try
> to authenticate a second time, appending both Proxy-Authorization
> strings (one for each realm) to the new (third INVITE) request.
>
> Unfortunately, to solve the problem of a challenge loop the admin
> probably must use:
>
>   modparam("auth", "disable_nonce_check", 1)
>
> ...to allow OpenSIPS to pass the third INVITE without challenging.
>   
Right.
> I doubt that the SIP RFCs specify such multiple challenge results,
> so if that's true then the choice is up to us. The question is:
>
>   Do we want to distribute and support a hacky way
>   to provide multiple authentication stages?
>   
Normally, this is a job for a b2bua and not for a proxy. I agree that 
what we have so far is also a hack, so I do not expect the miracle- 
solution here :). I'm not against hacking the hack, but I'm just trying 
to see the design of the new hack and how it should work in some cases.
>   Or would we rather restrict the admin to a single
>   authentication stage?
>   
That's impossible in same cases.

Regarding your solution, I see it as a clean idea -forcing the cseq 
change from the UAC side- , but I'm so positive about who you try to 
force the UAC the re-send the request (via a challenge) - what about 
trying it via a 300 redirect (to the same destination) ?
> There's a chance to do this better using new B2B logic, but I
> kind of doubt that it would be much less hacky than this. Don't
> forget, the unmodified uac_auth function is hacky itself. It
> doesn't conform to RFC 2543 recommending sequential CSEQ numbers.
>   
Again, right, but also making auth with b2bua requires some more work - 
it will not work out of the package.

Regards,
Bogdan
> Regards,
> Michael
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro