Subject: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

From: Christian Huitema <[email-masked]>
Date: Sat, 29 Sep 2018 16:08:53 -0700

Reviewer: Christian Huitema
Review result: Has Issues

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Sep 2018 11:52:49 -0700

christian,

a stunning review as usual.  but i have two questions which you kind of
finessed.  they are simple binary, i.e. yes/no, questions that the end
user, to whom the IETF is ultimately responsible, really cares about.

if the manufacturer's servers go down, either permanently or even for
a day, does the device i have purchased still work?  i.e. is it fail
soft? [0]

if the manufacturer's servers go down, either permanently or even for
a day, can i give/sell the device i have purchased to a third, well
fourth i guess, party, at my whim and seamlessly unencumbered?

fwiw, i asked these same questions at the 2005 paris side meeting at
l'ecole whatever hosted by mark.  the blank stares i received alarmed
me.  the ietf is ultimately responsible to the users.

thanks.

randy

--

0 - yes, i understand i may not be able to access it through the
    manufacturer's cloud.  so you want to help look at tcpdumps of
    the manufacturer installed thermostat that does not talk to that
    mfgr on net that i am debugging this weekend?  :(

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 1 Oct 2018 08:58:06 +1300

> a day, does the device i have purchased still work?  i.e. is it fail

It still works if and only if the registrar already holds its voucher. 

There's a related question, which is: if the autonomic network is
air-gapped from the Internet, as is very likely in many sensitive
applications, does the whole mechanism work at all?

The answer is, as I understand it, yes, but with a variant. See option 3
in section 6.3. "Registrar security reductions", which explicitly covers
the case of obtaining vouchers in advance from the MASA.

The BRSKI authors regard this as less secure than relying on the MASA
in real time. You might have a different opinion, if you were operating
the air-gapped network. My personal opinion is that this will be a 
widely used solution, whatever its security issues, because it avoids
MASA dependency.

> fourth i guess, party, at my whim and seamlessly unencumbered?

There are two conditions for it to work as I understand:
1) The device ID is added to the list of devices acceptable to the
registrar in its new network.
AND
2) That registrar is able to contact the MASA.

Alternatively - see the previous point. If you had previously obtained
a voucher in advance, you could include it with the device. Just as
you might write the hard disk password on a yellow sticky when
selling a laptop in a garage sale.

    Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 30 Sep 2018 16:06:03 -0400

That answer seems to imply that if the MASA is down before I try to 
transfer my device, and if the MASA is still down when the recipient 
tries to get my device working, it won't work.

Which seems to mean that once a MASA goes down permanently, any new can 
not get a device reliant on that MASA to work.

Seems a pretty severe limitation.

Yours,
Joel

>> user, to whom the IETF is ultimately responsible, really cares about.
...

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Sep 2018 17:29:27 -0400

> a day, does the device i have purchased still work?  i.e. is it fail

First, BRSKI as used by ANIMA is specifically not targetted at Things.
(We are developing profiles of BRSKI that are about Things, but I think that
this internet-draft should not be be evaluated on that basis).

It's targetted at routers and other devices found at ISPs or Enterprises.

Whether or not the device continues to work after you take onwership is not
about this protocol.

Second, the only time the manufacturer's servers need to be alive is when
device ownership is claimed.   Once the device is claimed, it joins *YOUR*
network, and trusts your infrastructure, not the manufacturer.  Whether or
not the device will *operate* without the manufacturer's servers is really
outside of BRSKI.  However, if anything, we feel that as BRSKI creates a
strong connection between the device (the "pledge"), and the owner, that it
is much easier for the device to operate under the control of the owner
rather than exclusively the manufacturer's servers.

Joel M. Halpern <[email-masked]> wrote:
    > That answer seems to imply that if the MASA is down before I try to transfer
    > my device, and if the MASA is still down when the recipient tries to get my
    > device working, it won't work.

    > Which seems to mean that once a MASA goes down permanently, any new can not
    > get a device reliant on that MASA to work.

    > Seems a pretty severe limitation.

You are answering a different question than Randy asked, I think.
You are answer the question about whether the device can be resold.

This is a pretty important question and we have discussed it at length.
I remain concerned, but as far as I can see, we have this problem already.

It fundamentally depends upon a number of things which unfortunately, the
manufacturer has ultimate decision making about.  I hope that the market
will express itself, and the answers will result in environmentally
sustainable solutions rather than landfills.

Those things are:
   1) trivially, is the manufacturer alive, and willing to issue a new
      voucher to a new owner.  This is the easiest situation.

   2) if the manufacturer's software allows the domain owner to replace the
      MASA trust anchor with another one, then a different MASA could authorize
      the resale.

   3) if the manufacturer allows the entire software stack to be replaced,
      then in effect, a new manufacturer can be selected. (Think OpenWRT
      here)

In essence, all of these questions are about the degree to which the
manufacturer lets the owner control the software.  This is a tussle between
manufacturers that want to control it all, and owners who feel they should
control what the system does.

We think that BRSKI does not force either situation, but does deal with
some situations where a third party has inserted software between the point of
manufacturer and the owner.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Sep 2018 19:09:47 -0400

Christian, thank you for the review.

I have opened issues for each of the points you raise so that we can better
keep track of your comments.  Please see:
     https://github.com/anima-wg/anima-bootstrap/issues

I think that we authors will consider if we need to clarify any text to deal
with your comments, and if so, we'll post those changes/diffs.

Otherwise, we'll start a sub-thread of this email for the various cases.
Should we continue to CC [email-masked], or will secdir + anima do?

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Sep 2018 22:42:55 -0700

> a day, does the device i have purchased still work?  i.e. is it fail

My understanding is that, yes, the device that you have purchased and
installed still works. BRSKI is a bootstrap service, and as Michael
Richardson says, the dependency is only there during the bootstrap, i.e.
between the time you unwrap the device and the time initialization on
your network is complete.

The "soft fail" happens if devices need to be reset to factory settings
for some reason, then you will have to wait for the manufacturer's
servers to bring them back up. That may be mitigated if the manufacturer
provided you with nonceless vouchers, valid until "time=X", and in
particular if the manufacturer gave you vouchers "good until infinity".
In that case, your old devices could still be reset to factory condition
and restarted, without even "soft fail".

> fourth i guess, party, at my whim and seamlessly unencumbered?

It depends somewhat on the type of voucher that the manufacturer is
willing to give you, but the short answer is No, you can't.

If the manufacturer only wants to provide real time vouchers that
incorporate the random nonce issued by the device, then the answer is
very clearly no, you cannot resell the device without approval from the
manufacturer. The voucher in that case acts as a kind of DRM.

If the manufacturer is willing to issue "good until time=X" vouchers,
then in theory you could provide the voucher to your buyer, provided the
time limit of the voucher has not elapsed. If the manufacturer signs a
voucher "good until infinity", then the device can in theory be sold and
resold forever. But that's probably not true in practice, because the
voucher is written for a specific domain, and includes the certificate
of the domain for which the voucher is good. You may be able to play
games with some kind of certificate chain and make it work, but I will
believe that when I see it.

> me.  the ietf is ultimately responsible to the users.

The BRSKI specification is a tradeoff and that's why I would really like
to see the tradeoff explained in clear terms in the spec. It is designed
to prevent hijacking of the device during its registration in the
buyer's network.

If BRSKI implemented a pure RFC 7030 process, the device  might have to
accept to be imprinted by the
registrar without having verified to whom it is talking. In practice
that would mean relying on some kind of physical security, or maybe
relying on the kind of trust anchors commonly used for web services.
From the registrar point of view, the failure mode is that some kind of
man-in-the-middle inserts itself during the registration process, and
maintains control of the device after it is connected to the network.

The voucher system mitigates that risk, but at the cost of strong
dependency on the manufacturer. As I say, that's a trade-off, and I
could see different buyers having different opinions on that dependency.
In fact, I could see buyers willing to buy devices only if they
permitted "voucher-less" initialization. If the standard allowed that
option, then market forces would quickly define how valuable the voucher
system is.

-- Christian Huitema