|Summary:||ASTERISK-03202: [patch] SIP realm based authentication|
|Reporter:||Olle Johansson (oej)||Labels:|
|Date Opened:||2005-03-17 14:14:46.000-0600||Date Closed:||2008-01-15 15:28:38.000-0600|
|Environment:||Attachments:||( 0) siprealmauth.txt|
( 1) siprealmauth2.txt
|Description:||This patch adds realm basead authentication for the SIP channel as well as peers. It also changes authentication so that Asterisk never Proxy-authenticates (we are not a SIP proxy, so we should not behave as one).|
* Disclaimer on file.
****** ADDITIONAL INFORMATION ******
SIP authentication is based on HTTP authentication. All usernames and passwords belong to a realm. When we get a challenge from a SIP server, we have to choose username and password based on the server's realm. This has nothing to do with the From: user name in the SIP header.
This is the way SIP separates authentication from usernames, really (hint, hint, markster).
This was originally inspired by a request by jtodd, later tested for a long time in chan_sip2. It enables ease of configuration in many ways. If you add a dial command in the dial plan to a SIP proxy where you have to authenticate, and have a configuration for that realm in the [authentication] section - authentication will happen automatically.
When we have full support for outbound proxys, this will enable multiple authentications for one call.
|Comments:||By: Olle Johansson (oej) 2005-03-19 08:35:02.000-0600|
Added another patch that only implements realm based authentication and does not change the authentication behaviour.
The realm based auth was originally part of chan_sip2.
By: khb (khb) 2005-03-19 16:34:24.000-0600
Of course you are right that authentication is based on realms,
username/password credentials are valid only within the authentication
realm of a server. All this originated from WWW browsers, where the user
is prompted with a popup window usually for a username and password,
and in order for the user to know which credentials to enter the
authentication realm is displayed. SIP phones don't do that anymore
usually, unless they don't have a password already stored.
In addition, in SIP you have this extra username, that can be different
than the authentication user, typically it is a phone number or another
name, this is what goes into the to/from headers, as you point out,
however, the credentials are still associated with this "fromuser" and
shouldn't be separated, as your patch suggests. SIP does not separate them.
Storing a bunch of userids/passwords and using them when they seem to
match a realm that is challenging seems fine, if you're the only
person using that Asterisk. It turns Asterisk into a giant single user
When you make a call to just any domain or IP address, it's up to that
domain to allow that or not. If they allow it, then they shouldn't
challenge. If they do challenge then they must have an account for you
already and likely expect you to register with them to get your IP
address or location. Whether they require registration or not,
and since you have the credentials for that domain, the Asterisk
expectations is that you configure a [peer] in the config file
that contains your endpoint parameters and credentials, and that you
if needed register with the server.
In this sense we are already doing "Realm Authentication" there is no
other method. chan_sip has flaws of course, and we should indeed
check that the offered realm actually matches the credentials we have.
With the static peer configuration we are assuming that if we have
configured a server and this server is responding to our call and
letting us authenticate, that this server is indeed serving the
protection space of our credentials. So, Asterisk now, does authenticate
by realm, only it uses the DNS name system, to match the realm of
the credentials to the realm of the server, not unreasonable,
given that it often is recommended to set the authentication realm
as the domain name.
AFAIR, I have seen only one or two SIP servers that serve multiple
Realms on the same IP address and domain name. And if that does happen,
such a server cannot just offer a realm arbitrarily. In that case,
the caller needs to either present valid Authorization: header
with the INVITE, so the server can know which realm to search in,
or there must be some other method to established that, perhaps
a prior registration with the location server.
What if you have X number of users and they have different
credentials for a realm that is challenging, your patch doesn't seem
to match a set of credentials with the user calling. You can't just
select anyone or the first, particularly if you are charging users
for calls in some fashion. I must have missed that match in your code.
This opens the way to bypass all [peer] configurations and
channel all calls through one peer only, which has some interesting
aspects, as the peer configuration could be used only to specify
hardware and protocol parameters, ie. becomes a device template
for a call. I think we exchanged some e-mails in which I explained that
notion? But then a good user database is needed, preferably outside
of SIP. I have a res_ module for that now, since that time, but it
requires even more changes to the architecture of chan_sip to use
in a consistant manner.
I think your idea harbors some forward looking features, but makes
current chan_sip even more confused. It already doesn't know what
a user and a peer really is.
Just my $0.02.
By: Kevin P. Fleming (kpfleming) 2005-03-19 17:38:09.000-0600
OK, I've finally had some time to look over this patch, and I like it a _lot_. It's much more in line with how SIP is intended to operate, and I even think switching from Proxy-Authenticate to WWW-Authenticate is the right thing to do as well.
I do have a question, though. As it stands today, we use the 'username' in the From: header to try to locate a SIP user/peer so we can determine if they need to authenticate or not. With this patch, we are moving towards proper domain-based authentication, and I'm wondering how you envision this affecting the inbound side of things? We have a number of workarounds and things in chan_sip now to accomodate non-compliant and/or unusual configurations, and obviously it will be important to keep them operating.
By: Olle Johansson (oej) 2005-03-19 17:53:37.000-0600
kpfleming: You are right, somewhere along the line we have to start reading the digest user name and match that to the peer/user instead of relying on the From: user name...
I have some of that code in chan_sip2, but I decided to take it one step at a time.
khb: You have said that before, so don't use it. This is optional and solves a lot of problems for me in my network when working with various SIP trunks. Also observe that you can define realm auths per peer, if you have multiple users on one service provider. THis will override generic authentication schemes.
This will also let us implement multiple authentications for one call, like the situation when we have to do Proxy-auth to an outbound proxy and WWW-auth to the service provider in the same INVITE.
By: Mark Spencer (markster) 2005-03-24 17:12:11.000-0600
Added to CVS head, thanks!
By: Olle Johansson (oej) 2005-04-01 00:30:39.000-0600
---Not included in 1.0.
By: Digium Subversion (svnbot) 2008-01-15 15:28:38.000-0600
r5256 | markster | 2008-01-15 15:28:38 -0600 (Tue, 15 Jan 2008) | 2 lines
Add SIP real authentication (bug ASTERISK-3202)