Re: [core] Opsdir telechat review of draft-ietf-core-object-security-08

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

Hi Eric,

Thanks for your review. Comments inline.


On 2018-02-22 15:32, "Éric Vyncke" <[e-mail]> wrote:

>Reviewer: Éric Vyncke
>Review result: Has Issues
>
>Hello,
>
>I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate
>reviews
>a great part of the IETF documents being processed by the IESG for the
>OPS ADs.
>Please treat with these comments as with all other IETF LC comments.
>Please
>wait for direction from your document shepherd or AD before posting a new
>version of the draft.
>
>This document defines a method for application-layer protection of CoAP
>called
>OSCORE, re-using CORE (RFC8152) for protection and designed for
>constrained
>nodes. It is specifically designed to avoid clear-text access by TLS
>proxies.
>
>_Please note that I am not following the CORE WG so some candid comments
>may be
>uneducated._
>
>As a side note, I wonder why the AEAD algorithm is in the common security
>context as it prevents using different crypto algorithm for the two
>directions
>of the traffic.

This has been discussed but no compelling use case were presented so for
simplicity this was left out.

>
>Section 3.2 states that the master secret shall be pre-established but
>*does
>not give any hint on how to provision this master secret*.


I-D.ietf-ace-oauth-authz is referenced in Section 3.2, but - as you remark
below - we should also add the specific reference to
I-D.ietf-ace-oscore-profile. There are also other options. Some
constrained device deployments provision pre-shared keys which may be used
as master secret. There are also two candidate key exchange protocols
(draft-selander-ace-cose-ecdhe and draft-mattsson-ace-tls-oscore) but
progress has been stalled by a discussion in ACE which protocol is right.


>Section 4.2 defines the behavior when new CoAP fields/options will be
>specified. Which is good of course for the future operations.
>
>The draft specifies a mandatory AEAD algorithm to be implemented

The IETF mandates specification of MTI algorithms.


>=> I am afraid
>when this algorithm will become less secure, a revised version of this
>I-D will
>be published but let's hope that the devices will be able to be
>upgraded...
>(this issue is obviously out of scope for this document)

The use of I-D.ietf-ace-oscore-profile, for example, allows in addition to
master secret also the specification of AEAD algorithm and KDF algorithm
and other default parameters used to derive the security context. If the
device supports more than one AEAD algorithm, a switch can be made with
this protocol. As you remark, the real issue is that the device may not
support multiple algorithms.


>
>The OSCORE message contains a version which is good for future versions.
>
>Section 8 does not discuss the situations when the receiving endpoints
>does not
>support the proposed method...

It wasn’t clear to me what the "proposed method” referred to. Are you
thinking of receiving endpoints not supporting OSCORE? CoAP (RFC7252
section 5.4.1) specifies the behaviour of a receiving endpoint which does
not support the Object-Security option:

"Unrecognized options of class "critical" that occur in a Confirmable
request MUST cause the return of a 4.02 (Bad Option) response. This
response SHOULD include a diagnostic payload describing the unrecognized
option(s) (see Section 5.5.2).”


The application decides the conditions for which OSCORE is required, and
if it invokes OSCORE also needs to handle the case that OSCORE is not
supported by the server (which SHOULD become known to the client by the
mechanism described above).

Do we need to specify something in this respect?


>This section should mention how to provision/discover whether the
>receiving side (and possibly all the on-path proxies) support OSCORE.


As mentioned above, the provisioning of the receiving side is described
e.g. in I-D.ietf-ace-oscore-profile.

OSCORE is designed to work with proxies which understand or don’t
understand OSCORE, providing different functionality. But the protection
of messages between endpoints and proxies is not in scope. It can be added
by defining a class I option. Or, if endpoints and proxies can be consider
to part of a security group, the extension to group communications can be
applied (draft-ietf-core-oscore-groupcomm), where the key provisioning is
specified in another ACE draft (draft-tiloca-ace-oscoap-joining).

Please provide some more details as to what kind of provisioning/discovery
mechanisms you are still missing and for what purpose.


>Section 9 very briefly mention a 'osc' attribut in a
>web link.

Yes, that is one way to indicate support for OSCORE. Did you miss anything
in this section?

>
>The establishement of security context is very succinctly described in
>section
>11.2 which refers to section 3.2 which does not specify how to provision
>this
>master secret. It would be useful to refer to I-D.ietf-ace-oauth-authz and
>I-D.ietf-ace-oscore-profile in section 3.2

Agreed, as mentioned above.

>
>In short my concerns are:
>- no description of the master secret provisioning (or is a reference to
>draft-ietf-ace-oauth-authz enough?) - no YANG model for provisioning (or
>is
>there an I-D for this in writing?) - no description how crypto algorithms
>can
>be negociated

I hope I have answered these items above, except YANG model: The planned
deployments I know of are not using YANG, but if that is required or
people are interested we can specify that in a separate draft. Let us know.

>
>Hope this helps


Thanks,
Göran