Subject: [ietf-privacy] anonymity definition in "draft-hansen-privacy-terminology-03"

From: [email-masked]
Date: Thu, 9 Feb 2012 10:51:13 +0800

Hi,all

the definition of anonymity
"Definition:  Anonymity of a subject from an attacker's perspective
      means that the attacker cannot sufficiently identify the subject
      within a set of subjects, the anonymity set.
"
1) is not clear about the content of anonymity set, will the real 
identities of candidate subjects be included?
2) has too much variance when evaluating a scheme's anonymity.

For example, draft-zhang-hip-privacy-protection-04 gives a privacy 
protection scheme by  hashing the real identity:
B-HIT-I=SHA-1(HIT-T,N)

and send B-HIT-I along with N (chosen for each session).

if suppose the attacker has no knowledge of HIT-I, or  a set of HIT-I, the 
scheme has a certain anonymity;
if suppose the attacker has knowledge of HIT-I, or a set of HIT-I(which is 
not difficult to collect), the scheme has no anonymity because he can try 
each HIT-I he knowes by
recalculating SHA-1.
 
The scheme has anonymity at first and has less anonymity with time went on 
and users have collected more HITs?

I think as a character of system, it should be stable.

Regards~~~

-Sujing Zhou

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 9 Feb 2012 09:17:16 +0200

Hi Zhou, 

Thank you for your questions. 

I guess you are looking at the terminology document from the point of view of writing draft-zhang-hip-privacy-protection-04. You are trying to find the right words to describe the properties of the solution you have been working on. 

When you look at the privacy consideration draft (see http://tools.ietf.org/html/draft-iab-privacy-considerations-01) then the first thing is to think about a threat model. In your communication protocol you may consider the following adversaries:
(Note that I am saying this without having followed HIP for a long time and so I might be missing something here.)

* responders who get to see identity information,
* eavesdroppers who observe the exchanges and may want to learn about the communication relationships and the identities of the initiator and / or the responders, and 
* HIP-based intermediaries (e.g., these HIP-based firewalls).  

Could you explain me what the focus of your draft is with respect to hiding identities? 

I believe you are not trying to provide a mechanism to prevent disclosing the identity of the HIP initiator to the HIP responder. I think you care about eavesdroppers in the middle. Is this correct?

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Thursday, February 09, 2012 4:51 AM
To: [email-masked]
Subject: [ietf-privacy] anonymity definition in"draft-hansen-privacy-terminology-03"

Hi,all 

1) is not clear about the content of anonymity set, will the real identities of candidate subjects be included? 

For example, draft-zhang-hip-privacy-protection-04 gives a privacy protection scheme by  hashing the real identity: 
B-HIT-I=SHA-1(HIT-T,N) 

if suppose the attacker has no knowledge of HIT-I, or  a set of HIT-I, the scheme has a certain anonymity; 
if suppose the attacker has knowledge of HIT-I, or a set of HIT-I(which is not difficult to collect), the scheme has no anonymity because he can try each HIT-I he knowes by 
recalculating SHA-1. 
  
The scheme has anonymity at first and has less anonymity with time went on and users have collected more HITs? 

Regards~~~

-Sujing Zhou

---

From: [email-masked]
Date: Thu, 9 Feb 2012 15:49:19 +0800

Hi，Hannes，
I must make a clarification that the draft I took as an examle is not 
written by me :).
I just happen to read that draft and tried to find the security by 
referring  to the privacy terminology draft.

The question I have did not come only from the privacy draft by Zhang (not 
me), also from 
another definition of anonymity which is popular in cryptograhy:
 
the adversary is given two IDs, and an oracle computing an output from one 
of the IDs,
if the adversary cann't figure out the correct ID from the output with 
probability greater than 0.5, then it is called anonymous. 

But in the pivacy teminology, it is not clear if the attacker has the 
knowledge of affected IDs.

Come to Zhang's draft, it is rather easy to collect many HIP identity 
tags, and wheather or not knowledge of   identities is essential to 
evaluate the anonymity 
, at least to zhang's draft,I think.

Regards~~~

-Sujing Zhou

"Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> 写于 
2012-02-09 15:17:16:

> I guess you are looking at the terminology document from the point 
> of view of writing draft-zhang-hip-privacy-protection-04. You are 
> trying to find the right words to describe the properties of the 
> solution you have been working on. 
> 
> When you look at the privacy consideration draft (see http://tools.
> ietf.org/html/draft-iab-privacy-considerations-01) then the first 
> thing is to think about a threat model. In your communication 
> protocol you may consider the following adversaries:
> (Note that I am saying this without having followed HIP for a long 
> time and so I might be missing something here.)
> 
> * eavesdroppers who observe the exchanges and may want to learn 
> about the communication relationships and the identities of the 
> initiator and / or the responders, and 
> I believe you are not trying to provide a mechanism to prevent 
> disclosing the identity of the HIP initiator to the HIP responder. I
> think you care about eavesdroppers in the middle. Is this correct?
> 
> Ciao
> Hannes
> 
> 
> From: [email-masked] [mailto:ietf-privacy-
> [email-masked]] On Behalf Of ext [email-masked]
> if suppose the attacker has knowledge of HIT-I, or a set of HIT-
> I(which is not difficult to collect), the scheme has no anonymity 
> because he can try each HIT-I he knowes by 
> recalculating SHA-1. 
>   
> The scheme has anonymity at first and has less anonymity with time 
> went on and users have collected more HITs? 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 9 Feb 2012 10:53:01 +0200

Hi Zhou, 

I sort of assumed that you were the co-author of the mentioned draft without actually looking at it. Sorry, my mistake. 

Anyway, I believe that anonymity isn't the right term for that document when the privacy threat is focused on the HIP responder getting to know the host identities. The HIP responder receives the HITs in the exchange.

The only form of protection the document seems to provide is the usage of pseudonyms. A HI itself is already a pseudonym (based on the definition of a pseudonym in the document) and the main question here is about linkability and about the lifetime of these pseudonyms. We could, for example, regularly re-compute a new HI and use it. This may be computationally more expensive but would provide some level of protection. The problem only shows up in relationship to other usages of the HI, for example, for access control. In the draft this blinded HIT is used that is essentially derived from the original HiT (and consequently from the HI). An attacker may not able to learn the original HIT (or HI) but may still be able to make the individual protocol runs linkable to each other. Note that this mechanism has often been provided by other protocols as well (see all the network access authentication protocols). 

Btw, where did you got this anonymity definition from that you cite below? I don't think it is particularly good. Imagine that you have a VoIP service offering that only has two users, you and me. If an adversary eavesdrops on the communication it may not find out whether it is you or me (without using further information) but that's a pretty bad privacy protection. Instead, it would be much better if the anonymity set is much larger. 

Ciao
Hannes

PS: It may turn out to be useful to add another term to the document to express the common property of hiding the identity of the initiator to eavesdroppers, such as "initiator identity confidentiality". 

On Feb 9, 2012, at 9:49 AM, [email-masked] wrote:

> 
> Hi，Hannes， 
> I must make a clarification that the draft I took as an examle is not written by me :). 
> I just happen to read that draft and tried to find the security by  referring  to the privacy terminology draft. 
> 
> The question I have did not come only from the privacy draft by Zhang (not me), also from 
> the adversary is given two IDs, and an oracle computing an output from one of the IDs, 
> if the adversary cann't figure out the correct ID from the output with probability greater than 0.5, then it is called anonymous. 
> 
> But in the pivacy teminology, it is not clear if the attacker has the knowledge of affected IDs. 
> 
> Come to Zhang's draft, it is rather easy to collect many HIP identity tags, and wheather or not knowledge of   identities is essential to evaluate the anonymity 
> "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> 写于 2012-02-09 15:17:16:
> 
> > Hi Zhou, 
> > 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: [email-masked]
Date: Fri, 10 Feb 2012 09:44:20 +0800

Hannes Tschofenig <[email-masked]> 写于 2012-02-09 16:53:01:

> Anyway, I believe that anonymity isn't the right term for that 
> document when the privacy threat is focused on the HIP responder 
> getting to know the host identities. The HIP responder receives the 
> HITs in the exchange.
> 
> The only form of protection the document seems to provide is the 
> usage of pseudonyms. A HI itself is already a pseudonym (based on 
> the definition of a pseudonym in the document) and the main question
> here is about linkability and about the lifetime of these 
> pseudonyms. We could, for example, regularly re-compute a new HI and
> use it. This may be computationally more expensive but would provide
> some level of protection. The problem only shows up in relationship 
> to other usages of the HI, for example, for access control. In the 
> draft this blinded HIT is used that is essentially derived from the 
> original HiT (and consequently from the HI). An attacker may not 
> able to learn the original HIT (or HI) but may still be able to make
> the individual protocol runs linkable to each other. Note that this 
> mechanism has often been provided by other protocols as well (see 
> all the network access authentication protocols). 

I think unlinkability is stronger than anonymity( " An attacker might get 
to know
   information on linkability of various messages while not necessarily
   reducing anonymity of the particular subject.  ")
so anonymity is the basic requirement for privacy protection? 

> 
> Btw, where did you got this anonymity definition from that you cite 
> below? I don't think it is particularly good. Imagine that you have 
> a VoIP service offering that only has two users, you and me. If an 
> adversary eavesdrops on the communication it may not find out 
> whether it is you or me (without using further information) but 
> that's a pretty bad privacy protection. Instead, it would be much 
> better if the anonymity set is much larger. 

I got the definition of anonymity in  P10 [in Foundations of Group 
Signatures: The Case of Dynamic Groups 
http://www-cse.ucsd.edu/~mihir/papers/dgs.html]

> Ciao
> Hannes
> 
> PS: It may turn out to be useful to add another term to the document
> to express the common property of hiding the identity of the 
> initiator to eavesdroppers, such as "initiator identity 
confidentiality". 

or as a special case of anonymity?

---

From: Claudia Diaz <[email-masked]>
Date: Fri, 10 Feb 2012 15:07:35 +0100

Hi, 

> I think unlinkability is stronger than anonymity( " An attacker might get to know

I think it is more complicated than that. 

Some thoughts on the subject: 

- I believe Iinkability eventually leads to a degradation of anonymity. In fact, if actions / messages / transactions are linkable, I would say there is no anonymity, but rather "pseudonymity" (one can give a name or number to the set of transactions which acts as a pseudonym for the user). 

- I do not think one can talk of a "basic requirement" for privacy protection in general. Each case must be studied individually in order to see: how do we define a privacy breach in the context of the application, what is the threat model, how do the requirements translate to technical properties, etc. 

- I also think that one can distinguish (at least) two basic mechanisms for privacy protection (which can also be combined):

1) anonymity: the actions are known (eg, which web page is downloaded) and the identity is concealed. 

2) PIR/OT approach: the identity is known but the action is concealed (eg, I know you are accessing a record in my database, but I do not know which record it is). 

Best,
Claudia

On 10 Feb 2012, at 02:44:20, [email-masked] wrote:

> I think unlinkability is stronger than anonymity( " An attacker might get to know
> I got the definition of anonymity in  P10 [in Foundations of Group Signatures: The Case of Dynamic Groups 
> > initiator to eavesdroppers, such as "initiator identity confidentiality". 
> 

--------------------------------------------------------------------------
Prof. Dr. Ir. Claudia Diaz

Katholieke Universiteit Leuven                       
Dept. Electrical Engineering-ESAT / COSIC
Kasteelpark Arenberg 10, B-3001 Leuven, BELGIUM
tel: +32 16 32 18 14	fax: +32 16 32 19 69

email: claudia.diaz (at) esat.kuleuven.be
web: http://homes.esat.kuleuven.be/~cdiaz/
--------------------------------------------------------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Feb 2012 13:03:02 +0200

Hi Zhou, 

you raise good points. 

I believe we need terms for three cases: 

1) Hiding of your identity towards the final communication receiver. 
2) Hiding of your identity towards eavesdroppers (along the path between the sender and the receiver)
3) Avoiding the relationship between two (or more) protocol runs

My suggestion for terms is:

ad 1) Anonymity & pseudonymity (as currently defined in the draft)
ad 2) Identity confidentiality (currently not in the draft)
ad 3) unlinkable session (as currently defined in the draft). 

I could add examples for each of these cases from IETF protocols to the draft to draw the relationship with currently developed IETF protocols. 

Does this make sense to you? 

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Feb 2012 08:35:12 -0800

> 3) Avoiding the relationship between two (or more) protocol runs

So, I think it is useful to distinguish among the cases you have
above, but I think the third
needs a bit more work.  Avoid disclosing the relationship between two
or more protocol runs
*to whom*?  There's a difference between providing the protocol
mechanics to make two sessions
unlinkable to the outside observer and to making them unlinkable to
one of the parties to the session.

regards,

Ted

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Feb 2012 19:46:37 +0200

Hey Ted, 

yes, I should have been more precise. 

Here is the current definition of "unlinkable sessions":

   Definition:  The term "unlinkable session" refers the ability of the
      system to render a set of actions by a subject unlinkable from one
      another over a sequence of protocol runs (sessions).

This definition talks about the "system" and it should rather talk about eavesdroppers instead. 
Better wording may also be needed since I just created it when I updated the most recent draft version and I couldn't really find something else that worked nicely. 

You also raised the question what term to use when we actually want to provide unlinkability towards one or multiple communication recipients. This is essentially the debate about "profiling" and we could use terms from there. Here is what I have in the document:

  Definition:  We use the term "profiling" to mean learning information
      about a particular subject while that subject remains anonymous to
      the attacker.  For example, if an attacker concludes that a
      subject plays a specific computer game, reads specific news
      article on a website, and uploads certain videos, then the
      subjects activities have been profiled, even if the attacker is
      unable to identify that specific subject.

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Feb 2012 10:54:53 -0800

> Better wording may also be needed since I just created it when I updated the most recent draft version and I couldn't really find something else that worked nicely.

If you updated to say  "render a set of actions by a subject
unlinkable by either party or eavesdroppers
over a sequence of protocol runs (sessions)", does that meet your
intent?  Or do you mean a more limited
form?

Note that when I think about the subject've view as a party, the
property I expect is that the subject knows
that they are linked, but could not prove it based on data from the
protocol sessions.

regards,

Ted Hardie

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 13 Feb 2012 20:41:59 +0100

Sent from my iPad

> that they are linked, but could not prove it based on data from the

I guess there is still another case, that of the inability of the identity asserting party to know what entities the subject has a protocol run with. Example, I may have to show ID to get a beer, but the passport authority doesn't know I bought a beer.

Klaas

---

From: [email-masked]
Date: Tue, 14 Feb 2012 09:26:56 +0800

Hi, Hannes,
 
  IMO, case 2) is more like the current definition in the draft
       case 1) is harder to achieve, hiding id towards receiver seems 
rarely needed, 
              some privacy sensitive protocols may need it, e.g., 
anonymous authentication protocols, as far as I know.
       case 3) is even harder to achieve, may be included in some strong 
definitions of anonymity

Yes, I think it is a very good  idea of relating the definition here with 
available IETF protocols as examples.

Regards~~~
-Sujing Zhou

Hannes Tschofenig <[email-masked]> 写于 2012-02-13 19:03:02:

> I could add examples for each of these cases from IETF protocols to 
> the draft to draw the relationship with currently developed IETF 
protocols. 
confidentiality".

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Feb 2012 12:28:30 +0200

Hi Ted, 

The term needs to be refined based on this discussion. 

I want to have a term for a common aspect in security protocol design where you create a linkage between an initial protocol run and a subsequent one with the help of some state information where. 

For example, in case of TLS session resumption or the TLS ticket mechanism allows you to link the initial exchange (the full exchange) to subsequent exchanges from the perspective of the TLS server. The purpose of this exchange is exactly that the server is able to refer to an earlier exchange.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Feb 2012 17:08:32 +0200

Hi Klaas, 

On 2/13/12 9:41 PM, "ext Klaas Wierenga" <[email-masked]> wrote:

> I guess there is still another case, that of the inability of the identity
> asserting party to know what entities the subject has a protocol run with.
> Example, I may have to show ID to get a beer, but the passport authority
> doesn't know I bought a beer.

I have heard about this property in the context of the NSTIC project and
there were actually two variants of it:

1) two different relying parties should not be able to tell that the same
user has logged in to both of them by comparing their login logs.

Here I would just the term anonymity or pseudonymity of the subject towards
the individual relying parties.

2) the identity provider should not be able to keep track of which relying
parties are being used by the subject. You are talking about this one.

Here I would use the term relationship anonymity. In the draft I used the
example of a MIX-net whereby the attacker is assumed to observe every
communication between the sender and the receiver. In your description, I
believe, you implicitly assume that the identity provider (passport
authority) does not get to see every message that the subject exchanges with
the relying party. 

In any case, it is a good example. I could add it as an additional example
to the draft since it gets frequently mentioned in identity management
discussions these days.

Ciao
Hannes

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 14 Feb 2012 18:32:34 +0100

Sent from my iPhone

> user has logged in to both of them by comparing their login logs.

This property (targeted or directed identity) was not what I was referring to, but yes, you want a per session, per relying party (and in some cases for limited time) pseudonym

> the individual relying parties.

See above, it goes beyond pseudonimity towards rp, it is about not sharing pseudonyms between parties

> parties are being used by the subject. You are talking about this one.

Yep

> the relying party

Well, even more, the idp should not know at all which rp I talk to in the first place. 

> to the draft since it gets frequently mentioned in identity management

Another example is paying cash for something that you don't want to be traced to you

Klaas

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Feb 2012 20:05:09 +0200

> Well, even more, the idp should not know at all which rp I talk to in the first place. 

Right. Relationship anonymity would provide you that property.

> Another example is paying cash for something that you don't want to be traced to you

That may be quite difficult to deploy in practice with all the laws in the financial sector...
But we will ignore that use case for a moment.

---

From: [email-masked]
Date: Wed, 15 Feb 2012 14:06:20 +0800

Hi,

> This property (targeted or directed identity) was not what I was 
> referring to, but yes, you want a per session, per relying party 
> (and in some cases for limited time) pseudonym
> 
> > 

Isn't 1) similar to unlinkability?

> Well, even more, the idp should not know at all which rp I talk to 

It is a strong privacy reqirement. Ｉdoubt solutions in ABFAB can provide 
this feature.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Feb 2012 10:30:35 +0200

Hi Zhou, 

thanks for your response. 

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 15, 2012 8:06 AM
To: Klaas Wierenga
Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]; [email-masked]
Subject: 答复: Re: [ietf-privacy] 答复: Re: 答复: RE: anonymity definition in"draft-hansen-privacy-terminology-03"

Hi, 

You are certainly right that there is a relationship between anonymity and unlinkability. In fact we had test about this topic in earlier versions in the draft, see http://tools.ietf.org/html/draft-hansen-privacy-terminology-00#section-5 <http://tools.ietf.org/html/draft-hansen-privacy-terminology-00#section-5> . The problem with these earlier versions was that they are a bit hard to read – the wording feels a bit academic. 

As such, the term unlinkability (with some additional qualifications regarding the items of interests, such as ‘unlinkability with respect to the subject’) may also be suitable here.

In a description I would, however, point out who the adversary is. In the description above the adversaries here are the colluding relying parties rather than some eavesdropper observing the communication exchange. The unlinkability in the http://tools.ietf.org/html/draft-iab-privacy-terminology-00#section-3 <http://tools.ietf.org/html/draft-iab-privacy-terminology-00#section-3>  leaves a few things open, namely who the attacker is and what the items of interest are. The content of the message is likely going to play a role in our context as well and the relying parties get to see the content. So, in certain cases it may be possible to come up with a solution that does not allow an eavesdropper to link to message exchanges of a subject to two relying parties together but the relying parties themselves will be able to establish that linkage. 

> Well, even more, the idp should not know at all which rp I talk to 

It is a strong privacy reqirement. Ｉdoubt solutions in ABFAB can provide this feature. 

This is only the terminology document and so there is no requirement to actually accomplish that functionality. 

Regarding ABFAB the text would then say that it does not provide this functionality. 

ciao

Hannes

---

From: Rhys Smith <[email-masked]>
Date: Mon, 20 Feb 2012 17:16:46 +0000

> It is a strong privacy reqirement. Ｉdoubt solutions in ABFAB can provide this feature. 

Yes, ABFAB cannot do this natively.

Though there are always ways around this. SAML cannot do this natively either, but the Cabinet Office (UK government) is in the middle of setting up a national federated infrastructure with exactly this properly, which it achieves by having a gateway in the middle which mediates all traffic.

Note that this privacy requirement may well be asymmetric - there may be a difference between the IdP not being able to know about which RP the user is using, and the RP not knowing which IdP the user came from...

R.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's education and research network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 20 Feb 2012 19:23:12 +0100

> Though there are always ways around this. SAML cannot do this natively either, but the Cabinet Office (UK government) is in the middle of setting up a national federated infrastructure with exactly…

Right, which of course puts another entity in the middle that knows more about your transactions then you might like….. ;-) What you really want is to be able to is have the IdP issue claims that are not specific for 1 relying party and that you can wield with whatever RP you like, but that probably requires a client side implementation a la InfoCard.

> Note that this privacy requirement may well be asymmetric - there may be a difference between the IdP not being able to know about which RP the user is using, and the RP not knowing which IdP the u…

yes, absolutely. And to echo what Hannes was saying, I am not at all suggesting that their are currently protocols out there that satisfy all privacy requirements. In fact sometimes a balance between privacy and usability needs to be found, for example it may from a privacy point of view  be nice to have aq different pseudonymous identifier every time a use a service, from a usability point of view however I may like the service to maintain a history of my previous transactions.

Klaas

---

From: David Chadwick <[email-masked]>
Date: Tue, 21 Feb 2012 22:37:04 +0000

On 20/02/2012 17:16, Rhys Smith wrote:
> On 15 Feb 2012, at 06:06, [email-masked]
> <mailto:[email-masked]> wrote:
>
> Though there are always ways around this. SAML cannot do this natively
> either, but the Cabinet Office (UK government) is in the middle of
> setting up a national federated infrastructure with exactly this
> properly, which it achieves by having a gateway in the middle which
> mediates all traffic.

Hmmm. the design of this is very questionnable (and opaque). Full trust 
must be given to the gateway, without any assurance that it is 
trustworthy. It is not even mentioned in the trust assurance document.

regards

David

>
> Note that this privacy requirement may well be asymmetric - there may be
> a difference between the IdP not being able to know about which RP the
> user is using, and the RP not knowing which IdP the user came from...
>
> R.
> --
> Dr Rhys Smith
> email: [email-masked] <mailto:[email-masked]> /
> [email-masked] <mailto:[email-masked]>
> GPG: 0xDE2F024C
>
>
>

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: Rhys Smith <[email-masked]>
Date: Tue, 21 Feb 2012 22:48:39 +0000

On 21 Feb 2012, at 22:37, David Chadwick <[email-masked]> wrote:

> Hmmm. the design of this is very questionnable (and opaque).

I would happen to agree, but they have their reasons for their design, some of which almost make sense by the light of the full moon.

> Full trust must be given to the gateway, without any assurance that it is trustworthy.

Their view is that it is operated by HMG, why shouldn't it be trustworthy? Some may argue the opposite for exactly the same reason :-).

> It is not even mentioned in the trust assurance document.

What trust assurance document?

R.

Sent from my iPhone

---

From: Rhys Smith <[email-masked]>
Date: Wed, 22 Feb 2012 08:42:59 +0000

> Right, which of course puts another entity in the middle that knows more about your transactions then you might like….. ;-) What you really want is to be able to is have the IdP issue claims that a…

Or giving the user an X509 cert ;-).

> yes, absolutely. And to echo what Hannes was saying, I am not at all suggesting that their are currently protocols out there that satisfy all privacy requirements. In fact sometimes a balance betwe…

Agree totally, but would go further and say it's almost *always* a delicate balancing act between privacy and usability, in the same way that it's *always* a balancing act between security and usability. In the whole history of computer science, I don't remembering encountering anything where I think anyone has gotten the balance correct - not least, of course, because that balance is probably at a different point on the scale for different users of the technology.

R.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Feb 2012 20:47:40 +0200

Hi David, 

this specific case seems to have pretty tough privacy requirements: you want to avoid having relying parties to know who the identity providers are AND also want to avoid letting identity providers know which relying parties data subjects talk to AND finally you want to avoid collusion among relying parties to learn more about data subjects.

It is interesting to see how a set of privacy requirements produce a system that has questionable privacy properties...

Ciao
Hannes

PS: Whenever one talks about trust it is useful to mention 'who is trusted by whom to do what'. 

On Feb 22, 2012, at 12:37 AM, David Chadwick wrote:

> Hmmm. the design of this is very questionnable (and opaque). Full trust must be given to the gateway, without any assurance that it is trustworthy. It is not even mentioned in the trust assurance document.
> 
> regards
> 
> David
> 
>>

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 24 Feb 2012 19:56:51 +0100

Hi Hannes,

Perhaps I am mistaken, but it seems that there is a bit too much focus on what is possible with *todays* technology. I would rather like to focus on properties we would *like* to see, and possibly work on those in the IETF (but most likely other fora).... But still that is probably not for a terminology document, but I do think we need to be able to express all desirable properties using the terms from the terminology document.

Klaas

Sent from my iPad

---

From: David Chadwick <[email-masked]>
Date: Fri, 24 Feb 2012 22:33:12 +0000

Hi Klaas

I agree with you. It might that IRTF is more appropriate for some work 
items, but this is something the ADs can decide

regards

David

On 24/02/2012 18:56, Klaas Wierenga wrote:
> Hi Hannes,
>
> Perhaps I am mistaken, but it seems that there is a bit too much
> focus on what is possible with *todays* technology. I would rather
> like to focus on properties we would *like* to see, and possibly work
> on those in the IETF (but most likely other fora).... But still that
> is probably not for a terminology document, but I do think we need to
> be able to express all desirable properties using the terms from the
> terminology document.
>
> Klaas
>
> Sent from my iPad
>
> On 24 feb. 2012, at 19:47, Hannes
> Tschofenig<[email-masked]>  wrote:
>
>> Hi David,
>>
>> this specific case seems to have pretty tough privacy requirements:
>> you want to avoid having relying parties to know who the identity
>> providers are AND also want to avoid letting identity providers
>> know which relying parties data subjects talk to AND finally you
>> want to avoid collusion among relying parties to learn more about
>> data subjects.
>>
>> It is interesting to see how a set of privacy requirements produce
>> a system that has questionable privacy properties...
>>
>> Ciao Hannes
>>
>>>> Though there are always ways around this. SAML cannot do this
>>>> natively either, but the Cabinet Office (UK government) is in
>>>> the middle of setting up a national federated infrastructure
>>>> with exactly this properly, which it achieves by having a
>>>> gateway in the middle which mediates all traffic.
>>>
>>> Hmmm. the design of this is very questionnable (and opaque). Full
>>> trust must be given to the gateway, without any assurance that it
>>> is trustworthy. It is not even mentioned in the trust assurance
>>> document.
>>>
>>> regards
>>>
>>> David
>>>
>>>>
>>>> Note that this privacy requirement may well be asymmetric -
>>>> there may be a difference between the IdP not being able to
>>>> know about which RP the user is using, and the RP not knowing
>>>> which IdP the user came from...
>>>>
>>>> R. -- Dr Rhys Smith Identity, Access, and Middleware
>>>> Specialist Cardiff University&  Janet - the UK's education and
>>>> research network
>>>>
>>>> email: [email-masked]<mailto:[email-masked]>  /
>>>> [email-masked]<mailto:[email-masked]> GPG: 0xDE2F024C
>>>>
>>>>
>>>>
>>>> _______________________________________________ ietf-privacy
>>>> mailing list [email-masked]
>>> Professor of Information Systems Security School of Computing,
>>> University of Kent, Canterbury, CT2 7NF Skype Name:
>>> davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile:
>>> +44 77 96 44 7184 Email: [email-masked] Home Page:
>>> http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research
>>> Web site:
>>> http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust
>>> key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
>>>
>>> ietf-privacy mailing list [email-masked]
>> _______________________________________________ ietf-privacy
>> mailing list [email-masked]

--

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 13:07:06 +0000

Well, regardless of venue, seeing a few drafts
that showed us good ways to handle privacy in IETF
protocols would be useful IMO.

For example, the IESG recently reviewed the SIP
common log format. [1] As part of the review I asked
if the WG had considered privacy and the answer was
essentially no and nor had they thought about any
privacy-friendly ways to handle identifiers in
log files that might be exchanged between domains.

It'd have been great to be able to say "go look
at RFC xxxx where it shows you ten possible ways
to do that."

S

[1] http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/

---

From: Klaas Wierenga <[email-masked]>
Date: Sat, 25 Feb 2012 18:24:47 +0100

Fwiw, I have agreed with Stefan Winter and Tomasz Wolniewicz to write an informational draft on the design of eduroam, including how logging is handled using pseudonymous identifiers, now if only we manage to find some time to write it up.....

Klaas

Sent from my iPad

---

From: Klaas Wierenga <[email-masked]>
Date: Sat, 25 Feb 2012 18:43:21 +0100

In the meanwhile perhaps worth looking at http://www.eduroam.org/downloads/docs/GN2-08-243-DJ5-4-1-2_Advanced_Technologies_Overview_Second_Edition_20090204080004.pdf section 2.2 on the use of pseudonyms in the Chargeable User Identifier attribute.

Klaas

Sent from my iPad

---

From: Stefan Winter <[email-masked]>
Date: Sat, 25 Feb 2012 18:52:12 +0100

Hi,

the CUI study was updated and selected for production use later. You can
have a look at chapter 3 of

http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-09-213-DJ3_1_1_RadSec_Standardisation_and_Definition_of_eduroam_Extensions_20091106091343.pdf

and an addendum in section 3.1 of the follow-up report

http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-10-304%20DJ3.1.2,1%20%20Roaming%20Developments%2024FEB11.pdf

In that document, we also introduced a privacy-preserving log mechanism
that works even if RADIUS/TLS with dynamic discovery is used (and hence
there is no RADIUS server logs from a clearing house to parse any more).
It's called "F-Ticks" (the Federated TICKer system) and you can read up
on it in section 3.5 of that report.

It very roughly works along the lines of SIP common log format (but I
didn't know that one by the time I wrote up the F-Ticks structure).

Greetings,

Stefan Winter

P.S.: yes, our URL length and PDF file names ... underperform. That's
understood. :-)

---

From: David Chadwick <[email-masked]>
Date: Sun, 26 Feb 2012 02:47:38 +0000

On 25/02/2012 13:07, Stephen Farrell wrote:

> ...cut... nor had they thought about any

As part of the recently completed EC TAS3 project we considered this and 
implemented a (partial) proof of concept. This uses the Liberty Alliance 
scheme of passing encrypted PIDs between SPs. But the process is very 
unwieldy and gets very complex once a log record refers to the PIDs of 
several different entities, each of which has a different PID at each 
SP. So it is not a system that I would especially recommend

regards

David

--