On Mon, Aug 31, 2009 at 1:16 PM, Scott Lawrence
<[email protected]>wrote:
> One of the features of sipXecs security is that we have a permissions
> system that enforces access controls on dial plans. This is the
> foundation of our protections against toll fraud - preventing
> unauthorized persons (and especially outside attackers) from making toll
> calls through the PSTN from the PBX. Before a call can be made, the
> caller is authenticated using SIP authentication, and we verify that the
> authenticated identity has the permission required to use the dial plan.
> If the caller can't be authenticated (as would be the case for an
> outside caller), then there is no permission and so no call.
>
> This feature does have downsides, however, in that it makes some
> desirable configurations difficult or impossible. The most frequent
> example of this is gateway sharing across federated systems:
>
> If my company has offices in New York and London, each set up as a
> separate sipXecs system like this:
>
> PSTN (US) - gateway - pbx (NYC) -SIP- pbx (LON) - gateway - PSTN (UK)
>
> it would be nice for me to be able to configure each system to route
> calls through the other when that would result in lower cost calling
> (usually called 'toll bypass'). Today, that won't work because the user
> administration of the two systems is separate, so they can't
> authenticate to the other system (note that in the planned sipXecs 5.0
> multi-branch support, it would be possible to have unified user
> administration).
>
> Similarly, we now have configurations in which a sipXecs system is being
> added to legacy systems using a SIP Trunk through sipXbridge (often to
> support small branch off the larger legacy system):
>
> PSTN - gateway - sipXecs - sipXbridge -SIP- PBX - pbx_phone
>
> Again, it would be good to be able to support a phone on the legacy PBX
> making a call through the SIP trunk and out the sipXecs gateway.
>
> Note: these configurations could be set up today by turning off
> the permission requirements on the gateway dial plans: I
> strongly advise that this _never_ be done. If you do it, count
> on someday getting a really big phone bill (this is not
> theoretical - it has happened on at least one misconfigured
> system I know of: the attacker was sophisticated and set up a
> high volume operation very quickly).
>
> I'd like to explore solutions to allow these configurations by having
> the sipXecs border element (the component that first gets the connection
> from the 'other' system) authenticate the connection itself, and tag any
> request coming in on that connection as 'privileged' (note: not
> 'trusted' - I want it to have some implied identity whose permissions
> can be checked, not some blanket ability to bypass security).
>
> I think that this requires that both sipXproxy and sipXbridge be able to
> act as the 'border element'. The sipXproxy would be used for
> connections that are 'full' SIP (as two sipXecs system connected by a
> site-to-site rule), and the sipXbridge for connections to legacy systems
> in which the intermediation features (such as not forwarding REFER)
> created for ITSPs are needed.
>
> In either case, a connection that is configured to be privileged would
> attach a signed X-Sipx-Authidentity header (which, incidentally, I'd
> like to change to Sipxecs-Authidentity) with the identity configured for
> that connection. I _think_ that would prevent any further challenges
> and give the call the permissions associated with that identity.
>
> My own preference would be to require that the connection be mutually
> authenticated with TLS ('authentication' based on just an IP source
> address is notoriously easy to defeat).
>
> Comments?
>
If my understanding is correct, this would require for sipxbridge to keep a
the accounts database entry for the other system ( not bad now that we have
validusers.xml ) so that it can handle authenticating inbound requests from
that system. It would also require that sipxbridge issue REGISTER requests
so that phones in one domain can REGISTER with sipxbridge hence allowing
inbound calls to be forwarded to such phones. This feature would be
necessary to support legacy systems ( i.e. those that do not support REFER
).
I understand that you are proposing mapping all calls originating from a
given PBX to a single identity? The permission for all the callers that use
that PBX could be treated identically in that case. Alternatively, we could
interpret calling permissions from one system on the other system.
>
>
> _______________________________________________
> sipx-dev mailing list [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
> sipXecs IP PBX -- http://www.sipfoundry.org/
>
--
M. Ranganathan
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
