Open OliverPfaff opened 4 years ago
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.
Discussed in meeting:
Next step: PR with some suggested changes; at first, a PR just to summarize existing Web server authentication mechanism.
Short update: did not yet have a chance to talk to Sebastian (needed to get some more details as input)
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:
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.
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.
Unassigned myself - no current action to me (my reading)
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.
Meeting 2020-04-20:
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.
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)
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.
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.
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:
Step 3: use the outcome of step 2 in WoT-Sec to dive concrete things deeper:
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
"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):
"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)