Subject: [Sipping] New draft to clarify the privacy mechanism

From: Mayumi Munakata <[email-masked]>
Date: Wed, 18 Oct 2006 18:13:39 +0900

Hi all,

We have submitted a new draft clarifying the privacy mechanism.
The draft tries to clarify the semantics of each privacy header 
value (priv-value) and the handling of the target SIP headers 
to be obscured for each of the pre-existing priv-value.  It also
provides some guidelines on providing privacy considerations for
future extensions of SIP headers which may be influenced by the 
privacy mechanism.  This draft is not trying to change any 
existing definitions (RFCs 3323, 3325 and 4244).

During WGLC of acr-code draft, the definitions of priv-values 
in Privacy header were discussed in SIP ML.  It seems like some 
people have different interpretations of Privacy mechanism.
We are afraid that such discrepancy of interpretations will 
cause a lack of interoperability.  This draft is trying to 
clarify the privacy mechanism in order to solve the problem.

Any suggestions and comments would be appreciated.

Clarification of Privacy Mechanism for SIP
draft-munakata-sipping-privacy-clarified-00

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-munakata-sipping-privacy-clarified-00.txt

Thanks,
Mayumi Munakata

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 10:07:27 -0400

Interesting draft.

I'm mostly in agreement with your Table 1. I'm glad to see that you 
structured this so that the actions taken by each option are disjoint. 
If they were overlapping it would present difficulties in 
implementation. Specifically, the appropriate implementation point in 
the route of a request varies from option to option. (User is best done 
near the origination point, session can be done almost anywhere, but the 
others need to be done near to the exit point of the trust domain.)

You included several entries with question marks, but you didn't include 
any discussion of the considerations leading to the question marks. 
Clearly those need to be sorted out.

Also, you describe "strip", which is consistent with current practice up 
to a point. What you don't do is mention that the server doing the 
stripping must restore the stripped value in responses.

Regarding the question marks:

- Warning: what kind of modification did you have in mind? Why?

- Referred-By: modifying this is likely to break the REFER. I think
   this might depend on whether it appears in REFER or INVITE.
   If in a REFER, it reflects the user doing the REFER and so may
   be considered an appropriate subject of Privacy:user.
   If it is in an INVITE, it doesn't identify the sender of the
   request and so may not be an appropriate subject of Privacy:user.

- Replaces: this references specific state held by the target of the
   request. It is obviously already known to the target, and the request
   can't function without it. I don't see what can/should be modified.

- Target-Dialog: same as Replaces.

- Path: This can be stripped from a request, as long as restored
   in the response.

- Service-Route: This only appears in responses. For it to be
   stripped without breaking things, it must be replaced with something
   that will be restored later whenever that value appears in a Route
   header.

	Paul

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Oct 2006 09:55:07 -0700

Hi Paul;

Thanks for your comments.

my comments inline..

Paul Kyzivat wrote:
> the route of a request varies from option to option. (User is best
> done near the origination point, session can be done almost anywhere,
> but the others need to be done near to the exit point of the trust
> domain.)
>
> You included several entries with question marks, but you didn't
> include any discussion of the considerations leading to the question
> marks. Clearly those need to be sorted out.
>
I agree that they needed to be sorted out and that is exactly why
we added the question mark. We wanted other's opinions.
> Also, you describe "strip", which is consistent with current practice
> up to a point. What you don't do is mention that the server doing the
We will add a text explaining each of the action listed/used in
the table.
> - Warning: what kind of modification did you have in mind? Why?
I don't quite recall why we added this. I need to see what Mayumi
has to say on this > Mayumi?
> request and so may not be an appropriate subject of Privacy:user.
I think we are talking about what to do in REFER here.
Whatever "Referred-by" value referee sends in INVITE is what it
obtained through a REFER request from referrer, so I think we only need
to worry about Referred-by value sent in REFER. Should this be
clarified in the text?
> - Target-Dialog: same as Replaces.
Considering Target-Dialog contains call-id, which is to be obfuscated
when "user" is set as a priv-value, I believe same must go for
target-dialog.
> - Path: This can be stripped from a request, as long as restored
Agree.
Shida
>> The draft tries to clarify the semantics of each privacy header value
>> (priv-value) and the handling of the target SIP headers to be
>> obscured for each of the pre-existing priv-value. It also
>> privacy mechanism. This draft is not trying to change any existing
>> definitions (RFCs 3323, 3325 and 4244).
>>
>> During WGLC of acr-code draft, the definitions of priv-values in
>> Privacy header were discussed in SIP ML. It seems like some people
>> have different interpretations of Privacy mechanism.
>> We are afraid that such discrepancy of interpretations will cause a
>> lack of interoperability. This draft is trying to clarify the privacy
>> mechanism in order to solve the problem.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 13:47:21 -0400

