[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments

OK, I'm sorry. This draft *does* talk about removing the P-A-ID. I was thinking of the discussion about connected identity which has been loosely associated with this.

What this draft doesn't do is relate its use of P-A-ID with the Privacy header, and specifically Privacy:id.

The action it specifies for an egress proxy can cause the P-A-ID to be removed in cases where a proxy conforming to 3325 would leave it in.

I am inclined to agree with Jonathan about how things ought to work. But I do think it can be arranged so that the two approaches can be made to coexist. Its all a matter of defining a suitable policy around the interaction of these two mechanisms.

If an egress proxy (P-CSCF) discovers that P-A-ID doesn't match From, and if there is no Privacy:id header, it can simply leave P-A-ID in the requeest. If an ingress proxy finds a P-A-ID and the message is received from a source it trusts, it could leave that in the message and not attempt to verify any Identity header.

	Paul

Jonathan Rosenberg wrote:
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



_______________________________________________
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