Subject: [core] Comments on draft-selander-ace-objet-security-05

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Aug 2016 17:51:15 -0700

Random Thoughts:

Introduction:  Given the scope of the analysis, I do not believe that you
can restrict your solution to just dealing with the forwarding case.
Specifically I think you need to deal with the pub/sub cases with or w/o an
agent.

Introduction:  Is the determination of content being present based on the
length of the content or on the message type?  For example think of a POST
or a response with a zero length body.  I would tend to create a COSE body
in these cases rather than use the option for the body.

Section 2 - I am not sure that the SHOULD NOT on caching makes complete
sense.  It would make sense to cache the response if correlated to the
original request for reliability.   Caching also makes sense in the pub-sub
world

Section 2 - how does setting Max-Age interact with pub-sub and w/ caching
for reliable transmission?

Section 2 - the last sentence seems to be odd - are you really given an
example of option length or how different option lengths are encoded?

Section 3 - s/common keying material/common shared secret material/

Section 3 - s/of forward secret keying material/of secret material with the
property of forward secrecy/

Section 3.1 - You need to add a field for who is being talked to on the
client side of the context.  There is nothing to say that Cids are unique
for the client and therefore it needs to be able to determine which to use
when sending a message to the other side.  This may also be required for
servers when doing unicast in the event that it will spontaneously send
messages.

Section 3.1 - The idea of flip-flopping the context when the client and
server change roles seems to be a very bad idea.  If the client sends
message <Cid, X> and the server never receives it.  Then they flip contexts
and the old server sends <Cid, X> because it swapped server and recipient,
then you have a security leak problem.  Once the contexts are established
they should never be swapped.  I think this is what the last paragraph in
this section is suggesting.

Section 3.2 - there should be a big warning at the top of this section that
this procedure is only run once on a set of common secret material.  Running
it a second time is going to lead to bad things unless there is something
added.

Section 3.2 - I would prefer to add some additional items to the info
structure to make sure that things are going to agree on both sides.  These
would include the algorithm and the lengths of the item being derived.  Look
at the prefix derivation problems that can exist otherwise.

Section 3.2 - I have a problem with the text " The Context Identifier SHALL
be unique for all security contexts used by the party being server." As I am
not sure how to test this.  A statement that a server will check and reject
is testable.  I do not think that one can assume that a TTP will be able to
ensure this as there may be more than one of them and they may assign the
same type of uniqueness indicator (i.e. the addresses of both parties).
Please do not assume there is only one authorization server.

Section 3.2 - There is a fun thing that needs to be thought about.  A client
which sends a token along with the request may try and register the same Cid
more than once because the response to its request may get lost.  This needs
to be documented potentially as saying that the same Cid must result in the
same context being generated.

Section 4 - When doing encryption only, I would remove the I column from
figure 4.  I would just note that "E includes I" but "I" by itself would be
a different proposition.  That is 'I' would be ONLY integrity protected or
integrity protected in a signed or MAC only message.

Section 4 - The second paragraph below table 4 should not be dealing with
duplication  not integrity protection.  That is the items it needs to talk
about are 1) encryption or not and 2) duplicate or not and if it is
duplicated are they evaluated separately or must the contents be the same -
with the addition of new security services then it would also make sense to
talk about 3) integrity protect or not.

Section 5 - I would suggest making the mandatory algorithm declarations in a
single location so that it is easy to find rather than having it in multiple
locations.

Section 5 - Your maximum sequence number is going to be much smaller than
2^56-1.  You need to factor in the reduced sized tag and the limits for GCM
into this size.  I will need to do some research to figure out what the
correct limit is.  It is going to be closer to 2^32 w/o adjusting for the
abbreviated tag.

Section 6.1 - OSCOAP should not be a challenge response protocol so this
paragraph is troubling.  It needs to be able to support more than just this
one situation.

I am going to play with some other details so I will probably have more
comments following this.

Jim