Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

From: Richard Barnes <[email-masked]>
Date: Mon, 6 Jan 2014 21:24:18 -0500

Dear PERPASS,

Stephen asked me to take a stab at a problem statement for PERPASS.  With
some help from Bruce, Cullen, and Ted, the results have just been published
as draft-barnes-pervasive-problem-00.

In general, this draft tries to outline at a technical level what we mean
by pervasive attack, and what the high level mitigations are.

Comments welcome!

Thanks,
--Richard

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <[email-masked]>, Ted Hardie <[email-masked]>,
Bruce Schneier <[email-masked]>, Richard Barnes <[email-masked]>

A new version of I-D, draft-barnes-pervasive-problem-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-pervasive-problem
Revision:       00
Title:          Pervasive Attack: A Threat Model and Problem Statement
Document date:  2014-01-06
Group:          Individual Submission
Pages:          23
URL:
http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt
Status:
https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/
Htmlized:       http://tools.ietf.org/html/draft-barnes-pervasive-problem-00

Abstract:
   Documents published in 2013 have revealed several classes of
   "pervasive" attack on Internet communications.  In this document, we
   review the main attacks that have been published, and develop a
   threat model that describes these pervasive attacks.  Based on this
   threat model, we discuss the techniques that can be employed in
   Internet protocol design to increase the protocols robustness to
   pervasive attacks.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Lambert <[email-masked]>
Date: Mon, 6 Jan 2014 18:49:41 -0800

> Comments welcome!

Nice work!

Minor comment - don't see any text on L2 wireless tracking.  All of our wireless devices effectively beacon our location and identity (e.g 802.11 MAC addresses and probing). While not strictly a IETF domain of work (L2), the solutions to this class of problems do require changes in IETF protocols.

Paul

From: perpass [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, January 06, 2014 6:24 PM
To: perpass
Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

Dear PERPASS,

Stephen asked me to take a stab at a problem statement for PERPASS.  With some help from Bruce, Cullen, and Ted, the results have just been published as draft-barnes-pervasive-problem-00.

In general, this draft tries to outline at a technical level what we mean by pervasive attack, and what the high level mitigations are.

Comments welcome!

Thanks,
--Richard

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Ted Hardie <[email-masked]<mailto:[email-masked]>>, Bruce Schneier <[email-masked]<mailto:[email-masked]>>, Richard Barnes <[email-masked]<mailto:[email-masked]>>

Name:           draft-barnes-pervasive-problem
Revision:       00
Title:          Pervasive Attack: A Threat Model and Problem Statement
Document date:  2014-01-06
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-barnes-pervasive-problem-00.txt
Status:         https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/
Htmlized:       http://tools.ietf.org/html/draft-barnes-pervasive-problem-00

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Richard Barnes <[email-masked]>
Date: Mon, 6 Jan 2014 22:01:03 -0500

> Nice work!
Thanks!

Minor comment – don’t see any text on L2 wireless tracking.  All of our
> wireless devices effectively beacon our location and identity (e.g 802.11
> MAC addresses and probing). While not strictly a IETF domain of work (L2),
> the solutions to this class of problems do require changes in IETF
> protocols.
>

I also wonder to what degree this is a "pervasive attack" issue.  If the
attack involves being physically close to the victim, it's hard to see how
the attacker would achieve a pervasive scale.

What sorts of changes to IETF protocols are you imagining?

--Richard

>
>
> Paul
>
>
>
>
>
> *From:* perpass [mailto:[email-masked]] *On Behalf Of *Richard
> Barnes
> *Sent:* Monday, January 06, 2014 6:24 PM
> *To:* perpass
> *Subject:* [perpass] Fwd: New Version Notification for
> draft-barnes-pervasive-problem-00.txt
>
>
>
> Dear PERPASS,
>
>
>
> Htmlized:
> http://tools.ietf.org/html/draft-barnes-pervasive-problem-00
>
>
> Abstract:

---

From: Watson Ladd <[email-masked]>
Date: Mon, 6 Jan 2014 19:08:22 -0800

On Mon, Jan 6, 2014 at 6:24 PM, Richard Barnes <[email-masked]> wrote:
> In general, this draft tries to outline at a technical level what we mean by
> pervasive attack, and what the high level mitigations are.
>
> Comments welcome!

Minor quibble:
Intermediate nodes can also be active attackers, e.g. an ISP could
insert fake email for its customers.

At a higher level this draft feels overly removed from the real
problem: users assumptions about what is
public on the Internet have frequently been violated, even when
technical measures to address these issues
exist. This gets mentioned in passing, but should be front and centre.

The NSA is not the only organisation doing this: Saudi Arabia, the UK,
China, Ethiopia, France all have major monitoring
systems in place that can only work because of how weak the core
protocols of the internet are against manipulation. (And let's not
forget the
Pakistani ISP that accidentally knocked Youtube offline)

Also, BGP tricks mean that anyone can be local.

The point should be very simple: no more cleartext, authenticate
everything, limit authority, and produce an audit trail for when
things go wrong.
Now let's see if we can do more about it than the CRYPTO '13 rump
session accomplished.[1]
Sincerely,
Watson Ladd
[1] For those who are unfamiliar:
http://www.youtube.com/watch?v=cVUIk6nXVcw is the best statement of
the issue and the solution.
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Richard Barnes <[email-masked]>
Date: Mon, 6 Jan 2014 22:41:45 -0500

> insert fake email for its customers.

Clearly, anyone on-path can be an active attacker.  And, as some of the
TOR-related revelations show, some off-path entities as well.

> exist. This gets mentioned in passing, but should be front and centre.

That seems like it might be a better topic for
draft-farrell-perpass-attack.  We're trying to stick to technical things in
this draft, so "user assumptions" are kind of out of scope.

> Pakistani ISP that accidentally knocked Youtube offline)

