In a private thread on teap-BRSKI, it was asked how the BRSKI Registrar
("server", aka "authentication server" in 1X terminology) validates the
provisional TLS connection with the pledge (aka "supplicant").While there are a number of possible operational modes for BRSKI, but in all of them, the authentication of the pledge IDevID comes back to RFC7030, https://tools.ietf.org/html/rfc7030#section-3.3.2 The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. i.e. the Registrar has a list of trust anchors for the manufacturers that it expects to have join. This clearly is a difficulty for most residential applications and an operational headache for industrial uses. So the question then becomes, how does the Explicit TA database get easily extended? My suggestion, and this is entirely an implementation detail, is that a Registrar accept, but fail, connections from devices with unknown manufacturers, and then ask a human. I've never liked the "TOFU" term, because many use it to mean "SSH-client" like, and but SSH clients do not trust on first use. They ask human on first use, and then pin (AHFUTP is way less pronounceable than TOFU). And it's AHFUTP is what we want. A registrar could go further, contacting the MASA and attempting to obtain a voucher. A registrar could assign some higher value to a MASA that can be validating via public WebPKI when asking a human. There is an extension point here that we could consider: a Registrar could ask the MASA for a list of trust anchors used to sign IDevID. This could be the /.well-known/est/cacerts end point; it's certainly correct from the MASA point of view, but maybe it's an abuse. I don't feel strongly either way. This would validate the Manufacturer's IDevID CA using the TLS connection validated by the WebPKI. Many would find this acceptable, but perhaps some would not.
-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
