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

[Benjamin Kaduk <[e-mail]>]

Cigdem and Daniel,

Thanks for working to get this resolved.  It will be one less thing for me
to comment on :)

-Ben

On Tue, Apr 13, 2021 at 08:57:53AM -0400, Daniel Migault 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

> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace