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. >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
