[Ace] EST over CoAP

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 -

Re: [Ace] EST over CoAP

Hannes Tschofenig wrote: > 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 gen

Re: [Ace] EST over CoAP

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:mcr+i...@sandelman.ca] Sent: 14 May 2018 12:39 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST

Re: [Ace] EST over CoAP

f.org Subject: [Ace] EST over CoAP 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 s

Re: [Ace] EST over CoAP

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org<mailto:ace@ietf.org> Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see https://datatracker.ietf.

Re: [Ace] EST over CoAP

Hannes Tschofenig wrote: > 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. It's not really just us, it's time to get people to do the reviews requir

Re: [Ace] EST over CoAP

Hi Michael, -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 14 May 2018 16:46 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > Thanks for the feedback. > Why do you think it takes so l

Re: [Ace] EST over CoAP

Hannes Tschofenig 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,

Re: [Ace] EST over CoAP

t 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:ace-boun...@ietf.org] On Behalf Of Michael Richardson Sent: 14 May 2018 16:54 To: ace@ietf.org Subject: Re: [Ace] EST

Re: [Ace] EST over CoAP

to address some of these comments. From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) mailto:pkamp...@cisco.com>>; ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] EST over CoAP Hi Panos, Thanks

Re: [Ace] EST over CoAP

thenticated identifier is not good for security. Ciao Hannes -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson Sent: 14 May 2018 16:54 To: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > Regarding the randomness r

Re: [Ace] EST over CoAP

removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository with you. Panos *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Hannes Tschofenig *Sent:* Monday, May 14, 2018 5:05 AM *To:* ace@ietf.org *Subject:* [Ace] EST over CoAP Hi all, At IETF#101

Re: [Ace] EST over CoAP

teration, as we have updated to try to address some of these comments. From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) mailto:pkamp...@cisco.com>>; ace@ietf.org<mailto:ace@ietf.org> Subject:

Re: [Ace] EST over CoAP

t no free lunch even if we would like it sooo much. Ciao Hannes -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns Sent: 14 May 2018 22:50 To: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Hannes - Basically, the argument I'm hearing agai

[Ace] EST over CoAP: Introduction

Here is a proposal to change the introduction to the relevant parts only and to avoid repetition. (The current document still keeps talking about IEEE 802.15.4 when there are so many other radio technologies as well. There is nothing in this spec that makes this 15.4 specific. I understand that

Re: [Ace] EST over CoAP

not incur significant workload to the endpoint itself. Rgs, Panos From: Mohit Sethi [mailto:mohit.m.se...@ericsson.com] Sent: Tuesday, May 15, 2018 1:37 AM To: Panos Kampanakis (pkampana) ; Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, How do you intend to use

Re: [Ace] EST over CoAP

ace@ietf.org<mailto:ace@ietf.org> 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 On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote: Hi Hannes, To address your question about s

Re: [Ace] EST over CoAP

o:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) mailto:pkamp...@cisco.com>>; ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] EST over CoAP Hi Panos, Thanks for sharing this info. Regarding the randomness requ

Re: [Ace] EST over CoAP

:* Tuesday, May 15, 2018 1:37 AM *To:* Panos Kampanakis (pkampana) ; Hannes Tschofenig ; ace@ietf.org *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 On 05/14/2018 04:58 PM, Panos Kampanakis

Re: [Ace] EST over CoAP

Ø 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 re

[Ace] EST over CoAP: Randomness

Hi all, I am still a bit unhappy about this paragraph: " Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has also shown that low-resource endpoints sometimes generate n

Re: [Ace] EST over CoAP: Introduction

