Subject: [Ace] EST over CoAP

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2018 09:05:09 +0000

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

-          Operational parameter values

-          Server side key generation using simple multipart encoding

-          Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the meeting but in general I am curious where we are with the document. It would be great to get it finalized. It appears that we are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 May 2018 07:38:54 -0400

> I have challenged the usefulness of the server-side key generation
    > during the meeting but in general I am curious where we are with the
    > document. It would be great to get it finalized. It appears that we are
    > adding new features and therefore will not be able to complete the work
    > in any reasonable timeframe.

Server side key generation is not the only way to use this, and I'm not
interested in it myself.

I don't think we can do http/coap proxying in any meaningful way if
we are using TLS/DTLS for the secure transport.  I have encouraged my
co-authors to either take it out, or realize that they are confusing
the EST link (over DTLS) with the Registration Authority<->Certificate
Authority link (over HTTPS).

    > So, do we have a plan for how to complete the document?

I am implementing at this time, with CoAP over DTLS using OpenSSL today,
and mbedTLS for the pledge side in a week or two.   I believe that we can
finish this document by the end of the summer.  I don't think we'd get to
WGLC before IETF102, and as August is a dead zone for IETF work, having a
WGLC before September 1 would seem pointless.

-- 
]               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: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2018 11:53:35 +0000

Hi Michael,

Thanks for the feedback.

Why do you think it takes so long to get this document finished? In the end, you are just carrying EST over CoAP instead of conveying it over HTTP.

Ciao
Hannes

PS: Regarding the use of DTLS/TLS for the proxy. There are obviously ways to get this accomplished but the question for me is whether this functionality should go into this version of the spec or rather a companion document.

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]]
Sent: 14 May 2018 12:39
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ace] EST over CoAP

    > in any reasonable timeframe.

Server side key generation is not the only way to use this, and I'm not interested in it myself.

I don't think we can do http/coap proxying in any meaningful way if we are using TLS/DTLS for the secure transport.  I have encouraged my co-authors to either take it out, or realize that they are confusing the EST link (over DTLS) with the Registration Authority<->Certificate Authority link (over HTTPS).

I am implementing at this time, with CoAP over DTLS using OpenSSL today,
and mbedTLS for the pledge side in a week or two.   I believe that we can
finish this document by the end of the summer.  I don't think we'd get to WGLC before IETF102, and as August is a dead zone for IETF work, having a WGLC before September 1 would seem pointless.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 14 May 2018 13:58:22 +0000

Hi Hannes,

To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration
~~~~~~~~~~~~~
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has shown that cheap endpoints
   sometimes generate numbers which could allow someone to decrypt the
   communication or guess the private key and impersonate as the device.
   Studies have shown that the same keys are generated by the same model
   devices deployed on-line.

   Additionally, random number key generation is costly, thus energy
   draining.  Even though the random numbers that constitute the
   identity/cert do not get generated often, an endpoint may not want to
   spend time and energy generating keypairs, and just ask for one from
   the server.

   In these scenarios, server-side key generation can be used.  The
   client asks for the server or proxy to generate the private key and
   the certificate which is transferred back to the client in the
   server-side key generation response.
~~~~~~~~~~~~~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the working copy of the draft as well. We no longer call this functionality proxying, but instead use the concept of the registrar that terminates the connection and establishes the next one.

We didn't add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with you.

Panos

From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: [email-masked]
Subject: [Ace] EST over CoAP

Hi all,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2018 14:14:29 +0000

Hi Panos,

Thanks for sharing this info.

Regarding the randomness requirement and the energy consumption. We have been a bit advocate for adding hardware-based random numbers to devices since randomness is a basic requirement for most security protocols.
You do not only need to have access to random numbers during key generation but also later when you use nonces, a DH exchange, create session keys, and IVs, and potentially even for signature generation. If you use a protocol that is not based on nonces then you may use one that relies on timestamps, which may not make the story necessarily easier.

Random number key generation is also not necessarily costly either (neither in terms of energy cost nor in terms of hardware costs).

Hence, I think you should consider the server-side key generation very carefully since you are essentially destroying the benefits of public key crypto and introduce a big vulnerability.

In a nutshell, I think you are better of recommending OEMs to select the right hardware for the given task.

Ciao
Hannes

PS: For the proxy work (in context of DTLS/TLS) you might want to reach out to your co-worker Owen Friel.

From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; [email-masked]
Subject: RE: EST over CoAP

Hi Hannes,

Panos

From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] EST over CoAP

Hi all,

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 May 2018 10:45:45 -0400

> Why do you think it takes so long to get this document finished? In the
    > end, you are just carrying EST over CoAP instead of conveying it over
    > HTTP.

It's not really just us, it's time to get people to do the reviews required :-)
It's also constrained about getting other documents out.  RFC8366 spent 4
weeks in AUTH48 due to a small YANG correction discovered at the last minute.
(And we had to bikeshed the title)

    > PS: Regarding the use of DTLS/TLS for the proxy. There are obviously
    > ways to get this accomplished but the question for me is whether this
    > functionality should go into this version of the spec or rather a
    > companion document.

I don't understand the use case.
EST requires a secure transport from requesting entity to Registrar.
A DTLS/TLS proxy represents a MITM, and I don't see a way for either party to
trust it.    I have been pushing to better detail how people want this to work.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2018 14:51:34 +0000

Hi Michael,

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]]
Sent: 14 May 2018 16:46
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ace] EST over CoAP

    > end, you are just carrying EST over CoAP instead of conveying it over

It's not really just us, it's time to get people to do the reviews required :-) It's also constrained about getting other documents out.  RFC8366 spent 4 weeks in AUTH48 due to a small YANG correction discovered at the last minute.
(And we had to bikeshed the title)

[Hannes] Fully understand. I am just advocating that we keep things going at a reasonable pace. I have seen documents hanging around waiting for not further defined events.
Since we are implementing this functionality I want to make sure we don't see surprises last minute.

[Hannes] I guess we will speculate about it when that work gets started in another document.

Ciao
Hannes

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 May 2018 10:53:48 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > Regarding the randomness requirement and the energy consumption. We
    > have been a bit advocate for adding hardware-based random numbers to
    > devices since randomness is a basic requirement for most security
    > protocols.

I think that this is the future, and I very much agree with you.

There seems to be a stock of older designs which have gone through other
kinds of validation (for instance, think about the engineering review of
physical cases and PCB design for electric metering).

My impression is that there is a desire to significantly update the security
profile of these devices (some of which are in the field already).  What was
deployed had poor security, or had proprietary protocols and there is a
desire to move it up to "par".

The other thing I hear is that the crypto libraries involved take some time
to get FIPS-140 certified and so the one that the devices were deployed with
do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and
means new keys.

I think that any device with any kind of TPM would rather generate it's own
keys.  Whether it's a physical TPM, or some kind of TrustZone,etc. version.

    > the right hardware for the given task.

I'd like to find some text that acknowledges the past, while setting things
up better for the future.

    > out to your co-worker Owen Friel.

he's in other loops already, but he seems shy to post to lists.

    > IMPORTANT NOTICE: The contents of this email and any attachments are

I wish your email system would omit this, as it's both meaningless and
sometimes harmful.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2018 18:49:05 +0000

Here is my personal take on this: you have to do your threat assessment to find out what attacks you care about. This will determine your hardware requirements (not the other way around). At a minimum you will have to figure out how to provide randomness in your design and that can come at a very low cost. For example, if I use ST's MCU finder http://www.st.com/en/development-tools/st-mcu-finder.html and search for microcontrollers that have TRNG support then I get 410 results (only for STM MCUs).

If you aim for devices that also provide ECC/RSA crypto in hardware + tamper-resistant key storage then we will move past the RFC 7228-type of constrained IoT device classes. You have can a look of what this means in context of Arm IP: https://developer.arm.com/products/system-ip/trustzone-security-ip

