Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
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" 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
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
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 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/
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
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 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
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
Thanks for the update, that works for me. Yours, Daniel On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul 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 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
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
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 > 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 > 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
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
Hello Daniel, One thing I didn't have a chance to ask yesterday in the interim was about the registration of the 'ace+json' application type. Francesca brought this up as the MQTT profile describes the HTTPS interactions differently than the core draft which says " When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body, as defined in section 3.2 of [RFC6749]." As I discussed with Francesca, we had discussions on the mailing list with Jim using ace+json as well. I recalled the view that the draft that introduces it should register it - I want to check if this is the general agreement, or you (or the group) has a different view - (1) registering this new type, or (2) MQTT draft is modified to comply with framework description - do we still agree that (1) it should be the MQTT profile registering it or (2) it should be done elsewhere? Kind regards, --Cigdem On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault wrote: > Thanks for the update, that works for me. > > Yours, > Daniel > > On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul > 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 > 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 >>> >>>
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
Hi, I am certainly missing something, but it is unclear to me why "application/ace+json" does not comply to "application/x-www-form-urlencoded". In other words, what would the update of the mqtt draft consist of to be aligned with the framework. I also have the impression that the use of "application/x-www-form-urlencoded" is a MAY and that the framework does not specify MUST. In general I am tempted to think it is better to be aligned with but It would probably need to understand better the issue and I am encouraging the WG to state rapidly their thoughts so we can move the draft forward. Regarding the second point, yes, the draft that introduces ace+json should register it. Yours, Daniel From: Ace on behalf of Cigdem Sengul Sent: Wednesday, April 14, 2021 4:58 AM To: Daniel Migault ; Ace Wg Subject: Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication Hello Daniel, One thing I didn't have a chance to ask yesterday in the interim was about the registration of the 'ace+json' application type. Francesca brought this up as the MQTT profile describes the HTTPS interactions differently than the core draft which says " When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body, as defined in section 3.2 of [RFC6749]." As I discussed with Francesca, we had discussions on the mailing list with Jim using ace+json as well. I recalled the view that the draft that introduces it should register it - I want to check if this is the general agreement, or you (or the group) has a different view - (1) registering this new type, or (2) MQTT draft is modified to comply with framework description - do we still agree that (1) it should be the MQTT profile registering it or (2) it should be done elsewhere? Kind regards, --Cigdem On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault mailto:mglt.i...@gmail.com>> wrote: Thanks for the update, that works for me. Yours, Daniel On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul mailto: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 mailto: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 e
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
Hello Daniel, I should clarify: I did not mean it was not compliant - it was more asking whether anybody objects to registering ace+json when the framework talks about a different method. Kind regards, --Cigdem On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault wrote: > Hi, > > I am certainly missing something, but it is unclear to me why > "application/ace+json" does not comply to "application/x-www-form-urlencoded". > In other words, what would the update of the mqtt draft consist of to be > aligned with the framework. I also have the impression that the use of > "application/x-www-form-urlencoded" is a MAY and that the framework does > not specify MUST. In general I am tempted to think it is better to be > aligned with but It would probably need to understand better the issue and > I am encouraging the WG to state rapidly their thoughts so we can move the > draft forward. > > Regarding the second point, yes, the draft that introduces ace+json should > register it. > > Yours, > Daniel > -- > *From:* Ace on behalf of Cigdem Sengul < > cigdem.sen...@gmail.com> > *Sent:* Wednesday, April 14, 2021 4:58 AM > *To:* Daniel Migault ; Ace Wg > *Subject:* Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - > AS communication > > Hello Daniel, > > One thing I didn't have a chance to ask yesterday in the interim was about > the registration of the 'ace+json' application type. > Francesca brought this up as the MQTT profile describes the HTTPS > interactions differently than the core draft which says " When HTTP is > used as a transport then the client makes a request to the token endpoint > by sending the parameters using the "application/ > x-www-form-urlencoded" format with a character encoding of UTF-8 in the > HTTP request entity-body, as defined in section 3.2 of [RFC6749]." > > As I discussed with Francesca, we had discussions on the mailing list with > Jim using ace+json as well. I recalled the view that the draft that > introduces it should register it - I want to check if this is the general > agreement, or you (or the group) has a different view > - (1) registering this new type, or (2) MQTT draft is modified to > comply with framework description > - do we still agree that (1) it should be the MQTT profile > registering it or (2) it should be done elsewhere? > > Kind regards, > --Cigdem > > On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault > wrote: > > Thanks for the update, that works for me. > > Yours, > Daniel > > On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul > 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 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 >
Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
Hi, I do not see this as an issue but would like the WG to state their opinion. Yours, Daniel From: Cigdem Sengul Sent: Wednesday, April 14, 2021 9:01 AM To: Daniel Migault Cc: Daniel Migault ; Ace Wg Subject: Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication Hello Daniel, I should clarify: I did not mean it was not compliant - it was more asking whether anybody objects to registering ace+json when the framework talks about a different method. Kind regards, --Cigdem On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault mailto:daniel.miga...@ericsson.com>> wrote: Hi, I am certainly missing something, but it is unclear to me why "application/ace+json" does not comply to "application/x-www-form-urlencoded". In other words, what would the update of the mqtt draft consist of to be aligned with the framework. I also have the impression that the use of "application/x-www-form-urlencoded" is a MAY and that the framework does not specify MUST. In general I am tempted to think it is better to be aligned with but It would probably need to understand better the issue and I am encouraging the WG to state rapidly their thoughts so we can move the draft forward. Regarding the second point, yes, the draft that introduces ace+json should register it. Yours, Daniel From: Ace mailto:ace-boun...@ietf.org>> on behalf of Cigdem Sengul mailto:cigdem.sen...@gmail.com>> Sent: Wednesday, April 14, 2021 4:58 AM To: Daniel Migault mailto:mglt.i...@gmail.com>>; Ace Wg mailto:ace@ietf.org>> Subject: Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication Hello Daniel, One thing I didn't have a chance to ask yesterday in the interim was about the registration of the 'ace+json' application type. Francesca brought this up as the MQTT profile describes the HTTPS interactions differently than the core draft which says " When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body, as defined in section 3.2 of [RFC6749]." As I discussed with Francesca, we had discussions on the mailing list with Jim using ace+json as well. I recalled the view that the draft that introduces it should register it - I want to check if this is the general agreement, or you (or the group) has a different view - (1) registering this new type, or (2) MQTT draft is modified to comply with framework description - do we still agree that (1) it should be the MQTT profile registering it or (2) it should be done elsewhere? Kind regards, --Cigdem On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault mailto:mglt.i...@gmail.com>> wrote: Thanks for the update, that works for me. Yours, Daniel On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul mailto: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 mailto: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 wonder
