[email protected] wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-17
notes:
new section 5.3. Registrar Authorization of Pledge
new section 9.1. DoS against MASA
also:
1.3.4. Bootstrapping is not Booting
This document describes "bootstrapping" as the protocol used to
obtain a local trust anchor. It is expected that this trust anchor,
along with any additional configuration information subsequently
installed, is persisted on the device across system restarts
("booting"). Bootstrapping occurs only infrequently such as when a
device is transfered to a new owner or has been reset to factory
default settings.
The yang tree diagram changed from +---- to +--, and I don't know the
signficance (if any) of that.
9.1. DoS against MASA
There are uses cases where the MASA could be unavailable or
uncooperative to the Registrar. They include active DoS attacks,
planned and unplanned network partitions, changes to MASA policy, or
other instances where MASA policy rejects a claim. These introduce
an operational risk to the Registrar owner in that MASA behavior
might limit the ability to bootstrap a pledge device. For example
this might be an issue during disaster recovery. This risk can be
mitigated by Registrars that request and maintain long term copies of
"nonceless" vouchers. In that way they are guaranteed to be able to
bootstrap their devices.
The issuance of nonceless vouchers themselves creates a security
concern. If the Registrar of a previous domain can intercept
protocol communications then it can use a previously issued nonceless
voucher to establish management control of a pledge device even after
having sold it. This risk is mitigated by recording the issuance of
such vouchers in the MASA audit log that is verified by the
subsequent Registrar and by Pledges only bootstrapping when in a
factory default state. This reflects a balance between enabling MASA
independence during future bootstrapping and the security of
bootstrapping itself. Registrar control over requesting and auditing
nonceless vouchers allows device owners to choose an appropriate
balance.
The MASA is exposed to DoS attacks wherein attackers claim an
unbounded number of devices. Ensuring a registrar is representative
of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained
devices. Supply chain integration ("know your customer") is an
additional step that MASA providers and device vendors can explore.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
