Subject: [Mobopts] Privacy BoF Proposal

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Jun 2005 13:37:11 +0300

All,

Please find below our initial proposal for a privacy BoF in Paris.
If you have time to review it and give comments, please do it within
a next few days.  I intend to submit it to the IESG early next week.

--Pekka

Anonymous Identifiers BOF (ALIEN)
=================================

August, 2005
------------

Name:                Anonymous Identifiers (ALIEN)
Area:                Internet
Conflicts:           TBD
Expected attendance: 100-200
Special requests:    none
Number of Slots:     one
Timeslot:            2 hours and 30 minutes

Chairs:              TBA

AGENDA:
------
  5 min   Agenda bashing                               Chairs
  5 min   Goal and purpose of the BOF                  Chairs
25 min   Other presentations, to be confirmed         TBD
10 min   Lower layers problem statement               TBA
10 min   Lower layers threat model                    TBA
60 min   Open Discussion                              All

DESCRIPTION:
------------
Privacy is becoming a more pressing issue in the Internet architecture.
There are several reasons to this, including new or proposed 
legistlation
in various countries, the Internet becoming more ubiquitous and mobile,
and changes in people's expectations.  Furthermore, it must be 
understood
that different people mean different things with network privacy, and 
that
there are huge cultural differences with respect to privacy expectations
between various countries.

The purpose of this BOF is twofold:

1. To initiate serious long term discussion on privacy within the
    community.    One possible outcome of this would be chartering
    of a privacy research group at the IRTF.

2. To initiate work on the more short term needs related to the IP
    layer, including problems related to IP-layer mobility and
    multi-homing solutions.  It remains to be determined whether this
    work should happen within an existing working group, split among
    a number of existing working groups, or whether a new working
    group should be formed.

The focus of the proposed work will be on protecting communicating
parties' privacy against eavesdroppers and other third parties.
Location privacy in the sense of keeping location related information,
such as the IP address, of a mobile party private from the other party
is out of scope.  However, location privacy in the sense of keeping a
given mobile user's location related information private from such
parties that the user is not actively communicating with falls within
the proposed scope.

MAILING LIST:
-------------
[email-masked]

To subscribe, visit http://lacnic.net/mailman/listinfo/momipriv

BACKGROUND:
-----------

While privacy is a multifaceted phenomenon with many different 
definitions
of what it exactly means.  Obviously, in this work the aim is to focus 
on
privacy issues in Intenet protocols and architecture, including all
protocols from sub-IP to application layers.  A basic approach in
addressing privacy in protocols is unlinkablity, denoting that an
eavesdropper is unable to link together identifiers and other data with
the aim of tracking the behaviour, location, and other sensitive
information about a user.

A more pressing need faces the IP and the layers below it.  The IETF has
developed and is still working on a various multi-homing and mobility
solutions.  These solutions aim to target various goals, including
keeping ongoing sessions alive while switching between different IP
addresses.  Introducing an identifier that remains stable even though
underlying IP addresses (i.e., locators) change is an important building
block.  However, the currently standardized and proposed mobility and
multi-homing solutions allow eavesdroppers and correspondent nodes to
easily identify, locate, and trace nodes in a mobile and multi-homed
environment.

Among these pieces of information, the IP and MAC addresses are the most
valuable source since they can easily enable a malicious party to 
identify
and locate its victim.  Once the target is discovered, the eavesdropper
can monitor the interaction aken by the entity using these locators /
identifiers and use this information as input to other profiling tools
in order to collect more information related to the victim's activities
and locations in real time.   Whenever these actions are possible, they
constitue a serious violation of the target's privacy.

As argued in input documents, addressing these privacy issues, 
separately
on the IP and MAC layer is insufficient especially that it does not take
the unlinkability aspect into account. Hence a solution, which addresses
the anonymity and unlinkability at both layers and takes into 
consideration
the synchronisation problem between them is needed.

In addition to low layers identifiers, the transport and application 
layers
can also provide information, which can be used for identifying and 
tracking
purposes, especially when combined with data gathered on lower layers. 
Based
on that, addressing anonymity and unlinkability issues at all layers is
required also for the long term goals.

The ALIEN BoF aims to discuss a recommendation for the IESG and the IAB 
to
charter related work at the IETF and the IRTF.

Drafts:

   draft-haddad-momipriv-problem-statement-01.txt
   draft-haddad-momipriv-threat-model-00.txt

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Jun 2005 10:30:08 -0700

Hi Pekka,

The agenda looks a little thin at the moment. The description is fine, but
one thing I think the BOF needs to discuss is privacy as an architectural
issue rather than a strictly protocol design issue. That is, I think that
each individual protocol needs to approach privacy in a way that is
appropriate for the design of that protocol, but that there are likely to be
some architectural guidelines that would be useful for all protocols and one
could, for example, put together a document that would describe those
guidelines ("Architectural Guidelines for Privacy in Internet Protocol
Design" or something like that).

One area that I think might be somewhat questionable is including sub-IP
layer protocols that are not IETF designed (PPP for example or MPLS would be
OK to cover, since they are IETF designed). We could come up with some
requirements from the IP standpoint about privacy that could then be
propagated to the various standardization bodies that control these
protocols, but anything in the design space here would probably be better
done in the appropriate standardization body.

            jak

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Wassim Haddad ((QA/EMC))" <[email-masked]>;
"Rajeev Koodli" <[email-masked]>; "IAB" <[email-masked]>
Sent: Wednesday, June 22, 2005 3:37 AM
Subject: Privacy BoF Proposal

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Jun 2005 10:44:01 -0700

Rajeev,

> The distinction between Location Privacy and Privacy itself is important
> enough to merit some discussion. "Privacy across layers" is a broader
topic
> that primarily addresses profiling of user communication (involving
> multiple identifiers).
>  From the first sentence of the above paragraph (and from the
> description below), I
> understood that ALIEN will focus on just that. And, it is worthwhile IMO.
> The problem of Location Privacy as applicable to _IP_ Mobility is
primarily
> concerned with managing disclosure of IP addresses. It is a narrower
> problem.

Actually, I think one can make an even further narrowing of scope, and that
is location privacy applied specifically to the Mobile IPv6 protocol. As I
believe you have pointed out, there are already several similar solutions
for this, and so it is probably better to pursue these in Mobopts and MIP6.

This gets back to the point I was trying to make about privacy as an
architectural v.s. a protocol design issue.

> And, MobOpts RG has been looking into that, and there are already
solutions
> available. So, I am inclined to suggest that Location Privacy should not
be
> the focus of ALIEN to avoid confusion and to foster progress and good
> will.  :-)
> I am hopeful that emerging techniques to thwart profiling are also
> useful for nodes
> concerned with Location Privacy.
>

I think location privacy as an architectural issue should be included, but I
think that any protocol solutions should be excluded. For example, there may
be location privacy issues with HIP or Mobike, or even with SIP, that would
need to be addressed in the respective working groups. As far as I know,
they aren't, and some architectural work might help these WGs to turn some
focussed attention on their particular protocols.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 22 Jun 2005 10:34:02 -0700

Hi Pekka,

thanks for bringing this up. I have few comments in-line.

>    of a privacy research group at the IRTF.
This would be worthwhile (necessary?), especially given the breadth of 
topics you
are hoping to address. It is not clear to me if you need a BOF to start 
an IRTF RG
however :-)

>    a number of existing working groups, or whether a new working
FYI: MobOpts is already looking into Location Privacy due to IP Mobility.
More on this below..

The distinction between Location Privacy and Privacy itself is important
enough to merit some discussion. "Privacy across layers" is a broader topic
that primarily addresses profiling of user communication (involving 
multiple identifiers).
 From the first sentence of the above paragraph (and from the 
description below), I
understood that ALIEN will focus on just that. And, it is worthwhile IMO.
The problem of Location Privacy as applicable to _IP_ Mobility is primarily
concerned with managing disclosure of IP addresses. It is a narrower 
problem.
And, MobOpts RG has been looking into that, and there are already solutions
available. So, I am inclined to suggest that Location Privacy should not be
the focus of ALIEN to avoid confusion and to foster progress and good 
will.  :-)
I am hopeful that emerging techniques to thwart profiling are also 
useful for nodes
concerned with Location Privacy.

Regards,

-Rajeev

> of what it exactly means.  Obviously, in this work the aim is to focus on
> As argued in input documents, addressing these privacy issues, separately
> The ALIEN BoF aims to discuss a recommendation for the IESG and the 
> IAB to

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 22 Jun 2005 11:14:33 -0700

Hi Jim,

>focussed attention on their particular protocols.
I was commenting on the proposal for which you have added the 
"architectural"
viewpoint.. IMO, we lack a consensus on what privacy means. So, my steps 
would
be:

1. Have folks talk about what privacy means. The result should be a problem
    definition folks have consensus on.
2. Identify what could be done. This would be a "framework" or 
"architecture" sort
    of discussion if my understanding of the breadth of the problem is 
even partially accurate.
3. Identify specific protocol interactions. And, take them to respective 
IETF WGs or spin out
    new ones if there is interest.

Location Privacy is more to do with disclosing identifiers to both 
on-lookers and
(unacquainted) correspondents. As such, I agree it also belongs in the 
"architecture"
discussion, but I am not sure if ALIEN is shooting itself for that. 
Location Privacy with
Mobile IPv6, as we agree, is an even narrower problem which we are 
considering in
MobOpts.

-Rajeev

ps: BTW, if anyone is interested in the extended version of our paper on
     Location Privacy with IP Mobility for Securecomm 2005, let
     me know.

---

From: Clint Chaplin <[email-masked]>
Date: Wed, 22 Jun 2005 11:58:26 -0700

Excuse my ignorance, but is this an IRTF or an IETF group proposal?

-- 
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager