Subject: Re: [Anima] 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: Michael Richardson <[email-masked]>
Date: Mon, 01 Oct 2018 20:28:08 -0400

> routers, servers, etc.; and do not want $vendor to break my network for

Then I suggest that you never patch the OS or apply firmware updates :-)

The reality is that they can break your network trivially if they want to.
But, you have a contract that says that they won't do that.

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

Yes, so when you sell the router, whether or not the buyer gets firmware
updates, the export firmware, or even a license is also up to the vendor, and
so the vendor already has a say.  This really changes nothing, except that it
formalizes the arrangement in computer code rather than legal code.

I'm not particularly happy about this, btw, but I don't see a way to both do
secure imprinting and liberate the end user from vendor control.  If you have
a way to solve this tussle, I'd really like to know.

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

naw, we just sell 3D printers, we do not say how they are used.

    > manufacturer's consent for me to resell my light^Hrouter.

Yes, but operators already had this problem.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Oct 2018 20:32:28 -0400

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

Or, they might be genuine X's running trojaned's software.

The fact that between leaving seller A and buyer C, they were activated by
attacker M will be in the MASA's audit log, if buyer C looks.

{Can attacker M replace software via serial console without leaving a trace?
Not BRSKI's problem exactly, but it's certainly a concern}

    > 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

Depending upon the software in X, you may be able to hook up a craft/serial
console and just configure it the way you want, just like you do today.

Or it might be some new-fangled SDN switch that won't operate with a
controller attached, and it doesn't even have a serial console.  Nothing I
can do will change that.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Oct 2018 21:07:04 -0400

> if, to actually own a device i bought, i need to manage my own
    > security, then i will take that.

I think that this is already the case, and I see BRSKI as a mechanism by
which to safely handoff control from the manufacturer to the owner.

If the manufacturer doesn't want to do this, BRSKI isn't very useful to
them.  They should retain control of the device via their cloud
infrastructure, and not let the end user have any control at all.

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

You are right.   But at least it's clear that john deere actually owns the
tractor, not the farmer and walk away from the mortgage.    It's not a
pretty picture, but I don't think we are making the situation worse: there is
already DRM and TPM.

What we are doing is making it clear that the tractor is actually owned,
and not p0wned.   However, I'm not sure that BRSKI has a value for large
devices with real user interfaces.  Maybe it has value for implements though.

---

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

---

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: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 15:00:45 -0400

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

    > no.  the owner's trust controller is.

Cool.  It's a relief to know that we've missed something obvious.
Could you please explain things more?

We call the owner's trust controller the "Registrar", or sometimes the
Join-Registrar/Coordinator.  I don't mind calling it a trust controller, but
maybe your term has a different meaning.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 15:05:34 -0400

Ted Lemon <[email-masked]> wrote:
    > 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. :)

The authors think that having the box rekeyed is a feature that some
manufacturers will provide, and some buyers will **insist** upon.

It has to be difficult, and in some cases, physical access may be too
insecure!

It's not much different than handing an (sometimes encrypted) QIC-tape/CD/DVD
containing source code over to an escrow lawyer, something I've regularly
done when I've worked on products with proprietary stacks.
We will see such things being discussed when we do the security review for
SUIT as well.

Being able to replace the manufacturer trust anchors for firmware, and the
trust anchor for validating ownership vouchers will become a checkmark
feature.  Any company can become Nortel.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Oct 2018 15:10:07 -0400

The problem is that possibly billions of devices will be bricked and
landfilled before this becomes the norm.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Oct 2018 21:29:40 +0200

Ted,

> landfilled before this becomes the norm.

You really answered your own concern.  Nobody would put up with such an
approach that either intentionally bricked* a perfectly functional
device.  We have to pay some attention change of ownership and
organizations going out of business.  That's work to do, not a reason to
claim the sky is falling.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 12:31:06 -0700

> Nobody would put up with such an approach that either intentionally
> bricked* a perfectly functional device.

https://www.nytimes.com/2016/01/14/fashion/nest-thermostat-glitch-battery-dies-software-freeze.html

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Oct 2018 08:46:17 +1300

> maybe your term has a different meaning.

There's a point that close followers of Anima may know and that others
don't. There is a topic intentionally missed out of the BRSKI document,
which is how the registrar decides whether a particular device, let's
say device X12345, is allowed to join the secure domain in question.

This point is skated over in the draft; in fact there is a text glitch
in section 5.2 where it should be stated, already known to the authors.
(Sorry, but we didn't find that text glitch soon enough to fix it before
the IETF Last Call.)

