Edwin,
EA> In this model, clients talk to their home server (analogous to a
submission server), which would use its certificate to authenticate itself to
the destination server. Depending on trust and
EA> deployment scenarios, Client A may also use TLS to communicate with SIP
Proxy A, but it's an independent decision, so the client-server mismatch isn't
really an issue. Of course, SIP also has
EA> provisions for encrypting of its message bodies (using S/MIME) for
end-to-end security.
EA> This all works for SIP, because, among other things, it does not have the
problem of transparent forwarders, of greeting card companies, or the legacy of
years of deployed systems, so its
EA> approach to the problem can be a little cleaner.
This requires that random proxies be able to authenticate each other,
without prior arrangement.
So far, that scenario has not scaled well on the net, at least due to
the lack of a global PKI. We have pretty good 'server' authentication to
the client but essentially no client authentication to the server,
without prior arrangement.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>