On Mon, 2009-08-31 at 14:54 -0400, Joly, Robert (CAR:9D30) 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.
>
> 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?
It can't... given this:
phone1 - other-pbx - sipXecs - gateway - PSTN
The sequence would be something like this:
1. Some phone1 attached to other-pbx dials a PSTN number and sends
the call to other-pbx
2. The other-pbx (presumably) internally authorizes this call and
sends it using SIP over TLS to sipXecs.
3. The first sipXecs component (either sipXbridge or sipXproxy,
depending on how the connection to other-pbx is configured)
notes that the request is arriving on a TLS connection whose
peer identity has been confirmed; that component then generates
the local sipXecs identity for the call based on the
configuration for that connection.
4. The call goes through the usual sipXecs permissions checks based
on that configured identity and is sent to the PSTN through the
gateway.
There are no requirements on the 'other' system except that it be able
to do TLS with mutual authentication. In particular, it need not
understand anything about sipXecs identities or permissions.
> 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.
That's exactly what I think I intended - my assumption is that the
number of such connections is going to be fairly small and not change
often. If you need many systems with lots of interconnection, then the
sipXecs 5.0 multi-branch solution is what you should be looking for, not
this.
Ranga said:
> 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 ).
No on both counts. The idea is to map all calls via a given connection
to a single locally-configured sipXecs identity.
> 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.
Exactly.
> Alternatively, we could interpret calling permissions from one system
> on the other system.
No - not worth the (substantial) incremental effort.
_______________________________________________
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/
