Subject: Re: [core] draft-ietf-core-coap-06 Security

From: "Alper Yegin" <[email-masked]>
Date: Fri, 10 Jun 2011 11:27:46 +0300

Sorry for the delay getting back to this thread..

> >>> I'm not singling out TLS here. I think this is a fundamental
> >>> distinction between channel security vs object-level security.
> >> It seems fundamentally easier to encrypt on a channel basis as the
> same
> >> end-point credentials are used to derive keying information which
> can
> >> encrypt and integrity protect simultaneously,
> > Using object-level security does not change that.
> Perhaps I misunderstood what you meant by object-level security. The
> way
> you described it seemed to suggest that elements of data transacted
> within the channel could be individually encrypted. My questions
> surround what security material is used to perform the encryption in
> each case.

Individual data elements, or the whole application-layer data (which
includes those individual data elements) can be encrypted using a key shared
between the two end-points. Where that key comes from is a separate problem
with its own solutions. What I'm seeking is the ability of CoAP to support
this possibility.

> >> e.g. most efficiently
> >> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make
> the
> >> encryption more granular, what do you then use as the cryptographic
> >> basis for secrecy between the transacting objects? Asymmetric or
> >> symmetric?
> > Symmetric.
> >
> >> Would you use the same granularity as the channel end
> >> points?
> >> Or be more granular?
> > Not sure I understand. Can you elaborate?
> As above - what security material would you use to encrypt? The same
> security material as is used for channel encryption? Or something more
> granular, i.e. would each distinct element of encrypted data have its
> own security material? 

Not necessarily. A single shared-secret key between the two end-points is
sufficient.

> What is the distinction? If communicating
> objects
> multiplex their transactions on a single channel, this could be the
> case.
> >> All I'm saying is there is probably more to this than meets the eye.
> > Let's find out.

Alper

> > Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 10 Jun 2011 11:38:40 +0300

> This object security discussion is totally orthogonal to the DTLS
> security that is default in CoAP (so this really isn't relevant to
> core-coap-06). 
> Object security is definitely interesting in this
> domain, and for example the JSON signing BOF in Prague was relevant to
> this. I would encourage Alper to write a draft about how to do simple
> object security for CoAP. 

What's I'm thinking is defining an option that can carry the one-way keyed
hash of CoAP header + payloads. And another option that can encrypt and
encapsulate other options that require privacy.

Alper

> Robert is right that the security model in
> the CoRE context should be an important part of that, as well as
> bootstrapping considerations.

> 
> Zach
> 
> On May 13, 2011, at 12:04 PM, Robert Cragie wrote:
> 
> >
> >
> > On 13/05/2011 2:39 AM, Alper Yegin wrote:
> way you described it seemed to suggest that elements of data transacted
> own security material? What is the distinction? If communicating
> objects multiplex their transactions on a single channel, this could be
> the case.
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> 
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 10 Jun 2011 11:45:52 +0300

Robert,

> I wouldn't say totally orthogonal - this spun off from a discussion as
> to whether DTLS was indeed the right choice for security and whether we
> could define a CoAP security (for example, like RPL did). However, my
> view is that DTLS is the right choice.

For all kinds of deployments? I don't think so. Apparently the current spec
does not think so either. There is already IPsec in it.

I don't think we need to find a "right" choice in IETF anyways. As far as
IETF is concerned, at least one choice has to be there (because we cannot
ship such a protocol without a security mechanism) -- and that's DTLS. Since
the final choice is for the system developers, architecture designers, and
the deployments, they'll deal with it.  They already have nosec and IPsec.

Alper

> 
> Robert
> 
> On 13/05/2011 3:10 PM, Zach Shelby wrote:
> core-coap-06). Object security is definitely interesting in this
> object security for CoAP. Robert is right that the security model in