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 >
Re: [Ace] minutes of the interim meetings
one clarification. Thanks Marco for raising the issue! Yours, Daniel On Tue, Apr 13, 2021 at 11:58 AM Daniel Migault wrote: > Hi, > > Thank you for attending the interim meeting. We had constructive > discussions. My takeaways from the meeting are: > * next version of draft-ietf-ace-cmpv2-coap-transport is expected to be > ready for WGLC > * draft-ietf-ace-wg-coap-eap needs more discussion. Please include the emu > mailing list to discuss interactions with EAP. > * draft-ietf-ace-pubsub-profile is making progress > * draft-ietf-ace-key-groupcomm-oscore is being updated. > * draft-ietf-ace-key-groupcomm is expecting additional reviews before we can end the WGLC. > > Minutes are available here. Thank you Cigdem for taking the notes. The > session has also been recorded. > > https://datatracker.ietf.org/meeting/interim-2021-ace-07/session/ace > > Yours, > Logan and Daniel > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] minutes of the interim meetings
Hi, Thank you for attending the interim meeting. We had constructive discussions. My takeaways from the meeting are: * next version of draft-ietf-ace-cmpv2-coap-transport is expected to be ready for WGLC * draft-ietf-ace-wg-coap-eap needs more discussion. Please include the emu mailing list to discuss interactions with EAP. * draft-ietf-ace-pubsub-profile is making progress * draft-ietf-ace-key-groupcomm-oscore is being updated and is expecting additional reviews before we can end the WGLC. Minutes are available here. Thank you Cigdem for taking the notes. The session has also been recorded. https://datatracker.ietf.org/meeting/interim-2021-ace-07/session/ace Yours, Logan and Daniel -- 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
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
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] ACE interim meeting on 2021-04-13 14:00 - 15:00 UTC
Hi, This is just a reminder to remind you the ACE interim is happening today in 1h:30. Yours, Logan and Daniel On Thu, Apr 1, 2021 at 10:06 PM Daniel Migault wrote: > Hi, > > Just to let everyone know the next interim meeting is on April 13. > > If you would like a slot to present, feel free to let us know. > > The current agenda is available here: > https://codimd.ietf.org/notes-ietf-interim-2021-ace-07-ace > > Please upload your presentations here: > https://datatracker.ietf.org/meeting/interim-2021-ace-07/session/ace > > Provisional Agenda > * agenda bashing > * draft-ietf-ace-cmpv2-coap-transport > * draft-ietf-ace-wg-coap-eap > * draft-ietf-ace-pubsub-profile > * draft-ietf-ace-key-groupcomm-oscore > > Yours, > Logan and Daniel > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
