I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I reviewed version 16 of draft-ietf-anima-bootstrapping-keyinfra, specifying
Bootstrapping Remote Secure Key Infrastructures (BRSKI). It is part of the
"autonomic networking" specifications developed in the Anima WG. It describes processes for
enrolling devices in an "Autonomic Network", with the assistance of a voucher service
provided by the vendor of the device. This review will start with a summary of the BRSKI
processes, as I understood them from the document, before focusing on security
considerations. The whole system appears well engineered, but it is quite
complex, requiring interactions between three parties. My main problem is that
neither the document in general nor the security section in particular delineates the threats
that the protocol is protecting against, and that the protocol as it stands gives a lot
of control to manufacturers on the deployment of devices in their customers' networks.

BRSKI uses Enrollment over Secure Transport (EST, RFC 7030) to enroll new devices into a domain.
Doing that requires solving a set of issues, such as whether the device should accept to be
enrolled in the domain, whether the domain should accept the device, and whether all of that
can be achieved safely. The constraint is that devices come out of the manufacturing chain
with only generic configuration, such as device identifiers or manufacturer certificates,
but without any destination specific configuration information. In BRSKI, this is
described as a "drop ship" model, in which devices are shipped with their "factory default".

The EST enrollment process assumes mutual authentication of the device and the registrar
using TLS. The registrar can verify the "initial device identifier" per 802.1AR, but the
device itself has no knowledge of the domain that it will join. For the initial TLS
connection, the device cannot verify the registrar certificate and will simply accept
it. 

This is similar to the "resurecting duckling" methaphor, inspired from Karl Lorentz' 
observation that a new born ducking accepts the first duck that its sees as its mother. 
The duckling thus gets "imprinted" to allways follow its "mother". In BRSKI, the equivalent
is that the device will be "imprinted" to trust the first qualified "registrar" that it
discovers.

There is always a risk that the duckling sees a wolf before seeing its actual mother, with bad
consequences for the duckling. In BRSKI, the equivalent would be a device captured by a
different registrar than the intended owner. In BRSKI devices mitigate that risk by requesting
a voucher (RFC 8366) from the registrar before proceeding with enrollment per RFC 7030. The
voucher are provided by the Manufacturer Authorized Signing Authority (MASA) service and thus
can be verified by the device. They effectively authorize the registrar to take ownership of a
device.

BRSKI supports several types of voucher: either vouchers including a nonce specified by
the device, or vouchers specifying an expiration date. Nonced vouchers must be provided
in real time by the manufacturer or vendor of the device. Nonceless vouchers may be
provisioned in advenced, possibly as part of a procurement application.

BRSKI specifies a rather complex three-parties process between device, domain registrar
and proxy, and vendor or manufacturer provided voucher service. The security section
mentions some potential issues with non cooperating vendors, but it does not feel
comprehensive. It lacks an actual security analysis, looking at the list of threats.
On the top of my head, I could think of a few issues:

1) Denial of service against the vendor MASA service. Adversaries could mount an
attack against the service at a critical time, preventing real-time issuance of
nonced vouchers. This could for example prevent the deployment of autonomic networks
during emergencies.

2) Compromise of the vendor's public key. This would allow attackers to get
"ugly ducklings" imprinted in the domain.

3) Rotation of the vendor's public key. This could prevent old devices from
joining the domain, or from verifying the new vouchers.

4) Abuse of long duration timeless vouchers by a previous owner. This is
discussed in the security section.

5) Device tampering during the drop ship process, maybe by some kind of
Tailored Access Operation group. I think that BRSKI does nothing against
that attack, but maybe we should just say so.

6) No "ship and forget" operation. BRSKI supposes continuous involment of
the manufacturer during the deployment process. This means that a whole
class of inexpensive devices are out of scope. This is a tradeoff between
usability and some security properties, and the tradeoff should be
explained.

7) The closest to ship and forget is a MASA service configured to always
issue vouchers, regardless of the device ID and the registrar domain. I would
expect that to be popular with some manufacturers. It is mentioned in
section 6.4, which recommend that manufacturers should not do that. What
are the consequences if they still do? 

8) Attacks by the device. What happens if a device refuses to be imprinted?
I suppose someone will have to "resurrect the duckling". How costly is that?

9) Attacks by the device, pretending to be an infinity of virtual devices.
This is listed in the security considerations.

11) Attacks by the MASA. What happens if the MASA refuses to provide a voucher,
or provides a wrong voucher? Can the MASA be used to restrain commerce
with specific countries? Is that a feature or a bug?

12) Device implementation of random numbers. The draft discusses management of 
time in a drop ship device, but what about the management of random numbers? For
example, what if poorly manufactured devices always generated the same nonce,
or a predictable nonce?

13) Device individualization. The drop ship model assumes that devices are
shipped with factory default, but BRSKI also assumes that devices come with
individuals ID and certificate. This requires a specific per device step in
the manufacturing process. Some makers of inexpensive devices don't do that,
and ship devices that are all strictly identical. How does that affect the
BRSKI process?

14) Privacy considerations. Third parties will be able to observe traffic
between domain registrar and service provider MASA. They will at a minimum
be able to learn that domain X is a customer of provider Y. Can they do more?
The communication is protected by TLS. How much is revealed by clear
text components like the SNI? How much can be obtained by traffic
analysis?

Several of the issues listed above can be construed as potential operation
problems, not just security issues. They can be the result of honest mistakes
or implementation errors. 

-- Christian Huitema