Summary:	ASTERISK-01699: [patch] Add realm authentication to SIP
Reporter:	Olle Johansson (oej)	Labels:
Date Opened:	2004-05-26 13:46:23	Date Closed:	2011-06-07 14:04:40
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sipauth.txt
Description:	This patch adds realm-based authentication to the SIP channel. This is used when another SIP proxy or UAS challenges us and we need to authenticate. Realm-based auth overrides other configuration. We remain backwards compatible, not to disturb current installations. ****** ADDITIONAL INFORMATION ****** [authentication] +; Authentication for outbound calls, i.e. when a proxy challenges your +; Asterisk server for authentication +; This way, Asterisk can authenticate for outbound calls to other +; realms. We match realm on the challenge and pick an set of +; credentials from this list +;      auth = <user>:<secret>@<realm> +;      auth = <user>#<md5secret>@<realm> +; Example: +;auth=mark:topsecret@mainswitch.digium.com
Comments:	By: Mark Spencer (markster) 2004-05-26 14:28:22 Is it possible that different peers might want to authenticate us using the same realm but we need to authenticate with different secrets? i.e. should the auth stuff be on a per-peer basis? By: khb (khb) 2004-05-26 14:33:11 Olle, it's not clear to me how this is used and why needed. Maybe I need to apply the patch to understand in context. Why do you call it realm-based? Making outgoing calls is already authenticated against the realm we are calling with the parameters from a peer definition or the Dial command. Is this for calling just any domain without knowing the proxy? This brings me to another subject: documentation.  I think it should be mandatory to submit a detailed writeup of purpose, background, features, intended functionality, usage, etc. for new features to be added to the code base, not just a small patch to the sample configs. It should not be necessary to read the source code to understand a new feature. I don't know how else you're ever going to have complete and useful reference documentation for Asterisk. By: Olle Johansson (oej) 2004-05-26 15:09:47 Mark: This is needed on a general level, but could also be written so it can be added per peer. I didn't need that now, that could be a later patch. On a general level, this applies mostly to register=> statements or calling to SIP proxies that require auth regardless if we register or not. khb: It's realm-based, since we match on the realm given in the challenge from the other side. This is really how SIP auth works, the username/password applies to one realm. The patch to sample configs is all we have. When this patch reaches stable, it's time to add documentation to the wiki and the docs project. I agree with you that it shouldn't be necessary to read source to understand, that's why I added more than a one-liner to the config file... Please join the documentation project to help us with better documentantion. They need you. By: khb (khb) 2004-05-26 16:13:00 So I still don't understand how this is different than what we have. Of course all auth is realm based. What do you mean, when you say it's needed on a "general level"?  Is this just another configuration variation? Can you describe an actual scenario when this would be used and how, so that anyone can understand the value of your patch?  You obviously spent some valuable time and effort on this and it should not be wasted or misunderstood. I think a new feature without documentation should never reach stable, how can it be evaluated w/r/t to intent, implementation, security etc. without docs? How do you know it's stable, if it hasn't been evaluated against the original intent?  Usually what happens in most projects when there are no controls in the creation phase is that no one ever goes back and documents things that are already in place. Others that do want to pick up the task at that point have to wade through an almost unsurmountable backlog of patches and discussion lists and the chances are a feature will not get properly documented anymore. That's one reason so much computer software documentation is so bad.  For major new features I think there should even be planning documents to evaluate the best approach to take to implement a new feature, take for example SRTP implementation.  With planning docs you have guidelines against which to evaluate the success of the implementation. By: Olle Johansson (oej) 2004-05-27 02:53:44 khb: Learn asterisk first, then raise your voice. Asterisk chan_sip doesn't match on realm today, in fact, until I fixed it recently all Asterisk servers where using "asterisk" as a realm for authentication. Step by step, I'm changing that. Now, if you read the RFCs, you'll see that in SIP, authentication is done per realm, with Asterisk it is one auth per peer/user, even if calling outbound, ,with *no* matching on realm. Regardless of what the other server says, we use the same username/password. In some networks this doesn't work, we thus need to authenticate per realm. So as I stated, this patch adds realm based outbound authentication. Download the patch, read the docs included and run it. In most networks this isn't needed, it doesn't matter. Yours is propably such a network. In my business, I need this. Also, please study the chan_sip2 project. Within that code, I've documented what I want to do, where I'm going and why. Also, I agree that we need more documentation. Roll up your sleaves and help us document, on the wiki (that I started) or in the asteriskdocs.org project. Please move the larger documentation debate out of this bug report and continue on the -dev list or on the IRC. By: Olle Johansson (oej) 2004-05-27 13:54:58 New patch with * Peer realm auth added * 'sip show peer <name>' lists realm authentications set for peer * Clears auth lists on peer deletion or sip reload By: khb (khb) 2004-05-27 14:13:53 This is all very unnessessary, but I see where the wind blows; there is no chest pumping and agression needed, your patronizing attitude is quite out of place. When I explained to you recently how SIP breaks the OPTIONS rules, I didn't tell you to go and learn Asterisk and SIP.  Here, I simply asked for a clear statement for everyone's benefit what's deficient currently and how your patch solves it, nowhere did I put in question the validity of your project, nore did I have the basis for that without documentation. Others often get grilled or belittled when they post their issues. Too bad you feel you're above simple documentation and accountability. You agreed that it shouldn't take reading source to understand the value of an improvement and now you tell me to go and read the source. The only good of this is that it finally dawns on me just what YOU mean by "realm-based". A simple two sentence explanation would have done that to start. There can be many variations of authentication and authorization. The RFC's don't dictate any one specific scenario. To say that we don't authenticate for realm currently is not accurate, since we connect to the proxy of a domain as configured and we may assume that a designated host is authoritative for a realm or domain, the RFC states that a realm name should preferably be a resolvable host or domainname. If the host challenges a UA and accepts our credentials than we have in effect authenticated against that realm, whether the realm STRING in their headers matches or not. Checking against that string of course is fine, but there can be several scenarios again, the proxy can serve more than one distinct realm, or for one realm it can return to the UA multiple challenges. Many people likely have patched their Asterisk code for special situations. Don't assume you were the first to discover that the realm string that Asterisk sends shouldn't be a constant for everyone. So what exact scenario does your patch address?  Would you like to tell us, or do you really want people to go and run tests to discover what your intent was? edited on: 05-27-04 13:14 By: Olle Johansson (oej) 2004-05-27 14:54:31 The scenario is that a proxy challenges us with a realm and we authenticate with a username and secret that works within that specific realm. Period. By: John Todd (jtodd) 2004-05-28 19:04:04 Tested against SER 0.8.12; seems to work!  I have not exhaustively tested, but calls are now passing between my Asterisk box and my SER proxy, with various ANI and DID combinations, all across the same authentication account (i.e.: same billing entry.) That is very, very cool and tremendously useful. Note: current patch doesn't patch cleanly on chunk #3 against CVS -head, but it's a trivial fix. By: John Todd (jtodd) 2004-05-28 19:30:08 Maybe I'm a little premature in saying it does exactly what I need it to do. :-) I'm still getting caller ID being set to be the authentication account name, and not the correct numeric ANI that I'm looking for. So:   7960A  -> Asterisk ->  SER  ->  7960B 7960A should show a caller ID of 3015611900 Asterisk sees that correctly.  Asterisk authenticates against SER with an auth line of:  jt-test1:bo8czoe@proxy1.loligo.com.  Then, SER passes the call to 7960B, but 7960B sees the caller ID as jt-test1 <"3015611900">, meaning that the authentication name is getting passed as the caller ID numeric portion of the call.  Of course, I want the 3015611900 digits to be passed as the caller ID, not the authentication name.  In fact, the authentication name should be kept as a private token between the Asterisk server and the SER platform, and never seen outside that conversation. The more I think about this, the less sure I am it's even possible to have a single authentication username and password act as a "hidden" account authorizer for multiple origin ANI's, at least using SER as the next SIP proxy before handoff to a UA or gateway. By: Olle Johansson (oej) 2004-05-29 03:16:31 jtodd: Please add sip debug of traffic between Asterisk and the SER proxy. Since I don't know the config of the SER, I need to know what asterisk sends in your case.  Asterisk doesn't know the digest auth name until authentication, so I guess it's the SER config that display's the auth name. But it's guessing at this stage :-) By: Olle Johansson (oej) 2004-06-13 15:56:41 Keeping this in chan_sip2 for extensive testing. Will re-open when tested and confirmed by more users.