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 <[email protected]<mailto:[email protected]>>
wrote:
Hi Adam
On 12 Jul 2019, at 00:25, Adam Roach
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
