Subject: Re: Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Oct 2018 14:47:30 +0200

Hi Christian,

On 01.10.18 07:42, Christian Huitema wrote:
> 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.

IMHO it should be possible as an option to not pin the domain.  In that
case, a voucher could be a scannable label or BOM that can be handed off
directly with the device.  Obviously that's a nonceless option as well. 
Think of it as a file that one simply uploads to the registrar.  The key
thing here is that the manufacturer needs to make the decision for which
devices it wants to do this.  This would also solve [6] in your list of
issues.  However, this mitigation will not always be appropriate,
particularly for devices that may transit from one network to another,
or where it is simply inconvenient to retain a label.

Addressing some more of your LC comments:

> 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.

This can be mitigated by onboarding devices in inventory *before* the
emergency.  It could also be mitigated as per the above.

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

Let's be clearer, because there are two separate threats:

 1. A compromised end point inappropriately being onboarded in order to
    attack a network; where the registrar is validating the signature
    and certificate; and
 2. A perfectly fine endpoint being inappropriately onboarded to an
    unauthorized network; where the endpoint is validating the signature
    and certificate.

Also, I think you are referring to the *private* key associated with a
vendor certificate.  [1] can be mitigated by the registrar by the vendor
reissuing the voucher signing cert and checking a CRL.  [2] requires a
bit more care and a backup certificate of some form.

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

Old certificates never die.  They just fade away.  More seriously, if
the cert is used, it should be kept available, unless a backup is also
provided.

> 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? 

In a wireless scenario this could be problematic, since the device could
imprint on the first network seen.  This presumes something like
draft-lear-eap-teap-brski.txt.  We haven't gotten that far, but it is
clearly an issue and something we want to discuss in Bangkok.  In a
wired environment this is less of an issue, although there are still risks.

> 8) Attacks by the device. What happens if a device refuses to be imprinted?

It will not be able to trust the local environment, and may not be able
to retrieve a local certificate.  I presume lots of issues would crop up
from there.
> 11) Attacks by the MASA. What happens if the MASA refuses to provide a voucher,
> or provides a wrong voucher? 

Same as above.  There is a mitigating factor against this behavior: the
cost of a support call.

> 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?

Then we have bigger fish to fry.  The device's crypto is broken.

> 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?

It's a prerequisite, so...
> 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?

This could be mitigated by using unpinned vouchers that come with the
device.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Oct 2018 12:36:56 -0700

>> 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]
> 
> 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.

i missed where i said light bulbs.  i do have some of those, but i run
routers, servers, etc.; and do not want $vendor to break my network for
*any* reason.

> Second, the only time the manufacturer's servers need to be alive is
> when device ownership is claimed.

i.e. when i sell the router to some other op.  that was my second
question.

> 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.

ahhh.  we just sell the guns, we do not say how they are used.

>> 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

no.  he is speaking to the second question i asked.  and his answer
deeply concerns me.

> 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.

if i understand correctly, it creates a new problem, needing the
manufacturer's consent for me to resell my light^Hrouter.

> It fundamentally depends upon a number of things which unfortunately, the
> manufacturer has ultimate decision making about.

see above about guns

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Oct 2018 10:44:56 +1300

> ahhh.  we just sell the guns, we do not say how they are used.

It's not quite that.

We sell X's. We cannot control how the X's are used. But if they
are used without calling home to our MASA, we cannot certify that they
are genuine X's. They might be counterfeit X's.

BRSKI is a way of proving that the X announcing its identity as
X12345 really is the one and only X12345.

If you sell it to someone who doesn't care about that, they can use it
anyway.

Anyway, that's how I understand it.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Oct 2018 15:44:51 -0700

> 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.

when i sell the lightb^Hrouter to mary, of course i reset to factory
settings.

> 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".

dear world: be absolutely sure that, when you buy a lightb^Hrouter,
you get a nonceless voucher with an infinite lifetime.  before handing
them your cash, you can test this by ....

right

how about the spec says that "the manufacturer MUST accompany the
lightb^Hrouter with a nonceless voucher with an infinite lifetime.
purchasers who, for whatever reason, with more restricted vouchers
may negotiate."

>> 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?
> 
> 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.

then i strongly object to the ietf specifying this; c.f. selling guns.
 
> believe that when I see it.

i.e. practically you can not resell something you thought you had
bought.  baaaaaad.

> 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, to actually own a device i bought, i need to manage my own security,
then i will take that.

> 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.

two problems.

the buyer will not realize that they just rented the lightb^Hrouter
until they go to sell it; way too late to do anything about it.

the manufactures have very small incentive to lower drm barriers.
i can point to a jillion current examples.  my favorite of the week is
john deere.

randy

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Oct 2018 08:53:30 +0200

> when i sell the lightb^Hrouter to mary, of course i reset to factory

Great.  Mary can register the device with light^hrouter manufacturer and
life goes on.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 04:21:25 -0700

> Great.  Mary can register the device with light^hrouter manufacturer
> and life goes on.

iff the manufacturer still exists and the manufacture is willing.

you and others seem to be missing that there is a major right of
ownership war going on out here in the real world.

randy

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Oct 2018 14:28:28 +0200

Randy

> ownership war going on out here in the real world.

I think we've lost sight of what we're talking about.  We're talking
about a completely automated method for a local trust anchor to be
installed on a device, and a kick to EST for the device to receive a
local credential.  For that to happen there needs to be a trusted
introduction, and the device manufacturer or its agent is in the best
position to do that.

There are many ways for a manufacturer to lock a device to a deployment
without this, just one example being a software license that gets erased
on device reset (remember?  you said you were going to perform a device
reset).  I'd suggest that we not get wrapped around the axle over the
ownership war. 

I would be more concerned about what happens if the manufacturer goes
out of business.  I think that's a bigger deal, but can I ask that we
also consider that problem with some more experience under our belts?  I
could easily envision a few solutions, but better would be to face down
the problem with some more code and deployment.  BTW, manufacturer going
out of business also means no more {bug fixes, security patches, h/w
support, etc}, and so zooming in and just dealing with this may be
suboptimal.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 05:41:42 -0700

> introduction, and the device manufacturer or its agent is in the best

no.  the owner's trust controller is.

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Oct 2018 14:20:02 -0400

> support, etc}, and so zooming in and just dealing with this may be

The manufacturer-going-out-of-business use case argues for there being a way that a person with physical access to the unit can re-key it without contacting the manufacturer.   It also argues for open source, but that's out of scope. :)

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 11:32:41 -0700

>> designed to prevent hijacking of the device during its registration
>> in the buyer's network.
> 
> By the way, there are many cases where the buyers and the
> manufacturers interests are well aligned, besides just securing the
> bootstrap. For example, consider the "router fell from the back of the
> truck" scenario.  I assume that both the original buyer and the
> manufacturer will be interested to find out who the second hand buyer
> is.

yep.  i like the idea of find my iphone, though it has not helped find a
lost phone for me.

but it is MY choice to use it.  MY choice to register the phone with
apple's add-on service.

to quote myself from a private thread

> i might have other relationships with the manufacture or third
> parties, such as warranty, add-ons with non-ownership, color-matched
> magenta paint, etc.  but when i purchase the bleeping thing, i bloody
> own it.

randy

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Oct 2018 11:26:48 -0700

On 9/30/2018 10:42 PM, Christian Huitema wrote:

> 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.

By the way, there are many cases where the buyers and the manufacturers
interests are well aligned, besides just securing the bootstrap. For
example, consider the "router fell from the back of the truck" scenario.
I assume that both the original buyer and the manufacturer will be
interested to find out who the second hand buyer is.

-- Christian Huitema