The actual authorization mechanism - "X12345 is allowed to join" - is
not part of BRSKI. It is, as Randy rightly implies, not the business
of the manufacturer.

The MASA is used only to verify that X12345 is in fact X12345. It's
part of the trust model, not the authorization model.

If I had my wishes, the MASA would be optional, with a local voucher
store in the registrar as the alternative. But that wasn't the WG
consensus.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Oct 2018 16:06:34 -0400

Off-list:

It sounds from you rnote like either:
1) Anima admission process is seriously underspecified in a way that 
affects itneroperability, or
2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and 
advanced (if desired) by some other working group.

I doubt either is your intention.
And statements such as Eliot's ill-formed comment that no one would do 
that do not help the case for the Anima WG having thought this through.

Yours,
Joel

On 10/2/18 3:46 PM, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Oct 2018 16:19:46 -0400

> approach that either intentionally bricked* a perfectly functional

No one would put up with it if they anticipated it.   The problem is that they might not anticipate it.   It's the kind of risk that the end user might simply not imagine.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 18:44:42 -0400

> landfilled before this becomes the norm.

It is very sad.
Maybe some will get firmware upgrades, but I doubt it.

So we should hurry up and get to his out there, so we can learn how to do it
correctly sooner.

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 15:45:59 -0700

> So we should hurry up and get to his out there, so we can learn how to
> do it correctly sooner.

definitely important to rush and not be distracted by warnings about the
model being sorely broken.

randy

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 18:53:03 -0400

> store in the registrar as the alternative. But that wasn't the WG

So you speak of non-expiring nonceless vouchers with wildcard for the domain
owner, that would come with the device?  I.e. a bearer voucher/token on a QR code.

We decided that such a thing was fraught with issues.

So we painted around it, and declared that version out of scope for now,
because we didn't think we were smart enough to figure out the security
implications of it. (We did this in RFC8366, btw)

In particular, we did not think it had a place in the medium to high-value
devices that we expect ANIMA ACP BRSKI to deal with.
[i.e. routers, VM hosts, NAS boxes... not light bulbs]

I think that there are better ways to deal with a bearer voucher,
and that a layer of intermediation would help with the issues possible
with a bearer token.  This may suit "ship and mostly forget" situation,
but I also think it's squarely an IoT application, rather than appropriate
for BFRs.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Oct 2018 13:33:19 +1300

> affects itneroperability, or

No, it's *intentionally* underspecified w.r.t. authorization. The registrar
is part of a specific autonomic networking implementation, so I think it's
OK that this is not standardized. Once there is established practice, it
might be time to revisit this.
 
> advanced (if desired) by some other working group.

I think BRSKI has the misfortune of being potentially quite general, but
it is in fact required by Anima as the basis for the initial secure
substrate.

> I doubt either is your intention.

Indeed not.

> that do not help the case for the Anima WG having thought this through.

I think it's been thought through but badly articulated. In that sense,
the Last Call is doing its job.

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Oct 2018 13:46:09 +1300

> [i.e. routers, VM hosts, NAS boxes... not light bulbs]

There are issues with not doing it too. I think the thing right now is that
the draft doesn't explain itself properly, hence this discussion.

I'm still gnawing on my original bone: if I was running a highly secure,
personnel-safety-critical network, like the particle accelerator control
network I used to run for a living, I *would not* allow it to rely on
masa.vendor.com, and it would be physically impossible to do so because
there would be no physical link anyway. I would get my vouchers some
other way. This is not light bulbs either.

I believe this can be fixed by clearer scoping of the document, and
by renaming the "lower security" section as "alternative trust models"
or something.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2018 17:52:54 -0700

> the Last Call is doing its job.

does that mean that i can stop trying for a narten medal, go back to
work, and christian will wake me up again when my two scenarios have
clear answers; one hopes ones with which i can live?

also, please tell me that i do not need to stick my nose into the rest
of anima in order to let the user unequivocally own what they buy.  i
have my own rabbit holes to pursue in the ietf.

randy

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 3 Oct 2018 01:06:35 +0000

Based on this exchange, and the arguments presented here that I observed so far, I'm with Randy. I have not seen adequate answers to his concerns (which IMHO are reasonable).

P.S. Feel free to trim the CC: list when/if responding.

P.P.S. In one of my prior incarnations many years ago, we designed a somewhat similar system, and called it "Zero-Touch Provisioning". It was a very big company, so we did not consider the possibility of it/us going out of business (and leaving the customers stranded). But if Randy's arguments were presented to our team then, we'd probably accepted them and tried to address...

