idnits 2.17.1 draft-liu-t2trg-bootstrapping-survey-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2705 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft Q. An 4 Intended status: Experimental Alibaba Group 5 Expires: May 4, 2017 October 31, 2016 7 Survey on Thing Secure Bootstrapping 8 draft-liu-t2trg-bootstrapping-survey-00 10 Abstract 12 This document presents a survey of secure bootstrapping mechanisms 13 for Internet of Things (IoT) system. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 4, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Cloud Server Based Secure Bootstrapping . . . . . . . . . . . 2 57 3. Thread Commissioning . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This document provides a guidance desgin for thing secure 67 bootstrapping for Internet of Things (IoT) system. It introduces 68 third-party entity located in Internet into thing bootstrapping, to 69 offer enhanced security. 71 2. Cloud Server Based Secure Bootstrapping 73 This section describes the cloud server based secure bootstrapping 74 method for IoT 76 Architecture for thing secure bootstrapping method is shown in figure 77 1. 79 preamble to the figure. 81 +---------+ 82 | Cloud | 83 | Server | 84 +---------+ 85 | 86 | 87 +------------------------------+ 88 | Group Owner | 89 +------------------------------+ 90 | | 91 +-----------+ +----------+ 92 | | 93 +----------+ +----------+ 94 | Thing | | User APP | 95 +----------+ +----------+ 97 Figure 1: Architecture for thing secure bootstrapping method 99 The flow of thing secure bootstrapping method is shown in figure 2. 101 preamble to the figure. 103 +----+ +----+ +------+ +-----+ +------+ 104 |User| |User| |Thing | |Group| |Cloud | 105 | | |APP | | | |Owner| |Server| 106 +----+ +----+ +------+ +-----+ +------+ 107 |1.Initiate | | | | 108 |bootstrapping. | | | | 109 |User APP is in | | | | 110 |"Listen" mode | | | | 111 |-------------->| | | | 112 | | | | 2.Notify | 113 | | | | Server | 114 | |--------------+-------------+-------------->| 115 | | | | 3.Create PSK | 116 | | | | and send to | 117 | | | | group owner | 118 | | | |<--------------| 119 | | |4.Broadcast | | 120 | | |RandomKey | | 121 | | |<------------| | 122 |5.Trigger thing| | | | 123 |into secure | | | | 124 |bootsrapping | | | | 125 |mode | | | | 126 |---------------+------------->| | | 127 | | |---+6.Scan | | 128 | | | |to get | | 129 | | |<--+RandomKey| | 130 | | | | | 131 | | |7.Func(PSK, | | 132 | | |RandomKey) | | 133 | | |------------>| | 134 | | | | | 135 | | |8.Result of | | 136 | | |bootstrapping| | 137 | | |<------------| | 138 | |9.Result of | | | 139 | |bootstrapping | | | 140 | |<-------------| | | 141 | | | | | 142 |10.If succeeds,| | | | 143 |notify server | | | | 144 |---------------+--------------+-------------+-------------->| 145 | | | | | 147 Figure 2: Architecture for thing secure bootstrapping method 149 Premise of secure bootstrapping 151 o Group Owner can connect to Internet with server. 153 o User application has been binded with group owner. 155 Func() in step 7 is used to calculate a value based on inputing 156 RandomKey and PSK. and is known by both thing and group owner. The 157 definion is out of this document's scope. 159 3. Thread Commissioning 161 This section descibes the secure bootstrapping method defined by 162 Thread Group, "Thread Commissioning". 164 Commissioning is the process whereby a user wants to get the Thread 165 Device they have just bought onto their Thread Network. 167 Term definition 169 o Commissioner: The currently elected authentication server for new 170 Thread devices and the authorizer for providing the network 171 credentials they require to join the network. A device capable of 172 being elected as a Commissioner is called a Commissioner 173 Candidate. 175 o Joiner: The device to be added by a human administrator to a 176 commissioned Thread Network. This role requires a Thread 177 interface to perform and cannot be combined with another role in 178 one device. The Joiner does not have network credentials. 180 o Joiner Router: An existing Thread router or REED (Router-Eligible 181 End Device) on the secure Thread Network that is one radio hop 182 away from the Joiner. 184 o Border Router: Any device capable of forwarding between a Thread 185 Network and a non-Thread Network. 187 The commissioning process has two phases 189 o Petitioning: The process of authenticating and authorizing a 190 Commissioner Candidate onto the Thread Network through a 191 representative (typically the Border Router). 193 o Joining: The process of authenticating and authorizing a Thread 194 Device onto the Thread Network. 196 Petitioning must occur before any Joiner can join, that is, there 197 must be one sole authorized Commissioner - the authenticator for 198 subsequent Joiners 200 There are four cases which are considered: 202 External Commissioner is connected to the WLAN 204 o Border Router is not Joiner Router 206 o Border Router is Joiner Router 208 Native Commissioner is connected to the Thread Network 210 o Joiner Router is not Commissioner 212 o Joiner Router is Commissioner 214 The following takes the most complex case as an example to illustrate 215 the commissioning process: External Commissioner is connected to the 216 WLAN, and Border Router is not Joiner Router. 218 preamble to the figure. 220 +------------+ +------+ +-------+ +------+ 221 |Commissioner| |Board | |Joiner | |Joiner| 222 | | |Router| |Router | | | 223 +------------+ +------+ +-------+ +------+ 224 | | | | 225 | WLAN | Thread | P2P | 226 |<------------------>|<------------>|<------------->| 227 | | | | 229 In this case, there are three separate and distinct paths the 230 authentication traffic (the DTLS handshakes) has to go through: 232 o Joiner to Joiner Router point-to-point 234 o Joiner Router to Border Router through Thread Network 236 o Border Router to Commissioner through WLAN 238 Joiner to Joiner Router Point-to-Point communication is over an 239 unsecured, one-hop 802.15.4 radio link and all traffic between the 240 Joiner and Joiner Router will be sent in the clear without any form 241 of integrity checking. This fundamentally means the Joiner Router 242 has to treat any traffic from the Joiner as completely 243 unauthenticated. Normally, the Thread Network would be in a "lock 244 down" mode, which would cause any Thread Device on the perimeter to 245 ignore any unsecured 802.15.4 traffic. However, when joining is 246 permitted, Joiner Routers should carefully police unsecured 802.15.4 247 traffic and assume it to be authentication traffic. The DTLS 248 handshake will occur as initial communication being established 249 between the Joiner and Joiner Router. This uses UDP on a specific 250 port, which allows it to be distinguished from other traffic. A 251 relay agent will police the incoming traffic and the Joiner Router 252 will relay the DTLS client handshake along with address and port 253 details of the Joiner and the Joiner Router itself to the Border 254 Router. The address and port details ensure relayed DTLS server 255 handshake response messages can be relayed back through the Joiner 256 Router to the originating Joiner. 258 Joiner Router to Border Router through Thread Network communication 259 is over the Thread Network, which will be secured hop-by-hop at the 260 802.15.4 link layer. It is assumed that there is connectivity over 261 one or more hops between the Joiner Router and the Border Router. 262 The Joiner Router will relay authentication traffic to and from the 263 Border Router using relay messages carrying the DTLS handshake 264 packets along with address and port details. 266 Border Router to Commissioner through WLAN communication over the 267 WLAN uses the existing secure Commissioning session set up between 268 the Border Router and the Commissioner, maintained by Commissioning 269 keep-alive notifications. The Commissioning Relay receive and 270 transmit messages are used to carry the DTLS Handshake to and from 271 the Commissioner and the messages are secured at the DTLS record 272 layer based on the secure Commissioning session. 274 The steps of joining are: 276 o Joiner and Commissioner establish an end-t-end DTLS connection, 277 and share a pair-wise key. 279 o Based on the established DTLS connection, Joiner starts the 280 Joining request. 282 o After receiving the Joining request, COmmissioner sends the pair- 283 wise key to Joiner Router. 285 o Using the pair-wise key, Joiner Router sends the commissioning 286 parameters to Joiner. 288 o After Joiner successfully joins Thread network, Joiner requests to 289 close the DTLS connection with Commissioner. 291 4. IANA Considerations 293 This document makes no request of IANA. 295 5. Security Considerations 297 TBD 299 6. Acknowledgements 301 TBD 303 7. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 Authors' Addresses 312 Dapeng Liu 313 Alibaba Group 314 Beijing 315 Beijing 317 Phone: +86-1391788933 318 Email: maxpassion@gmail.com 320 Qing An 321 Alibaba Group 322 Beijing 323 Beijing 325 Phone: +86-13810495624 326 Email: anqing.aq@alibaba-inc.com