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

[Carsten Bormann <[e-mail]>]

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.

There is, of course, a big difference between NoSec and the other modes.  What the other modes materially differ in is what TLS cipher suite was used to set up the DTLS connection and what the keying materials used for setting them up can be used for.  The two PK modes (RPK and cert) also have a key that can be used as an identity of the server (the text doesn’t discuss whether you have to use the same kind in both directions or you have to use a client key at all).  Since a device can have multiple such identities, CoAP suggests using SNI, so a device with multiple public keys also needs a hostname-like name (or anything that can be put in a RFC 6066 ServerName).  The CoAP modes do not say what the authorization implication of these keys/identities are or how they are used in an authorization protocol. 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.

Grüße, Carsten