[Ace] Adam Roach's No Objection on draft-ietf-ace-coap-est-18: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-ace-coap-est-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- COMMENT: -- Thanks for addressing my discuss and comments! ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt
Sorry, forgot the git link https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93=is%3Aissue +%22s+IESG%22 -Original Message- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Monday, January 06, 2020 1:12 PM To: ace@ietf.org; i-d-annou...@ietf.org Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Hello, This iteration addresses all IESG reviews. More details on the feedback and how we addressed it are in the git issues here Rgs, Panos -Original Message- From: Ace On Behalf Of internet-dra...@ietf.org Sent: Monday, January 06, 2020 1:00 PM To: i-d-annou...@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-18.txt Pages : 51 Date: 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace smime.p7s Description: S/MIME cryptographic signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt
Hello, This iteration addresses all IESG reviews. More details on the feedback and how we addressed it are in the git issues here Rgs, Panos -Original Message- From: Ace On Behalf Of internet-dra...@ietf.org Sent: Monday, January 06, 2020 1:00 PM To: i-d-annou...@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-18.txt Pages : 51 Date: 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace smime.p7s Description: S/MIME cryptographic signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
-Original Message- From: Ace On Behalf Of Olaf Bergmann Sent: Monday, January 6, 2020 2:03 AM To: Jim Schaad Cc: ace@ietf.org; 'Benjamin Kaduk' ; draft-ietf-ace-dtls-authorize@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 Jim, Jim Schaad writes: [Ben's review] > We also are potentially in violation of the framework's requirements with > respect to the independent selection of profiles for client/AS and client/RS > interactions -- at present, when DTLS+RPK is used for client/RS, we require > that DTLS+RPK is also used for client/AS, in order to prove possession of the > key. We could perhaps weasel our way out by saying that the framework's > requirement applies at the profile granularity, and with symmetric PSK we can > be fully independent, but we still need to say something about this property > and the interaction with the framework's requirements. > > [JLS] I am missing where it is saying this. Can you give a pointer? I > don't believe that the POP of the RPK is required at the time that the token > is obtained. The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. [JLS] What if I do the following sequence of events: 1. The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS. 2. The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1). 3. The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows that it is tied to the client due to what happened in step 2. The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it. The AS does a current POP for RPK1 when the token is being asked for. The AS did a POP for RPK3 when it was placed into the system. The AS has not done a POP for RPK4 - that was simply configured without that step ever being done. The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current. The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS. Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air. RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to. Jim Jim Grüße Olaf ___ 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
[Ace] I-D Action: draft-ietf-ace-coap-est-18.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-18.txt Pages : 51 Date: 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
Hi Panos, On Mon, Jan 6, 2020, at 5:32 PM, Panos Kampanakis (pkampana) wrote: > Hi Alexey, > > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > No we don't forbid them in the draft. We do not make them MTI either though. > The long URIs can be supported and they would be a non-default EST-coaps > resource that a server could support and a client could do resource > discovery for. So we did not add text to say "MUST NOT implement the long > URIs". The mandatory to implement/support EST-coaps URIs are the short URIs > for EST-coaps though. After the followup discussion, I was thinking more about adding something along the lines of "MAY implement the long URIs". But this comment is non blocking and I am sure you will do the right thing. Best Regards, Alexey > Panos > > > -Original Message- > From: Ace On Behalf Of Alexey Melnikov via > Datatracker > Sent: Monday, January 06, 2020 12:21 PM > To: The IESG > Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; > ace-cha...@ietf.org; ace@ietf.org > Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: > (with COMMENT) > > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > -- > COMMENT: > -- > > Thank you for this well written document. And thank you for addressing my > points in github. > > A remaining comment (which might or might not have been resolved): > > 5.1. Discovery and URIs > >Clients and servers MUST support the short resource EST-coaps URIs. > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > Attachments: > * smime.p7s ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
Hi Alexey, > Just to clarify: the original EST URIs are prohibited in COAP-EST? No we don't forbid them in the draft. We do not make them MTI either though. The long URIs can be supported and they would be a non-default EST-coaps resource that a server could support and a client could do resource discovery for. So we did not add text to say "MUST NOT implement the long URIs". The mandatory to implement/support EST-coaps URIs are the short URIs for EST-coaps though. Panos -Original Message- From: Ace On Behalf Of Alexey Melnikov via Datatracker Sent: Monday, January 06, 2020 12:21 PM To: The IESG Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; ace-cha...@ietf.org; ace@ietf.org Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- COMMENT: -- Thank you for this well written document. And thank you for addressing my points in github. A remaining comment (which might or might not have been resolved): 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace smime.p7s Description: S/MIME cryptographic signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Panos, On Fri, Dec 27, 2019, at 5:20 AM, Panos Kampanakis (pkampana) wrote: > Hi Alexey, > > This commit > https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e > should address your feedback. The full discussion is in > https://github.com/SanKumar2015/EST-coaps/issues/155 > > Let us know if it does not make sense. Yes, the changes look fine to me. I just cleared my DISCUSS. Best Regards, Alexey > Rgs, > Panos > > *From:* Ace *On Behalf Of *Alexey Melnikov > *Sent:* Monday, December 23, 2019 9:42 AM > *To:* consulta...@vanderstok.org; Carsten Bormann > *Cc:* ace-cha...@ietf.org; Jim Schaad ; Benjamin > Kaduk ; Ace Wg ; The IESG ; > draft-ietf-ace-coap-...@ietf.org; Klaus Hartke > *Subject:* Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: > (with DISCUSS and COMMENT) > > Hi Peter, > > On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: >> HI all, >> >> We had this discussion about this specific text several times. >> I like to keep at least some text for the following reason: >> Implementers, new to coap without a photographic memory of RFC7252 text, are >> surprised by the absence of uri host in the examples, and tend to assume an >> error. >> >> The curent text does not look like a "normative rephrasing" to me. >> Nevertheless, is the suggestion below acceptable to everyone? >> >> OLD >> >> The Uri-Host and Uri-Port Options can be omitted if they coincide >> with the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are typically >> used when an endpoint hosts multiple virtual servers and uses the >> Options to route the requests accordingly. >> >> NEW >> Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options >> can be omitted if they coincide >> with the transport protocol destination address and port >> respectively. >> >> Other suggestions are welcome. > Your suggested text is much better. > > Thank you, > Alexey >> Peter >> Carsten Bormann schreef op 2019-12-20 18:16: >>> On Dec 20, 2019, at 17:34, Klaus Hartke wrote: I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* >>> >>> Klaus has an important point here. >>> >>> We need to be **much more** vigilant about specifications messing with >>> their normative references. >>> Saying how they are used, yes, but re-stating (or, worse, re-interpreting) >>> normative material from those references is prone to creating dialects that >>> no longer interoperate with their unadulterated originals. Unless these are >>> hopelessly broken(*) and this is the only way to fix them, this is a MUST >>> NOT. >>> >>> Grüße, Carsten >>> >>> (*) the normative reference EST has an example for that case: The use of >>> content-transfer-encoding with HTTP, which is explicitly ruled out in >>> Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a >>> count of RFC 7030 messing with a normative reference, and in turn >>> **needed** to be messed with in CoAP-EST (and eventually needs to be fixed >>> in the parent specification, too). > > > *Attachments:* > * smime.p7s ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- COMMENT: -- Thank you for this well written document. And thank you for addressing my points in github. A remaining comment (which might or might not have been resolved): 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
Jim, Jim Schaad writes: [Ben's review] > We also are potentially in violation of the framework's requirements with > respect to the independent selection of profiles for client/AS and client/RS > interactions -- at present, when DTLS+RPK is used for client/RS, we require > that DTLS+RPK is also used for client/AS, in order to prove possession of the > key. We could perhaps weasel our way out by saying that the framework's > requirement applies at the profile granularity, and with symmetric PSK we can > be fully independent, but we still need to say something about this property > and the interaction with the framework's requirements. > > [JLS] I am missing where it is saying this. Can you give a pointer? I > don't believe that the POP of the RPK is required at the time that the token > is obtained. The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
