Subject: [Anima] Ownership Concept

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Mar 2015 23:11:58 +0100

There was no time during the meeting today to ask too many questions
(because of lack of time). That's unfortunately and so I have to fall
back to the mailing list.

I wanted to get some better understand what the ownership concept is
about and what the implications are for the protocol design. The term
came up in various presentations today and it appears to be important.

Many parties are involved in the manufacturing process of products today
and the value chain is certainly complex. Hence, who the owner of what
is and at what point might be difficult to determine.

Does it really matter who the owner actually is?

Ciao
Hannes

---

From: Rene Struik <[email-masked]>
Date: Tue, 24 Mar 2015 18:21:13 -0400

Hi Hannes:

I think supply chain issues, and transgression from one supply chain 
step to the next, are important in life-cycle considerations. This 
includes how to move from one logical "owner" to the next and 
potentially "cutting the ties" with the former. These aspects certainly 
require more work.

A very simple example of supply chain would be relabelling a device as a 
"white goods" device (e.g., by selling a branded good at a superstore, 
such as Walmart, under the Walmart brand, whereas in reality it 
outsourced all production (except perhaps putting the sticker on top).

Best regards, Rene

On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 05:11:45 +1300

I think it is unanswerable, or at least the answer is YMMV. You may remember that
one of my comments on draft-pritikin was basically: I hate the MASA. I was glad
to see the connection to the MASA was clearly indicated as optional in the slides
yesterday. The point is that we have no control over this - different classes
of device and different vendors will have different ideas about this. I firmly
believe that any design we do in the IETF has to be very flexible on
this point.

Regards
   Brian

On 25/03/2015 11:21, Rene Struik wrote:
> Hi Hannes:
> 
> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle
> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the
> former. These aspects certainly require more work.
> 
> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good
> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps
> putting the sticker on top).
> 
> Best regards, Rene
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Mar 2015 10:06:46 -0700

Should i be able to find a more detailed reasonining from you about MASA 
in the mailing list archive ?  if not, would you mind to elaborate here ?

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 07:02:33 +1300

> in the mailing list archive ?  if not, would you mind to elaborate here ?

I expect it is somewhere in my comments on draft-pritikin, but basically
I think we MUST have a mode that has no external dependencies whatever.
A nuclear plant operator might agree with me, or anyone who wants a secure
network with an air gap round it.

As long as the MASA is optional, it's fine.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Mar 2015 11:45:52 -0700

Thanks, Brian.

If i understand it correctly, in the netconf zerotouch approach,
the router to control the meltdown process in the reactor would still 
need to receive a file from the outside of the reactor airgap (axctually
something like a .tar of 4? files). And in result it would have some
bootstrap config, but not a nuclear pant operator certificate. 

True/False ?

How would that match your requirements - any better/different to
you than MASA ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 08:00:20 +1300

Indeed, I think any kind of call-home is unacceptable in
certain high security environments. Would you expect, say,
the door lock control system of the White House or the
Bundestag to call an external server for a firmware update?

Another aspect is disaster recovery. If you have to reboot
your network at a time when all Internet access is down
(think hurricane or earthquake), you don't want to *require*
an external service.

"We can't open the elevator doors because the Internet is down."

I really think our bootstrap scenarios have to allow for this.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 25 Mar 2015 19:26:40 +0000

>By Brian

It is exactly the same comment that I have made a couple of time. It is up to the owner of the network or the network operator how they may validate the bootstrapped devices. It may be MASA, may be some other ways, or even simply nothing (yes, it is insecure). But the owner of the network has the right to choose. Any mandated mechanism would harm the independency of the network operator.

Best regards,

Sheng

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Mar 2015 13:07:58 -0700

Thanks Brian,

There is a difference between call-home and bring-in-key. Aka:
You have in the powerplant a server that runs Registrar, CA and
config-server for new devices in the powerplant, no outside
network connectivity required.

With both zerotouch and pritikin(masa included) approaches i could
make this work by requiring that somebody brings into the powerplant
a USB stick with the right authorization material. And given how
this is very little data, it would also be very easy to vet that this
is not a virus or the like.

If i see it correctly, the zerotouch draft does not even have the option
to forego the backend processes that result in such a USB stick with
files. Although i think it would equally be possible to do that as
it would be possible in draft-pritikin to make MASA optional.

I just think that devices that do permit to be enrolled/configured
without MASA or the zerotouch backend equivalent will be intrinsically
less secure. It does make sense though to permit them to exist, especially
for high security envionments where te vendor and customer may have
a much better lock on the ongoing physical presence of the device and
what networks it gets connected to.

Cheers
    Toerless

P.S.: I think all devices other than those owned by DoD and DoE can
be expected to have connectivity to a backend server in Fort Meade
including White House and Bundestag ;-)

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 25 Mar 2015 21:14:39 +0100

Dear all,

We must remember the initial requirements: ability to _securely_ and 
_automatically_ enroll a device (or a function, piece of software (e.g. 
VNFs)).

The automation part is motivated by operational costs.
The security level might be dependent on the end-user.

You may want to be isolated/independent from an external/remote system, 
but you still want security, then it will cost you more (e.g. "trusted" 
humans installing (manually) the device or software).
This could work for certain cases or up to a certain level, but if you 
imagine not only physical devices but also digital/software functions, 
this will become rapidly prohibitive/unpractical.

So, the point is that yes you can have the flexibility but don't forget 
the cost.

Finally, in the context of ANIMA, if we are not allowed to think/design 
stuff that increase the level of automation/autonomicity of the 
technologies, then why are we having a working group on it?
I mean it is ok to have the option to disable automation, etc. and it 
should be integrated in the design of our stuff, however in the majority 
of the cases (i.e. not nuclear plant) we want more automation and lower 
operational costs.
The reliability, trust and confidence in/of the technology is orthogonal.

Best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 25 Mar 2015 20:55:07 +0000

An excellent question Hannes.

During bootstrapping the concern is that a device is bootstrapped into the “wrong” domain, e.g. into the domain of an attacker that does not own the device. This can be seen as a DoS attack, in that the newly detected device was expected to join the target domain and it did not. In order to support the points that Rene brings up I don’t think this is an attack against the device though — it is originally “just” a DoS attack against the domain.

It leads to a persistent attack against the domain though. If the attacker inserts malware onto the device and then injects it back into the domain that originally expected the device it has now injected malware into the target domain. This is, in my mind, the more important threat to mitigate.

Possible mitigations include:

a) Fully tracking ownership. This mitigates the attack but requires the Vendor to fully secure the life-cycle including all the transitions detailed by Rene. All security depends on good decisions by the Vendor. [this should look similar to the draft-ietf-netconf-zerotouch-02 approach].

b) Trusted Hardware Modules such that malware can not be installed on devices or that such devices can be detected by the target domain. This requires very specific and detailed hardware such as the TPM provided by Trusted Computing Group and is, I think, out of scope for IETF solutions.

c) Providing the domain a method of detecting and blocking the insertion. For example if the Vendor and its partners provided a log service that indiscriminately produced “authorization tokens” for devices and domains to join each other then the Domain could check the log service to detect potential attackers thus mitigating the problem. All decisions are made on the Domain. [this should look similar to the draft-pritikin-anima-bootstrapping-keyinfra-01 approach].

I think this does effect the protocol design.

- max

On Mar 24, 2015, at 4:21 PM, Rene Struik <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes:

I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the former. These aspects certainly require more work.

A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps putting the sticker on top).

Best regards, Rene

Ciao
Hannes

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

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 25 Mar 2015 21:00:13 +0000

> it would be possible in draft-pritikin to make MASA optional.

See the first paragraph of the security considerations:

   In order to support a variety of use cases, devices can be claimed by
   a registrar without proving possession of the device in question.

This allows the use case of powerplants, oil rigs, etc.

I don’t understand how one can expect the backend to be totally “optional” since the device doesn’t know if it should be optional or not. The best I think we can do is make the backend “no decision” and “air gap compliant”. But if the device itself is willing to make the back end optional thats like saying that the end device has a trivial downgrade attack. 

I wonder if the netconf draft (ownership validation) isn’t better for offline situations than what the masa has described. A mix of hte two might work well then, 

- max

---

From: Rene Struik <[email-masked]>
Date: Wed, 25 Mar 2015 17:05:03 -0400

Dear Toerless:

I think it would help to describe the underlying security model, from a 
device and network lifecycle perspective. Essential elements here are 
description of security policy enforcement, and potential transitions 
here over time. This also allows filling in detail as to what degree 
statements, such as the one below, are technically correct.

Rene

less secure.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 25 Mar 2015 22:00:15 +0000

Max>I don’t understand how one can expect the backend to be 
>totally “optional” since the device doesn’t know if it should be 
>optional or not.

One possible deployment scenario: the owner of the network has obtained the certs of devices out-of-band before the device bootstraps. The certs are stored at the registrater locally. Then, we the new devices is plugged in, the registrater can validate it by it self - no need to contact MASA.

Sheng

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 25 Mar 2015 23:08:55 +0000

I think Rene’s point about the underlying security model is a good one. It explains why I disagree with your note below. Refer to my email earlier in this thread where I lay out the attack which must be mitigated: the device joins Mallory’s domain and has malware installed on it.  

> One possible deployment scenario: the owner of the network has obtained the certs of devices out-of-band before the device bootstraps. The certs are stored at the registrater locally. Then, we the…

In which case Mallory can trivially do this and now has full access to the device. Mallory installs malware on the device and, using the malware, joins the target network. 

What I laid out in the prior thread were three possible mitigations. None of them are ideal. Of the choices I’ve contended that the MASA approach is the least onerous since it minimizes the central cloud service to a simple logging entity. 

Where the MASA concept is weakest is when an air-gap is anticipated. In such cases the MASA concept allows for “nonce-less” authorizations that are long lived. To minimize that one can optionally do full ownership tracking but only if all MASA responders agree to do so — which reduces our ability to deal with “vendor went out of business but there are 3rd party MASA services” use cases. 

I’m uncomfortable mitigating this problem by mandating full ownership tracking, as in the netconf proposal, because that is a really hard problem to solve even while I see the value of it.

