Anonymous Identifiers (ALIEN) BoF
These are the minutes for the Anonymous Identifiers (ALIEN) BoF
held during the 62nd IETF meeting on on Wednesday, April 3rd 2005,
at 2pm - 4:30pm in Paris, France. Thanks to Andrew McGrecor and
Julien Laganier, on whose notes these minutes are based on.
These minutes have been compiled
by Pekka Nikander, one of the
BoF co-chairs, and was sent to the momipriv and saag mailing lists
for verification.
The purpose of this BoF was to discuss to discuss three different issues:
- Whether to form a privacy-related Research Group at the IRTF
- Whether to charter a new Working Group in the Security Area
- Whether to charter new working items for existing Working Groups
However, during the meeting it became clear that the suggested
approach does not work. In general, this experience indicates that
trying to charter an IRTF Research Group and an IETF Working Group
on a single BoF may not work well unless there is considerably
pre-existing work on the topic, as was the case when the HIP WG and
RG where discussed.
The positive output from the BoF was that there seems to be
considerable interest in this area among both the mobility and
security people. There seems also to be a fair amount of energy,
with over 10 people interested in working towards an IRTF RG and at
least 6 people interested in organising a workshop on the topic.
The negative output from the BoF was that the security (and
probably also other) people felt that we do not understand the
problems we are trying to solve. We do not understand the problem
even in the limited scope of MAC and IP addresses. Many people also
felt that solving the problem only at the link and IP layers is not
enough alone, but the approach should be more comprehensive.
In some discussions afterwards a number of people expressed their
concerns about the proposed limited WG of not having formed. It
looks like that there is a need and real energy in the community,
and it is well possible that there may be another attempt in the
next IETF meeting, provided that people are able to work out a good
enough problem statement and threat model. However, it must be
duly noted that the level of detail must be much better thought out
before a new BoF could take place.
As the next steps, the following seems to be likely:
- Form a new mailing list with the intention of chartering a
Research Group at the IRTF. The list is intended to eventually
become the RG discussion list.
- Initiate discussion on the RG charter, with the intention of
submitting it to the IRTF chair and IAB latest in October.
- Start working out the more specific threat analyses for two
problem scopes:
- A larger, more comprehensive scope
- A narrower scope, focusing on IPsec (including IKE) and
layers below
- Start working out details for a workshop to kick start the
Research Group work in this area. When writing this (on Friday
after the IETF meeting) it looks like that such a workshop, were
it to take place, most probably will not be an IAB
workshop, even though there may be IAB members participating.
Presentations and Discussion
Agenda and Introduction
The chairs introduced the BoF by discussing the current situation
where it is fairly easy to correlate link layer, IP layer and upper
layer identifiers, thereby collecting comprehensive communication
profiles about both stationary and mobile users. This is becoming
more a problem due to increased mobility, allowing the communication
profile to be annotated with the (approximate) location of the users
at any given time. Existing and anticipated legistlation in some
countries, European Union being the prime example, requires that
the systems must not disclose privacy-related information about the
users without their concent.
The flip side of the coin is that we need to have a balance between
identifiability and anonymity. Full anonymity would probably lead
to more unwanted traffic, including Denial of Service attacks and
various forms of Spam.
The chairs then outlined the proposed approach, which consisted of
the following:
- Consider forming a Research Group
- Understanding the larger problem space
(privacy in Internet protocols)
- Consider forming a Working Group
- Focus on implementation guidelines and gap analysis
- Consider new working working items for existing WGs
- Should we change existing protocols?
- Rajeev Koodli:
- You could do 2 [implementation guidelines
and gap analysis] as a part of 1 [in a Research Group]; you don't
need a working group for that. As I understand it, Research Groups
can publish documents as guidelines.
- Pekka Nikander:
- We'll consider this; that will be part
of the open discussion towards the end.
Terms and definitions
Erik Nordmark gave a presentation giving defintions for the
following terms, as defined
in draft-haddad-momipriv-problem-statement-01.txt:
- Anonymity
- Pseudonymity
- Unlinkability
- Privacy
There was some discussion about the terms. Erik noted that perfect
anonymity may not be technically possible. Rajeev wanted to know
what is meant with the term "entity", is it a device, a user, or
what? Erik answered that an entity may be different in different
cases. For example, a VPN gateway is a device used by potentially
hundreds of devices, and there may not be any mapping from the
gateway to individual devices or users. Rajeev noted that there
seems to be a mistake in the definitions at least in the slides: If
there are two actions, and if at least one of them is fully
anonymous, that is sufficient for not being able to correlate that
action back to a given entity. [The slide stated that if there are
two anonymous actions, they cannot be correlated back to "A".]
There was some discussion between Eric Rescorla, Erik Nordmark, and
Rajeev Koodlin about the relationship between anonymity and
unlinkability, mainly whether unlinkability is a sufficient
condition to anonymity and whether anonymity implies
unlinkability. Rejeev stated that he might want to unlinkability
but not anonymity. Erik replied that if any of your acts can be
linked back to your identity, your identifier sets become
linkable.
Hesham Soliman asked if type of service is supposed to be private,
and Erik replied that one may not want to disclose that he or she
has gold service.
Proposed Scope for the planned work
Pekka Nikander presented a few slides on the proposed scope.
Basically, the idea is to focus on making identifiers unlinkable,
thereby achieving some level of anonymity or pseudonymity towards
third parties.
- Rajeev Koodli:
- Doesn't this presume we understand what
unlinkability actually is, and that you know a solution to
unlinkability, and how these could be fitted into existing
protocols.?
- Pekka Nikander:
- Personally, I think we do. There are
already two solutions; I think we roughly know how to solve the
issues (but I may be wrong).
- Rajeev:
- This should be done into the existing groups.
- Alper Yegin:
- Is there's a limitation on the kind of
identifiers we are dealing with
- Pekka:
- That is to be discussed.
One example approach
Pekka Nikander presented one potential solution approach, presented
previously at the 2005 Cambridge Security Protocols workshop. He
also noted that there may be IPR issues with the
approach.
The basic idea of the presented approach is to replace constant
identifiers with jointly agreed pseudo-random sequences of
identifiers. The first paper in the area was presented already in
1977, but the work has gained new interested only recently.
- Hesham Soliman:
- These set of IDs would need to be
exchanged at the beginning
- Pekka:
- Yes.
- Hesham:
- It is matter to exchange the initial seed value?
- Pekka:
- Yes. We expect to use a kye management protocol.
- Hesham:
- Could this apply to IP addresses as well. What
about collisions with IPv6
- Pekka:
- Yes, in theory you can apply this to IPv6
address, too. You don't care about collisions there, you just
move on to the next ID set.
- Hesham:
- To bootstrap the relationship, you would need to
use an identifier that can be semi-permanent. Will that kill the
scheme.
- Pekka:
- Not necessarily, you have identity protection with HIP
or possibly with IKEv2; see the BLIND paper given in the
references.
- Eric Rescorla:
- What is the threat model? In v4, you
can't blind the IP address, so blinding everything else doesn't
buy that much.
- Pekka:
- Yes, in v4 this would probably require to change
the way you use the IP addresses. What I presented is an one example
of the solution space we could explore.
- Eric:
- I'd like to ask that the next speaker be more
explicit about the threat model.
- Greg Daley:
- Work on changing existing protocols can be
pushed back to their WGs. But, with a model like this, you could
have a single session between two hosts that would protect all
concurrent sessions; a privacy bootstrap protocol. That may be a
worthwhile work item.
- Pekka:
- Quite a lot depends on your definition of
protocols: perhaps you don't change packet format, just the way
the state in end-nodes is used.
- Alper Yegin:
- Can you explain againk how does the
implicit origin authentication work?
- Pekka:
- Only the sender and receiver knows the random
sequences. If there is enough entropy in the changing
identifiers, it is very unlikely that another entity is able to
generate the same sequence.
- Alper:
- But it doesn't really secure the contents of the
all packets.
- Pekka:
- Right, it's not really true security in that
sense.
- Glen Travers:
- You talk about no extra bits and
zero-signalling mobility, but wont't this generate extra traffic?
- Pekka:
- You are right. In practice it will.
- Rajeev Koodli:
- You still need to run return routability,
on something that is routable. This implies it's not exactly
zero-signalling.
- Pekka:
- Yes, you are right.
- Rich Draves:
- So there is extra bits on the wires. So is
there is anything revealed to the receiver of the spurious ACKs?
- Pekka:
- I'm not sure but I think not. I would need to
look at that more.
MIPv6 Privacy Extensions
Gabriel Montenegro presented another example approach, dealing with
Mobile IPv6.
- Hesham Soliman:
- If you do RO, you still get the TMI
- Gabriel Montenegro:
- Yes the TMI is an index to the encrypted HoA.
If you are a server, yes you can't hide your home address, it's too late
to hide it.
- Hesham:
- Can a server avoid revealing much of its
identity? no hang on, that's probably not doable.
- Rajeev Koodli:
- There where few proposal to address that
in the past, how to mask HoA.
- Gab:
- Yes, this one example of known techniques.
- Rajeev:
- How can you recover the HoA from the
pseudo-identifier? We've looked at this... you still need to run
return routability on the original HA.
- Gab:
- Remember that TMI is not routable, structurally so.
- Nico Williams:
- It seems the first proposal could work
very well in open networks.
Trade-offs between anonymity and identifiability
Bob Hinden led a brief discussion about some of the tradeoffs
involved.
- Steve Bellovin:
- Who is enemy, what is the threat model?
Examples with SPAM, DoS is not about IP address forgery.
- James Kempf:
- We don't actually have a threat
analysis.
- Hesham Soliman:
- I share Bob's concerns. But, if there is
a negotiation, people could choose not to use a service if anonymity
is not possible.If you allow resource allocation, what is the impact
of that and the updates during sessions.
- Bob Hinden:
- I have no answers; I just think the WG needs
to think about these questions
- Raj Patil:
- Anonymizing identity is one thing, Pekka
mentioned that regulations will mandates that. There is more needs to
maintains identity as per other regulations, than to anonymize
it.
- Pekka:
- That tends to depend on the environment, but yes.
Threats to lower layers
Wassim Haddad discussed the current draft about lower layer thread
model.
Lower layers problem statement
Erik Nordmark presented the current draft concerning the problems
perceived to exist w.r.t. unlinkability at the IP layer and
below.
Reconstructing the following piece of discussion was hard due to
the big differences between the two sets of notes. The main points
seemed to be the following:
- It is possible to fingerprint radios based on the RF signals;
consequently, hiding the MAC doesn't help much unless you also
consider bridging.
- In most access networks you still need to give your identity
to the AAA server; consequently, there are potential problems
with EAP in this space.
- Changing MAC addresses might still be useful against
resource-constrained eavesdroppers.
- Rajeev Koodli:
- CoA disclosure out of scope? [Yes]
- Eric Rescorla:
- I think we're concentrating on locator unlinkability.
- Rajeev:
- Mipv6 has been looking at this.
- Eric:
- Are you assuming the only access the attacker has
to wireless traffic is through the MAC interface? If they can
fingerprint your radio, there is no point hiding the MAC
address.
- Eric Rescorla:
- When you authenticate at a link, don't
you give your identity to the RADIUS server anyway?
- Steve Bellovin:
- Yes...
- Erik Nordmark:
- Right, so let's keep it in mind
- Hesham Soliman:
- Today they know which phone device you have.
- Erik:
- But there is temporary IMSI, TMSI
- Hesham:
- TMSI is used only after authentication
- Christian Huitema:
- On hot-spots, you anyway to pay so
you need to be identified. You might change your MAC address as often
as you want but it doesn't help
- Erik:
- Unless you have many credit cards.
- Alper Yegin:
- In some mode, the MAC address is not in
the frames in .16, only seen on the air when you authenticate, and you
might even hide them during authentication. So there's not that much
concerns with the fact that .16 addresses appears in
certificates.
Open mikes discussion
(Discussion continues, notes again agreeing.)
- Rajeev Koodli:
- It's good to look at unlinkability and
pseudonimity aspects. I'd like to make the distinction between
location privacy with IP addresses in general, and IP addresses as
used by MIP (i.e. HoA, and CoA).
- Sam Hartman (AD):
- Before we discuss about the approach,
let's make sure we understand the problem.
- Pekka:
- I'll ask two questions: Do we understand
the narrow problem of unlinkability, and then which approach to
follow: wider or more focused.
Unconclusive hums about understanding the problem.
- Alper Yegin:
- Still don't have a clear boundary for this.
My main concerns is about scope, and which layer coordination
issues go. I still don't have a clear boundary where we are going
to stop this work. Also about L2. I think we need to further
discuss the scope.
- Sam Hartman:
- There is jabber discussion saying that we
don't understand WHAT problem we are trying to solve.
- Pekka Nikander:
- That's why I think there may be a need
for a research group. But it also seems like there may be smaller
issues that can clearly be attacked in existing contexts. First
I'd want to discuss about the approach : what work to solve in the
WG, and what in other fora.
- Steve Bellovin:
- I don't think we don't understand even
the basics well enough because there are so many possible
variants. We don't understand what we're trying to protect
against well enough. There are things for individual groups,
clearly. A research group might be good, but working
group... When I was AD I tried to have people write RFC about what
guidelines and introduce a privacy considerations requirement for
documents, but it did not succeed. But save a focused group until
we have a clear idea. A WG should exist to solve a narrow
problem.
- Christian Huitema:
- What/who are we protecting against?
Are you protecting against neighbors , ISPs, .... I don't believe
a research group will be that useful. What would be useful would
be to develop a threat model. You can do as much RGs as you want,
that's what researcher do.
- Bob Morgan:
- I'd certainly say we don't understand
anything... for a WG. There's been work on pseudonymous
identifiers around, but not in IETF. I support the RG
concept.
- Raj Patil:
- Who exactly is asking that there is a need
for such privacy? And about MAC address problem: it is IEEE
business, not IETF.
- James Kempf:
- So you're asking who is the customer for
privacy.
- Raj:
- Exactly.
- Hesham Soliman:
- First an RG is fine, good idea. We would
need a holistic approach along Pekka's proposal, but I don't think
we're anywhere near that. Almost need a survey of all protocols,
and make sure that everyone understands this, and design like that
for a long period, otherwise one small feature of one new protocol
can break the whole thing. Maybe we need to look at where the
holes are. What is the impact of that, or to allow such
scheme. If we have a Privacy consideration in RFC that would help
to reach a common understanding of what are the problems.
- Greg Daley:
- I agree that we need to have a very narrow
scope for a WG. There is still a need for this sort of thing. We
have existing protocols that expose the identifiers in various
places. Things like MIP do not provide unlinkability. The are
customers for existing protocols, but it is not the full
solution. We might get advice on what not to do in the short time.
It would also be nice to have some guidance from the IAB as to
what we know now.
- John Loughney:
- I hummed no [to the question of whether
we understand the problem]; we need to better understand what we
are trying to solve. Guidelines and gap analysis is premature.
- Gabriel Montenegro:
- I like the idea of having privacy
considerations in RFC. In terms of a security area WG, I like the
idea of people working on this. An IAB workshop inviting people
who might be customer of this might be good, for example, people
like European policy makers. People that understand what are the
problem might provide us a starting point to look for technical
solutions. Then get clear idea of who customers are etc.
- Raj Patil:
- A RG makes a lot of sense. Once there are
documents coming out of that, we might understand better. That
might be a good time to have a workshop. The issue for MIP6 is
addressed right now in the WG, and the scope is limited.
- Alper Yegin:
- Bob Hinden's presentation has many
questions, that need to be analyzed before we move forward.
- Hesham Soliman:
- I don't think we should invite policy
makers because they are the people we try to hide from, they are
not the real customers.
- Rajeev Koodli:
- Fine with RG. Workshop seems like a good
idea, too, modulo attendee list.
- Leslie Daigle [wearing the IAB chair hat]:
- Sounds like
there could be the basis for an RG, also conceivable that an IAB
workshop might come of this, however focus may be an issue. Needs
to have a well framed and scoped proposal so that there is chance
of producing useful output, or an IAB workshop won't work. There
are also many (practical) steps between thinking of a workshop
idea and having one -- so if a workshop doesn't follow, this group
should not be completely unwarned. In terms of the suggestion
about IAB guidance, the IAB doesn't hand down guidance from on
high -- workshops are indeed our most common form of work. In
terms of forming an RG -- the word should be "propose" an RG, not
"form" an RG -- you are welcome to poll this room to guage
interest in, and proposal for an RG, but it's input to the RG
creation process.
- Pekka Savola:
- Do you think that a threat model belongs
to the IRTF or should that be elsewhere?
The discussion was followed by a number of questions to the room:
- Do you think we should try to identify and analyze the problem
[better than what we have done so far]? Yes.
- Should we propose forming an IRTF Research Group in this space?
Yes.
- Who are willing to work on an RG, and write documents? Steve
Bellovin, Alper Yegin, Francis Dupont, Wassim Haddad, Pekka
Nikander, James Kempf, others
- Who are willing to work towards a workshop? Steve Bellovin,
Alper Yegin, Rajeev Koodli, Gabriel Montenegro, Pekka Nikander,
James Kempf; maybe others.
- Nico Williams:
- Who is the customer and who is the
implementer?
- Steve Bellovin:
- Threat model is topic #1 for the
proposed RG, not for 8 minutes now. Too big.
- Thomas Roessler:
- Part of this will be
influenced by regulations, public policy. We should not go to far
with threat model documentation before the workshop. There will
be feedback. There are W3C groups looking at some related areas
too.
- Unknown speaker:
- Workshop first is a good idea, since
there can be inconsistent legal requirements.
|