--- 1/draft-ietf-6tisch-minimal-security-00.txt 2017-02-02 06:13:21.836906701 -0800 +++ 2/draft-ietf-6tisch-minimal-security-01.txt 2017-02-02 06:13:21.872907543 -0800 @@ -1,103 +1,95 @@ -6TiSCH M. Vucinic, Ed. +6TiSCH Working Group M. Vucinic Internet-Draft Inria Intended status: Standards Track J. Simon -Expires: June 17, 2017 Linear Technology +Expires: August 6, 2017 Linear Technology K. Pister University of California Berkeley - December 14, 2016 + February 02, 2017 Minimal Security Framework for 6TiSCH - draft-ietf-6tisch-minimal-security-00 + draft-ietf-6tisch-minimal-security-01 Abstract This draft describes the minimal mechanisms required to support secure initial configuration in a device being added to a 6TiSCH network. The goal of this configuration is to set link-layer keys, and to establish a secure session between each joining node and the JCE who may use that to further configure the joining device. Additional security behaviors and mechanisms may be added on top of this minimal framework. -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 June 17, 2017. + This Internet-Draft will expire on August 6, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 3.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 5 3.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 5 - 3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 5 - 3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 5 + 3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 6 + 3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 6 3.4. Step 4 - Join Request . . . . . . . . . . . . . . . . . . 6 3.5. Step 5 - Join Response . . . . . . . . . . . . . . . . . 6 - 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 + 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 7 4.1. Proxy Operation of JA . . . . . . . . . . . . . . . . . . 7 - 4.1.1. Implementation of origin_info . . . . . . . . . . . . 7 - 4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 7 - 4.3. Implementation of Join Request . . . . . . . . . . . . . 8 - 4.4. Implementation of Join Response . . . . . . . . . . . . . 8 - 5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Implementation of origin_info . . . . . . . . . . . . 8 + 4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 8 + 4.3. Implementation of Join Request . . . . . . . . . . . . . 9 + 4.4. Implementation of Join Response . . . . . . . . . . . . . 9 + 5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 10 5.1. Well-known beacon authentication key . . . . . . . . . . 10 5.2. Private beacon authentication key . . . . . . . . . . . . 10 - 6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . 12 - 11.3. External Informative References . . . . . . . . . . . . 14 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction When a previously unknown device seeks admission to a 6TiSCH [RFC7554] network (to "join"), it first needs to synchronize to the network. The device then configures its IPv6 address and authenticates itself, and also validates that it is joining the right network. At this point it can expect to interact with the network to configure its link-layer keying material. Only then may the node establish an end-to-end secure session with an Internet host using @@ -108,37 +100,47 @@ This document describes the mechanisms comprising a minimal feature set for a device to join a 6TiSCH network, up to the point where it can establish a secure session with an Internet host. It presumes a network as described by [RFC7554], [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. It assumes the joining device pre-configured with either a: o pre-shared key (PSK), + o raw public key (RPK), + o or a locally-valid certificate and a trust anchor. As the outcome of the join process, the joining device expects one or more link-layer key(s) and optionally a temporary network identifier. 2. Terminology + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. These + words may also appear in this document in lowercase, absent their + normative meanings. + The reader is expected to be familiar with the terms and concepts defined in [I-D.ietf-6tisch-terminology], [RFC7252], and [I-D.ietf-core-object-security]. The entities participating in the protocol that is specified in this document are: o JN: Joining node - the device attempting to join a particular 6TiSCH network. + o JCE: Join coordinating entity - central entity responsible for authentication and authorization of joining nodes. + o JA: Join assistant - the device within radio range of the JN that generates Enhanced Beacons (EBs) and facilitates end-to-end communications between the JN and JCE. 3. Join Overview This section describes the steps taken by a joining node (JN) in a 6TiSCH network. When a previously unknown device seeks admission to a 6TiSCH [RFC7554] network, the following exchange occurs: @@ -427,21 +443,21 @@ valid EB, since the JN can neither know the ASN a priori nor verify the address of the JA. This permits a Denial of Service (DoS) attack at the JN. Beacon authentication keys are discussed in Section 5.1 and Section 5.2. 5.1. Well-known beacon authentication key For zero-touch operation, where any 6TiSCH device can attempt to join any 6TiSCH network out of the box, a well-known EB link-layer key MUST be used. The value of this key is specified in - [I-D.ietf-6tisch-minimal]. + [I-D.ietf-6tisch-minimal] 5.2. Private beacon authentication key Some pre-configuration MAY be done when the device is manufactured or designated for a specific network (i.e. the network is one-touch) or a network operator may not wish to allow arbitrary devices to try to join. A private (per-vendor, or per-installation) EB link-layer key MAY be used in place of a well-known key to create a private network. 6. Asymmetric Keys @@ -554,21 +570,21 @@ Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", draft-ietf-cose-msg-24 (work in progress), November 2016. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-ietf-core- - object-security-00 (work in progress), October 2016. + object-security-01 (work in progress), December 2016. 11.2. Informative References [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. @@ -590,46 +606,44 @@ 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [I-D.ietf-6tisch-minimal] - Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-17 (work in - progress), November 2016. + Vilajosana, X., Pister, K., and T. Watteyne, "Minimal + 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work + in progress), January 2017. [I-D.ietf-6tisch-6top-protocol] Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- ietf-6tisch-6top-protocol-03 (work in progress), October 2016. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE - 802.15.4e", draft-ietf-6tisch-terminology-07 (work in - progress), March 2016. + 802.15.4e", draft-ietf-6tisch-terminology-08 (work in + progress), December 2016. [I-D.selander-ace-cose-ecdhe] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- cose-ecdhe-04 (work in progress), October 2016. -11.3. External Informative References - [IEEE802154-2015] - IEEE standard for Information Technology, "IEEE Std + IEEE standard for Information Technology, ., "IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area - Networks (WPANs)", December 2015. + Networks (WPANs)", 2015. Appendix A. Example Figure 3 illustrates a join protocol exchange in case PSKs are used. JN instantiates the OSCOAP context and derives the traffic keys and nonces from the PSK. It uses the instantiated context to protect the CoAP request addressed with Proxy-Scheme option and well-known host name of JCE in the Uri-Host option. The example assumes a JA that is already aware of JCE's IPv6 address and does not need to resolve the well-known "6tisch.jce" host name. Triggered by the presence of @@ -632,22 +646,25 @@ CoAP request addressed with Proxy-Scheme option and well-known host name of JCE in the Uri-Host option. The example assumes a JA that is already aware of JCE's IPv6 address and does not need to resolve the well-known "6tisch.jce" host name. Triggered by the presence of Proxy-Scheme option, JA forwards the request to the JCE. Once JCE receives the request, it looks up the correct context based on the context identifier (cid) field. It reconstructs OSCOAP's external Additional Authenticated Data (AAD) needed for verification based on: o Version field of the received CoAP header. + o Code field of the received CoAP header. - o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. + + o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg] + o Request URI reconstructed following [I-D.ietf-core-object-security]. Replay protection is ensured by OSCOAP and the tracking of sequence numbers at each side. In the example below, the response contains sequence number 7 meaning that there have already been some attempts to join under a given context, not coming from the JN. Once JA receives the response, it looks up and decodes the cid field in order to decide where to forward it. JA constructs the CoAP response to JN by setting the CoAP token to the value decoded from cid and @@ -728,21 +747,21 @@ } ], h'af93' / assigned short address / ] Encodes to h'8281a201042050e6bf4287c2d7618d6a9687445ffd33e642af93' with a size of 26 bytes. Authors' Addresses - Malisa Vucinic (editor) + Malisa Vucinic Inria 2 Rue Simone Iff Paris 75012 France Email: malisa.vucinic@inria.fr Jonathan Simon Linear Technology 32990 Alvarado-Niles Road, Suite 910 @@ -743,17 +762,18 @@ Email: malisa.vucinic@inria.fr Jonathan Simon Linear Technology 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 USA Email: jsimon@linear.com + Kris Pister University of California Berkeley 512 Cory Hall - Berkeley, California 94720 + Berkeley, CA 94720 USA Email: pister@eecs.berkeley.edu