> to worry about Referred-by value sent in REFER. Should this be

The interactions here are complex, so I think they do need to be
clarified, and perhaps supported by an example.

The problem is that the Referred-By may be important to authorize the
request, so messing with it may break the request.

Also, there is a question of whose privacy is being protected. Suppose
that Alice sends a refer to Bob, asking for an invite to be sent to
Charlie. If user privacy is being applied to Alice, then that may
require removing info about Alice from the Referred-By in the REFER request.

If user privacy is being applied to Bob (and not to Alice) then there is
no need to do anything to the Referred-By in the INVITE, because it is
associated with Alice, not Bob.

Then think what happens when the invite reaches Charlie. Perhaps Charlie
would accept this if he knew it was referred by Alice, but not otherwise.

There really need to be some examples of how this is supposed to work.

> when "user" is set as a priv-value, I believe same must go for

Again there are multiple parties involved here, and you have to look at
use cases to sort this out.

Suppose Alice called Charlie using call-id C1. No privacy is in effect.

Then Alice sends a REFER to Bob to take over her call with Charlie. The
REFER contains a Replaces that references C1. Bob then generates an
invite to Charlie containing the Replaces with C1. But user privacy is
applied to Bob. You had better not mess with C1 in this case or the call
won't work.

Now try the same thing, except that both Alice and Bob have user privacy
applied.

In that case, callid C1 is replaced with new callid C2 before it gets to
Charlie. When Alice sends the REFER, I guess you want the callid in the
Refer-to to also be replaced by C2. (That could be a difficult
requirement to meet.)

When Bob sends the INVITE, with a Refer-to containing C2, you don't want
that messed with.

	Paul

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Oct 2006 12:39:41 -0700

Hi Paul;

Comments inline.

Agree.
Agree.
> There really need to be some examples of how this is supposed to work.
I think you laid out the example above, if it's the request is REFER
sent from Alice
asking privacy, obviously it would remove Alice from Referred-By. IF the
privacy
is requested by Bob then Referred-By would be untouched as it is not
about Bob.
Would text explaining something along the line of this be sufficient?

As for the consequence this may cause at Charlie, I believe is out of
scope of this draft.

BTW, would you think identity-info, location header be a target as well
for some of the
priv-value(e.g. header) as it generally contains the domain name of the
caller in URI form?

Now if identity is provided, one may doubt the motivation of requesting
privacy but let's
not forget that user requesting the privacy may have no idea
sip-identity is provided as
service. In which case it is completely reasonable for caller to request
privacy even when
the domain serving that user provides sip-identity.

>>> can't function without it. I don't see what can/should be modified.

Sorry I forgot to respond to this but I agree with you, replaces SHOULD
not be
modified.

