Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

["Max Pritikin (pritikin)" <[e-mail]>]

FYI what you all are discussing are potential changes to the normative language of
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-22#section-7.2

Probably strengthening this paragraph from MAY/SHOULD to a MUST:

   3.  The pledge MAY have an operational mode where it skips voucher
       validation one time.  For example if a physical button is
       depressed during the bootstrapping operation.  This can be useful
       if the manufacturer service is unavailable.  This behavior SHOULD
       be available via local configuration or physical presence methods
       (such as use of a serial/craft console) to ensure new entities
       can always be deployed even when autonomic methods fail.  This
       allows for unsecured imprint.

If this is a suggested change please comment on the subsequent paragraph which reads:

It is RECOMMENDED that "trust on first use" or any method of skipping
   voucher validation (including use of craft serial console) only be
   available if hardware assisted Network Endpoint Assessment [RFC5209]
   is supported.  This recommendation ensures that domain network
   monitoring can detect innappropriate use of offline or emergency
   deployment procedures when voucher-based bootstrapping is not used.

The use of SHOULD and RECOMMEND are strong indicators of how this should be done. As much so as a MUST "security requirements we write into our specs, we'll have no means of enforcement”.

Since Eliot has brought up other options like being able to replace the MASA trust anchors or some form of  “self emitted” voucher here are the current thoughts along those lines:

If one possessed a nonceless voucher then one possesses a permanent token to enable bootstrapping of the device. This is the very first point in section 7.2 discussed above:

   1.  The pledge MUST accept nonceless vouchers.  This allows for a use
       case where the registrar can not connect to the MASA at the
       deployment time.  Logging and validity periods address the
       security considerations of supporting these use cases.

There are two ways to leverage this. Predominately his means that after a single BRSKI exchange any domain owner can opt out of any future BRSKI stuff and still be able to (re)perform over-the-wire bootstrapping (this is of course captured in the audit log). Additionally the privacy protections mean that this voucher can be tied to a transient keypair that could be distributed with the device for resale. So this can be passed on to entities further down the supply chain or during a resale of the device.

These two methods hit a large percentage of use cases being discussed while maintaining the audit log.

- max

On Jul 12, 2019, at 1:27 AM, Eliot Lear <[e-mail]<mailto:[e-mail]>> wrote:

Hi Adam

On 12 Jul 2019, at 00:25, Adam Roach <[e-mail]<mailto:[e-mail]>> wrote:


The smallest change that would satisfy my concern would be a statement that says that devices conformant to this specification MUST contain a local means of bootstrapping that does not rely on any specific server being available. As with the security requirements we write into our specs, we'll have no means of enforcement. But as with the security requirements we write into our specs, we'll give interested parties just that little bit more leverage that might tip the scales towards the correct behavior.


I think this is easily possible within the paradigm of the document after the device has first been onboarded. At this stage, I would also suggest that the MUST be a SHOULD for another reason: there may be cases where it is in the customer best interest to prevent onboarding of a device just through proof of possession.  I am thinking of anti-theft mechanisms.  Having a discussion of this and the risks of not having any on-prem method ever seems like a reasonable add.

Eliot