________________________________________ From: [email protected] [[email protected]] On Behalf Of Mossman, Paul (Paul) [[email protected]]
Scott wrote: > For example, some systems may require that connections to > them be made with mutually authenticated TLS; in order to > interoperate with them, a peer would be configured so that > there is somewhere to insert the > required certificate chain and to give it a name. You don't want to > have to invent a dummy permission to give them just to be > able to connect to them. OK, this is what I'm after. Just to confirm... Calls will fail if such a remote system is not configured as a TLS Peer? If so, I'll close XX-8534. _______________________________________________ There are a bunch of misconceptions that are clouding the discussion. (And thanks to Ranga for filling me in on the details.) There are two *separate* functionalities here. One function is the process of making a TLS connection between two sipXecs systems, or more exactly, their sipXbridges. That is set up on the originating side by configuring the destination sipXecs's sipXbridge as if it was an ITSP host. In order for the connection to be made, each end must present a certificate for which the other end has an authority certificate. Note that the domain name of the certificate is not important; TLS is used to ensure the integrity of the connection but not the authorizations of the caller. This rests on a design principle: Calls from non-authenticated originators being routed through sipXecs are not, per se, a security problem. (In much the same way that any phone on the world PSTN can call your phone.) But calls from non-authenticated originators are not allowed to be routed to destinations that require permissions. That is what protects gateways and other "expensive" destinations. Thus, a call from the outside world can be made into sipXecs via a TLS connection, as long as the originator has a certificate from a well-known certificate authority -- in the same way that a call can be made into sipXecs via a UDP datagram arriving over the greater Internet. The "TLS Peer" capability is a configuration that instructs sipXbridge to consider TLS connections from certain originators to be special, in that, if the certificate of the far end matches certain domain names, to apply to incoming calls particular permissions. (Or rather, to authenticate them with a special identity which has the permissions in question.) A certain amount of confusion arises because two sipXecs's can communicate via TLS, and thus be "TLS peers", without the "TLS Peer" capability being configured on either sipXecs. (I have been subject to this confusion.) Within the context of XX-8534, this means that using the "TLS Peer" screen without enabling any permission has no effect. But within the context of this discussion, the presence or absence of a TLS Peer configuration does not affect whether one system can establish a TLS connection with another. (And there is no reason it should.) 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/
