Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote:
    >> There does not otherwise seem to be any risk from this compromise to
    >> devices which are already deployed, or which are sitting locally in
    >> boxes waiting for deployment (local spares).  The issue is that

    > (That is, if the boxes are already in local storage at the time of
    > first compromise)

yes. If you have physical care of them, then nobody could have tried an
attack while the MASA signing key was compromised.

    >> The authors are unable to come up with an attack scenario where a
    >> compromised voucher signature enables an attacker to introduce a
    >> compromised pledge into an existing operator's network.  This is the
    >> case because the operator controls the communication between Registrar
    >> and MASA, and there is no opportunity to introduce the fake voucher
    >> through that conduit.

    > This seems predicated on the attacker having the MASA signing key but
    > not persistent control of the (formerly?) legitimate MASA service,
    > right?

yes, that's right.  Assume the key was generated in a deterministic way
(the way the SSH keys were), or brute-forced, or something like that.

    >> A key operational recommendation is for manufacturers to sign
    >> nonceless, long-lived vouchers with a different key that they sign
    >> short-lived vouchers.  That key needs significantly better protection.
    >> If both keys come from a common trust-anchor (the manufacturer's CA),
    >> then a compromise of the manufacturer's CA would be a bigger problem.

    > (probably some wordsmithing options for "be a bigger problem")

how about:
              If both keys come from a common trust-anchor
              (the manufacturer's CA), then a compromise of the
              manufacturer's CA would compromise both keys.  Such a
              compromise of the manufacturer's CA likely compromises
              all keys outlined in this section.


-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-