Subject: [Ace] Security properties of CoAP message fields

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 Sep 2015 20:11:39 -0700

I want to go through the fields of a CoAP message and figure out what the
security properties for each of the fields would need to be at a minimum.
It would, of course, always be acceptable to provide a higher degree of
security on any field, but knowing minimums helps.  I am not worried about
how to achieve the required security level.  This should just be a
discussion of what security levels are required.

I have provided first guesses at what security functions I think are needed,
but am probably wrong about several of them.

Part of the questions would be - if this changes in flight, should the
receiver treat the message as invalid?

Looking at a CoAP Message piece by piece I see the following:

To and From Addressing:  Ok this is not really part of the message, I just
want to ensure that nobody things that this should be protected in any way
as it will be modified in transit by any number of CoAP and non CoAP
entities.

CoAP version number:  Maybe integrity protected - I don't see any benefit in
hiding.

Message type:  This might be interesting to integrity protect, I don't know
there is any benefit in hiding.

Token Length:  Implicitly protected if the token itself is protected.

Token:  Should be integrity protected.  Protection should be extended to
noting that a token does not exist.

Code:  I think that this is going to depend on what the code is.  For C->RS
messages and probably for RS->C success responses it should be integrity
protected.  For RS->C failures, it would be good to be integrity protected.
For Proxy->C responses it might not be able to be protected.  For Mallory->C
responses it would never be protected.   Does C do different things if a
protected message is sent and an unprotected message is returned?  (Assumes
that C always initiates.)

Message ID:  Should be integrity protected. 

Options:  Protection extended to options is going to be option and possibly
dialog specific.
*  None:  There are/may be options which are expected to be modified in
transit.  There are options which may be/are expected to be inserted in
transit.  These options cannot have any security protection on them

*  Integrity Only:  The option can be visible to intervening entities, and
indeed might be required to be visible for them to function properly, but
there is a requirement that the option not be changed between the sender and
the recipient.

* Confidential (and integrity protected):  The option is not to be visible
to intervening entities.

Body:  Depends on content.  Will either be integrity protected or
confidential and integrity protected.

Jim