Subject: [Anima] interface towards vendors

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Mar 2015 23:08:31 +0100 (CET)

Hi,

With my operator hat on, I just want to say that I do not want a lot of 
different ways of interacting with vendors to get credentials or anything 
else from the vendor regarding the devices we have purchased from them. I 
do not want separate protocols or mechanisms, and preferrably not 
different credetials either.

So whatever happens with the protocols speaking to IoT devices, admission 
control to Autonomic Networks, and to Netconf-call-home, we need to make 
sure the "backend systems" are the same. I think this was implied in the 
presentation about draft-he-6lo-analysis-iot-sbootstrapping, but I just 
want to say that I am of this opinion as well.

Can we do achieve this?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 25 Mar 2015 10:49:20 -0500

+1
Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

On Tue, Mar 24, 2015 at 5:08 PM, Mikael Abrahamsson <[email-masked]> wrote:
> else from the vendor regarding the devices we have purchased from them. I do
> not want separate protocols or mechanisms, and preferrably not different
> credetials either.
>
> presentation about draft-he-6lo-analysis-iot-sbootstrapping, but I just want
> to say that I am of this opinion as well.
>
> Can we do achieve this?
>
> --
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

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

On 25/03/2015 11:08, Mikael Abrahamsson wrote:
> 
> Hi,
> 
> With my operator hat on, I just want to say that I do not want a lot of different ways of interacting with vendors to get
> credentials or anything else from the vendor regarding the devices we have purchased from them. I do not want separate protocols
> or mechanisms, and preferrably not different credetials either.
> 
> So whatever happens with the protocols speaking to IoT devices, admission control to Autonomic Networks, and to
> Netconf-call-home, we need to make sure the "backend systems" are the same. I think this was implied in the presentation about
> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that I am of this opinion as well.
> 
> Can we do achieve this?

Shout at Thread, first, to tell them not to work in secret.

More generally, I am very worried about this. We cannot force
the industry to adopt a single solution. If someone can define
a common registrar model, which I guess is what you mean by
a common back end, that would be fine. I am a bit pessimistic.

To the extent that we can factor this out of the anima protocols as
such, we should do so. In my walkthrough I had Discover("trust relay").
I suspect that the response to that will have to include a list of
supported methods. The alternative would be for a node that supports,
for example, draft-pritikin would say Discover("draft-pritikin-relay")
and so on for the other methods.

    Brian

---

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

> and so on for the other methods.

Or it discovers one relay and then reports (somehow, somehow securely) which methods it accepts for onboarding?

Something like, the device indicates which of these options are supported:
	a) prove you own me (required: vendors to track this plus vendor cloud service)
	b) i’ll prove i’m not corrupted (required: NEA hardware)
	c) prove this event is logged (required: vendor neutral cloud service)
And the “trust relay” reacts accordingly?

- max

---

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

Hi Max,
  > -----Original Message-----
  > From: Anima [mailto:[email-masked]] On Behalf Of Max Pritikin
  > (pritikin)
  > Sent: Thursday, March 26, 2015 7:55 AM
  > To: Brian E Carpenter
  > Cc: [email-masked]; Mikael Abrahamsson
  > Subject: Re: [Anima] interface towards vendors
  > 
  
  > 	a) prove you own me (required: vendors to track this plus vendor cloud

It is ownership issue, and I believe it belongs to higher level security rather than devices securely joins the network.

  > 	b) i'll prove i'm not corrupted (required: NEA hardware)

How about firmware signature by vendor?
  > 	c) prove this event is logged (required: vendor neutral cloud service) And
  > the "trust relay" reacts accordingly?

Why should the device care about this information?

Besides, why is the domain concept needed if any one of the above mentioned options are supported?

Regards,
Ana

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 01:15:32 +1300

Hi Ana,
> Besides, why is the domain concept needed if any one of the above mentioned options are supported?