Sent from my test iPhone

On Oct 2, 2018, at 20:53, Randy Bush <[email-masked]> wrote:

> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 22:35:21 -0400

Brian E Carpenter <[email-masked]> wrote:
    > I'm still gnawing on my original bone: if I was running a highly
    > secure, personnel-safety-critical network, like the particle
    > accelerator control network I used to run for a living, I *would not*
    > allow it to rely on masa.vendor.com, and it would be physically
    > impossible to do so because there would be no physical link anyway. I
    > would get my vouchers some other way. This is not light bulbs either.

So possibilities that I see:

1) you run a half-mind Registrar that is on the secure side of your air-gap, and it has
   a USB interface (or 9-track tape drive... statscan.gc.ca used to run
   unidirectional UUCP over 9-track tapes walked across the machine room air-gap)
   on which it can place voucher requests, and receive vouchers from
   other-half-mind Registrar.

   This lets you use nonced vouchers, potentially with expiry dates.
   Maybe very long expiry dates.  Or maybe your personnel-safety-critical
   equipment has a best-before date, and so it's acceptable for you to have
   vouchers only until that date.

   Also recall that we permit the Registrar to ask for, and get, voucher
   renewals at any time, so the connected ("other-half-mind") Registrar could
   always keep a live set of vouchers.

2) you use NETCONF's mechanism with vouchers that you obtain another way, and
   you place them on USB key/CDROM/QR-code.

3) you continue to configure such a network with craft-serial console,
   initiating the EST connection via some other credential.

    > I believe this can be fixed by clearer scoping of the document, and by
    > renaming the "lower security" section as "alternative trust models" or
    > something.

I accept that the document could have better text here.
At one point we discussed an operational considerations document.
Is that really what you are asking for?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Oct 2018 16:50:33 +1300

>    always keep a live set of vouchers.

Yes, that sort of solution would work.
 
>    you place them on USB key/CDROM/QR-code.

You could. But that makes me a bit nervous too. It's not far from
seeing a yellow sticky in the ops room saying "sys pw muggle3scop#"
or whatever. People who want airgap security are very cautious about
USB keys these days.

>    initiating the EST connection via some other credential.

It still doesn't scale.

> Is that really what you are asking for?

Later, maybe, but to get this draft out of the door I think we can
do a simpler fix. As Christian pointed out, there isn't really
a distinct security analysis, so I think we need to say:
This <text> is the recommencded trust model, based on an on-line
MASA. If you don't like that trust model, here are the alternatives: <text>.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 3 Oct 2018 08:20:30 +0200

Hi Michael:

>    vouchers only until that date.

One approach I would like would be to get the voucher size down to the
point where it could reasonably fit into a QR code.  Then it's a scan. 
I see that as future work.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Oct 2018 10:28:12 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> 2) you use NETCONF's mechanism with vouchers that you obtain another
    >> way, and you place them on USB key/CDROM/QR-code.

    > seeing a yellow sticky in the ops room saying "sys pw muggle3scop#" or
    > whatever. People who want airgap security are very cautious about USB
    > keys these days.

