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
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
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 softphone. 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 Repository: asterisk Revision: 5256 U   trunk/channels/chan_sip.c U   trunk/configs/sip.conf.sample ------------------------------------------------------------------------ r5256 | markster | 2008-01-15 15:28:38 -0600 (Tue, 15 Jan 2008) | 2 lines Add SIP real authentication (bug ASTERISK-3202) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5256