Juha Heinanen wrote:
Greger V. Teigre writes:
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.
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