I agree, it's a bit similar.
Except that the voucher is a signed entity, and disclosing it causes privacy
issues (people know what you have), rather than being p0wned.  It can easily
go on a CDROM or something else you do trust.
A QR code is also possible, assuming your personnel-safety-critical device
has a camera.
[oh. Now I'm thinking about 2001, Space Odyssey.  I'm seeing Dave Borman with
a giant QR code tattoed on him, much like we proposed doing with the RSA
algorithm back during the cryptowars of the 1990s ]
{and the issues with USB devices are squarely a problem of GUIs accepting
input devices without validation.  It's fixable}

    > It still doesn't scale.

And, worse, I think, it's prone to human error, which is exactly what we want
personnel-safety-critical devices not to suffer from.

    >> by > renaming the "lower security" section as "alternative trust
    >> models" or > something.
    >>
    >> I accept that the document could have better text here.  At one point
    >> we discussed an operational considerations document.  Is that really
    >> what you are asking for?

    > Later, maybe, but to get this draft out of the door I think we can do a
    > simpler fix. As Christian pointed out, there isn't really a distinct
    > security analysis, so I think we need to say: This <text> is the
    > recommencded trust model, based on an on-line MASA. If you don't like
    > that trust model, here are the alternatives: <text>.

okay.
It's gonna take a gallon or two of caffeinated beverage.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Oct 2018 10:37:33 -0400

Eliot Lear <[email-masked]> wrote:
    >> equipment has a best-before date, and so it's acceptable for you to
    >> have vouchers only until that date.

    > I see that as future work.

current constrained voucher:

dooku-[projects/pandora/highway](2.4.1) mcr 10028 %ls -l
tmp/voucher_00-D0-E5-F2-10-03.vch
-rw-r--r-- 1 mcr mcr 800 Oct  2 23:06 tmp/voucher_00-D0-E5-F2-10-03.vch

Note that this does not include the key that did the signing (the MASA key),
and I think that this pins a certificate rather than a Raw Public Key,
so it could be smaller.  (I have to check what I put in that one)
It's okay not to include the signing key inside, as the pledge already
has it.  The Registrar ("owner's trust controller") would like to have that
key to audit the signature, but that can be done outside of the voucher.

It converts to QR code just fine:
   http://www.sandelman.ca/tmp/qr1.png

Probably needs to have some URI or some such to tell things what is inside.
However, not many devices we care about (whether routers or lightbulbs)
have cameras.  If there is some smartphone interaction, then that's a
different thing, and DPP could work, provided we get the APIs that we need to
make it deployable.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 5 Oct 2018 20:02:55 +0000

Great thread you all. Some key points for response follow. Additionally we’re working through each numbered comment specifically.

Generally lets keep the scope of BRSKI in mind. It is a new protocol for bootstrapping via vouchers. It does not preclude the use of a local console for bootstrapping/asserting ownership. The current voucher format is a starting point and there is already work in progress for various additional forms of vouchers to address the other use cases brought up.

Re: Can vouchers be distributed directly rather than through the BRSKI-MASA sub-protocol

Vouchers are signed messages and there are a number of distribution models available. This protocol describes a predominately online model. The netconf zerotouch draft describes a different method using the same vouchers with slightly different operational trade-offs. The intention is that between these a good foundation is set for all use cases (with a focus on anima and netconf; where these documents were working group items). As described below the current method and current BRSKI flow work with direct distribution as envisioned by some of the discussion on this thread (e.g. no MASA) but that is not a primary use case. The existing work on more constrained voucher formats could help to enable those ideas a more direct use cases but will not require BRSKI protocol exchanges to change.

Re: Does BRSKI change the ownership model from the owner to the manufacturer?

Absolutely not. BRSKI defines a scalable method of bootstrapping remote secure key infrastructures via the distribution of “vouchers” from the registrar to the device. It specifically attempts to ensure the registrar (owner) is in control of decisions and attempts to minimize supply chain integrations (e.g. how much the vendor even knows about who actually owns a device). The structure is such that a 3rd party could provide all the Manufacturer Authorized Signing Authority (MASA) responsibilities — thus enabling complete vendor independence from a BRSKI protocol perspective. It specifically supports models wherein the voucher is distributed in advance, on a 2d barcode or in sales material or whatever. There is no expectation of a secure connection between the device and the vendor (beyond an expectation that vouchers are signed). The goal here is to allow the vendor to help provide a scalable deployment model.

Re: What about transfer of ownership; particularly if the MASA is antagonistic to resale?

Because there is no expectation of sales-channel integration this is really limited to discussions of antagonistic vendors. I applaud purchasing decisions to avoid such vendors. Such vendors are only able to reject zero touch deployment — they can’t effect customers that use less scalable deployment models such as console access. All vendors have the option of leveraging security technologies to make resale difficult... the existence of BRSKI only exposes such attempts in the same way the signed image loading highlights similar attempts to avoid 3rd party code.

As per the basic trust model the registrar can even provide the new owner 90% of the functionality even in the face of an antagonistic MASA: The owner can obtain a nonce-less voucher against a device specific registrar keypair. This then provides them a permanent method of bootstrapping the device that they can safely provide with the device during resale. This maintains the majority value of the protocol to the new owner while completely circumventing any future antagonism by the vendor. The device can be reset to factory defaults before the sale.

Re: What happens if the MASA service is unavailable?

BRSKI is for the transfer of trust to the current owner. There is no effect to deployed devices.
As discussed in this thread there are facilities for nonce-less permanent vouchers including ones that can be used for resale. An owner that is worried about re-deploying in the future state can take this approach. Either using a common registrar or by using a registrar per device (depending on if they plan to resale).

There will always be cases where a vendor goes away and a device is therefore limited. For example security updates to signed firmware can be impacted if the vendor no longer produces them. BRSKI does make this reality worse.

- max

On Oct 2, 2018, at 7:06 PM, Uri Blumenthal <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my test iPhone

On Oct 2, 2018, at 20:53, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

randy

_______________________________________________
secdir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima