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

[Eliot Lear <[e-mail]>]

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 WG:
>>
>> (a) Mixing authorization with key management: authorization and key-management 
>> are separate functions, so they need separate specs.
> This is probably a document management aspect and from a protocol point
> of view there are indeed certain areas where authorization can separated
> from the key distribution.
>
> For example, separating the aspect where permissions are granted to
> access a specific resource are separately from key distribution.

+1.


>
>>
>> (b) Application-independent key management: a good key management protocol 
>> should be deployable for a reasonably broad set of applications area 
>> (including Consumer IoT and Industrial IoT).
>>
>> So while its useful to have a solution for lighting application, it remains to 
>> be seen if the solution works for other applications.
> We have been looking at other application domains outside lighting as
> well but so far what we have are several companies interested from the
> lighting community asking for a specification. If there are other use
> cases as well then I am sure the group is interested to hear about them.

Somebody has to be first.  Others should step forward.

>
>>
>> (c) ACE WG work-pace:  The ACE use-cases document took over a year to finish, 
>> with numerous argumentative & boring emails (I'm not going to name names). 
>> Sigh. If it takes over 1 year just to agree on use-cases, I can't imagine how 
>> long it will take to complete an IoT secure multicast key management protocol. 
>> Double sigh.
> Yes, that's indeed a fair concern. I am also worried about the speed.

Yes, but this is not a reason to not adopt a document.  It's a reason to
have editors and chairs who can move the ball.  What is a reason is the
above and below.
>
>>
>> (d) Reinventing stuff:  The IETF did have a secure multicast WG that produced 
>> a lot of drafts and some RFCs, notably RFC 3740 and RFC3547 (RFC6407). There's 
>> product out there implementing these already.
> Re-using work sounds useful.
>
>> There's also a draft in DICE on multicast for DTLS (not sure what happened to 
>> it).
> The DTLS multipath was discontinued. Instead, the current approach is to
> work on an application layer layer multicast security solution.
>
>> There is the Fluffy draft, but so far the ACE WG has not been very interested 
>> in it.
> The group decided to go for an OAuth-based approach in ACE but there are
> certainly multicast security aspects in the Fluffy draft that should be
> explored IMHO.
>
>>
>> (e) Re-chartering:  Will the ACE WG need rechartering and how long.
> The ACE group needs to be re-chartered to work on low latency group
> communication security. Whether this happens at all depends on the
> outcome of this discussion.
>
Fair.

Eliot