10 Oct
2005
10 Oct
'05
noon
On Monday 10 October 2005 10:03, Klaus Darilion wrote:
Juha Heinanen wrote:
I think you are right for the scenarios where you are the client and you are
serving the domain in the From header. In that case you should present a
certificate which matches the From.
But on the other site: what happens if you just forwarded the request and
neither the From, To or (the new) request-uri belongs to you. In that case
you can only present a generic certificate which matches one of your domains.
But for me it is anyhow a question what a server is going to verify on a
client certificate.
But for the server scenario I think Juha is right. Because when the TLS
connections is being establish you do not know for what is the target domain
of the request. Thus you can only present one generic certificate and that
should be valid for all of your domains.
Nils
i'm not a TLS expert either, but i have been
wondering if a proxy
serving multiple domains would need to have a client/server certificate
for each. i hope not.
in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy
scenario, it should suffice that both proxies have certificates for the
proxy hosts themselves and they don't need to have anything to do with
the domains in the uris of sip requests.
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid
certificate for its hostname. Then, this SIP proxy sends a SIP request
with the header:
From: "Klaus Darilion" <sip:klaus@darilion.com>
Now, what is the receiving proxy interested in? Does it want to validate
the host or the sender (From header)?
IMO, I want to authenticate the sender in the From header. Thus, the
certificate would have to match the SIP domain, and not the host name.
Please read RFC3263 section 4.1. It gives much insight.