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
