Re: [Anima] teap-brski

[Michael Richardson <[e-mail]>]

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [