On Wed, Mar 11, 2015 at 6:26 PM, Daniel-Constantin Mierla <[email protected]> wrote: > > > On 11/03/15 22:11, Matthew Jordan wrote: >> On Wed, Mar 11, 2015 at 3:31 PM, Olle E. Johansson <[email protected]> wrote: >>>>> So far most of authorization between Kamailio and Asterisk relies on IP >>>>> addresses, but those need to be provisioned one by one in both sides. The >>>>> new module is practically adding a custom header with a hash over parts of >>>>> the message or other environment attributes (eg., IP address) and a shared >>>>> secret. The www-digest with username and password has the overhead of an >>>>> extra round of signaling messages, but also the constraint on CSeq >>>>> increment >>>>> after the challenge. Also, the MD5 is rather week hashing these days. >>>>> >>> Why can't this be done in the dialplan?. This is exactly why I implemented >>> the MD5 >>> dialplan stuff in Asterisk years ago. We need something else than MD5 today, >>> but still - both Asterisk and Kamailio can handle it without modules or >>> extra coding... >>> >>> The IETF is working on OAUTH authentication for SIP - which is the solution >>> we really want to look into - not copy weak auth from the API world... :-) > > Continuing the thread, but answering to Olle's remarks -- yes, many > things can be done via config, as I noted it is mainly about the > management of the shared secret rather than the computing of the > hashing. I consider it important to be able to work verifying against > many keys at the same time, but using one (the most recent) for adding > the header. > > Then I didn't want a complex scripting around it, with db queries and > managing the result in the config, putting extra complexity there. The > idea was to make it as scalable and elastic as possible. Also, C coding > is the easiest I can do ;-) and again, I wanted to come up with some > real stuff, not just theoretical discussion. Being something good or > bad, is now opened for discussions. > > One problem with IETF is that takes ages for new good specs and the 'API > guys' will be further ahead with new auth mechanisms by that time. Not > to say that many things from IETF come out without any practical > background, being based on pure theoretical concepts from some > specs-writting-machine-guys. > > While I am all for standardization and open specifications, I think that > some concepts can be tested before pushing to a formalization. And open > source should be the perfect ground for such ideas, if found useful > and/or practical, someone can take the lead on standardization process. > In other words, I want open source to be more involve in standardizing > practical things, rather than implementing specs from others -- > definitely will be more feasible specs out of such process. >
If we put aside the notion of authentication for a second, I think it is worth exploring the concept of 'identity' - that is, how does an Asterisk instance know who the Kamailio instance that just sent a request is, and how should it treat it. Currently, the most used (and probably the only way) is to use Asterisk RealTime, and - before the new Kamailio instance sends a request to an instance in the cluster - add an endpoint for that instance in the database. When a request is received from the new Kamailio node, an Asterisk instance will query the database, match the endpoint using one of the existing mechanisms (From user, IP address/hostname, etc.), and then perform authentication using the proposed mechanism. There are downsides to this approach: (1) All Asterisk nodes have to either use the same database, or else the new Kamailio endpoint has to be replicated across multiple databases. Either way, the databases become the limiting factor in scaling. (2) Ostensibly, if the goal is to have a new node "inform" the cluster of its existence, then requiring a database update for nodes in the cluster to occur defeats much of the "discovery" message. Is there a better, or different way? In an ideal world, how should a new Asterisk instance be informed of the existence of a new Kamailio instance? A few rough ideas: * Map instances of Kamailio to a single endpoint definition. This works fine for inbound requests, but has limitations on how Asterisk can place outbound requests to specific instances, as it must send all outbound INVITE requests using specific SIP URIs in the dialplan. * Allow something external to both systems (possibly whatever decided to bring up a new Kamailio instance in the first place) to push the configuration of the PJSIP endpoint into Asterisk. This could be exposed through ARI. * Use an existing platform, such as Corosync, to provide the "discoverability" of nodes and map that (somehow) to PJSIP endpoints. There may be other ideas - I'd be very curious what others think is the best way to handle this particular scenario, as it gets rather tricky quickly. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
