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

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

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?


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

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

> 
>
>> 
>> 
>> >
>> >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.
>
>Making C.2-C.5 be sub sections would probably also help

OK.


Göran


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