Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 22 Jun 2006 15:38:07 -0400

A domain in the RFC3325 sense, that is a "trust domain", is somewhat strictly defined in RFC3324 Section 2.3. Without that definition, which Mr. Watson produced in the face of my increasing skepticism about the nebulous manner in which domain boundaries were being discussed, there would be no RFC3325. Perhaps that definition would be of service here.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2006 4:49 PM
> To: Paul Kyzivat
> Cc: IETF SIP List
> Subject: Re: [Sip] New draft on coexistence of SIP identity and
> P-Asserted-ID
> 
> 
> I view a domain, in the SIP context, as a set of proxies under single 
> administrative control. This is also somewhat loosely defined, I admit. 
> The main idea is that, since a single administrative entity manages the 
> proxies (configuring them, operating them, etc.), it has complete 
> confidence that it knows the precise and absolute conditions under which 
> P-Asserted-ID was inserted into the request.
> 
> There is trust inter-domain, but knowledge about the configuration of 
> the proxy that resulted in insertion of P-Asserted-ID isn't known 
> directly - its known indirectly by trusting that the peer domain did its 
> job. I think thats different.
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
> 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> >>> - While it is clear that you are trying to tighten up the 
> security of 
> >>> identity from what it is in 3325, I'm not convinced that 
> requiring 
> >>> the removal of P-Asserted-Identity when receiving a request from 
> >>> another domain actually achieves anything. Suppose it 
> were left in? 
> >>> That means that if some server along the path was bad or 
> inept the 
> >>> assertion might be a lie. But a bad or inept server in the 
> >>> originating network, before signing, can also result in 
> an assertion 
> >>> that is a lie, and then result in a signature for that 
> lie, and then 
> >>> to that being trusted in the terminating network.
> >>
> >>
> >> The main point is that I am trying to change the scope of 
> >> P-Asserted-ID to intra-domain, and thus by definition any value 
> >> received from outside the domain is meaningless.
> > 
> > 
> > I think this begs the question of what it means for a message flow 
> > between a sender and a receiver to be "in the domain" vs 
> "outside the 
> > domain". When sip:edge1.atlanta.com sends a message to 
> > sip:home3.atlanta.com, how do they decide they are in the 
> same domain, 
> > and that it is the atlanta.com domain?
> > 
> > Isn't that itself all a matter of trust? Or is there some formal 
> > definition of it? If it is all a matter of trust, then why 
> is it ok for 
> > sip:home3.atlanta.com to trust sip:edge1.atlanta.com but 
> not ok to trust 
> > sip:edge5.biloxi.com?
> > 
> > Are all the atlanta.com servers supposed to be using TLS 
> with mutual 
> > authentication and certs that say they are in atlanta.com? 
> But then how 
> > do they prove they are the specific server they claim?
> > 
> > Even in this case, why is it ok to trust the proxies in 
> your own domain 
> > but not ok to trust those in another domain. Some providers are 
> > federations of semi-autonomous divisions, but want to 
> appear to be a 
> > single domain. But that doesn't make them all equally 
> competent. The 
> > trust of one division by another may not be as great as its 
> trust in 
> > some other domain.
> > 
> >     Paul
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              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-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jun 2006 20:36:09 -0400

> A domain in the RFC3325 sense, that is a "trust domain", is somewhat strictly defined in RFC3324 Section 2.3. Without that definition, which Mr. Watson produced in the face of my increasing skeptic…

Yep, I think it would.

And, since the issue at hand is about the use of P-Asserted-Identity, 
which is defined by 3325, and 3325 already references 3324. However, for 
some reason it only references it informatively. So for purposes here it 
  may eventually need to become a normative reference.

	Paul

P.S. Jon - if you insisted on 3324 as a prerequisite for 3325, then why 
did you let them get away without a normative reference?