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

From: Francesca Palombini <[email-masked]>
Date: Thu, 8 Sep 2016 09:21:20 +0000

Hi Jim,

Thank you for reading our draft again, we have created issues in the github repository from many of them, and we'll deal with them soon.
If you are interested you can follow and comment here: https://github.com/EricssonResearch/OSCOAP/issues 
For the rest, I'd like to ask for explanations (inline).

Thanks again!
Francesca

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: den 31 augusti 2016 02:51
To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-selander-ace-objet-security-05

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.

[FP] the pub/sub case should be dealt with by OSCON (Object Security of Content - Appendix C), in which only the payload of the message would be protected, not the entire request-response exchange. We really meant OSCOAP as a challenge-response protocol (mentioned first in the abstract "OSCOAP provides (...) a secure binding between CoAP request and response messages"). Other scenarios (such as multicast with unicast response) can be used with OSCOAP, with some adjustments (this is a work to come soon).

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.

[FP] Yes, in the case of a zero-length body, the COSE object should go in the CoAP payload of the protected message. Thank you for pointing that out, we'll clarify this.

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

[FP] I am not sure I understand this comment. What do you mean by "for reliability"? If you talk about message re-transmission, that's on CoAP message layer or a lower layer than CoAP neither of which are in scope of OSCOAP.

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

[FP] again, what do you mean by 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?

[FP] You are right, we don't give an example, it would more exact to say that we detail the message overhead caused by the Object Security option.

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

[FP] OK

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

[FP] OK

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.

[FP] We are adding a field Sender ID and a field Recipient ID that should solve this problem. These fields shall be unique, either globally (stochastically) unique, or locally unique in case of globally (stochastically) unique Cid:s, and set up in a previous phase (for example while doing EDHOC). 

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.

[FP] I think this paragraph may not have been clear. We meant that the context stayed the same even though the client became the server and the server became the client. Each endpoint uses the same keying material and procedure for setting IV and protecting from replay as it did before, when sending and receiving. So we agree with you, flip-flopping the context is a bad idea and we were trying to say that it must not be done, and also that there is no need to re-negotiate new material. We'll try to clarify.

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.

[FP] You are right.

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.

[FP] OK, we'll add algorithm and length to the info structure.

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.

[FP] We understand, but we think this is something that an application using OSCOAP should decide how to achieve.

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.

[FP] I don't understand what you mean by "register the Cid", and what token are you talking about here. Could you expand?

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.

[FP] Yes, we'll remove the I column.

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.

[FP] Assuming you meant to write "should be dealing with duplication not integrity protection", I agree. We'll change that.

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.

[FP] OK

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.

[FP] Please elaborate on this. And you do mean CCM, right?

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.

[FP] Is this the same comment as before regarding e.g. pub-sub?

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

Jim

---

From: Jim Schaad <[email-masked]>
Date: Thu, 8 Sep 2016 14:19:31 -0700

> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Thursday, September 08, 2016 2:21 AM
> To: Jim Schaad <[email-masked]>; draft-selander-ace-object-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-selander-ace-objet-security-05
> 
> Hi Jim,
> 
> Thank you for reading our draft again, we have created issues in the
github
> repository from many of them, and we'll deal with them soon.
> If you are interested you can follow and comment here:
> https://github.com/EricssonResearch/OSCOAP/issues
> 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.
> 
> [FP] the pub/sub case should be dealt with by OSCON (Object Security of
> Content - Appendix C), in which only the payload of the message would be
> protected, not the entire request-response exchange. We really meant
OSCOAP
> as a challenge-response protocol (mentioned first in the abstract "OSCOAP
> provides (...) a secure binding between CoAP request and response
messages").
> Other scenarios (such as multicast with unicast response) can be used with
> OSCOAP, with some adjustments (this is a work to come soon).

This may be an issue with how the document is arranged then.  I don't know
that it makes sense to have OSCON be in an appendix if it is expected to be
used in such a major situation as pub/sub.  Being in an appendix makes it be
low priority in my mind as being not too useful.

> 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
> [FP] I am not sure I understand this comment. What do you mean by "for
> reliability"? If you talk about message re-transmission, that's on CoAP
message
> layer or a lower layer than CoAP neither of which are in scope of OSCOAP.

Caching is part of what allows for re-transmission and reliable sending in
my mind.  I realize that this may not be a general feeling, however if a
response is cached then the re-transmission can be short circuited at the
cache rather than needing to go all the way back to the responder and thus
having the same problems with getting the response all the way back because
of collisions and time outs.

When I say reliable transmission I am talking about it in the same sense as
does RFC 7252 which is the CoAP specification.

> 
> Section 2 - how does setting Max-Age interact with pub-sub and w/ caching
for
> reliable transmission?
> 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.
> 
> [FP] We are adding a field Sender ID and a field Recipient ID that should
solve
> this problem. These fields shall be unique, either globally
(stochastically) unique,
> or locally unique in case of globally (stochastically) unique Cid:s, and
set up in a
> previous phase (for example while doing EDHOC).

You may still want to have an identity in the table ala a DNS name so that
you can look up by that as well.  You will need this type of information to
do the initial lookup to say "I want to send to foo, what key material do I
use?"

I am sorry, I don't believe in your globally/locally unique Cid values.
Feel free to ignore me on this.

> 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).
> [FP] We understand, but we think this is something that an application
using
> OSCOAP should decide how to achieve.

Then it is not clear that SHALL is the correct word.

> 
> 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.
> 
> [FP] I don't understand what you mean by "register the Cid", and what
token are
> you talking about here. Could you expand?

By register the Cid, I mean put it into the key table that I am maintaining.

Client                        		Server
Send request		--> 	receive and process
                ||blocked    	<--  	send response
	|| or lost
Resend same request   --->          receive and process -- 
		what do I do about the duplicate Cid???  
                             Error or return the same response

> 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.
> 
> [FP] Assuming you meant to write "should be dealing with duplication not
> integrity protection", I agree. We'll change that.

Yes, that is what I meant.

> 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.
> 

No, I actually meant GCM not CCM in this case because I have an idea of what
the limit is due to the long discussions on the TLS mailing list.  I really
have no idea at this time what the limit would be for CCM.  I need to
re-read the documents and make some guesses.

Jim