[Ace] draft-ietf-ace-key-groupcomm-oscore-18 ietf last call Opsdir review

[Thomas Graf via Datatracker <[e-mail]>]

Document: draft-ietf-ace-key-groupcomm-oscore
Title: Key Management for Group Object Security for Constrained RESTful
Environments (Group OSCORE) Using Authentication and Authorization for
Constrained Environments (ACE) Reviewer: Thomas Graf Review result: Not Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational and manageability
aspects of the IETF drafts.

This documents defines an application profile of the Authentication and
Authorization for Constrained Environments (ACE) framework which depends on the
following specifications:

- RFC 7252 for Constrained Application Protocol specification
- RFC 8613 for Object Security for Constrained RESTful Environments
- RFC 9052 and 9053 for CBOR Object Signing and Encryption
- RFC 9200 for Authentication and Authorization
- RFC 9254 for Key Provisioning for Group Communication
- draft-ietf-core-oscore-groupcomm for Group Object Security

I have been studying these documents, its relationships in order to understand
how operational and manageability aspects are addressed to understand how
draft-ietf-ace-key-groupcomm-oscore as application profile for authentication
and authorization fit in and failed to do so because none of the above
mentioned documents describe the operational and manageability aspect as
described in
https://datatracker.ietf.org/doc/html/draft-opsarea-rfc5706bis#section-3.

To my current understanding, none of these documents describe or refer to
configuration models or how the defined protocols and mechanisms can be
monitored.

Here my feedback to the document:

In section 1.1 terminology, the term "Monitor" is being defined and referred to
"silent server" in draft-ietf-core-oscore-groupcomm. Why is a different term
being used? Both document fails to describe the role and intend of that
function. For instance in "Signature verifier" it states "intended to verify
the signature of messages exchanged".

In section 2 it describes "A network node can join an OSCORE group by
interacting with the responsible Group Manager. Once registered in the group".
My understanding is based from reading RFC 9594 that the intent is to support
multiple application profiles where draft-ietf-ace-key-groupcomm-oscore
describes one.

The documents misses to describe under normal operation:

- How can network operation verify which network nodes joined an OSCORE group
successfully and which application profile has been used? - How can network
operation determine that there were unsuccessful attempts in the past and from
which network nodes at which time. - How does "Monitor" resp. "silent server"
contribute to a troubleshooting process?

Throughout the document error codes such as

https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-18#section-6.2

- The Group Manager MUST reply with a 5.03 (Service Unavailable) error response
in the following cases - The Group Manager MUST reply with a 4.00 (Bad Request)
error response in the following cases: - the Group Manager MAY reply with a
4.00 (Bad Request) error response in case all the following conditions hold:

are used but no references are given where those error codes are being defined.

To my understanding they relate to
https://www.rfc-editor.org/rfc/rfc7252#section-5.9 and a description in section
2, "Protocol Overview", describing that Response Code Definitions from
https://www.rfc-editor.org/rfc/rfc7252#section-5.9 are used, is required to
understand error code meaning and relationship to the CoAP protocol.

What is unclear to me is how besides a CoAP client an operator would have
visibility in the individual errors, are they logged?, or how an operator could
obtain a statistical view on the errors occurring.

For an statistical example, the CoAP Management Interface,
https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-20#section-6
describes the error handling and how they are represented statistically in a
data model. To my current understanding, this is missing in context of the
Authentication and Authorization for Constrained Environments (ACE) framework.

Best wishes
Thomas Graf