6tisch R. Struik Internet-Draft Struik Security Consultancy Intended status: Informational October 27, 2014 Expires: April 30, 2015 Observations about IPv6 Addressing draft-struik-6lo-on-ipv6-addressing-00 Abstract This document contains some observations on IPv6 addressing. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Struik Expires April 30, 2015 [Page 1] Internet-Draft 6lo-addressing October 2014 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Opaque identifiers . . . . . . . . . . . . . . . . . . . . . 2 2. Security Considerations . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Opaque identifiers RFC7217 [RFC7217] describes a mechanism for generating opaque interface identifiers and argues that these identifiers improve security and privacy of IPv6 addresses, when compared to using modified EUI-64 address formats. The main case presented in that document is that using opaque interface identifiers, rather than fixed hardware device identifiers, thwarts attempts at correlating of host activities over time, tracking across multiple networks, and pinpointing devices that may exhibit known vulnerabilities. There are also some down sides to adopting this opaque identifier format: 1. Use of opaque identifiers does not preclude traceability on layer 2. While this is an obvious remark, the reverse also seems to hold: if Layer 2 MAC addresses would be randomized (see, e.g., discussion on MAC address randomization at IETF-90), then derivation of IPv6 addresses using those randomized MAC adddreses (rather than the EUI-64 hardware address) would certainly serve the same purpose as the technique in RFC 7217. Moreover, IPv6 opaque addresses may trickle down to Layer 2, by deriving the randomized MAC address from the interface identifier (assumed to be at least 64-bit long). This would allow constrained nodes to derive compression benefits that would not be available if one would cut the ties between Layer 2 and Layer 3 address formats. As such, this would benefit "constrained cluster" specifications, such as RFC6282, RFC4944, and RFC 6755. 2. The algorithm in RFC 7217 for generating opaque interface identifiers RID depends on an intra-device secret key (secret_key), and some public parameters (Prefix, Net_Iface, Network_ID) and takes the form RID:=F(key, public parameters). It is noted that F() MUST be difficult to reverse, MUST not be computable without knowledge of the secret key, and should not Struik Expires April 30, 2015 [Page 2] Internet-Draft 6lo-addressing October 2014 leak the secret key given a number of samples F(key,public parms), where parms are under the control of an adversary. The output should be at least 64 bits (and, in practice, mostly is). While the specification suggests that the secret key should, indeed, be kept secret, the specification seems to allow administrator access and depends on trustworthy bootstrapping. Since it cannot be verified outside the device whether the quantity RID and the opaque interface identifier were indeed generated as specified with a secret key unknown to any outside device, this leaves this technique open to "Big Brother"-esque manipulation. Indeed, it is not hard to see (inspired by [Surveillance]) that one could field devices, where device- internal private information could be leaked via the opaque interface identifier, no matter the good intentions: the supposedly opaque interface identifier simply serves as a so- called subliminal channel. This subliminal channel cannot be detected without close examination of the entire device implementation. 2. Security Considerations This note illustrates that privacy is a system issue and illustrates examples where the opaque interface identifier could be turned into a subliminal channel for releasing secret information to a Big Brother agent, without means for detecting this. 3. IANA Considerations There is no IANA action required for this document. 4. Acknowledgments Kudos to Edward Snowden for introducing fascinating technical problems to the paranoid. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. Struik Expires April 30, 2015 [Page 3] Internet-Draft 6lo-addressing October 2014 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, October 2012. [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and W. Will, "Recommendation on Stable IPv6 Interface Identifiers", draft-ietf-6man-default-iids-01 (work in progress), October 2014. [I-D.ietf-6man-why64] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", draft-ietf-6man-why64-07 (work in progress), October 2014. [I-D.sarikaya-6lo-cga-nd] Sarikaya, B. and F. Xia, "Lightweight and Secure Neighbor Discovery for Low-power and Lossy Networks", draft- sarikaya-6lo-cga-nd-01 (work in progress), October 2014. [Surveillance] Mihir Bellare, Kenneth G. Paterson, Phillip Rogaway, "Security of Symmetric Encryption Against Mass- Surveillance", CRYPTO 2014, IACR, August 2014. Author's Address Rene Struik Struik Security Consultancy Email: rstruik.ext@gmail.com Struik Expires April 30, 2015 [Page 4]