Indeed.  We cite the Great Firewall as an example.

(And technically, that Pakistani ISP didn't accidentally knock YouTube
offline; the only accident was knocking YouTube offline *outside* *of*
*Pakistan*.)

> Also, BGP tricks mean that anyone can be local.

s/local/on-path/

> everything, limit authority, and produce an audit trail for when

That seems like a concise statement of the mitigations discussed in Section
5.
<http://tools.ietf.org/html/draft-barnes-pervasive-problem-00#section-5>

We can try to make that message clearer in future versions, though.

Thanks,
--Richard

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 07 Jan 2014 08:15:28 +0100

Richard Barnes <[email-masked]> wrote
Mon, 6 Jan 2014 22:01:03 -0500:

| I also wonder to what degree this is a "pervasive attack" issue.  If the
| attack involves being physically close to the victim, it's hard to see how
| the attacker would achieve a pervasive scale.

An attacker could control a large number of "home routers".

Do we need stronger indications that's actually being done at a large
scale before we consider strengthening L2 protocols and best practices?
If so, what is "large scale" and "pervasive"?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Jan 2014 14:05:23 +0000

Richard et al.

Many thanks for getting this out. I think its a fine start.

I guess one thing to check is whether this captures all of
the significant points from the various other "problem
statement" contributions.

Ta,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jan 2014 15:39:06 +0100

Hi Richard, Bruce, Cullen, and Ted,

Thanks for this draft.  I wonder if it would be useful to create an
additional table on what can be classified, and at what point.  So for
instance:

     Layer         Field        Risk
   =============================================================
          L2    |  src/dst |  correlation of physical device
                |          |  and IP address
                |          |	
     IP Layer   |  src/dst |  rough correlation with location
                |          |  and identity, with hints as to
      	      	|          |  services being used
              	|          |  (e.g., movies.example.com)
     Transport  |  port#   |  correlation of activity based on
                |          |  transport	service	field
                |          |	
   ============================================================

This makes it clear that it's not just the application data that is
desired.  You of course say as much in the draft.

It's good that you talk about aggregation.  There is an inherent tension
between use of aggregation to blind or blur, and the risk of the
aggregating device being managed by a witting or unwitting
collaborator.  We have at least some evidence that this has happened.

And all of this must be put into the context of other threats against
which it must be balanced (e.g., phishing, spam, etc) where encryption
can defeat the existing remediations.

