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 certificatesip.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
Regards, Mikael