Subject: Re: [Anima] Question on draft-ietf-anima-voucher-06 (fwd) Michael Richardson: Re: Question on draft-ietf-anima-voucher-06

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Dec 2017 10:48:01 -0500

Forwarded with permission.

Subject: Re: Question on draft-ietf-anima-voucher-06
From: Michael Richardson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], IESG <[email-masked]>
Date: Wed, 13 Dec 2017 10:13:04 -0500
List-Id: <[email-masked]>

Let me answer this in two emails, because I want to make sure that we are on
the same page before continuing.   I also want to note that some of these
remarks are specific to how BRSKI uses audit-vouchers.

There are other uses of vouchers (including NETCONF), and some of them do not
need audit-vouchers or would accept audit-vouchers.

Eric Rescorla <[email-masked]> wrote:
    draft> Audit Voucher: An Audit Voucher is named after the logging
    draft> assertion mechanisms that the Registrar then "audits" to enforce
    draft> local policy. The Registrar mitigates a MiTM Registrar by auditing
    draft> that an unknown MiTM registrar does not appear in the log
    draft> entries. This does not directly prevent the MiTM but provides a
    draft> response mechanism that ensures the MiTM is unsuccessful. This
    draft> advantage is that actual ownership knowledge is not required on
    draft> the MASA service.

    > Can you walk me through the attack in question and how
    > auditing/logging
    > detects it, because I'm really not following from this document.
    > I'm
    > sure I'll have more questions later but I think I need to
    > understand
    > this one first.

You will recall the light-bulb attack you postulated at the 2012 IoT Security
Workshop.   The threat was that an attacker that could control millions of smart
light bulbs, would be able to turn them all on and off at the same time,
causing stress and possibly damage to the electrical grid.

The postulated situation was that attacker wanders through DIY store (Home
Depot, etc.) or better yet, works there.  They remove light bulbs from
packages (carefully), go through the official imprint situation and then as
the official owner, replace the firmware with one that they have control
over, and then they "factory" reset the device (and put it back in the
package) such that the end purchaser is unaware that the firmware is
trojan'ed.   For the purposes of this discussion, let's assume that the
IDevID certificate and private key is secure in a tamper-proof TPM.

I'll stop here because I want to make sure that we agree on the attack.

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

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