On Jul 3, 2007, at 9:38 PM, Jonathan Rosenberg wrote:
inline.
Dean Willis wrote:
So what? I think thats what ought to happen. I'd like to see some
specific use cases where this can't work with the edge proxy
performing the authentication. Keep in mind, we are talking about
*certificate* authentication; that doesn't (by definition)
required any kind of pre-arranged secret - only a common root CA.
My edge proxy might be provided by MCI, but I might be using a
chat service from another provider overseas. This other provider
might be willing to trust the certificate for authentication
(given that I have a signed cert from MCI, who in turn has a
signed CA cert from a recognized op-level CA). However, the chat
provider might not be willing to just accept P-Asserted-Identity
from MCI as an authentication mechanism, since said provider does
not have a trusted peering arrangement with MCI and therefore
ANYBODY could spoof my P-Asserted-Identity.
In a case where your chat provider has no relationship whatsoever
with this edge proxy, for what purpose would you be connecting to
it in the first place? You should connect directly to your chat
provider offering the service. Then, if you have a cert - great -
authenticate to it using mutual TLS.
Well, I might be doing "outbound" with my edge proxy in order to get
some help from it for relaying messaging back through my NAT. Or it
might be a QoS-controlling proxy ala PacketCable. Or a firewall-
control-proxy . . .
The chat provider might not just be on the other side of my edge
proxy, but on the other side of my home serving proxy too. And the
certificate auth stuff would appear to be able to traverse that proxy
as well.
--
Dea
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
