"Thing authentication" appears fuzzy

[OliverPfaff]

"Thing authentication" in WoT essentially matches "server authentication" in the traditional (human user-centric) Web

"Server authentication" relies on 3 pillars (in an AND conjunction): 1: PoP checking (part of RFC 2246) 2: Certification path validation (required by RFC 2246; spec'ed in RFC 5280) 3: Actual/expected matching (required/sped'ed by RFC 2818, see also 6125)

I believe WoT Security should explain how 1, 2 and 3 get mapped in WoT

My current reading is: 1: can be mapped (mapping is somewhat implicit since references to security protocols are rather generic) 2: hard to map (can be seen a job of the security protocol spec to which WoT security refers rather than a job of WoT security) 3: not mapped - at least I did not find such mapping

From my perspective, task 3 can not (!) be regarded a job of the security protocol spec(s) to which WoT security refers. They only cover the parts "what's actual?", they don't cover "what was expected and how does that match the actual?". WoT security should present a position on task 3 (whatever that is at the end: an extension to RFC 6125, an application of RFC 6125 etc)

[ereshetova]

I guess for the matching you are referring to this (from RFC 2818):

" Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."

Since we expect people to use standard certificates and infrastructures to manage keys, etc, I guess the same rules apply to WoT also. RFC 6125 is applicable similarly in our case IMO, but since we never did a detailed mapping between the server authentication and WoT thing authentication, we did not write any of there details.

If in today's WoT call everyone also feels that we need to have such mapping, I think it would be great if you can try to write such a section and submit the PR for others to review.

[mmccool]

Discussed in meeting:

• Client/server vs Consumer/Thing
• Server authentication is central
• We need to map people's understanding of server authentication on the Web to the WoT context
• Probably should start by clearly defining what is done in the normal Web context
• Then explain a few complications and scenarios that might appear in the IoT/WoT context
• When an IoT device can follow the web model, it should

Next step: PR with some suggested changes; at first, a PR just to summarize existing Web server authentication mechanism.

[OliverPfaff]

Short update: did not yet have a chance to talk to Sebastian (needed to get some more details as input)

[OliverPfaff]

I had a talk with Sebastian and other from Siemens in WoT. This note captures the output. I am rephrasing 1-3 in the original posting somewhat to help understanding

"Server authentication" relies on 3 pillars: a) Expected: HTTP clients (Web browser/app) have an understanding about a server which may answer a HTTP request on the level of its host name (from e.g. location bar, bookmarks, hyperlinks, configuration) b) Actual: TLS (RFC 2246 et al, certificate exchange, PoP) and PKIX (RFC 5280, certification path validation) establish an n understanding about the server which answered a HTTP request on the level of its host name (from the subjectAltName extension in the EE certificate) c) Matching: HTTP-over-TLS (RFC 2818, 6125) specifies the matching between expected and actual

According to our discussion: b) can be mapped - as long as we consider TLS or DTLS c) can be mapped - as long as we consider HTTP-over-TLS or CoAP-over-DTLS a) can not yet be mapped. Establishing such mapping is regarded a joint task within the WoT initiatve (not WoT Security alone)

Moreover the overall assumption was:

• WoT security should consider/map/refer to the traditional server authentication in the Web to make its approach to entity authentication clear
• This can not be done by refering to a security protocol such as (D)TLS only

[mmccool]

In summary, this is a more general issue than just WoT security; it also relates to discovery. So we will keep this issue open for now. This also seems to relate to profiles: we can limit supported protocols/security mechanisms in profiles to those in the "can be mapped" category.

[mmccool]

Summary: It's not clear who the actors are for authentication; it needs a clearer definition and discussion. This is true in the TD and Architecture docs as well as in the security guidelines. A lot of the definitions in Architecture are based on other standards, which however may be based on client-server architecture.

Next steps: Propose a clearer definition in the Architecture document for "authentication" that references existing standards but builds upon them as necessary.