- max

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 25 Mar 2015 23:34:25 +0000

Hi, Max,

I agree you have desribe a valid attack model there. However, I don't think check with MASA online would solve the prolem. Onless the MASA performs hardware signature validation, to make sure the hardware has not been modified since it leaves the manufacture, which I don't think is in the current version of bootstrap. However, even so, hardware signature validation may also be able to be processed on the registrater within the network. So, MASA would still be optional.

Sheng

________________________________________
From: Max Pritikin (pritikin) [[email-masked]]
Sent: 26 March 2015 7:08
To: Sheng Jiang
Cc: Toerless Eckert (eckert); Hannes Tschofenig; [email-masked]; Rene Struik
Subject: Re: [Anima] Ownership Concept

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 25 Mar 2015 23:49:29 +0000

On Mar 25, 2015, at 5:34 PM, Sheng Jiang <[email-masked]> wrote:

> Hi, Max,
> 
> I agree you have desribe a valid attack model there.

I suspect we’d agree it is incomplete — only focusing on a single important threat at the moment. As we proceed we’ll have to build this out. 

> However, I don't think check with MASA online would solve the prolem. Onless the MASA performs hardware signature validation, to make sure the hardware has not been modified since it leaves the manufacture, which I don't think is in the current version of bootstrap.

The threat being mitigated is a network based attack where Mallory inserts itself between the new device and the valid domain. I think “hardware modification" assumes Mallory has physical access to the device and I agree that the Trusted Platform Module type mitigation is the path to take for that. That is being worked on by other efforts so I think we’d be ok declaring that out-of-scope in our threat modeling even while I agree we’ll eventually address it. Perhaps the right approach is to admit into the onboarding protocol some alignment with the Network Endpoint Assessment (NEA) work (e.g. RFC5209).

> However, even so, hardware signature validation may also be able to be processed on the registrater within the network. So, MASA would still be optional.

How would we deal with this in standards language? I suppose it would go something like:
"If the device does not support NEA [RFC7209] integration then it MUST verify the [MASA "authorization token" or NCONF “ownership validation”] otherwise it MAY imprint on an unknown and unvalidated domain”? Also the registar/domain would have to know the capabilities/requirements of the device during onboarding so it knows if it needs to contact the cloud.

I think you’re arguing that all three mitigation techniques, or at least two of them, are required? Is that true?

- max

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 26 Mar 2015 02:55:48 +0000

Max>I think you’re arguing that all three mitigation techniques, 
>or at least two of them, are required? Is that true?

No. I did not argue on any certain mitigation techniques. My argument is the necessity of online checking with MASA. I don't think there is technical requirements that you could not do on the registrater locally, although it may require some pre-configuration or out-of-band setup.

Evenmore, the owner of the network should have the right to trust devices with Trust-on-first-use (TOFU) policy.

Sheng

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 26 Mar 2015 05:48:41 +0000

I agree that ownership is important in life-cycle consideration, but I believe it belongs to higher security level that impacts the interaction or manipulation between NEs or between NEs and owner.

  > -----Original Message-----
  > From: Anima [mailto:[email-masked]] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 12:12 AM
  > To: Rene Struik
  > Cc: Hannes Tschofenig; [email-masked]
  > I think it is unanswerable, or at least the answer is YMMV. You may
  > remember that one of my comments on draft-pritikin was basically: I hate
  > the MASA. I was glad to see the connection to the MASA was clearly
  > indicated as optional in the slides yesterday. The point is that we have no
  > control over this - different classes of device and different vendors will have
  > different ideas about this. I firmly believe that any design we do in the IETF
  > has to be very flexible on this point.
  > 
  > Regards
  >    Brian
  > 
  > > includes how to move from one logical "owner" to the next and potentially
  > "cutting the ties" with the former. These aspects certainly require more
  > work.
  > >
  > > A very simple example of supply chain would be relabelling a device as
  > > a "white goods" device (e.g., by selling a branded good at a
  > > superstore, such as Walmart, under the Walmart brand, whereas in reality
  > it outsourced all production (except perhaps putting the sticker on top).
  > >
  > > Best regards, Rene
  > >
  > >> Many parties are involved in the manufacturing process of products
  > >> today and the value chain is certainly complex. Hence, who the owner
  > >> of what is and at what point might be difficult to determine.
  > >>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 26 Mar 2015 15:55:49 +0000

On Mar 25, 2015, at 8:55 PM, Sheng Jiang <[email-masked]> wrote:

> No. I did not argue on any certain mitigation techniques. My argument is the necessity of online checking with MASA.

I take this to mean you accept the threat model discussion and that the mitigations I supplied address the threats — but that you really don’t like having a cloud service in the loop at all.

> I don't think there is technical requirements that you could not do on the registrater locally,

The requirement is that the solution ensure against, or detect, malware being installed by a Mallory registrar. At the time that this occurs the communication is between the device and the Mallory registrar so I don’t understand how the domain Registrar could prevent this w/o adding specific functionality on the device. For example...

> although it may require some pre-configuration or out-of-band setup.

… here you imply a pre-configuration or out-of-band feature on the new device. If so, I agree with you that pre-configuration of the new device via an out-of-band channel like a console port does mitigate the threat described, to some extent. I thought a basic requirement is for zero-touch (no pre-configuration). Additionally “out-of-band” channels are becoming rarer as devices move to more and more wireless or at least single/simple ports without user interfaces. I didn’t consider this a particularly useful mitigation but agree it could be included for completeness in the discussion.

> Evenmore, the owner of the network should have the right to trust devices with Trust-on-first-use (TOFU) policy.

The only way I know to secure this is, according to the threat model and mitigations agreed on above, is to use TPM like hardware behind an NEA mechanism. The network *of course* has the right to demand and to purchase such equipment. Lets assume for a moment that not all devices have this hardware though. What mitigation mechanism do you suggest to ensure against, or detect, malware being installed by a Mallory domain that is not either a MASA cloud service (logging used for detection) or an Ownership Validation cloud service (fully tracking ownership in the sales channel)? 

- max

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 11:56:28 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    > b) Trusted Hardware Modules such that malware can not be installed on
    > devices or that such devices can be detected by the target domain.
    > This requires very specific and detailed hardware such as the TPM
    > provided by Trusted Computing Group and is, I think, out of scope for
    > IETF solutions.

This is neither here nor there.
Even without this trojan, it might be that I can still MITM the operator.

Getting the device to join my malicious network, instead of your network, may
be more than enough.  I can now control your actuators.  That might mean I've
won, period. 

Maybe, I will provide a different device that appears to join your network,
and after some on your part, troubleshooting, convince you that it's the
right device, because after all, when you operate this "fake" device, the
real valves actually do operate... 

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 11:57:27 -0400

Hedanping (Ana) <[email-masked]> wrote:
    > I agree that ownership is important in life-cycle consideration, but I
    > believe it belongs to higher security level that impacts the
    > interaction or manipulation between NEs or between NEs and owner.

I strongly disagree.
Ownership is fundamental.  No other interaction makes sense until you
establish ownership.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 26 Mar 2015 16:06:03 +0000

> Even without this trojan, it might be that I can still MITM the operator.

Agreed. There are plausible attacks against a TPM where the MiTM could “control your actuators” effectively using the TPM as a remote hardware security module.

Since I’d be happy to declare this mitigation out of scope (it requires hardware and I don’t think IETF is in a position to mandate hardware!) I’m certainly not going to argue against possible weaknesses. Like any security space the TPM/NEA technology is progressing. It will get better but we shouldn’t assume it is ubiquitous nor infallible.

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 26 Mar 2015 16:06:38 +0000

> Ownership is fundamental.  No other interaction makes sense until you

+1

Well and strongly said. 

- max

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 26 Mar 2015 16:35:45 +0000

Hi Michael,
  > From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
  > Richardson
  > Sent: Thursday, March 26, 2015 11:57 PM
  > To: [email-masked]
  > Cc: Hedanping (Ana)
I don't think there is any problem that devices belong to different owners can join the same network securely and make necessary networking configuration.
Normally devices don't need to know each other's ownership until they really need interaction... What I mean is that ownership doesn't affect secure networking.
It doesn't mean that ownership is not fundamental for application level security. From my point of view, it is very important, especially in iot cases.

Regards,
Ana

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 26 Mar 2015 17:10:21 +0000

> I don't think there is any problem that devices belong to different owners can join the same network securely and make necessary networking configuration.

Hmm. What do we mean by “ownership”? 

I’d work backward form the slang term “pwn”, as in: Mallory has pwned that device!
At one level the “owner” of a device is whomever has complete control over it. 

We care very strongly who this is. (Namely that is isn’t Mallory). 

I don’t think its possible to track and identify the correct owner via sales channel security, which is my primary concern about the “ownership validation” approach taken in the netconf draft. The MASA approach cares strongly about providing logs about entities that have “owned” the device without requiring that any central source actually know who those entities are. Meaning that I think it is sufficient to know that somebody “pwned” it but I don’t think it is necessary to know the authenticated name of the pwner. 

- max

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 14:59:29 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    > I don’t understand how one can expect the backend to be totally
    > “optional” since the device doesn’t know if it should be optional or
    > not. The best I think we can do is make the backend “no decision” and
    > “air gap compliant”. But if the device itself is willing to make the
    > back end optional thats like saying that the end device has a trivial
    > downgrade attack.

I have read this thread.
Unfortunately, I missed the discussion at the session, as I had to present in
6lo at that time.

I don't see a conflict between MASA and no-MASA.  Both are valid, legitimate
security models, and business models.

In the certificate based ownership mechanism (I hesitate to call it a
protocol), that I envision, the MASA function defends against certain kinds
of attacks, and enables other kinds of attacks.

A MASA may be operated by either a vendor or their supply chain delegate.
As such, it is subject to various attacks: National Security letters,
takeovers (friendly and hostile), etc.  The existence of the MASA provides
a way to detect, or prevent, transfers from one owner to another.  Some
device claim mechanisms may include knowledge of a pre-shared (symmetric)
key (such as might come from a QRcode on the packaging).  That key, if
disclosed in the supply chain, can enable logical device theft.

