[Users] Re: [Devel] TLS requirements and some brainstorming (long email)
mikaelmagnusson at glocalnet.net
Fri Nov 18 13:19:25 CET 2005
Bogdan-Andrei Iancu wrote:
> Hi Klaus,
> indeed this is a long email ;).
> please see my inline comments.
> Klaus Darilion wrote:
>> Hi all!
>> There are several scenarios where TLS will be used to interconnect SIP
>> proxies. (open)ser's TLS implementation should be generic enough to
>> handle all the useful scenarios. Thus, to better understand the
>> requirements, first I present some examples where (open)ser+TLS will
>> be useful. (I do not propose which of the following interconnect
>> models are good or bad. However, openser should be capable to handle
>> all of them, best in a mixed mode).
>> Enterprise scenario:
>> A company uses TLS to interconnect their SIP proxies via public
>> Internet. The proxies import the companies selfsigned CA-cert as
>> trusted CAs. The proxies trust other proxies as soon as their cert is
>> validated using the root CA.
>> This is already possible using openser 1.0.0 (= or ser+experimental TLS)
>> Federation scenario:
>> Some ITSPs form a federation. The federation-CA signs the certs of the
>> ITSPs. Here, the validation is like in the enterprise scenario.
>> (open)ser validates against the federations CA-cert. This works with
>> openser 1.0.0 as long as the ITSP is only in one federation, or uses
>> different egress/ingress points for each federation. If the ITSP is
>> member of two federations and uses one egress/ingress proxy, it has to
>> decide which certificate it should present to the peer. The
>> originating proxy could choose the proper client certificate for
>> example by using a table like (or having the certificate as blob
>> directly in the DB):
>> dst_domain certificate
>> sip.atlanta.com /etc/openser/federationAcert.pem
>> sip.biloxy.com /etc/openser/federationBcert.pem
>> sip.chicago.com /etc/openser/federationAcert.pem
>> Presenting the proper server certificate, is more difficult. The
>> server does not know if the incoming TLS request belongs to a member
>> of fedA, fedB or someone else. Thus, presenting the wrong certificate
>> will lead to the clients rejecting the certificate due to failed
>> validation. One solution would be sending the "trusted_ca_keys" (TLS
>> extension) in Client Hello. Unfortunatelly this is not supported in
>> openssl (and gnutls). Any workaround for this?
> As I understood from Cesc, gnutls already support this extension, but to
> migrate to gnutls and restart all testing may not pay the effort as time
> as it's just a matter of time until the extension will be also available
> in openssl.
> As temporary solution I will suggest to go by default without the
> extension patch, but to provide the patch into the TLS directory and
> people interested in these multi-domain scenarios will have to apply and
> recompile the openssl lib. And maybe we should do some lobby (read
> pressure) on the openssl mailing list in order to push this extension in
> the official tree.
> Just an idea.
Can't openser use different ports for each domain it's serving? This of
course requires that SRV records are configured in the DNS and that the
UAC supports SRV.
domain port certificate
atlanta.com 5061 /etc/openser/federationAcert.pem
biloxy.com 5063 /etc/openser/federationBcert.pem
chicago.com 5065 /etc/openser/federationAcert.pem
More information about the Users