Action: Create issue in Architecture repo (done: https://github.com/w3c/wot-architecture/issues/429) and reference this issue.

[OliverPfaff]

Unassigned myself - no current action to me (my reading)

[mmccool]

This may be related to the current lifecycle discussion and definition of actors and what rights and capabilities they need, and how we need to authenticate actors and devices. Let's look at this again once the lifecycle discussion is nailed down.

[mmccool]

Meeting 2020-04-20:

• Key is lifecycle discussion and definition of stages and actors where authentication plays a role
• In each case, have compare expectation against actual (eg authentication is validation of expectations)
• in lifecycle table, need to note what expectations need to be validated for each state

Relevant issue: https://github.com/w3c/wot-architecture/issues/476

Action: Leave this issue open, when the above issue is resolved review it to ensure that authentication is properly addressed, defined, and scoped.

[OliverPfaff]

Just repeating. The pillars for the authentication of Web servers are: 1: TLS establishes an "actual" 2: HTTP covers the "expected" 3: HTTP-over-TLS defines how to match "actual" against "expected"

To proceed here we need a concise picture of 2 for the WoT. This has to be delivered by WoT-Arch (w3c/wot-architecture#476)

This issue can only proceed after w3c/wot-architecture#476 is addressed (still in state Open as of now)

[zolkis]

That issue is for something else mainly and won't be closed very soon it seems. If the dependency is on defining authentication in Architecture, please open a separate issue on it. Then also Architecture issue 476 will depend on that.

[mmccool]

The Security TF thinks the dependency is the other way around: we can't define authentication until we know who the actors are and how and why they need to be authenticated, and that depends on the lifecycle states defined and the "actor" table we discussed creating. So we (the WoT Security TF) are waiting for the lifecycle diagram to stabilize so we can define authentication requirements for each transition.

[OliverPfaff]

My proposal for the next steps (as discussed in TG call 2020-04-27) is following

Step 1: extend the description of (entity) authentication to cover the principle of matching expected vs. actual. According to my initial reading former versions did not or not fully cover this principle. This perceived gap caused me to open this issue. Step 1 should be independent from WoT-Arch

Step 2: ask WoT-Arch for clarifications on related concerns such as:

• Recognized WoT system roles
• Recognized WoT system actors/entities
• Envisioned suite of (application) protocols in WoT and their addressing schemes (trival for HTTP/CoAP, for else)
• Lifecycle stages and transition through them Step 2 was already kicked-off (my understanding) but is not yet completed in WoT-Arch (my understanding again). In the best case, everything is there (then closing corresponding issues should be sweatless)

Step 3: use the outcome of step 2 in WoT-Sec to dive concrete things deeper:

• How many (native) authentication schemes (and their options) do we have to consider in the addition? What are they?
• What are their prerequisites? How to fulfill them
• Does this result in authentication silos?
• Is this an issue (it is a difference whether authentication scheme A with prereq A' is different to B and B' but they never appear in one site vs. they do)?
• If yes: what to do in the intervall [describe it as it is...worry about uniform experience for users across protocol subdomains and thing lifecycle]
• etc Step 3 depends on step 2; can deal with concrete abstractions (Caveat: step 3 might become complex - depending on the exact outcome of step 2 => should probably get a new issue and possibly also split into manageable chunks)

Step 4: deal with the wildcards on a more abstract level (giving guidance rather than being concrete). It is quite likely that there will be wildcards in the response to step 2 (guess nobody would want to exclude the coverage of the still to-be-invented IoT protocol) Step 4 is semi-dependent from step 2 (less than step 3). It seems possible to get this started more early (after step 1) as this could be a corollary to step 1 (at least partially) in sense of: no matter what the details of will be it is likely that it makes a difference if one talks to "Home" vs "Mafia" (making a case for authentication), addressing that can be expected to have something to do with matching "expected" (="Home") vs. actual (="Home" or "Mafia") etc

[mlagally]

"Thing authentication" in WoT essentially matches "server authentication" in the traditional (human user-centric) Web

The discussion in this issue seems to make a couple of baseline assumptions, such as the usage of TLS, HTTP, X509 certificates and a strict client server model.

I believe this is narrowing down the problem space too much at this point of the discussion. What about pub/sub? Other authentication mechanisms, e.g. via distributed ledgers, other protocols?

We should first make sure to have the authentication use cases outlined to make sure to gather the appropriate requirements.

A few examples (using architecture terminology):

• A thing wants to send messages to a consumer. Before this is permitted, the consumer has to ensure the authenticy of the thing.
• A consumer wants to read a property or invoke an action. To do this, the consumer must be trusted, i.e. the thing must ensure that the "right" consumer is using it.