On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert <[email protected]> wrote:
> > On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <[email protected]> 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. 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 [email protected] > >> 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 protected] > >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 > >[email protected] > >https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > -- Best regards, Kathleen
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