The set of devices permitted to perform autonomic configuration in
a network must be limited to devices within the network, and also they
must be able to verify that peer autonomic nodes are also in the same
network. The Device ID and Domain ID both need to be cryptographically
authenticated for this. That's why we need registration *within*
the domain. Actually that is much more important for Anima that
ownership.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 03:53:39 +1300

> Or it discovers one relay and then reports (somehow, somehow securely) which methods it accepts for onboarding?

I don't see how that can be done securely, since at that moment nobody
can trust the new device at all.

For the rest I agree with Max.

   Brian

---

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

> can trust the new device at all.

Yes, “(somehow, somehow securely)” was meant to imply I’m not sure how to do secure negotiation either. 

Although we can leverage the IDevID to authenticate the client, and know that the negotiation proposal originated at the client, we can’t know if malware is driving this negotiation unless we have one of the mitigation techniques already in place. 

> For the rest I agree with Max.

I think we’re on the same page, 

- max

---

From: Rene Struik <[email-masked]>
Date: Thu, 26 Mar 2015 11:49:42 -0400

Max:

Below, you mentioned the risk that a device that joins the network may 
end up with malware, which may end up with the correct network it may 
later on join.

I think your example conflates network security and application 
security, since the underlying assumption seems to be that the 
(adversarial) network manager (the one injecting the malware) has both 
authority to communicate network-related parameters and to change huge 
chunks of internal state of the device that does not have to do anything 
with infrastructure security (but with device management).

For detail on security models, please see my earlier email (Thu March 
26, 2015, 11.26am EDT).

Rene

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

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 26 Mar 2015 15:59:10 +0000

Hi Brian,

  > From: Anima [mailto:[email-masked]] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 8:16 PM
  > To: Hedanping (Ana); Max Pritikin (pritikin)
  > >   > 	a) prove you own me (required: vendors to track this plus vendor
  > cloud
  > >   > service)
  > >
  > And
  > The set of devices permitted to perform autonomic configuration in a
  > network must be limited to devices within the network, and also they must
  > be able to verify that peer autonomic nodes are also in the same network.
  > The Device ID and Domain ID both need to be cryptographically
  > authenticated for this. That's why we need registration *within* the domain.
  > Actually that is much more important for Anima that ownership.
  > 
Domain ID sounds like network ID to me. Do we really need the centralized manner to let registrar assign the domain ID to a joining device?
But I do agree that in some scenarios, it would be better if the registration can be realized locally. The solution should not limit users' option: The registrar can either download device lists/credential material from vendor or be configured locally. 

Ana

---

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

On Mar 26, 2015, at 9:49 AM, Rene Struik <[email-masked]> wrote:

> Max:
> 
> Below, you mentioned the risk that a device that joins the network may end up with malware, which may end up with the correct network it may later on join.
> 
> I think your example conflates network security and application security, since the underlying assumption seems to be that the (adversarial) network manager (the one injecting the malware) has both authority to communicate network-related parameters and to change huge chunks of internal state of the device that does not have to do anything with infrastructure security (but with device management).

For the purpose of a threat model I go further and assume the attacker can load arbitrary code onto the device. We’re talking about taking local “ownership” of the device meaning full control to do whatever the device allows in the way of configuration and updates and new images and etc. This includes the ability to install vulnerable images and inject malware through known (perhaps older) security vulnerabilities. 

The hardware TPM for secure boot and attestation as described in NEA does mitigate this but I figure we’re looking for an approximation of that security without mandating that hardware. 

- max

> For detail on security models, please see my earlier email (Thu March 26, 2015, 11.26am EDT).
> 
> Rene
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 08:18:21 +1300

On 27/03/2015 04:59, Hedanping (Ana) wrote:
> Domain ID sounds like network ID to me. 

More or less, except that we can have a precise definition of "Domain"
but "network" can mean almost any scope.

> Do we really need the centralized manner to let registrar assign the domain ID to a joining device?

Yes, because a node needs to make assertions like "I am {Node ID} in {Domain ID}"
and sign it with a private key who public key is in a cert from the CA in {Domain ID}.

   Brian

> .