[Users] Re: [Devel] TLS requirements and some brainstorming (long email)
bogdan at voice-system.ro
Tue Nov 22 17:05:01 CET 2005
Klaus Darilion wrote:
> 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
>>> 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
> SSL obejct?
yes - this is possible - make available info about the connection
evolved even if it's new one or a re-used one.
>>> 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
>>> 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?
yes it's a valid scenario. If so you cannot relay on any transaction
related data as you may choose to statelessly forward the request.
Sounds bloated but in this case you need to store it in VIA also :-/ - i
really don;t like the idea :(
>> 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.
maybe this should be a configurable option.....at least on our side......
More information about the Users