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

[Klaus Darilion]

Bogdan-Andrei Iancu wrote:
> 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.

ACK

>>
>> 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)
>>
> interesting but there might be some problems - the information you want 
> to log comes from transport layer and you try you log it by using 
> mechanism from the SIP level. It will works, but the info will be 
> actually available only for requests that initiated the TLS connection 
> (send or received) and not also for the requests that reuse the connection.

Where is the missing link?
Is it possible to retrieve the tcp_connection from which a SIP message 
was received? If yes, we should be able to get the SSL object 
(tcp_connection->extra_data).
Is it possible to retrieve the certificate porpierties if we have the 
SSL obejct?

>>   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.
>>
> not sure what you mean by cert parameters.......

The properties (subject: common name, Issuer ...)

>>   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. 
> 
> 
> 
> the solution will also the mighty extension, indeed.....
> 
>> 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.
> 
> 
> I don't thing we should worry about replies - they will return via same 
> connexion - the expiration time of a tcp connection must be higher than 
> the expiration time of a transaction..

Is'nt is a valid scenario that the TLS connection may dropped (for 
whatever reason) during an ongoing transaction and thus, the TLS 
connection must be re-established for the replies?

> But about the within the dialog requests - you have a strong case here!! 
> But is actually more complex : you need to know the inbound and outbound 
> domains actually - if you received the request from another peer via TLS 
> and fed it also via TLS to another peer (relaying) will need to remember 
> both domains since the within the dialog request may flow in both 
> directions ;).
> Maybe storing the domain names as RR param is the simplest and uglier 
> solution...in the mean while I think is the only one without involving 
> any dialog persistence.

As workaround (IMO this is a bug in RFC3261) I would validate domains 
only for out-of-dialog request.

>> 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?
> 
> 
> one premiss we should based on is the fact that cannot exists (in my 
> opinion) connections that should or not require domain validation in 
> different case. Argumentation: AFAIK only two types of connections can 
> be: user oriented and peering oriented; the first type will not require 
> validation at all and the second one may or may nor, based on local 
> policy. So, I think, we cannot have a case when connection to X will 
> require validation and later no.

I think we should differ between validation of the certificate against 
the CA certificates and validation of domain names (e.g. From domain == 
common name domain)

> To control the validation (and maybe other parameter of the connection), 
> prior setting from the script may be the solution - I was investigating 
> with Cesc the idea of building a TLS module which will be used for 
> provisioning the cert and to control the connection params. The TLS 
> engine itself will stay in core as now.
> 
> So, I would say we never reach the case when we want to reuse an 
> existing connection but with different settings.


regards
klaus