Re: [sipcore] Understanding Privacy: history invoked by UAS

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 10 November 2010 04:52 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F0E3A67FE for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 20:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level:
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOYZZdfG00jq for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 20:52:22 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D80FE3A67E2 for <sipcore@ietf.org>; Tue, 9 Nov 2010 20:52:21 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 23:52:47 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 23:52:47 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Shida Schubert <shida@ntt-at.com>
Date: Tue, 9 Nov 2010 23:52:43 -0500
Thread-Topic: [sipcore] Understanding Privacy: history invoked by UAS
Thread-Index: AcuAkx168p1bfSMAT9G6L6ZMOBxfCw==
Message-ID: <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA02357ADA69@MCHP058A.global-ad.net> <A78B9020-EB78-477E-8B2A-22F8F27B1032@ntt-at.com> <A444A0F8084434499206E78C106220CA023587F123@MCHP058A.global-ad.net> <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com>
In-Reply-To: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 04:52:23 -0000

Out of curiosity, will anything "break" if the anonymized H-I entries are simply removed?  I'm not suggesting we document doing that in the draft, just asking if any apps/use-cases/whatever will break if it happens.  Because my guess is some of us will just remove them, and I'd like to know if there's any real reason I shouldn't.

-hadriel

On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote:

> 
> I think RFC4244 was quite vague about how privacy is 
> requested and due to that, both privacy header outside 
> H-I header or part of hi-entry are used without any clear 
> distinction.
> 
> Thus for backward compatibility, I don't think we can 
> eliminate the use of Privacy:history, I think we can definitely 
> clarify the use of them by saying proxy SHOULD or MUST 
> use privacy=header and UAC uses Privacy:history. 
> 
> I do think we should clarify the procedure of how history-info 
> is anonymized, may be something along the line as follows.
> 
> 1. Setting privacy indication.
> 
> UAC sets privacy by setting privacy:header or privacy:history
> Proxy/UAS sets privacy by setting privacy=history in hi-entry
> 
> 2. Applying privacy to request.
> 
> Privacy service at the boundary of domain checks if privacy:header 
> or privacy:history exists.
> 
> If privacy:history or privacy:header exists then it anonymize all the 
> hi-entry from its responsible domain by changing the hi-target-to-uri 
> to URI with anonymous.invalid. 
> 
> If the hi-entry that is a target of anonymization and has privacy=history, 
> it will remove the privacy=history after anonymizing the hi-entry.
> 
> If the hi-entry is already anonymized (URI with anonymous.invalid) it 
> will leave the entry as is. 
> 
> After anonymizing all the hi-entry from its responsible domain it will 
> remove the priv-value of "history" from Privacy header (real header).
> 
> If there are no priv-value remaining in the Privacy header then it will 
> remove the Privacy header itself following the procedure in RFC3323.
> 
> If there is no priv-value of "history" or "header", privacy service 
> looks through hi-entries and see if there are URI from its domain 
> with privacy=history.
> 
> For each hi-entry with privacy=history, privacy service will anonymize 
> the hi-target-to-uri and remove the privacy=history after anonymizing 
> the hi-entry. 
> 
> 3. Privacy:none
> 
> With regards to privacy:none, it's tad tricky because 
> as Ian said, how it's honored depends on the regulation etc. 
> 
> Regards
>  Shida
> 
> On Nov 10, 2010, at 10:30 AM, Elwell, John wrote:
> 
>> In which case we don't need Privacy: history in the response, since it is only a partial solution?
>> 
>> John 
>> 
>>> -----Original Message-----
>>> From: Shida Schubert [mailto:shida@ntt-at.com] 
>>> Sent: 09 November 2010 06:24
>>> To: Elwell, John
>>> Cc: sipcore@ietf.org
>>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
>>> 
>>> 
>>> Hi John;
>>> 
>>> In practice, if C cares about its privacy, there should be 
>>> a priori arrangement with the service provider or 
>>> configuration in proxy to withhold its identity.
>>> 
>>> This will allow the proxy sending the 4xx which sets the hi-entry 
>>> to ensure privacy is applied by setting escaped privacy header 
>>> or Privacy:header. 
>>> 
>>> Regards
>>> Shida 
>>> 
>>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote:
>>> 
>>>> Suppose a request from A is targeted initially at B, this 
>>> is mapped to C, and then to registered contact D. The UAS (D) 
>>> puts Privacy: history in the response, and therefore prevents 
>>> A learning about C and D. Fine.
>>>> 
>>>> Now, supposing D is not registered at the time, i.e., there 
>>> is no registered contact for C. This results in a 4xx 
>>> response to A. How do we ensure that the identity of C is not 
>>> disclosed to A, in line with what is achieved when D is registered?
>>>> 
>>>> John
>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipcore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>> 
>>> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore