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

[Göran Selander <[e-mail]>]

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" <[e-mail]> 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