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

["Brian Rosen" <br at brianrosen.net>]

I've wondered about this myself.

Further, I don't want to foster interdomain use of P-A-I without the kinds
of "Trust Domain" specifications 3325 discusses.  I think we have the
problem now where most people ignore most of these issues in using P-A-I.

I'm particularly distressed by the use of P-A-I to assert the Main Number.
If we need such a facility, we should create one, and allow SIP Identity to
validate it.

I'd really like us to be thinking that we phase out P-A-I when Sip Identity
is deployed.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Wednesday, October 18, 2006 9:30 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
> 
> Roland's comments below are a reflection of a general issue about the
> semantics of identity that seems to be brewing.
> 
> On one hand we have a set of people who are trying to restore the lost
> usefulness of the From header, by providing a way to prove its validity
> as an identity.
> 
> On the other hand we have a different set of people who *like* the fact
> that From is an unauthenticated assertion of identity, and want to keep
> it that way.
> 
> Or do I have the latter wrong? Maybe its ok if From gets authenticated
> as long as there is still a way to have another asserted identity as well.
> 
> 	Paul
> 
> 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
> >
> >
> >
> > _______________________________________________
> > 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


_______________________________________________
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