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 protected] 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 > 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 protected]> 写于 > 2012-02-09 15:17:16: > > > 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 protected] [mailto:ietf-privacy- > > [email protected]] On Behalf Of ext [email protected] > > Sent: Thursday, February 09, 2012 4:51 AM > > To: [email protected] > > Subject: [ietf-privacy] anonymity definition in"draft-hansen- > > privacy-terminology-03" > > > > > > 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 > > > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
