Local transport and secure onboarding

[mmccool]

Intention is the following:
Resolves #27
Resolves #13

• Updates to secure transport section; now has both global and local transport sections
• Addition of onboarding section

WIP: to discuss, improve before merging. Please comment and suggest improvements.

---

Preview | Diff

[mmccool]

Comments:

1. DTLS version. Based heavily on TLS, small diff to handle initial handshake. However, only DLTS 1.2 has been released, DTLS 1.3 is still in draft. So hard to recommend both TLS1.3 and DTLS1.3.
2. Mutual authentication is useful in an IoT context to identify client. However, TLS1.2 has a privacy risk here: it transmits certs without encryption, so devices can be identified during initial handshake. Was solved, at least for clients, in TLS1.3. Need to check if it was fixed for servers.
3. ACE has some useful material on an "IoT profile" that uses DLTS/CoAP and PoP tokens with OAuth2. Can delegate authentication to hub, which has full connectivity. One of the mechanisms for validating client identity needs an API extension on the server. However, this ACE profile is still in draft. Does use client flow. See
   
4. Our current security schemes don't mention TLS versions, use of mutual authentication, and we don't have pop tokens (and more...), we don't mention use of authz (and the API endpoint ACE depends).
5. Local and offline networks are different. In particular, in a local network with a NAT, all devices can still confirm certs by communication with external CAs. In an offline network you can't do that. In offline networks can use OSCORE (investigate), but this is object security.
6. PSK seems to be an addition to certs in TLS. To confirm/investigate/clarify; it seems PSK is normally used without certs but maybe this is just without strong certs. McCool to find an exact reference.

Still to do: re-read DID and VC. Need to check things like server privacy, which is not a general issue for the web but is for IoT. Also still looking at BRSKI and SZPT.

[mmccool]

Discussion of onboarding:

1. Need to define requirements, input and output.
2. For offline network, may temporarily use a device with a network connection, such as a phone, for onboarding (see, for instance, Thread).
3. For lifecycle, is state machine in Architecture, but needs expansion and clarification, for instance, the difference between provisioning and onboarding. McCool: think provisioning is setting up certs/identities on all devices/services/things; onboarding is establishing trust relationship.
4. Also problem of group keys. Many specs don't address them, and they are difficult to manage (assign, rotate, etc). So processes like discovery should not depend on secure multicast, etc.

[mmccool]

Actions:

1. separate local and offline sections; they have distinct needs
2. deal with TLS1.3 and DTLS1.3 (recommend the latter, probably, even if just draft)
3. finish reading DID, VC, SZTP, BRSKI, Authz, EST, and write up notes on these and the other specs
4. Also should look at MUDs to document trust relationships...