Subject: [Sipping] History information privacy requirements

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Jan 2003 08:30:31 +0000

Mary and others,
 
I don't want to open up the whole discussion we had a few weeks ago, but
having read version 01 of the history requirements document I feel that we
perhaps need to make an addition.
 
Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information
about the originator of the request (according to the preceding sentence).
Privacy requirements of other users are not mentioned. I think they should
be discussed in the document, even if the conclusion is that no additional
requirements are placed on the solution.
 
1. Privacy requirements of the retargeted-to user.
 
1.1 This user may wish not to have his identity revealed to the originator.
This, of course, can apply to any request, not just requests that have
undergone retargeting. However, it is likely to be of greater relevance to a
request that has been retargeted. A destination user can protect his privacy
using RFC3323. It is important that the provisions of RFC3323 are not
compromised as a result of retargeting.
 
2. Privacy requirements of the retargeting user.
 
2.1 This user may be unwilling to disclose to the originator the fact that
retargeting has occurred
 
2.2 This user may be willing to disclose to the originator the fact that
retargeting has occurred but unwilling to disclose to the originator the
identity of the retargeted-to user.
 
2.3 This user may be unwilling to disclose to the retargeted-to user the
fact that retargeting has occurred
 
2.4 This user may be willing to disclose to the retargeted-to user the fact
that retargeting has occurred but unwilling to disclose to the retargeted-to
user the identity of the previous target.
 
NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these
requirements are supported in public ISDN.
 
2.5 The retargeting user can also be a retargeted-to user of a previous
retarget. As such requirement 1.1 above can apply, i.e., the retargeting
user (retargeted-to user of previous retarget) is unwilling to disclose his
identity to the originating user.
 
2.6 The retargeting user has some of the characteristics of an originator if
the request is retargeted again further downstream. As such PRIV-req-1 and
PRIV-req-2 can apply to a retargeting user.
 
Regards,
 
John
 
John Elwell
e-mail: mailto:[email-masked] <mailto:[email-masked]>  

_______________________________________________
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: "Mary Barnes" <[email-masked]>
Date: Wed, 15 Jan 2003 17:55:07 -0600

John,

The purpose of the requirements is to ensure that the protocol has the
necessary elements to support any privacy requirements.  The intent of
PRIV-Req-1 was to ensure that user requested privacy is maintained as
retargeting occurs and the intent of PRIV-Req-2 is to address the need for
any entity (Proxy or UAS) receiving the information to maintain the privacy,
with the implication that any privacy mechanism is based on RFC 3323. Now,
perhaps the problem is that these requirements are currently too general and
need to be more specific, although I think getting more specific involves
getting more solution oriented. I could see the need to add a bit more
background to section 5. 

You are correct that RFC3323 does briefly discuss the privacy requirements
of the destination, but I think the clear recommendation is that you would
have provided a URI that doesn't reveal any information that you wouldn't
want disclosed. It clearly does not specify how you can maintain
functionality if you apply privacy to things like Record Route and does
clearly state that there's no way to privacy protect information needed to
route a request, however, you can somehow "disguise" the URI so that it
minimizes the privacy impact. (Jon, please do clarify if I've misinterpreted
this here). 

As Mark pointed out in the conclusion to the previous thread, existing
networks might appear to have this as a requirement, but it's not a general
requirement for SIP.
http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.htm
l
I'm only personally familiar with how this works in the US with my
understanding primarily based upon how my home service works, as specified
by an insert provided by SWBell in 1995.  It clearly states that even if one
activates the feature to block the calling line ID, that this information is
still sent to the network and may not be blocked on calls to 800/900
numbers.  The blocking of the called party is typically not provided for a
PSTN user (for the same reason it's not done for Request URIs - you can't
reach the guy if you do so and is entirely application specific.  There are
examples where the actual DN of a destination isn't revealed, but that's all
due to application specific logic and not the protocols (e.g call centers
internally route calls without providing an externally dialable destination
DN for the agents)).  

We can likely go on and on with anecdotal scenarios, but I really don't want
to get into a rathole discussion on the nature of privacy (and calling line
id blocking, etc.)  but I am certainly open for further discussion if you
point us to some regulatory specifications documenting the need for
supporting something more.

