[Home]

Summary:ASTERISK-11587: Global Register vs Global Authentication error
Reporter:Csaba Lack (csabka)Labels:
Date Opened:2008-03-06 05:28:05.000-0600Date Closed:2011-06-07 14:02:41
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a problem with global authentication based on username.
(I've tried also with match_auth_username=yes option, but nothing changed)

The problem is the following:

I have two SIP account with different password at the same ITSP. If I register it:
register=<user1>:<secret1>@sip.itsp.dom/<user1>
register=<user2>:<secret2>@sip.itsp.dom/<user2>

It works fine:
sip show registry
Host Username Refresh State              
sip.itsp.dom:5060 <user1> 105 Registered          
sip.itsp.dom:5060 <user2> 105 Registered

After I delete the secret from the register line, like this:
register=<user1>@sip.itsp.dom/<user1>
register=<user2>@sip.itsp.dom/<user2>

and add global authentication:
[authentication]
auth = <user1>:<secret1>@<realm>
auth = <user2>:<secret2>@<realm>

then:
Host Username Refresh State              
sip.itsp.dom:5060 <user1> 105 Registered          
sip.itsp.dom:5060 <user2> 120 Auth. Sent

After I change the order of global authentication
[authentication]
auth = <user2>:<secret2>@<realm>
auth = <user1>:<secret1>@<realm>

then:
Host Username Refresh State              
sip.itsp.dom:5060 <user1> 120 Auth. Sent
sip.itsp.dom:5060 <user2> 105 Registered

I have also tried if I didn't delete the secret from register, but the same result as above. Note that the realm is totally different from sip.itsp.dom.

I found an interesting "solution". If I change my ITSP's password to the same for all my accounts (user2's secret to the same as user1) then it works.

Summary: This can only work if user[n] to user[n+1] has the same password: secret[n]=secret[n+1]

Regards:
Csaba Lack
Comments:By: Olle Johansson (oej) 2008-03-18 01:53:00

Well, we can't handle multiple credentials in the same realm. That's by design, not a bug. We propably should point that out in the configuration file.
By: Csaba Lack (csabka) 2008-04-02 07:31:30

So you mean that it won't be changed, because this is not a bug just a design?
If it is true, why is there an option to set username?
syntax:
auth = <user>:<secret>@<realm>

so if you are right with the design in your case it should be the syntax:
auth = secret@realm  (without user field)

I think if the user field exists then it should be called as a bug, a wontfix known bug.

Regards:
Csaba Lack
By: Jason Parker (jparker) 2008-05-06 15:17:19

oej, do you want to document this limitation, or should we support user@realm separate from realm?
By: Olle Johansson (oej) 2008-07-01 07:35:43

You are assuming that the "user" is the From username field, not the authentication user. In the realm based authentication, it's the digest auth user that is specified, NOT the From username.

In order to support this, we need to add a new specifier, which should be a full URI, not only the username part. That's why I see this as a feature request, not a bug report.
By: Kevin P. Fleming (kpfleming) 2008-08-05 17:56:09

As Olle has said, this is expected behavior given the design of realm-based authentication in Asterisk today. The 'user' part of the authentication information in that section is the name to be provided to the endpoint requesting authentication; the same username will always be provided to any endpoint requesting authentication for that realm, regardless of what sort of connection (REGISTER, INVITE, SUBSCRIBE, etc.) prompted it or which user account might be associated with that service.

If your provider actually supported realm-based authentication, they would provide you a single user name that would be used for all your services with them, and Asterisk could be configured to use that. Since they are providing separate authentication for each service, you'll have to configure Asterisk that way.