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.
But then you are not talking just about a proxy-to-proxy scenario. You don't
really want to check only the integrity and authenticity of the proxy, but
also of the sender. Just like smtp, you can use TLS to exchange messages
between mail servers and you trust the certificate of the other mail server,
but how do you check the sender of the email? It's on a different level and
mostly you do it on the MTA level. Of course, you could add checks
verifying that emails from mail server A matches the domain found in server
A's certificate.
From that perspective, you would probably only allow
From domains that are
found in the CN and alternative names of the certificate of
server A.
I don't think this is a general matter (finding what is "correct"), but more
about the policies you implement (or level of integrity checks you want to
enforce). Do you allow the certificate of the sender to deviate
(domain-wise) from the domain of the proxy? If you have multiple proxies
between you and the sender and you trust the proxy, you probably will allow
it. If you are peering with a proxy and only want to allow that proxy's
users, you probable disallow it.
BTW, "I want to authenticate the sender in the From header": You cannot
possibly authenticate the sender in the From header using the proxy server
certificate, you need to use the sender's certificate. You can verify that
the proxy you trust (because the certificate is correct) does not try to
forward calls from somebody outside its domain (maybe a hacker found a way
to do that through that proxy). And if the bad guy really wants to send you
from
darillion.com, he can add that domain to his certificate as an
alternative name (if I interpret the mentioned section correctly).
Out of interest: Is this related to SER TLS or are you working on some other
implementation that you can share info on?
g-)