Re: [Ace] 4. Security modes (Re: Open Issues)

[Ludwig Seitz <[e-mail]>]

On 01/17/2014 09:48 AM, Carsten Bormann wrote:
> On 16 Jan 2014, at 17:48, Stefanie Gerdes <[e-mail]> wrote:
>
>>>> 4. Security modes for CoAP
>>>> (http://www.ietf.org/mail-archive/web/ace/current/msg00104.html). Is it
>>>> in the scope of ACE to define security modes for CoAP?
>>>
>>> I'm obviously biased here, since it's the title of my draft. My main
>>> argument for including this is that the security modes are the first
>>> authorization step. What you do is to authorize the client to establish
>>> a DTLS connection in the first place.
>>>
>>
>> I think it is interesting to think about the various possible solutions
>> for authenticating the authorization information such as symmetric and
>> asymmetric key approaches or even object security. I am not sure,
>> however, if we need new security modes for CoAP for that. Don't we just
>> need to define how we use the existing ones?
>
> I think that’s mostly a matter of “semantics” (understanding of terms).
>
> Some people read the section 9 about security modes in the CoAP spec and
> derive a very literal understanding of what these security modes are.
 > Some others read them as building blocks.  The first group would think
 > they are defining new security modes when the second group thinks they
 > are applying the existing security modes in scenarios that are more
 > complex than those used to explain the modes in the spec.
>[...] draft-seitz-core-security-modes adds some ways to use them and
 > calls them additional CoAP modes.  This terminology may confuse some
 > who think we are extending TLS with fundamentally new cipher suites.
 > It may also be more useful to define the entire authorization protocol
 > instead of just the “CoAP mode” aspect of it.

Carsten, I am fine renaming the draft to something like "usage profile 
for CoAP security modes" if you think that can help to avoid confusion. 
The bigger question is: Is this work that people consider useful within 
ACE (I'm obviously biased here)?

I'm also all in favour of defining the entire authorization protocol, 
but the question is: do we want to cram everything into one draft?

The advantage I see with having draft-seitz-core-security-modes separate
is that it allows you to implement a very coarse grain access control 
(at the level of "who can initiate a DTLS connection with this 
device?"). I suspect this would be enough for a relevant number of 
applications, that don't need to implement more sophisticated access 
control.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone [phone]
http://www.sics.se