Subject: [Anima] EST (EST-COAP) usage vs BRSKI

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Oct 2018 17:36:07 -0400

Max,

While implementing pure enrollment code for EST-COAP testing, I have realized
that on the Registrar there is a state which we may not have adequately
discussed.

While 2.1 provides a nice diagram for the Pledge, when we changed the view of
things we lost some of the state machine thoughts from the Registrar point of
view.  For a pure first-time enrollment, there is not a lot of issue.

The issue comes when one tries to combine a few functions in a registrar.
(BTW: I had advocated splitting these into seperate servers and ports)

When a registrar receives a connection from another node, it examines
the TLS Client Certificate and may categorize it into three possible things:

1) This is an LDevID certificate (possibly recently expired, see LAMPS), and
   the node is about to as for a simpleenrollment to renew it!

2) This is an IDevID certificate from a manufacturer which implements BRSKI
   (and which is in the whitelist) and which is expected to do voucher processing.

3) This is an IDevID certificate from a manufacturer/device which has a known
   anchor, just does EST enrollment, and already trusts the Registrar via "magic".

Part of my surprise was that I realized that the TLS connection is never
really "provisional" from the Registrar point of view.   It's either
authenticated by the IDevID/manufacturer-certificate, or via the LDevID.
Or the client certificate does not lead to any reasonable trust anchor, and
the connection is to be rejected.  Unless the Registrar is "promiscuous",
which is to say has a "*" in the anchor whitelist.

It seems to me that like we either ought to fail the TLS connection in a very
clear fashion if the client certificate is unacceptable, or we need to have a
very clear 5xx return to all operations if we think it's a good idea to let
the connection persist. (Caveat, we might actually want to log the telemetry
status operation, and perhaps we always return 200 for that)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-