Subject: Re: [Sipping] Screened From: and Privacy

From: [email-masked]
Date: Thu, 18 Apr 2002 15:39:43 EDT

In a message dated 4/18/02 1:20:14 AM Eastern Daylight Time, 
[email-masked] writes:

> 
> if the user has given display string "Anonymous" and the call gets
> routed to sip destination, i must implement b2bua and make also the from
> uri anonymous.  if the call gets routed to pstn, i set the calling party
> number blocking parameter.
> 
> <snip>
> 
> i still don't understand what this whole thread is all about and i still
> haven't got a reply to my question what advantage rpid or some other new
> header field would bring as compared to the current situation.
> 
> -- juha
> 

It's obvious to me that there is not a consistent opinion of what the 
"current situation" is. I believe I've heard several different 
interpretations of what bis-09 says regarding the From and the use of 
"anonymous" in the Display name. For example, your comment above is that, if 
the user puts in "Anonymous", you (as the servie provider) must do something 
to the uri. I don't read that in bis-09. It says that if the user wants to 
remain hidden "a UAC SHOULD use ... "Anonymous", along with ... a meaningless 
URI." So what really is the "current situation"?

In a message dated 4/18/02 8:02:13 AM Eastern Daylight Time, 
[email-masked] writes:

> you could define another header field for that purpose, but in the
> meanwhile, i need to be able to run my sip service with CURRENT UAs,
> proxies, and sip/ss7 gws all of which today support the from uri +
> display string trick as i have described.  since my basic rule is "if it
> not broken, don't fix it", i'm not interested to change the current
> working practice just for the sake of it.
> 
> -- juha
> 
Again, I think the comments and different opinions expressed clearly indicate 
that it is "broke", even if it may just be the description of the use of From 
and "Anonymous". But it seems that any attempt to redefine (or better 
define?) these fields results in a claim that it "breaks" some current 
implementation.

In a message dated 4/18/02 7:46:00 AM Eastern Daylight Time, 
[email-masked] writes:

> Yes, 3GPP has this requirement too. But it is a slightly separate question 
> from the NAI itself. If we follow the SHOULD in the SIP specification about 
> the From uri being meaningless when the user requests privacy, then another 
> field is needed to allow the user to choose which identity will be used for 
> 

Yes, I believe Mark is correct, another field is required which is only 
intended for the UA to tell the "network" their identity and the network is 
expected to verify it and may reject calls that don't have a valid identity. 
The UA can not fill it with "meaningless" information. In some cases it may 
be omitted. What the "network" might do with it is another issue.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Thu, 18 Apr 2002 17:45:13 -0400

I finally got to the end of this thread!
My observation of what this boils down to:

The user may wish to project a public identity end-to-end (UAI).
The UAI may not be valid for authentication.
The network has a need to identify the user to authorized third parties (NAI).
There are legal requirements for "public" service providers to restrict the 
NAI.

Question:  Can UAI and NAI be one and the same?
Answer: Not unless:
a) it is possible to modify that parameter along the way,
b) it is OK to block the end-to-end UAI.

If you want From: field that means it must be modifiable or use B2BUA.

To meet legal requirements:
The network entity must be able to authenticate the subscriber.
The network entity must be able to set/reset the NAI value.
The network entity must be able to restrict passing the NAI value to any 
next hop not authorized to see it.

The question of hop-by-hop versus end-to-end trust chains determines 
whether a crypto-based solution or service agreement arrangement may be used.

One added wrinkle:  Given that a public service provider may not have 
sufficient information to authenticate the data in the From: field, will 
the legal requirements drive all intermediate hops to be public service 
providers if the From: field falls under the Privacy Rules?  (Falls out of 
the assumption that a public carrier refuses all calls unless from a 
trusted carrier, or from an authenticatable user.)

Mike

At 03:39 PM 4/18/2002 -0400, [email-masked] wrote:
>"anonymous" in the Display name. For example, your comment above is that, 
>if the user puts in "Anonymous", you (as the servie provider) must do 
>something to the uri. I don't read that in bis-09. It says that if the 
>user wants to remain hidden "a UAC SHOULD use ... "Anonymous", along with 
>... a meaningless URI." So what really is the "current situation"?
>
>Again, I think the comments and different opinions expressed clearly 
>indicate that it is "broke", even if it may just be the description of the 
>use of From and "Anonymous". But it seems that any attempt to redefine (or 
>better define?) these fields results in a claim that it "breaks" some 
>current implementation.
>
>>Yes, 3GPP has this requirement too. But it is a slightly separate 
>>question from the NAI itself. If we follow the SHOULD in the SIP 
>>specification about the From uri being meaningless when the user requests 
>>privacy, then another field is needed to allow the user to choose which 
>>identity will be used for the Network Asserted Identity out of a 
>>particular set.
>
>
>intended for the UA to tell the "network" their identity and the network 
>is expected to verify it and may reject calls that don't have a valid 
>identity. The UA can not fill it with "meaningless" information. In some 
>cases it may be omitted. What the "network" might do with it is another issue.
>
>Mike

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