Regards,
Mary.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Monday, January 13, 2003 2:31 AM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
'Peterson, Jon'
Cc: [email-masked]'
Subject: History information privacy requirements

Mary and others,

 

 

 

 
 
Regards,
 
John
 
John Elwell

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Jan 2003 18:12:30 +0000

Mary,
 
To pick up on a particular point, you wrote:
 
".... There are examples where the actual DN of a destination isn't
revealed, but that's all due to application specific logic and not the
protocols (e.g call centers internally route calls without providing an
externally dialable destination DN for the agents)...."
 
Applying this same principle to SIP, application logic at the proxy could
determine the retargeted to URI. There may be reasons for not disclosing
this URI to the caller. Obviously one way to achieve this is to omit history
information altogether. Then the caller will never discover the
retargeted-to URI unless the UAS sends it back, but RFC 3323 provides the
UAS with a way of preventing that. However, there may be good reason why the
proxy will wish to place history information in the request before sending
it on downstream, e.g., to prevent retrying targets that have already been
tried, to advise the callee where the call has come from. So there may be a
requirement to send history information downstream but prevent it going
upstream back to the caller. Either there has to be a protocol solution to
indicate this privacy requirement to downstream proxies and the UAS, or the
retargeting proxy has to be responsible for removing any history information
that might compromise the privacy requirement. Unfortunately the latter
works only for a proxy, not a redirect, but perhaps redirection is
inappropriate in this situation (since the redirection request could reach
the UAC).
 
So even if we say that we don't need protocol enhancements as such, the
section of the solution document that describes proxy behaviour should point
out the possible need to remove upstream history information.
 
I guess most of the additional privacy requirements I mentioned can be
solved by appropriate proxy behaviour without requiring any additional
protocol elements. But I had expected these requirements to be laid down in
the requirements document and text in the solutions document indicating what
action needs to be taken to fulfil these requirements.
 
Concerning regulatory requirements, these are not my primary concern. Even
if there is no regulatory requirement governing a certain aspect of privacy,
there may be business requirements, as in the example above where there is a
requirement not to reveal the identity of a call centre agent.
 
Regards,
 
John

John Elwell

 -----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 15 January 2003 23:55 PM
To: 'Elwell, John'; Mark Watson; 'Peterson, Jon'
Cc: [email-masked]'; [email-masked]'
Subject: RE: History information privacy requirements

John, 

<http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.ht
ml>  

Regards, 
Mary. 

-----Original Message----- 
From: Elwell, John [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, January 13, 2003 2:31 AM 
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
'Peterson, Jon' 
Cc: [email-masked]' 
Subject: History information privacy requirements 

Mary and others, 

  

  

  

  

  

Regards, 
  
John 
  
John Elwell 
e-mail: mailto:[email-masked] <mailto:[email-masked]>  <
mailto:[email-masked] <mailto:[email-masked]> >

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Jan 2003 14:40:23 -0600

Hi John,

I do understand your concerns and I think we agree that this is an
application issue.
I think what we need to do is to add some text in section 5 (and actually I
think this text should replace what's currently the last paragraph of that
section) highlighting that there may also be application specific reasons
for not including the Request History Information in responses, but that the
these reasons don't impose any additional requirements on the protocol.  I
think there is alot of overlap with the concerns you have raised and the
general optionality aspects that are primarily controlled by the application
and local policy as to whether the information is captured, and if it is
captured whether it is included in requests beyond that domain or in
responses, etc. As with the optionality, I think we've previously agreed
(and documented in the requirements) that the solution does need to provide
some guidelines as to the aspects which must be addressed by applications
making use of this capability.  I can add similar wording to section 5. 

As to what's needed in the solution draft to address this, section 2.3.3
does describe that whether the information is included in the response is
also based upon local policy, which should thus encompass these privacy
aspects.  

Mary.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 12:12 PM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
'Peterson, Jon'

Mary,

 

 
 
Regards,
 
John

John Elwell

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jan 2003 10:25:31 +0000

Mary,

In-line.

Regards,

John
> Sent: 16 January 2003 20:40

[JRE] Good. I look forward to that in the next draft.

> also based upon local policy, which should thus encompass 

[JRE] Yes, but there may also be cases where the proxy wishes to include
information in the request sent downstream but not in the response sent
upstream. It is not clear from the existing text that local policy could say
different things for the two directions. Also this may mean intercepting
History-info headers received in responses from downstream entities and
stripping out those that this proxy originally inserted if policy dictates
that they not be sent upstream.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 17 Jan 2003 12:07:51 -0000

John, All,

John suggests there may be a requirement for a proxy to 'strip out'
History-Info from a response as that response goes past. I think we should
be clear that this happens as a result of local policy (related to privacy)
*at the proxy doing the stripping*, and not policy somehow communicated from
elsewhere.

What we need to avoid is cases where a proxy knows there is some privacy
restriction associated with a piece of information, but it includes it in
the message anyway, and 'trusts' a later proxy to remove it. At least this
work should not assume such trust relationships.

I think it would be sufficient for the Request History work to require that
information which is known to be subject to a privacy requirement is just
not sent - and by 'sending' I include passing on received information when
you forward a request/response.

Other work (the generic privacy solution) can provide generic mechanisms for
sending information subject to privacy requirements around the network. Only
two ways to do this:
1) Encrypt it with a key known only to entities 'trusted' to have the
information
2) Send the message (securly) to an entity known to be able to provide the
required privacy protection (i.e. privacy service).

