[Ace] Iotdir early review of draft-ietf-ace-wg-coap-eap-08

Reviewer: Eliot Lear Review result: On the Right Track This draft provides a means for EAP authentication via CoAP. This is an evolution on top of EAPoL/EAP so as to not require 802.1X on certain classes of devices. The general goal of reusing existing EAP methods – and code – is admirable. I

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] Working group adoption of draft-vanderstok-ace-est

Hi Jim, I agree that this document should be adopted.  I am willing to review and comment. Eli On 30.01.18 21:23, Jim Schaad wrote: > This is the start of a two week call for input on the adoption of the WG of > the document draft-vanderstok-ace-est. The document has been presented at > the la

Re: [Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-04.txt

Hi, Is this ready for publication as a WG draft? Eliot On 22.01.18 09:38, peter van der Stok wrote: > Hi Ace, WG-chairs, > > This new version of coap-est takes into account the remarks made by > Hannes; thanks Hannes. > > This version looks appropriate for acceptance by the WG. > > Greetings, >

Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est

Hi Hannes, To keep things simple to understand, what would be best is the closest analog to EST/HTTP.  I don't object to other work going on, however. Eliot On 9/13/17 5:42 PM, Hannes Tschofenig wrote: > Hi all, > > in previous IETF meetings we had presentations on these two documents > and it

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

+1. On 3/7/17 9:33 AM, peter van der Stok wrote: > After reading Jim's statement, my position is a bit different. > Multicast security is severely needed. > Not making it a WG document augments the risk that the subject is > frozen and no progress is made. > To guarantee progress, adoption seems

Re: [Ace] Asymmetric signature performance

On 2/9/17 4:45 PM, Derek Atkins wrote: > Hi, > > "Panos Kampanakis (pkampana)" writes: > >> I am not saying symmetric keys are better than public key auth. >> I am saying that applying an 80-bit security level (RSA/DSA1024) today >> offers a false sense of security. You might as well not authen

Re: [Ace] Doodle for ACE virtual interim meeting

I think at least one of the draft authors is away until the 8th. Can we push out a week? Eliot On Jan 13, 2017, at 6:01 PM, Kepeng Li mailto:kepeng@alibaba-inc.com>> wrote: Oh, sorry, my mistake. I made a mistake between you and Mike Jones. Let's change our call to Option 1, 9th Feb, Th

Re: [Ace] where are we with draft-somarju-ace-multicast?

On 12/22/16 11:36 PM, Michael StJohns wrote: > > > On 12/22/2016 3:42 AM, Eliot Lear wrote: >> Hi, >> >> This working group has been in a state of indecision about this draft >> for quite some time and I would like to gain some clarity on the matter. >> &

[Ace] where are we with draft-somarju-ace-multicast?

Hi, This working group has been in a state of indecision about this draft for quite some time and I would like to gain some clarity on the matter. On the one hand, we have a draft that there seems to be unanimous agreement would be useful to the lighting people. On the other hand, we have some c

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] Summary of ACE Group Communication Security Discussion

Hi Mike, Just one clarification: On 9/26/16 5:41 PM, Michael StJohns wrote: > > With respect to Eliot's comment, it doesn't really matter if the key > management protocol is asymmetric if the multicast session keys are > symmetric and used for control. This doesn't really capture my position

Re: [Ace] Summary of ACE Group Communication Security Discussion

Hi, On 9/26/16 7:11 PM, Kepeng Li wrote: > > Please correct us if we are wrong in our interpretation of your mail > postings. > Perhaps my middle ground didn't seem important, but I had thought it was a good way forward: require asymmetric for group admission (as Abhinav & co do), group keying fo

Re: [Ace] Group Communication Security Disagreements

Hi Mike, On 9/15/16 5:36 PM, Michael StJohns wrote: > Hi Elliot et al - > > Sorry, I think you're still missing the point: > > * Source Authentication (A) cannot be accomplished securely by > Symmetric Key Multicast (^B): (A -> ^B) > * Cyber Physical control functions (C) require sour

Re: [Ace] Group Communication Security Disagreements

Hi Abhinav, Thanks for this email. I think this is pretty close to what I think is necessary. To be sure, vendors and developers have very little power to limit where their products will be placed. Thus it is important to state strongly that source authentication is necessary at other layers wh

Re: [Ace] Group Communication Security Disagreements

Hi Ludwig and Mike, In thinking about this problem, I wonder if the challenge here really is a matter of layering. First of all, if we were to do source authentication, what would that mean? Would it mean that all messages were signed? If so, what sort of format would we be talking about? IPSE

Re: [Ace] Group Communication Security Disagreements

Hi, Reflecting on this discussion and the adoption of the related draft, if the draft is adopted I would suggest that before it goes forward an auditing section should be added to security considerations so that appropriate advice is given in the case a member of a group is compromised. I could e

Re: [Ace] Group Communication Security Disagreements

On 7/28/16 4:31 PM, Paul Duffy wrote: > +1 > > On 7/28/2016 10:02 AM, Michael Richardson wrote: >> I'm not convinced. What I have taken home is that people think they >> want to >> use symmetric keys, and perhaps it might be safe among completely >> equivalent >> devices. I take your point (stro

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Markus, Thanks for this. I think you've summed up the problem in a nut shell. Please see below. On 7/27/16 2:34 PM, Grunwald, Markus wrote: > > > For me, this leads to multiple security levels: > > 1) Basic security: fast response, low cost with lower security: > use symmetric keys. Us

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

ther information > such as commissioning data. > > Abhinav > > > Sent from my Windows Phone > ---- > From: Eliot Lear <mailto:l...@cisco.com> > Sent: ‎26/‎07/‎2016 17:59 > To: Kathleen Moriar

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Hi Kathleen, On 7/26/16 4:52 PM, Kathleen Moriarty wrote: > What is the bigger threat model? > > Lights turning on/off in large buildings could result in increased > energy costs. > Lights turning on/off could result in safety issues (they could be > extreme). It's also a matter of changing co

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

On 7/25/16 8:07 PM, Michael StJohns wrote: > > The receiver has no guaranteed way of knowing whether or not ANY group > member is compromised so the authentication is pretty much meaningless. I would just add that it is also more difficult to determine just which device has been broken into afte

Re: [Ace] Group Communication Security Disagreements

Hi Hannes, On 7/25/16 5:47 PM, Hannes Tschofenig wrote: > In order for the attack to work a luminary and a door lock need to be in > the same group and share the same group key. > > For me the question is (from an authorization point of view) why the > door lock as well as a luminary belong to th

Re: [Ace] Group Communication Security Disagreements

On 7/21/16 3:48 PM, Michael StJohns wrote: > Without unique source identification (and for that matter role > identification either inband or implicit) any compromised device > results in your attacker being able to act as a controller for the > group. Again, not a large problem (but a problem n

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Hi Hannes, On 7/21/16 12:30 AM, Hannes Tschofenig wrote: > Hi Thomas, > > thanks for the response. > > > On 07/21/2016 12:05 AM, Thomas Hardjono wrote: >> Generally I'm in support of any efforts to secure multicast messaging for >> IoT >> applications However, I have some concerns about the ACE

Re: [Ace] Constrained Environment PKI enrollment

Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt? Eliot On 6/2/16 9:38 AM, Julien Vermillard 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 li