> Refer-to to also be replaced by C2. (That could be a difficult
Okay obviously we need an example here too.
Let's say Alice is behind privacy service and requesting "header" level
privacy.
1. Alice establishes a dialog with Bob
2. Alice decides to send a REFER to Charlie to replace her call with Bob.
3. Charlie sends an INVITE to Bob to replace the call.

In this case privacy service allocated in front of Alice would need to
modify the target-dialog that would be sent from Alice as it would differ
from the dialog-id Bob if it doesn't.

Alice > C1 > Priv-service > C2 > Bob
Alice > REFER(Bob, target=C1) > Priv Service > REFER(Bob, target=C2) >
Charlie

BTW what about Replaces parameter set to Refer-To header?

Alice > C1 > Priv-service > C2 > Bob
Alice > REFER (Refer-To: Bob?Replaces=C1) > Priv Service > REFER
(Refer-To: Bob ? Replaces = C2) > Charlie

Anyhow, obviously this needs to be illustrated to clarify when privacy
service
should intervene.

Regards
Shida
Agree.

Regards
Shida

---

From: Hendrik Scholz <[email-masked]>
Date: Thu, 19 Oct 2006 15:24:36 +0200

Hi!

I didn't follow the prior discussions but how about the Diversion header?
Diversion as of draft-levy-sip-diversion-08.txt supports a
diversion-privacy tag to protect the original destination.
In contrast to Referred-By it contains the destination not
the source.

The issue I currently see is that removing additional information
might break call log or billing applications.

Cheers,
  Hendrik

-- 
Hendrik Scholz - <[email-masked]> - http://www.wormulon.net/
drag me, drop me - treat me like an object

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 19 Oct 2006 16:23:59 +0200

My next comment is with regard to the  'history' privacy:

The 'history' privacy can be within the Message or within the History Info header itself so we need to extend the table.

Also the same comments with regard to 'header' because also 'history' is a subset of 'header'

So the table with regard to 'history should add a row and change as follows:
Target headers        user       header     session     id      history

History-Info                     not add    not add             delete
History-Info-Entry               not add    not add             delete

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Mayumi Munakata [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. Oktober 2006 11:14
> An: [email-masked]
> Betreff: [Sipping] New draft to clarify the privacy mechanism
> 
> 
> Hi all,
> 
> Clarification of Privacy MechanismFrom [email-masked] Thu Oct 19 10:25:23 2006
Content-class: urn:content-classes:message
Subject: AW: [Sipping] New draft to clarify the privacy mechanism
Date: Thu, 19 Oct 2006 16:23:59 +0200
From: "Jesske, R" <[email-masked]>
To: <[email-masked]>,
    <[email-masked]>
Cc: 

My next comment is with regard to the  'history' privacy:

The 'history' privacy can be within the Message or within the History Info header itself so we need to extend the table.

Also the same comments with regard to 'header' because also 'history' is a subset of 'header'

So the table with regard to 'history should add a row and change as follows:
Target headers        user       header     session     id      history

History-Info                     not add    not add             delete
History-Info-Entry               not add    not add             delete

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Mayumi Munakata [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. Oktober 2006 11:14
> An: [email-masked]
> Betreff: [Sipping] New draft to clarify the privacy mechanism
> 
> 
> Hi all,
> 

Thanks,
Mayumi Munakata

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 19 Oct 2006 16:24:42 +0200

We had already discussion of the interpretation of 'id' and 'header'

I wrote:
I think this is one interpretation how the 'header' privacy is interpreted but looking into 3323 where 'header' is defined is says:

      header: The user requests that a privacy service obscure those
      headers which cannot be completely expunged of identifying
      information without the assistance of intermediaries (such as Via
      and Contact).  Also, no unnecessary headers should be added by the
      service that might reveal personal information about the
      originator of the request.

My interpretation is that the P-Asserted-Identity is also a header 'which cannot be completely expunged of identifying information without the assistance of intermediaries'.
So if the user includes 'header' the P-Asserted-Identity' shall also be anonymised.

I know that the 'id' privacy was defined in an extra context as a P-header draft but the general rules of SIP shall apply. So also the rules of RFC3323. 

So what I understand from the answers was, that this assumpt for SIP

Thanks,
Mayumi Munakata

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 19 Oct 2006 16:24:42 +0200

I wrote:

So what I understand from the answers was, that this assumption seen from the pure words within RFC 3323 and 3325 is correct.

So this should be reflected within your draft and table as follows.

arget headers        user       header     session     id      history

P-Asserted-Identity              delete     delete    delete

Best Regards

Roland

Thanks,
Mayumi Munakata

ion seen from the pure words within RFC 3323 and 3325 is correct.

So this should be reflected within your draft and table as follows.

arget headers        user       header     session     id      history

P-Asserted-Identity              delete     delete    delete

Best Regards

Roland

Thanks,
Mayumi Munakata

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 19 Oct 2006 16:28:32 +0200

Diversion can now be done with the History-Info Header in RFC 4244. And this is covered with the priv value 'history'.

Best Regards

Roland

> Von: Hendrik Scholz [mailto:[email-masked]] 
> Gesendet: Donnerstag, 19. Oktober 2006 15:25
> An: Mayumi Munakata
> Cc: [email-masked]
> Betreff: Re: [Sipping] New draft to clarify the privacy mechanism
> 
> 
> Hi!
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Oct 2006 13:56:08 -0400

I think there is difficulty if you make any of these options be a subset 
of some other option. It adds confusion to who should do the task.

Also, I think there needs to be some clarity on where in the call path 
these things are to be done. In the case of "id" it is clear that it 
needs to be done on the edge of the trust domain. Its not so clear for 
the rest. "User" and "session" *can* be done near the originating point.

For instance, must "header" be done at the exiting edge of the trust 
domain? Or can it be done earlier? The problem with doing it earlier is 
that it only affects the headers present at that time, not those that 
get added subsequently.

	Paul