Steve Dotson wrote:
Maybe this is naïve, but doesn't this alter the operator trust model?


I always envisioned P-A-ID (as an example) as a way for a home
network to tell a 3rd party service "trust this one, they are
authenticated", as long as the home network and the service had a
relationship. Having an edge proxy in a visited domain telling the
home network "trust this one" seems to turn things around.

P-A-ID asserts identity between providers with trust, yes that is true. SIP Identity works with lesser degrees of trust, but if you don't trust the signing domain, of course it doesn't work.

However, my point is, one of the two following scenarios always apply:

1. the edge proxy is trusted by the home proxy, in which case you can use mutual TLS to authenticate the client to the edge proxy, and then P-A-ID or SIP Identity from edge proxy to home proxy, *OR*

2. there is no trust at all between visited and home networks. In this case, you shouldn't be connectign to a visited proxy in the first place. COnnect to the home proxy in your home network. Then, case 1 applies again.


In other words, the entire motivation behind this draft is based on an assumption that a client needs to connect to its actual proxy through an intermediate proxy that no one trusts. SO many things get broken in that model. So, don't do it! This idea of a visited proxy with whom I have no relationship, is totally broken. ALl of the reasons people list for wanting them, we have far better solutions for (NAT traversal, firewall traversal, QoS). I'll note further that QoS can never work in a model without trust.

-Jonathan R.



--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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

Reply via email to