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

From: Göran Selander <[email-masked]>
Date: Fri, 2 Dec 2016 08:31:14 +0000

Hi Jim,

Thanks for your comments. The subject of this thread should of course be
"Comments on draft-ietf-core-object-security-00”.

Appendix C, OSCON, is addressing other use cases than OSCOAP, more of this
below. It has not been progressed lately since we wanted to focus on the
OSCOAP use cases which seem most relevant at this stage. Also we were
waiting for Klaus to present his solution, which may overlap with OSCON. I
will make Github issues out of the comments inline, but we may incorporate
those in the draft at a later stage since we have a tight time schedule
for OSCOAP.

On 2016-11-30 07:08, "Jim Schaad" <[email-masked]> wrote:

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

>
>Appendix C - Talking about the "unprotected" and the "protected" CoAP
>message is very confusing especially since COSE has protected and
>unprotected objects as well.  It would be better to use a different
>terminology such as "the original message" and "the resulting message".

This terminology is defined in the body of the draft. (FWIW the
terminology probably predates COSE.) If we always qualify with
unprotected/unprotected CoAP, protected/unprotected COSE header, I suppose
there would less of a risk for misunderstanding?

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

>
>Appendix C - It is not clear if the Content-Format should be set if there
>was no Content-Format in the original message.

It should, to be clarified.

>
>Appendix C.1 - I do not understand what this section is trying to
>accomplish.  It appears to be doing three different things, some of which
>should be in Appendix C, some of which should be standalone and some of
>which looks like it should be

It is an introduction to sections C.2-C.5. We should clarify that.

>
>Appendix C.5 - There should be a discussion related this this about the
>different security properties that are to be found for Encrypt+Sign(M) vs
>Sign(Encrypt(M)).

There are plans to write more about the security properties of SEAS,
probably in a different document.

>
>Appendix B - These are really example message flows rather than examples
>of
>OSCOP messages.  This should be made clearer in the section title

OK, I’ll make that update in -01.

>
>Appendix B.1 - How does one securely bind the request and the response?  I
>am not seeing anything from this example that will do so.

No, it is not visible from the message format. See section 6.1 "the
response is verified to match a prior request, by including the unique
transaction identifier of the request in the Additional Authenticated Data
of the response message."

Göran

---

From: Jim Schaad <[email-masked]>
Date: Fri, 2 Dec 2016 18:38:31 -0800

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Friday, December 02, 2016 12:31 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-core-object-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-core-object-security-06
> 
> Hi Jim,
> 

I think the -06 is left over from looking at the EDHOC document.  You are completely correct it should have been -00

> OSCOAP use cases which seem most relevant at this stage. Also we were waiting
> for Klaus to present his solution, which may overlap with OSCON. I will make
> Github issues out of the comments inline, but we may incorporate those in the
> draft at a later stage since we have a tight time schedule for OSCOAP.
> 
> >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.
> 
> 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.
> 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.
> 
> 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.
> 

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.

> This terminology is defined in the body of the draft. (FWIW the terminology
> probably predates COSE.) If we always qualify with unprotected/unprotected
> CoAP, protected/unprotected COSE header, I suppose there would less of a risk
> for misunderstanding?

Doing the full qualification would be nice.  I will admit that I probably missed that since I started half way down the document.

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

> 
> 
> >
> >Appendix C - It is not clear if the Content-Format should be set if
> >there was no Content-Format in the original message.
> 
> >accomplish.  It appears to be doing three different things, some of
> >which should be in Appendix C, some of which should be standalone and
> >some of which looks like it should be
> 

Making C.2-C.5 be sub sections would probably also help

Jim

> >different security properties that are to be found for Encrypt+Sign(M)
> >vs Sign(Encrypt(M)).
> 
> There are plans to write more about the security properties of SEAS, probably in
> a different document.
> 
> >
> >Appendix B - These are really example message flows rather than
> >examples of OSCOP messages.  This should be made clearer in the section
> >title
> 
> >Appendix B.1 - How does one securely bind the request and the response?
> >I am not seeing anything from this example that will do so.
> 
> No, it is not visible from the message format. See section 6.1 "the response is
> verified to match a prior request, by including the unique transaction identifier
> of the request in the Additional Authenticated Data of the response message."
> 
> Göran
>

---

From: Göran Selander <[email-masked]>
Date: Mon, 5 Dec 2016 07:13:06 +0000

On 2016-12-03 03:38, "Jim Schaad" <[email-masked]> wrote:

>>“publish-
>>can be
>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?

>>terminology
>Doing the full qualification would be nice.  I will admit that I probably
>missed that since I started half way down the document.

OK, we’ll make sure of that.

>>response

Does the text above make things more clear?

>Making C.2-C.5 be sub sections would probably also help

OK.

Göran

>>response is

---

From: Jim Schaad <[email-masked]>
Date: Sun, 4 Dec 2016 23:47:29 -0800

> Sent: Sunday, December 04, 2016 11:13 PM
> >> >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.
> >>
> >>currently
> >> 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.
> >>
> >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.
> 
> 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:
> 
> 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.

> >> >response is not permitted?  There are a lot of ways to do this that
> >> >do not rely on CoAP.
> >>

As stated above - no.

Jim