[Users] Re: [Devel] TLS requirements and some brainstorming (long email)

Klaus Darilion klaus.mailinglists at pernau.at
Fri Nov 18 14:19:59 CET 2005

Mikael Magnusson wrote:
> Bogdan-Andrei Iancu wrote:
>> Hi Klaus,
>> indeed this is a long email ;).
>> please see my inline comments.
>> regards.
>> Bogdan
>> 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

AFAIK this is possible:

But I think this is not nice solution (restart ser, firewall settings 
...). It might be useful when hosting multiple domains, but only one 
federation. But if you take part in several federations you would have 
to publish different ingress points for each federation. That does nto 
scale. E.g. if you use ENUM (e164.arpa) to publish your ingress point, 
you can publish a sinlge URI for all federations.


More information about the Users mailing list