AM To: ace@ietf.org Subject: [Ace] EST over CoAP: Introduction Here is a proposal to change the introduction to the relevant parts only and to avoid repetition. (The current document still keeps talking about IEEE 802.15.4 when there are so many other radio technologies as well. There is nothing

Re: [Ace] EST over CoAP: Randomness

Hi Hannes, > On 9 May 2019, at 16:42, Hannes Tschofenig wrote: > > Hi all, > > I am still a bit unhappy about this paragraph: > > " > Constrained devices sometimes do not have the necessary hardware to > generate statistically random numbers for private keys and DTLS > ephemeral keys.

Re: [Ace] EST over CoAP: Randomness

Thanks Hannes. Before I try to address it, can you help me understand what you are proposing. To amend this paragraph maybe? -Original Message- From: Ace On Behalf Of Hannes Tschofenig Sent: Thursday, May 09, 2019 10:43 AM To: ace@ietf.org Subject: [Ace] EST over CoAP: Randomness Hi

Re: [Ace] EST over CoAP: Randomness

he IoT space that there is no point in dealing with RSA these days. -Original Message- From: Panos Kampanakis (pkampana) Sent: Freitag, 10. Mai 2019 04:53 To: Hannes Tschofenig ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Thanks Hannes. Before I try to address it, can

Re: [Ace] EST over CoAP: Randomness

Sent: Friday, May 10, 2019 4:58 AM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Panos, I had argued earlier that this feature shouldn't be in the draft but it seems that I will not get there. Hence, I believe it would be better to first shor

Re: [Ace] EST over CoAP: Randomness

: Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP: Randomness Hi Hannes, > Hence, I believe it would be better to first shorten the following paragraph > to a single line: Note that this paragraph was added from feedback in the review process just to motivate server-side

Re: [Ace] EST over CoAP: Randomness

Your text updates look good to me, Panos. Thanks. Hannes From: Panos Kampanakis (pkampana) Sent: Freitag, 10. Mai 2019 13:06 To: Hannes Tschofenig ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Hannes, > Hence, I believe it would be better to first shorten the follow

Re: [Ace] EST over CoAP: Randomness

Hi Esko, good to hear from you. * Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain certificates must be created by the systems under direct control of the IT department. (E.g. to comply w

Re: [Ace] EST over CoAP: Randomness

Dijk ; Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Esko, good to hear from you. * Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain

Re: [Ace] EST over CoAP: Randomness

Esko, your line of thought makes sense to me. I leave it to Panos to enhance the text. Ciao Hannes From: Esko Dijk Sent: Dienstag, 14. Mai 2019 11:57 To: Hannes Tschofenig ; Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Hannes, Agree. The draft

Re: [Ace] EST over CoAP: Randomness

On 5/9/2019 10:42 AM, Hannes Tschofenig wrote: I believe we should encourage developers to pick the correct hardware for the task rather than making them believe we have come up with solutions that allow them to get away without a hardware-based RNG. I also do not believe the statement that r

Re: [Ace] EST over CoAP: Randomness

) cost and price of an MCU are different aspects. Ciao Hannes -Original Message- From: Paul Duffy Sent: Dienstag, 14. Mai 2019 15:08 To: Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP: Randomness On 5/9/2019 10:42 AM, Hannes Tschofenig wrote: > I believe we should encoura

Re: [Ace] EST over CoAP: Randomness

My understanding of the use case for server generated keys is for existing, deployed systems where the system can easily get a firmware update, but the hardware TPM itself is unable/unwilling to generate new keys, and can't be upgraded, but keys can be loaded. Systems like Hannes' company produce

Re: [Ace] EST over CoAP: Randomness

HA256 and AES in hardware), and (d) cost and price of an MCU are different aspects. Ciao Hannes -Original Message- From: Paul Duffy Sent: Dienstag, 14. Mai 2019 15:08 To: Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP: Randomness On 5/9/2019 10:42 AM, Hannes Tsc

Re: [Ace] EST over CoAP: Randomness

-quality random numbers is therefore important. [ … ] ~ I am planning to reupload by the end of the week. Rgs, Panos From: Hannes Tschofenig Sent: Tuesday, May 14, 2019 3:28 PM To: Esko Dijk ; Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Esko

Re: [Ace] EST over CoAP: Randomness

On 5/14/2019 7:29 PM, Hannes Tschofenig wrote: Hi Paul, My understanding from reading the draft text was that the "cost" was actually talking about "energy cost" rather than "monetary cost". The monetary cost may also be interesting. It is difficult to judge the extra cost of a RNG in an MCU b

Re: [Ace] EST over CoAP: Randomness

Hi Mike, A few remarks inline. On 5/14/2019 7:29 PM, Hannes Tschofenig wrote: > Hi Paul, > > My understanding from reading the draft text was that the "cost" was actually > talking about "energy cost" rather than "monetary cost". > The monetary cost may also be interesting. > > It is difficult t

[Ace] EST over CoAP in ACE wg

Dear ACE members Peter van Stok gave a short overview during the ACE f2f meeting on the work related to EST (RFC 7030) over DTLS secured CoAP (draft-vanderstok-core-coap-est-00). In the meeting there was general interest among the a

[Ace] EST over CoAP PKCS#10 encoding

Hi, I'm currently implementing EST over CoAP. I wonder why, on simple enrollment, the payload is put in a CBOR binary string? I understand why dropping base64, but just putting the PKCS#10 binary in the CoAP payload is technically enough. What is the benefit of CBOR encapsulation? BTW you have a

[Ace] EST over CoAP at 104 hackathon?

