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

Thanks for the update, that works for me.

Yours,
Daniel

On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul <cigdem.sengul@gmail.com>
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=
> 40ericsson.com@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
>

-- 
Daniel Migault
Ericsson

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