Re: [core] Comments on draft-ietf-core-object-security-06

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Göran Selander [mailto:[e-mail]]
> Sent: Sunday, December 04, 2016 11:13 PM
> To: Jim Schaad <[e-mail]>; draft-ietf-core-object-
> [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-core-object-security-06
> 
> 
> 
> On 2016-12-03 03:38, "Jim Schaad" <[e-mail]> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Göran Selander [mailto:[e-mail]]
> >> Sent: Friday, December 02, 2016 12:31 AM
> >> To: Jim Schaad <[e-mail]>; draft-ietf-core-object-
> >> [e-mail]
> >> Cc: [e-mail]
> >> Subject: Re: Comments on draft-ietf-core-object-security-06
> >>
> >>
> >> >Appendix C - I am having a hard time with the first paragraph here.
> >> >I do not believe that you have correctly characterized the problem.
> >> >The reason that you cannot use OSCOAP for this has more to do with
> >> >how you decided which records in the header to authenticate rather
> >> >than the fact that this is going to be distributed to multiple recipients.
> >>
> >> The intended logic is the following:
> >>
> >> The security requirements draft
> >> https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs
> >>currently
> >> describes three use cases “proxy forwarding”, “proxy caching” and
> >>“publish-
> >> subscribe”. The solutions to these requirements protect as much as is
> >>possible,  while still allowing the functionality of the use case.
> >> OSCOAP addresses the "proxy forwarding” use case, which is a basic
> >>CoAP  request-response with optional forward proxy functionality. This
> >>is a use case  we have been requested to support, and it is an
> >>interesting case also because  essentially all options and headers
> >>that are passed end-to-end in a CoAP request  and response can be
> >>protected, response can be bound to a request, and some  other
> >>security features can be supported.
> >>
> >> OSCON addresses other use cases with a common solution, including the
> >>two  remaining use cases mentioned above. In these cases less of the
> >>records can be  protected, e.g. because a single response should be
> >>meaningful to multiple  requests. This solution thus targets a format
> >>where multiple use cases can be  supported rather than optimising
> >>security for a particular use case.
> >>
> >> I will make an issue to clarify this.
> >
> >It is not the least bit clear to me that publish-subscribe case cannot
> >be done with OSCOAP.  The proxy caching problem is more difficult, but
> >is not solved by OSCON in a way that is not also solved in the OSCOAP
> >case as far as I can tell.
> 
> In OSCOAP, the response is bound to the request by including the transaction
> identifier (cid, sender ID, sequence number) of the request in the external_aad
> of the response. With this the client is able to verify that the server has received
> the request and that this message is a response of that request. This
> construction also works for multiple responses to a given request such as CoAP
> observe (RFC7641) and group communication for CoAP (RFC7390). Different
> observe notifications can be distinguished by different sequence numbers of
> server, and different unicast responses to a multicast request can be
> distinguished by the responding node’s (sender) ID.
> 
> However, with caching and publish-subscribe a given response is used for
> multiple requests, so the response cannot be bound to a particular request.
> Moreover, for caching and publish-subscribe, less CoAP options and headers can
> be protected. E.g. the publisher can update a topic with a PUT, which is provided
> with a GET response to the subscriber, so the CoAP Code cannot be integrity
> protected between publisher and subscriber. More details about which options
> and header are protected in caching and pub-sub in the requirements draft:
> 
> https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs
> 
> Thus the set of headers and options, and how response is bound to request as
> defined in OSCOAP does not apply to pub-sub. But similar constructions are
> possible, or else just essentially protect the CoAP payload as with OSCON.
> 
> We did not write anything of the underlying construction in the draft, maybe we
> should?

I will send a separate message on some thoughts I had over the weekend at some point soon.

> 
> 
> >
> >>
> >
> >>
> >> >
> >> >Appendix C - I do not understand what this sentence means. " OSCON
> >> >shall not be used in cases which require a secure binding between
> >> >request and response."  Is it intended to say that the use of a
> >> >transaction identifier in the COSE wrappers for the request and
> >> >response is not permitted?  There are a lot of ways to do this that
> >> >do not rely on CoAP.
> >>
> >> As mentioned, this format is addressing use cases which does not bind
> >>response  to request. It is possible to define a wrapping of a message
> >>exchange in COSE  which has different features, but that was not the
> >>intention here.
> >
> >This is not making it any clearer to me.
> 
> Does the text above make things more clear?

As stated above - no.

Jim

> 
> 
> Göran
> 
>