18 Nov
2005
18 Nov
'05
3:19 p.m.
Bogdan-Andrei Iancu wrote:
Hi Klaus,
indeed this is a long email ;).
please see my inline comments.
regards.
Bogdan
Klaus Darilion wrote:
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
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.
Just an idea.