Thanks for the clarification. I am more concerned by having the profiles coherent with the framework than having the profiles providing the same capabilities. I am fine with the dtls profile making the introspection out of scope and leave it to the WG or co-author if they are willing to change it at that stage. Unless I am hearing a willingness to move into this direction I propose we move these documents as they are.
Yours, Daniel On Mon, Mar 8, 2021 at 2:58 AM Göran Selander <goran.selander= 40ericsson....@dmarc.ietf.org> wrote: > Hi Daniel, > > draft-ietf-ace-oscore-profile-16 does recommend a security protocol to be > used between RS and AS, see Section 5: > > "As specified in the ACE framework (section 5.9 of > [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) > and the AS communicates via the introspection or token endpoint. The > use of CoAP and OSCORE ([RFC8613]) for this communication is > RECOMMENDED in this profile; other protocols fulfilling the security > requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such > as HTTP and DTLS or TLS) MAY be used instead." > > For draft-ietf-ace-dtls-authorize-15: "The use of introspection is out of > scope for this specification." > > So it seems your concern is already resolved in these drafts. > > We might ask ourselves why introspection is included in one or not the > other. It is not heavily used in draft-ietf-ace-oscore-profile-16, only in > Section 4.2: > > "The RS may make an introspection request (see Section 5.9.1 > of [I-D.ietf-ace-oauth-authz]) to validate the token before > responding to the POST request to the authz-info endpoint." > > A similar sentence could have been included in > draft-ietf-ace-dtls-authorize as well (together with a recommendation to > use DTLS). > > Is this something we want to change at this stage? > > > Göran > > > > > On 2021-03-05, 22:11, "Ace on behalf of Daniel Migault" < > ace-boun...@ietf.org on behalf of 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 > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