On a meta-level I have difficulties with the security design decisions made in IETF IoT-related groups since they swing back and forth between the extremes in pretty much no time. At the London IETF meeting I hear people talking about drafting guidelines for the use of new crypto algorithms with IoT devices since P256r1 and AES128-CCM is not good enough for them. At the same time I am having a hard time convincing people that using an unauthenticated identifier is not good for security.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 14 May 2018 16:54
To: [email-masked]
Subject: Re: [Ace] EST over CoAP

There seems to be a stock of older designs which have gone through other kinds of validation (for instance, think about the engineering review of physical cases and PCB design for electric metering).

My impression is that there is a desire to significantly update the security profile of these devices (some of which are in the field already).  What was deployed had poor security, or had proprietary protocols and there is a desire to move it up to "par".

The other thing I hear is that the crypto libraries involved take some time to get FIPS-140 certified and so the one that the devices were deployed with do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means new keys.

I think that any device with any kind of TPM would rather generate it's own keys.  Whether it's a physical TPM, or some kind of TrustZone,etc. version.

    > the right hardware for the given task.

I'd like to find some text that acknowledges the past, while setting things up better for the future.

    > IMPORTANT NOTICE: The contents of this email and any attachments are

I wish your email system would omit this, as it's both meaningless and sometimes harmful.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 14 May 2018 19:24:15 +0000

Your recommendation about having the right hardware is valid and what everyone should do as much as possible. What about Class 1 OEMs that cannot add the hardware you are recommending? Or even the ones that will not comply with the recommendations for their own reasons? We can't forget about those.

Is the vulnerability that you were referring to that the RA or CA have to generate the key? Trust of these entities needs to be established or this model falls apart anyway. It is up to the admin to decide if it trusts the Registrar will not store and reveal the private keys or generate insecure keys on the device itself. I am more concerned about this vulnerability https://www.kb.cert.org/vuls/id/566724 where some thousands of devices have the same identity and now they can all impersonate each other in my network as shown in https://jhalderm.com/pub/papers/https-imc13.pdf and https://factorable.net/paper.html

We agree on the other ephemeral keys used in secure communications. Good hardware would solve these issues. Without secure hardware some of these communications could be decrypted assuming the right resources. Even though, decrypting some data per connection is a concern, I don't think that the risk is as high as a compromised identity. Also, the former concern does not mean we should not have an option to eliminate the latter.

About the Proxy section 6, I would like to see comments about in in the next iteration, as we have updated to try to address some of these comments.

From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] EST over CoAP

Hi Panos,

Ciao
Hannes

From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
Subject: RE: EST over CoAP

Hi Hannes,

Panos

Hi all,

Ciao
Hannes

---

From: Michael StJohns <[email-masked]>
Date: Mon, 14 May 2018 16:50:03 -0400

Hi Hannes -

Basically, the argument I'm hearing again is that we have to have common 
protocols that work with the least capable devices in the same way that 
they work with more capable devices.   Which then is taken to mean that 
we have to limit the security of said protocols to what's available with 
those most limited devices.

This seems to be a bad argument both for the big guys and for the small 
guys.  And its really not about the hardware requirements for a specific 
device that should be the concern of the IETF, but about specifying the 
protocol requirements - said requirements being reasonable for the 
specific limited field of use.

E.g. The recommendation must be for a "good" RNG - that doesn't 
necessarily translate to a requirement for a hardware TRNG, but if 
that's what you need to get to "good", then that's what the builder 
should spec.

I'm wondering if its time to fork the Internet Standards path and create 
an IOT Standards RFC path that deals with these less capable devices, 
explains that these are not to be used for larger devices unless talking 
to the constrained devices, but which still gets the IETF standards 
process treatment?  RFC 7228 may have done us a disservice by not 
explaining what the minimum capable security services were for each of 
the classes.

Mike

On 5/14/2018 2:49 PM, Hannes Tschofenig wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Mohit Sethi <[email-masked]>
Date: Tue, 15 May 2018 08:37:10 +0300

Hi Panos,

How do you intend to use these server generated keys once they are 
provisioned onto the device?

--Mohit

On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:
>
> Hi Hannes,
>
> To address your question about server-side key gen, below is the 
> explanation we have put in the draft already and will be in the next 
> iteration
> /~~~~~~~~~~~~~/
>
> /   Constrained devices sometimes do not have the necessary hardware to/
>
> /   generate statistically random numbers for private keys and DTLS/
>
> /   ephemeral keys. Past experience has shown that cheap endpoints/
>
> /   sometimes generate numbers which could allow someone to decrypt the/
>
> /   communication or guess the private key and impersonate as the device./
>
> /   Studies have shown that the same keys are generated by the same model/
>
> /   devices deployed on-line./
>
> //
>
> /   Additionally, random number key generation is costly, thus energy/
>
> /   draining.  Even though the random numbers that constitute the/
>
> /   identity/cert do not get generated often, an endpoint may not want to/
>
> /   spend time and energy generating keypairs, and just ask for one from/
>
> /   the server./
>
> //
>
> /   In these scenarios, server-side key generation can be used.  The/
>
> /   client asks for the server or proxy to generate the private key and/
>
> /   the certificate which is transferred back to the client in the/
>
> /   server-side key generation response./
> /~~~~~~~~~~~~~/
>
> About the proxy-Registrar question, we already have made the change in 
> the working copy of the draft as well. We no longer call this 
> functionality proxying, but instead use the concept of the registrar 
> that terminates the connection and establishes the next one.
>
> We didn’t add any new features in the doc after removing the BRSKI stuff.
>
> *From:* Ace [mailto:[email-masked]] *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, May 14, 2018 5:05 AM
> *To:* [email-masked]
> *Subject:* [Ace] EST over CoAP
>
> Hi all,
>
> -Operational parameter values
>
> -Server side key generation using simple multipart encoding
>
> -Explain trust relations for http/coap proxying
>
> document. It would be great to get it finalized. It appears that we 
> are adding new features and therefore will not be able to complete the 
> work in any reasonable timeframe.
>
> confidential and may also be privileged.. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 May 2018 08:27:17 +0000

Hi Panos,

I would say forget class 1 devices when you want to use public key crypto.

https://factorable.net/paper.html (and https://jhalderm.com/pub/papers/https-imc13.pdf  since it revisits the earlier analysis) was a problem with understanding where the entropy comes from. If you take a regular desktop Linux and remove keyboard, mouse, disk drive, complex process scheduling etc. then the ordinary entropy sources are suddenly gone. That was the problem identified in that paper.

I am worried about keys across devices. For this reason we have standardized protocols to allow you to provision devices with new keys. Here is a whitepaper published not too long ago that discusses the issue, see https://www.omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Credential-Management_Final.pdf

I believe you would agree with me that there is a lot of value in the public key crypto since you don't have to expose the private key. If your design suddenly still requires this then you are losing some of the good properties of public key crypto systems.

Ciao
Hannes

Sent: 14 May 2018 21:24

Hi Panos,

Ciao
Hannes

Hi Hannes,

Panos

Hi all,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 May 2018 08:30:01 +0000

Hi Mike,

You are getting the story wrong.

First, the boundary between what is IoT and what isn't isn't that clear. One man's IoT is another man's data center.

Second, many of the problems we run into are fundamental to crypto rather than the protocol design. There is just no free lunch even if we would like it sooo much.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: 14 May 2018 22:50
To: [email-masked]
Subject: Re: [Ace] EST over CoAP

Hi Hannes -

Basically, the argument I'm hearing again is that we have to have common protocols that work with the least capable devices in the same way that they work with more capable devices.   Which then is taken to mean that we have to limit the security of said protocols to what's available with those most limited devices.

