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

[Michael Schloh von Bennewitz]

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.

>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.

>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.

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?

  Or would we rather restrict the admin to a single
  authentication stage?

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.

Regards,
Michael

-- 
Michael Schloh von Bennewitz
http://michael.schloh.com/