Subject: [core] draft-oflynn-core-bootstrapping

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 21:21:14 -0600

Big question:

Lots of good stuff but I think we need to start narrow in on what we need to specify to actually go and implement this. For example, say I have a device with a button and LED, what do I need to implement so that the user can take that device and get to the point where the "bootstrap" is complete and all the information needed to security run COAP is there. I realize that is probably a bunch of different things and different use cases but at some point we need to be clear about what a device need to implement and how it will be secure. 

Few minor things. 
It mention SE2.0 has devices be programmed with a certificate. What the trust root for theses? 

HIP
I assume we are talking about the rfc4843-bis style ORCHIDs here which thought they are 182 bits long, 28 of those bits get fixed so you really have 100 bits of hash resulting in a much smaller search space for collisions. It would be worth thinking about how long theses would remain security given current estimates. There must be some reasons that these are written up an experiment that ends in 2014 if not explicitly renewed.

---

From: Robert Cragie <[email-masked]>
Date: Sun, 07 Nov 2010 21:49:36 +0000

Hi Cullen,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

> Lots of good stuff but I think we need to start narrow in on what we need to specify to actually go and implement this. For example, say I have a device with a button and LED, what do I need to imp…
<RCC>
I think that is the problem - there is a huge bunch of use cases. The 
foundation of this document is the described general architecture, the 
aim of which is to provide a framework for fitting bootstrapping 
protocols into. The examples may need to refer more clearly as to which 
of the protocols is used and to use the architecture nomenclature more. 
This should make is clearer how it all fits together.
</RCC>
> It mention SE2.0 has devices be programmed with a certificate. What the trust root for theses?
<RCC>There is a PKI with a Root CA as usual so the certificate can be 
verified up to the root. There may be more than one Root CA. This is 
pretty standard - is it necessary to mention this?</RCC>
> I assume we are talking about the rfc4843-bis style ORCHIDs here which thought they are 182 bits long, 28 of those bits get fixed so you really have 100 bits of hash resulting in a much smaller sea…
<RCC>I think this ties in with Rene's earlier concerns re. entangling 
name space and cryptographic space.</RCC>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 23:10:28 -0700

On Nov 7, 2010, at 2:49 PM, Robert Cragie wrote:

> <RCC>There is a PKI with a Root CA as usual so the certificate can be verified up to the root. There may be more than one Root CA. This is pretty standard - is it necessary to mention this?</RCC>

No I don't think it needs to be mentioned in the draft I was just trying to get up to speed. 

I was trying to get an idea if there was one PKI and all the the manufactured build devices with certificates that go up to the same trust root -- or --  if it was the people deploying the devices had their own root CA and as they deployed the devices they installed certificates so different deployments might have a different trust root. 

Some of the IP phone manufactures consider both of theses models and decided neither of them were ideal. The model where the certificate needed to be installed on the phone by the service provider meant you could not ship the phone from manufacture to the where it was being installed or at least you had to touch the phone in some way as part of the installment to install the certificate. On the other hand, the manufactures were not keen on having the liability of running a CA to sign the certs on the phones where if it was compromised, it would compromise the security of all their customers operational networks. It seems like there might some of the same concerns these deployments.

The end solution that is used involves the manufactures installs a manufactured installed cert that is tied to the mac address of the phone which you can barcode off the boxes without opening them. The only thing this certificate is used for is to identify the phone to install a local certificate. So the service provider would use the manufacture certificate to help install the local certificate and the SP runs, or contracted out, the CA for local certificates. If the manufacture's CA is compromised, then the SP has to stop allowing new phones to be enrolled in the system while the issues is dealt with but all the phones that were already enrolled before the compromise are not at risk. The risk of the operational network sits with the SP's CA. Clearly if the manufactures CA is compromised but it takes them months to notice, then there phones deployed in that time window are at risk but this type of scheme helps mitigate risk and helps allocate it between manufactures and SP.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 9 Nov 2010 08:14:33 +0200

Hello,

Alternative to the manufacturer running its own Sub CA is to let a CA vendor
produce the certs for the manufacturer. That can increase the cost for the
manufacturer, but reduces the risk mentioned in Cullen's email.

Alper

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Monday, November 08, 2010 8:10 AM
To: [email-masked]
Cc: core
Subject: Re: [core] draft-oflynn-core-bootstrapping

> <RCC>There is a PKI with a Root CA as usual so the certificate can be
verified up to the root. There may be more than one Root CA. This is pretty
standard - is it necessary to mention this?</RCC>

No I don't think it needs to be mentioned in the draft I was just trying to
get up to speed. 

I was trying to get an idea if there was one PKI and all the the
manufactured build devices with certificates that go up to the same trust
root -- or --  if it was the people deploying the devices had their own root
CA and as they deployed the devices they installed certificates so different
deployments might have a different trust root. 

Some of the IP phone manufactures consider both of theses models and decided
neither of them were ideal. The model where the certificate needed to be
installed on the phone by the service provider meant you could not ship the
phone from manufacture to the where it was being installed or at least you
had to touch the phone in some way as part of the installment to install the
certificate. On the other hand, the manufactures were not keen on having the
liability of running a CA to sign the certs on the phones where if it was
compromised, it would compromise the security of all their customers
operational networks. It seems like there might some of the same concerns
these deployments.

The end solution that is used involves the manufactures installs a
manufactured installed cert that is tied to the mac address of the phone
which you can barcode off the boxes without opening them. The only thing
this certificate is used for is to identify the phone to install a local
certificate. So the service provider would use the manufacture certificate
to help install the local certificate and the SP runs, or contracted out,
the CA for local certificates. If the manufacture's CA is compromised, then
the SP has to stop allowing new phones to be enrolled in the system while
the issues is dealt with but all the phones that were already enrolled
before the compromise are not at risk. The risk of the operational network
sits with the SP's CA. Clearly if the manufactures CA is compromised but it
takes them months to notice, then there phones deployed in that time window
are at risk but this type of scheme helps mitigate risk and helps allocate
it between manufactures and SP. 
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Robert Cragie <[email-masked]>
Date: Tue, 09 Nov 2010 07:00:48 +0000

Hi Cullen,

What you describe is pretty much what we are proposing for ZigBee SE 
2.0. In my comment below, I was only referring to mfr. certificates.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064