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

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Jun 2006 21:38:01 +0100

Jonathan,

Interesting. I have posted the following draft:
http://www.ietf.org/internet-drafts/draft-elwell-sip-tispan-connected-identi
ty-00.txt
   ETSI TISPAN has presented Next Generation Network (NGN) requirements
   for the delivery of two identities for the caller and two identities
   for the callee in a SIP INVITE-initiated dialog.  Although the
   solution for this in SIP is relatively straightforward for caller
   identity, the delivery of callee identity presents some additional
   problems.  This document discusses the issues and suggests some
   candidate solutions.

This has arisen from my recent discussions with some ETSI TISPAN people
following some discussions a few weeks ago on the SIP list. Basically TISPAN
wants to support the concept of delivering two numbers to identify a party,
as indicated in their requirements draft
(draft-jesske-sipping-tispan-requirements-02 - now expired). For this
purpose they are using PAI and From for the two identities (where the From
identity could be authenticated by Identity). This does seem to be in
conflict with the proposal in your draft. I think we need to find some way
of accommodating TISPAN requirements as well as finding a way to encourage
the deployment of Identity.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 19 June 2006 14:27
> To: IETF SIP List
> Subject: [Sip] New draft on coexistence of SIP identity and 
> P-Asserted-ID
> 
> As folks know, we have defined both P-Asserted-ID and SIP-identity. 
> Though the intention is for SIP-identity to replace 
> P-Asserted-ID, there 
> are a number of practical challenges in doing this. SIP identity 
> requires both sides of the call to support it, and it doesn't work at 
> all with b2buas with media (whether THAT is a bug or a feature is a 
> matter of perspective).
> 
> I've written an I-D that describes a pretty straightforward technique 
> for allowing both mechanisms to simultaneously co-exist. Its 
> backwards 
> compatible with rfc3325 and works in the presence of b2bua's 
> under many 
> (but not all) conditions. The essential idea is to use SIP identity 
> inter-domain and P-Asserted-ID intra-domain. Until it appears in the 
> archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coe
> xistence-00.txt
> 
> Thanks,
> Jonathan R.
> -- 
> 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: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 23 Jun 2006 16:05:07 +0100

My understanding is that the requirement to complete Spec(T) in RFC 3325 is the implementation of the RFC 3324 requirement that you identify. Therefore RFC 3324 never needed to be a normative reference from RFC 3325.

>From RFC 3325:

   "A key requirement of [5] is that the behavior of all nodes within a
   given Trust Domain 'T' is known to comply to a certain set of
   specifications known as 'Spec(T)'.  Spec(T) MUST specify behavior for
   the following:

   1. The manner in which users are authenticated

   2. The mechanisms used to secure the communication among nodes within
      the Trust Domain

   3. The mechanisms used to secure the communication between UAs and
      nodes within the Trust Domain

   4. The manner used to determine which hosts are part of the Trust
      Domain

   5. The default privacy handling when no Privacy header field is
      present

   6. That nodes in the Trust Domain are compliant to SIP [1]

   7. That nodes in the Trust Domain are compliant to this document

   8. Privacy handling for identity as described in Section 7.

   An example of a suitable Spec(T) is shown in Section 11."

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 23 June 2006 01:36
> To: Peterson, Jon
> Cc: IETF SIP List
> Subject: Re: [Sip] New draft on coexistence of SIP identity and
> P-Asserted-ID
> 
> 
> 
> 
> Peterson, Jon wrote:
> > 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.
> 
> 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?
> 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> >> 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
> >>>
> >> --