On Mon, 2009-08-31 at 13:16 -0400, Scott Lawrence wrote:
> 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).
It seems fairly straightforward. For each "privileged" connection, some
element has to verify the originating identity and paste on a
destination identity. (Of course, this requires that we can have two
X-SipX-Authidentity headers in one message, one for the originating
domain and one for the destination domain, but that probably works
already, and if not, just requires adjusting the machinery. We don't
want to strip the originating X-SipX-Authidentity, as that reduces
traceability.)
For connections through sipXbridge, it seems like sipXbridge would be a
good choice. For "direct SIP" connections, I suppose the Proxy would
have to do the work. (In which case, we might as well have the Proxy do
the work for sipXbridge, too.) The originating Proxy can verify the
permissions of the call originator, then translate them into the
appropriate destination identity. (The translation process has to know
the credentials of the destination identity and/or whatever goes into a
X-SipX-Authidentity for the destination system, as well as how to do
this mapping.)
Since the SIP request in transit between the originating and destination
system is (somewhat) protected by its credentials, we don't *have* to
use TLS between the systems, although of course that would make things a
lot safer.
The messy case is if the originating system is a TDM PBX, or rather, a
gateway from a TDM PBX. (If a TDM PBX can send SIP to sipXecs,
presumably it can be programmed to provide individual user credentials
for each of its users, and sipXecs can authenticate its users as if they
were native SIP users.) In that case, we need the gateway to properly
translate the authorizations that the TDM PBX has determined into
sipXecs' identities. For very small branches, this is easy, as there
will be no PSTN ingress to the branch, and the gateway can apply one
identity to all calls forwarded to sipXecs.
Dale
_______________________________________________
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/
