Subject: Re: [perpass] IAB security/privacy programme PM draft

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 07 Oct 2014 12:35:17 -0400

As the showrunner for the confidentiality effort in the IAB privacy
and security program, please do share your feedback with us. We are
also contemplating a companion document on mitigations for the threats
outlined in the threat model.

best, Joe

On 9/15/14, 10:56 AM, Stephen Farrell wrote:
> 
> Hi all,
> 
> Richard and a few folks started work on documenting a problem 
> statement [1] some time ago. As I think was stated here before it
> seems like a good plan for that to be progressed as part of the
> IAB's re-factored security/privacy programme. So Brian Trammell has
> picked up the pen and pushed out [2].
> 
> Comments very welcome (I've still to read it myself so will send my
> comments here too when I've had a chance),
> 
> Cheers, S.
> 
> 
> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2]
> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat
>
>  _______________________________________________ perpass mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/perpass
> 

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Paul Lambert <[email-masked]>
Date: Tue, 7 Oct 2014 10:45:20 -0700

On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>and security program, please do share your feedback with us.

Great document Š some observations on a missing topic area:

The draft-iab-privsec-confidentiality-threat-00 provides a good
overview of many issues, but does not mention the problems associated
with static MAC addresses. MAC addresses, while perhaps considered
beneath the purview of IETF have a significant impact on the system
considerations for private Internet communications.

MAC addresses are assigned to device interfaces to support
link level communications on subnets.  These addresses are assigned
through a global registry with allocations to individual companies to
distribute unique assignments.  Being unique, the MAC addresses are
often used as a device identification.  Some operating systems use
a device MAC address to create a GUID (globally unique identifier)
that is then used to identify the host.  The GUID is then embedded
in documents to identify the source platform.

MAC addresses are used to create IPv6 addresses.  The unique MAC address
provides a convenient  mechanisms to assign a unique IP address.
This convenience for unique IPv6 assignment makes a unique
MAC address an integral part of many emerging architectures
(e.g for IoT). Binding the device unique MAC address to an IPv6
address makes the communicating device identifiable by
any observer end-to-end.

Static MAC addresses are a particularly serious problem in
wireless networks.  Simply sniffing of traffic provides
the device unique address which is readily correlated
to the specific user.

IEEE 802 does provide facilities for local MAC addresses.  The
local MAC addresses are not used widely and have been applied
primarily for special purpose protocol applications
(e.g. Local MAC used as BSSID for IBSS).  The local MAC
addresses does allow a random address to be used for the link
provides significant improvements for privacy, but the
impact on bridging, routing and device authentication need
to be considered.  Frequently changing MAC addresses will
Potentially overflow routing tables.  DHCP servers may run
out of available addresses.  Guidelines for protocols that
use MAC addresses will need to be developed to prevent
disruption of network communications.  Some IETF protocols
may need to be modified to facilitate the use of local
MAC addresses.

>We are

Š  if we want to build a private Internet
we should ensure that we have a solid foundation at the
bottom of the stack (MAC addresses).  Addressing architectures
must be be reconsidered to ensure that a static address is not
necessary.  Identity should not be an addresses, but some other
non-assigned locally generated identifier that can be bound
to a end device cryptographically.

Paul

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (Darwin)
>
>iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda
>8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy
>WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM
>OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi
>vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO
>l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK
>7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY
>+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0
>NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX
>IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+
>nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z
>ndxTiZ7dEsIuOJE0OCaL
>=4SpJ
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>perpass mailing list
>[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Oct 2014 14:16:12 -0400

> may need to be modified to facilitate the use of local
Thanks, Paul.  We've been working with the IEEE and in particular with Juan
Carlos Zuniga on this topic.  He has talked to us about work the IEEE is
doing and presented at the last SAAG meeting.  Your points are good ones on
the interconnection between their work and ours.

Here are his slides from the last SAAG meeting, this set doesn't go deep
into that topic though.
http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf

-- 

Best regards,
Kathleen

---

From: Paul Lambert <[email-masked]>
Date: Tue, 7 Oct 2014 18:49:46 -0700

On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, Paul.  We've been working with the IEEE and in particular with Juan Carlos Zuniga on this topic.  He has talked to us about work the IEEE is doing and presented at the last SAAG meeting.  Your points are good ones on the interconnection between their work and ours.
Yes, I’ve been pushing this in IEEE and the WFA for a year or two …

We do have one specification already in the Wi-FI Alliance that will be using link local MAC addresses (to be announced soon).  I’m optimistic that this will see some broad adoption, however, it is not your standard client to hotspot messaging so there is still more work to do.  I’m hoping that some devices will support both this new and old mode of operation simultaneously and so adopt changing MAC addresses.   Right now these recommendations for changing address are a little loose and only stipulate that the MAC address should remain the same for at least 30 minutes.

The point in the narrative above, was not so much to describe the work in IEEE that may be out-of-scope for the IETF, but to indicate that work in the IETF will be required to adapt to constantly changing MAC addresses.

Paul

Here are his slides from the last SAAG meeting, this set doesn't go deep into that topic though.
http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf

Paul

>> list [email-masked]<mailto:[email-masked]>
>(p) 202-407-8825<tel:202-407-8825>
>(f) 202-637-0968<tel:202-637-0968>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

--

Best regards,
Kathleen

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 8 Oct 2014 21:03:01 +0000

Hi Paul,

From: Paul Lambert [mailto:[email-masked]]
Sent: Tuesday, October 07, 2014 9:50 PM
To: Kathleen Moriarty
Cc: [email-masked]; Joseph Lorenzo Hall
Subject: Re: [perpass] IAB security/privacy programme PM draft

Thanks, Paul.  We've been working with the IEEE and in particular with Juan Carlos Zuniga on this topic.  He has talked to us about work the IEEE is doing and presented at the last SAAG meeting.  Your points are good ones on the interconnection between their work and ours.
Yes, I've been pushing this in IEEE and the WFA for a year or two ...

We do have one specification already in the Wi-FI Alliance that will be using link local MAC addresses (to be announced soon).  I'm optimistic that this will see some broad adoption, however, it is not your standard client to hotspot messaging so there is still more work to do.  I'm hoping that some devices will support both this new and old mode of operation simultaneously and so adopt changing MAC addresses.   Right now these recommendations for changing address are a little loose and only stipulate that the MAC address should remain the same for at least 30 minutes.

The point in the narrative above, was not so much to describe the work in IEEE that may be out-of-scope for the IETF, but to indicate that work in the IETF will be required to adapt to constantly changing MAC addresses.
[JCZ] Yes, this is something that concerns IETF and that's why we are coordinating as much as possible the joint effort between IEEE 802 and IETF.
One of the main outcomes of the potential MAC randomization trial would be to highlight the implications of MAC address changes on IETF protocols. As you know, so far we have identified potential repercussions on DHCP, ARP/ND, IPv6 SAA, switches and AAA infrastructure. Whether these will require changes in the actual protocols or just changes/recommendations for configuration, is still FFS.
Regards,
Juan Carlos

Paul

Paul

--

Best regards,
Kathleen