Network Working Group D. Liu Internet-Draft Q. An Intended status: Experimental Alibaba Group Expires: May 4, 2017 October 31, 2016 Survey on Thing Secure Bootstrapping draft-liu-t2trg-bootstrapping-survey-00 Abstract This document presents a survey of secure bootstrapping mechanisms for Internet of Things (IoT) system. Requirements Language 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 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 May 4, 2017. Copyright Notice Copyright (c) 2016 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 Liu & An Expires May 4, 2017 [Page 1] Internet-Draft Secure Bootstrapping Survey October 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Cloud Server Based Secure Bootstrapping . . . . . . . . . . . 2 3. Thread Commissioning . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document provides a guidance desgin for thing secure bootstrapping for Internet of Things (IoT) system. It introduces third-party entity located in Internet into thing bootstrapping, to offer enhanced security. 2. Cloud Server Based Secure Bootstrapping This section describes the cloud server based secure bootstrapping method for IoT Architecture for thing secure bootstrapping method is shown in figure 1. Liu & An Expires May 4, 2017 [Page 2] Internet-Draft Secure Bootstrapping Survey October 2016 preamble to the figure. +---------+ | Cloud | | Server | +---------+ | | +------------------------------+ | Group Owner | +------------------------------+ | | +-----------+ +----------+ | | +----------+ +----------+ | Thing | | User APP | +----------+ +----------+ Figure 1: Architecture for thing secure bootstrapping method The flow of thing secure bootstrapping method is shown in figure 2. preamble to the figure. Liu & An Expires May 4, 2017 [Page 3] Internet-Draft Secure Bootstrapping Survey October 2016 +----+ +----+ +------+ +-----+ +------+ |User| |User| |Thing | |Group| |Cloud | | | |APP | | | |Owner| |Server| +----+ +----+ +------+ +-----+ +------+ |1.Initiate | | | | |bootstrapping. | | | | |User APP is in | | | | |"Listen" mode | | | | |-------------->| | | | | | | | 2.Notify | | | | | Server | | |--------------+-------------+-------------->| | | | | 3.Create PSK | | | | | and send to | | | | | group owner | | | | |<--------------| | | |4.Broadcast | | | | |RandomKey | | | | |<------------| | |5.Trigger thing| | | | |into secure | | | | |bootsrapping | | | | |mode | | | | |---------------+------------->| | | | | |---+6.Scan | | | | | |to get | | | | |<--+RandomKey| | | | | | | | | |7.Func(PSK, | | | | |RandomKey) | | | | |------------>| | | | | | | | | |8.Result of | | | | |bootstrapping| | | | |<------------| | | |9.Result of | | | | |bootstrapping | | | | |<-------------| | | | | | | | |10.If succeeds,| | | | |notify server | | | | |---------------+--------------+-------------+-------------->| | | | | | Figure 2: Architecture for thing secure bootstrapping method Liu & An Expires May 4, 2017 [Page 4] Internet-Draft Secure Bootstrapping Survey October 2016 Premise of secure bootstrapping o Group Owner can connect to Internet with server. o User application has been binded with group owner. Func() in step 7 is used to calculate a value based on inputing RandomKey and PSK. and is known by both thing and group owner. The definion is out of this document's scope. 3. Thread Commissioning This section descibes the secure bootstrapping method defined by Thread Group, "Thread Commissioning". Commissioning is the process whereby a user wants to get the Thread Device they have just bought onto their Thread Network. Term definition o Commissioner: The currently elected authentication server for new Thread devices and the authorizer for providing the network credentials they require to join the network. A device capable of being elected as a Commissioner is called a Commissioner Candidate. o Joiner: The device to be added by a human administrator to a commissioned Thread Network. This role requires a Thread interface to perform and cannot be combined with another role in one device. The Joiner does not have network credentials. o Joiner Router: An existing Thread router or REED (Router-Eligible End Device) on the secure Thread Network that is one radio hop away from the Joiner. o Border Router: Any device capable of forwarding between a Thread Network and a non-Thread Network. The commissioning process has two phases o Petitioning: The process of authenticating and authorizing a Commissioner Candidate onto the Thread Network through a representative (typically the Border Router). o Joining: The process of authenticating and authorizing a Thread Device onto the Thread Network. Liu & An Expires May 4, 2017 [Page 5] Internet-Draft Secure Bootstrapping Survey October 2016 Petitioning must occur before any Joiner can join, that is, there must be one sole authorized Commissioner - the authenticator for subsequent Joiners There are four cases which are considered: External Commissioner is connected to the WLAN o Border Router is not Joiner Router o Border Router is Joiner Router Native Commissioner is connected to the Thread Network o Joiner Router is not Commissioner o Joiner Router is Commissioner The following takes the most complex case as an example to illustrate the commissioning process: External Commissioner is connected to the WLAN, and Border Router is not Joiner Router. preamble to the figure. +------------+ +------+ +-------+ +------+ |Commissioner| |Board | |Joiner | |Joiner| | | |Router| |Router | | | +------------+ +------+ +-------+ +------+ | | | | | WLAN | Thread | P2P | |<------------------>|<------------>|<------------->| | | | | In this case, there are three separate and distinct paths the authentication traffic (the DTLS handshakes) has to go through: o Joiner to Joiner Router point-to-point o Joiner Router to Border Router through Thread Network o Border Router to Commissioner through WLAN Joiner to Joiner Router Point-to-Point communication is over an unsecured, one-hop 802.15.4 radio link and all traffic between the Liu & An Expires May 4, 2017 [Page 6] Internet-Draft Secure Bootstrapping Survey October 2016 Joiner and Joiner Router will be sent in the clear without any form of integrity checking. This fundamentally means the Joiner Router has to treat any traffic from the Joiner as completely unauthenticated. Normally, the Thread Network would be in a "lock down" mode, which would cause any Thread Device on the perimeter to ignore any unsecured 802.15.4 traffic. However, when joining is permitted, Joiner Routers should carefully police unsecured 802.15.4 traffic and assume it to be authentication traffic. The DTLS handshake will occur as initial communication being established between the Joiner and Joiner Router. This uses UDP on a specific port, which allows it to be distinguished from other traffic. A relay agent will police the incoming traffic and the Joiner Router will relay the DTLS client handshake along with address and port details of the Joiner and the Joiner Router itself to the Border Router. The address and port details ensure relayed DTLS server handshake response messages can be relayed back through the Joiner Router to the originating Joiner. Joiner Router to Border Router through Thread Network communication is over the Thread Network, which will be secured hop-by-hop at the 802.15.4 link layer. It is assumed that there is connectivity over one or more hops between the Joiner Router and the Border Router. The Joiner Router will relay authentication traffic to and from the Border Router using relay messages carrying the DTLS handshake packets along with address and port details. Border Router to Commissioner through WLAN communication over the WLAN uses the existing secure Commissioning session set up between the Border Router and the Commissioner, maintained by Commissioning keep-alive notifications. The Commissioning Relay receive and transmit messages are used to carry the DTLS Handshake to and from the Commissioner and the messages are secured at the DTLS record layer based on the secure Commissioning session. The steps of joining are: o Joiner and Commissioner establish an end-t-end DTLS connection, and share a pair-wise key. o Based on the established DTLS connection, Joiner starts the Joining request. o After receiving the Joining request, COmmissioner sends the pair- wise key to Joiner Router. o Using the pair-wise key, Joiner Router sends the commissioning parameters to Joiner. Liu & An Expires May 4, 2017 [Page 7] Internet-Draft Secure Bootstrapping Survey October 2016 o After Joiner successfully joins Thread network, Joiner requests to close the DTLS connection with Commissioner. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations TBD 6. Acknowledgements TBD 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Dapeng Liu Alibaba Group Beijing Beijing Phone: +86-1391788933 Email: maxpassion@gmail.com Qing An Alibaba Group Beijing Beijing Phone: +86-13810495624 Email: anqing.aq@alibaba-inc.com Liu & An Expires May 4, 2017 [Page 8]