Subject: [Ace] Constrained Environment PKI enrollment

From: Julien Vermillard <[email-masked]>
Date: Thu, 2 Jun 2016 15:38:02 +0200

Hi,
In industrial or enterprise M2M/IoT application we often use PSK for
authentication, but more and more user want to enroll the device on their
public key infrastructure like they does with some routers using SCEP/CMP.

I wonder if it was explored to enroll devices, and renew certificates on
PKI only using CoAP and not HTTP?

--
Julien Vermillard

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Jun 2016 10:30:46 -0400

Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt?

Eliot

On 6/2/16 9:38 AM, Julien Vermillard wrote:
> authentication, but more and more user want to enroll the device on
> their public key infrastructure like they does with some routers using
> SCEP/CMP.
>
> I wonder if it was explored to enroll devices, and renew certificates
> on PKI only using CoAP and not HTTP?
>
> --
> Julien Vermillard
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Julien Vermillard <[email-masked]>
Date: Thu, 2 Jun 2016 17:36:19 +0200

Thanks Eliot, I'll take a look.

--
Julien Vermillard

On Thu, Jun 2, 2016 at 4:30 PM, Eliot Lear <[email-masked]> wrote:

> Ace mailing [email-masked]://www.ietf.org/mailman/listinfo/ace
>
>
>

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 3 Jun 2016 17:08:12 +0200

The company I previously worked for where looking into adopting EST for
this purpose, the benefit of EST compared to cmp or scep was that it
defined the process for server side generated keys, which could be
beneficial if key generation would be to cumbersome for the device or if
you don't trust the device to generate a "good" key.

Maybe Shahid could give sold more updates since he was helping us with this
project

---

From: Shahid Raza <[email-masked]>
Date: Sat, 4 Jun 2016 01:01:29 +0200

We (SICS and neXus) have been working on this since September last year and designed and implemented an enrollment protocol over secure CoAP. Both the specifications and the Contiki source code will be available soon. This is done under the umbrella of a Swedish project called CEBOT: Certificate Enrollment in Billions of Things.

Regards,
Shahid

> On 03 Jun 2016, at 17:08, Samuel Erdtman <[email-masked]> wrote:
> 
> The company I previously worked for where looking into adopting EST for this purpose, the benefit of EST compared to cmp or scep was that it defined the process for server side generated keys, which could be beneficial if key generation would be to cumbersome for the device or if you don't trust the device to generate a "good" key.
> 
> Maybe Shahid could give sold more updates since he was helping us with this project
> 
> On Thursday, 2 June 2016, Julien Vermillard <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> In industrial or enterprise M2M/IoT application we often use PSK for authentication, but more and more user want to enroll the device on their public key infrastructure like they does with some routers using SCEP/CMP.
> 
> I wonder if it was explored to enroll devices, and renew certificates on PKI only using CoAP and not HTTP?
> 
> --
> Julien Vermillard

---

From: Julien Vermillard <[email-masked]>
Date: Mon, 6 Jun 2016 15:18:40 +0200

Hi Samuel,
I wonder in which scenario a RNG is safe enough for running a DTLS stack
but not good enough for generating a ECDSA key couple?

--
Julien Vermillard

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 6 Jun 2016 16:30:10 +0200

Hi Julien,

The first one that comes to mind would be where Pre-Shared-keys are used
i.e. symmetric keys. These keys could be factory keys used only to setup
the PKI-keys.

If you look at EST the server generated keys is also recommended to be
wrapped in an extra layer of encryption in addition to the transport layer
security (DTLS/TLS). So if the transport layer security is not absolute no
keys should be leaked.

//Samuel

---

From: Julien Vermillard <[email-masked]>
Date: Mon, 6 Jun 2016 17:05:02 +0200

Yes, but since you need some random numbers for doing a TLS-PSK handshake
(ClientHello random) why a TLS-PSK client should no be able to generate
ECDSA keys?

--
Julien Vermillard

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jun 2016 14:31:05 -0400

Samuel Erdtman <[email-masked]> wrote:
    > beneficial if key generation would be to cumbersome for the device or
    > if you don't trust the
    > device to generate a "good" key.

Hi, these are definitely important considerations.
I would invite you to read the ANIMA bootstrap keying documents, and
possibly join the design team.
At this point I believe the bootstrap is out of scope for ACE.

We are considering whether to use OSCOAP for 6tisch though.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jun 2016 14:33:29 -0400

Julien Vermillard <[email-masked]> wrote:
    > I wonder in which scenario a RNG is safe enough for running a DTLS
    > stack but
    > not good enough for generating a ECDSA key couple?

Particularly since my understanding is that ECDSA signatures (like DSA ones)
require good RNG.  This attribute has also bugged me about DSA, and made me
prefer RSA :-)

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 7 Jun 2016 06:57:53 +0200

Okay so there needs to be some sort of random number generation for the
TLS-PSK handshake, I was not aware of that. (is the requirements on it as
rigor as for the key generation)

The other reason I could think of that is kind of mentioned previously, it
is the "quality" of the generated key, in some deployments, FIPS certified
key generation is required and that could be easier to guarantee
server-side.

But it might be that there are no absolute situations where server-side
key-generation but rather a design option.

//Samuel

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Jun 2016 17:05:17 -0700

ECDSA can be run in a deterministic fashion if desired (see RFC 6979).  Note
that the new EdDSA is only a deterministic signature and no random component
is needed.

Jim

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Monday, June 06, 2016 11:33 AM
> To: Julien Vermillard <[email-masked]>
> Cc: Samuel Erdtman <[email-masked]>; [email-masked]
> Subject: Re: [Ace] Constrained Environment PKI enrollment
> 
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Jun 2016 17:09:15 -0700

The client random value does not need the same quality of randomness that would be desired for a private key generation process – especially a long term key.  I would need to sit down and think about it, but it is quite possible that a counter would work for the client random value.  The main thing you want with this is non-repeating so that the final secret is always uniquely generated.  There have been cases where time has been part of this random value and I don’t believe that it makes the final key any less secure.

Jim

From: Ace [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Monday, June 06, 2016 9:58 PM
To: Julien Vermillard <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Constrained Environment PKI enrollment

Okay so there needs to be some sort of random number generation for the TLS-PSK handshake, I was not aware of that. (is the requirements on it as rigor as for the key generation)

The other reason I could think of that is kind of mentioned previously, it is the "quality" of the generated key, in some deployments, FIPS certified key generation is required and that could be easier to guarantee server-side.

But it might be that there are no absolute situations where server-side key-generation but rather a design option.

//Samuel

On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard <[email-masked] <mailto:[email-masked]> > wrote:

Yes, but since you need some random numbers for doing a TLS-PSK handshake (ClientHello random) why a TLS-PSK client should no be able to generate ECDSA keys?

--
Julien Vermillard

On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman <[email-masked] <mailto:[email-masked]> > wrote:

Hi Julien,

The first one that comes to mind would be where Pre-Shared-keys are used i.e. symmetric keys. These keys could be factory keys used only to setup the PKI-keys.

If you look at EST the server generated keys is also recommended to be wrapped in an extra layer of encryption in addition to the transport layer security (DTLS/TLS). So if the transport layer security is not absolute no keys should be leaked.

//Samuel

On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard <[email-masked] <mailto:[email-masked]> > wrote:

Hi Samuel,

I wonder in which scenario a RNG is safe enough for running a DTLS stack but not good enough for generating a ECDSA key couple?

--
Julien Vermillard

On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman <[email-masked] <mailto:[email-masked]> > wrote:

On Thursday, 2 June 2016, Julien Vermillard <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

--
Julien Vermillard

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Jun 2016 09:39:50 +0200

Hi Shahid,

have you had a chance to look at the work done by the OMA with LWM2M
since it provides this support as well?

Ciao
Hannes

On 06/04/2016 01:01 AM, Shahid Raza wrote:
> We (SICS and neXus) have been working on this since September last year
> and designed and implemented an enrollment protocol over secure CoAP.
> Both the specifications and the Contiki source code will be available
> soon. This is done under the umbrella of a Swedish project called
> CEBOT: Certificate Enrollment in Billions of Things.
> 
> Regards,
> Shahid
> 
>> On 03 Jun 2016, at 17:08, Samuel Erdtman <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> The company I previously worked for where looking into adopting EST
>> for this purpose, the benefit of EST compared to cmp or scep was that
>> it defined the process for server side generated keys, which could be
>> if you don't trust the device to generate a "good" key.
>>
>>     In industrial or enterprise M2M/IoT application we often use PSK
>>     for authentication, but more and more user want to enroll the
>>     device on their public key infrastructure like they does with some
>>     routers using SCEP/CMP.
>>
>>     I wonder if it was explored to enroll devices, and renew
>>     certificates on PKI only using CoAP and not HTTP?
>>
>>     --
>>     Julien Vermillard
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Jun 2016 09:41:42 +0200

Michael,

it depends what "bootstrapping" means.

We have a key distribution mechanism in the OAuth-ACE document (which is
relevant to this specific discussion thread).

Ciao
Hannes

On 06/06/2016 08:31 PM, Michael Richardson wrote:
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Jun 2016 09:46:19 +0200

Hi Jim,

the random value in the DTLS/TLS handshake needs to be random.

In the OAuth-ACE framework we assume some initial keying material
provided to the device (for example using some commissioning tool or
during manufacturing). That key is the long-term key.

Generating further keys that are bound to access tokens is then
something provided by the OAuth-ACE protocol and also there randomness
is needed when deriving the keys (except for the PSK case at the moment
where that key is generated on the server-side).

Note that some ciphers in TLS also utilize ECDHE and therefore also need
to generate those keys.

Ciao
Hannes

PS: Assuming wall-time support is yet another challenge. It is easier to
find micro-controllers with a hardware-based random number generator
than it is to integrate time into the solution.

On 06/09/2016 02:09 AM, Jim Schaad wrote:
> The client random value does not need the same quality of randomness
> that would be desired for a private key generation process – especially
> a long term key.  I would need to sit down and think about it, but it is
> quite possible that a counter would work for the client random value. 
> The main thing you want with this is non-repeating so that the final
> secret is always uniquely generated.  There have been cases where time
> has been part of this random value and I don’t believe that it makes the
> final key any less secure.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> *From:*Ace [mailto:[email-masked]] *On Behalf Of *Samuel Erdtman
> *Sent:* Monday, June 06, 2016 9:58 PM
> *To:* Julien Vermillard <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ace] Constrained Environment PKI enrollment
> 
>  
> 
> TLS-PSK handshake, I was not aware of that. (is the requirements on it
> as rigor as for the key generation)
> 
> The other reason I could think of that is kind of mentioned previously,
> it is the "quality" of the generated key, in some deployments, FIPS
> certified key generation is required and that could be easier to
> guarantee server-side.
> 
> On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Yes, but since you need some random numbers for doing a TLS-PSK
>     handshake (ClientHello random) why a TLS-PSK client should no be
>     able to generate ECDSA keys?
> 
> 
>     --
>     Julien Vermillard
> 
>      
> 
>     On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman <[email-masked]
>         The first one that comes to mind would be where Pre-Shared-keys
>         are used i.e. symmetric keys. These keys could be factory keys
>         used only to setup the PKI-keys.
> 
>         If you look at EST the server generated keys is also recommended
>         to be wrapped in an extra layer of encryption in addition to the
>         transport layer security (DTLS/TLS). So if the transport layer
>         security is not absolute no keys should be leaked.
> 
>          
> 
>         //Samuel
> 
> 
> 
> 
>          
> 
>         On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Samuel,
> 
>             I wonder in which scenario a RNG is safe enough for running
>             a DTLS stack but not good enough for generating a ECDSA key
>             couple?
> 
> 
>             --
>             Julien Vermillard
> 
>              
> 
>             On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman
>             <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                 The company I previously worked for where looking into
>                 adopting EST for this purpose, the benefit of EST
>                 compared to cmp or scep was that it defined the process
>                 for server side generated keys, which could be
>                 beneficial if key generation would be to cumbersome for
>                 the device or if you don't trust the device to generate
>                 a "good" key.
> 
>                  
> 
>                 On Thursday, 2 June 2016, Julien Vermillard
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
> 
>                     Hi,
> 
>                     In industrial or enterprise M2M/IoT application we
>                     often use PSK for authentication, but more and more
>                     user want to enroll the device on their public key
>                     infrastructure like they does with some routers
>                     using SCEP/CMP.
> 
>                     I wonder if it was explored to enroll devices, and
>                     renew certificates on PKI only using CoAP and not HTTP?
> 
> 
>                     --
>                     Julien Vermillard
> 
>              
> 
>          
> 
>      
> 
>  
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Jun 2016 09:49:49 +0200

Julien,

for our current work in OAuth-ACE we don't need such support since the
equivalent functionality is already provided in
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02

It is work we re-use from OAuth and it nicely integrated into the rest
of the flow exchange.

Ciao
Hannes

On 06/03/2016 05:08 PM, Samuel Erdtman wrote:
>     their public key infrastructure like they does with some routers
>     using SCEP/CMP.
>

---

From: Shahid Raza <[email-masked]>
Date: Mon, 20 Jun 2016 12:39:51 +0200

Hi Hannes,
We have looked at it a while ago. 
Unless something is added in near past, LWM2M, in relation to the UDP channel security, discusses certificate provisioning in high-end IoT devices. Also. LWM2M demands the keys to be generated on server side. 
In any case, our work should complement than compete LwM2M. 

Soon leaving for summer vacations and will look into it when back.

Regards,
Shahid

> On 20 Jun 2016, at 09:39, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Shahid,
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 20 Jun 2016 17:25:38 +0000

> On Jun 20, 2016, at 1:41 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Michael,
> 

Hannes, are referencing this statement?
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02

   This framework supports a wide variety of communication security
   mechanisms between the ACE entities, such as client, AS, and RS.  We
   assume that the client has been registered (also called enrolled or
   onboarded) to an AS using a mechanism defined outside the scope of
   this document.  In practice, various techniques for onboarding have
   been used, such as factory-based provisioning or the use of
   commissioning tools.  Regardless of the onboarding technique, this
   registration procedure implies that the client and the AS share
   credentials, and configuration parameters.  These credentials are
   used to mutually authenticate each other and to protect messages
   exchanged between the client and the AS.

My working definition of bootstrapping is exactly the things that are declared out-of-scope in the ace-oauth-authz doc. 

If you meant a different doc could you provide a more specific reference? Thanks,

- max

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