So, as far as Request History goes, do we need to say any more than 'local
policy at a proxy may identify privacy requirements associated with Request
History information. Request History information subject to privacy
requirements shall not be included in outgoing messages unless it is
protected as described in <general privacy mechanism>.'

...Mark

> Sent: 17 January 2003 10:26

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jan 2003 17:36:52 +0000

Mark,
 
Although I think we have agreement on the general principles, I am still
concerned that the text you propose does not explicitly mention removing
information from responses.
 
Regards,
 
John

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 17 January 2003 12:08
To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon'
Cc: [email-masked]'; [email-masked]'
Subject: RE: History information privacy requirements

John, All, 

...Mark 

> > From: Mary Barnes [ mailto:[email-masked]
<mailto:[email-masked]> ] 

> > < mailto:[email-masked] <mailto:[email-masked]> >  
> >

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 17 Jan 2003 17:43:12 -0000

Well, a response is an 'outgoing message' from the UAS and every proxy it
passes through. So the text below certainly includes removing information
from a response. This would occur if a proxy was aware of some privacy
requirement for the information that the original sender & other proxies in
the path was not aware of.

...Mark

> Sent: 17 January 2003 17:37
> To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary [NGC:B602:EXCH];
> 'Peterson, Jon'

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Jan 2003 08:36:33 +0000

Mark,
 
I understand that "outgoing messages" includes responses, but the text talks
only about "include" in outgoing messages, which might be interpreted as
insertion into the response as opposed to passing information on in the
response. Furthermore, we have to be careful when discussing passing
information on in the response, since the condition "unless it is protected
as described in <general privacy mechanism>" applies only to information
provided by the proxy concerned (i.e., sent downstream in the request and
received back again in the response). For this information, passing the
information on in the response towards the upstream entity should indeed be
subject to privacy protection and if not the information should be removed
from the response. Of course, the proxy concerned cannot be responsible for
privacy information inserted by other downstream entities and therefore such
information can be passed on unconditionally. I think the words you propose,
whilst "correct", do not adequately point out the implications.
 
Therefore perhaps the words could be extended as follows:
 
'Local policy at a proxy may identify privacy requirements associated with
Request History information. Request History information subject to privacy
requirements shall not be included in outgoing messages unless it is
protected as described in <general privacy mechanism>. Local policy can
apply different rules to the inclusion of Request History information in the
request and the inclusion of Request History information in the response. If
Request History information is subject to privacy requirements in the
response but not in the request, the proxy is responsible for removing from
any received response any Request History information that this proxy
inserted into the request.'

Regards,
 
John

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 17 January 2003 17:43
To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon'
Cc: [email-masked]'; [email-masked]'
Subject: RE: History information privacy requirements

...Mark 

> From: Mark Watson [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Elwell, John [ mailto:[email-masked]
<mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> > ] 
<mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> >
] 
> > > From: Elwell, John [ mailto:[email-masked]
<mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > < mailto:[email-masked] <mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> > >  
> > >