Re: [Acme] Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
Linda, To provide some clarification: a "delay-tolerant network" isn't just a descriptive term, it is a specific type of overlay network operating with the Bundle Protocol of RFC 9171 in accordance with the principals of RFC 4838. This proposed validation method is both conceptually and procedurally analogous to the email validation of RFC 8823, and a DTN can be thought of in the same way as an email transport network: email addresses exist independently of the IP addresses or DNS names of the clients used to originate and receive those email messages, just as DTN Node IDs (and the BP Agents that transfer bundles) exist independently of whatever network, IP or otherwise, that transports bundles addressed with those Node IDs. This is why the RFC 8823 validation mechanism exists separately from the IP/DNS mechanisms, and is why the DTN Node ID mechanism requires its own mechanism. Brian S. On Fri, Oct 21, 2022 at 6:28 PM Linda Dunbar wrote: > Deb, > > > > The discussion stemmed from my question about the mechanism specified in > the draft-ietf-acme-dtnnodeid-10 not touching upon the special properties > of Delay Tolerant. For example, are there any special considerations for > the satellite network that requires hours or days of the round trip instead > of the traditional network of ms for the round trip? > > This triggered me to ask if the mechanism is applicable to validate IDs in > other types of networks, like SD-WAN. > > > > Linda > > > > *From: *Deb Cooley > *Date: *Friday, October 21, 2022 at 2:33 PM > *To: *Linda Dunbar > *Cc: *Roman Danyliw , "ops-...@ietf.org" , > "acme@ietf.org" , "draft-ietf-acme-dtnnodeid@ietf.org" > , "last-c...@ietf.org" < > last-c...@ietf.org> > *Subject: *Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10 > > > > Linda, > > > > I'm now very confused. The original topic was comments on a DTN acme > draft. How did we get to discussing Virtual Network IDs of SD-WAN edge > devices? > > > > Do you want to get X.509 certificates for these devices? Or do you have > something else in mind to validate these devices? > > > > Deb Cooley > > > > On Fri, Oct 21, 2022 at 2:02 PM Linda Dunbar > wrote: > > Roman, > > Thanks. > I don't see how DTN wg is relevant, as the SD-WAN is NOT Delay Tolerant > Network. More relevance is on the "certificate issuance mechanism" to > validate if the IDs advertised by a remote node are legitime. > > Does ACME Wg work on "Certificate issuance mechanism" for remote node > IDs? > > Linda > On 10/21/22, 12:53 PM, "Roman Danyliw" wrote: > > IMO, the simplest thing would be to pose this question on the DTN WG > mailing list. This very specific work is being done in the ACME WG because > it has the expertise on the certificate issuance mechanism, but I see you > applicability to SD-WAN as more general. > > Roman > > > -Original Message- > > From: Linda Dunbar > > Sent: Friday, October 21, 2022 1:48 PM > > To: Roman Danyliw ; ops-...@ietf.org > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org; > last-c...@ietf.org > > Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10 > > > > Roman, > > > > Can you give me a few names with who I can chat to find out more? > > > > Thank you > > > > Linda > > > > On 10/21/22, 12:38 PM, "Roman Danyliw" wrote: > > > > Hi Linda! > > > > As I understand the scenario below, it would align to the work > in this > > document only to the degree that the SD-WAN network would be an > underlay > > to the DTN Bundle Protocol (via some as of yet undefined convergence > layer) > > and the Virtual Network IDs would have an easy mapping to the > DTN-specific > > addressing mechanism (Endpoint IDs per Section 4.2.5 of RFC9171). > I'll let the > > DTN experts correct me or provide more insight on the alignment. > > > > As an aside, there is a critical IANA issue with this document > and it is being > > pulled from the planned telechat docket. > > > > Roman > > > > > -Original Message- > > > From: Linda Dunbar > > > Sent: Friday, October 21, 2022 12:46 PM > > > To: Roman Danyliw ; ops-...@ietf.org > > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org; > last- > > c...@ietf.org > > > Subject: Re: Opsdir telechat review of > draft-ietf-acme-dtnnodeid-10 > > > > > > Roman, > > > > > > Can the mechanism specified in the draft be used to validate > the Virtual > > > Network IDs of SD-WAN edge devices? > > > For example, an SDWAN edge deployed in a remote site, say a > shopping > > mall, > > > might advertise the routes and client VPN IDs to the BGP > Route-Reflector > > (RR). > > > The RR needs to validate the Client's IDs are legitimate. Can > the mechanism > > > specified in the draft do the job? >
Re: [Acme] [IANA #1217636] Expert Review for draft-ietf-acme-dtnnodeid-08 (bundle)
All, I'm reposting here to confirm that in a different thread I identified the DTN draft which modifies the IANA registry [1] as a necessary companion to the ACME document. The DTN document purely updates the IANA registry and has no other substantial content. [1] https://datatracker.ietf.org/doc/draft-sipos-dtn-bpv7-admin-iana/ On Thu, Oct 20, 2022 at 8:07 PM Amanda Baber via RT < drafts-expert-rev...@iana.org> wrote: > Thanks, Marc. I've sent a message to the document's authors, chairs, and > ADs. > > Amanda > > On Thu Oct 20 23:44:09 2022, marc.blanc...@viagenie.ca wrote: > > I think this request should be in the hands of the DTN co-chairs or > > the author to add additional text to the document or have another > > document. I don’t think, as one of the two designated expert for that > > registry, it is us, the designated experts, to decide a new structure > > of the registry (while I do have my own opinion on how to do it). > > While it may slow down the publication of that document, I guess you > > could put that state and someone will follow up and I guess the draft > > will be in revised ID needed until that issue is resolved. > > > > My 2 cents. > > > > Marc. > > > > > Le 20 oct. 2022 à 19:14, Amanda Baber via RT > > rev...@iana.org> a écrit : > > > > > > Dear Bundle Administrative Record Types experts (cc: acme WG), > > > > > > Resending this question about a new bundle registry field in a > > > document on next Thursday's telechat agenda. > > > > > > If the document continues to include the new "Protocol Version" > > > field, but doesn't tell us to add the field to the registry (which > > > also requires that we be told how to populate it for existing > > > entries), we'll have to mark the document "IANA NOT OK." > > > > > > thanks, > > > Amanda > > > > > > On Fri Oct 14 20:23:02 2022, amanda.baber wrote: > > >> Dear bundle experts and DTN chairs, > > >> > > >> This document, listed on the IESG's October 27th telechat agenda, > > >> asks > > >> us to add an entry to the Bundle Administrative Record Types > > >> registry > > >> that would include a "Protocol Version" field: > > >> > > >> https://datatracker.ietf.org/doc/html/draft-ietf-acme-dtnnodeid > > >> > > >> However, that field isn't currently part of the registry: > > >> > > >> https://www.iana.org/assignments/bundle/bundle.xhtml#admin-record- > > >> types > > >> > > >> We need a document that a) creates the field and b) populates it for > > >> existing entries so that we can list it as an additional reference > > >> for > > >> the registry itself. Can that be done through this document? > > >> > > >> thanks, > > >> > > >> Amanda Baber > > >> IANA Operations Manager > > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-10.txt
All, This last editorial change adds (aside) paragraphs to explain the experimental nature of different aspects of the validation mechanism, updates references to now-published RFCs, and fixes the examples to properly contain the algorithm identifier structures. I believe that this addresses all comments received so far, so the document is ready for WGLC and further progression. Thanks, Brian S. On Sun, Sep 11, 2022 at 10:26 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automated Certificate Management Environment > (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension > Author : Brian Sipos > Filename: draft-ietf-acme-dtnnodeid-10.txt > Pages : 32 > Date: 2022-09-11 > > Abstract: >This document specifies an extension to the Automated Certificate >Management Environment (ACME) protocol which allows an ACME server to >validate the Delay-Tolerant Networking (DTN) Node ID for an ACME >client. The DTN Node ID is encoded as a certificate Subject >Alternative Name (SAN) of type otherName with a name form of >BundleEID and as an ACME Identifier type "bundleEID". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-10.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-10 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt
Sean, Thank you for this review! I'm preparing changes based on this feedback. For your #2 and #4 my preference is to cite the IANA registry as the authority with RFC 9174 as the secondary only because I want to treat RFC 9174 as an informative reference. It certainly informs the use case of this validation method but they shouldn't be seen as directly coupled; only through the PKIX OIDs on which they both depend. On Wed, Sep 7, 2022 at 1:43 PM Sean Turner wrote: > Hi! Some comments: > > tl;dr: Let the experiment begin! > > # General > > I thought this document is well written and easy to follow. > > # Nits > > 1) s1: s/certificate authorities/Certification Authorities (CAs) > > 2) s2: I think maybe you can drop the IANA-SMI reference here: > > … identified by id-on-bundleEID of [IANA-SMI], consistent >with the requirements of Section 4.4.2.1 of [RFC9174]. > > RFC 9174 includes the OID and the semantics so unless you’re changing that > I think this text could be: > > … identified by id-on-bundleEID, consistent >with the requirements of Section 4.4.2.1 of [RFC9174]. > > 3) s3.3: r/[draft-ietf-cose-hash-algs]/[RFC9054] > > 4) s5: A better reference for id-kp-bundleSecurity would be [RFC9174], at > least I think it is because that’s where id-kp-bundleSecurity is defined. > > 5) s5.2: I think the last para needs a little tweaking. Just because a > client asks for signature only certificate for a DH key shouldn’t mean they > get it ;) Maybe something like, “Obviously, the request for signature-only > and encryption-only certificates is algorithm dependent” or something like > that. > > 6) Appendix A: I think you need to include text that states this Appendix > is a normative part of the specification. Often Appendices are considered > informative, but this one includes the definition of the CDDL. > > Cheers, > spt > > > On Aug 18, 2022, at 06:13, Deb Cooley wrote: > > > > A reminder: we need a few more eyes on this draft to move it forward. > > > > Deb (and Yoav) > > > > On Thu, Jul 28, 2022 at 8:19 PM Deb Cooley wrote: > > Dear ACME, > > > > We need to get some eyes on this draft - draft-ietf-acme-dtnnodeid. If > you have time, please take a look and let us know whether you think it is > ready (or make comments). We are hoping to get this draft finished! > > > > Deb Cooley > > > > On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J. > wrote: > > All, > > > > I haven’t seen any reviews of the last draft version -09. I hope that > the closer alignment with RFC 8823 makes its understanding and analysis > easier. > > > > > > > > From: Acme On Behalf Of Deb Cooley > > Sent: Tuesday, May 24, 2022 7:39 AM > > To: IETF ACME ; Brian Sipos > > Cc: Roman Danyliw ; Dorothy E Cooley < > deco...@radium.ncsc.mil> > > Subject: [EXT] Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt > > > > > > > > APL external email warning: Verify sender acme-boun...@ietf.org before > clicking links or attachments > > > > > > > > Did we ever get reviews on the updated draft? If not, can we get some > (or revive the) volunteers? > > > > > > > > Deb Cooley > > > > > > > > On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley wrote: > > > > It is on the agenda. We will ask for volunteers to review. > > > > > > > > Deb > > > > > > > > On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw wrote: > > > > Hi! > > > > > > > > We’re past IETF LC in terms of document processing and -08 and -09 > appear to have changed protocol behavior. Since there hasn’t been any > discussion about this on the mailing list yet, I’d like to ask the WG to > review these changes ( > https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09). > Please raise any objections by Friday April 1. > > > > > > > > Helpfully, this document is on the ACME meeting agenda tomorrow at IETF > 113. > > > > > > > > Regards, > > > > Roman > > > > > > > > From: Acme On Behalf Of Brian Sipos > > Sent: Wednesday, March 2, 2022 11:27 PM > > To: IETF ACME > > Subject: Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt > > > > > > > > All, > > > > I have posted an update to the Node ID Validation document which updates > references to now-published DTN RFCs (yay!) and adds algorithm agility for > the Key Authorization Digest to avoid the validation method being stuck on > SHA-256
Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt
Stephen, All of your interpretations look correct to me; thank you for this insightful review! I can add a paragraph to Section 1.1 "Scope" explaining what the experiment actually is and what it is not. I agree that the ACME validation is the well-understood portion and the utility of the mechanism is the actual experiment. The rationale for Section 3.5 is really to maintain parity with the existing ACME validation methods and to explain to implementations what assumptions to avoid (e.g., there's no longer a prior known source endpoint for the Challenge Bundle, keep responding until the client tells you to stop). Even though this is getting into more complex scenarios than the basic experiment of usefulness, I would like to keep the guidance in there for consistency of logic if someone does want to use multi-perspective. The whole thing is conditioned on "When required by policy ..." so it's really all optional. I am going to track proposed changes as part of a github ticket [1] and, if you don't mind, would like to hash out any more details in that ticket and an eventual pull request. Thanks, Brian S. [1] https://github.com/BrianSipos/acme-dtnnodeid/issues/4 On Sat, Sep 3, 2022 at 4:38 PM Stephen Farrell wrote: > > Hiya, > > Someone asked me to look at this draft, so I did:-) > > On 18/08/2022 11:13, Deb Cooley wrote: > > A reminder: we need a few more eyes on this draft to move it forward. > > Overall, I think the draft is ready for experiments on which > nothing much (yet) depends, but not ready for deployments > that do need some predictable forms of security guarantee and > I don't think that distinction is clear enough in the draft > as of now. (Or, I missed it:-) > > The draft does aim to become an experimental RFC, which is > good, but I think would benefit from some text saying that > the practical security benefits from the mechanism described > here is most of the experiment. (IOW, the experiment here is > mainly about the security resulting from use of this protocol > and not experimentation as to whether this protocol will > otherwise work or not.) > > A few brief reasons for the above: > > - The emergent security properties of DTN naming and routing > schemes are mostly unknowns if we compare those against what > we know of security based on DNS and BGP (or email). > - DTN routing is far likelier to involve nodes that broadcast > or multicast or use spray-and-wait so there will be notably > more on-path nodes who could cheat, not all of which will be > "well known" (e.g. some passing data mule). > - Last I know of, (which is a while ago) BIB deployment was > still notional. That may have changed in some DTNs but I'm > also unaware that DTN security mechanisms like the BIB are > being used to secure bundles between independent DTNs. > > A not-quite-nit on the text itself: section 3.5 seems odd. > I'm not sure for what DTN topologies this might make sense > as an added security mechanism, but I'd not be surprised > if it provided no added benefit, if the ACME server were in > a well-connected region that has basically one gateway to > each DTN that's less well-connected. I don't know if the > ACME or DTN WGs considered that though, maybe they did, but > I'd probably delete that section as figuring out whether > such mechanisms add value for DTNs as they do for the DNS > is part of the experiment I'd guess and so it'd be a bit > soon to include such recommendations now. > > Cheers, > S. > > > > > Deb (and Yoav) > > > > On Thu, Jul 28, 2022 at 8:19 PM Deb Cooley wrote: > > > >> Dear ACME, > >> > >> We need to get some eyes on this draft - draft-ietf-acme-dtnnodeid. If > >> you have time, please take a look and let us know whether you think it > is > >> ready (or make comments). We are hoping to get this draft finished! > >> > >> Deb Cooley > >> > >> On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J. > > >> wrote: > >> > >>> All, > >>> > >>> I haven’t seen any reviews of the last draft version -09. I hope that > the > >>> closer alignment with RFC 8823 makes its understanding and analysis > easier. > >>> > >>> > >>> > >>> *From:* Acme *On Behalf Of *Deb Cooley > >>> *Sent:* Tuesday, May 24, 2022 7:39 AM > >>> *To:* IETF ACME ; Brian Sipos < > brian.sipos+i...@gmail.com> > >>> *Cc:* Roman Danyliw ; Dorothy E Cooley < > >>> deco...@radium.ncsc.mil> > >>> *Subject:* [EXT] Re: [Acme] I-D Action: > draft-ietf-acme-dtnnodeid-09.txt > &g
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
All, I have posted an update to the Node ID Validation document which updates references to now-published DTN RFCs (yay!) and adds algorithm agility for the Key Authorization Digest to avoid the validation method being stuck on SHA-256. It does add a publication dependency on the COSE hash document, but that is in AUTH48 (though it's been stuck in that state for some time now). Comments are welcome and can be discussed at the next IETF. Brian S. On Wed, Mar 2, 2022 at 7:35 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automated Certificate Management Environment > (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension > Author : Brian Sipos > Filename: draft-ietf-acme-dtnnodeid-09.txt > Pages : 31 > Date: 2022-03-02 > > Abstract: >This document specifies an extension to the Automated Certificate >Management Environment (ACME) protocol which allows an ACME server to >validate the Delay-Tolerant Networking (DTN) Node ID for an ACME >client. The DTN Node ID is encoded as a certificate Subject >Alternative Name (SAN) of type otherName with a name form of >BundleEID and as an ACME Identifier type "bundleEID". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-09.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-08.txt
All, This latest revision of the Node ID validation document has made both behavioral and editorial changes. The change to behavior and encodings (on both ACME and DTN channels) simplifies the logic for both server and client and also avoids a possible on-path impersonation method when a client account key thumbprint is known (from some other channel). Each of the two token parts and new ID value are now single purpose and more closely resemble the values in the email validation RFC 8823. The editorial changes are to add clarity to the DTN terms and uses. I believe all of thr comments received to date have been addressed. Thank you, Brian S. On Mon, Jan 10, 2022, 23:24 wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automated Certificate Management Environment > (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension > Author : Brian Sipos > Filename: draft-ietf-acme-dtnnodeid-08.txt > Pages : 30 > Date: 2022-01-10 > > Abstract: >This document specifies an extension to the Automated Certificate >Management Environment (ACME) protocol which allows an ACME server to >validate the Delay-Tolerant Networking (DTN) Node ID for an ACME >client. The DTN Node ID is encoded as a certificate Subject >Alternative Name (SAN) of type otherName with a name form of >BundleEID and as an ACME Identifier type "bundleEID". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-08.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-08 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Opsdir last call review of draft-ietf-acme-dtnnodeid-07
Linda, The way that Roman has described this is correct. There are however subtleties to the distinctions between Node ID, Administrative Endpoint ID, and general Endpoint ID that are not explained in this document that deserve at least an expansion in the Terminology section and a paragraph in the ACME Identifier section (to delineate between what you can do with this mechanism and what you cannot). I intend on making an update soon with this change and one other behavioral change that came up in earlier review. Thank you for the feedback, Brian S. On Thu, Jan 6, 2022 at 11:57 AM Linda Dunbar wrote: > Roman, > > Thank you very much for the explanation. > It now all makes sense. > > Thank you. > > Linda > > -Original Message- > From: Roman Danyliw > Sent: Thursday, January 6, 2022 9:00 AM > To: Linda Dunbar ; ops-...@ietf.org > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org; > last-c...@ietf.org; Linda Dunbar > Subject: RE: Opsdir last call review of draft-ietf-acme-dtnnodeid-07 > > Hi Linda! > > Thanks for the review. > > > -Original Message- > > From: Linda Dunbar via Datatracker > > Sent: Monday, November 29, 2021 4:31 PM > > To: ops-...@ietf.org > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org; > > last-c...@ietf.org; ldun...@futurewei.com > > Subject: Opsdir last call review of draft-ietf-acme-dtnnodeid-07 > > > > Reviewer: Linda Dunbar > > Review result: Not Ready > > > > I have reviewed this document as part of the Ops area directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the Ops > area directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > This document specifies an extension to ACME protocol which allows an > > ACME server to validate the Delay-Tolerant Networking Node ID for an > ACME client. > > > > Issues: > > I will let the authors correct me when I get it wrong. As background, > this is work that was coordinated with the DTN WG but done in the ACME WG > since it has the most expertise with ACME extensions. > > > The document didn't describe how the Node ID described in this > > document is related to the Delay Tolerant Network. I see the mechanism > > can be equally used in any network. What are the specifics related to > > the "Delay Tolerant Network"? > > The relationship to DTN is that this document describes how to get a > certificate via ACME for a DTN Node ID, the unique addressing scheme > defined by the DTN architecture. Specifically, this document allows the > validation of a claim for a Node ID represented in the certificate as a > Subject Alternative Name (SAN) of type otherName with a name form of > BundleEID (defined by the DTN WG in Section 4.4.2.1 of > draft-ietf-dtn-tcpclv4-28). BundleEID is a new PKIX OID defined > specifically for DTN addresses. This new OID was not the original design > but something that surfaced during AD review of this document and resulted > in coordinated changes to both this document and draft-ietf-dtn-tcpclv4. > > While DTN is designed to be a flexible overlay onto many different types > of networks assuming a convergence layer is defined, it is my understanding > that the addressing scheme for the bundles would still be a DTN Node ID. > I'm not aware of any other protocol that is using the DTN addressing scheme > so this ACME extensions strikes me as quite purpose built for DTN. > > Regards, > Roman > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-06.txt
All, This latest update of the DTN Node ID Validation draft removes any updates to the DTN document (and references the new draft that those portions are now moved into) and makes some more explicit statements about "multi-perspective validation" including a recommended (not required) policy that agrees with Let's Encrypt implementation experience. I believe that these changes address all comments received to-date and the draft should be ready for any further review. Thanks, Brian S. On Wed, Oct 13, 2021 at 11:58 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automated Certificate Management Environment > (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension > Author : Brian Sipos > Filename: draft-ietf-acme-dtnnodeid-06.txt > Pages : 29 > Date: 2021-10-13 > > Abstract: >This document specifies an extension to the Automated Certificate >Management Environment (ACME) protocol which allows an ACME server to >validate the Delay-Tolerant Networking (DTN) Node ID for an ACME >client. The DTN Node ID is encoded as a certificate Subject >Alternative Name (SAN) of type otherName with a name form of >BundleEID and as an ACME Identifier type "bundleEID". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-06.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt
Aaron, Yes, this is intentional and it's due to a slight difference in the mechanics between the two mechanisms. While the RFC 8823 mechanism can generate a unique "from" email address for each challenge (e.g. the document example " acme-challenge+2i211oi1204...@example.com") that the client can use to filter-in valid challenges, the Bundle protocol has no such controllable uniqueness at the BP layer (i.e the Primary Block). In RFC 8823 the "from" address can be used by an ACME-aware mail client to ignore unauthorized requests. While in the proposed Node ID validation the ACME server's Source Node ID is the same for all challenges, and only the "token-chal" is distinct for the authorized challenge. The ACME client's BP agent can use this to filter-in (and respond to) only authorized challenges. This does bring up the point that multi-perspective validation would have different challenge bundle Source Node ID for each perspective, so the current logic of defining a single "source" for each challenge limits the multi-perspective use to routing from multiple forwarders but all from the same source (and thus the response bundle going to the same destination). If the "token-chal" is assumed to be globally unique, then the client really doesn't need to know what ACME servers are making the challenges. On Mon, Oct 4, 2021 at 3:05 PM Aaron Gable wrote: > Brian, > > Fantastic, thank you for the responses! One further comment inline. > > On Thu, Sep 30, 2021 at 3:28 PM Brian Sipos > wrote: > >> BS1: This is to handle a basic property that BP bundles are necessarily >> independent units, unidirectional, and (currently) have no "conversation" >> or "flow" associations at the BP layer. Any associations between bundles >> must be made at the application layer above, so in fact tuple (token-chal, >> token-bundle) is the *only* way for an ACME Server to correlate the two >> bundles. >> This is the same way that RFC8823 uses to correlate the two emails. >> Because email and bundles both have similar logical patterns of transport, >> this Node ID validation is intended to have the same structure and security >> properties as the email validation. >> > > RFC8823 sends the two tokens via separate mechanisms: token-part1 > (corresponding to token-bundle) is sent only in the email, and token-part2 > (corresponding to token-chall) is provided only via the Challenge object > over HTTPS to the ACME client. This draft differs, in that both token-chall > *and* token-bundle are provided in the Challenge Bundle. I believe that an > ACME Server, rather than its BP Agent, should be responsible for verifying > that the Response Bundle is correct, so there is no need for the Server's > BP Agent to ever be aware of token-chall at all, just as in RFC8823 there > is no reason for the Server's email agent to ever be aware of the > token-part2 that is part of the Challenge object. > > Thanks, > Aaron > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt
Aaron, These are all good points to notice. My responses are inline below with the prefix "BS1". On Wed, Sep 29, 2021 at 5:51 PM Aaron Gable wrote: > A couple comments/questions from my recent read-through. > > - In Section 3, it says "the validation procedure is successful only if > all responses are successful". This language is included because the draft > explicitly accounts for multi-perspective validation, with each perspective > using a different `token-bundle` value. Speaking as a Let's Encrypt > engineer: our research into[1] and practical experience with[2][3] > multi-perspective validation for current ACME challenge types is that > requiring *all* validations to succeed is both not necessary for security > and is actively harmful for reliability. Let's Encrypt's current policy is > twofold: First, the validation from within the audited, secure data center > perspective must succeed, as required by the Baseline Requirements; Second, > no more than one of the remote perspectives can fail validation. This > allows the CA to take advantage of multiple perspectives, without creating > undue latency or reliability problems. Obviously, these bundleEID > certificates would not be issued by CAs subject to the CA/BF BRs, so the > situation is slightly different. But unless there is a very compelling > reason to do so that I'm not aware of, I would caution against requiring > that every perspective succeed in this specification, and instead leave > that up to server policy. > > [1] > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > [2] > https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee > [2] https://letsencrypt.org/2020/02/19/multi-perspective-validation.html > > BS1: Yes, the current required behavior was not driven by anything but a simple, and naive, logic. I agree that making it a matter of CA policy would be better, and then I can add that "The RECOMMENDED policy is ..." to agree with what you have described: one primary perspective succeeds and at least all-but-one other perspectives succeed. > - It is not clear to me why the `token-chal` value is included in both the > ACME Server's `dtn-nodeid-01` Challenge resource and in the BP Agent's > Challenge Bundle administrative record content. The overview of the client > procedure in Section 3 makes it seem like the ACME Client should be > communicating the `token-chal` to its BP Agent, so that it can be used to > fulfil the challenge. But Section 3.4 says that the response's `token-chal` > should be copied from the Request bundle. The inclusion of the `token-chal` > in both places feels redundant. If it is not, and there is good reason for > its inclusion in both places, then I believe the language should be updated > to make that reasoning clear. > > BS1: This is to handle a basic property that BP bundles are necessarily independent units, unidirectional, and (currently) have no "conversation" or "flow" associations at the BP layer. Any associations between bundles must be made at the application layer above, so in fact tuple (token-chal, token-bundle) is the *only* way for an ACME Server to correlate the two bundles. This is the same way that RFC8823 uses to correlate the two emails. Because email and bundles both have similar logical patterns of transport, this Node ID validation is intended to have the same structure and security properties as the email validation. > - Finally, Section 3.4.1 says that the Response Bundle must be received in > the interval which "starts at the Creation Timestamp and extends for the > Lifetime of the Response Bundle". Why is this the lifetime of the Response > Bundle, as opposed to the lifetime of the Challenge Bundle? A server should > only accept responses that arrive within the window that it defines; > although the draft says that the client's Response Bundle SHALL have a > lifetime which is contained within the Challenge Bundle's lifetime, a > malicious client could ignore that constraint and generate bundles with > lifetimes far into the future and a strictly-implemented server would be > obligated to accept them. > > BS1: I agree that ideally these would indicate the same end time, but the ACME server should trust only its own originated data, i.e. from the challenge bundle. This will be reworded with a clarifying statement about why. > Thanks, > Aaron > > On Sun, Sep 26, 2021 at 6:24 AM Brian Sipos > wrote: > >> All, >> This latest update to the DTN Node ID validation draft should resolve all >> of the AD comments *except* for this document updating a document from a >> different WG. The discrepancy in BPv7 (not) using admin record type IANA >
Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt
All, This latest update to the DTN Node ID validation draft should resolve all of the AD comments *except* for this document updating a document from a different WG. The discrepancy in BPv7 (not) using admin record type IANA registry can be pulled out of this ACME document and made into its own separate DTN WG draft. But that would need to be a normative reference of this document and I didn't want to make big structural changes with the other edits. Part of this update is a change in the related DTN/BP PKIX profile (from TCPCLv4) to avoid using SAN URI and instead use a SAN otherName form specific to bundle EID content. The logic on the ACME side is otherwise the same, just with a different identifier name and its associated PKIX claim source. I still see a couple of vestigial mentions of "URI" that need to be replaced for consistency. Please let me know if there are any other issues to discuss before the next interim, Brian S. On Thu, Sep 23, 2021 at 12:19 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automated Certificate Management Environment > (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension > Author : Brian Sipos > Filename: draft-ietf-acme-dtnnodeid-05.txt > Pages : 29 > Date: 2021-09-22 > > Abstract: >This document specifies an extension to the Automated Certificate >Management Environment (ACME) protocol which allows an ACME server to >validate the Delay-Tolerant Networking (DTN) Node ID for an ACME >client. The DTN Node ID is encoded as a certificate Subject >Alternative Name (SAN) of type otherName with a name form of >"bundleEID" and as an ACME Identifier type "bundleEID". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-05.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
Not yet. The document's original AD was Magnus Westerlund, but the new DTN documents were handed off to new AD Zaheduzzaman Sarker (included on this message) earlier this year. My feeling of the DTN WG perspective regarding the PKIX details is: "figure out the right way to do it," because there is no well established PKI in that domain that would need to retain compatibility. For Zahed, the original ACME review which drove this discussion was < https://mailarchive.ietf.org/arch/msg/acme/7HaJSiLnZ21zppL8p6MMIr6JEaI/>. I have been posting summaries of this discussion in the DTN mailing list also, starting at < https://mailarchive.ietf.org/arch/msg/dtn/xNp_9mFjTadDivhoKZA35B5MNUk/>. On Fri, Aug 20, 2021 at 3:44 PM Russ Housley wrote: > Brian: > > Is the AD that sponsored that document part of this discussion? If not, I > suggest that we loop them in. > > Russ > > On Aug 20, 2021, at 3:10 PM, Brian Sipos > wrote: > > Rich, I see your point. I had made my own assumptions that tools would > validate that the SAN URI contained a valid URI and nothing more. But > because the RFC 5280 requires more about the authority part some > tools/libraries are free to throw out URIs that have some other > (RFC-invalid) authority part. > > Unfortunately, the document this most affects is already in the editor > queue. But I think the new otherName type-id OID will be needed to avoid > potential tooling compatibility issues. My plan is to propose adding a new > otherName OID for any DTN Endpoint ID (as a URI) and then use that for DTN > Node IDs as a subset of EIDs. The logic is almost identical to current SAN > URI except for those DNS/IP related restrictions on SAN URI content being > replaced by DTN scheme restrictions. > > On Sun, Aug 15, 2021 at 11:11 AM Salz, Rich wrote: > >> >>- Does it seems like it's at all reasonable, from the perspective of >>the security area and focus on PKIX (documents and tools), for an >>application profile like this to say to conform to "... RFC 5280 with the >>exception of the FQDN/IP-address restriction on URI authority part". It's >>not exactly an update to RFC 5280 but I don't know how valid or typical it >>is for one RFC to relax requirements from a normative reference. >> >> >> >> How would that work? Let’s take an application using OpenSSL. It >> currently calls d2i_X509() to parse the DER into internal format. It does >> various cert checks along the way. Would you add a new API (because you >> can’t change the calling sequence it breaks all existing applications), and >> then pass that flag down through all the call stack? >> >> >> > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
Rich, I see your point. I had made my own assumptions that tools would validate that the SAN URI contained a valid URI and nothing more. But because the RFC 5280 requires more about the authority part some tools/libraries are free to throw out URIs that have some other (RFC-invalid) authority part. Unfortunately, the document this most affects is already in the editor queue. But I think the new otherName type-id OID will be needed to avoid potential tooling compatibility issues. My plan is to propose adding a new otherName OID for any DTN Endpoint ID (as a URI) and then use that for DTN Node IDs as a subset of EIDs. The logic is almost identical to current SAN URI except for those DNS/IP related restrictions on SAN URI content being replaced by DTN scheme restrictions. On Sun, Aug 15, 2021 at 11:11 AM Salz, Rich wrote: > >- Does it seems like it's at all reasonable, from the perspective of >the security area and focus on PKIX (documents and tools), for an >application profile like this to say to conform to "... RFC 5280 with the >exception of the FQDN/IP-address restriction on URI authority part". It's >not exactly an update to RFC 5280 but I don't know how valid or typical it >is for one RFC to relax requirements from a normative reference. > > > > How would that work? Let’s take an application using OpenSSL. It > currently calls d2i_X509() to parse the DER into internal format. It does > various cert checks along the way. Would you add a new API (because you > can’t change the calling sequence it breaks all existing applications), and > then pass that flag down through all the call stack? > > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
All, I understand more fully now that the RFC5280 definition for uniformResourceIdentifier has a more specific purpose than as a general URI container, and that existing tools likely have additional assumptions baked in about what services the URIs are to be used for. I was really hoping that the use of the SAN URI in TCPCLv4 would allow reuse of existing structure and avoid new OID allocation, but it appears that was over optimistic. Does it seems like it's at all reasonable, from the perspective of the security area and focus on PKIX (documents and tools), for an application profile like this to say to conform to "... RFC 5280 with the exception of the FQDN/IP-address restriction on URI authority part". It's not exactly an update to RFC 5280 but I don't know how valid or typical it is for one RFC to relax requirements from a normative reference. On the other hand, I see no reason why a new otherName OID allocation under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [2] could not be used with the same value (a Node ID URI) and value encoding (IA5String). The PKIX profile for DTN is new and I doubt it has much deployment yet within DTNs. But now's the time to settle this out; the TCPCLv4 doc defining the profile is still in the RFC editor's queue. RE Russ' comment about "dtn" scheme-specific-part structure: unfortunately the naming portion of BPv7 is more informational than normative at this point. These URI schemes have been in use for many years across several implementations; I believe that they are in wide use in DTNs and there would be little support to change the SSP structure. The interaction of the URI structure with "other domain" tools like this just was not foreseen. [2] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 On Sat, Aug 14, 2021 at 11:08 AM Salz, Rich wrote: > I completely agree with Ryan. > > > >- Do not touch 5280 as there will be too many competing interests to >improve it and interop will be broken or the bis version will be ignored. >(Years ago I wanted to re-open PKIX and I learned what a bad idea that is, >and I became ACME co-chair instead.) >- There are extension points within 5280 that can be used, at the loss >of built-in nameConstraints support. That doesn’t seem like a big loss, >especially as the semantics for DTN are not clear. >- Do not use the 5280 structures without saying this is PKIX, as that >will need to great confusion among open source implementors and their > users. > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04 (others)
Roman, My replies regarding the other, editorial comments are below with the prefix "BS:". I'll get back to the earlier topics in the other mail thread. ** Section 1. Editorial. The paragraph starting with "Once an ACME server validates ..." jumps immediately into discussion a "uri" without explicitly describing it. The text also transitions from the previous paragraph talking DTN Node Ids being URIs and now talking about "uri". I would have appreciate a bit more hand-holding use the ACME terminology of a new "identifier type" and the need for a new DTN specific "challenge type". > > BS: I will add a third paragraph in that section to explain the new ACME identifier and its rationale before using it. > ** Section 1. > This document also updates BPv7 to explicitly use the IANA >administrative record type registry in Section 6. > > Please explicitly cite a reference to BPv7 > > BS: Will do. > ** Section 1.2. > >When a ACME client requests a pre-authorization or an order with a >"uri" having one of the DTN Node ID schemes, the ACME server offers a >challenge type to validate that Node ID. > > As noted in section 1, please explicitly state that what a "uri" is - a new > ACME identifier type. I would recommend: > > When a ACME client requests a pre-authorization or an order with a "uri" > identifier type with a value being one of the DTN Node ID schemes, the ACME > server offers an "dtn-nodeid-01" challenge type to validate that Node ID. > > BS: Will do, this phrasing is more clear. > ** Figure 1. For clarity, it would be helpful to number the arrows between > nodes and also use the corresponding numbers in the narrative text. > > BS: I agree, will add ordinal number hints to each flow. > ** Section 1.4. Per the definition of "Challenge Bundle", shouldn't text > clarify that it's the BP agent of the ACME server? The Response Bundle > helpfully makes that distinction. > OLD > It is a Bundle created by the ACME > server to challenge a Node ID claim. > > NEW > It is a Bundle created by the BP agent managed by the ACME > server to challenge a Node ID claim. > > BS: Will clarify this. > ** Section 2. >Identifiers of type "uri" in certificate requests MUST appear in an >extensionRequest attribute [RFC2985] containing a subjectAltName >extension of type uniformResourceIdentifier having a value consistent >with the requirements of [RFC3986]. Because the >uniformResourceIdentifier is encoded as an IA5String it SHALL be >treated as being in the percent-encoded form of Section 2.1 of >[RFC3986]. > > Section 1 invokes the use of the PKIX profile [RFC5280]. The above described > guidance is only part of the constraints on using a SAN on the URI. Section > 4.2.1.6 of [RFC5280] covers the rest. > > BS: I will rephrase to specifically point to RFC5280 as a direct requirement here. > ** Section 3. >"token-chal" This token is unique to, and constant for, each ACME > authorization. > > This sentence reads to me as saying inconsistent things - "unique to ... each > ACME authorization" suggests that each authorization gets a different token. > "... and constant for each ACME authorization" seems to suggest is the same > token across all ACME authorizations. That doesn't seem right. > > BS: I added a statement to clarify unique-to-authorization vs. unique-to-challenge: Each authorization can consist of multiple Challenge Bundles (e.g. taking different routes), but they all share the same "token-chal" value. and also the the "token-bundle" paragraph explaining: This ensures that the Key Authorization is bound to the ability to receive the Challenge Bundle and not just have access to the ACME Challenge Object. > ** Section 3. Editorially. I found the validation process being described > as two separate lists of action, one for the client and one from the server, > instead of interleaving them hard to follow. However, I yield to the WG on > this one. > > BS: This was more due to taking existing ACME validation methods as examples than any other driving concern. I suspect that is because the client vs. server implementers have different communities of users. ** Section 3.3. >Source Node ID: The Source Node ID SHALL indicate the Node ID of the > ACME server performing the challenge. > > Is it the "Node ID of the ACME server" or the "Node ID of the BP agent of the > ACME server" > > BS: Yes, this is inaccurate and will be corrected. > ** Section 3.4. Typo. s/Each Each/Each/ > > ** Section 3.4. Typo. s/the the/the/ > > BS: Will fix both of these. > ** Section 3.4.1. > >* The Response Bundle was received within the time interval allowed > for the challenge. > > It would be helpful to state if this check based is based on the Creation > Time and Lifetime fields. > > BS: I will add explanatory text here and for the challenge bundle of: The allowed interval starts at the Creation Timestamp and
Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
Roman, Thank you for this thorough review. I want to address the more procedural/structural points first; the ones which have implications outside of just this document. > On the process side, this arrangement is rather unusual. No quarrels with the substance of the update which will improve extensibility. However, this particular document has experimental status and the document being updated (draft-ietf-dtn-bpbis) is proposed standard (PS). Having a lower maturity document updating one of higher status is my concern -- "experiments fail". Was this issue considered? Discussed with the DTN WG? I'll note that draft-ietf- dtn-bpbis has not yet been published (although it is in the late state of the RFCEd queue). Could the changes just be added there directly? BS: I did bring this up in the DTN WG earlier and the BPbis authors were fine with the update itself, which didn't require BPbis document changes, but I understand the concern about the different document status levels. I have brought this new concern up in the DTN WG with options of either a late AUTH48 edit or a separate small Proposed Standard document from the DTN WG. The change really is not specific to this ACME document but related only to this being the first new administrative record type for BPv7. > **I need a little help on DTN addressing. The text notes that that the intent is to issue certificates with DTN Node IDs as a URI in subjectAltName. > ... > Given the constraint of (c) and the flexibility afforded with the definition of a node ID in (a)+(b), will DTN Node IDs always satisfy the requirement from (c) to be FQDN? Is language needed to ensure that (likely in a few places in the document)? BS: This is a good catch regarding conformance to RFC 5280, and unfortunately represents a subtle logical conflict with this and another document [1]. Although Section 4.2.1.6 of RFC 5280 states this requirement about the URI authority part it makes no other use of this authority restriction, and although RFC 6125 does define a URI-ID which has matching logic based on the authority part the certificate profile shared by DTN TCPCLv4 [1] and this document explictly avoid using URI-ID in favor of the matching logic defined in [1] for NODE-ID. So while a "dtn" scheme URI contains an authority part which I believe meets the intent of the RFC 5280 restriction (a unique and unambiguous name/address) it does not meet the letter-of-the-law in that document. The dtn scheme is already in use and has been for many years; although it resembles a URN in semantics it does use a URL syntax which may be more of an historical accident than a design decision (as the "ipn" scheme does not use the URL authority syntax). Do you think that explicitly calling this out in this document and in [1] are an acceptable way to avoid this logical issue? Meaning any CSR or certificate handler for DTN must be aware to ignore that specific RFC 5280 requriement. I think all of your other comments are sensible and I will respond to them separately. Thank you, Brian S. [1] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26#section-4.4.2 smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Publication has been requested for draft-ietf-acme-dtnnodeid-04
Yoav, Is there anything needed in the near term to make progress on this document? I haven't seen any further comments since the WG last call has ended. Also, as an FYI the current draft is the result of review comments from the DTN WG and there are no outstanding issues from either WG. I am not going to be able to attend the IETF 111 ACME meeting, but also don't have anything new to report regarding the DTN Node ID Validation draft. Thanks, Brian S. Yoav Nir has requested publication of draft-ietf-acme-dtnnodeid-04 as Proposed Standard on behalf of the ACME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] RFC 8823 email-reply-00: How to concatenate the tokens?
Richard, >From my interpretation, the fact that the two token parts are base64url >strings is immaterial to the text-string concatenation into the ACME "token" >value. The Key Authorization calculation of RFC 8555 also does not care where >the token text came from or whether it is a base64url encoded text string. Also be careful about your assumptions about the tokens themselves. While RFC 8555 makes requirements about base64url encoded token values, RFC 8823 does not make any requirements about the content of the "token-part2" text value. The fact that the example looks like base64url encoding implies that, but I don't see any requirement on the token-part2 generation other than its minimum entropy. An RFC 8823 implementation could just as well use random ASCII, Latin-1, base16, or any other text; base64 just happens to produce more entropy-dense text. >From my reading, the RFC 8823 requirement text is sufficient to explain this >but having an example of the pre-digest Key Authorization value would be >helpful to clarify this. The example currently includes only the Key >Authorization digest but not the intermediate concatenated value. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] WGLC for ACME DTN Node ID
Yoav, This draft has also received a DTN WG review, and I have a new revision in progress. This new revision will also address a difference in behavior from the email S/MIME document that was brought up by Ryan Sleevi and explained by Ben Kaduk. That change does affect the data content by adding the challenge-unique token into the bundles with an explanation about its use. Once that new revision is posted I believe all comments to-date have been addressed. Thanks to Russ Housley and Ryan Sleevi for the reviews. Thanks to the authors for the revised version. This is not a great showing in terms of quantity of review, but the quality is sufficient. I will write the shepherd write-up and submit. Yoav ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] WGLC for ACME DTN Node ID
Ben, Thank you for the feedback. Given that this document is earlier in the stream, we still have opportunities to improve its encoded structure or properties. > My recollection from the email+S/MIME document (which is to be published as > an RFC imminently) is that the token-part2 was playing the role of a way to > bind the authorization to the specific ACME order. I also wanted to have a > unique identifier that binds the challenge email to the ACME order, and > that aspect changed a fair amount during the review process, but IIRC we > ended up with a bit of a fudge where the ACME exchange includes the "From:" > header field for the challenge email, and that could be unique to the order > but isn't required to be. Unfortunately in the case of bundles the source must be a fixed Node ID so we don't have the option of a similar challenge-specific address. Is there any value in having the ACME server use a unique-but-constant-per-order, and shown- to-the-client, value? Currently the distinguishing characteristic of is that it _only_ comes via bundle so knowing it means that you've seen the challenge bundle (which an on-path attacker can do equally as well) but this avoids the possibility of a response bundle being able to be produced before the challenge bundle is even received. Any value in a three-part nonce token (as recommended earlier, the names can be changed to reflect the use) as defined here? * Part 1 arrives only via challenge bundle, unique to that bundle (not just the order). * Part 2 arrives only via ACME HTTPS, unique to the order. * Part 3 is indicated in both the ACME HTTPS and the challenge bundle and provides a unique filter in the tuple of (Source Node ID, token-part3). This would be similar to the randomized email address. > That said, I have a (very vague, for which I apologize) recollection that > earlier in the evolution of the TCPCLv4 document there was an option where > certain TLS certificates would have an indication that the CA asserts that > the holder of the private key is trusted to provide its Node ID in the > TCPCL SESS_INIT even if the Node ID itself is not included in the > certificate. If that indication from the CA was the id-kp-bundleSecurity > EKU, then requiring ACME to always include that EKU in the issued > certificate would have surprising semantics. That said, it looks like in > at least the latest version of the TCPCLv4 draft, id-kp-bundleSecurity does > not play that role, so there is no issue. I'm only mentioning it now > because the potential scope of consequences is so large, and I am sure that > you will do the right thing (assuming I have been able to describe the > situation I'm worried about clearly enough). You are correct in your conclusion. The last recommended security policy (sent to the RFC editor) is to require a proper Node ID SAN and ignore any other SANs present. There is no recommended policy about implying the ownership/validity of a Node ID. smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] WGLC for ACME DTN Node ID
Ryan,
Thank you for the review comments. My responses are inline with prefix "[BS1]".
> With admittedly very little context for this specific use case, a few
> things stand out:
> Section 2 states "Any identifier of type "uri" in a newOrder request MUST
> NOT have a wildcard ("*") character in its value." This seems to
> unnecessarily constrain the character space. While I suspect the purpose
> was to exclude wildcards from the authority-part of a generic URI/specific
> to a particular scheme, it ends up defining the semantics for all URIs.
> Given URI's well-known ambiguity in representation across implementations,
> and the ability to do things like include pct-encoded characters in
> reg-name (it's only a must requirement, not a MUST requirement), this both
> seems unnecessarily restrictive and fails to achieve the goal, especially
> since such decoding to prevent this scenario, at the ACME server, is SHALL
> NOT'd by the same section.
> If the goal is to prevent wildcards that imply certain semantics for a
> given scheme (e.g. "dtn:"), then that probably deserves a separate section
> detailing the requirements for the extraction and validation of the Node ID
> from the URI, and can define any restrictions on the character namespace.
> Alternatively, since identifier labels are cheap, making the identifier
> type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
> to impose requirements specific to DTN URIs without risk of overfitting for
> other types of URIs.
[BS1] This was a copy-paste statement from ietf-acme-email-smime, and I agree
that this imposes unnecessary restrictions on the "uri" type. I will add
clarification that the URI must conform to any scheme-specific syntax.
It is actually the case that both "dtn" and "ipn" URI specifications [1]
restrict a Node ID to have a specific set of allowed characters (similar to
restrictions on DNS names). So a Node ID is a more restricted form of a generic
"dtn" or "ipn" URI, and I will add clarifying statements outside of the "uri"
type definition.
> Section 3 describes how this cribs from ietf-acme-email-smime, but provides
> no clear explanation as to the _why_, only the _how_. For example, the
> statement "requires that the ACME client have access to the results of each
> channel to get both parts of the token" describes a result, but does not
> describe the motivation that necessitates such a design. This seems like it
> might be relevant for security considerations, but documenting the
> rationale for this design seems relevant to successfully and securely
> implementing/extending this spec. This becomes equally relevant when
> attempting to understand why the choice of 128-bits of entropy within
> Section 3.1, since it seems the choice in the size of the parts is equally
> related to this undocumented threat.
[BS1] Yes, there is a missing "Threat: Bundle Replay" which applies to both
Challenge and Response bundles in similar ways. The "token-part2" is the unique
value for the whole ACME challenge and the "token-part1" is the unique value for
each bundle exchange. Having -part1 proves recepton of the Challenge Bundle (but
on-path attackers will also see this) and having -part2 proves access as the
ACME client (which will be hidden from OPAs).
Thinking through the logic a bit, I don't know if there is much value in -part2
since:
1. It's not part of the challenge bundle itself, so can't be used for on-path-
attack filtering.
2. It's used for the Key Authorization value alongside the client key
thumbprint, so there already is data binding the response to that ACME client.
3. The
Maybe Alexey (CC'd on this message) has some insight about the token splitting
for a messaging challenge (i.e. not a HTTP/TLS/DNS request-response exchange).
> In Section 3.1, I'm probably just not familiar enough with the underlying
> specs, but as far as I could tell, it's not clear why Step 3 the ACME
> client needs to indicate the to the BP agent, versus just the
> source. The source Node ID is clear, at least, but it seems like, at best,
> might just be serving as a "request ID" of sorts (judging by
> 3.4)
> The reason I highlight this is because I think it diverges from some of the
> classic assumptions about ACME and challenge design, because it seems to
> suggest that may transit the network in the clear and/or be
> held by multiple parties, which is a very different model than the history
> of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
> Token (which not simply a random value, but uniquely bound to the original
> request and is single-use). I *think* this might just be a terminology
> issue here, but would it make sense to name these according to their
> structural purpose, rather than just "token-part1" / "token-part2"?
[BS1] I agree that more purposeful names could help; the current ones were chose
only to follow in the steps of ietf-acme-email-smime draft.
The purpose of "token-part2" is in fact to be un
Re: [Acme] WGLC for ACME DTN Node ID
Russ,
Thank you for the review comments. My responses are inline with prefix "[BS1]".
> I think that this document is almost ready. I have a few comments.
> MAJOR:
> Section 4 points to Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]; but that profile
> does not require the certificate to
include an EKU of id-kp-bundleSecurity. When this document is used to verify
control over the DTN Node ID, I think the
issued certificate MUST include an EKU of id-kp-bundleSecurity. If other means
are used to validate other identities,
then other EKU values might be included as well.
[BS1] This seems reasonable to require. I suppose the "email-reply-00" document
[1] just leaves out any discussion of
EKU because the preexisting S/MIME documents define a more concrete certificate
profile and there is a lot of momentum
behind S/MIME implementation. I'm going to add statements about the EKU in the
CSR and the issued certificate.
> Section 4.2 is talking about S/MIME certificates. I think there is a
> cut-and-paste error here.
[BS1] Yes, these statements should replace "S/MIME" with "bundle security".
> MINOR:
> Section 3.1 says: "The only over-the-wire data required by ACME for a
> Challenge Bundle is a nonce token ...". This
is the first time that "nonce" appears in the document. Please reword.
[BS1] I removed this statement and replaced it with a statement about the
token-part2 scope:
The value included in this object is fixed for the entire
challenge, and may correspond with multiple
separate values when multiple Challenge Bundles are sent for a
single validation.
> Section 3.3 and 3.4: in the beginning of the section, please add a pointer to
> the document that defines these
parameters. I think it is draft-ietf-dtn-bpbis.
[BS1] That is the correct reference. I am adding a statement at the top of each
section.
> Section 6.1: please provide a reference for "BPSEC key material", and please
> spell out "BCB".
[BS1] I removed this speculative text and replaced it with:
It is possible for intermediate BP nodes to encapsulate-and-encrypt Challenge
and/or Response Bundles while they
traverse untrusted networks, but that is a DTN configuration matter outside of
the scope of this document.
> NITS:
> Section 1: please spell out BP on first use.
> Section 2: s/wildcard ("*") character/wildcard character ("*")/
> Section 6.2: please spell out "BIB".
[BS1] I am correcting all of these typos.
[1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-14
smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] ACME DTN Node ID validation update
All, Recently both the DTN drafts related to BPv7 (over which the Node ID validation is performed) and the ACME draft for email validation (from which the Node ID validation takes its workflow) have progressed to the RFC Editor's queue, which is great! I am updating the DTN Node ID validation from the last email-validation draft and including updated concrete examples. Because BPv7 uses CBOR and more easily supports bytestring encoding, the updated draft will use base64url encoding on ACME side but plain bytestring on the BP side to keep the encoding marginally smaller. ACME defines a canonical form so there should be no loss of information going either way and a concrete example should make this clear. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Adopting the DTN draft
Rich, I plan on submitting a slightly updated draft, including the WG name prefix, today. Thanks for the uptake and sorry for the delay in posting. From: Salz, Rich Sent: Friday, August 21, 2020 10:05 To: acme@ietf.org ; Brian Sipos Subject: Adopting the DTN draft There was little discussion of this draft on the mailing list. Notably Russ’s comments at https://mailarchive.ietf.org/arch/msg/acme/JiLHys9wikPgUL88FtFQgf6FeZE/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Facme%2FJiLHys9wikPgUL88FtFQgf6FeZE%2F&data=02%7C01%7CBSipos%40rkf-eng.com%7Cc99c8411e80f4bb074ff08d845db54be%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637336155615919231&sdata=GffvdVDxE133L3ApYMxYVSejjWZv9n3XztqPWAf8C5Q%3D&reserved=0> and https://mailarchive.ietf.org/arch/msg/acme/1YhEmxuI8gd5aZaL2ASq1DCDyGE/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Facme%2F1YhEmxuI8gd5aZaL2ASq1DCDyGE%2F&data=02%7C01%7CBSipos%40rkf-eng.com%7Cc99c8411e80f4bb074ff08d845db54be%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637336155615919231&sdata=a%2FldXa%2BynyS5%2B1ZCQr1vUjH2JJdTXtrSqf4hnhfDhHE%3D&reserved=0> So the consensus at the meeting is confirmed. Brian, please submit a new version of your document with the draft-ietf-acme- prefix. Thank you! ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME email validation
Sebastian, Thank you very much for this clarification. This would apply to all message exchange validation types then (including the one I'm looking into). I notice that the email validation draft does not mention multiple attempts from different sources, which RFC8555 does discuss briefly [1]. Is there an expectation that an email validation would be attempted from multiple ACME server addresses, or is a MITM attack on messaging not handled because of the nature of email security? [1] https://tools.ietf.org/html/rfc8555#section-10.2 From: Sebastian Nielsen Sent: Friday, June 19, 2020 13:25 To: Brian Sipos; acme@ietf.org Cc: alexey.melni...@isode.com Subject: SV: [Acme] ACME email validation The reason is to prevent email spoofing. In the case of .well-known or DNS validation, or ALPN, you publish a record where ACME fetches. That can’t be spoofed, because ACME itself searches for the record, you can’t send ACME a record and have it accept. In the email case, you instead send ACME the response back via email, which could be spoofed, if you had access to only the ACME client, if whole the token was given by ACME client. And in the second case, if whole token was given by email, it could be a private key that is being used for another thing – lets say signing internal certificates via HSM, where the signing system is misused to gain SMIME certificates by signing the token, without having access to the corresponding ACME client where the private key is installed. By requiring 2 parts of a token, you ensure the client has access to BOTH the email inbox AND the ACME client, AND the private key aswell. To ensure that the person replying to the email BOTH have access to the email account AND the ACME client, he must join 2 parts of a secure token, and then use his private key to calculate the value. Från: acme-boun...@ietf.org För Brian Sipos Skickat: den 19 juni 2020 00:13 Till: acme@ietf.org Kopia: alexey.melni...@isode.com Ämne: [Acme] ACME email validation All, In a recent draft I created for using ACME for non-web-PKI verification [1] I see that there are many similarities with an earlier draft for email verification [2]. In that email protocol, the challenge token is split into two parts which arrive at the email validation agent through two paths: token-part1 via the validation channel, and token-part2 via the ACME channel. Is there a technical reason why the token is split into two parts like this? Is replying with the proper corresponding Key Authorization not sufficient to prove ownership of the email address? I don't see any similar challenge token splitting in other ACME drafts and I don't see anything obvious in [2] to indicate why the split is useful or needed. I also didn't see any related discussion earlier on the ACME mailing list. Thank you, Brian S. [1] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-00 [2] https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-08 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] ACME email validation
All, In a recent draft I created for using ACME for non-web-PKI verification [1] I see that there are many similarities with an earlier draft for email verification [2]. In that email protocol, the challenge token is split into two parts which arrive at the email validation agent through two paths: token-part1 via the validation channel, and token-part2 via the ACME channel. Is there a technical reason why the token is split into two parts like this? Is replying with the proper corresponding Key Authorization not sufficient to prove ownership of the email address? I don't see any similar challenge token splitting in other ACME drafts and I don't see anything obvious in [2] to indicate why the split is useful or needed. I also didn't see any related discussion earlier on the ACME mailing list. Thank you, Brian S. [1] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-00 [2] https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-08 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