This seems to be a bad argument both for the big guys and for the small guys.  And its really not about the hardware requirements for a specific device that should be the concern of the IETF, but about specifying the protocol requirements - said requirements being reasonable for the specific limited field of use.

E.g. The recommendation must be for a "good" RNG - that doesn't necessarily translate to a requirement for a hardware TRNG, but if that's what you need to get to "good", then that's what the builder should spec.

I'm wondering if its time to fork the Internet Standards path and create an IOT Standards RFC path that deals with these less capable devices, explains that these are not to be used for larger devices unless talking to the constrained devices, but which still gets the IETF standards process treatment?  RFC 7228 may have done us a disservice by not explaining what the minimum capable security services were for each of the classes.

Mike

On 5/14/2018 2:49 PM, Hannes Tschofenig wrote:
> If you aim for devices that also provide ECC/RSA crypto in hardware +
> tamper-resistant key storage then we will move past the RFC 7228-type
> of constrained IoT device classes. You have can a look of what this
> means in context of Arm IP:
> https://developer.arm.com/products/system-ip/trustzone-security-ip
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 15 May 2018 14:00:36 +0000

Hi Mohit,
These priv/public keypairs+cert are provisioned and used on the endpoint as identity for authentication. If tamper-resistance is not supported on the endpoint, the keypairs could be reprovisioned more often than the traditional cert lifetime as the server-side key gen transaction does not incur significant workload to the endpoint itself.
Rgs,
Panos

From: Mohit Sethi [mailto:[email-masked]]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Ace] EST over CoAP

Hi Panos,

How do you intend to use these server generated keys once they are provisioned onto the device?

--Mohit

Panos

Hi all,

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Ace mailing list

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 May 2018 14:15:53 +0000

FWIW I would untangle the tamper resistance property from the lifetime of these keys.
You will want to issue new keys periodically anyway.

From: Ace [mailto:[email-masked]] On Behalf Of Panos Kampanakis (pkampana)
Sent: 15 May 2018 16:01
To: Mohit Sethi; [email-masked]
Subject: Re: [Ace] EST over CoAP

Hi Mohit,

From: Mohit Sethi [mailto:[email-masked]]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] EST over CoAP

Hi Panos,

--Mohit

Panos

From: Ace [mailto:[email-masked]<mailto:ace-bounces@ietf..org>] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] EST over CoAP

Hi all,

Ciao
Hannes

Ace mailing list

https://www.ietf..org/mailman/listinfo/ace<https://www.ietf.org/mailman/listinfo/ace>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 15 May 2018 20:07:44 +0000

Agreed. I see your point. I had read your whitepaper sometime back I think. Indeed ACE-Oath, or LWM2M KDC, or OCF DOXS could provide address the credential management issue. But I don't think we can tell endpoints that they are on their own unless they get the right hardware or they comply with the ACE-OAuth model, or DOXS.

EST server-side key gen is free in a sense does not require new entities. We are not introducing a new concept. If your EST-coaps server supports it, you could use it. But you do not need to even implement the server-side EST URI unless you want to. And of course server-side key gen does not address the whole credential issue which includes token, certs, raw public keys. It just gets an identity/priv keypair to the device.

Your feedback brings up good points, which I think we ought to elaborate on in the relevant sections and in the Security Considerations.

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Tuesday, May 15, 2018 4:27 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: EST over CoAP

Hi Panos,

Ciao
Hannes

Hi Panos,

Ciao
Hannes

Hi Hannes,

Panos

Hi all,

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 16 May 2018 11:07:46 +0300

Hi Panos,

I wonder what kind of devices you have in mind? On one hand, the devices 
are constrained enough not to have resources for generating 
cryptographic quality randomness. But they somehow have support for 
tamper-resistance identity protection? Is it cheaper to have 
tamper-resistance? And is it somehow more energy-efficient?

I understand that generating strong identities and storing them securely 
are different issues. But I would be interested to learn about IoT 
devices that have tamper-resistance storage but no possibility of 
generating cryptographic quality randomness. Also, what protocols do you 
think the devices would use for authenticating these identities?

