On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert <p...@marvell.com<mailto:p...@marvell.com>> wrote: On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <j...@cdt.org<mailto:j...@cdt.org>> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >As the showrunner for the confidentiality effort in the IAB privacy >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. 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 >We are >also contemplating a companion document on mitigations for the threats >outlined in the threat model. Š 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 > >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 perpass@ietf.org<mailto:perpass@ietf.org> >> 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<tel:202-407-8825> >(f) 202-637-0968<tel:202-637-0968> >j...@cdt.org<mailto:j...@cdt.org> >PGP: https://josephhall.org/gpg-key >fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > >-----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 >perpass@ietf.org<mailto:perpass@ietf.org> >https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org<mailto:perpass@ietf.org> https://www.ietf.org/mailman/listinfo/perpass -- Best regards, Kathleen
_______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
