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

[Cigdem Sengul <[e-mail]>]

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
>