Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG

[Brian E Carpenter <[e-mail]>]

I think it's worth adding that BRSKI was designed for a specific purpose, namely enrolling *only* a set of authorised autonomic nodes into an autonomic control plane, not for enrolling everything in sight (or do I mean "in site"?) into a data plane. It was designed as an integral part of the ANIMA framework (see https://tools.ietf.org/html/draft-ietf-anima-reference-model). BRSKI may prove to have more generality than that, but it wasn't an explicit goal.

We were always aware of SZTP while BRSKI was developed, and vice versa, but it wasn't a competition.

Regards
   Brian Carpenter

On 12-Sep-19 08:30, Kent Watsen wrote:
> 
> Hi Mohit,
> 
> 
>> Could you explain the high-level differences between BRSKI and SZTP for those like me who are not extremely familiar. 
>>
>> I know there are probably many differences. For example, I see that the SZTP spec says that devices can receive initial bootstrap information over DNS or from a bootstrap server.
>>
>> What I am trying to understand is what does a device start from (shared-secret/ephemeral key pair/manufacturer certificate), and what does it end with? Do we need both SZTP and BRSKI?
>>
> Top of mind.
> 
> 
> Preconditions:
> - SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMMENDED), alternate credentials possible.  Optional list of TA certs for validating SZTP servers.  Optional list of TA certs for validating vouchers.
> - BRSKI: IDevID MUST.  List of TA certs for validating vouchers MUST.
> 
> Normal Operations:
> - SZTP: many modes here, some doesn't require networking.  Vouchers only needed when TLS can't be used or trusted.   Vouchers, when used, are primarily long-lived, but MAY be ephemeral (e.g., nonced).  Primarily with strong ownership verification, but weaker forms are possible.
> - BRSKI: singular mode (pledge looks for a Registrar).  Vouchers are always used and are primarily conceived to be ephemeral (nonced) with a MASA that maintains a log; long-lived Vouchers and strong ownership-verification are possible.
> 
> Postconditions:
> - SZTP: a "payload" that could be as small as a script or as large as instructions for updating the OS image + setting an initial configuration.
> - BRSKI: a domain certificate.  Additional mechanisms needed to get device into a managed state (this is what some of the other ANIMA drafts are for)
> 
> 
> I think I got the BRSKI parts right, but hope folks will chime in if anything is misrepresented or underrepresented.
> 
> Kent
>