AW: Device Discovery and Telehash

Hi,

quickly stepping in without wanting to add any detail now.



What I’d like to offer are 2 things I learned over the last decade:

-          Discussion about authorization often enters technical/mechanical details too quickly and goes wrong for exactly this reason. The usual symptom is: people cannot express the designed authorization in human language but know that this answer is RBAC, XACML or <you name it> (I’m not saying this is the case here, just that I frequently encountered this anti-pattern in the past).

-          There is a continental divide between authorization for individually-owned consumer goods and legal entity-owned capital goods for instance

o   Authorization for individually-owned consumer goods typically following an a posteriori model: access request comes first, then authorization decision; results in an authorization policy that is build-up dynamically

o   Authorization for legal entity-owned capital goods commonly rely on a priori strategies: (static) authorization policy comes first, then (many) access requests and authorization decisions

(The fact that OAuth cares about the 2 sides of this continental devide under one umbrella without spelling that out does not help either)



Hence I’d suggest to always start with 2 simple question:

Q1: what is the nature of the thing - individually-owned consumer good and/or legal entity-owned capital good?

Q2: what is – in human language – the effect that authorization/access control shall achieve?



After that’s clear (it is not for me with respect to the problem discussed here) it will be more straight-forward to find an approach



Best regards,

Oliver



Von: Drasko DRASKOVIC [mailto:drasko.draskovic@gmail.com]
Gesendet: Dienstag, 9. Februar 2016 08:41
An: Tibor Pardi
Cc: Public Web of Things IG; Dave Raggett
Betreff: Re: Device Discovery and Telehash



Hi Tibor,
On Feb 9, 2016 12:07 AM, "Tibor Pardi" <tibor@zovolt.com<mailto:tibor@zovolt.com>> wrote:
> I think, at least for my use cases, perhaps the simplest solution is how the W3C web-of-things-framework handles the access control via the P2P protocol.
>
> Each node - which can be either a human or device user - has an ECC PPK public-private key pair and an account name. Prior connecting and sending data to each other, the devices and human users have to be aware of each others' public key and account name. The account name is 8-16 bytes and ECC public key is 32 bytes so it is particularly suited for a constrained device environment. An administrator user (in home environment typically the home owner or the admin of a solution provider) has access to the device and can update the device with the list of users' public key and account name. The list include the users that could access to the device. Alternatively, a web or any kind of online service can configure the device with the list of permitted account details. If this is not suitable for some use cases, then we can configure the device with only one admin public key and account name, which means such admin account has permission to configure the device with the allowed user list (or in fact with any configuration data) by connecting to the device once the device is on-line. (probably this latest is the simplest configuration).
> The human user knows the device's account name and can search for the device's public key via the P2P or centralized web network. Alternatively, the human user can load the device's public key from a file prior connecting to the network, which would even further eliminate the security threats of certain attacks such as Sybil attack (please note since all messages are signed with the public key in my opinion the room for a Sybil attack is very limited, but still we have to think about that in a P2P network. Of course on a client/server environment Sybil attack is not an issue).
> On a private or closed network that limits the access via a firewall to a known user base the public key pre-configuration can be avoided - only the account name is required. And then, once the devices and users are on-line then they can get each others public key by querying it based on account name from the key repository via the P2P, WWW or WS protocols.
> Once both parties are aware of each others' public keys then the ECDH key exchange is performed to agree on an a symmetric AES key. Following the ECDH key exchange all messages will be encrypted with the symmetric AES from end to end, purely peer to peer without using an authentication server or any centralized solution.
> The parties can change/update their public key at any time since the message of the new public key is signed with the existing public key so the originator of the new key can be verified by all interested parties.
>
> As for the services, the concept is similar: a PPK key pair is assigned to he service as well and then the authentication, access control follow the device-to-human and device-to-device method.
>
> This solution is based on standards. The ECC implementation is FIPS compliant, it uses recommended ECC curves and all messages are standard JWT, JWS and JWE compliant data streams.
>
> I think the above satisfies your requirement with regards to easy configuration - it can be as simple as having one public key and one account name on the device (the admin account which pushes the configuration messages to the device).
>
> For my use cases I need a solution in which the access control, authentication and provisioning can be handled without using any centralized authority or authentication server, without any cloud based or client/server solution, but I think such public/private key based authentication/access control scheme would work on a client/server topology as well. Personally, I prefer this simple but secure solution over the more resource consuming oAuth and other popular but complex authentication schemes.

This solution looks interesting indeed.

I am not a security expert, so I have a few questions:
- How does this solution compares to Telehash/Adept?
- Is there any other project using this security approach - i.e. is this something already deployed and tested by the industry somehow?

I totally agree that we should look for something lightweight and avoid heavy implementations like oAuth. As I told before, I was looking for Meshblu-like approach - but it is patented :(.

I saw that you have already documented something here: https://github.com/w3c/web-of-things-framework/blob/master/security.md. I think it would be smart to document these propositions/specs somehow, not to lost them in the e-mails.

From my experience GitHub wiki has been useful, especially if few of us can edit it. Otherwise we can use Markdown files in the repo, but this demands commits for each change.

Dave,
any opinions on creating wiki?

BR,
Drasko