Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

[Cigdem Sengul <[e-mail]>]

Hello Daniel,
I should clarify: I did not mean it was not compliant - it was more asking
whether anybody objects to registering ace+json when the framework talks
about a different method.
Kind regards,
--Cigdem

On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault <[e-mail]>
wrote:

> Hi,
>
> I am certainly missing something, but it is unclear to me why
> "application/ace+json" does not comply to "application/x-www-form-urlencoded".
> In other words, what would the update of the mqtt draft consist of to be
> aligned with the framework. I also have the impression that the use of
> "application/x-www-form-urlencoded" is a MAY and that the framework does
> not specify MUST. In general I am tempted to think it is better to be
> aligned with but It would probably need to understand better the issue and
> I am encouraging the WG to state rapidly their thoughts so we can move the
> draft forward.
>
> Regarding the second point, yes, the draft that introduces ace+json should
> register it.
>
> Yours,
> Daniel
> ------------------------------
> *From:* Ace <[e-mail]> on behalf of Cigdem Sengul <
> [e-mail]>
> *Sent:* Wednesday, April 14, 2021 4:58 AM
> *To:* Daniel Migault <[e-mail]>; Ace Wg <[e-mail]>
> *Subject:* Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS -
> AS communication
>
> Hello Daniel,
>
> One thing I didn't have a chance to ask yesterday in the interim was about
> the registration of the 'ace+json' application type.
> Francesca brought this up as the MQTT profile describes the HTTPS
> interactions differently than the core draft  which says " When HTTP is
> used as a transport then the client makes a request to the token endpoint
> by sending the parameters using the "application/
> x-www-form-urlencoded" format with a character encoding of UTF-8 in the
> HTTP request entity-body, as defined in section 3.2 of [RFC6749]."
>
> As I discussed with Francesca, we had discussions on the mailing list with
> Jim using ace+json as well. I recalled the view that the draft that
> introduces it should register it - I want to check if this is the general
> agreement, or you (or the group) has a different view
>     - (1) registering this new type, or (2) MQTT draft is modified to
> comply with framework description
>     - do we still agree that (1) it should be the  MQTT profile
> registering it or (2) it should be done elsewhere?
>
> Kind regards,
> --Cigdem
>
> On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault <[e-mail]>
> wrote:
>
> Thanks for the update, that works for me.
>
> Yours,
> Daniel
>
> On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul <[e-mail]>
> wrote:
>
> 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=
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
> --
> Daniel Migault
> Ericsson
>
>