> 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.
A couple of questions on this. How would the initiating system be able
to produce a signed authidentity that will be acceptable to the
receiving system? Would we share a secret between the two systems?
How would we manage permissions? For the purposes of connecting to a
specific system, one could create several 'connection' identities with
varying degrees of permissions and associate the connection identity
with suitable permissions to a given site-to-site dialplan but this can
quickly become cumbersome to manage. A possible alternative is to make
the assumption that permissions mean the same thing on both systems.
That way, when the initiating system passes a call to the other system,
it could encode in the authidentity it adds to the message a list of the
original caller's permissions and the receiving system would use those
permissions when deciding to authorize or not the call.
> 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).
TLS would of course be ideal but could be a ways away.
_______________________________________________
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/
