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 <cigdem.sen...@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....@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 > _______________________________________________ > 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
