RE: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments

["Michael Hammer \(mhammer\)" <mhammer at cisco.com>]

Jonathan,

The text seems to be saying that the PAID must take the value of the
From, even though it may be bogus, and where the trust domain can
determine form other means the true identity of the sender.

The problem is in forcing PAID to conform to whatever the sender put in
the From.

Mike
 

> -----Original Message-----
> From: Jonathan Rosenberg (jdrosen) 
> Sent: Wednesday, October 18, 2006 10:28 AM
> To: Jesske, R
> Cc: sip at ietf.org; Dieter.Jacobsohn at t-mobile.net; Seibel,Matthias
> Subject: Re: 
> [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments
> 
> Well, this harkens back to my rant during the last IETF 
> meeting. My point was that this usage of both P-A-ID and From 
> you are describing is not the semantics implied by RFC 3325 
> or RFC 3261, but rather a "decision" by 3gpp, ITU and others 
> to use PAID as a billing identity.
> 
> Indeed I quote RFC 3325:
> 
> 9.1 The P-Asserted-Identity Header
> 
>     The P-Asserted-Identity header field is used among trusted SIP
>     entities (typically intermediaries) to carry the identity 
> of the user
>     sending a SIP message as it was verified by authentication.
> 
> 
> To me, the "identity of the user sending a SIP message" is 
> NOT the "identity of the entity that will be billed for this 
> request". It means as it says - it is the identity of the 
> *user* that *sent* the request.
> 
> Quoting from RFC 3261:
> 
> 8.1.1.3 From
> 
>     The From header field indicates the logical identity of 
> the initiator
>     of the request, possibly the user's address-of-record.
> 
> 
> These are identical definitions, the only difference being 
> the term 'logical', which is implied I think in any system 
> that assigns identities to users.
> 
> I would like to understand how one can interpret these texts 
> to mean that P-A-ID is a billing identity while From is the 
> user's identity.
> 
> -Jonathan R.
> 
> 
> Jesske, R wrote:
> 
> > Dear all,
> > With regard to the following section I have some concerns regarding 
> > the thought use of the P-Asserted-Identity.
> > 
> > 4.3.  Ingress Proxy
> > 
> > ....  If the identity
> >    is verified, the ingress proxy SHOULD insert a 
> P-Asserted-ID header
> >    field containing the identity contained in the From 
> header field of
> >    the request.  The proxy SHOULD NOT remove the Identity 
> and Identity-
> >    Info header fields.  This allows for SIP networks where there are
> >    more than two administrative domains in a request path, and also
> >    allows for a UA to verify the signature on its own if it should
> >    desire....
> > 
> > This will violate the use of the From and 
> P-Asserted-Identity header 
> > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the 
> > mapping with the PSTN.
> > 
> > The P-Asserted-Identity is used as a public ID that is trusted. The 
> > From header is set by the user itself and is untrusted. So 
> that there 
> > is the possibility to have two different identities within 
> one INVITE.
> > To equalise such identities within a B2BUA at the ingress 
> even if the
> >>From is also a now secure and trusted ID.
> > 
> > Within the NGN this two identities are used for PBX services to 
> > present the main PBX number and a individual extension of the PBX.
> > 
> > Also the deletion and re-inclusion is against the rules of 
> the RFC3325.
> > The destination domain is not allowed to change the identity of the 
> > originating domain.
> > 
> > If such procedures will be done also charging and billing 
> mechanisms 
> > used between domains will be violated. because the 
> P-Asserted-Identity 
> > is the base identity of the origin domain on Billing and charging.
> > 
> > Best Regards
> > 
> > Roland
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen at cisco.com                              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 
> sip-implementors at cs.columbia.edu for questions on current sip 
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip