Subject: [sipcore] Applicability of privacy "header"

From: Jörgen Axell <[email-masked]>
Date: Thu, 8 Jun 2017 13:30:29 +0000

I have been involved in recent discussions on whether Privacy: "header" applies to P-Asserted-Identity, or rather whether the original meaning of RFC 3323 was that it applies to PAI. The uncertainty introduced in RFC 3323 is imported by 3GPP by explicit references.

The reason this is unclear is that RFC 3323 section 5 states that the document defines the logical role of "privacy service" and states the applicability as: "The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves." So in my mind the question is whether the inclusion of Privacy: "id" by a UA as specified in RFC 3325 fulfills the "provided by user agents themselves."

It makes logical sense to not cover PAI with "header" as there is a separate privacy value for this.

Anyone having a comment or knows the original intent?

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist
Business Unit Cloud and IP

Ericsson
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450
[email-masked]
www.ericsson.com

Legal entity: Ericsson AB, registered office in Kista. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Brett Tate <[email-masked]>
Date: Fri, 9 Jun 2017 10:46:49 -0400

Hi,

The following snippet from RFC 3325 section 9.3 seems applicable: “Note
that a user requesting multiple types of privacy MUST include all of the
requested privacy types in its Privacy header field value.”

Concerning "header", RFC 3323 indicates “server SHOULD NOT add any headers
to the message that reveal any identity”.  However, my recollection is that
it doesn’t prevent intermediaries from adding PAI with/without intermediary
also adding privacy "id".

Thus, your interpretation sounds correct.

*From:* sipcore [mailto:[email-masked]] *On Behalf Of *Jörgen
Axell
*Sent:* Thursday, June 08, 2017 9:30 AM
*To:* 'sipcore'
*Subject:* [sipcore] Applicability of privacy "header"

I have been involved in recent discussions on whether Privacy: "header"
applies to P-Asserted-Identity, or rather whether the original meaning of
RFC 3323 was that it applies to PAI. The uncertainty introduced in RFC 3323
is imported by 3GPP by explicit references.

The reason this is unclear is that RFC 3323 section 5 states that the
document defines the logical role of "privacy service" and states the
applicability as: "The function of a privacy service is to supply privacy
functions for SIP messages that cannot be provided by user agents
themselves." So in my mind the question is whether the inclusion of
Privacy: "id" by a UA as specified in RFC 3325 fulfills the "provided by
user agents themselves."

It makes logical sense to not cover PAI with "header" as there is a
separate privacy value for this.

Regards,

Jörgen

*Dr.* *JÖRGEN AXELL*
Senior specialist

*Ericsson*
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450
[email-masked]
www.ericsson.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ericsson.com&d=DwQFAw&c=uiYkEnhlQB0H-gDwErXr4Q&r=8Yr-1qTsPmhitR1Vv92TJ3hY6pQbjzLOi7kQZYxxXJY&m=lop9AQtw4m7WqeALFbxQ2YwvFQ3_iQZPMYOg8m1OuFQ&s=iRz8s-E_kjz4ZfrN3DHn2THWV8TgWZu5A-gqP_qGYhM&e=>

Legal entity: Ericsson AB, registered office in Kista. This Communication
is Confidential. We only send and receive email on the basis of the terms
set out at www.ericsson.com/email_disclaimer
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ericsson.com_email-5Fdisclaimer&d=DwMFAw&c=uiYkEnhlQB0H-gDwErXr4Q&r=8Yr-1qTsPmhitR1Vv92TJ3hY6pQbjzLOi7kQZYxxXJY&m=lop9AQtw4m7WqeALFbxQ2YwvFQ3_iQZPMYOg8m1OuFQ&s=IBineJYihvvkPriK4cufXct5XCb1f1i2SkKTGmIbKwY&e=>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Jun 2017 00:13:13 +0000

I have to say that I think the opposite is actually the case.

The various different privacy types may be enacted by multiple different entities within the network, and each of those entities might not know which other entities in the SIP path exist. Additionally the invoking UE may want to cover all bases by including as many protections as possible. Therefore it is certainly reasonable to me that multiple privacy types can appear in the same Privacy header field.

Any entity providing privacy should therefore fulfil the semantics of the privacy type it sees, understands, and provides capability for. Given that the P-Asserted-ID clearly is a header field providing information about the user, the it should be suppressed if header privacy is enacted.

I agree it could be argued that such a header field should not be in a message where header privacy is requested, but that should not stop it being removed if it is present.

Regards

Keith

From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: 09 June 2017 15:47
To: sipcore <[email-masked]>; Jörgen Axell <[email-masked]>
Subject: Re: [sipcore] Applicability of privacy "header"

Hi,

The following snippet from RFC 3325 section 9.3 seems applicable: “Note that a user requesting multiple types of privacy MUST include all of the requested privacy types in its Privacy header field value.”

Concerning "header", RFC 3323 indicates “server SHOULD NOT add any headers to the message that reveal any identity”.  However, my recollection is that it doesn’t prevent intermediaries from adding PAI with/without intermediary also adding privacy "id".

From: sipcore [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jörgen Axell
Sent: Thursday, June 08, 2017 9:30 AM
To: 'sipcore'
Subject: [sipcore] Applicability of privacy "header"

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist

Ericsson
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450
[email-masked]<mailto:[email-masked]>
www.ericsson.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ericsson.com&d=DwQFAw&c=uiYkEnhlQB0H-gDwErXr4Q&r=8Yr-1qTsPmhitR1Vv92TJ3hY6pQbjzLOi7kQZYxxXJY&m=lop9AQtw4m7WqeALFbxQ2YwvFQ3_iQZPMYOg8m1OuFQ&s=iRz8s-E_kjz4ZfrN3DHn2THWV8TgWZu5A-gqP_qGYhM&e=>

Legal entity: Ericsson AB, registered office in Kista. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ericsson.com_email-5Fdisclaimer&d=DwMFAw&c=uiYkEnhlQB0H-gDwErXr4Q&r=8Yr-1qTsPmhitR1Vv92TJ3hY6pQbjzLOi7kQZYxxXJY&m=lop9AQtw4m7WqeALFbxQ2YwvFQ3_iQZPMYOg8m1OuFQ&s=IBineJYihvvkPriK4cufXct5XCb1f1i2SkKTGmIbKwY&e=>

---

From: Jörgen Axell <[email-masked]>
Date: Wed, 21 Jun 2017 07:24:24 +0000

Multiple privacy values are normal. The question is how much and if they overlap. Of course an entity providing privacy acts on the types it understands. P-Asserted-ID is providing information about the user, but it is not added by the UE, it is added by the network. So the argument that the P-Asserted-ID is out of scope of header privacy in RFC3323 is that the RFC 3323 defined privacy service only applies to "privacy functions for SIP messages that cannot be provided by user agents themselves" and since RFC 3325 gives the UE a tool (privacy value "id") to provide privacy then P-Asserted-ID is out of scope for the privacy service defined in RFC 3323.

This is similar to why header privacy does not affect the From header field ("user" privacy is used for this). The UE can take care of this itself by setting the header to an anonymous URI.

Or do you think there is a fundamental difference between including a Privacy "id" from setting the From header field to [email-masked]?

Jörgen

From: sipcore [mailto:[email-masked]] On Behalf Of Drage, Keith (Nokia - GB)
Sent: 21 June 2017 02:13
To: Brett Tate <[email-masked]>; sipcore <[email-masked]>; Jörgen Axell <[email-masked]>
Subject: Re: [sipcore] Applicability of privacy "header"

Regards

Keith

From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: 09 June 2017 15:47
To: sipcore <[email-masked]<mailto:[email-masked]>>; Jörgen Axell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Applicability of privacy "header"

Hi,

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist

Ericsson
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Jun 2017 10:31:42 +0000

I am saying that if privacy values overlap, then the presence of one impacting content should not impact the presence of another impacting content.

I would note that I have not found any text specific to the “header” privacy value that says it does not apply to From and To, so where did you gain that information from.

5.1 of RFC 3323 identifies the specific actions that should be taken on a number of header fields, but I don’t think that this list is complete, or was ever intended to be complete – do any of the readers of this message believe it is?

In my view it then comes down to the definition of “header” privacy in RFC 3323 as to which header fields it impacts:

“      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.
”

I believe the last line applies only to the privacy server, and not to any other SIP proxy, otherwise all proxies in the call path would need to take special action on Contact, etc.

The question therefore is solely one of whether the text encompasses the P-Asserted-ID header field. My view is that it can be inserted prior to the privacy server without the knowledge of the user and the privacy server has no knowledge as to whether intermediaries will remove it. As such it applies, but I agree it is arguable. But the issue does come down to the interpretation of this bit of text and not to the presence, or absence. of any other privacy header value.

I understand that P-Asserted-ID is information that can added by the network (but is done so based on P-Preferred-ID), but there are many other header fields that can be modified or inserted by the network that potentially contain information about the user. I do not think an entity implementing “header” privacy should be forced into an analysis of which entity inserted or changed the information in order to decide whether to apply the privacy. Note that I can also identify use cases where the P-Asserted-ID is created by the end UA (a protocol interworking unit is a common case of this, but additionally from the public network viewpoint a number of enterprise networks do this but are still regarded as UAs from the public network viewpoint).

I do note that RFC 3323 permits cases where the user is not aware of privacy, so it may well be that the privacy service has to take account of information unintentionally inserted by the user:

“   A user may not always be the best judge of when privacy is required
   even under ideal circumstances, and thus privacy may in some
   architectures by applied by intermediaries without the user's
   explicit per-message request.  By sending a request through
   intermediaries that can provide a privacy role, the user tacitly
   permits privacy functions to be invoked as needed.
”

Keith

From: Jörgen Axell [mailto:[email-masked]]
Sent: 21 June 2017 08:24
To: Drage, Keith (Nokia - GB) <[email-masked]>; Brett Tate <[email-masked]>; sipcore <[email-masked]>
Subject: RE: [sipcore] Applicability of privacy "header"

Or do you think there is a fundamental difference between including a Privacy "id" from setting the From header field to [email-masked]<mailto:[email-masked]>?

Jörgen

From: sipcore [mailto:[email-masked]] On Behalf Of Drage, Keith (Nokia - GB)
Sent: 21 June 2017 02:13
To: Brett Tate <[email-masked]<mailto:[email-masked]>>; sipcore <[email-masked]<mailto:[email-masked]>>; Jörgen Axell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Applicability of privacy "header"

Regards

Keith

Hi,

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist

Ericsson
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450

---

From: Jörgen Axell <[email-masked]>
Date: Wed, 21 Jun 2017 14:53:48 +0000

I never mentioned To I hope, but for the From header my reasoning is that section 5 first paragraph states:
   The function of a privacy service is to supply privacy
   functions for SIP messages that cannot be provided by user agents
   themselves.
and I read "cannot be provided by user agents themselves " as referring to "privacy functions". So if the user agent can supply those privacy functions the privacy service does not do that. In the header definition you quote it is still the privacy service that performs the anonymization or removal but it does not look for user provided headers.

The From header is then set by the user agent and the privacy service does not touch that. Privacy "user" can be explicitly used to anonymize the From header and other user agent provided headers but "user" is mostly inserted by a network entity except for REGISTER.
Similar reasoning for the PAI where irrespective of who inserts it, the user agent can decide that privacy is to be applied by adding the privacy value "id".

This interpretation makes the values "user", "id" and "header" disjoint which I think is good design as it is simpler.

Jörgen

From: Drage, Keith (Nokia - GB) [mailto:[email-masked]]
Sent: 21 June 2017 12:32
To: Jörgen Axell <[email-masked]>; Brett Tate <[email-masked]>; sipcore <[email-masked]>
Subject: RE: [sipcore] Applicability of privacy "header"

Keith

From: Jörgen Axell [mailto:[email-masked]]
Sent: 21 June 2017 08:24
To: Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; Brett Tate <[email-masked]<mailto:[email-masked]>>; sipcore <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sipcore] Applicability of privacy "header"

Jörgen

Regards

Keith

Hi,

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist

Ericsson
Grönlandsgatan 31
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450