From 6fa2158201905a64f2ddd9412d62593eca45aa41 Mon Sep 17 00:00:00 2001 From: Michael McCool Date: Mon, 15 Nov 2021 08:50:11 -0400 Subject: [PATCH 1/5] local transport and secure onboarding --- index.html | 48 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index c142980..36d2cbd 100644 --- a/index.html +++ b/index.html @@ -401,6 +401,12 @@

Introduction

Secure Transport

+

Secure transport is the foundation of many other security mechanisms, which are + vulnerable if it is not used. For example, basic/digest passports and bearer tokens + (used in OAuth2) can be intercepted by attackers on the network if transport is not encrypted. + Enabling secure transport is essential despite the challenges of using it + especially in isolated or local networks. +

In general, the recommendation is to use the latest version of TLS and DTLS available, consistent with interoperability requirements. Currently, the latest version of TLS is 1.3 but as this is not yet @@ -410,7 +416,7 @@

Secure Transport

in general a migration plan should be in place to TLS 1.3 and new implementations should target TLS 1.3 if possible.

-

Ideally systems would implement the following for each of the given protocols: +

Systems should implement the following for each of the given protocols:

HTTPS:

HTTP + TLS 1.3

CoAPS:

CoAP + DTLS. See also: @@ -433,19 +439,55 @@

Secure Transport

-

Local networks

- In order to secure HTTP and COAP with TLS/DTLS in local networks, we highly recommend +

Global Networks

+ +
+

Offline and Local Networks

+

We define a local network as one in which not all endpoints are visible to the rest of the internet. + This can include both fully offline isolated networks, such as those often used for factory automation, + and networks behind a NAT or firewall, as are common for home or business networks. In these cases, + establishing the identity of endpoints based on publically visible URLs and the CA system is not + possible. +

In order to secure HTTP and COAP with TLS/DTLS in local networks, we highly recommend the usage of TLS 1.3 with Raw Public Keys as specified in RFC8446 and RFC7250. + However, the keys still need to be assigned and the identities of endpoints established. + In local networks, this should be accomplished using an onboarding process, discussed in the next section.

Best practices for local security are still under discussion.
+

+ Unfortunately it may not be possible in general to use some useful consumers, in particular browsers, + with this infrastructure. The best option is to include client devices in the onboarding practice + and register a certificate that the browser can use. This is the only option for fully isolated networks. + The second best option, usable only for segmented networks with a NAT and/or firewall, is to expose a limited + number of secure endpoints, for example a "dashboard" service on a home hub, to the internet, and give + it a public URL and certificate. This can be accomplished using either STUN/TURN to set up a tunnel + through the NAT and a system such as DynDNS to establish the public IP, or a cloud-based (reverse) proxy. + Of course such exposed endpoints should have strong authentication + requirements (OAuth2 is recommended). Individual IoT devices in such a system should generally + not be directly exposed to the internet. +

+
+

Onboarding

+

Onboarding is the process of establishing trust with new endpoints in a network, which includes + establishing a way to confirm their identities and establishing a mechanism to share encryption keys. + This process is essential in order to establish secure transport between endpoints. + For systems that are globally visible on the internet, the CA (Certificate Authority) service can + be considered an onboarding process that assigns certificates to endpoints. The URL used to access + endpoints then becomes the endpoints' identify, and is encrypted into the certificate that is provided. + For devices on local networks, keys can be assigned during the onboarding process, but a mechanism + to establish the identities of endpoints is also needed. + See Different Aspects of Onboarding for IoT/Edge Devices. +

+
+

Authentication and Access Control

From 0272fdfcfb61a62e06b68eb1325001b70cbc6b25 Mon Sep 17 00:00:00 2001 From: Michael McCool Date: Mon, 15 Nov 2021 09:01:20 -0400 Subject: [PATCH 2/5] fix sections --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 36d2cbd..d3d943c 100644 --- a/index.html +++ b/index.html @@ -440,6 +440,9 @@

Secure Transport

Global Networks

+

To do. Use of public URLs, certificates, and CA. +

+

Offline and Local Networks

From bdef614c8f5282e7b065c5293c3c2f7d8896ab20 Mon Sep 17 00:00:00 2001 From: Michael McCool Date: Mon, 15 Nov 2021 10:15:39 -0400 Subject: [PATCH 3/5] revise issue reference --- index.html | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index d3d943c..b63b0ba 100644 --- a/index.html +++ b/index.html @@ -456,11 +456,11 @@

Offline and Local Networks

RFC7250. However, the keys still need to be assigned and the identities of endpoints established. In local networks, this should be accomplished using an onboarding process, discussed in the next section. - -
+

+

Best practices for local security are still under discussion. -

+

Unfortunately it may not be possible in general to use some useful consumers, in particular browsers, with this infrastructure. The best option is to include client devices in the onboarding practice @@ -487,7 +487,16 @@

Onboarding

endpoints then becomes the endpoints' identify, and is encrypted into the certificate that is provided. For devices on local networks, keys can be assigned during the onboarding process, but a mechanism to establish the identities of endpoints is also needed. - See Different Aspects of Onboarding for IoT/Edge Devices. +

+ See + Different Aspects of Onboarding for IoT/Edge Devices, + BRSKI, + DID/VC, + Anima, + and + https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping. +

+

From 457e23d4ef5e50b4586a89e7961363fd08b1d4d4 Mon Sep 17 00:00:00 2001 From: Michael McCool Date: Mon, 15 Nov 2021 10:33:39 -0400 Subject: [PATCH 4/5] update references --- index.html | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index b63b0ba..df0413c 100644 --- a/index.html +++ b/index.html @@ -15,7 +15,7 @@ , group: "wg/wot" , edDraftURI: "https://w3c.github.io/wot-security-best-practices/" , githubAPI: "https://api.github.com/repos/w3c/wot-security-best-practices" - , issueBase: "https://www.github.com/w3c/wot-security-best-practices/issues" + , issueBase: "https://www.github.com/w3c/wot-security-best-practices/issues/" , editors: [ { name: "Elena Reshetova" @@ -488,15 +488,23 @@

Onboarding

For devices on local networks, keys can be assigned during the onboarding process, but a mechanism to establish the identities of endpoints is also needed.

- See + See the following ITRF/IETF references: + Terminology and processes for initial security setup of IoT devices, Different Aspects of Onboarding for IoT/Edge Devices, - BRSKI, - DID/VC, - Anima, + BRSKI, and - https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping. + SZTP. + Some related work in the W3C is also relavant, in particular + Decentralized Identifiers (DID) and + Verifiable Credentials (VC).

-

+

+ The WoT Scripting API needs to establish a secure environment for a script to run in and also needs to + expose and consume secure network endpoints. + Several of the + open issues in the WoT Scripting API + depend on the need for + secure onboarding, specifically the provision and management of keys and identities.

From df99fc4df06e3ca88d0df623e41761ba25545bee Mon Sep 17 00:00:00 2001 From: Michael McCool Date: Mon, 15 Nov 2021 10:37:49 -0400 Subject: [PATCH 5/5] fix typo --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index df0413c..bd711ed 100644 --- a/index.html +++ b/index.html @@ -484,7 +484,7 @@

Onboarding

This process is essential in order to establish secure transport between endpoints. For systems that are globally visible on the internet, the CA (Certificate Authority) service can be considered an onboarding process that assigns certificates to endpoints. The URL used to access - endpoints then becomes the endpoints' identify, and is encrypted into the certificate that is provided. + endpoints then becomes the endpoints' identity, and is encrypted into the certificate that is provided. For devices on local networks, keys can be assigned during the onboarding process, but a mechanism to establish the identities of endpoints is also needed.