[sr-dev] where is s proxy_challenge function?

[Jan Janak]

On Thu, Jul 1, 2010 at 6:01 PM, Iñaki Baz Castillo <ibc at aliax.net> wrote:
> 2010/7/1 Jan Janak <jan at ryngle.com>:
>>> With SER the above problem would be solved by using the same realm for
>>> all the users and domains, but with a constrain: the "username" field
>>> of the creedentials generated by the user should be a full URI
>>> "sip:alice at example.org" (or perhaps also "alice at example.org"), so the
>>> auth module would parse the username and domain from the credentials
>>> "username" field.
>>
>> And this too can already be done, you can simply set the value of the
>> digest_realm variable with something  like:
>>
>> $f.digest_realm = @authorization[...].username.domain
>
> Could you please detail more this code? Let me set an example:

Sorry, I don't have an example at hand, it's been a while since I
worked on this.

> 1) SR multidomain and two users:
>
>  - sip:alice at dom1.org  -  realm = "myserver.org"
>  - sip:alice at dom2.org  -  realm = "myserver.org"
>
>
> 2) An INVITE arrives sent by alice at dom1.org:
>
>  INVITE sip:bob at dom3.org SIP/2.0
>  From: sip:anonymous at invalid-domain.org
>
>
> 3) SR asks for authentication using the shared realm "myserver.org".
>
>
> 4) Let's imagine the UAC sets credentials in these ways:
>
>   4.1)  Digest realm="myserver.org", username="alice"
>   4.2)  Digest realm="myserver.org", username="alice at dom1.org"
>   4.3)  Digest realm="myserver.org", username="sip:alice at dom1.org"
>
>
> So, option 4.1 wouldn't clarify if the authenticated user is
> "sip:alice at dom1.org" or "sip:alice at dom2.org". This is, if the UAC just
> sets its AoR username in the credentials 'username' field then the
> above case cannot work as it would require the proxy using a different
> realm = domain and the INVITE request to contain the domain somewhere
> (i.e. P-Preferred-Identity header which is not the case).

This seems correct to me.

An alternative solution would be making the username 'alice' unique
across all domains supported on the server. Then you could deduce the
virtual domain from the username. Although feasible, this scenario is
not common and I mention it just for completeness.

> Option 4.2 would work as from the credentials the proxy can identity
> "sip:alice at dom1.org", but IMHO the credentials username format should
> be an AoR (with the schema).

Whether or not the schema should be included is something we can argue
about, but in the end it does not really matter because it is not
standard anyway. You can choose whichever way you like more and what
your UAs support.

> Options 4.3 seems the best one for me, but not sure if it's feasible
> with the currently existing UA's.

If the UA allows you to enter the username for digest authentication
explicitly then it probably will be supported. In fact, from what I
have seen on iptel.org, this is quite common configuration mistake.

The column ha1b in the subscriber table exists exactly for this case.
That is, if you have calc_ha1 disabled and the UA sends a username
with '@' in it, SR automatically uses the column ha1b instead of ha1.
The difference between ha1 and ha1b is that the hash in ha1b is
calculated as MD5(username at realm:realm:password), while ha1 is
calculated as MD5(username:realm:password). So you've got both cases
covered and you can still disable calculate_ha1.

>> before calling proxy_authenticate. Any part of the SIP message can be
>> used to set digest realm.
>
> The problem is that in the above INVITE there is no way to choose the
> realm based on the SIP headers.

If there is nothing that identifies the domain then there isn't much
you can do. Though I've seen UAs that send "empty" digest credentials
with just username and no nonce or response attributes, that could be
used in such case.

>> Note that this would also work with calc_ha1 set to 0. The subscriber
>> table contains a column called ha1b which is used when the UA supplies
>> digest username of form "user at domain".
>
> Yes, but would it work in case of "sip:user at domain"?

I am not sure, you'll need to check the code. I wrote that part 8
years ago and I don't remember if I check for the presence of scheme.
;-).

-Jan