From acooper@cdt.org Fri Jul 1 06:11:59 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27311E8135 for ; Fri, 1 Jul 2011 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA8DrynUo24v for ; Fri, 1 Jul 2011 06:11:59 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0616C11E81C9 for ; Fri, 1 Jul 2011 06:11:49 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for privacydir@ietf.org; Fri, 1 Jul 2011 09:11:48 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 14:11:46 +0100 Message-Id: <52885BD5-4732-4072-B0E8-E892BA345A11@cdt.org> To: privacydir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [privacydir] Meeting at IETF 81 X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:11:59 -0000 One thing we're working on within the IAB's privacy program (see = http://www.iab.org/activities/programs/privacy-program/) is developing = guidance to help people review their own documents for privacy = considerations (see = http://tools.ietf.org/html/draft-morris-privacy-considerations-03). As = part of that effort, the IAB privacy program would like to schedule a = meeting during IETF 81 to go over the privacy reviews that have recently = been completed, both by privacy directorate folks and IAB members, and = to see if there are any general themes emerging that might be good = inputs to the guidance document. If you'll be in Quebec City and you'd like to participate in such a = meeting, please reply to me off-list. The prep should not take long -- = there are about six short reviews that have been done recently that we'd = like people to read and think about in advance. We are still working out = the exact timing for the meeting. Thanks, Alissa= From Hannes.Tschofenig@gmx.net Tue Jul 5 03:49:06 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9518521F8773 for ; Tue, 5 Jul 2011 03:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEMw+7E1CcEk for ; Tue, 5 Jul 2011 03:49:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A53C521F876E for ; Tue, 5 Jul 2011 03:49:05 -0700 (PDT) Received: (qmail invoked by alias); 05 Jul 2011 10:49:04 -0000 Received: from unknown (EHLO [10.255.132.24]) [192.100.123.77] by mail.gmx.net (mp023) with SMTP; 05 Jul 2011 12:49:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19sqw8sf5psC8RSApCyy2F6e7zW59zXqXJjQIrZmA pUv87b2GIMNtm2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Tue, 5 Jul 2011 13:48:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> To: privacydir@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [privacydir] Privacy Terminology: What are useful terms? X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 10:49:06 -0000 Hi all,=20 You may have seen that the privacy terminology document over time got = shorter and shorter as I removed content to make it more readable. Here = is the latest version:=20 http://tools.ietf.org/html/draft-hansen-privacy-terminology-02 It is still too long. Most IETF document authors are likely to use only = a few terms.=20 In a recent discussion in the IAB privacy program we were wondering what = are the terms we absolutely need to have. Here are the terms I think = could be useful for IETF document authors to know.=20 1) Anonymity 2) Unlinkability 3) Unobservability 4) Pseudonym/Pseudonymity Anonymity, unlinkability and pseudonymity are useful terms for many of = the IETF's authentication protocols. The sub-categories of sender = anonymity and relationship anonymity are more applicable to protocols = like onion routing proposals.=20 Unobservability shows up in the context of security protocols where = dummy traffic is used to pad exchanged data. Identity management is often touched in the work on architectures. While = many of the entities have their own unique terms with each proposal = there are some concepts that seem to be quite generic, such as = 'identity', and 'identifier'. It may be useful to capture this aspect as = well.=20 =46rom your experience, what other terminology is useful to have?=20 Ciao Hannes From nick.a.mathewson@gmail.com Fri Jul 8 11:40:05 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821DA21F8B9D for ; Fri, 8 Jul 2011 11:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIJ4s4qLgR9n for ; Fri, 8 Jul 2011 11:40:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8282F21F8B98 for ; Fri, 8 Jul 2011 11:40:01 -0700 (PDT) Received: by wyj26 with SMTP id 26so1738693wyj.31 for ; Fri, 08 Jul 2011 11:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xhy6jaFJdY1fAMvxa/6oB5CyqAKiZLMKTNC9twnDoFk=; b=Uf/zC91bmbDif6DfvEYXrYFR3n+eKULnViSUqGOQwlwFihf/PPnjjDJ7EJL830q13d Klf799NiPsOSFl0knNdXmRv0o7q1/ojkLB5dP+OW7gr3fu50tgYXkDmy7yBWRN0RLKUD 6FwsNmLs1Hp12xKHRvzfSu+BjXAvkDkzhGiHM= MIME-Version: 1.0 Received: by 10.216.122.10 with SMTP id s10mr936017weh.34.1310150400586; Fri, 08 Jul 2011 11:40:00 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.216.156.1 with HTTP; Fri, 8 Jul 2011 11:40:00 -0700 (PDT) In-Reply-To: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> References: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> Date: Fri, 8 Jul 2011 14:40:00 -0400 X-Google-Sender-Auth: fDar2qr19ZoWF_p2k5t4oteJeiU Message-ID: From: Nick Mathewson To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: privacydir@ietf.org Subject: Re: [privacydir] Privacy Terminology: What are useful terms? X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:44:19 -0000 Hello, Hannes! On Tue, Jul 5, 2011 at 6:48 AM, Hannes Tschofenig wrote: [...] > From your experience, what other terminology is useful to have? I'm going to answer from the perspective of my own work on anonymity and privacy with Tor, recognizing that not everybody's needs are the same as our own. We use "Linkability" and subject "Anonymity" in approximately the same ways that you do. (We mostly use the "attacker cannot sufficiently distinguish" formulation, not the "Attacker cannot distinguish" formulation. In practice, the attacker's inability to link X and Y with certainty is mostly useless if the attacker can nevertheless link X and Y with strong probability. When we're being precise, we use these terms to mean the degree of the attacker's uncertainty.) We also use "Anonymity" to refer to unlinkability between an IOI and its origin. We use a stronger definition of "pseudonym": we only consider X to be a pseudonym when it is an identifier that is unlinkable to its subject by an attacker of interest. (Thus, by our lights, "Batman" is a pseudonym since Batman's enemies do not know he is Bruce Wayne, but "Ad-Rock" is not a pseudonym since Beastie Boys fans worldwide know that he is really Adam Horovitz.) We don't use "undetectability" or "unobservability". Some additional terminology in common use that we use: * Instead of "sender" and "receiver" anonymity, we usually speak of "initiator" and "responder" anonymity. (In systems that provide bidirectional communication, most everybody "sends" and "receives".) * We talk about one kind of or item being "distinguishable" from another. (For example, a protocol is "indistinguishable" from HTTPS to the extent that an attacker can't tell instances of that protocol from regular HTTPS connections.) * We use "profiling" to mean learning information about an anonymous subject's activities without necessarily linking them to any specific transaction. For example, if an attacker concludes that I play WoW, read reddit.com, and upload videos, then my activities have been profiled, even if the attacker is unable to identity which connections or accounts are mine. Some additional terminology that I think might be idiosyncratic: * We use "linkable session" to refer to a set of actions by a subject that the system makes no effort to render unlinkable from one another. * We refer as a "linking identifier" to any parameter P that an attacker can observe about an IOI and use to link it to similar IOIs that have similar values for P. For example, the window size header transmitted in a typical HTTP request is a linking identifier. Many thanks for all your work here! yrs, -- Nick From acooper@cdt.org Mon Jul 11 03:14:37 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7021F8B0F for ; Mon, 11 Jul 2011 03:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e14GNhQW+KRw for ; Mon, 11 Jul 2011 03:14:37 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1B721F8ACC for ; Mon, 11 Jul 2011 03:14:37 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for privacydir@ietf.org; Mon, 11 Jul 2011 06:14:21 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alissa Cooper In-Reply-To: <52885BD5-4732-4072-B0E8-E892BA345A11@cdt.org> Date: Mon, 11 Jul 2011 11:14:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52885BD5-4732-4072-B0E8-E892BA345A11@cdt.org> To: privacydir@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [privacydir] Meeting at IETF 81 X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:14:38 -0000 Just a reminder to let me know if you're interested in participating in = this meeting (if you haven't already responded). It looks like this will = be a dinner meeting at the Hilton on Monday, July 25 after the plenary. Thanks, Alissa On Jul 1, 2011, at 2:11 PM, Alissa Cooper wrote: > One thing we're working on within the IAB's privacy program (see = http://www.iab.org/activities/programs/privacy-program/) is developing = guidance to help people review their own documents for privacy = considerations (see = http://tools.ietf.org/html/draft-morris-privacy-considerations-03). As = part of that effort, the IAB privacy program would like to schedule a = meeting during IETF 81 to go over the privacy reviews that have recently = been completed, both by privacy directorate folks and IAB members, and = to see if there are any general themes emerging that might be good = inputs to the guidance document. >=20 > If you'll be in Quebec City and you'd like to participate in such a = meeting, please reply to me off-list. The prep should not take long -- = there are about six short reviews that have been done recently that we'd = like people to read and think about in advance. We are still working out = the exact timing for the meeting. >=20 > Thanks, > Alissa > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir >=20 From hannes.tschofenig@gmx.net Wed Jul 13 02:40:03 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE11321F8BE4 for ; Wed, 13 Jul 2011 02:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMOjmXgWTZQj for ; Wed, 13 Jul 2011 02:39:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5F9C721F8BE5 for ; Wed, 13 Jul 2011 02:39:59 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2011 09:39:58 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp070) with SMTP; 13 Jul 2011 11:39:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19XMTwEJWtXOXZfOcsMOBKEeodBD65bwz6vrKYg6d 6RF3DxNfsX5kUO Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 13 Jul 2011 12:39:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> To: Nick Mathewson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: privacydir@ietf.org Subject: Re: [privacydir] Privacy Terminology: What are useful terms? X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:40:03 -0000 Hi Nick,=20 thank you for your feedback. I like the examples you provided.=20 It may be useful to add examples to the draft as well to make the text = more interesting to read.=20 On Jul 8, 2011, at 9:40 PM, Nick Mathewson wrote: > Hello, Hannes! >=20 > On Tue, Jul 5, 2011 at 6:48 AM, Hannes Tschofenig > wrote: > [...] >> =46rom your experience, what other terminology is useful to have? >=20 > I'm going to answer from the perspective of my own work on anonymity > and privacy with Tor, recognizing that not everybody's needs are the > same as our own. >=20 > We use "Linkability" and subject "Anonymity" in approximately the same > ways that you do. (We mostly use the "attacker cannot sufficiently > distinguish" formulation, not the "Attacker cannot distinguish" > formulation. In practice, the attacker's inability to link X and Y > with certainty is mostly useless if the attacker can nevertheless link > X and Y with strong probability. When we're being precise, we use > these terms to mean the degree of the attacker's uncertainty.) >=20 > We also use "Anonymity" to refer to unlinkability between an IOI and = its origin. >=20 > We use a stronger definition of "pseudonym": we only consider X to be > a pseudonym when it is an identifier that is unlinkable to its subject > by an attacker of interest. (Thus, by our lights, "Batman" is a > pseudonym since Batman's enemies do not know he is Bruce Wayne, but > "Ad-Rock" is not a pseudonym since Beastie Boys fans worldwide know > that he is really Adam Horovitz.) >=20 Ok.=20 > We don't use "undetectability" or "unobservability". >=20 >=20 I have seen the unobservability term being used in security protocols = when the traffic characteristics shall be hidden (via padding).=20 Aren't you doing something similar in Tor? If you do, how do you call = that property?=20 > Some additional terminology in common use that we use: >=20 > * Instead of "sender" and "receiver" anonymity, we usually speak of > "initiator" and "responder" anonymity. (In systems that provide > bidirectional communication, most everybody "sends" and "receives".) >=20 Such a change makes sense to me. We actually use these terms in various = IETF protocols as well.=20 IKEv2, for example, talks about initiator and responder for exactly the = same reason.=20 > * We talk about one kind of or item being "distinguishable" from > another. (For example, a protocol is "indistinguishable" from HTTPS > to the extent that an attacker can't tell instances of that protocol > from regular HTTPS connections.) Could be useful.=20 >=20 > * We use "profiling" to mean learning information about an anonymous > subject's activities without necessarily linking them to any specific > transaction. For example, if an attacker concludes that I play WoW, > read reddit.com, and upload videos, then my activities have been > profiled, even if the attacker is unable to identity which connections > or accounts are mine. Profiling may be a useful term to add.=20 Btw, I searched through the Tor documents and couldn't really find a = definition.=20 >=20 > Some additional terminology that I think might be idiosyncratic: >=20 > * We use "linkable session" to refer to a set of actions by a > subject that the system makes no effort to render unlinkable from one > another. Could you provide an example?=20 >=20 > * We refer as a "linking identifier" to any parameter P that an > attacker can observe about an IOI and use to link it to similar IOIs > that have similar values for P. For example, the window size header > transmitted in a typical HTTP request is a linking identifier. >=20 I wasn't aware that the window size header has such a characteristic.=20 Is there a paper you could recommend to learn more about this aspect?=20 >=20 > Many thanks for all your work here! >=20 Thanks for the review.=20 Ciao Hannes > yrs, > --=20 > Nick From nick.a.mathewson@gmail.com Fri Jul 15 21:14:56 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7821F8744 for ; Fri, 15 Jul 2011 21:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQpaeEwv9UZh for ; Fri, 15 Jul 2011 21:14:55 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9163421F86DF for ; Fri, 15 Jul 2011 21:14:55 -0700 (PDT) Received: by wwe5 with SMTP id 5so1231013wwe.13 for ; Fri, 15 Jul 2011 21:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BNdxWBuGVYlKJc39Hg5LUgiM0LrQYo++HMoVs7bVoIA=; b=kd+K05UCsHWNgE2rJXg95Q7V5cm57PnhlQ4EsGNFb2sUMmV/BmaGAlVLlgx7q694FZ g97r/U8hlFKKe/TIbG14JbZpZYG4jhAh/5MjrcdUfKevoHcFlIa9KwOCG+JLTAzR8Xxr Un57lFA+oBeRzTMfqvLutAuiljkATLPcGWi5c= MIME-Version: 1.0 Received: by 10.216.205.160 with SMTP id j32mr3594522weo.36.1310789694367; Fri, 15 Jul 2011 21:14:54 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.216.46.66 with HTTP; Fri, 15 Jul 2011 21:14:54 -0700 (PDT) In-Reply-To: References: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> Date: Sat, 16 Jul 2011 00:14:54 -0400 X-Google-Sender-Auth: jlynjmkiSouwe7NvUvSN_T0EwW0 Message-ID: From: Nick Mathewson To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: privacydir@ietf.org Subject: Re: [privacydir] Privacy Terminology: What are useful terms? X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 04:14:56 -0000 On Wed, Jul 13, 2011 at 5:39 AM, Hannes Tschofenig wrote: >> We don't use "undetectability" or "unobservability". >> >> > I have seen the unobservability term being used in security protocols whe= n the traffic characteristics shall be hidden (via padding). > Aren't you doing something similar in Tor? If you do, how do you call tha= t property? Well, we don't actually do enough padding right now to make many interesting characteristics unobservable. When we talk about padding, we usually talk not in terms of making the real traffic volume unobservable so much as we talk about making the padded view of a traffic stream unlinkable to an unpadded view. When we're talking in general about a particular unobservable property, we tend to use the active voice. Rather than say (for example) that stream open and close events are unobservable by an attacker watching the client, we tend to say that the attacker can't tell when streams open and close. (This is my sense from skimming and grepping our recent design documentation; it may be that I'm a bit off. Also, again, I'm not suggesting that our practice is better than the proposed terminology--just that it seems to be what we're doing.) [...] >> =A0 * We talk about one kind of or item being "distinguishable" from >> another. =A0(For example, a protocol is "indistinguishable" from HTTPS >> to the extent that an attacker can't tell instances of that protocol >> from regular HTTPS connections.) > > Could be useful. [...] >> =A0* We use "profiling" to mean learning information about an anonymous >> subject's activities without necessarily linking them to any specific >> transaction. =A0For example, if an attacker concludes that I play WoW, >> read reddit.com, and upload videos, then my activities have been >> profiled, even if the attacker is unable to identity which connections >> or accounts are mine. > > Profiling may be a useful term to add. > Btw, I searched through the Tor documents and couldn't really find a defi= nition. I think the closest you'd find might be in a discussion of guard nodes. But I don't think we ever came up with a good formal definition. >> Some additional terminology that I think might be idiosyncratic: >> >> =A0 * We use "linkable session" to refer to a set of actions by a >> subject that the system makes no effort to render unlinkable from one >> another. > > Could you provide an example? Sure. Take a session on a website. The user's browser might request resources from a number of different hosts, and might do so not only for one but for several pages. Nonetheless, it might make sense to treat all the TCP connections as part of a single "session", since each is already linked to all the rest semantically. For a more trivial example, suppose a user is logging in to a service pseudonymously. Given this behavior, there's no point to try to make different logins to the same pseudonymous account unlinkable by the service: the service can already link them through their use of the same pseudonym. >> =A0 * We refer as a "linking identifier" to any parameter P that an >> attacker can observe about an IOI and use to link it to similar IOIs >> that have similar values for P. =A0For example, the window size header >> transmitted in a typical HTTP request is a linking identifier. >> > I wasn't aware that the window size header has such a characteristic. > Is there a paper you could recommend to learn more about this aspect? I'd check out the findings from the EFF panopticlick project for recent results in identifying web browsers by header. For older results, I'll need to look around a bit. Window size alone isn't enough to split off traffic by users (since people resize windows) and isn't enough to isolate users (since lots of people can share a single window size), but it helps plenty with statistical linking. cheers, --=20 Nick From acooper@cdt.org Mon Jul 18 22:22:22 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5A21F85F6 for ; Mon, 18 Jul 2011 22:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj47sxCKYlA5 for ; Mon, 18 Jul 2011 22:22:18 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6F21F85DD for ; Mon, 18 Jul 2011 22:22:14 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 19 Jul 2011 01:22:09 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 06:22:07 +0100 Message-Id: <973CDAB6-BD51-4503-BDCB-D9FFDAA16E71@cdt.org> To: privacydir@ietf.org, privacy-program@iab.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: IAB IAB Subject: [privacydir] Privacy directorate/IAB privacy program meeting at IETF 81 X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 05:22:22 -0000 Here are the details for the privacy directorate/privacy program meeting = at IETF 81: Date: Monday, July 25, 2011 Time: 8:45pm to 10:15pm Location: Hilton Quebec, meeting room 304 A (the IAB room) Meeting materials: = http://www.iab.org/activities/programs/privacy-program/privacy-reviews/ Dinner will not be available, please eat beforehand The privacy reviews linked at the above page were written recently for a = variety of purposes: the EAP and IPv6 ones try to review the history of = privacy thinking as the protocols developed, the SAVI and IPFIX ones = were done as privacy directorate reviews, the presence and AAA ones are = included as examples in draft-morris-privacy-considerations-03, and the = ABFAB and mobility ones analyze architectures in development. We'll kick = off the meeting with these questions: -- Are there issues or lessons learned that appear repeatedly in these = reviews? What can we generalize about those? -- Are there any general criteria that are emerging to help protocol = designers review their documents for privacy considerations? What = questions are reviewers asking themselves? What questions should they be = asking themselves? -- Is there any sort of classification of threats that can be drawn from = these reviews? Which threats are or are not discussed? Let me know if you have questions or suggestions prior to IETF 81. Best, Alissa= From stephen.farrell@cs.tcd.ie Tue Jul 19 01:29:58 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC221F8797 for ; Tue, 19 Jul 2011 01:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.402 X-Spam-Level: X-Spam-Status: No, score=-104.402 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYT9Dgm21-yJ for ; Tue, 19 Jul 2011 01:29:54 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E19B821F850F for ; Tue, 19 Jul 2011 01:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 31CB21543F9; Tue, 19 Jul 2011 09:29:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1311064168; bh=9fP4Z vCiZY/63kfdYy7Lp1ZQCJEDq+4GIC4DCrGBdE4=; b=ydQwJKw7SFmWX+VcVzLWk 6EsQpKGZnuCrKFYtFch86DiHgn45KUYg8CRSiRjsTpubNuvk2isJK+RcY89fspnu m5fgGYbgEbhEq7HqEH+TC6Q4qa/At5aZrCw4pzmfACsd6tSdR3TP63/zhb9VEQYT cwlirXjqNwDso4wHo1w8QF/rTlp1bfCWBDdS6rB0hsT1JiXLQHEv8mwjjk3Moq+f 4dB81hcLlrXlQ+cZTv0Br5fou48IMcaEd2msMaaoRHdbz8h18sdxzSxcuaYLXB4W YDVz+wxAssa2wBveBcQSt6wcMFAq6i/VjYhcjmlibdyWWZIuQovgYQj6b+3yYtcR A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id lNPMyytkVIM4; Tue, 19 Jul 2011 09:29:28 +0100 (IST) Received: from [10.53.87.234] (unknown [62.40.32.24]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CA166171BF9; Tue, 19 Jul 2011 09:29:27 +0100 (IST) References: <973CDAB6-BD51-4503-BDCB-D9FFDAA16E71@cdt.org> In-Reply-To: <973CDAB6-BD51-4503-BDCB-D9FFDAA16E71@cdt.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <96767D9F-E8A0-446F-A364-D3A6EFF951F2@cs.tcd.ie> X-Mailer: iPhone Mail (8J2) From: Stephen Farrell Date: Tue, 19 Jul 2011 09:29:21 +0100 To: Alissa Cooper Cc: "privacydir@ietf.org" , "privacy-program@iab.org" , IAB IAB Subject: Re: [privacydir] Privacy directorate/IAB privacy program meeting at IETF 81 X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 08:29:58 -0000 As a SEC AD I've one further issue, to go at the end probably, but practical= ly an important one. It's put in it's proper place below:-) S On 19 Jul 2011, at 06:22, Alissa Cooper wrote: > Here are the details for the privacy directorate/privacy program meeting a= t IETF 81: >=20 > Date: Monday, July 25, 2011 > Time: 8:45pm to 10:15pm > Location: Hilton Quebec, meeting room 304 A (the IAB room) > Meeting materials: http://www.iab.org/activities/programs/privacy-program/= privacy-reviews/ > Dinner will not be available, please eat beforehand >=20 > The privacy reviews linked at the above page were written recently for a v= ariety of purposes: the EAP and IPv6 ones try to review the history of priva= cy thinking as the protocols developed, the SAVI and IPFIX ones were done as= privacy directorate reviews, the presence and AAA ones are included as exam= ples in draft-morris-privacy-considerations-03, and the ABFAB and mobility o= nes analyze architectures in development. We'll kick off the meeting with th= ese questions: >=20 > -- Are there issues or lessons learned that appear repeatedly in these rev= iews? What can we generalize about those? >=20 > -- Are there any general criteria that are emerging to help protocol desig= ners review their documents for privacy considerations? What questions are r= eviewers asking themselves? What questions should they be asking themselves?= >=20 > -- Is there any sort of classification of threats that can be drawn from t= hese reviews? Which threats are or are not discussed? - How do we get reviews done (at least a few days, better a week) before the= relevant IESG telechat so that the review has impact and isn't wasted effor= t. >=20 > Let me know if you have questions or suggestions prior to IETF 81. >=20 > Best, > Alissa > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir From hannes.tschofenig@gmx.net Sat Jul 23 12:52:48 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E1721F86DC for ; Sat, 23 Jul 2011 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgj-tpuM6Qrz for ; Sat, 23 Jul 2011 12:52:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 53EC121F8565 for ; Sat, 23 Jul 2011 12:52:46 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2011 19:52:44 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp061) with SMTP; 23 Jul 2011 21:52:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xXmUm2zgxbqjcfi24HherPZyivy7mO40anBblR/ Hhox3FfmmmAjiB From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Jul 2011 15:52:42 -0400 Message-Id: <8A650AFE-7D0F-4EDB-84CD-C462764B570A@gmx.net> To: privacydir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [privacydir] Slides about "Privacy Considerations for Internet Protocols" X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 19:52:48 -0000 Hi all,=20 I was invited by Ann Cavoukian and by Tara Whalen to speak about the = privacy consideration document to Ontario/Canadian privacy = commissioners. To present the ongoing work in a more structured way I = created a slide set and I wanted to share it with you. =20 The slides start with the way on how we do security in the IETF and = whether we can learn something from that experience. Then, I describe = some limitations the IETF standardization work has to deal with. I = subsequently deal with available privacy engineering guidelines and = briefly touch on the recommendations in = draft-morris-privacy-considerations. Since we do need more input on = these guidelines I highlighted two example case studies we had been = looking into, IPv6 and network access authentication. =20 Here are the slides:=20 http://www.tschofenig.priv.at/svn/canada-privacy/Privacy.ppt Ciao Hannes From acooper@cdt.org Sun Jul 24 07:22:02 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A851F21F8569 for ; Sun, 24 Jul 2011 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1Adn6CckOjB for ; Sun, 24 Jul 2011 07:22:00 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8021F856A for ; Sun, 24 Jul 2011 07:21:59 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sun, 24 Jul 2011 10:21:36 -0400 From: Alissa Cooper Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-7-350129897 Date: Sun, 24 Jul 2011 10:21:35 -0400 References: <973CDAB6-BD51-4503-BDCB-D9FFDAA16E71@cdt.org> To: privacy-program@iab.org, privacydir@ietf.org Message-Id: <6D837D4D-02D4-4EA9-AD82-0DCEB636973C@cdt.org> X-Mailer: Apple Mail (2.1084) Cc: Yves Lafon , Marc Linsner , Klaas Wierenga , Eliot Lear Subject: [privacydir] Privacy meeting -- room change and documents X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 14:22:02 -0000 --Apple-Mail-7-350129897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Monday night's privacy meeting has been moved to room 301A. A reminder = of the details: Date: Monday, July 25, 2011 Time: 8:45pm to 10:15pm Location: Hilton Quebec, meeting room 301 A Meeting materials: = http://www.iab.org/activities/programs/privacy-program/privacy-reviews/ Dinner will not be available, please eat beforehand Some of the links on the site above don't seem to be working at the = moment (there is some work being done on the IAB site), so I've attached = those files here. Alissa --Apple-Mail-7-350129897 Content-Disposition: attachment; filename="AAA privacy review.txt" Content-Type: text/plain; name="AAA privacy review.txt" Content-Transfer-Encoding: 7bit [from draft-morris-privacy-considerations-03] 5.2. AAA for Network Access On a high-level, AAA for network access uses the communication model shown in Figure 3. When an end host requests access to the network it has to interact with a Network Access Server (NAS) using some front-end protocol (often at the link layer, such as IEEE 802.1X). When asked by the NAS, the end host presents a Network Access Identifier (NAI), an email alike identifier that consists of a username and a domain part. This NAI is then used to discover the AAA server authorized for the users' domain and an initial access request is forwarded to it. To deal with various security, accounting and fraud prevention aspects an end-to-end authentication procedure, run between the end host (the peer) and a separate component within the AAA server (the server) is executed using the Extensible Authentication Protocol (EAP). After a successful authentication protocol exchange the user may get authorized to access the network and keying material is provided to the NAS to enable link layer security over the air interface. From a privacy point of view, the entities participating in this eco- system are the user, an end host, the NAS, a range of different intermediaries, and the AAA server. The user will most likely have some form of contractual relationship with the entity operating the AAA server since credential provisioning had to happen someone but, in certain deployments like coffee shops, this is not guaranteed. In many deployment during this initial registration process the subscriber is provided with credentials after showing some form of identification information (e.g. a passport) and consequently the NAI together with credentials can be used to linked to a specific subscriber, often a single person. The username part of the NAI is data provided by the end host provides during network access authentication that intermediaries do not need to fulfill their role in AAA message routing. Hiding the user's identity is, as discussed in RFC 4282 [RFC4282], possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. Such EAP methods have been designed and requirements for offering such functionality have have become recommended design criteria, see [RFC4017]. More than just identity information is exchanged during the network access authentication is exchanged. The NAS provides information about the user's point of attachment towards the AAA server and the AAA server in response provides data related to the authorization decision back. While the need to exchange data is motivated by the service usage itself there are still a number of questions that could be asked, such as o What mechanisms can be utilized to offer users ways to authorize sharing of information (considering that the ability for protocol interaction is limited without sucessful network access connectivity)? o What are the best current practices for a privacy-sensitive operation of intermediaries? Since end hosts are not interacting with intermediaries explicitly and users have no relationship with those who operate them it is quite likely their practices are less widely known. o Are there alternative approaches to trust establishment between the NAS and the AAA server so that the involvement of intermediaries can be limited or avoided? +--------------+ | AAA Server | +-^----------^-+ * EAP | RADIUS/ * | Diameter --v----------v-- /// \\\ // AAA Proxies, \\ *** | Relays, and | back- | Redirect Agents | end \\ // *** \\\ /// --^----------^-- * EAP | RADIUS/ * | Diameter +----------+ Data +-v----------v-- + | |<---------------->| | | End Host | EAP/EAP Method | Network Access | | |<****************>| Server | +----------+ +--------------- + *** front-end *** Legend: <****>: End-to-end exchange <---->: Hop-by-hop exchange Figure 3: Network Access Authentication Architecture --Apple-Mail-7-350129897 Content-Disposition: attachment; filename="ABFAB privacy review.txt" Content-Type: text/plain; name="ABFAB privacy review.txt" Content-Transfer-Encoding: 7bit [from draft-lear-abfab-arch-02] 5. Privacy Considerations Sharing identity information raises privacy violations and as described throughout this document an existing architecture is re- used for a different usage environment. As such, a discussion about the privacy properties has to take these pre-conditions into consideration. We use the approach suggested in [I-D.morris-privacy-considerations] to shed light into what data is collected and used by which entity, what the relationship between these entities and the end user is, what data about the user is likely needed to be collected, and what the identification level of the data is. 5.1. What entities collect and use data? Figure 2 shows the architecture with the involved entities. Message exchanges are exchanged between the client application, via the relying part to the AAA server. There will likely be intermediaries between the relying party and the AAA server, labeled generically as "federation". In order for the relying party to route messages to the AAA server it is necessary for the client application to provide enough information to enable the identification of the AAA server's domain. While often the username is attached to the domain (in the form of a Network Access Identity (NAI) this is not necessary for the actual protocol operation. The EAP server component within the AAA server needs to authenticate the user and therefore needs to execute the respective authentication protocol. Once the authentication exchange is complete authorization information needs to be conveyed to the relying party to grant the user the necessary application rights. Information about resource consumption may be delivered as part of the accounting exchange during the lifetime of the granted application session. The authentication exchange may reveal an identifier that can be linked to a user. Additionally, a sequence of authentication protocol exchanges may be linked together. Depending on the chosen authentication protocol information at varying degrees may be revealed to all parties along the communication path. This authorization information exchange may disclose identity information about the user. While accounting information is created by the relying party it is likely to needed by intermediaries in the federation for financial settlement purposes and will be stored for billing, fraud detection, statistical purposes, and for service improvement by the AAA server operator. 5.2. Relationship between User's and other Entities The AAA server is a first-party site the user typically has a relationship with. This relationship will be created at the time when the security credentials are exchange and provisioned. The relying party and potential intermediares in the federation are typically operate under the contract of the first-party site. The user typically does not know about the intermediaries in the federation nor does he have any relationship with them. The protocol interaction triggered by the client application happens with the relying party at the time of application access. The relying party does not have a direct contractual relationship with the user but depending on the application the interaction may expose the brand of the application running by the relying party to the end user via some user interface. 5.3. What Data about the User is likely Needed to be Collected? The data that is likely going to be collected as part of a protocol exchange with application access at the relying party is accounting information and authorization information. This information is likely to be kept beyond the terminated application usage for trouble shooting, statistical purposes, etc. There is also like to be additional data collected to to improve application service usage by the relying party that is not conveyed to the AAA server as part of the accounting stream. 5.4. What is the Identification Level of the Data? With regard to identification there are several protocol layers that need to be considered separately. First, there is the EAP method exchange, which as an authentication and key exchange protocol has properties related to identification and protocol linkage. Second, there is identification at the EAP layer for routing of messages. Then, in the exchange between the client application and the relying party the identification depends on the underlying application layer protocol the EAP/GSS-API exchange is tunneled over. Finally, there is the backend exchange via the AAA infrastructure, which involves a range of RADIUS and Diameter extensions and yet to be defined extensions, such as encoding authorization information inside SAML assertions. Since this document does not attempt to define any of these exchanges but rather re-uses existing mechanisms the level of identification heavily depends on the selected mechanisms. The following two examples aim to illustrate the amount of existing work with respect to decrease exposure of personal data. 1. When designing EAP methods a number of different requirements may need to get considered; some of them are conflicting. RFC 4017 [RFC4017], for example, tried to list requirements for EAP methods utilized for network access over Wireless LANs. It also recommends the end-user identity hiding requirement, which is privacy-relevant. Some EAP methods, such as EAP-IKEv2 [RFC5106], also fulfill this requirement. 2. EAP, as the layer encapsulating EAP method specific information, needs identity information to allow routing requests towards the user's home AAA server. This information is carried within the Network Access Identifier (NAI) and the username part of the NAI (as supported by RFC 4282 [RFC4282]) can be obfuscated. 5.5. Privacy Challenges While a lot of standarization work was done to avoid leakage of identity information to intermediaries (such as eavesdroppers on the communication path between the client application and the relying party) in the area of authentication and key exchange protocols. However, from current deployments the weak aspects with respect to security are: 1. Today business contracts are used to create federations between identity providers and relying parties. These contracts are not only financial agreements but they also define the rules about what information is exchanged between the AAA server and the relying party and the potential involvement of AAA proxies and brokers as intermediaries. While these contracts are openly available for university federations they are not public in case of commercial deployments. Quite naturally, there is a lack of transparency for external parties. 2. In today's deployments the ability for users to determine the amount of information exchanged with other parties over time, as well as the possibility to control the amount of information exposed via an explict consent is limited. This is partially due the nature of application capabilities at the time of network access authentication. However, with the envisioned extension of the usage, as described in this document, it is desirable to offer these capabilities. --Apple-Mail-7-350129897 Content-Disposition: attachment; filename="EAP privacy review.txt" Content-Type: text/plain; name="EAP privacy review.txt" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba =20 Subject: [Privacy-program] EAP privacy (and privacy issues arising from = SAVI).=20 Date: June 14, 2011 7:23:40 PM GMT+01:00=20 To: privacy-program@iab.org The privacy issues discussed in this review overlap with a number of = issues encountered in EAP identity privacy. In an EAP network authentication, there are a number of relevant = identifiers: 1. The MAC address of the user. 2. The IP address of the user, typically assigned after the EAP exchange has completed. 3. The EAP network access identifier (NAI) used in the EAP-Response/Identity exchange. The NAI is defined in RFC 4282. 4. The EAP NAI used within the (potentially = protected) EAP method exchange 5. Network Access Server (NAS) identifiers carried = by the AAA protocol. There include: NAS-Identifier, NAS-IPv4-Address (RFC = 2865), NAS-IPv6-Address (RFC 3162) and Called-Station-Id (RFC 2865, 3580). In addition to identifying the NAS, these attributes can be used to infer = the user's location. 6. User identifiers carried by the AAA protocol. These include the following attributes: User-Name (RFC 2865), = Calling-Station-Id (RFC 3580) EAP-Message attribute (RFC 3579), Chargeable User Identity = (RFC 4372). Initially, the EAP privacy discussion focused on the threat posed by an attacker snooping on an EAP exchange to obtain the user identity = included in the EAP-Response/Identity exchange. This was considered largely a = security threat in that knowledge of the user name could enable an attacker to = more easily mount an attack to recover the password of that user. Other = privacy threats such as the exposure of data from the AAA exchange (which in the = case of RADIUS, occurs in the clear) were not included in the discussion, nor = was a comprehensive threat model developed. The EAP Identity exchange occurs in the clear since it is used to route = the EAP packets to the AAA server prior to initiation of the EAP exchange = which derives keys which can subsequently be used to encrypt the link. The EAP methods defined in RFC 3748 did not provide for EAP-method specific = identities nor did they derive keys, so the EAP-Response/Identity was the only = identity available to those methods. While EAP-TLS (RFC 2716) did derive keys, it = did not provide for encryption of the TLS client certificate, and thus an = attacker could obtain the user identity from the client certificate. RFC 5716 subsequently enabled encryption of the client certificate exchange. Since the EAP-Response/Identity is used to route the EAP exchange to the appropriate AAA server cannot be encrypted, it is not possible to = provide complete anonymity -- unless the exchange utilizes a local AAA server, a domain name must be provided. Methods such as EAP-TTLSv0 (RFC 5281) = enabled an "anonymous NAI" of the form "anonymous@example.com" or "anonymous" to be = sent within the EAP-Response/Identity. The EAP server would then initiate an = EAP method chosen by the administrator, in which the method-specific = identity would be provided via an encrypted tunnel from the user to the EAP = server. In such an exchange, an attacker snooping on the EAP exchange, while = still potentially learning the user domain, would not know the user name, but = the administrator of the AAA server would have all the information that = would normally be obtained from the NAS and user (e.g. user as well as NAS information) . Note that in this model, not only would an attacker snooping the user = not learn the user name, but the network operator would also not learn it. = This created a potential issue for billing, because the accounting records submitted by the network operator would no longer identify the user-name initiating the session. Some existing solutions were considered. = Permanent identifiers (such as Calling-Station-Id, which could contain the MAC = address or originating telephone number) could still be included in accounting records, so that the network operator would still have some ability to = track the user. While the AAA server could potentially pass the Class or = User-Name attributes in an Access-Accept for inclusion in the accounting record = this would provide user identity to the network operator. The Chargeable User Identity (RFC 4372) developed to provide information in the accounting = record so that the AAA server could correlate the network operator-provided accounting info with its own records. Given the presence of permanent identifiers in user-NAS exchanges (e.g. = MAC address) as well as in AAA exchanges (e.g. Calling-Station-Id), in = addition to NAS identifiers akin to location data, the discussion of EAP privacy was = not the last word on the issue. Subsequently in IEEE 802.11 there was = discussion of issues such as "temporary" MAC addresses and MAC address spoofing. = Note that in IEEE 801.11i, there is no protection against MAC address = spoofing, merely binding of keys to MAC addresses. Thus an attacker can spoof a = MAC address and potentially disrupt network access for another user. Subsequently IEEE 802.1ar developed a mechanism to allow proof of MAC = address ownership via a certificate and EAP-TLS exchange, and such an identity certificate approach (with EAP-TLS authentication) was also used in = WiMAX on network entry. The carriage of location info in clear text also became an issue of = concern when it became understood that an attacker snooping on RADIUS = authentication or accounting packets could obtain user location in realtime, given the wiremap data to convert NAS identifiers to location. This lead to = proposals for encryption of AAA traffic (e.g. Diameter over TLS/IPsec, RADIUS over = IPsec as defined in RFC 3579, RADIUS over DTLS, RADIUS over TLS, etc.). Of = course, merely encrypting the traffic is not sufficient if the data itself were = not protected; therefore interest also developed in storage of log data on encrypted file systems. Note that this data is often kept for = substantial periods (e.g. 7 years) due to financial and other requirements. Lessons from EAP privacy 1. At no point during the EAP privacy debate was a privacy threat model developed, describing the entire system (EAP, AAA, link layer) and the = threats from various entities (e.g. attacker snooping the NAS exchange, attacker snooping the AAA exchange, network operator, administrator, etc. Instead = the debate occurred on a piecemeal basis across multiple documents and WGs. 2. Due to the piecemeal nature of the discussion, introduction of = partial anonymity in one part of the system (e.g. user-NAS communications) = resulted in issues arising for other actors (e.g. network providers, = administrators). 3. The term "privacy" was never defined, nor were the goals laid out. = Indeed the initial concerns seemed to be more about security than privacy, and subsequent arguments more about billing assurance than privacy. 4. Although regulatory requirements eventually loomed large in the = debate, these were never referenced in any of the documents, or even = comprehensively discussed. As a result, there were arguments within the IETF as well as = IEEE 802 about what those requirements were real or imagined that were never = put to rest (e.g. is a MAC address considered PII, and if so, in what = countries? What other things in the EAP/AAA system are considered PII?). 5. The lack of a definition of privacy or goals lead to somewhat odd = design decisions that were not fully justified or even discussed. This included things like leaving permanent identifiers (MAC addresses) while focusing = on ephemeral user names. 6. The use of EAP and AAA data in other contexts has continued to grow. = For example, this data is a very popular source of location info as provided = in location configuration protocols (e.g. HELD, DHCP). It is also commonly = used in response to security incidents (e.g. denying access to infected = machines, detection of spoofing or bot infection, etc.). An example of where AAA = privacy issues have arisen again is given below. > From: rbarnes@bbn.com > Subject: privacydir review of draft-ietf-savi-threat-scope > Date: Tue, 14 Jun 2011 12:49:33 -0400 > = To: draft-ietf-savi-threat-scope@tools.ietf.org; savi-chairs@tools.ietf.org; privacydir@ietf.org; iesg@ietf.org > > Do not be alarmed. I have = reviewed this document as part of the privacy directorate's ongoing effort to some = IETF documents being processed by the IESG. These comments were written = primarily for the benefit of the security area directors. Document editors and WG = chairs should treat these comments just like any other review comments. > > = This document attempts to scope the threats that the SAVI mechanisms are = intended to counter, and describe some potential approaches to countermeasures. = While the document is quite thorough in its descriptions of spoofing problems = and concerns related to network architecture, it reads more as a primer on spoofing and anti-spoofing than a set of constraints for a working = group. This expanded focus leaves the document with at least some serious problems: = > (1) It fails to scope the SAVI problem tightly enough, leaving the door open = to potentially privacy-risky designs, > (2) It does not address some = solution approaches that would be more privacy-friendly. > (3) It conflates anti-spoofing with attack mitigation/forensics, a much more = privacy-risky activity > > > 1. > > With regard to scoping: The document discusses = several points in the network architecture (Figure 1) where anti-spoofing = measures can be enforced, but it never states clearly at which points the SAVI = mechanism is intended to be applied. Given the considerations discussed in the = document (and indeed the SAVI charter), it seems clear that there are sufficient mechanisms (BCP 38 and uRPF) for use at the various inter-network = interfaces and, by extension, to links between subnets within a network. > > Thus, = the document should clearly state that SAVI is limited to spoofing within a = local layer-2 network, before it reaches a router. The closest the current = version comes to this is the statement in Section 4.2.3 that "Much of the work = of SAVI is initially targeting minimizing source address spoofing in the LAN." = This statement should be tightened (e.g., by removing "Much" and "initially") = and made more prominent as a constraint for the SAVI solution. > > This = constraint is important from a privacy perspective because of the risk that SAVI solutions will increase the propagation of potentially private host = identity information (e.g., the MAC-IP bindings prevented by RFC 4941). > > = Another ambiguity that raises privacy concerns is the document's discussion of = binding anchors. The document uses the phrase "binding anchor" without = definition. Another SAVI document (draft-ietf-savi-framework, which is not = referenced) defines a binding anchor as a "link layer property of the host's network attachment ... [which] must be verifiable in every packet that the host = sends, and harder to spoof than the host's IP source address itself". > > This documents suggests that network authentication credentials, e.g., those = used for 802.1X, could be suitable binding anchors. This proposal clearly contradicts the cited definition for binding anchors, since these = credentials are not verifiable in packets. The use of such credentials outside of = their role in AAA systems clearly creates privacy risks by increasing the = exposure of what is often personally-identifying information. > > > 2. > > All of = the attacks listed in Section 3 rely on a host accepting and processing = spoofed packets, as opposed to spoofed packets being used to overwhelm some network-internal resources. This property would seem to indicate that = the real goal for SAVI is the following: A host must not accept packets from = other hosts on the same local network unless the source host has been properly assigned that address. > > Viewed from this perspective, SAVI should essentially constitute a mechanism for adding assurance to ARP/ND = caches, e.g., by allowing hosts to receive information about address bindings = either from each other or from an authoritative source such as a router on the = link. By basing the solution at end hosts, where the information being assured already resides, the solution could avoid the privacy concern that the = current network-based approaches raise. Namely, network-based solutions leak information cached in the local network into other parts of the network control plane, increasing the risk that it will be further exposed. > > = > 3. > > The document mentions several times the need for greater traceability = in support of attack forensics, i.e., for mechanisms that allow network administrators to identify the source of an attack. These requirements = should be removed, because they are out of scope and create privacy risks. > > Anti-spoofing mechanisms are a limited subset of traceability = mechanisms. They support attack mitigation/forensics by ensuring that the view of the = network from DHCP lease tables and ND caches is correct. More general = traceability mechanisms can involve binding addresses to other data like network = access credentials and user identifiers. These data are not required for anti-spoofing, and are clearly much more privacy-sensitive than the = layer-2 information used for anti-spoofing. > > > > > > > > > _______________________________________________=20 Privacy-program mailing list Privacy-program@iab.org = https://www.iab.org/mailman/listinfo/privacy-program= --Apple-Mail-7-350129897 Content-Disposition: attachment; filename="IPv6 addresses privacy review.txt" Content-Type: text/plain; name="IPv6 addresses privacy review.txt" Content-Transfer-Encoding: 7bit Privacy and IPv6 Addresses == Introduction == IPv6 was designed to improve upon IPv4 in many respects, and mechanisms for address assignment were one such area for improvement. In addition to static address assignment and DHCP, stateless autoconfiguration was developed as a less intensive, fate-shared means of performing address assignment. With stateless autoconifguration, routers advertise on-link prefixes and hosts generate their own suffixes to complete their addresses. Over the years, many suffix generation mechanisms have been defined: -- Manual configuration -- Link-layer address-derived: -- MAC address (RFC 1972/2464) -- IPv4 address (many RFCs) -- IPv4 address + port (RFC 4380) -- Random (RFC 3041/4941) -- Hash of public key (RFC 3972) Deriving the suffix from a globally unique MAC address (RFC 2462) was one of the earliest mechanisms developed. Although a number of privacy problems associated with this approach were later identified, major IPv6 compliance testing suites required (and still require) implementations to support MAC-derived suffixes in order to be approved as compliant. Implementations that fail to support MAC-derived suffixes are therefore largely not eligible to receive the benefits of compliance certification (e.g., use of the IPv6 logo, eligibility for government contracts, etc.). == Problems with MAC-derived addresses == A number of privacy issues related to the MAC-derived mechanism were identified after its standardization. MAC-derived suffixes are unique, allowing users to be tracked as they move. As RFC 3041/4941 explain: "The use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. For example, a network sniffer placed strategically on a link across which all traffic to/from a particular host crosses could keep track of which destinations a node communicated with and at what times. Such information can in some cases be used to infer things, such as what hours an employee was active, when someone is at home, etc. ... The use of a constant identifier within an address is of special concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper layer payloads were encrypted." RFC 3041 reflects some notion of what the threats against MAC-derived suffixes could be like -- the network sniffer mentioned above, the possibility for web sites (alone or together with other sites or network-based entities) to correlate user activity across visits -- but it did not include any in-depth threat modeling. (Notably, work on RFC 3041 took place around the time when Intel's inclusion of a unique, retrievable serial number in its Pentium III processors was creating some privacy controversy in the press and among regulators.) Attackers were assumed to not be on the same LAN as the user, which precludes certain kinds of adversaries (e.g., governments). The tracking made possible by MAC-derived suffixes is of particular concern because MAC addresses are much more permanent than, say, DHCP leases. MAC addresses tend to last roughly the lifetime of a device's network interface, allowing tracking on the order of years, compared to days for DHCP. The structure of the MAC address also makes it easier for an attacker to identify an individual device than if the suffix were comprised of purely random bits and it creates a potential security vulnerability not present in IPv4 addresses. MAC addresses contain 24-bit organizationally unique identifiers (OUIs) that identify vendors or manufacturers. Because popular OUIs are well known and easy to find, their presence in IPv6 address suffixes reduces the number of variable bits in a MAC-derived address, making it easier for an attacker to scan for individual addresses. An attacker with knowledge of device-specific vulnerabilities could also use the presence of known OUIs as a way to quickly scan for particular devices to exploit. These problems only surfaced subsequent to the realization of the tracking issues associated with MAC addresses. Had they been identified during the development of RFC 1972, using a hash of the MAC address instead of the address itself to derive the suffix could have provided a simple way to avoid these problems. == Addressing the problems == RFC 3041 (later obsoleted by RFC 4941) sought to address the problems with user tracking by defining "temporary addresses" (commonly referred to as "privacy addresses") for outbound connections. Temporary addresses are meant to supplement the other suffixes that a device might use, not to replace them. They are randomly generated and change daily by default. The idea is for temporary addresses to be used for things like web browsing while maintaining the ability to use a "public" address when more address stability is required (e.g., in DNS advertisements). For a temporary address to provide protection against tracking and re-identification, it cannot be mixed together with a public address for the same device, otherwise the temporary address could be correlated to the persistent public address. This aspect has sometimes been overlooked in applications' use of multiple addresses generated in different ways. RFC 3484 specifies that public addresses be used for outbound connections unless an application explicitly prefers temporary addresses. The default preference for public addresses was established to avoid applications potentially failing due to the short lifetime of temporary addresses or the possibility of a reverse look-up failure or error. However, RFC 3484 allowed that "implementations for which privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses." Some major implementations (e.g., Windows) default to temporary addresses for outbound connections, but the default preference against using temporary addresses remains as the normative standard. The address-scanning problem can be mitigated by using randomly-generated suffixes for all addresses, whether they are public/persistent or temporary. These addresses can still be used for tracking, but they remove the OUI-associated vulnerability and make address scanning for IPv6 addresses no easier than for IPv4 addresses. Windows uses random suffixes for all addresses, but many other implementations do not. == Other IPv6 privacy issues == Since IPv6 subnets have unique prefixes, they reveal some information about the location of the subnet, just as IPv4 addresses do. However, routing IPv6 traffic at a location where IPv4 NAT is in use can reveal far more locational granularity than IPv6 alone. Hiding this information is one motivation for usng NAT in IPv6 (see RFC 5902 section 2.4). Teredo (RFC 4380) specifies a means to generate an IPv6 address from the underlying IPv4 address and port, leaving many other bits set to zero. This makes it relatively easy for an attacker to scan for IPv6 addresses by guessing the Teredo client's IPv4 address and port (which for many NATs is not randomized). After this vulnerability was pointed out in a number of security analyses, some implementations began deviating from the standard by including 12 random bits in place of zero bits. This modification was later standardized in RFC 5991. == Lessons learned == 1. It is more difficult to retrofit privacy protection onto an already-established standard than it is to build the protection in initially. Once the MAC-derived suffix mechanism was standardized, it was perceived to be required and therefore became part of compliance suites, which continue to compel implementations to support it many years after the associated vulnerabilities have been identified. Once vulnerabilities are discovered, implementors that develop fixes may be put in the position of choosing to deploy fixed-but-non-standard implementations while they wait for standardized solutions to catch up. 2. Even with the vulnerabilities identified, a comprehensive privacy threat model was never developed (which seems to be a recurring theme with older protocol development efforts). This may be one reason why the same underlying vulnerabilities appear again and again (e.g., address scanning). 3. Notions of the implications of using particular identifiers that are contemporaneous with standards development will inform how those identifiers are used within standards work. In the late 1990's when IPv6 stateless autoconfiguration was being developed, notions of what constituted "personally identifiable information" (PII) were limited to identifiers such as name, address, and telephone number. If stable identifiers like MAC addresses had been more widely considered to be PII, or if the privacy implications of persistent re-use of stable identifiers had been better understood, the temporary addressing mechanism would have been more likely to have emerged sooner and with a stronger normative default. This is particularly important given current debates about whether it is even possible to continue to draw strict lines between PII and non-PII. 4. Even when "private" identifiers are available, combining or correlating them with persistent identifiers may often happen by accident. Ensuring that identifier silos are maintained often needs to happen outside of the standards process and can be difficult to enforce. 5. Implementability/usability can trump privacy. Temporary addresses are not recommended by default because of the risks that they pose to applications that rely on stable addresses and/or reverse look-up. --Apple-Mail-7-350129897 Content-Disposition: attachment; filename="Presence privacy review.txt" Content-Type: text/plain; name="Presence privacy review.txt" Content-Transfer-Encoding: 7bit [from draft-morris-privacy-considerations-03] 5.1. Presence A presence service, as defined in the abstract in RFC 2778 [RFC2778], allows users of a communications service to monitor one another's availability and disposition in order to make de- cisions about communicating. Presence information is highly dynamic, and generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like. Necessarily, this information has certain privacy implications, and from the start the IETF approached this work with the aim to provide users with the controls to determine how their presence information would be shared. The Common Profile for Presence (CPP) [RFC3859] defines a set of logical operations for delivery of presence information. This abstract model is applicable to multiple presence systems. The SIP- based SIMPLE presence system [RFC3261] uses CPP as its baseline architecture, and the presence operations in the Extensible Messaging and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922]. SIMPLE [RFC3261], the application of the Session Initiation Protocol (SIP) to instant messaging and presence, has native support for subscriptions and notifications (with its event framework [RFC3265]) and has added an event package [RFC3856] for pres- ence in order to satisfy the requirements of CPP. Other event packages were defined later to allow additional information to be exchanged. With the help of the PUBLISH method [RFC3903]. clients are able to install presence information on a server, so that the server can apply access-control policies before sharing presence information with other entities. The integration of an explicit authorization mechanism into the presence architecture has been a major improvement in terms of involving the end users in the decision making pro- cess before sharing information. Nearly all presence systems deployed today provide such a mechanism, typically through a reciprocal authorization system by which a pair of users, when they agree to be "buddies," consent to divulge their presence information to one another. One important extension for presence was to enable the support for location sharing. With the desire to standardize protocols for systems sharing geolocation IETF work was started in the GEOPRIV working group. During the initial requirements and privacy threat analysis in the process of chartering the working group, it became clear that the system would an underlying communication mechanism supporting user consent to share location information. The resemblance of these requirements to the presence framework was quickly recognized, and this design decision was documented in RFC 4079 [RFC4079]. While presence systems exerted influence on location pri- vacy, the location privacy work also influenced ongoing IETF work on presence by triggering the standardization of a general access control policy language called the Common Policy (defined in RFC 4745 [RFC4745]) framework. This language allows one to express ways to control the distribution of information as simple conditions, actions, and transformations rules expressed in an XML format. Common Policy itself is an abstract format which needs to be instantiated: two examples can be found with the Presence Authorization Rules [RFC5025] and the Geolocation Policy [I-D.ietf-geopriv-policy]. The former provides additional expressiveness for presence based systems, while the latter defines syntax and semantic for location based conditions and transformations. As a component of the prior work on the presence architecture, a format for presence information, called Presence Information Data Format (PIDF), had been developed. For the purposes of conveying location information an extension was developed, the PIDF Location Object (PIDF-LO). With the aim to meet the privacy requirements defined in RFC 2779 [RFC2779] a set of usage indications (such as whether retransmission is allowed or when the retention period expires) in the form of the following policies have been added that always travel with location information itself. We believe that the standardization of these meta-rules that travel with location information has been a unique contribution to privacy on the Internet, recognizing the need for users to express their preferences when information travels through the Internet, from website to website. This approach very much follows the spirit of Creative Commons [CC], namely the usage of a limited number of conditions (such as 'Share Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group did not, however, initiate work to produce legal language nor to de- sign graphical icons since this would fall outside the scope of the IETF. In particular, the GEOPRIV rules state a preference on the retention and retransmission of location information; while GEOPRIV cannot force any entity receiving a PIDF-LO object to abide by those preferences, if users lack the ability to express them at all, we can guarantee their preferences will not be honored. While these retention and retransmission meta-data elements could have been devised to accompany information elements in other IETF protocols, the decision was made to introduce these elements for geolocation initially because of the sensitivity of location information. The GEOPRIV working group had decided to clarify the architecture to make it more accessible to those outside the IETF, and also provides a more generic description applicable beyond the context of presence. [I-D.ietf-geopriv-arch] shows the work-in-progress writeup. --Apple-Mail-7-350129897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Alissa Cooper > Date: July 19, 2011 1:22:07 AM EDT > To: privacydir@ietf.org, privacy-program@iab.org > Cc: IAB IAB > Subject: [privacydir] Privacy directorate/IAB privacy program meeting = at IETF 81 >=20 > Here are the details for the privacy directorate/privacy program = meeting at IETF 81: >=20 > Date: Monday, July 25, 2011 > Time: 8:45pm to 10:15pm > Location: Hilton Quebec, meeting room 304 A (the IAB room) > Meeting materials: = http://www.iab.org/activities/programs/privacy-program/privacy-reviews/ > Dinner will not be available, please eat beforehand >=20 > The privacy reviews linked at the above page were written recently for = a variety of purposes: the EAP and IPv6 ones try to review the history = of privacy thinking as the protocols developed, the SAVI and IPFIX ones = were done as privacy directorate reviews, the presence and AAA ones are = included as examples in draft-morris-privacy-considerations-03, and the = ABFAB and mobility ones analyze architectures in development. We'll kick = off the meeting with these questions: >=20 > -- Are there issues or lessons learned that appear repeatedly in these = reviews? What can we generalize about those? >=20 > -- Are there any general criteria that are emerging to help protocol = designers review their documents for privacy considerations? What = questions are reviewers asking themselves? What questions should they be = asking themselves? >=20 > -- Is there any sort of classification of threats that can be drawn = from these reviews? Which threats are or are not discussed? >=20 > Let me know if you have questions or suggestions prior to IETF 81. >=20 > Best, > Alissa > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir >=20 --Apple-Mail-7-350129897--