Finally, several comments about overlay routing, such as TOR.  As I
think Bruce you yourself pointed out, if a small subset of people make
use of it, they make themselves targets.  Additionally bandwidth isn't
free, and neither is delay.  Stretch in the routing system matters.  A
fundamental issue here is who can do an effective job of anonymizing IP
addresses at the size and scale of the Internet.

Eliot

On 1/7/14 3:24 AM, Richard Barnes wrote:
> Dear PERPASS,
>
> Stephen asked me to take a stab at a problem statement for PERPASS.
>  With some help from Bruce, Cullen, and Ted, the results have just
> been published as draft-barnes-pervasive-problem-00.
>
> In general, this draft tries to outline at a technical level what we
> mean by pervasive attack, and what the high level mitigations are.  
>
> Comments welcome!
>
> Thanks,
> --Richard
>  
>
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: Cullen Jennings <[email-masked] <mailto:[email-masked]>>, Ted
> Hardie <[email-masked] <mailto:[email-masked]>>, Bruce
> Schneier <[email-masked] <mailto:[email-masked]>>,
> Richard Barnes <[email-masked]>
>
>
>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 7 Jan 2014 13:52:50 -0800

Hi Richard,
Minor comment – don’t see any text on L2 wireless tracking.  All of our wireless devices effectively beacon our location and identity (e.g 802.11 MAC addresses and probing). While not strictly a IETF domain of work (L2), the solutions to this class of problems do require changes in IETF protocols.

I also wonder to what degree this is a "pervasive attack" issue.  If the attack involves being physically close to the victim, it's hard to see how the attacker would achieve a pervasive scale.
MAC address are readily picked up by any hotspot, mobile device, or by special monitoring devices.  Commercial systems already exist to aggregate, track and identify people based on unique identifiers in our radio transmissions.

A fun example is the Renew Orb (a trash can that tracks people):
   http://renewlondon.com/2013/06/renew-release-results-of-smartphone-data-capture/
In one week, 7 trash cans were able to track 530M devices.

I’ve seen larger system solutions for sale suitable for country-wide analysis at a security conference in Singapore a few years back …

What sorts of changes to IETF protocols are you imagining?
Most of the work is IEEE related.  Impacts to IETF protocols might include:
 - IP address assignment and IPv6 usage of MAC address
 - authentication protocols/framework to bind ephemeral MAC address to
   longer term identity
 - RADIUS/EAP usage changes

Paul

--Richard

Paul

