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

Göran Selander

2018-02-23 10:58:18 UTC

Hi Eric,

Thanks for your review. Comments inline.

Post by Ãric Vyncke
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.

Post by Ãric Vyncke
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.

Post by Ãric Vyncke
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.

Post by Ãric Vyncke
=> 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.

Post by Ãric Vyncke
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?

Post by Ãric Vyncke
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.

Post by Ãric Vyncke
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?

Post by Ãric Vyncke
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.

Post by Ãric Vyncke
- 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.

Post by Ãric Vyncke
Hope this helps

Thanks,
Göran