10 Oct
2005
10 Oct
'05
10:03 a.m.
Juha Heinanen wrote:
Greger V. Teigre writes:
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.
regards
klaus
I haven't read the RFC you are referring to,
but
in a proxy-proxy scenario, do you really validate against an uri?
Shouldn't you validate the server and not the actual requests? (If
the proxy is relaying on behalf of others) Also, whether you want to
accept a request to another domain is not really on TLS level is it?
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.