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 protected]> 写于 2012-02-13 19:03:02:
> 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
>
>
> 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