Hello, I have not seen any mention of the upcoming 104 hackathon on this list.  Is it possible there might be a group or two that to a point where they would want to test their implementation of EST over CoAP? Thanks, Pete ___ Ace mailing list Ace@ietf

Re: [Ace] EST over CoAP in ACE wg

sulta...@vanderstok.org' Subject: [Ace] EST over CoAP in ACE wg Dear ACE members Peter van Stok gave a short overview during the ACE f2f meeting on the work related to EST (RFC 7030) over DTLS secured CoAP (draft-vanderstok-core-coap-est-00<https://tools.ietf.org/html/draft-vanderstok-core-coap-est-

Re: [Ace] EST over CoAP in ACE wg

I think this is a good idea. Eliot On 11/21/16 3:00 PM, Kumar, Sandeep wrote: > Dear ACE members > > Peter van Stok gave a short overview during the ACE f2f meeting on the work > related to EST (RFC 7030) over DTLS secured CoAP > (draft-vanderstok-core-coap-est-00

Re: [Ace] EST over CoAP in ACE wg

+1 on ACE taking up this work. From: Kumar, Sandeep [mailto:sandeep.ku...@philips.com] Sent: Monday, November 21, 2016 9:00 AM To: ace@ietf.org Cc: 'consulta...@vanderstok.org' ; Panos Kampanakis (pkampana) ; Shahid Raza Subject: EST over CoAP in ACE wg Dear ACE members Peter van Stok gave a s

Re: [Ace] EST over CoAP in ACE wg

Hi All, To run EST over DTLS and CoAP to address more constrained devices is not new to me, this was part of conversations that neXus (my previous employer) and SICS had about one and a half year ago. I would support this work. I think certificates makes sense for ACE because of the connection to

Re: [Ace] EST over CoAP in ACE wg

Hi, Thanks for the initiative Sandeep. I fully support this. As Samuel mentioned, SICS has been working with neXus on this solution for more than a year now. We would be glad to bring in our experience and would be happy to share our Contiki side and the SICSthSense side (sense.sics.se

Re: [Ace] EST over CoAP in ACE wg

I support this work and it being done in ACE. Thanks, Brian On Nov 21, 2016, at 6:00 AM, Kumar, Sandeep mailto:sandeep.ku...@philips.com>> wrote: Dear ACE members Peter van Stok gave a short overview during the ACE f2f meeting on the work related to EST (RFC 7030) over DTLS secured CoAP (dra

Re: [Ace] EST over CoAP in ACE wg

Hi All, My first post after joining the list. As mentioned by Shahid and Samuel, Nexus Group and SICS began a joint project over a year ago for enabling constrained devices enroll for certificates using EST over CoAP. A standard EST server add-on will soon be part of the Nexus Certificate Manag

Re: [Ace] EST over CoAP in ACE wg

I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch environment as a zero-touch enrollment process. (Yes, I am an auth

Re: [Ace] EST over CoAP in ACE wg

see inline Martin Furuhed Nexus wrote: > My first post after joining the list. welcome! > As mentioned by Shahid and Samuel, Nexus Group and SICS began a joint > project over a year ago for enabling constrained devices enroll for > certificates using EST over CoAP. > A sta

Re: [Ace] EST over CoAP in ACE wg

Hi Michael, As such, what we would really like is an EST-like mechanism which runs over OSCOAP with EDHOC keying. Ideally, it would also permit the process to be managed/initiated from the new device (the pledge), or from the JCE (Registrar, which might also be the AS in ACE terminology).

Re: [Ace] EST over CoAP PKCS#10 encoding

HI Julien, Julien Vermillard schreef op 2017-03-30 09:08: Hi, I'm currently implementing EST over CoAP. Great, that is good news. I wonder why, on simple enrollment, the payload is put in a CBOR binary string? I understand why dropping base64, but just putting the PKCS#10 binary in the CoA

Re: [Ace] EST over CoAP PKCS#10 encoding

Hi, Thanks for your answer. I think content negotiation should be done using the Content-Format option like other CoAP based protocols. And would also match the HTTP way to do it. -- Julien Vermillard On Thu, Mar 30, 2017 at 4:16 PM, peter van der Stok wrote: > HI Julien, > > > Julien Vermilla

Re: [Ace] EST over CoAP PKCS#10 encoding

Hi, Right, will look into it. The github address is: https://github.com/SanKumar2015/EST-coaps Peter Julien Vermillard schreef op 2017-03-30 09:23: Hi, Thanks for your answer. I think content negotiation should be done using the Content-Format option like other CoAP based protocols. And would