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

Mikael Magnusson 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.
> 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


More information about the Users mailing list