Subject: Re: [Anima] Question on draft-ietf-anima-voucher-06

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2017 10:40:18 -0500

Eric Rescorla <[email-masked]> wrote:
    > The case I am concerned with right now is the case where the attacker
    > just imprints the device and then operates it even though it's in the
    > victim's network.

How can they join the victim's network, if the point of the enrollment is to
provide the device with keys to be able to join the victim's network?

(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of the
6tisch, actual 802.15.4 keys are return.  NETCONF uses this new trust to
permit the owner to reach in and do configuration with RESTCONF)

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Dec 2017 07:43:41 -0800

> provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewhere. I had understood the point of the
enrollment in this context to be to get it to join the ANIMA fabric, not
necessarily the physical network (hence why we have ACP, etc.)

Am I just totally missing the point here?

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2017 10:56:08 -0500

I was trolling the comments during the IESG call.
I was distracted and arrived after the telechat for our document :-(

I found this in the datatracker just now.
As I recall, we moved the specification of the MIME types to BRSKI.

Comments from Adam Roach:
> Thanks to the authors and working group participants for their work on this
> document. I have a somewhat major and handful of minor suggestions for
> improvement.

> The larger comment is: section 5 talks about a variety of potential
> alternate formats and mentions a couple of techniques that might be used to
> differentiate among them. I'll note that these techniques relate to MIME
> types and related data (filename extensions). The fact that *this* document
> doesn't define a MIME type for the CMS-signed-JSON variant will make it
> difficult and/or awkward for these future formats to employ these
> techniques. For example, if I were to define a COSE-signed-CBOR format and
> say "use HTTP Content-Type header fields to tell this apart from
> CMS-signed-JSON", I would be in the somewhat odd position of having to
> define the MIME-type for CMS-signed-JSON in *that* document, or of coming
> up with a very short update to the anima-voucher document that does nothing
> other than define its MIME type.

> It seems that adding a single sentence to section 5 ("To facilitate these
> techniques, this document registers a MIME type for CMS-signed JSON in
> section 8.4") plus a registration of a new MIME type along with its
> filename extension (e.g., "application/voucher-cms+json" and ".vcj") in
> that new section 8.4 would make life much easier for anyone who wants to
> define the alternate formats envisioned by section 5.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 14 Dec 2017 16:29:10 +0000

On Dec 14, 2017, at 8:43 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Ah, now I think we're getting somewhere. I had understood the point of the enrollment in this context to be to get it to join the ANIMA fabric, not necessarily the physical network (hence why we have ACP, etc.)

So, more directly responding to your concern: What happens if the attacker “just imprints the device and then operates it even though its in the victim’s network”?
Answer:

If the vendor system has sales channel integration then the voucher signatures provide an optional method of blocking “attacker imprint” (because it is no longer trust-on-first-use). This PREVENTS the attack you’re asking about.
If the victim network operator has appropriate inventory management then BRSKI/MASA integration provides logging inputs into that system to DETECT the scenario you describe, even without sales channel integration.

Once detected, then what? The BRSKI draft has this to say about its protocol flow and network access control:

draft-ietf-anima-bootstrapping-keyinfra-09:

   This document presumes that network access control has either already
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR [IDevID<https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#ref-IDevID>], and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see [RFC3748<https://tools.ietf.org/html/rfc3748>]), is
   out-of-scope.

Its even more out of scope for the voucher itself since that is a msg format for “who should the device trust” and to trigger enrollment but is even further removed from network access control.

A potential integration is to use ANIMA or BRSKI to manage device enrollment and credential from a quarantine network. The network access control could be configured to segregate all devices that are not enrolled (perhaps into a true quarantine network or maybe just pass them all through to a carefully managed dmz or … whatever). If the device enrolls successfully then you get on the “real” network. In your scenario then the attacker gain control over a device that is untrusted and placed appropriately by the network access control system. But as noted, providing the tools for this is different than actually defining that integration. I encourage the network access control folks to address these types of concerns.

- max

-Ekr

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Dec 2017 08:32:53 -0800

On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <[email-masked]

>
> On Dec 14, 2017, at 8:43 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson <[email-masked]
> > wrote:
>
>>
> So, more directly responding to your concern: What happens if the attacker
> “just imprints the device and then operates it even though its in the
> victim’s network”?
> Answer:
>
> If the vendor system has sales channel integration then the voucher
> signatures provide an optional method of blocking “attacker imprint”
> (because it is no longer trust-on-first-use). This PREVENTS the attack
> you’re asking about.
> If the victim network operator has appropriate inventory management then
> BRSKI/MASA integration provides logging inputs into that system to DETECT
> the scenario you describe, even without sales channel integration.
>

So if neither of these cases applies, then the attack succeeds?

To be clear, I'm not saying this is a defect in the protocol. I don't know
how to fix it. I'm just trying to get clear.

-Ekr

>
> Once detected, then what? The BRSKI draft has this to say about its
> protocol flow and network access control:
>
>    Identity is consistant with IEEE 802.1AR [IDevID <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#ref-IDevID>], and allows for
>    Extensible Authentication Protocol (EAP) method (see [RFC3748 <https://tools.ietf.org/html/rfc3748>]), is
>    out-of-scope.
>
> Its even more out of scope for the voucher itself since that is a msg
> format for “who should the device trust” and to trigger enrollment but is
> even further removed from network access control.
>
> A potential integration is to use ANIMA or BRSKI to manage device
> enrollment and credential from a quarantine network. The network access
> control could be configured to segregate all devices that are not enrolled
> (perhaps into a true quarantine network or maybe just pass them all through
> to a carefully managed dmz or … whatever). If the device enrolls
> successfully then you get on the “real” network. In your scenario then the
> attacker gain control over a device that is untrusted and placed
> appropriately by the network access control system. But as noted, providing
> the tools for this is different than actually defining that integration. I
> encourage the network access control folks to address these types of
> concerns.
>
> - max
>
>
> -Ekr
>
>
>>
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2017 11:36:14 -0500

Eric Rescorla <[email-masked]> wrote:
    mcr>     How can they join the victim's network, if the point of the
    mcr> enrollment is to provide the device with keys to be able to join the
    mcr> victim's network?

    > Ah, now I think we're getting somewhere. I had understood the point of
    > the enrollment in this context to be to get it to join the ANIMA
    > fabric, not necessarily the physical network (hence why we have ACP,
    > etc.)

    > Am I just totally missing the point here?

Yes, in the BRSKI context of ISP provisioned autonomic networks, it's to join
the ACP fabric.

If it's a BFR/etc. then it joined the physical network by being physically
plugging in.
The port that it is physically plugged into might have some protection.
We also imagine that there are only two devices on that piece of (dark?) fiber.
We don't think that audit-vouchers will be used for larger value equipment.

In other contexts, (6tisch, light bulbs) which are wireless, then there has
to be some "join" network on which the device connects.  The details of that
are not in the voucher document, because it has to be in the specifics of the
network.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 14 Dec 2017 17:15:33 +0000

On Dec 14, 2017, at 9:32 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <[email-masked]<mailto:[email-masked]>> wrote:

Correct. My preference is the non-sales channel approach where the network operator has complete control.

To be clear, I'm not saying this is a defect in the protocol. I don't know how to fix it. I'm just trying to get clear.

Agreed. I don’t see this as a “defect” myself, its a conscious decision to allow flexibility in deployment models.

This is important because secure bootstrapping requires devices to engage in security operations. Doing so runs the risk that something won’t work when needed. Our design choice is to limit the device security operations to the minimal amount: just sufficient for network operator audit or vendor control. This should be more reliably while allowing the the vendor or the network operator can provide substantial security *if they want*.

- max

-Ekr

- max

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Dec 2017 09:25:47 -0800

This all seems reasonable. I think I understand this better and I really
appreciate people being willing to talk it through.

>From my perspective it would be nice if we added a bit more text to the
document to explain this stuff. Would people be interested in that? Would
they want me to produce text?

-Ekr

On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) <[email-masked]

>
> On Dec 14, 2017, at 9:32 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <
> [email-masked]> wrote:
>
>>
>> On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson <
>> [email-masked]> wrote:
>>
>>>
>> the enrollment in this context to be to get it to join the ANIMA fabric,
>> not necessarily the physical network (hence why we have ACP, etc.)
>>
>> So, more directly responding to your concern: What happens if the
>> attacker “just imprints the device and then operates it even though its in
>> the victim’s network”?
>> Answer:
>>
> This is important because secure bootstrapping requires devices to engage
> in security operations. Doing so runs the risk that something won’t work
> when needed. Our design choice is to limit the device security operations
> to the minimal amount: just sufficient for network operator audit or vendor
> control. This should be more reliably while allowing the the vendor or the
> network operator can provide substantial security *if they want*.
>
> - max
>
>
> -Ekr
>
>
>>

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 14 Dec 2017 18:06:20 +0000

I think it would be useful as I had many of the same concerns myself.  The standard is intended to support multiple different levels of security, and a wide variety of use cases.  And while this is noted in the document, there isn’t much guidance about what the various tradeoffs are, and what you gain or lose by making certain deployment choices.

I would be willing to help draft language to address this.

-Tim

From: Anima [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, December 14, 2017 10:26 AM
To: Max Pritikin (pritikin) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Toerless Eckert <[email-masked]>; Anima WG <[email-masked]>; [email-masked]; IESG <[email-masked]>
Subject: Re: [Anima] Question on draft-ietf-anima-voucher-06

This all seems reasonable. I think I understand this better and I really appreciate people being willing to talk it through.

>From my perspective it would be nice if we added a bit more text to the document to explain this stuff. Would people be interested in that? Would they want me to produce text?

-Ekr

On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) <[email-masked] <mailto:[email-masked]> > wrote:

On Dec 14, 2017, at 9:32 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <[email-masked] <mailto:[email-masked]> > wrote:

On Dec 14, 2017, at 8:43 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson <[email-masked] <mailto:[email-masked]> > wrote:

Answer:

- max

-Ekr

   This document presumes that network access control has either already
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR [IDevID <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#ref-IDevID> ], and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see [RFC3748 <https://tools.ietf.org/html/rfc3748> ]), is
   out-of-scope.

- max

-Ekr

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Dec 2017 19:20:54 +0100

Tim, Eric:

As a co-author:

I think it would be great to get proposed explanatory text about context
from you. Especially because authors are often so engulfed into the
problem space that they overlook to address what they think is obvious
(and actually is not).

As WG-chair:

of the explanations discussed in this thread
where specific to ANIMA/BRKSI, but the voucher mechanism itself is meant
to applicable beyond it, specifically draft-ietf-netconf-zerotouch,
so it would be good if explanations stay as independent of BRSKI specific
aspects as possible. Explanations specific to BRSKI hsould be welcome
as well (i can not speak for the authors there ;-), but probably should
go into BRSKI (as well as of course netconf specific explanations go into netconf).

Cheers
    Toerless

On Thu, Dec 14, 2017 at 06:06:20PM +0000, Tim Hollebeek wrote:
> I think it would be useful as I had many of the same concerns myself.  The standard is intended to support multiple different levels of security, and a wide variety of use cases.  And while this is noted in the document, there isn???t much guidance about what the various tradeoffs are, and what you gain or lose by making certain deployment choices.
> 
>  
> 
> So, more directly responding to your concern: What happens if the attacker ???just imprints the device and then operates it even though its in the victim???s network????
> 
> Answer:
> 
>  
> 
> If the vendor system has sales channel integration then the voucher signatures provide an optional method of blocking ???attacker imprint??? (because it is no longer trust-on-first-use). This PREVENTS the attack you???re asking about. 
> 
> Agreed. I don???t see this as a ???defect??? myself, its a conscious decision to allow flexibility in deployment models.  
> 
>  
> 
> This is important because secure bootstrapping requires devices to engage in security operations. Doing so runs the risk that something won???t work when needed. Our design choice is to limit the device security operations to the minimal amount: just sufficient for network operator audit or vendor control. This should be more reliably while allowing the the vendor or the network operator can provide substantial security *if they want*. 
> 
>  
> 
> - max
> 
> 
> 
> 
> 
>  
> 
> -Ekr
> 
>  
> 
>  
> 
> Its even more out of scope for the voucher itself since that is a msg format for ???who should the device trust??? and to trigger enrollment but is even further removed from network access control.
> 
>  
> 
> A potential integration is to use ANIMA or BRSKI to manage device enrollment and credential from a quarantine network. The network access control could be configured to segregate all devices that are not enrolled (perhaps into a true quarantine network or maybe just pass them all through to a carefully managed dmz or ??? whatever). If the device enrolls successfully then you get on the ???real??? network. In your scenario then the attacker gain control over a device that is untrusted and placed appropriately by the network access control system. But as noted, providing the tools for this is different than actually defining that integration. I encourage the network access control folks to address these types of concerns.
> 
>  
> 
> - max
> 
> 
> 
> 
> 
>  
> 
> -Ekr
> 
>  
> 
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2017 14:24:49 -0500

Eric Rescorla <[email-masked]> wrote:
    > OK, I think I see where we're starting to talk past each other. I'm
    > not assuming that the device ever tries to connect to the device
    > owner.

    > Let me walk through the first attack I'm talking about here and you
    > can tell me what I'm missing.

    > 1. I compromise a device before it enters your network. Maybe I load
    > new firmware, but let's assume I don't for now.

okay, so you have a device you have administrative control over, and you put
it back in the package.

    > 2. You buy the device and install it, but for some reason don't
    > explicitly try to imprint it (perhaps because you have a lot of them
    > and so expect them to auto-imprint).

I buy 100 of these devices and I get one of yours, and I don't notice that
they did not all auto-imprint.

How do I install it?

    > 3. The device doesn't ever try to connect, so it's still being managed
    > by me, even thought it's in your house.

If it's wired, I can see that I can plug the wire in, and it calls home to
you or UPnP's or something, and you have access to it.
I agree: my network is toast at that point if it's wired.

If it's wifi or 802.15.4, it doesn't have a network key, so it sits there
dead.   If I have an open wifi (I used to, but my neighbour found it hard to
discipline her teenager, so I turned it off), and the device does a scan to
find a network and picks it, then I'm toast.  But, I had an open wifi, so
you didn't need to trojan me.

    > I assume you either think that (a) this can't happen for some reason I
    > don't understand or (b) it's just out of scope. Can you help?

I think that it's out of scope for the *voucher* document.
I think it's out of scope for many uses of BRSKI, but not all.

So let's continue for a bit.

Let's go back to 2012's workshop discussion:

We assumed that it really is the case that the price difference between
smart light bulbs and light bulbs has become negligible such that all light
bulbs are smart.  Smart bulbs, when in "legacy" mode (either because they are
not imprinted, or because you put them back into that mode) do the obvious
thing: turn on when there is AC, and turn off when there is no power.

So the attacker has thousands (millions!) of smart light bulbs being bought
and "installed" by home owners who simply don't know or care that they are
smart.  The light bulbs work in the way they always have.

We already know that many of these bulbs will form a mesh, and since the
attacker has initialized them all with his mesh key, if they find any bulbs
nearby, they will link up.  If one of them can find open wifi, or can find an
exploit in a wifi chipset/security stack, then the entire mesh gets online
and calls home.   We have seen these situations in the wild already.
Will the attacker ever have enough bulbs to damage the grid? Could happen.

A better use of the access to free (stolen) electricity might be to mine for
bitcoin whenever the bulbs are on, but I doubt there is ram space to do that
in the bulbs.

Audit vouchers don't prevent this; by allowing the attacker to imprint the
bulbs without sales channel integration they enable this attack.

I'd be happy to put this into a Security Considerations, but I'd rather put
it into the BRSKI document (draft-ietf-anima-bootstrapping-keyinfra) than in
vouchers.