--Mohit

On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote:
>
> Hi Mohit,
>
> These priv/public keypairs+cert are provisioned and used on the 
> endpoint as identity for authentication. If tamper-resistance is not 
> supported on the endpoint, the keypairs could be reprovisioned more 
> often than the traditional cert lifetime as the server-side key gen 
> transaction does not incur significant workload to the endpoint itself.
>
> Rgs,
>
> Panos
>
> *From:*Mohit Sethi [mailto:[email-masked]]
> *Sent:* Tuesday, May 15, 2018 1:37 AM
> *To:* Panos Kampanakis (pkampana) <[email-masked]>; Hannes 
> Tschofenig <[email-masked]>; [email-masked]
> *Subject:* Re: [Ace] EST over CoAP
>
> Hi Panos,
>
>     explanation we have put in the draft already and will be in the
>     next iteration
>     /~~~~~~~~~~~~~/
>
>     About the proxy-Registrar question, we already have made the
>     change in the working copy of the draft as well. We no longer call
>     this functionality proxying, but instead use the concept of the
>     registrar that terminates the connection and establishes the next
>     one.
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     during the meeting but in general I am curious where we are with
>     the document. It would be great to get it finalized. It appears
>     that we are adding new features and therefore will not be able to
>     complete the work in any reasonable timeframe.
>
>     IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged.. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 May 2018 09:16:19 +0000

Ø  But I don't think we can tell endpoints that they are on their own unless they get the right hardware or they comply with the ACE-OAuth model, or DOXS.

[This is probably an issue unrelated to EST topic but worthwhile to talk about nevertheless.]

How do you expect companies to come up with reasonable IoT security?

Our (Arm) thinking was that working on building blocks that are then combined in complete IoT device management solutions (like LwM2M) and supplemented with security guidance that includes the implementation (software & hardware), as we do it with the Platform Security Architecture (see https://developer.arm.com/products/architecture/platform-security-architecture), is the only way to improve IoT security. If you just dump ideas and protocols with lots of options to OEMs and let them figure out the security story themselves then guess what the outcome will be.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 18:50:52 -0400

Michael StJohns <[email-masked]> wrote:
    > Basically, the argument I'm hearing again is that we have to have
    > common protocols that work with the least capable devices in the same
    > way that they work with more capable devices.   Which then is taken to
    > mean that we have to limit the security of said protocols to what's
    > available with those most limited devices.

This is not really what's going on here.

The argument is whether device generate private keys should be supported
in the constrained version of EST.  The RA/CA (RFC5280 terms) side of things
in generally assumed not be seriously contrained.
(I expect to install a CA on an openwrt based Turris home router, but that's
equivalent to a 15 year old laptop, and hardly counts as constrained)

There is no reason why a RA/CA(%) can't support server-side key generation
according to RFC7030 section 4.4 as well as permitting capable devices to
generate their own keys.

Having the CA generate keys seemed to be all the rage at some point.
I was never clear if this was because desktop OSes couldn't be trusted
to do it properly, or because end-users wanted their private key as
part of their mobile profile, or because of the implicit escrow that it
permitted. (Remember splitting signing and encrypting keys...)

Panos' situation is, I understand, that he has customers with an extensive
deployment of devices in the field.  They currently use a proprietary
enrollment and key distribution system.  They want to "upgrade" to CoAP-EST,
but clearly there are some concerns about local key generation.  I don't know
why exactly, but I suspect it has to with the validation (FIPS140) of the
libraries available on that platform: perhaps they are not validated to
create their own keys...(yet?)

But they can be field upgraded in an unattended fashion to use a standard
protocol, as long as they don't have to do new crypto tricks *today*.

(%)- In smaller/self-contained systems, the Registration Authority (RA) is
     often co-located (part of, implemented by the same system) with the
     Certificate Authority.
     I actually don't know if the RA or CA generates the private key.