[Users] Re: [Devel] TLS requirements and some brainstorming (long email)
klaus.mailinglists at pernau.at
Fri Nov 18 13:03:02 CET 2005
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.
>> 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
Is it possible to retrieve the certificate porpierties if we have the
>> 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.
More information about the Users