Anonymous Identifiers (ALIEN) BoF

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:

1. Do you think we should try to identify and analyze the problem [better than what we have done so far]? Yes.
2. Should we propose forming an IRTF Research Group in this space? Yes.
3. Who are willing to work on an RG, and write documents? Steve Bellovin, Alper Yegin, Francis Dupont, Wassim Haddad, Pekka Nikander, James Kempf, others
4. 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.