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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Francesca Palombini [mailto:[e-mail]]
> Sent: Thursday, September 08, 2016 2:21 AM
> To: Jim Schaad <[e-mail]>; draft-selander-ace-object-
> [e-mail]
> Cc: [e-mail]
> 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
> For the rest, I'd like to ask for explanations (inline).
> 
> Thanks again!
> Francesca
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: den 31 augusti 2016 02:51
> To: [e-mail]
> Cc: [e-mail]
> 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).

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

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

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.
> 
> [FP] Please elaborate on this. And you do mean CCM, right?

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

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