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

Klaus Darilion klaus.mailinglists at pernau.at
Mon Nov 14 18:46:29 CET 2005


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?

Anyway, in this scenario it is important to have the certificate 
parameters (Subject, Issuer) available in the routing logic to make 
routing decisions based on the TLS authenticaten and adding them to the 
CDRs (e.g. via AVPs and extra accounting)

   Bilateral scenario:
An ITSP has bilateral trust relationships. Each ITSP has its own CA 
which signs the certs of this ITSP. If another ITSP wants to trust this 
ISTP it only has to import the others CA-cert. This works already with 
openser 1.0.0, but exporting the cert parameters for extra accounting 
will be useful.

   Hosted SIP scenario:
An ITSP hosts multiple SIP domains for its customers. If the server has 
to offer a certificate which includes the proper SIP domain, the 
server_name extension is needed to indicate the requested domain in the 
client_hello request. Then the server will present the proper 
certificate and domain validation (Subject domain == SIP domain) in the 
client will succeed. This will work fine with initial (out-of-dialog) 
requests as they usually will include the SIP domain in the request URI. 
There will be problems for responses and in-dialog requests as usually 
the Record-Route and Via headers only includes IP addresses. Thus, the 
SIP proxy either has to insert the SIP domain into Via and Record-Route,
or the domain validation should only be done for in-dialog requests.

This leads to the problem of domain validation. The TLS connection will 
be set up after all the routing logic, somewhere inside t_relay. Thus, 
if we want domain validation, it will be inside t_relay. Maybe we can 
use a certain flag to indicate if domain-validation should be done (on a 
per-transaction basis). This might cause problems if there is already a 
TLS connection to the requested destination, but without domain 
validation or validation against a different domain (virtual domain 
hosting). How to solve this?


I can't propose a solution to all scenarios. But I think I showed that 
the certificate selection and validation should be very flexible, e.g. 
by choosing the proper client certificate for each transaction and 
different routing in the server depending on the presented client 
certificate and the cerfiticate signer (e.g. based on a whitelist).

Further we have to take care to add certifcates and CA-certs during 
runtime, e.g. using a FIFO command "tls_reload". This should also drop 
all existing TLS connections. Having a maximum connection time after 
which we force re-validation will also be useful.

Also (open)ser should allow to import CRL (certificate revocation lists) 
(shouldn't be a problem with openssl) or usage of OCSP (Online 
Certificate Status Protocol).

Now I'm ready for some discussions :-)

regards
klaus




More information about the Users mailing list