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

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

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

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] 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 >

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

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] 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] 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

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] 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 > wrote: Oh, sorry, my mistake. I made a mistake between you and Mike Jones. Let's change our

[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