From: perpass [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Monday, January 06, 2014 6:24 PM
To: perpass
Subject: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

Dear PERPASS,

Comments welcome!

Thanks,
--Richard

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jan 6, 2014 at 9:17 PM
Subject: New Version Notification for draft-barnes-pervasive-problem-00.txt
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Ted Hardie <[email-masked]<mailto:[email-masked]>>, Bruce Schneier <[email-masked]<mailto:[email-masked]>>, Richard Barnes <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Stefan Winter <[email-masked]>
Date: Wed, 08 Jan 2014 07:52:08 +0100

Hi,

>     I also wonder to what degree this is a "pervasive attack" issue.  If
>     the attack involves being physically close to the victim, it's hard
>     to see how the attacker would achieve a pervasive scale.
> 
> MAC address are readily picked up by any hotspot, mobile device, or by
> special monitoring devices.  Commercial systems already exist to
> aggregate, track and identify people based on unique identifiers in our
> radio transmissions.  

Another attack vector is the routing of RADIUS authentication requests
for enterprise WiFi. The client device's MAC address is transported in
the clear inside the RADIUS attribute Calling-Station-Id; so if your
RADIUS server is "somewhere on the internet" (e.g. if you are part of a
roaming consortium and send your authentication traffic via a off-site
clearing house) then anybody who happens to listen on the wire learns
about those MAC addresses and the associated user identity (or at least
the realm he comes from, if the end user was mindful enough to configure
identity privacy on his device).

Partial mitigations for that are possible; RADIUS/TLS for example makes
the clear-text transmission on IP level go away; but the fact that the
clearinghouse gets to see all traffic does not go away with that.

You should read
https://tools.ietf.org/html/draft-wierenga-ietf-eduroam-01 section 3.5 -
this issue is discussed in some detail there.

A partial solution that may make some clearing houses go away is direct
dynamic discovery of RADIUS servers as per
https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/
which can (but does not necessarily always) bypass central clearing houses.

In short: MAC addresses are NOT necessarily local to the LAN; if they
leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols
that transport information about MAC addresses on the layers above are
most certainly IETF work.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Jan 2014 07:59:53 +0100

> most certainly IETF work.

Indeed.  Mac addresses are also found in location registrations for some
services.

Eliot

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Jan 2014 03:08:25 -0500

On Jan 07, 2014, at 02:15, Linus Nordberg <[email-masked]> wrote:

> If so, what is "large scale" and "pervasive”?

I’m in the camp that we don’t.

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Jan 2014 11:32:07 +0000

> Indeed.  Mac addresses are also found in location registrations for some

And even, horribly, in the DNS [1] - which is one of
those "better to document than ignore" things.

S.

[1] http://tools.ietf.org/html/rfc7043

---

From: joel jaeggli <[email-masked]>
Date: Wed, 08 Jan 2014 09:04:40 -0800

> those "better to document than ignore" things.

In both cases the scope in which their appropriate to use is germaine.
If you do layer-2 authentication or resource allocation it would seems
likely that you would collect and store layer-2 identifiers for future
use. DHCP servers do this also.

Should this information (L2 binding to some upper layer information) be
exposed to applications that don't need the L2 binding? I don't think so.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jan 2014 09:05:13 -0800

> Indeed.  Mac addresses are also found in location registrations for some

Some?  Virtually all in fact.

It's mostly due to the prevailing attitude in that community (likely
others), that not sending something could represent a lost opportunity
in the future where the cost of doing so is considered trivial.  That
cost assessment is one we need to influence if we're going to make any
sort of real impact on this problem.

And by we, I don't think that this is something the IETF can
realistically do anything about, except by a sort of osmosis.
Technically, there are no measures that can be deployed against that
sort of meme.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Jan 2014 10:02:56 -0800

>> most certainly IETF work.

So Š this year as we introduce Œephemeral MAC addresses¹ into 802.11.
The IETF should be prepared to fix upper layers as they break :-)

The simplest change is for hourly or daily changes of a link local MAC
address.
This breaks the long term tracking and any usage of MAC address for
authentication.

Longer term, the ephemeral address could be bound to an authentication
process.
My favored key centric approach would be

mac_address = h(pk, nonce)[:6] | 0x800000000000 # upper 6 octets with
bitwise to set link local

Paul

---

From: Stefan Winter <[email-masked]>
Date: Thu, 09 Jan 2014 07:53:27 +0100

Hi,

> The simplest change is for hourly or daily changes of a link local MAC

What a wonderful idea. IEEE 802.1X authenticates sessions by MAC
address. If you change it while you are in an authenticated session,
you'll be kicked off the net instantly.

> Longer term, the ephemeral address could be bound to an authentication

That is what IEEE 802.1X does today. It binds the current session,
identified by MAC address, to a user identity, identified by an EAP
credential.
Its only requirement is that the MAC address remains unchanged during
the session. However ephemeral the MAC address may be, it should survive
a session, independent of the session duration.

> bitwise to set link local

In eduroam, we do see people changing their MAC address *between*
sessions, and that's know to work. I don't know or care about their
algorithms. Their motivation is to get around "fair use" capping which
some hotspots may have in place. Change MAC, change outer EAP identity,
and you'll appear as a "brand new" user. That is one of the reasons why
we introduced the use of Chargeable-User-Identity (CUI, RFC4372) for our
authentications. CUI can be implemented in a way which prevents tracking
(by hashing the CUI including the Operator-Name attribute, so that
different hotspots get different CUIs for the same user).

I think I can say with some confidence that RADIUS and EAP won't "break"
if MAC addresses change. The change should happen in a sane moment
though to avoid session disruption.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473