Hello Daniel,
I propose the following change to clarify the TLS use - if you are happy
with it, I will update the document:
To provide communication confidentiality and RS authentication to MQTT
clients, TLS
is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes
the same assumptions as Section 4 of the ACE framework
[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
the AS and setting up keying material. While the Client-Broker
exchanges are only over MQTT, the required Client-AS and RS-AS
interactions are described for HTTPS-based communication [RFC7230],
using 'application/ace+json' content type, and unless otherwise
specified, using JSON encoding. The Client-AS and RS-AS MAY also use
protocols other than HTTP, e.g. Constrained Application Protocol
(CoAP) [RFC7252] or MQTT; it is recommended
that TLS is used to secure the communication channels between Client-AS
and RS-AS."
Since it is in this paragraph, one thing that Francesca brought up to do is
to register the 'application/ace+json' content type.
Kind regards,
--Cigdem
On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault <daniel.migault=
40ericsson....@dmarc.ietf.org> wrote:
> Hi,
>
>
>
> Now that the authz document is being consolidated, I do have some minor
> concerns regarding the recommendations mentioned in the profile documents,
> that might require an additional update.
>
> The update to the authz document indicates more more clearly than before
> that profiles need to provide some recommendations for the RS – AS
> communication.
>
>
>
> “””
>
> Profiles MUST specify for introspection a communication security protocol
> RECOMMENDED to be used between RS and AS that provides the features
> required above. “””
>
>
>
> It seems to me the MQTT profile text makes it pretty clear that TLS is
> recommended for all communications but I am wondering if additional
> clarification would be beneficial – see below. That said I agree this is a
> very minor point in this case that could be handled by the RFC editor.
>
> For the OSCORE or DTLS profiles, unless I am missing the RS – AS
> recommendations in the documents , it seems to me it has been omitted and
> needs to be added -- see below.
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
> ## MQTT - draft-ietf-ace-mqtt-tls-profile-10
>
>
>
> “””
>
> To provide communication confidentiality and RS authentication, TLS
>
> is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes
>
> the same assumptions as Section 4 of the ACE framework
>
> [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>
> the AS and setting up keying material. While the Client-Broker
>
> exchanges are only over MQTT, the required Client-AS and RS-AS
>
> interactions are described for HTTPS-based communication [RFC7230],
>
> using 'application/ace+json' content type, and unless otherwise
>
> specified, using JSON encoding.
>
> “””
>
>
>
> I am wondering if that would not be more appropriated to specify in the
> first line RS and AS authentication or simply authentication.
>
>
>
>
>
>
>
>
>
> - OSCORE draft-ietf-ace-oscore-profile-16
>
> “””
>
> This
>
> profile RECOMMENDS the use of OSCORE between client and AS, to reduce
>
> the number of libraries the client has to support, but other
>
> protocols fulfilling the security requirements defined in section 5
>
> of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as
>
> well.
>
> “””
>
>
>
>
> - DTLS draft-ietf-ace-dtls-authorize-15
>
>
>
> “””
>
> It is RECOMMENDED that the client
>
> uses DTLS with the same keying material to secure the communication
>
> with the authorization server, proving possession of the key as part
>
> of the token request. Other mechanisms for proving possession of the
>
> key may be defined in the future.
>
> “””
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