A MASA could also in some cases be operated by a sophisticated end user.
How the trust relationship to do so is setup depends upon some details that
need to be worked out, but not here.

Solutions without a MASA have the advantage that MASA do not need to be
available.  This isn't just about network "availability", but also about
business continuity.  A device that sits in a warehouse for 20 years should
not have to depend the company that made it still existing at the same
address. (I saw a closet full of Nortel Meridian spare parts last week...)

Solutions without a MASA enable the end owner to decide how/when to
resell/transfer the device to another owner. This is a transaction that the
MASA can prevent.  (Reselling things is business as usual for some, and theft
to other vendors)  The solution I describe at:
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

has a potential flaw: a previous owner, and any supplier in the supply chain
could assert their ownership certificate again, and steal the device "back"
From the end user.  This happens if either you do not replace the 802.1AR
certificates with locally significant certificates.  (If you merely augment
the 1AR with a LDevID, then the originally UDevID may be still useable)
This may be a "feature" --- it means that you can call up the guy who sold
you the device, and get their help to "reset your password".

In the scenario that I describe above, using 1AR certificates with an
extension like I describe at
          http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-cert/

one can operate this online or offline. The certificate could be shipped
with the device when you buy it.  It could also be generated online from a
MASA-type device based upon a one-time token that you provide to the MASA
device (along with the public key you want to have bound).
It could be that the work in ACME applies as well here.

I suggest that a virtual interim meeting would be appropriate soon.

-- 
]               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: Thu, 26 Mar 2015 17:09:19 -0400

> I don't think there is any problem that devices belong to different
    > owners can join the same network securely and make necessary networking
    > configuration.

That's a very surprising thing that you say.
And I want to understand what it is that you mean.
Are you saying for instance that two operators at some common place could
pull their configuration down from an available public wifi (netconf-style)
or 3G network.   

But, I don't see how an operator of a network can tolerate having a device owned
by another operator inside the core of their network.
I wonder if the word "owner" is being mis-understood.

An operator receives some crates of equipment from a variety of vendors.
They take it out of the boxes, and plug things together (or in the case of
wireless equipment, they "unplug", I guess).  Today, the equipment gets its'
initial configuration either by having a serial console plugged in, or more
commonly now, the equipment iether runs a dhcp client or a dhcp server
(possibly on a custome wifi ESSID), and someone connects to it with a laptop
and HTTPS. (Clicks through the certigficate is not valid warning...)

But, this takes trained personnel.  If the equipment is connected together
via some long wire (a cross-country dark fiber), then shipping people to both
ends is expensive and annoying.

    > Normally devices don't need to know each other's ownership until they
    > really need interaction... What I mean is that ownership doesn't affect
    > secure networking.

I am looking for example/reason why two devices would be plugged together, if
not so that they would interact.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 17:19:26 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    > I don’t think its possible to track and identify the correct owner via
    > sales channel security, which is my primary concern about the
    > “ownership validation” approach taken in the netconf draft. The MASA
    > approach cares strongly about providing logs about entities that have
    > “owned” the device without requiring that any central source actually
    > know who those entities are. Meaning that I think it is sufficient to
    > know that somebody “pwned” it but I don’t think it is necessary to know
    > the authenticated name of the pwner.

Which document are you talking about?
Can you comment on whether the MASA would be selected by the device, by the
vendor, or by the operator?  Is there a competitive market for providing the
MASA service?

