2012/2/13 Hannes Tschofenig <[email protected]>: > > 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 >
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 > 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 > > > On Feb 10, 2012, at 3:44 AM, [email protected] wrote: > >> >> Hannes Tschofenig <[email protected]> 写于 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? >> > > _______________________________________________ > 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
