Internet DRAFT - draft-liu-t2trg-bootstrapping-survey
draft-liu-t2trg-bootstrapping-survey
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]