I had previously assumed that the MASA would be operated by some entity in
the supply chain of the device.  Probably the vendor, but as has been
discussed, it could also be delegated to VARs, and even into parts of the
customer (I imagine some piece of .mil might run one for all of the US
military.  I was looking for the name of that entity, found:
http://en.wikipedia.org/wiki/Military_acquisition and gave up)

But, if there are more than one place to find this log, how do I know that
I've looked in all the right places?

---

From: Robert Cragie <[email-masked]>
Date: Thu, 26 Mar 2015 23:45:41 +0000

This conversation is going around in circles as this was Hannes' original
question.

In my attempt to analyse the discussion, there are a number of points I
notice.

Firstly, the concept of MASA seems to be no more than an online whitelist
(using LDAP or something). There are certainly cases where I can see this
being used but conceptually it is not much different to a whitelist on the
registrar. The only other operation it seems to do is to sign the domain
certificate. But the registrar could also do this - so I guess this is
really combining MASA and registrar in a single box. Either way, the NE has
to have the domain public key, whether the MASA or the Registrar is
authorised to issue domain certificates on behalf of the Domain CA and any
other public keys relevant to the certificate chain.

Regarding the honeypot (Mallory) attack - the NE is going to find out it's
a honeypot as the honeypot will not be able to issue valid domain
certificates. A MASA makes no difference here, it's simply about validating
the trust chain of the domain certificate, surely? So I don't see issues
with pre-loading NE IDs/certs on the Registrar providing the domain
certificate chain is validated by the NE.

Robert

On 26 March 2015 at 17:10, Max Pritikin (pritikin) <[email-masked]>
wrote:

> sales channel security, which is my primary concern about the “ownership
> validation” approach taken in the netconf draft. The MASA approach cares
> strongly about providing logs about entities that have “owned” the device
> without requiring that any central source actually know who those entities
> are. Meaning that I think it is sufficient to know that somebody “pwned” it
> but I don’t think it is necessary to know the authenticated name of the
> pwner.
>
> - max
>
> > It doesn't mean that ownership is not fundamental for application level
> security. From my point of view, it is very important, especially in iot
> cases.
> >
> > Regards,
> > Ana
> >>
> >> --

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 27 Mar 2015 01:14:11 +0000

Inline,

> On Mar 26, 2015, at 3:19 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

The two bootstrapping docs being discussed: Pritikin-anima-bootstrapping-keyinfrastructures (MASA concepts) and the netconf alternative (owner validation). 

> vendor, or by the operator?  Is there a competitive market for providing the

The drafts assume vendor provides the cloud service for their devices. Because the MASA concept doesn't require sales channel integration it could be provided by a third party more easily. 

I think there would be a market for 3rd party MASA servers that provide the service for multiple manufacturers. I have not explored that as a business case though. 

> I've looked in all the right places?

If consensus were to support more than just the vendor we'd have to signal the NE behavior (eg MASA servers it trusts) in a secure manor. Off the cuff this could be embedded in the IDevID certificate similar to an AIA etc. 

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 27 Mar 2015 01:21:22 +0000

Inlines,

On Mar 26, 2015, at 5:45 PM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

This conversation is going around in circles as this was Hannes' original question.

In my attempt to analyse the discussion, there are a number of points I notice.

Firstly, the concept of MASA seems to be no more than an online whitelist (using LDAP or something).

More appropriate is to think of the MASA as a 3rd entity logging events. It is not itself a whitelist -- recall it can be implemented without making any decisions about who owns what. All whitelist belong in the Domain Registrar, in my opinion.

There are certainly cases where I can see this being used but conceptually it is not much different to a whitelist on the registrar.

The registrar is owned and operated by the domain owner. The cloud service is not. I argue MASA substantially simplifies the threat model.

The only other operation it seems to do is to sign the domain certificate. But the registrar could also do this - so I guess this is really combining MASA and registrar in a single box. Either way, the NE has to have the domain public key, whether the MASA or the Registrar is authorised to issue domain certificates on behalf of the Domain CA and any other public keys relevant to the certificate chain.

The MASA does not sign certs. All it ever does is assure, via the authorization token, the NE that if it joins the domain this will be logged. That way Mallory can be detected by the real domain.

Regarding the honeypot (Mallory) attack - the NE is going to find out it's a honeypot as the honeypot will not be able to issue valid domain certificates.

The NE can't identify a "valid" domain certificate so I don't believe this is correct.

A MASA makes no difference here, it's simply about validating the trust chain of the domain certificate, surely?

Nope. See above.

- max

So I don't see issues with pre-loading NE IDs/certs on the Registrar providing the domain certificate chain is validated by the NE.

Robert

On 26 March 2015 at 17:10, Max Pritikin (pritikin) <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 26, 2015, at 10:35 AM, Hedanping (Ana) <[email-masked]<mailto:[email-masked]>> wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael
>> Richardson
>> To: [email-masked]<mailto:[email-masked]>
>> Cc: Hedanping (Ana)
>> Hedanping (Ana) <[email-masked]<mailto:[email-masked]>> wrote:

- max

>> Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Mar 2015 14:00:20 +0000

>The drafts assume vendor provides the cloud service for their devices.
>Because the MASA concept doesn't require sales channel integration it
>could be provided by a third party more easily.

The Netconf ZeroTouch approach could also support 3rd-parties - a vendor
delegates a signing key to the 3rd-party and let them define their own
vetting policy.  The issue, of course, is that this key could be used to
sign data for anybody's equipment and lead to a simple attack.

Regarding use-cases for bootstrapping, there might be four that matter:

  1. Operator's CPE device plugging into operator's network

  2. Device plugging into a 3rd-party network (franchise chains)
  3. Device plugging into campus/enterprise network
  4. Device plugging into a home network
  <there may be more>

Some characterizations:

  - 1 and 4 are needed because we need something easy for grandma
  - 1, 2 and 3 are high-touch sales events, where validating ownership is
possible
  - 4 may allow for degraded or no security
  - all should allow for a normal boot when no bootstrapping is possible

Switching gears, last night I had an idea that might apply here.  That
both the device and the network could enforce a minimum security level.
For instance, a device could be manufactured with an requirement that any
network it's plugged into provides at least a gold-level security and/or
bootstrapping process.  Likewise, a  network could be configured with a
requirement that any device plugged into it implements at least
bronze-level security and/or bootstrapping process.   I'm still searching
for how this might work, but it seems intuitive and roughly approximates
the concerns...

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Mar 2015 14:28:44 +0000

>  4. Device plugging into a home network

On second thought, #4 may not matter, at least not from a security
perspective.  This as it seems improbable that a consumer would go through
the trouble of staging bootstrapping infrastructure in a way that would
ensure security.  The whole idea with #4 is to dumb it down, heaping
complexity on top is the opposite of what's desired.

FWIW, 1-3 are high-touch in another way too, in that the rightful owner is
willing to go through a staging process, so long as a negates the need for
the installer to have to be a skilled technician.

Thanks,
Kent

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 27 Mar 2015 15:31:38 +0000

Inline,

> On Mar 27, 2015, at 8:00 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> 

I think the difference is that netconf netconf zerotouch requires the cloud to know who owns which device. This means integration into the sales channel. MASA doesn't require that - so it would be easier for a third party to provide the ongoing service. 

>  - 4 may allow for degraded or no security

I see this supported by having the MASA be a dumb logger and by the registrar not checking the logs. This allows one network to "not care" about security without forcing everybody else to be insecure. (Or forcing venders to ship multiple "secure" vs "insecure" versions of their product. 

>  - all should allow for a normal boot when no bootstrapping is possible

By normal I take you to mean locally configured. I think in the long run this won't exist: because all devices will ship without local console ports - they'll all use wireless which needs a security model. But I understand we are not there yet. 

> for how this might work, but it seems intuitive and roughly approximates

As noted previously -- I think the device needs a fixed behavior and the domain needs to make the decision about the local security level. I had thought the vendor/cloud behavior could be fixed and always the same (no decisions, MASA approach) but to support air gaps I provide two levels of security on the MASA authorization token: nonced and nonceless responses. The characteristics of the protocol would be improved if nonceless responses were of the netconf zero touch ownership validation variety. 

Hmm. That would be an interesting blending of the two approaches. 

- max

---

From: Robert Cragie <[email-masked]>
Date: Sat, 28 Mar 2015 23:52:24 +0000

Perhaps I was a bit premature in sending the original e-mail and have taken
the time to read definitions and design goals draft and the reference model
draft (on which I will post comments shortly)

Not having participated fully in the anima inner sanctum, I don't find the
description of the MASA at all clear (it's just a "tbd"
in draft-behringer-anima-reference-model). However, I have read between the
lines somewhat and I think I have a clearer picture.

Comments inline.

Robert

On 27 March 2015 at 01:21, Max Pritikin (pritikin) <[email-masked]>
wrote:

>  Inlines,
>
> On Mar 26, 2015, at 5:45 PM, Robert Cragie <[email-masked]>
> wrote:
>
>  More appropriate is to think of the MASA as a 3rd entity logging events.
> It is not itself a whitelist -- recall it can be implemented without making
> any decisions about who owns what. All whitelist belong in the Domain
> Registrar, in my opinion.
>

<RCC>The "automated orchestrator" hints at that behaviour ("or in real time
for each new device"). I can't see that just logging will achieve that
much, unless the aim is to alert someone (unclear - user, vendor?) that an
anomalous event has occurred.</RCC>

>
>
>   There are certainly cases where I can see this being used but
> conceptually it is not much different to a whitelist on the registrar.
>
>
>  The registrar is owned and operated by the domain owner. The cloud
> service is not. I argue MASA substantially simplifies the threat model.
>

<RCC>I see now that the purpose of the MASA service is not online
whitelisting, and the difference in the domain authority and the MASA.</RCC>

>
>   The only other operation it seems to do is to sign the domain
>  The MASA does not sign certs
>

<RCC>So why is it called a "signing authority" then? Confusing. I can see
it may sign authorisation tokes (see later). I see the Factory CA signs the
IDevID - that seems to be what is shown in Figure 1 and I can see it would
be the Registrar (on behalf of the domain CA) signing any domain
certificate (or it may just pass it on?). However, the MASA is shown in the
same dotted line as the Factory CA - which I would assume means "the
Vendor". So what is the difference between the Factory CA and the MASA? If
the MASA is separate, what is the trust relationship between Factory CA and
MASA? Chain to the same common CA? I guess the question I am asking is how
can the new element trust the MASA unless it has been pre-programmed with
its public key as part of its factory-configured material - is that the
intent?</RCC>

. All it ever does is assure, via the authorization token, the NE that if
> it joins the domain this will be logged. That way Mallory can be detected
> by the real domain.
>

<RCC>
So please explain the authorisation token in more detail and what leads to
its generation. This is a bit more than just logging.

As far as I can see (and please correct me if I am wrong), the
Mallory/honeypot detection isn't really shown in Figure 1. For this to
work, the NE would have to send details of the registrar it has received,
presumably relayed by the registrar itself (OCSP)? Then the MASA service
sends a signed authorisation token back, attesting the validity of the
Registrar. A honeypot would not be able to provide valid credentials so at
that point would fail. If a honeypot tried to use a honeypot MASA, it
wouldn't have the private key to sign the authorisation token so that would
fail to. If the honeypot claims the MASA is unreachable - another failure.
So I agree, a good way to simplify the threat model.
</RCC>

>
>
>   Regarding the honeypot (Mallory) attack - the NE is going to find out
> it's a honeypot as the honeypot will not be able to issue valid domain
> certificates.
>
>

<RCC>It could if it were pre-provisioned with the Registrar's public key
and Domain CA public key. As you point out, in Section 2, "As a service
offering the MASA can incorporate many of the bootstrapping elements (such
as the Registrar and the Domain CA) into the overall service." So surely in
this case, there is no separation of CAs?</RCC>

> chain of the domain certificate, surely?

<RCC>There are different models here which need to be elucidated. A whole
load more information needs to go into the document.</RCC>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 30 Mar 2015 17:03:17 +0000

On Mar 28, 2015, at 5:52 PM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps I was a bit premature in sending the original e-mail and have taken the time to read definitions and design goals draft and the reference model draft (on which I will post comments shortly)

Not having participated fully in the anima inner sanctum, I don't find the description of the MASA at all clear (it's just a "tbd" in draft-behringer-anima-reference-model). However, I have read between the lines somewhat and I think I have a clearer picture.

Thanks for the feedback.

Comments inline.

responses inline,

Robert

On 27 March 2015 at 01:21, Max Pritikin (pritikin) <[email-masked]<mailto:[email-masked]>> wrote:
Inlines,

<RCC>The "automated orchestrator" hints at that behaviour ("or in real time for each new device"). I can't see that just logging will achieve that much, unless the aim is to alert someone (unclear - user, vendor?) that an anomalous event has occurred.</RCC>

The Registrar is “alerted” in that when it decides if a device is to join the domain it checks the logs. If there is an anomalous event the Registrar makes appropriate decisions based on domain policy. This allows the domain to scale up or down the security as it requires.

<RCC>I see now that the purpose of the MASA service is not online whitelisting, and the difference in the domain authority and the MASA.</RCC>

<RCC>So why is it called a "signing authority" then? Confusing. I can see it may sign authorisation tokes (see later).

Understood. It signs the “proof of logging” things we called “authorization tokens”. Please feel free to suggest terms that resonate.

I see the Factory CA signs the IDevID - that seems to be what is shown in Figure 1 and I can see it would be the Registrar (on behalf of the domain CA) signing any domain certificate (or it may just pass it on?). However, the MASA is shown in the same dotted line as the Factory CA - which I would assume means "the Vendor". So what is the difference between the Factory CA and the MASA? If the MASA is separate, what is the trust relationship between Factory CA and MASA? Chain to the same common CA?

Specifically the vendor trusts the MASA trust anchor and installs it on the devices. The simplest approach is to re-use the IDevID trust anchor but for 3rd party MASA’s one could install a set of MASA trust anchors. Ultimately trust anchors are just public keys with policy about how/what they are trusted for.

I guess the question I am asking is how can the new element trust the MASA unless it has been pre-programmed with its public key as part of its factory-configured material - is that the intent?</RCC>

yes.

. All it ever does is assure, via the authorization token, the NE that if it joins the domain this will be logged. That way Mallory can be detected by the real domain.

<RCC>
So please explain the authorisation token in more detail and what leads to its generation. This is a bit more than just logging.

s4.1.2: NE only joins a domain if an authorization token is provided. This behavior of the NE ensures that a log of the authorization token is also a log of every time the NE joins a domain.

s4.3.2: Registrar only allows the device to join the domain if the devices history (e.g. the log information) doesn’t show it has joined Mallory’s domain. Or, if the registar doesn’t care, maybe it just doesn’t check.

s4.3.3: Registrar MUST claim the device, obtaining an authorization token and ensuring a log entry is generated, in order to get the device to trust it.

As far as I can see (and please correct me if I am wrong), the Mallory/honeypot detection isn't really shown in Figure 1.

In figure1 note that “device history log” and “authorization token” are sent to the Domain from the MASA. The Domain then decides “still accept device?” based on the log information. This is the Registrar checking for Mallory. If the log information shows an unknown/unexpected log entry then Mallory has been detected.

It is still the Domain’s policy decision about continuing.

For this to work, the NE would have to send details of the registrar it has received, presumably relayed by the registrar itself (OCSP)?

Ummm… didn’t follow you completely. I suggest keeping the log information in the cloud and delivering it to the registrar from there because I don’t trust the NE to reveal that it is has been corrupted by Mallory.

Then the MASA service sends a signed authorisation token back, attesting the validity of the Registrar. A honeypot would not be able to provide valid credentials so at that point would fail.

Correct, the Mallory domain would have to contact the MASA to obtain a signed authorization token which ensures that the event has been logged.

If a honeypot tried to use a honeypot MASA, it wouldn't have the private key to sign the authorisation token so that would fail to. If the honeypot claims the MASA is unreachable - another failure. So I agree, a good way to simplify the threat model.
</RCC>

<RCC>It could if it were pre-provisioned with the Registrar's public key and Domain CA public key. As you point out, in Section 2, "As a service offering the MASA can incorporate many of the bootstrapping elements (such as the Registrar and the Domain CA) into the overall service." So surely in this case, there is no separation of CAs?</RCC>

For any given domain one could do this. But it doesn’t work at scale or if the target domain isn’t known when the device leaves the vendor.

Nope. See above.

<RCC>There are different models here which need to be elucidated. A whole load more information needs to go into the document.</RCC>

Thanks for the feedback,

- max