From nobody Mon Feb 3 20:46:58 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5581200F9; Mon, 3 Feb 2020 20:46:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <158079161324.28459.3152118765068547136@ietfa.amsl.com> Date: Mon, 03 Feb 2020 20:46:53 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-22.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 04:46:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-22.txt Pages : 143 Date : 2020-02-03 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-22 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-22 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/ From nobody Mon Feb 3 20:50:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9A1200A3; Mon, 3 Feb 2020 20:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nwcpdE2RxkR; Mon, 3 Feb 2020 20:49:47 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC75F1200F9; Mon, 3 Feb 2020 20:49:42 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0FE6D54803E; Tue, 4 Feb 2020 05:49:34 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 068D6440059; Tue, 4 Feb 2020 05:49:34 +0100 (CET) Date: Tue, 4 Feb 2020 05:49:33 +0100 From: Toerless Eckert To: Benjamin Kaduk Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191230173030.GJ35479@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 04:49:54 -0000 Hi Benjamin Thanks a lot for the review, just committed -22 to answer to your review, providing separate diffs inline for the rfc822 vs IPsec parts to easier separate out the fixes for you. For everybody else, they can just do a diff -21 -> -22, which will also include the input changes to your review. inline.. On Mon, Dec 30, 2019 at 09:30:30AM -0800, Benjamin Kaduk wrote: > Inline (but reflecting the updated editor's copy)... [...rfc822name] > > Aka: At this stage, i would like to stick to the current rfc822address encoding. > > I think we did do a good amount of diligence for it in the WG, and > > existing coding seems to support our decision. > > > > So, i did not change any text for it in -21. > > While I can understand that this is an appealing approach, it still seems > to me that the list at the end of Section 6.1.2 reads more as a list of > reasons why it's convenient to use rfc822Name rather than a list of reasons > why it's the right thing to do. > > I have been thinking about this topic a > great deal, and consulted with several PKIX experts at IETF 106 during the > week, and got a universal sense that this usage is not an rfc822Name, and > instead is exactly the sort of thing that otherName is meant for. > > Accordingly, I'm going to continue to hold a Discuss for this point -- we > need to define how to build the ACP in a PKIX-compliant way. I can not have a technical defense against only "universal sense" of "not the right thing" from undisclosed experts, nor explain in the drafts text to implementers or the WG why a more complex option would be required to comply with PKIX. Pls. let me know the names of those PKIX experts so i can open up an email thread in which we can discuss what PKIX RFCs actually say about "right thing" and "PKIX compliant". I for once am persuaded that what we have choosen in the draft is not only PKIX compliant, but also "the right thing", because an rfc822name is a perfect identifier for the ACP of a node. To that extent i improved the explanations of 6.1.2 and hope that they now better argue that point and are more persuasive. Please see the following rfcdiff for this DISCUSS point: http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/5568de7b5adc206c9c148692f4688a1da28a1bcd/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/d4782f08d22be5ada206e6afb7e91def685d77e5/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt > That may not > preclude individual deployments that build an ACP in a PKIX-non-compliant > way (i.e., rfc822Name), and I could imagine some way to write text that > admits such a possibility while noting that it's not the right thing to do. Lets wait for the outcome of the above requested actual technical discussion. If the requirements raised in the new 6.1.2 explanations (especially single string representation of ACP domain information) are fulfilled by a different solution, then i don't think there would be a need for a separate non-preferred rfc822address option. > That said, my one Discuss point is not the end of the road for things; > since as I understand it the WG has already considered the topic > extensively, it may be time to check with the responsible AD about bringing > the document back on a telechat with, e.g., an alternate ballot procedure > ("single-discuss" or the full-on "alternate procedure" from > https://ietf.org/standards/process/iesg-ballots/). I don't remember > hearing much from any other IESG members on this topic, at least as of yet. Not quite sure i follow everything you say: My understanding is that E'ric is now the responsible AD for the document, so we authors will simply follow his guidance for any further necessary AD review . Given how we already had a lot of exhaustive and good reviews and resulting fixes, i hope the poor ADs will not be forced to repeat potentialy unnecessary work on such a big document given how the fixes are all well documented and also summarized now in the changelog (summarizing IESG review up to -21 and explaining that there are no fundamental changes just a good amount of detail fixes and textual improvements). But this is my first RFC as big as this, so i have no prior good experience with the process in a case like this. > > 2. Missing crypto parameters. [...] > In Singapore I managed to strong-arm Valery Smyslov into taking a look, and > I digested his comments into a pull request at > https://github.com/anima-wg/autonomic-control-plane/pull/9 . Note that I > marked it as "WIP", as Valery's preferences are to defer to the existing > usage guidelines RFCs as much as possible, so that we don't need to say > anything at all about several of the parameters. I also wanted to check > one last time that the goal is still to go for the 256-bit security level > across the board, as a couple things might get tweaked otherwise. Thanks a lot for the proposed crypto text changes. I first included your pull request. Here is the rfcdiff for others on this mail thread: http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/d4782f08d22be5ada206e6afb7e91def685d77e5/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/667f5cc13cd7a576023467c1a4d3462369287063/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Then i tried to make as small as possible changes, just to improve readability. Alas, the changes became somewhat larger because of some of discuss mcr had in github and you had in your XML comments (additional encrypt option) and to also answer what you referred to as Valery's concern of minimizing changes to existing requirements standards (8221/8247), or at least be more precise about them. I hope i resolved those concerns, so if you're fine with them maybe we can run it by Valery and make him more happy with this version. http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/667f5cc13cd7a576023467c1a4d3462369287063/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-22.txt Possible gap: I am not 100% sure that either the text you had or the revisited text from me does sufficiently well exclude the ability to implement weak crypto beside the excluded NO_CRYPTO option. I am fairly confident with rfc8221, there is only a "SHOULD NOT" open for 3DES, and thats i think fine. For RFC8247 i am not so sure, but not sure what simple sentence would close that gap. Minimum key size for part of IKEv2 ? Here is the list of changes in changes (see diff), also in changelog: 6.1 - Added explanation of why manual keying for ACP is not feasible for ACP. Surprisingly, that text did not exist. Referred to by IPsec text (6.7.1), but here is the right place to describe the reasoning. 6.1.2 - Small textual refinement referring to requirements to authenticate peers (for the special cases of empty or '0' ACP address in ACP domain information field. 6.3 - To better justify Bens proposed change of secure channel protocol being IPsec vs. GRASP objective being IKEv2, better explained how protocol indicated in GRASP objective-value is name of protocol used to negotiate secure channel, use example of IKEv2 to negotiate IPsec. 6.7.1 - refinemenet similar to 6.3. - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 as it equally applies to GRE encapped IPsec (looks nicer one level up). - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to clearer distinguish between these two requirements blocks - Refined the text in these two sections to hopefully be a good answer to Valery's concern of not randomnly mocking with existing requirements docs (rfc8247 / rfc8221). 6.7.1.1.1 - IPsec/ESP requirements section: - MUST support rfc8221 mandatory EXCEPT for the superceeding requirements in this section. Previously, this was not quite clear from the text. - Hopefully persuasive explanations about the requirements levels for ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC (was in prior version, just not well structured), added new expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, ENCR_CHACHACHA are SHOULD when they are implementable with rqual or faster performancce than ENCR_AES_GCM_16. - Removed text about "additional rfc8221" reqiurements MAY be used. Now the logic is that all other requirements apply. 6.7.1.1.2 - RFC8247 requirements - Added mandate to support rfc8247, added explanation that there is no "stripping down" requirement, just additional stronger requirements to mandate correct use of ACP certificartes during authentication. - refined text on identifying ACP by IPv6 address to be clearer: Identifying in the context of IKEv2 and cases for '0' in ACP domain information. - removed last two paragraphs about relationship to rfc8247, as his is now written in first paragraph of the section. > > 3. RPL root provisions for logging unknown destinations > > Just to be concrete, the updated text does address my last discuss point -- > thanks! Great. > Sorry again for the delay -- I really needed some time to try to digest the > rfc822Name topic. Sure. Still need to resolve that. I still hope i can persuade you and the other experts through the now better justifications in the text that rfc822 addresses are becoming more ubiquitous and simpler identifiers than the 'good-ol' X.500 subject identifier fields, so why not use that for devices too. Hope we can get an email thread going for that. Cheers Toerless > > -Ben > > > Appended below our last exchange. > > > > On Tue, Jul 23, 2019 at 01:22:43AM +0200, Toerless Eckert wrote: > > > --- Context: > > > > > > I hope i am correctly restating, that this reply is as follows: > > > -> After finishing second round of replies for -16, Ben Kaduk provided a reply > > > that is now also his new DISCUS position on datsatracker. this is my reply > > > to that DISCUS. > > > > > > -> The diff for the changes discussed in this email is: > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt > > > They are also summarized under section (3) of the -20 changelog. > > > > > > -> The total changes -19 to -20 are of course: > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt > > > > > > > > > On Tue, Jul 16, 2019 at 03:54:42PM -0700, Benjamin Kaduk via Datatracker wrote: > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-anima-autonomic-control-plane-19: Discuss > > > > > > 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-anima-autonomic-control-plane/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > [trimming to just the topics still under discussion; no change to the > > > text of the remaining items even though some changes have been made > > > to the document] > > > > > > I think there needs to be some justification of why rfc822Name is chosen > > > over a more conventional structure in the otherName portion of the > > > subjectAltName, which is explicitly designed to be extensible. > > > > Let me but the compromise proposal and conditions on top: > > > > Compromise proposal (not integrated into current text yet): > > > > The document defines a new otherName like ACPdomainIdentity, type IA5String > > > > I can figure out how to write the the necessary formal text for this, > > stealing from e.g.: rfc8398 or the like (asking for IANA registration etc..) > > i will whine for help (from you) when i fail with that text formalisms/ASN1. stuff. > > > > The encoding of the string is the existing domain-information > > > > The length limitation of 64 for the local part is lifted (yeah). > > > > The rest of the text (justification for formatting etc.) is appropriately > > fixed up. I will remove all the text suggesting this could be an actual > > rfc822 address and just escribe it in terms of below reasoning (nice format > > to express domain based identities "local+policies@domain" or the like. > > > > Condition: > > > > Sufficient support in WG (tomorrow meeting) wrt. the following key aspects: > > -> Belief that even the most stupid existing libraries to > > deparse certificates can give access to this information without rev'ing > > such libraries (we assume this is true for rfc822Name). > > -> Ability of a good amount of existing diagnostics tools to actually > > display the string content as a string, even when it obviously doesn't know > > what type the otherName is. > > This is based on my hope that i correctly understand BER/DER to be self > > identifying, so deparser would know the element is string, but thats's what > > i am not sure about. > > > > Reasons: > > - We need both a human readable and in-cmputer representation of the information. > > I really don't see enough reason to have two different ones, and i really > > don't want to write to structure defintions. So i think the existing > > ABNF string is nice for both purposes. This info will go into all type > > of backend systems, inventory tracking etc.. deparsing specifically formatted > > strings is quite common there. > > > > - The domain-information is really the non-cryptographic part of the ACP device > > identity. and the local@domain part is an established way to represent this, > > so its hopefully "nice" too - e.g.: i woldn't know a more appropriate > > format. > > > > > In a few places, the MTI cryptographic mechanisms are under-specified, > > > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > > > to note these locations in my section-by-section comments. > > > > Right. > > a) I couldn't find good references for certificate requirements. > > The IPsec/IKEv2 reference STANDARDS RFCs lamely said something like > > "problem for the PKIX community". > > > > (seems like a gapipng big interop hope for those protocols if it doesn't exist). > > > > b) I am confused about TLS parameters needed beside what i wrote in latest > > update. See nit discuss below. > > > > > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > > > root, but if I understand correctly the RPL root is automatically > > > determined within the ACP, and thus the operator does not a priori know > > > which node will become the RPL root. Am I misunderstanding, or is this > > > effectively placing this requirement on all ACP nodes? > > > > Fixed by adding an option to not ask for this diagnostics to lowest-end > > nodes least in line to become root. When one of those nodes becomes > > root, the network is already in a worst degraded state, so this advanced > > diagnostics is then likely the least of problems. > > > > Details in reply to original -16 review answer you sent. > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Thank you for adding the implementation experience note to the shepherd > > > writeup; it is helpful to understand the maturity level of the document. > > > > > > The comments here are probably best understood in the context of my > > > previous ballot position, specifically with respect to certain topics > > > being "speculative" or a matter for "future work". > > > > > > One somewhat general comment that occurred to me on the reread is that > > > by encoding the ACP address into a node's LDevID, we are on the face of > > > things locking it into a given addressing model, though in practice it > > > should be fairly straightforward to issue a new certificate through > > > regular update/renewal mechanisms. I forget if we have discussion of > > > this non-issue already. > > > > Readdressing is possible, but the address is really the non-security > > part of the identity of an ACP node (security part is key-pair), so all > > the ACP text talks about trying to maintain it whenever possible (discussed > > in the text for example in the face of change of registrars, so the originally > > assigning registrar is gone). > > > > There is really nothing breaking in the ACP when ACP nodes change their > > addresses, but typically the short-term adoptions of ACP into non-fully > > autonomic environments would love to see persistent addresses, because thats > > what they do today: > > > > Operators have used IP addresses as ideally never-changing network services > > identifiers of nodes for decades (loopback addresses). Thats just what > > we do with ACP, and the assignment via certificate is an elegant way to solve the > > current manual problem of network wide unique assignment, it just gets a > > bit complicated under the hood in above mentioned cases (registrar change > > during cert renewal). > > > > The use of well-defined address plans standardized in the ACP document is also > > something that effectively just automates operational practices and keeps > > deployment specific options at a minimum. > > > > > Section 1 > > > > > > Combining ACP with Bootstrapping Remote Secure Key Infrastructures > > > (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the > > > "Autonomic Network Infrastructure" as defined in > > > [I-D.ietf-anima-reference-model], which provides autonomic > > > connectivity (from ACP) with fully secure zero-touch (automated) > > > bootstrap from BRSKI. The ANI itself does not constitute an > > > > > > nit: It's unclear that there's universal agreement about what "fully > > > secure" might mean, so I'd suggest just using "secure". > > > > Done. > > > > > Section 2 > > > > > > ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate > > > (LDevID) carrying the domain information field which is used by > > > > > > nit: I think the reference is for "certificate", not "provisioned". > > > > > > ACP secure channel: A cryptographically authenticated and encrypted > > > data connection established between (normally) adjacent ACP nodes > > > to carry traffic of the ACP VRF secure and isolated from Data- > > > Plane traffic in-band over the same link/path as the Data-Plane. > > > > > > nit: I'm not sure if "secure" or "securely" is better (but what does > > > "secure from" mean?) > > > > securely sounds find. fixed. > > I think its read ... "secure(ly)" and "isolated from". > > > > > > Enrollment: The process where a node presents identification (for > > > example through keying material such as the private key of an > > > IDevID) to a network and acquires a network specific identity and > > > trust anchor such as an LDevID. > > > > > > nit: the LDevID is the identity; it's not a trust anchor. > > > > Fixed to: > > > > network specific identity such as an LDevID and trust anchors such as Certificate Authority (CA) certificate. > > > > > Section 5 > > > > > > 3. For each node in the candidate peer list, it authenticates that > > > node (according to Section 6.1.2) and negotiates a mutually > > > acceptable channel type. > > > > > > 4. For each node in the candidate peer list, it then establishes a > > > secure tunnel of the negotiated type. The resulting tunnels are > > > then placed into the previously set up VRF. This creates an > > > overlay network with hop-by-hop tunnels. > > > > > > nit: the "channel type" of (3) is the "negotiated type" of the "secure > > > tunnel" in (4), right? It might be nice to use the same word in > > > both items, to help tie the language together. > > > > Changed to "negotiated channel type in 4". > > > > > Section 6 > > > > > > nit: "must have it's ACP domain certificate" gained an apostrophe in "it's" > > > but the original "its" was correct. > > > > fixed. > > > > > Section 6.1 > > > > > > members. The LDevID is used to cryptographically authenticate the > > > membership of its owner node in the ACP domain to other ACP domain > > > members, the TA is used to authenticate the ACP domain membership of > > > other nodes (see Section 6.1.2). > > > > > > nit: comma splice > > > > fixed (two sentences). > > > > > The ACP does not mandate specific mechanisms by which this keying > > > material is provisioned into the ACP node, it only requires the > > > Domain information field as specified in Section 6.1.1 in its domain > > > certificate as well as those of candidate ACP peers. See > > > > > > nit: comma splice > > > > fixed (two sentences). > > > > > The ACP domain certificate SHOULD be used for any authentication > > > between nodes with ACP domain certificates (ACP nodes and NOC nodes) > > > where the required condition is ACP domain membership, such as ACP > > > > > > nit(?) I'd suggest s/required condition/required authorization > > > condition/ > > > > fixed. > > > > > Section 6.1.1 > > > > > > The ABNF in Figure 2 seems to have multiple what I'll call for lack of a > > > better term "terminal constructions" (i.e., routing-subdomain and > > > domain-information) that are not used in other rules. Some text on > > > which one is used in the rfc822Name and which is just informational for > > > other purposes is probably in order. > > > > Added below figure: > > > > domain-information is the encoded information that is put into the ACP domain certificates subjectAltName / rfc822Name field. routing-subdomain is a string that can be constructed from the domain-information, and it is used in the hash-creation of the ULA (see below). The requirements and sementics of the parts of this information are explained in the following paragraphs: > > > > I think there are no more terminal name than those two. > > > > > o The maximum size of "domain-information" is 254 characters and the > > > maximum size of node-info is 64 characters according to [RFC5280] > > > that is referring to [RFC2821] (superseded by [RFC5321]). > > > > > > nit: I don't think we refer to node-info anywhere. > > > > s/node-info/local-part/ > > > > > On the topic of rfc822Name vs. otherName, I note that there's no > > > requirement to use ASN.1 for the internal structure of the value; it's > > > perfectly acceptable to make it an OCTET STRING and shove a > > > more-friendly data structure in there. (It's a little bit weird in > > > terms of mental models, but funny looks aside, it's pretty common.) If > > > the other structure is fixed-length, there is not any actual ASN.1 > > > knowledge required by the recipient; they just check that the length is > > > right and the data starts with the correct fixed prefix (corresponding > > > to the OID and ASN.1 length encoding), before processing the encoded > > > data in whatever manner is appropriate. Since we want to put domain > > > names in, fixed-length is probably out of the figure, but even if we're > > > limited to what openssl provides, getting an ASN1_OCTET_STRING and > > > extracting its contents to a pointer+length is pretty well established; > > > we don't need to make people learn about ASN1_SEQUENCE() at all. So you > > > could have the fundamental structure of the otherName be something like: > > > > > > 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +---------------------------------------------------------------+ > > > | Flags |M|A| > > > +---------------------------------------------------------------+ > > > | | > > > + + > > > | | > > > + [acp-address] + > > > | | > > > + + > > > | | > > > +---------------------------------------------------------------+ > > > | rsub-len | rsub... | > > > +------------------------------+ + > > > ~ ~ > > > +---------------------------------------------------------------+ > > > | acp-domain-len | acp-domain... | > > > +------------------------------+ + > > > ~ ~ > > > +---------------------------------------------------------------+ > > > | [TLV extensions] | > > > +---------------------------------------------------------------+ > > > > > > where M means that the holder of the cert is allowed to establish an ACP > > > secure channel (what the '0' acp-address does in the present > > > formulation) and A means that the acp-address field is present > > > > > > and just pack that into an OCTET STRING. > > > > > > Is the rfcSELF@acp.example.com email address for human use really > > > providing much value? This is pretty clearly breaking an abstraction > > > barrier, from my point of view. > > > > See above at the DISCUSS for my list of reasons to go with the rfc822name > > encoding. Compared to your (more efficient) encoding, its specifically > > about diagnostics and the ability for any existing certificarte tool to > > correctly display a string for an existing field (rfc822name). What would > > a randomn existing tool show a human for your field ? could i easily > > copy & paste it, could i easily have a script put it into a list, > > copy into excel spreadsheet (annoyingly enough we still live in a world > > where we need to deal with humans and their preferences. We're trying to minize > > what humans need to manage in ANIMA/ACP, but this is exactly the pieces they > > will need to deal with whenever they troubleshoot). > > > > We wouldn't only have to redo the whole encoding into the certificate > > as you proposed, but also come up with recommended standard representations for humans > > to make it easy to operate across all type of tool chains where humans > > are involved. Which could be the rfc822 representation because its > > kinda nicely human logical ("node+tags@domain"...). > > > > > It also makes acp-domain-name a valid e-mail target across all > > > routing-subdomains. > > > > > > nit: rfcSELF@acp-domain-name > > > > actually "domain-information", fixed. > > > > > o It should be possible to share the LDevID with other uses beside > > > the ACP. Therefore, the information element required for the ACP > > > should be encoded so that it minimizes the possibility of creating > > > incompatibilities with such other uses. > > > > > > otherName with an ACP-specific OID has zero possibility of collisions > > > with other uses; reusing rfc822Name has nonzero possibility of > > > collision. (Note that having multiple otherNames is allowed.) > > > > Q1: Who allocates the OID ? > > Q2: Could we put the currently domain-information into the otherName as a string ? > > Q3: Would existing tools that deparse certificates human readable display > > OtherNames that are string type (with e.g.: BER) ? > > > > > o The information for the ACP should not cause incompatibilities > > > with any pre-existing ASN.1 software. This eliminates the > > > introduction of a novel information element because that could > > > require extensions to such pre-existing ASN.1 parsers. > > > > > > Even getting to the rfc822Name requires some level of ASN.1 parsing, so > > > it's unclear how strong this argument really is. > > > > From what we discussed in the WG, all ASN.1 parsers people knew would > > already be able to parse those defined fields, especially rfc822Name > > > > > > > > o The element required for the ACP should not be misinterpreted by > > > any other uses of the LDevID. If the element used for the ACP is > > > interpreted by other uses, the impact should be benign. > > > > > > [OIDs are by construction unique] > > > > See Q1. > > > > > o At minimum, both the AN domain name and the non-domain name > > > derived part of the ACP address need to be encoded in one or more > > > appropriate fields of the certificate, so there are not many > > > alternatives with pre-existing fields where the only possible > > > conflicts would likely be beneficial. > > > > > > It's even possible to define multiple OIDs for otherName use, one for > > > acp-domain-name, one for rsub, etc.. But that feels kind of like > > > overkill to me. > > > > See above. I am a lot more partial to keep a easily human readable string > > representation of the information than using rfc822Name. And i do not really > > want to bother about two representations (human vs. machine) in this case. > > > > Not using rfc822Name would also give the ability to define a longer limit for > > local-part which is my biggest worry when we're talking future extensions. > > > > > Section 6.1.2 > > > > > > 3: The peer's certificate passes certificate path validation as > > > defined in [RFC5280] against one of the Trust Anchors associated > > > with the ACP nodes ACP domain certificate (see Section 6.1.3 > > > below). > > > > > > nit: "node's" possessive > > > > Fixed. > > > > > 4: If the node certificate indicates a Certificate Revocation List > > > (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or > > > Online Certificate Status Protocol (OCSP) responder ([RFC5280], > > > section 4.2.2.1), then the peer's certificate must be valid > > > according to those criteria: An OCSP check for the peer's > > > certificate across the ACP must succeed or the peer certificate > > > must not be listed in the CRL retrieved from the CDP. [...] > > > > > > side note: we could (but don't have to) note that OCSP stapling is a > > > way to get an OCSP response to check. > > > > Right. thats why i fixed the text already via feedback to i think your first > > round by adding that this only applies when the security association protocol > > is incapable to carry the CDP/OCSP information itself. > > > > > 5: The peer's certificate has a syntactically valid ACP domain > > > information field (encoded as subjectAltName / rfc822Name) and the > > > acp-domain-name in that peer's domain information field is the > > > same as in this ACP node's certificate (lowercase normalized). > > > > > > (Writing this as "has an otherName subjectAltName using the ACP OID" > > > seems more concise to me, but I'll try to stop beating that horse.) > > > > ;-) Let me understand your answers to Q1...Q3 and also tell me what you > > think about keeping the string ("looks like an email identity") enoding > > but using your suggested field. > > > > > When an ACP node learns later via OCSP/CRL that an ACP peers > > > certificate for which rule 4 had to be skipped during ACP secure > > > channel establishment is invalid, then the ACP secure channel to that > > > peer SHOULD be closed even if this peer is the only connectivity to > > > access CRL/OCSP. The ACP secure channel connection MUST be retried > > > periodically to support the case that the neighbor aquires a new, > > > valid certificate. > > > > > > nit: we could probably tighten up the writing here about "MUST be > > > retried periodically" in terms of needing to reestablish the TLS > > > connection provisionally and repeat the initial connection steps, though > > > on second read the current text seems better than I thought on first read. > > > > I will not take action against this comment as i am not clear what > > the suggestion exactly is. Do you want me to try to cut the first sentence > > into multiple smaller ones to make sound less like a german hold hostage by > > the english language (or vice versa). > > > > > Only when checking a candidate peer's certificate for the purpose of > > > establishing an ACP secure channel, one additional check is > > > performed: > > > > > > nit: I'd suggest s/Only when/When/ > > > > Done. > > > > > Formally, the ACP domain membership check includes both the > > > authentication of the peers certificate (steps 1...4) and a check > > > authorizing this node and the peer to establish an ACP connection > > > and/or any other secure connection across ACP or data-plane end to > > > end. Step 5 authorizes to build any non-ACP secure connection > > > between members of the same ACP domain, step 5 and 6 are required to > > > build an ACP secure channel. For brevity, the remainder of this > > > document refers to this process only as authentication instead of as > > > authentication and authorization. > > > > > > I'd prefer to see a penultimate sentence along the lines of "Other > > > authorization models are possible by local policy, but for this > > > specification (and to some extent, autonomic systems in general), domain > > > membership is deemed sufficient authorization for all operations." > > > > "_local_ policy" is in general a big no-no for us except where we can't avoid it, > > so i better don't say "local" this without good reason. > > > > I also don't find this section specifically talking about ACP Domain membership > > check the right place to say this. > > > > I did ad the following paragraph to the new section 6.1.1 about ACP domain certificates: > > > > Note that is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with future requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. For example, see . > > > > Aka: that example in the appendix already is explaining our recognition > > that for higher layers at least roles seem to be clearly needed to create > > better security. Indeed the flag in the certificate for an EST server is > > really just a speific example of such a role. Except that it seems to be > > called "extended certificate usage" instead of role ;-). > > > > > Section 6.1.3 > > > > > > A certificate path is a chain of certificates starting at a self- > > > signed certificate of a so called root-CA or Trust Anchor, followed > > > > > > nit(?): I'm used to seeing chain construction start at the > > > leaf/end-entity and chain up to the root, but to some extent this is an > > > editorial question. > > > > In routing and biology, trees start at the root, so pls. excuse my ignorance ;-) > > > > fixed to: > > > > A certificate path is a chain of certificates starting at > > the ACP certificate (leaf/end-entity) followed by zero or more > > intermediate Trust Point or sub-CA certificates and ending with > > a self-signed certificate of a so called root-CA or Trust Anchor. > > > > > A single owner can operate multiple independent ACP domains from the > > > same set of private trust anchors (CAs) when the ACP Registrars are > > > trusted not to permit certificates with incorrect ACP information > > > fields to be signed. Such as ACP information with a wrong acp-domain > > > field. [...] > > > > > > nit: This last sentence is a sentence fragment (I suggest joining it to > > > the previous one with a comma). > > > > Done. > > > > > Section 6.1.4 > > > > > > with its ACP domain certificate. When BRSKI (see > > > [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of > > > the BRSKI registrar from the BRSKI TLS connection SHOULD be > > > remembered and used for the next renewal via EST if that registrar > > > also announces itself as an EST server via GRASP (see next section) > > > on its ACP address. > > > > > > IIUC, the BRSKI spec currently advertises BRSKI registrars with the > > > EST-TLS objective, and I don't really understand how this interacts with > > > SRV.est or whether this text should change. > > > > The equivalent to the SRV.est announcement is actually in BRSKI the > > AN_join_registrar announcement. A registrar that does both BRSKI (initial > > enrollment) and renewal (EST propoer) would send both announcements. > > I think this text is fine. > > > > > Section 6.1.4.1 > > > > > > The objective name "SRV.est" indicates that the objective is an > > > [RFC7030] compliant EST server because "est" is an [RFC6335] > > > registered service name for [RFC7030]. Objective-value MUST be > > > ignored if present. Backward compatible extensions to [RFC7030] MAY > > > be indicated through objective-value. Non [RFC7030] compatible > > > certificate renewal options MUST use a different objective-name. > > > > > > I'd consider adding some text about ignoring unrecognized > > > objective-values, to attempt to preserve the usability of this extension > > > point. > > > > Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored. > > > > > Section 6.1.4.3 > > > > > > The ACP node SHOULD support Certificate Revocation Lists (CRL) via > > > HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) > > > > > > My understanding is that HTTP-not-s is commonly used for CRL > > > distribution since the CRL content itself is signed, and there would be > > > a risk of a circular dependency in validating the server's TLS > > > certificate to get to the CRL information. > > > > Fixed. > > > > > HTTPs connections. The connecting ACP node SHOULD verify that the > > > CDP certificate used during the HTTPs connection has the same ACP > > > address as indicated in the CDP URL of the nodes ACP domain > > > certificate if the CDP URL uses an IPv6 address. > > > > > > nit: "node's" possessive. > > > > fixed. > > > > > Section 6.1.4.5 > > > > > > enrollment. Using the ACP node's domain certificate allows the BRSKI > > > registrar to learn that nodes ACP domain information field, so that > > > > > > nit: "node's" possessive. > > > > fixed > > > > > with its old ACP certificate. The re-enrolling candidate ACP node > > > SHOULD only request a voucher from the BRSKI registrar when this > > > authentication fails during TLS connection setup. > > > > > > I might suggest "SHOULD only fall back to requesting a voucher". > > > > fixed. > > > > > Section 6.1.4.6 > > > > > > An ACP domain certificate is called failing in this document, if/when > > > the ACP node can determine that it was revoked (or explicitly not > > > renewed), or in the absence of such explicit local diagnostics, when > > > the ACP node fails to connect to other ACP nodes in the same ACP > > > domain using its ACP certificate. For connection failures to > > > > > > nit: maybe "the ACP node to which the certificate was issued", since > > > when I first read this I was expecting it to be about telling that some > > > other node's certificate is failing, not a node's own certificate. > > > > fixed. > > > > > Section 6.5 > > > > > > At this time in the lifecycle of ACP nodes, it is unclear whether it > > > is feasible to even decide on a single MTI (mandatory to implement) > > > security association protocol across all ACP nodes. > > > (This is a future-looking statement that implies uncertainty in the > > > current spec.) > > > > Yikes. How did this sentence survive so long. > > With all the other places pounding on the key thing > > being to not mandate a single network wide MTI because there is sufficient > > insight that it would be way too limiting. > > > > removed. Thanks a lot. > > > > > [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, > > > therefore Node 1 considers itself Bob and Node 2 Alice > > > on connection C1, but they also identify that C2 is to the > > > > > > I think this first "Node 2" should be "Node 1"? > > > > Fixed. > > > > > interface" that they both connect to. An autonomic node must not > > > assume that neighbors with the same L2 or link-local IPv6 addresses > > > on different L2 interfaces are the same node. This can only be > > > determined after examining the certificate after a successful > > > security association attempt. > > > > > > This could potentially be a "MUST NOT". > > > > fixed. > > > > > Section 6.7.1.1 > > > > > > To run ACP via IPsec natively, no further IANA assignments/ > > > definitions are required. An ACP node that is supporting native > > > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and > > > peer link-local IPv6 addresses used for encapsulation. It MUST then > > > support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 > > > hash and MUST NOT permit weaker crypto options. Key establishment > > > MUST support ECDHE with P-256. > > > > > > I don't think "SHA256 hash" is quite specific enough (and we probably > > > want GMAC for integrity anyway). > > > > In the answer to your i already changed this text to ENCR_AES_GCM_16. > > The way i understand it (pls. help me if i am wrong), it comes with its > > own integrity protection mechanism. Pls. check new text in 6.7.1.1 > > > > > Section 6.7.1.2 > > > > > > To run ACP via GRE/IPsec, no further IANA assignments/definitions are > > > required. An ACP node that is supporting ACP via GRE/IPsec MUST then > > > support IPsec security setup via IKEv2, IPsec transport mode, local > > > and peer link-local IPv6 addresses used for encapsulation, ESP with > > > AES256 encryption and SHA256 hash. > > > > > > Why is IPsec/GRE using AES256/SHA256 when IPsec native is using > > > AES256-GCM? > > > > Error in duplication. New text from your and erics review > > removes all duplication and has GRE just > > refer to the native requirements and only explain changes. > > > > > Section 6.7.2 > > > > > > We define the use of ACP via DTLS in the assumption that it is likely > > > the first transport encryption code basis supported in some classes > > > of constrained devices. > > > > > > nit: I don't think "basis" is quite the right word, here; maybe "base" > > > (or collapsed back to "codebase" as one word) or omit it entirely. > > > > deleted term. > > > > > Section 6.7.3 > > > > > > support DTLS. An ACP node connecting an area of constrained ACP > > > nodes with an area of baseline ACP nodes MUST therefore support IPsec > > > and DTLS and supports therefore the baseline and constrained profile. > > > > > > nit: this could probably work just fine as a non-normative "must", since > > > it's just describing facts. > > > > fixed. > > > > > Section 6.8.2 > > > > > > nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces" > > > in the second box from the top. > > > > > fixed > > > > > ............................................................... > > > . | | | ^^^ Users of ACP (GRASP/ASA) . > > > . | | | ACP interfaces/addressing . > > > . | | | . > > > . | | | A > > > . | ACP-Loopback Interf.| <- ACP Loopback interface C > > > . | ACP-address | - address (global ULA) P > > > . subnet1 | subnet2 <- ACP virtual interfaces . > > > . link-local | link-local - link-local addresses . > > > ............................................................... > > > > > > I'm still a bit confused by this box in the figure -- is the "Users of > > > ACP" label supposed to apply to the previous box(es) or the current one? > > > If the former, it's confusing to see the "ACP security and transport > > > substrate for GRASP" being described as a "user of ACP". > > > > Changed to "Users of ACP interfaces". > > > > Alas i have no more lines without breaking the picture onto multiple > > pages in RFC TXT so i can not well try to carve out better space to > > show where ASA sit (difficult as they would use both ACP interfaces > > as well as some GRASP API. > > > > > GRASP unicast messages inside the ACP always use the ACP address. > > > Link-local addresses from the ACP VRF must not be used inside > > > objectives. GRASP unicast messages inside the ACP are transported > > > via TLS 1.2 ([RFC5246]) connections with AES256 encryption and > > > SHA256. Mutual authentication uses the ACP domain membership check > > > defined in (Section 6.1.2). > > > > > > Just "AES256 encryption and SHA256" describes quite a few TLS > > > ciphersuites > > > (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4); > > > I'd suggest limiting to a specific handful like > > > > > "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > > > > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and > > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" > > > > > (the "Recommended" column in > the registry will be helpful at picking things). > > > It's probably also useful to specify a RSA/ECDSA key size (and elliptic > > > curve for ECDSA) and the nature of the ECDHE or DHE. > > > > Can you please suggest recommended text here ? I spent a lot of reading > > up on the whole IPsec/channel level especially also because you indicated > > we would need other folks to help on IPsec, but i figure you would be > > a good person to ask for TLS. > > > > Given how this is all new code, i see no reason to have mor than one MTI, > > its also easy to override at application level (this would ahppen for > > application scoped GRASP TLS connections). > > > > How about mandating LS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > > > I have no idea how ECDHE are intermixed with RSA here, and what key sizes > > we talk about - i hope the one from the cert, but the cert would only hae > > one type of public key, ECDHE or RSA, right ? > > > > > Section 6.8.2.1 > > > > > > If GRASP peer connections would just use TCP, compromised ACP members > > > could simply eavesdrop passively on GRASP peer connections for whom > > > they are on-path ("Man In The Middle" - MITM). Or intercept and > > > > > > nit: I'd suggest "were to use just TCP". > > > > fixed. > > > > > modify them. With TLS, it is not possible to completely eliminate > > > > > > nit: sentence fragment > > > > merged with prior sentence. > > > > > > Section 6.10 > > > > > > Links inside the ACP only use link-local IPv6 addressing, such that > > > each nodes ACP only requires one routable virtual address. > > > > > > nit: "node's" possessive. > > > > fixed. > > > > > Section 6.10.2 > > > > > > o Establishing connectivity between different ACP (different acp- > > > domain-name) is outside the scope of this specification. If it is > > > being done through future extensions, then the rsub of all > > > routing-subdomains across those autonomic networks need to be > > > selected so their hashes do not collide. For example a large > > > > > > nit: the grammar could be more clear that it's hash(routing-subdomain) > > > that must be collision-free, rather than hash(rsub) > > > > Fixed to .. so the resulting routing-subdomain hashes.. > > > > > Section 6.10.7.2 > > > > > > information - ACP domain-name, ACP-address, and so on. If the ACP > > > registrar uses BRSKI, it signals the ACP domain information field to > > > the Pledge via the EST /csraddrs command (see > > > [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR > > > Attributes"). > > > > > > I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030 > > > (and the section number is probably stale as well, as the RFC Editor > > > note attests). Oh, but /csrattrs is very close, so this is likely just > > > a typo. > > > > fixed to csrattr, section now 5.9.2 in brski-22 > > > > > Section 6.10.7.3 > > > > > > scheme. The first address of the prefix is the ACP address, all > > > other addresses in the prefix are for other uses by the ACP node as > > > described in the zone and Vlong addressing sub scheme sections. The > > > > > > nit: comma splice > > > > fixed. > > > > > policy. For example, in BRSKI, the ACP registrar is aware of the > > > IDevID of the candidate ACP node, which contains a serialNnumber that > > > is typically indicating the nodes vendor and device type and can be > > > > > > nits: "serialNumber", "node's vendor" possessive > > > > fixed > > > > > > > > ACP registrars SHOULD default to allocate ACP zone sub-address scheme > > > addresses with Subnet-ID 0. Allocation and use of zone sub-addresses > > > with Subnet-ID != 0 is outside the scope of this specification > > > > > > nit: it's only referred to as "Subnet-ID" in the manual addressing > > > sub-scheme; for the zone addressing sub-scheme it's "Zone-ID". > > > > > > > *yikes*. Good catch. There was one more further down of this mistake. > > fixed. > > > > > Section 6.11.1.1 > > > > > > Additionally, failed ACP tunnels can be quickly discovered the secure > > > channel protocol mechanisms such as IKEv2 Dead Peer Detection. This > > > > > > nit: missing word, maybe "through the secure channel protocol" > > > > fixed. > > > > > Section 6.11.1.9 > > > > > > [RFC6550] security not used, substituted by ACP security. > > > > > > Because the ACP links already include provisions for confidentiality > > > and integrity protection, their usage at the RPL layer would be > > > redundant, and so RPL security is not used. > > > > > > The ACP links provide only hop-by-hop security, but it looks like at > > > least some of the RFC6550 mechanisms provide more global source > > > authentication. (I'm not suggesting we change the protocol to use RPL > > > security, just noting that this text is not quite right about being > > > entirely redundant.) > > > > I really have no idea. I had these profile template points be filled > > out by Pascal Thubert, so i would assume it is correct. I forwarded > > the nit to him, let's see what he says. > > > > > Section 6.11.1.14 > > > > > > I still think it's worth calling out that the RPL root is not > > > necessarily preconfigured and this "SHOULD" requirement could > > > potentially apply to any node, but this is only Comment-level and you > > > should feel free to ignore it. > > > > Check the paragraph i inserted into the section for your first review email > > talking about how this does not apply to nodes supporting only > > "default" administrative preference. Hope this is a good trick to > > aleviate the need for forwarding plane enhancemeents on that wouldn't > > never become root in a network operating in a state where this diagnostic > > function would be useful. > > > > > Section 6.12.5 > > > > > > Care must also be taken when creating multi-access ACP virtual > > > interfaces across ACP secure channels between ACP nodes in different > > > domains or routing subdomains. The policies to be negotiated may be > > > described as peer-to-peer policies in which case it is easier to > > > create ACP point-to-point virtual interfaces for these secure > > > channels. > > > > > > nit: the text is unclear about what sort of policies are being > > > negotiated. > > > > Changed sentence to: > > If for example future inter-domain ACP policies are defined as "peer-to-peer" policies, it is easier to create ACP point-to-point virtual interfaces for these inter-domain secure channels. > > > > > Section 8.1.1 > > > > > > When an ACP Edge node receives a packet from an ACP connect > > > interface, it MUST only forward it intot he ACP if it has an IPv6 > > > > > > nit: "into the" > > > > fixed. > > > > > Section 9.1 > > > > > > when using OCSP/CRL. The same benefit can be achieved when using > > > CRL/OCSP, periodically refreshing the revocation information and > > > also tearing down ACP secure channels when the peers (long-lived) > > > certificate is revoked. There is no requirement against ACP > > > > > > nit: "peer's" possessive > > > > fixed. > > > > > partition is left with one or more of such ACP registrars, it can > > > continue to enroll new candidate ACP nodes as long as the ACP > > > registrars sub-CA certificate does not expire. Because the ACP > > > > > > nit: "registrar's sub-CA" possessive > > > > fixed. > > > > > Section 9.2.2 > > > > > > not the Data-Plane. Especially for those management plane functions > > > that have no good protection by themselves because they do not have > > > secure end-to-end transport and to whom ACP does not only provides > > > automatic reliable connectivity but also protection against attacks. > > > > > > nit: s/does not only/not only/ > > > > fixed > > > > > Section 9.3 > > > > > > An ACP is self-forming, self-managing and self-protecting, therefore > > > has minimal dependencies on the administrator of the network. > > > Specifically, since it is (intended to be) independent of > > > configuration, there is no scope for configuration errors on the ACP > > > itself. The administrator may have the option to enable or disable > > > > > > nit: Given that Section 8.2.1 talks about configuring ACP neighbors and > > > 8.2.2 about configuring tunneled neighbors, I'd suggest to s/no > > > scope/only limited scope/, > > > > fixed. > > > > > and perhaps similar tweaks in the following paragraphs. > > > > fixed to. > > > > While configuration (except for and ) is not possible > > > > > Section 10.1 > > > > > > o Check the validity of the domain certificate: > > > > > > * Does the certificate authenticate against the trust anchor? > > > > > > nit: s/authenticate/validate/ > > > > fixed. > > > > > - The neighbors certificate does not have the required > > > trust anchor. Provide diagnostics which trust anchor it > > > has (can identify whom the device belongs to). > > > > > > - The neighbors certificate does not have the same domain > > > (or no domain at all). Diagnose domain-name and > > > potentially other cert info. > > > > > > - The neighbors certificate has been revoked or could not > > > be authenticated by OCSP. > > > > > > - The neighbors certificate has expired - or is not yet > > > valid. > > > > > > nit: s/neighbors/neighbor's/ (every time) > > > > fixed > > > > > Section 10.2.2 > > > > > > For BRSKI or other mechanisms using vouchers: Parameters to > > > determine how to retrieve vouchers for specific type of secure > > > bootstrap candidate ACP nodes (such as MASA URLs), unless this > > > information is automatically learned such as from the LDevID of > > > candidate ACP nodes (as defined in BRSKI). > > > > > > I thought the LDevID was essentially synonymous with "ACP domain > > > certificate" in this document, so I can't understand what this means > > > (unless IDevID was intended). > > > > Yes, this and i think one or two more typos LDevID -> IDevID where fixed > > already for your first review email. > > > > > Section 10.2.3 > > > > > > Even when such a malicious ACP registrar is detected, resolving the > > > problem may be difficult because it would require identifying all the > > > wrong ACP domain certificates assigned via the ACP registrar after it > > > was compromised. And without additional centralized tracking of > > > assigned certificates there is no way to do this. > > > > > > side note: RFC 6962-style certificate transparency is a somewhat > > > decentralized way to do such tracking, though I do not think the > > > engineering tradeoffs favor trying to use it for this situation. > > > > Interesting RFC. i pondered adding a reference to it, because some of the > > actual logging data structures seems quite useful, but the openness model > > would very likely scare operators off ("ACP makes me public how > > many and what nodes my network has ??? go away"). > > > > > Section 10.2.5 > > > > > > Which candidate ACP node is permitted or not permitted into an ACP > > > domain. This may not be a decision to be taken upfront, so that a > > > per-serialNumber policy can be loaded into ever ACP registrar. > > > > > > nit: "every" > > > > fixed. > > > > > Section 10.3.x > > > > > > I still think the document quality here is not as mature as the majority > > > of the document, though concede there is value in covering these topics > > > to some extent in the initial work. > > > > Copied from reply to your first mail: > > > > Not sure how i could bake it better, but it would probably not be worth it > > in this document, given how this is mostly food for thought not impacting > > interoperability and standardization would only come through implementation > > and deployment experimentation followed by some Yang model. Other reviewers > > (Joel if i remember correctly) where grumbling, but couldn't provide any better > > suggestions of how to make operator level interface shutdowns more resilient against > > unintential network disconnect. Hence i argued strongly to keep this section in there > > as important food for thought, especially because its been the #1 ask against ACP to > > figure out by operators i talked to. > > > > > Section 10.3.5 > > > > > > interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will > > > operate interface where "ACP/ANI enable" is set. Setting of > > > > > > nit: "operate on interfaces where" > > > > fixed > > > > > Section 10.3.5.1 > > > > > > Automatically setting "ANI enable" on brownfield nodes where the > > > operator is unaware of it could also be a critical security issue > > > depending on the vouchers used by BRKSI on these nodes. An attacker > > > could claim to be the owner of these devices and create an ACP that > > > the attacker has access/control over. In networks where the operator > > > explicitly wants to enable the ANI this could not happen, because he > > > would create a BRSKI registrar that would discover attack attempts. > > > Nodes requiring "ownership vouchers" would not be subject to that > > > attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more > > > details. Note that a global "ACP enable" alone is not subject to > > > these type of attacks, because it always depends on some other > > > mechanism first to provision domain certificates into the device. > > > > > > It's probably worth double-checking that all of these details are still > > > synchronized with RFC 8366 and the current state of BRSKI. > > > > Yepp. Nothing changed as this is very fundamental, but i still rewrote the > > paragraph somewhat to better express the main concern, which is that > > an operator with no clue what BRSKI/MASA is even though his devices support it > > would not attempt to get an account at the MASA and that opens the door > > to attackers to easier do some form of identity theft > > > > "Frank, we got a letter from our router-vendor with techno-mumbo-jumbo-masa-account", > > "oh, no idea, we're not using that stuff. throw it in the trash bin". > > > > And then someone who did forge the request to get the account for the company > > goes through that company's trash. > > > > > Section 10.3.6 > > > > > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > > > reliable operations of the ACP if it can be executed by mistake or > > > unauthorized. This behavior could be influenced through some > > > additional property in the certificate (e.g., in the domain > > > information extension field) subject to future work: In an ANI > > > > > > [I don't know if it was intentional or an omission to leave this "future > > > work" note in place when most others were removed.] > > > > I only got rid of all "future" in the normative part, which didn't > > only consist of removing the word, but moving text out of the normative section > > referring to this - and this is where such text ended up being (non-normative). > > > > Consider this 10.3.x stuff to be staging for hopefully something we would > > put into YANG in followup work (and as in this case extensions to the cert). > > (unless we define operator interfaces via YANG, we can't standardize them anyhow). > > > > > Section 10.4 > > > > > > There is no desirable configuration for the ACP. Instead, all > > > parameters that need to be configured in support of the ACP are > > > limitations of the solution, but they are only needed in cases where > > > not all components are made autonomic. Whereever this is necessary, > > > it will rely on pre-existing mechanisms for configuration such as CLI > > > > > > "will rely on" can also be seen as an indicator for future work. > > > > In this case i was just thinking about the future as implementations of this > > spec, not future features. So i reworded to "it relies on". > > > > > > > > o When the ACP needs to be extended across interfacess other than > > > L2, the ACP as defined in this document can not autodiscover > > > candidate neighbors automatically. Remove neighbors need to be > > > configured, see Section 8.2. > > > > > > nit: s/Remove/Remote/ > > > > fixed. > > > > > Once the ACP is operating, any further configuration for the data- > > > lane can be configured more reliably across the ACP itself because > > > > > > nit: data-plane > > > > fixed before. > > > > > Section 11 > > > > > > o Every ACP registrar is criticial infrastructure that needs to be > > > hardened against attacks similar to a CA. A malicious registrar > > > > > > nit: as written, this parses as saying that the attacks are similar to a > > > CA, not the amount of hardening needed on the ACP registrar. Adding a > > > comma would probably help. > > > > fixed. > > > > > The ACP It is designed to enable automation of current network > > > management and future autonomic peer-to-peer/distributed network > > > > > > s/It // > > > > fixed. > > > > > Attacks from impacted ACP nodes against the ACP are more difficult > > > than against the data-plane because of the autoconfiguration of the > > > ACP and the absence of configuration options that could be abused > > > that allow to change/break ACP behavior. This is excluding > > > configuration for workaround in support of non-autonomic components. > > > [...] > > > The ACP acts as a security (and transport) substrate for GRASP inside > > > the ACP such that GRASP is not only protected by attacks from the > > > outside, but also by attacks from compromised inside attackers - by > > > relying not only on hop-by-hop security of ACP secure channels, but > > > adding end-to-end security for those GRASP messages. See > > > Section 6.8.2. > > > > > > This is true, but the system as a whole still has the weakness that the > > > compromised node is able to announce GRASP objectives for arbitrary > > > services and potentially cause legitimate traffic to be directed towards > > > it. The connection would still validate (until the certificate > > > expires or is revoked) and the attacker could return bad data that > > > causes honest nodes to misbehave. > > > > Yes. For non-autonomic networks such as those we target via rfc8368, > > i think we can most easily solve this problem easily via cert bits for Roles (A.10.5), > > so only NOC equipment can announce services. > > > > Note that this was traditionally not a real issue which is why we didn't wanted > > to add all these aspects to certs initially: you would have > > a real hard time to get new attack software into a typical legacy HW network infra. > > You'd have to attack by adding new hardware that has the software. Of course, > > in the last 5 years (after we started this *sigh*) network infra components > > become a lot more like PCs, so adding software becomes easier and hence also > > attacks from such software. And i fear that even though secure boot etc. exists, > > the security chains there are not necesssarily very strong. > > > > More fully distributed, self-organizing "Autonomic" solutions of course will > > be tougher. I would be happy if we can show that the security shell provided > > by the ACP and secure router platforms would be strong enough that there is > > enough room for starting to deploy more distributed services management > > without necessarily having to figure out upfront how to build self-organizing higher > > levels of security such as through self-learning reputation sccoring or the > > like. There is just a difference between what would be fun to do, and what i > > as an operator would be willing to accept as baked enough at any point in time ;-) > > > > > revocation and non-renewal of short-lived cdrtificates. In this > > > > > > nit: "certificates" > > > > fixed. > > > > > Section A.6 > > > > > > In my opinion, a lot of this could be split out into a separate draft > > > (that need not be published as an RFC) and just a couple paragraphs left > > > here with a pointer to that separate draft. But this is only a > > > Comment-level point, and I do not insist on it. > > > > Hah. In the other reply i gave you i think i referred to this text as already removed, > > but i forgot that the idea was to remove it before publication. So now i > > added the two notes to the top of this section: > > > > [RFC Editor: This section to be removed before RFC. > > [This section kept for informational purposes up until the last draft version as that would be the version that readers interested in the changelog would also go to to revisit it.] > > > > E.g.: I think its hard to justify putting more time (like separate RFC) > > into something that should be called "leftover ramblings from when we worked > > out the ACP, that we really should not forget". > > > > Going up to last draft seems like a low-cost compromise. > > > > Btw: Its nice you didn't say this is crazy, because as i mentioned in the other > > mail, the WG conclusion was that this type of multi-stage negotiation would be > > way too complex (hence also the removal). ;-) > > > > > Section A.7 > > > > > > An ACP domain is the set of all ACP nodes using certificates from the > > > same CA using the same domain field. GRASP inside the ACP is run > > > across all transitively connected ACP nodes in a domain. > > > > > > It's not entirely clear to me that we need to insist on a single shared > > > CA; given our discussion of potentially joining two distinct ACT domains > > > into a combined network, it seems that we just need to have all nodes > > > using the same set of trust anchor(s), which could potentially include > > > multiple CAs. (There would of course need to be some out-of-band > > > mechanism to avoid address-assignment collisions, which could be as > > > simple as rsub.) > > > > "from one or more Trust Anchors (TA) (typically one CA)" > > > > > Section A.8 > > > > > > For example, Intent could indicate the desire to build an ACP across > > > all domains that have a common parent domain (without relying on the > > > rsub/routing-subdomain solution defined in this document). For > > > example ACP nodes with domain "example.com", "access.example.com", > > > "core.example.com" and "city.core.example.com" should all establish > > > one single ACP. > > > > > > It is interesting to see this discussion in the context of the text in > > > the previous section about """If different ACP domains are to be created > > > [...] Domains "example.com" and "research.example.com" are separate > > > domains if both are domain elements in the domain information element of > > > certificates.""" > > > > Because this document doesn't intend to fnish working this out, its in appendices ;-) > > > > > Section A.8 > > > > > > There still feels like a lot of speculative things in here; I'd suggest > > > adding a disclaimer/introduction at the top that "Intent is the > > > architecture component [...]. Its applicability for use is quite > > > flexible and freeform, with potential applications including:" > > > > Its applicability for use is quite flexible and freeform, with potential applications including policies flooded across ACP GRASP and interpreted on every ACP node. > > > > i like "flexible and freeform" as a euphemism for > > "unclear, undefined and ongoing contentuous" ;-)) > > > > But yes, once we come up with specific policies we want to get standardized, > > we'll figure out a fitting way to do it, and thats what we then call Intent ;-) > > > > > Section A.9 > > > > > > Some solutions may already have an auto-addressing scheme, for > > > example derived from existing unique device identifiers (e.g., MAC > > > addresses). In those cases it may not be desirable to assign > > > addresses to devices via the ACP address information field in the way > > > described in this document. The certificate may simply serve to > > > identify the ACP domain, and the address field could be empty/unused. > > > The only fix required in the remaining way the ACP operate is to > > > define another element in the domain certificate for the two peers to > > > decide who is Alice and who is Bob during secure channel building. > > > > > > I think we need to mention this requirement for tiebreaking earlier in > > > the document, when we introduce the possibility of a certificate with > > > ACP address of '0'. > > > > The "0" address ACP nodes are not allowed to build secure channels, > > they are for ACP-connect'ed nodes in the NOC (i added that explanation > > through the reply to your first review email). > > > > The ++ = no-address ACP addresses are the ones that this spec does > > not define but supports interop with (by defining the address format). > > Added to the channel selection text in 6.5: > > > > A peer with an empty ACP address field in its ACP domain certificate becomes Bob (this specification does not define such peers, only the interoperability with them) > > > > In other words: I do not know nor care yet how to decide on Alive vs. Bob > > when both peers have no ACP address in their certificate. Subject to > > future work. > > > > > Section A.10 > > > > > > nit: the section title uses "futures" as a standalone term synonymous > > > with "future work"; unfortunately, "futures" is already an English word > > > with a quite distinct meaning. > > > > Changed to: "Further (future) options" > > > > I could sell you some A.10.7 options, sure they will go up in value ;-) > > (is that what you meant ?). > > > > > Section A.10.7 > > > > > > 1. Consider if LLDP should be a recommended functionality for ANI > > > devices to improve diagnostics, and if so, which information > > > elements it should signal (insecure). Includes potentially new > > > information elements. > > > > > > I'd suggest changing the parenthetical to "noting that such information > > > is conveyed in an insecure manner)". > > > > Fixed. > > > > > 3. The IDevID of BRSKI pledges should be included in the selected > > > insecure diagnostics option. > > > > > > In some environments (not really the current target case of Enterprise > > > networks) the IDevID would be considered privacy-sensitive, which may be > > > worth mentioning again here. > > > > Hmm. i went with a security example (which is arguably one reason for the desire of privacy, but i think many readers would associate privacy mostly with humans, so would be harder to read by some): > > > > This may be undesirable when exposure of device information is seen as too much of a security issue (ability to deduce possible attack vectors from device model for example) > > > > I also added a similar note to the end of the paragraph in 6.1.1 about certificates: > > > > Any other field of the ACP domain certificate is to be populated as required by or desired by the operator of the ACP domain ACP registrars/CA and required by other purposes that the ACP domain certificate is intended to be used for. For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID into the ACP domain certificate, such as the "serialNumber" (see section 2.3.1). Inclusion of this information makes it easier to potentially attack the node though, for example by learning the device model, which may help to select a fitting subset of attacks. Neighboring attackers can retrieve the certificate through an otherwise unsuccessful initiation of a secure channel association. > > > > > Section A.10.8 > > > > > > Ensuring that manaement sessions using invalidated credentials are > > > > > > typo: "management" > > > > Fixed. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Feb 3 23:31:02 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C9120129; Mon, 3 Feb 2020 23:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E+gt8rPB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W+UmaVhU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJqlnPFzsg06; Mon, 3 Feb 2020 23:30:54 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D46E120122; Mon, 3 Feb 2020 23:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2736; q=dns/txt; s=iport; t=1580801454; x=1582011054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1E9ogAycY50R40zMGdGpjMx7jl53y9+ZV/R97jhmTvw=; b=E+gt8rPBcgY7am0H9Uwaps/Tx+loLrtBiT1w90T42gg3g1t2vRJZtJr0 bgVJxQOQD9ja4MRpRlPu8+zlLoF5dmN4L0DClECfsSScD3RSP+3cYcpp0 dVB4awsn3ZQrDjImIZLINDwiR6NlaEjMv6R51a09fFXfVgG8yRy57hgPY E=; IronPort-PHdr: =?us-ascii?q?9a23=3AtVbIhhEHemG4+wdLMX9QLp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0fioxH8lqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAQD7HDle/5xdJa1lDg4BAQEBAQc?= =?us-ascii?q?BAREBBAQBAYFqBAEBCwGBUyQsBWxYIAQLKgqECoNGA4p5gjolmA+CUgNUCQE?= =?us-ascii?q?BAQwBASMKAgEBhEACF4IdJDcGDgIDDQEBBAEBAQIBBQRthTcMhWcBAQECARI?= =?us-ascii?q?REQwBATcBDwIBCA4MAh8HAgICMBUQAgQBDQUigwQBgkoDDiABAwuhEwKBOYh?= =?us-ascii?q?idYEygn8BAQWFFhiCDAMGgQ4qAYwhGoFBP4ERJwwUgkw+gmQCgXyCeTKCLI1?= =?us-ascii?q?igjo7nxAKgjuHSY56G5sIjmGIZ5IzAgQCBAUCDgEBBYFoI4FYcBVlAYINATM?= =?us-ascii?q?fMRgNjh0MFxWDO4UUhQQ7dIEpjDABgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,398,1574121600"; d="scan'208";a="421407388" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Feb 2020 07:30:53 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0147UpKn015134 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2020 07:30:53 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 01:30:36 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 02:30:35 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 02:30:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XImLVMPA5AxMwQOm5NEtz4Kxka/f54VvLp5x5IFFkIoc8yrXfbK1JlMn8zEyUuwgq8nJEJjKF809zgjb9mupmdzrh6JwZuTkT9xFp2dQ4XGCmFafjb3tpm2tc24NC98At8Te0tBT4Pvz57gtS0q/zbIG1qDfkUw1BhxlXQ0SIRcqOHFxhmPQ8dgc1MaGdVawfJbsKCFm8zjTKXQ2JvZldr0b5IG/UC0+BJgmLK///GdN463V5Q3SVWCt4Fdbqi9E3OejKEKDYrgsmkJwulEKPNlPLvee1fw+iuKP9hFnuGBnHKllRhGAlqiDMobsmdK9EfFrw3elkjPjjkZdf7+b2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1E9ogAycY50R40zMGdGpjMx7jl53y9+ZV/R97jhmTvw=; b=hizqPw8ptqHdur4J/drPOZNdY6Bhx8hMkf0Q46EgVDaFzNwC+X0aV7hSv1EyqnRQN4JNi07PltVqUCYuZgUiuYGOAfBYEqy2p7+YBoa+ujH8/Y2J7+4nYIuophUWdI2U9M+CtgE2MEieIxrUCBiFohetQGapiF/NuMcTHElMLn/e8IXwQEd6B6oCnIc6Rla4cDN3lcdjmKQzXRMiLapLrxk8Wt/i2Pe/MQS2kjQ7w7JX2Vcgn0RIFHNEzmSDB9FUPyjVseRlRGAuUZMZMiWH/0r84v2HAXxD7yoJ2ASFhMmdhEU9Ar8pKfqBD21HQyaVoOwks/hd48xR/v2Yttx5Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1E9ogAycY50R40zMGdGpjMx7jl53y9+ZV/R97jhmTvw=; b=W+UmaVhUJOLivWM9chitmDf5jICyZAaBJvDqHEW8Eq5gCm1OJbixozZLFMBivBVm46jwlcvOS+m9m4liRo632J345yj2bvynm6XUpR2eiHuO7EHKSGe/8Z6JgV8tgbzhJ16xOb9QWDWee38JOLonV9VUn4Nh/vKSv/k8hW+5A6M= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB0043.namprd11.prod.outlook.com (10.164.154.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.33; Tue, 4 Feb 2020 07:30:34 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff%11]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 07:30:34 +0000 From: "Eric Vyncke (evyncke)" To: Toerless Eckert , Benjamin Kaduk CC: "anima-chairs@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , The IESG , "anima@ietf.org" , "jiangsheng@huawei.com" Thread-Topic: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) Thread-Index: AQHV2yz8y9tVyLCb2kKBeuBtDKasSg== Date: Tue, 4 Feb 2020 07:30:34 +0000 Message-ID: <3CF6794C-63E6-4078-A55F-329E874FEFC5@cisco.com> References: <20191230173030.GJ35479@kduck.mit.edu> <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [92.184.116.201] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 160f7aed-1f2b-48d2-87a3-08d7a9441f4f x-ms-traffictypediagnostic: DM5PR11MB0043: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(136003)(366004)(189003)(199004)(5660300002)(6506007)(966005)(4326008)(186003)(86362001)(316002)(33656002)(6512007)(64756008)(66476007)(478600001)(66556008)(66446008)(76116006)(81166006)(81156014)(71200400001)(66946007)(91956017)(36756003)(8936002)(54906003)(26005)(8676002)(2906002)(2616005)(6486002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB0043; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qhXm7MPaitaQHP6eKEY3BlXFKB7/ZAzK/8s/mAl+l+SriZ430uq2ilYuyYLu29nli6q/Hv8rj1z5KjBz85g4LdwOB/TDCSgrPzAf4QxUUJkB+DaUINpu+Zxtt0UNv+aKG+knmNOpdrgruixXtvXb+yRr7m/uMewMsK+Mt7Slzph6x3iCenC+fydHCGjjH34FRzXTejBhESdSbGZGVZiVZg1qIoXe8YTuaBSQVxmH6Gfq6wBu/uhWzLGYuFJZjh5SHpiQzDxyo3YDmvVx2ZgMTc7wW442eNo3H18qwbWRMqKbuxW1+T+252X0mkCyCuY8Zgz6CkrDM7lYb7kVemtm1gs44sr4aEH4ChXvQUvdm74KVtqBAdBd0/Kw9Hgas+IQyLT8Zth2ixm1y7C+fuvFZXxoyzUyUDaExU55TeSMfnTLURjkrvQzVGsEqUwHEjkpFyJnaC6kgOSHU1TOXOYFEtO1TKjELnFMo5bkeCgbfRvq8EHLkhYsrJVn7s6MHJyLpS0duLFBJkurms74D8hEqg== x-ms-exchange-antispam-messagedata: JTbjAbALEmSYPVDk8s++9XywQl+JtzAYXZ9+PBqMiZhGliv7JYUzWBEeqLMP47KjOc+aurhnfLB2M3ujHzqwHd5op/2tB71ooeLaUCkniK9tJYPV4cTyQwTtzCBI5vpSgMGh9+9PAoTAXjJuEqO7JA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5AB8FDDC96D16E4CB4F64F34D92C2A3D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 160f7aed-1f2b-48d2-87a3-08d7a9441f4f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 07:30:34.2001 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EAw7wZu4cecUaKLRUGwz0EerikcTwFubPBboXi7WbnifYi0h8DCrgaP9IKPrFXAVdBbjz1a2RV07ieGkrZToPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0043 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 07:30:57 -0000 VG9lcmxlc3MNCg0KVGhhbmsgeW91IGZvciB0aGlzIHVwZGF0ZWQgcmV2aXNpb24uIA0KDQpBYm91 dCB0aGUgbmV4dCBzdGVwczoNCg0K77u/T24gMDQvMDIvMjAyMCwgMDU6NDksICJpZXNnIG9uIGJl aGFsZiBvZiBUb2VybGVzcyBFY2tlcnQiIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIHR0ZUBjcy5mYXUuZGU+IHdyb3RlOg0KDQogICAgSGkgQmVuamFtaW4NCg0KICAgIC0tLS0t JTwtLS0tLS0lPC0tLS0tDQogICANCiAgICA+IFRoYXQgc2FpZCwgbXkgb25lIERpc2N1c3MgcG9p bnQgaXMgbm90IHRoZSBlbmQgb2YgdGhlIHJvYWQgZm9yIHRoaW5nczsNCiAgICA+IHNpbmNlIGFz IEkgdW5kZXJzdGFuZCBpdCB0aGUgV0cgaGFzIGFscmVhZHkgY29uc2lkZXJlZCB0aGUgdG9waWMN CiAgICA+IGV4dGVuc2l2ZWx5LCBpdCBtYXkgYmUgdGltZSB0byBjaGVjayB3aXRoIHRoZSByZXNw b25zaWJsZSBBRCBhYm91dCBicmluZ2luZw0KICAgID4gdGhlIGRvY3VtZW50IGJhY2sgb24gYSB0 ZWxlY2hhdCB3aXRoLCBlLmcuLCBhbiBhbHRlcm5hdGUgYmFsbG90IHByb2NlZHVyZQ0KICAgID4g KCJzaW5nbGUtZGlzY3VzcyIgb3IgdGhlIGZ1bGwtb24gImFsdGVybmF0ZSBwcm9jZWR1cmUiIGZy b20NCiAgICA+IGh0dHBzOi8vaWV0Zi5vcmcvc3RhbmRhcmRzL3Byb2Nlc3MvaWVzZy1iYWxsb3Rz LykuICBJIGRvbid0IHJlbWVtYmVyDQogICAgPiBoZWFyaW5nIG11Y2ggZnJvbSBhbnkgb3RoZXIg SUVTRyBtZW1iZXJzIG9uIHRoaXMgdG9waWMsIGF0IGxlYXN0IGFzIG9mIHlldC4NCiAgICANCiAg ICBOb3QgcXVpdGUgc3VyZSBpIGZvbGxvdyBldmVyeXRoaW5nIHlvdSBzYXk6IE15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdA0KICAgIEUncmljIGlzIG5vdyB0aGUgcmVzcG9uc2libGUgQUQgZm9yIHRo ZSBkb2N1bWVudCwgc28gd2UgYXV0aG9ycyB3aWxsIHNpbXBseQ0KICAgIGZvbGxvdyBoaXMgZ3Vp ZGFuY2UgZm9yIGFueSBmdXJ0aGVyIG5lY2Vzc2FyeSBBRCByZXZpZXcgLg0KICAgIA0KICAgIEdp dmVuIGhvdyB3ZSBhbHJlYWR5IGhhZCBhIGxvdCBvZiBleGhhdXN0aXZlIGFuZCBnb29kIHJldmll d3MgYW5kIHJlc3VsdGluZw0KICAgIGZpeGVzLCBpIGhvcGUgdGhlIHBvb3IgQURzIHdpbGwgbm90 IGJlIGZvcmNlZCB0byByZXBlYXQgcG90ZW50aWFseSB1bm5lY2Vzc2FyeQ0KICAgIHdvcmsgb24g c3VjaCBhIGJpZyBkb2N1bWVudCBnaXZlbiBob3cgdGhlIGZpeGVzIGFyZSBhbGwgd2VsbCBkb2N1 bWVudGVkIGFuZA0KICAgIGFsc28gc3VtbWFyaXplZCBub3cgaW4gdGhlIGNoYW5nZWxvZyAoc3Vt bWFyaXppbmcgSUVTRyByZXZpZXcgdXAgdG8gLTIxIGFuZCBleHBsYWluaW5nDQogICAgdGhhdCB0 aGVyZSBhcmUgbm8gZnVuZGFtZW50YWwgY2hhbmdlcyBqdXN0IGEgZ29vZCBhbW91bnQgb2YgZGV0 YWlsIGZpeGVzDQogICAgYW5kIHRleHR1YWwgaW1wcm92ZW1lbnRzKS4gIEJ1dCB0aGlzIGlzIG15 IGZpcnN0IFJGQyBhcyBiaWcgYXMgdGhpcywNCiAgICBzbyBpIGhhdmUgbm8gcHJpb3IgZ29vZCBl eHBlcmllbmNlIHdpdGggdGhlIHByb2Nlc3MgaW4gYSBjYXNlIGxpa2UgdGhpcy4NCg0KQXMgSSBh bSB0aGUgJ3Bvb3InIHJlc3BvbnNpYmxlIEFEIG5vdywgd2l0aCB0aGUgYW1vdW50IG9mIGNoYW5n ZXMgaW4gdGhlIGRvY3VtZW50LCBhbiBJRVRGLXdpZGUgTGFzdCBDYWxsIGlzIHJlcXVpcmVkIHRv IGVuc3VyZSBhIHN3aWZ0IHByb2Nlc3MuIEFzIHNvb24gYXMgSSBhbSBjb25maWRlbnQgdGhhdCAt MjIgaXMgJ2dvb2QgdG8gZ28nLCB0aGVuIEkgd2lsbCBzdGFydCB0aGlzIExhc3QgQ2FsbCwgdGhl biBJRVNHIGV2YWx1YXRpb24sIGJhbGxvdCBhbmQgdGVsZWNoYXQgYW5kIGhvcGVmdWxseSB0aGUg ZG9jdW1lbnQgd2lsbCBiZSBhcHByb3ZlZCBiZWZvcmUgdGhlIG5ldyBJRVNHLg0KDQpSZWdhcmRz LA0KDQotw6lyaWMNCg0KLS0tLSU8LS0tLS0tLS0tLS0lPC0tLS0tLS0tLS0NCiAgICANCiAgICAN Cg0K From nobody Wed Feb 5 02:34:46 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7B12012D; Wed, 5 Feb 2020 02:34:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <158089888100.12738.7507919945958957940@ietfa.amsl.com> Date: Wed, 05 Feb 2020 02:34:41 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-35.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:34:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-35.txt Pages : 118 Date : 2020-02-05 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-35 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-35 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/ From nobody Wed Feb 5 04:36:55 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADBC12013D for ; Wed, 5 Feb 2020 04:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw_k_mz1vr1E for ; Wed, 5 Feb 2020 04:36:52 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DB912013A for ; Wed, 5 Feb 2020 04:36:52 -0800 (PST) Received: from dooku.sandelman.ca (ip5f5bd76d.dynamic.kabel-deutschland.de [95.91.215.109]) by relay.sandelman.ca (Postfix) with ESMTPS id A0F961F45A; Wed, 5 Feb 2020 12:36:50 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7ED7B1314; Wed, 5 Feb 2020 07:36:47 -0500 (EST) From: Michael Richardson To: anima@ietf.org, Benjamin Kaduk CC: Warren Kumari In-reply-to: <158089888100.12738.7507919945958957940@ietfa.amsl.com> References: <158089888100.12738.7507919945958957940@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Wed, 05 Feb 2020 02:34:41 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 05 Feb 2020 13:36:47 +0100 Message-ID: <27544.1580906207@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-35.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 12:36:55 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Toerless Eckert > Michael H. Behringer > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-35.txt > Pages : 118 > Date : 2020-02-05 This version has the examples updated. I have confirmed: 1) the registrar has cmcRA set. 2) the OID in the IDevID is the newly IANA assigned one. 3) no other extensions are present. 4) I have added a JSON dump of the "parboiled" (Registrar->MASA voucher request). 5) I wrapped up the base64 dumps of the vouchers in lines. 6) I also went back to Alissa's non-YANG related comments to be sure that I had already dealt with them, and I had. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl46tt8ACgkQlUzhVv38 QpB+MQf5AcH4wOyL80mSMzaCTAqF3HjPz+tLnmxKHKrq5wYiS3O/nJP+YNucLfUX 4NN3NyPpqBioJ8WY65vaU7oRNVM/RNQn9kltS1+igjGbavgbWzYkPEYHsXiU0hCq qbLeSkOiLelAzTyd/jhPT0x+O+d++Hs4OhQMT1uS0SNypDmqj74ulY0kTIsx/2yj 2XHW4hssc7FvQsab/XTZxLO8sqq8/CDBu+9FIXxlzRFwMA2GXgG3/se87lyNFicg Hzx1vJUvAP8JlZ0NJCQLGFhTSvaJSgCw2i1cchoUuerQvyFOo4ntGekywnkx76/p pESXgnO2BOxMhbyFncy6Uf8ofOTt7g== =ERwq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 6 12:38:32 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FD212011D; Thu, 6 Feb 2020 12:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.377 X-Spam-Level: ** X-Spam-Status: No, score=2.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dju8NCeQHqdv; Thu, 6 Feb 2020 12:38:25 -0800 (PST) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8651201E5; Thu, 6 Feb 2020 12:38:25 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:1993:81d7:2ab0:b9b6]) by relay.sandelman.ca (Postfix) with ESMTPS id 6E61D1F45A; Thu, 6 Feb 2020 20:38:23 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F04621A0955; Thu, 6 Feb 2020 21:38:21 +0100 (CET) From: Michael Richardson To: Toerless Eckert , Benjamin Kaduk , The IESG , anima@ietf.org In-reply-to: <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> References: <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Tue, 04 Feb 2020 05:49:33 +0100." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 06 Feb 2020 21:38:21 +0100 Message-ID: <19293.1581021501@dooku> Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 20:38:27 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Thanks a lot for the review, just committed -22 to answer to your > review, providing separate diffs inline for the rfc822 vs IPsec parts > to easier separate out the fixes for you. For everybody else, they can > just do a diff -21 -> -22, which will also include the input changes to > your review. After all the nice text in section 6.3 on page 37 justifying why the objective is called IKEv2, why did the title of 6.7.1 change to IPsec? IPsec is manually keyed. IKEv2 is not. If this is too confusing to TLS people, then perhaps we could say: 6.7.1 ACP via IKEv2 (IPsec) As for the rfc822Name debate, it is a format (other than pure FQDN), which lets us use ACME with the proposed email-reply-00 challenge in draft-ietf-acme-email-smime. The only other alternative is FQDN with dns-01, and that would likely be uglier. If these unnamed PKIX experts would like to debate this with us openly, they know where to find the WG. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl48eT0ACgkQlUzhVv38 QpDG8wf/ROgQigbIVzmv9OLiHaXwo7hrREfk81pFLq0kjzGyD2oUO+Ml+XJwSuYt Y9DQ/nw5Fgrl04MuJXeF5g5BqndP/vsvxgetsrbYTlE3g9WdUyqIT0gaCru95iNX ba9/tLUY8oRq95nEi4WfpzJUxslHl1IWvpXVfL9SGtBNFbvGfVb2G5HBFqhDQc++ kCEOK7hBwtOA2u1bwxrPAPPSp3p+7lPl0LNVEmVCSoxj7CbZMdbG3ZsYoybr9+G5 vHDLmZ4WOsPJxA3H1xqPM3MSPho+SC/+F2rM+Of5azXFsFWHOXp+Et7djVuefssG vyU+s6eOgzPV0+RrZZaUBs8LPvI2Ww== =VPyR -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 6 12:59:59 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75ED12012A for ; Thu, 6 Feb 2020 12:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yafLqKhfCL0o for ; Thu, 6 Feb 2020 12:59:55 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD64812022A for ; Thu, 6 Feb 2020 12:59:55 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BE824548015; Thu, 6 Feb 2020 21:59:49 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B7F34440059; Thu, 6 Feb 2020 21:59:49 +0100 (CET) Date: Thu, 6 Feb 2020 21:59:49 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 20:59:58 -0000 Hi Brian, sorry to pick you out, but i think you've got the best overview of the ongoing set of ASA related docs. I just got reminded through ongoing ACP spec review about something that would be good to write into the appropriate ASA spec, but not sure which one: One of the fundamental problems we have to solve longer term is how we can establish better than "Any ANI peer is equally trusted" notion. Short term, i'll propose when i have time to have according roles in the ANI certificates, but thats really a non-autonomic solution because some outside intelligence (operator) has to assign such a role. In reality today, its family,friends,colleagues&media that establish the trust notion for us: trust foo.com to provide service bar, but certainly not acme.com. The fact that you can then cryptographically (web-Cert) assert that you're really talking to foo.com is really just a secondary dependency. I think DINRG is working in this direction, but have failed to track. Maybe there is a way to collaborate on this, aka: see if/when they might have output we could think to adopt/leverae. But its fundamental if we want to move into more autonomic solutions beyond just supporting the current SDN model. Right now we expect objective announcements from any node to be equally trustworthy and decide on selecting one only on announced parameters (also subject to equal trust) and network parameter comparison. And of course, this goes beyond trust into performance vetting by others and so on. Trying to figure out the most easy use-case would also be quite helpfull. aka: what the most short term useful ASA that we'd like to have spread around the network, where we could apply different degrees of these mechanisms... Cheers Toerless From nobody Thu Feb 6 13:55:39 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E1512011B for ; Thu, 6 Feb 2020 13:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xQkma4LjpJT for ; Thu, 6 Feb 2020 13:55:34 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966481200B3 for ; Thu, 6 Feb 2020 13:55:34 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:1993:81d7:2ab0:b9b6]) by relay.sandelman.ca (Postfix) with ESMTPS id 73B961F45A; Thu, 6 Feb 2020 21:55:32 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F01C41A096A; Thu, 6 Feb 2020 22:55:31 +0100 (CET) From: Michael Richardson To: Toerless Eckert cc: Brian E Carpenter , anima@ietf.org In-reply-to: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Thu, 06 Feb 2020 21:59:49 +0100." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 06 Feb 2020 22:55:31 +0100 Message-ID: <23372.1581026131@dooku> Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 21:55:37 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I just got reminded through ongoing ACP spec review about something that > would be good to write into the appropriate ASA spec, but not sure which > one: > One of the fundamental problems we have to solve longer term is how we > can establish better than "Any ANI peer is equally trusted" notion. I agree. But, at this point, all the ANI peers are equal. None do anything special yet... Once we have protocol(s) that can do something different, then we need to figure out what the requirements for that protocol. Putting the trusted-to-do-foo bit into the certificate is probably unwise. It seems that in an autonomic network that there ought to be a service that can be used to ask, "should I trust node FOO to do X?". That could be the (cmc)RA or another node so designated. It seems that GRASP can pretty much do all of this. COSE can be used to sign answers. That is probably a thing we need to add. > I think DINRG is working in this direction, but have failed to track. > Maybe there is a way to collaborate on this, aka: see if/when they might > have output we could think to adopt/leverae. I don't know what they are doing either. > Right now we expect objective announcements from any node to be equally > trustworthy and decide on selecting one only on announced parameters > (also subject to equal trust) and network parameter comparison. > And of course, this goes beyond trust into performance vetting by > others and so on. At some level, if you are looking for resource X, and some node can provide X, and it works and does what you need... then maybe it is reasonable to trust it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl48i1MACgkQlUzhVv38 QpAxMQgAmeBs2IqTGJ1Ex9R9IRzIaGVlSUHJHfPHup/YtAF/i6kWYvViN4VwxvfQ nW7NmrnX+HU0pmeiFOMSOKw2iTlf5ODvBwt/pmcP+cQv62E/OaGkZSn/SC6TgdGP tGWvCyjQVqPeEV2jC9tw2MLp6046tndIoz4HOoOUK77yvBiWGV9vbR676GgwxuCV 5MPi8yP+9XtgJsrbuWNb3Db3aqCcM9YS2wCTXzRx0+ph4sLnBvmXK+t7P8/SjaDo VMEsy1YJh1G/P4e+uoDmaEQ/XbYYt6QqXSryMYU7Gdyjty63ZEMEQvMw17vYdyuV i0SByAmHifeh8omFeQ1ta17qcmjiSA== =q9gA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 6 19:42:22 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336E712011D for ; Thu, 6 Feb 2020 19:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO4NaApstHyh for ; Thu, 6 Feb 2020 19:42:18 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488D812001B for ; Thu, 6 Feb 2020 19:42:18 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id dw13so335570pjb.4 for ; Thu, 06 Feb 2020 19:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=c8EWojBs5lWBIQIZIK6fC7995Ent0pK5V0XclWeNkBFxsgB5tPYCn1Evathwo9hrAH QJppiZnrOXcRa3fuYdilH07p7cTV9ScLgNitrZjJ/6wlVAr7BxpBlyv6lr3vaSLw99WT fSy53TDszcPjs/lzM50TMloNxMwLkAKTuHOIE4zSCVu83sLCxPhgo1p/pku4dwYDp0uP 8Oc4+4YBiTtyA2HKbq+z6JpVTi3A1/NAx6XDkbn0m3pO1IP0TCunagq09SRnJ/P91Exa 9+/JhVZdjVgJpRn2HWTY/WLkcVKy4RYGeVX59tp88IvjeqpD/t2lzUdHYFTKklBSXpaD tzSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=GScXG+nKsTB6YC5p8dN5EGfLfZ4Ki2qbaqJsYkkFFW7uLsUykyMCB2dSrbYItU6m9L qEd1w7C3PmZcIDhJlLKVRQHldA8g/y7QGd1xSnF959riPWO1LzuATlD+Oxb1j4mh8loG 6SicK8RIMZKORqVUoR085ag1dMF9U96yYBSyrBd7dvvL7hIenbJY29R49Fa8BCeE5eTO 0+R3jKxCWA7lyTghvGgL5ScvEBqv9swQdzPe/12Rt6w5YffXsllk7NxnmKKOPYO2kwvn Bi/hCtLzsfAkteigOHHGR3Bh0aLr6nz0ejbcfVMz4yZazWri6/CGAA33eg2jfCujXIro QeiQ== X-Gm-Message-State: APjAAAUqr59OGJyv3v4dSmDpcV1eB9bsnL096TRSH1/8OA4le+VI+M6p XkyJRdVjANF4fl+RBAY2SqvbR1ii X-Google-Smtp-Source: APXvYqxWuUbNcIhpXgaEFX2+Nl+EhLRFkW8SH0fyCcszdDFoTIBbtTsDAOOtIWcLmUDaGaIezwFcpA== X-Received: by 2002:a17:90a:ac18:: with SMTP id o24mr1414873pjq.33.1581046937431; Thu, 06 Feb 2020 19:42:17 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id b3sm846450pfr.88.2020.02.06.19.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 19:42:16 -0800 (PST) To: Michael Richardson , Toerless Eckert Cc: anima@ietf.org References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> From: Brian E Carpenter Message-ID: <3777ab26-2a73-2cf6-75ea-7573681b64b7@gmail.com> Date: Fri, 7 Feb 2020 16:42:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <23372.1581026131@dooku> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 03:42:20 -0000 Yes, this is certainly a gap, and it's why I put register_asa and register_objective in the API, thinking that when we add some kind of trust/authorize magic dust, this would be created when registering the ASA to (a) run and (b) manage certain GRASP objectives. I feel quite far from having a complete model in my head though. I guess we should start with understanding what threats we are protecting against. Regards Brian Carpenter On 07-Feb-20 10:55, Michael Richardson wrote: > > Toerless Eckert wrote: > > I just got reminded through ongoing ACP spec review about something that > > would be good to write into the appropriate ASA spec, but not sure which > > one: > > > One of the fundamental problems we have to solve longer term is how we > > can establish better than "Any ANI peer is equally trusted" notion. > > I agree. > But, at this point, all the ANI peers are equal. > > None do anything special yet... Once we have protocol(s) that can do > something different, then we need to figure out what the requirements for > that protocol. > > Putting the trusted-to-do-foo bit into the certificate is probably unwise. > > It seems that in an autonomic network that there ought to be a service that > can be used to ask, "should I trust node FOO to do X?". > That could be the (cmc)RA or another node so designated. > It seems that GRASP can pretty much do all of this. > > COSE can be used to sign answers. > That is probably a thing we need to add. > > > I think DINRG is working in this direction, but have failed to track. > > Maybe there is a way to collaborate on this, aka: see if/when they might > > have output we could think to adopt/leverae. > > I don't know what they are doing either. > > > Right now we expect objective announcements from any node to be equally > > trustworthy and decide on selecting one only on announced parameters > > (also subject to equal trust) and network parameter comparison. > > And of course, this goes beyond trust into performance vetting by > > others and so on. > > At some level, if you are looking for resource X, and some node can provide > X, and it works and does what you need... then maybe it is reasonable to > trust it. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Fri Feb 7 06:58:13 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D2612029C for ; Fri, 7 Feb 2020 06:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD5-dBm-nd-X for ; Fri, 7 Feb 2020 06:58:09 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9055B1207FC for ; Fri, 7 Feb 2020 06:58:09 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C164454804C; Fri, 7 Feb 2020 15:58:02 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B9400440059; Fri, 7 Feb 2020 15:58:02 +0100 (CET) Date: Fri, 7 Feb 2020 15:58:02 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23372.1581026131@dooku> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:58:12 -0000 On Thu, Feb 06, 2020 at 10:55:31PM +0100, Michael Richardson wrote: > I agree. > But, at this point, all the ANI peers are equal. Except for cmc(RA). > None do anything special yet... Once we have protocol(s) that can do > something different, then we need to figure out what the requirements for > that protocol. Or rather service. yes. Thats what i am asking for. > Putting the trusted-to-do-foo bit into the certificate is probably unwise. Well... a) see above (registrar) b) I think its wise, but i do understand how the crypto folks don't lke it and every time you ask crypto folks think outside the box it takes eternities. Aka: to me its not different from the implied trust expressed by a weeb certificate through the name. If i have cert bits indicating more generic "roles" thats IMHO quite similar. c) But the main ask here was to see if there is some actionable output of research that moves us beyond this model. > It seems that in an autonomic network that there ought to be a service that > can be used to ask, "should I trust node FOO to do X?". Sure, and i am going to run a hacked ACP node thats announcing in GRASP to be the "best-ever" node to provide that service ;-) How to you prohibit me to happen ? -> Anser: i dont have a fitting certificate, or there is some ACP crowd intelligence that says i am untrustworthy. > That could be the (cmc)RA or another node so designated. Right. Thats the "role" indications in certificate approach. And of course we want to limit that to really "lifetime role assignments" (lifetime larger than cert lifetime..). > It seems that GRASP can pretty much do all of this. > > COSE can be used to sign answers. > That is probably a thing we need to add. Right. > > I think DINRG is working in this direction, but have failed to track. > > Maybe there is a way to collaborate on this, aka: see if/when they might > > have output we could think to adopt/leverae. > > I don't know what they are doing either. > > > Right now we expect objective announcements from any node to be equally > > trustworthy and decide on selecting one only on announced parameters > > (also subject to equal trust) and network parameter comparison. > > And of course, this goes beyond trust into performance vetting by > > others and so on. > > At some level, if you are looking for resource X, and some node can provide > X, and it works and does what you need... then maybe it is reasonable to > trust it. Yes, discovering violation of trust is the biggest issue for crowd intelligence. The easier starting point case would be crowd intelligence based on client measured service performance experience. Think DNS proxies on each edge-router circling around the set of DNS services announced, DNS proxies measure RTT and failure rate, exchange amongst themselves those parameters and adjust their use of these servers accordingly. Easy to see how this might easily wipe out unreliable servers. Much more difficult to do the solution to optimize overall load when the best server becomes overloaded because everybody wants to start using it. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Feb 7 15:04:41 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408261200FE for ; Fri, 7 Feb 2020 15:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRfYi5vxsUor for ; Fri, 7 Feb 2020 15:04:38 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55A21200FA for ; Fri, 7 Feb 2020 15:04:37 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id y73so534875pfg.2 for ; Fri, 07 Feb 2020 15:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JHDPZAXZAqQtYiOnep6GOjHirCBN8qK2lPKF+gm1FP0=; b=HidNEnOSPiFrnAv+rbHbLLtpZdcrXReaeKIL4RQP8l2ScxwyOtReSSMa7AjbF1qgOr 2QzJd2pIHEHQw2qVyTgms50PtJnb7XPp9GrYGUzTWOQTW5Z/1leyWRYxU3bmL2fLepz3 Ulj6/PkKR9kqIdWRLUNSDtMpVeP3cCtO7TUhoTo4B4I/hRSvVzbHAC+LhCFUIWTJqaNx bTXlQMvIXchzqUPm88U+IF+WnWyqRLgAet22WVIeKuGxyEEvs7oCPi3qXlXJu3mPkZ/F pm0P9evGh79tW5Z0CxeB6rnPMWUa3dcJ4pacPxol16UpFyNxQJJTdR2TEduoXsuA1ri3 Al8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JHDPZAXZAqQtYiOnep6GOjHirCBN8qK2lPKF+gm1FP0=; b=Ahlx4B8JwAreZyzacsva0x61Y0sbx388Lo8h2Fr1yFUcTaMZwCh2XrVxYYKGTyd6Jp eYTSO064Ze9R1OcZf7jiHM7AExv5D9geJDG+YoxxKmBX3YyIuEV5P+SKjQEHnpvlDw56 ZpW40tYPbAMPq+uQ1C5fppi/iWX5vJribkwiKMuXAhWa1tQtt0X/9mDhsZocOhV8taQA m2iwFjGDJHiAEjfbSRTntksu30MxjTwFWz8Z7P3AuuVSZFYBPMc9STDEUgMpgaNOr+41 bRITI+EUei+mdaAE3RJ9qGHNKLZKATXzpMEv11Oppm8JmaFYWty2asa38r2QQ8UAEaR0 Nu+Q== X-Gm-Message-State: APjAAAXFIZZyY/9an0lxk5vfmh/17ZfZ+frtPDOiHHe2rOuuQH/GXUGy 3whUCosIYppcxc/PFOW0qa9lIq7F X-Google-Smtp-Source: APXvYqxtey4Y5PSkkcjD/tH51xRxe1hLrqjw+6zSPKO5yp+5t4IYziNvIj0P06HESkrlPQTZc2aeiw== X-Received: by 2002:a63:c304:: with SMTP id c4mr1579635pgd.85.1581116676978; Fri, 07 Feb 2020 15:04:36 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id j14sm3897616pgs.57.2020.02.07.15.04.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 15:04:36 -0800 (PST) To: Toerless Eckert , Michael Richardson Cc: anima@ietf.org References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> Date: Sat, 8 Feb 2020 12:04:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 23:04:39 -0000 On 08-Feb-20 03:58, Toerless Eckert wrote: > Sure, and i am going to run a hacked ACP node thats announcing in GRASP > to be the "best-ever" node to provide that service ;-) How to you > prohibit me to happen ? -> Anser: i dont have a fitting certificate, or > there is some ACP crowd intelligence that says i am untrustworthy. I don't see how you can get away from asymmetric crypto to do that. An ASA comes up and says 'I support "DANGER"', which is a GRASP objective for doing something very dangerous. Take a concrete example: 'I support "PrefixManager"', which is defined in draft-ietf-anima-prefix-management and will be in an RFC one day soon. So this ASA needs to be trusted to allocate or assign IP address space. How can we check this is OK? As far as I can see, only if we have previously decided to trust any PrefixManager ASA that can prove possession of a given private key, or more precisely one of a given set of private keys. In practical reality, I'm sure operators will want to install identical binaries of a given ASA on multiple autonomic nodes. So the private key will be scattered around the autonomic domain. My guess is that a lot of operators would not see this as any better than just trusting the nodes, not the individual ASAs. Brian From nobody Sat Feb 8 02:36:16 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6745312004D for ; Sat, 8 Feb 2020 02:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW7ELWUhkdBz for ; Sat, 8 Feb 2020 02:36:12 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E651712004A for ; Sat, 8 Feb 2020 02:36:11 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id z3so1785329wru.3 for ; Sat, 08 Feb 2020 02:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=peLEEYxF67KS2z/A4f6CTohEHqSpEPf+6UorR02VPjk=; b=im8r3X1iLA3KP1KDxNleLnYnPlA8L0RSIQtMPqqfRCWejOnqK0p47d1LNssvFd7GAn Czqp5CQ3/u5U1QxRjo43UAJor5lxPXnrzejPDFNE5+JQMRvkx0aFpeK83k5R/CXNAGoW /5kNHBXbdG17eiRu6Oc8e4ppWq+YKYKJCUev7KWmpDqjoI9pOg9En6QoK2Vt+FfEsVyM V2QnPD8uq8DnRC8zCQN3FhjVBT5r907nXL6N+KBLF9ioBaQMq5gQDjPIReXdn+qdEi8I 4qPCTfE0murV3O7SflBQ8Gy2qIIQ/y5QqH6pFR5JwhvEP3wjYRkKeR/xBxzp3K8t9NsV iMag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=peLEEYxF67KS2z/A4f6CTohEHqSpEPf+6UorR02VPjk=; b=Zs54X3HCSafp5hjpDvNyOUFE2HU0vd6gJaHWlZcvrONct0/ndeWbydUOzAvpYAtDRw S99ZT3OJ36GOkIB8ywpf3JiS1z8FLIEMpBBk9Rup4+4RH9BbG1bqRIPI2NlTYanzk44+ yoChrznJAhHlCumInZDaPG1AUXObH9oEQLsfYvnBdKMLWsptrD7RfDGZPsXkZoluxb4C ZCQTzqZsaJcF1y70eZNtlF2mYk/kNgGonlfdQhYZDTfIbn5BklOe68ZP5srRwQdfTGkX eq0Ipf4E76q9TTVtU25fUJ7XEotnkNMoEcNbCy5Fip27TgUT/uo7q1q3NZzr4Qe0na6Y L3bg== X-Gm-Message-State: APjAAAW0CkUm5Fxp4B+cvPzcutCP9fQyzMhkORrIwvJ7mx7UA4sGPE8V GKLj62hp8fmRFIUAE8FgMoMkS1Wf X-Google-Smtp-Source: APXvYqziQnKR2bLh0MmszwHVJz3V9EEv7LBaGPxhN1kiyXTlUPI99lRbk2ktH8Cc5nnqAVgyzxfofQ== X-Received: by 2002:a5d:6a02:: with SMTP id m2mr4849125wru.52.1581158169921; Sat, 08 Feb 2020 02:36:09 -0800 (PST) Received: from ?IPv6:2a01:cb1d:111:eb00:1c6:dd42:ea44:b699? ([2a01:cb1d:111:eb00:1c6:dd42:ea44:b699]) by smtp.gmail.com with ESMTPSA id c9sm6767742wme.41.2020.02.08.02.36.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Feb 2020 02:36:09 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> Message-ID: Date: Sat, 8 Feb 2020 11:36:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 10:36:15 -0000 Brian, I'm not sure I understand your phrase "the private key will be scattered around the autonomic domain." Are you suggesting to create a key pair for a role, and if several nodes have the same role, they will have the same private key?!? That strikes me as very unusual... I think we're back to really old concepts of security: A node has an identity and a role. The identity is proven by a certificate. The role (ex: Prefix Manager) is assigned to an identity. And a role may require a specific ASA to fulfil its function. As Toerless points out, we CAN (and do) assign roles statically in a certificate. In the "real" world a diplomatic passport is exactly that: It's an identity of a person, plus a role (diplomat). But that only makes sense for fairly static roles, and I would not suggest that for things like Prefix Manager. There are two alternatives: 1 - We come up with a consensus model (see Toerless' mail). In a distributed model such as ANI very interesting, but I think needs a lot more work. Much more common though: 2 - We maintain a directory (read: a secured database), where we assign roles to identities. This is "normal" in standard security. Role based access control for example, Active Directory, etc. I would vote for a directory type of solution at first. This way an administrator can assign and change roles quite easily. Later we can look into consensus models. I'd need a lot more convincing that certificates for roles (or ASAs) are a good idea. And shared private keys (actually: Contradiction in terms, I probably misunderstood Brian there) definitely not. Michael On 08/02/2020 00:04, Brian E Carpenter wrote: > On 08-Feb-20 03:58, Toerless Eckert wrote: > >> Sure, and i am going to run a hacked ACP node thats announcing in GRASP >> to be the "best-ever" node to provide that service ;-) How to you >> prohibit me to happen ? -> Anser: i dont have a fitting certificate, or >> there is some ACP crowd intelligence that says i am untrustworthy. > I don't see how you can get away from asymmetric crypto to do that. An ASA > comes up and says 'I support "DANGER"', which is a GRASP objective for doing > something very dangerous. Take a concrete example: 'I support "PrefixManager"', > which is defined in draft-ietf-anima-prefix-management and will be in an > RFC one day soon. So this ASA needs to be trusted to allocate or assign > IP address space. > > How can we check this is OK? As far as I can see, only if we have previously > decided to trust any PrefixManager ASA that can prove possession of a given > private key, or more precisely one of a given set of private keys. > > In practical reality, I'm sure operators will want to install identical > binaries of a given ASA on multiple autonomic nodes. So the private key > will be scattered around the autonomic domain. My guess is that a lot of > operators would not see this as any better than just trusting the nodes, > not the individual ASAs. > > Brian > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sat Feb 8 11:05:32 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F561200B1 for ; Sat, 8 Feb 2020 11:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk1QiloYMadY for ; Sat, 8 Feb 2020 11:05:29 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F9E120059 for ; Sat, 8 Feb 2020 11:05:28 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id y5so1508821pfb.11 for ; Sat, 08 Feb 2020 11:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xD3KZiolPWLsNkpAAhiwGzeWc90j+L1R/T6xPh7yGTQ=; b=SH7mXLonSkyCgG0JQKRO4+S1YqvB/rktb5k4RUw+miBzUpn19VtFN9gfCBWTe4NDDn eShw6R8ZkZpRjieTnrGT5jrQ1TTLnRsaBJkbPFkOf5Oyl0DtKumx9xxacVhFb9RdUHOE eaVE2AxO+i1R5V7Mmh5qCRSXQONwMpgAQUJy+WJyUj0+CvIcUafb+XoQLbj9Pip5z646 mO46woSBHj7YOM0T0kgvsxU0I/Hme7jBOyis3O3KDa/gEydtGPt4ah4j1/QvyaHQptpb JEmZnFtSxhXdn2k5ICavYcY+Hu8t6id39JdQtDzseVGJIwkMmR01AmNH5ENGqloUONyp CmJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xD3KZiolPWLsNkpAAhiwGzeWc90j+L1R/T6xPh7yGTQ=; b=EDy/jizoBS50bXITpe0l4/MuyueKZLmZQp5Wy1jwq5zKjmgsgxwueMM8shJsLhjvxM BeEwrNTWKlgOIA6TexH9+jS8hpn7mJmxjuPbfS5PTyc5fXM32wP4w401Rs/e6PU5EwGj /Mhw7zD71AU4Usl9TO3N3/UZ2zWyxlCTRJrLYBc/OWK6ynJyf2MkNsgZoW7F3UMiE5b6 ceiSZ//xCrXgn3SD94vIaDNNYtIxVGTpRy19D4n3RfmhF7DQWJTdDS4l2yiONDdGpMPw VHNT009jRwH8mdBD0lEWtR6iVHPOM0/3mZDT1/KB8XMcg8kBOuhGdAuU4MaTCJKMZLn8 YdRA== X-Gm-Message-State: APjAAAVbnMoT5GLIReA3WALx+j343bGXvcURH16Y128Zeyu/q1CJFGbL aJObB2MJ+TRFP4I+mdkDl6CWgALk X-Google-Smtp-Source: APXvYqyY6V01mNjawWILZjk/zp6XX6R9irUUQesHbS4lImHBwGby3La/PeFN0Of1tRlm84eTdCxPqQ== X-Received: by 2002:a63:9251:: with SMTP id s17mr5831425pgn.127.1581188727988; Sat, 08 Feb 2020 11:05:27 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id w8sm7558889pfj.20.2020.02.08.11.05.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2020 11:05:27 -0800 (PST) To: "Michael H. Behringer" , anima@ietf.org References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> From: Brian E Carpenter Message-ID: <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com> Date: Sun, 9 Feb 2020 08:05:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 19:05:31 -0000 On 08-Feb-20 23:36, Michael H. Behringer wrote: > Brian, I'm not sure I understand your phrase "the private key will be > scattered around the autonomic domain." Are you suggesting to create a > key pair for a role, and if several nodes have the same role, they will > have the same private key?!? That strikes me as very unusual... Yes. But if you're a network operator, you're very pragmatic and if you have an updated binary of an ASA that you need to install on 500 nodes, you won't want to add a complex key management task to the installation. Indeed it's bad security to share a key. I just think that it will happen, if we propose an alternative that is perhaps as complex as BRSKI itself but is applied at the ASA level instead of the node level. > I think we're back to really old concepts of security: > > A node has an identity and a role. The identity is proven by a > certificate. The role (ex: Prefix Manager) is assigned to an identity. > And a role may require a specific ASA to fulfil its function. Make that plural. A node may have mutltiple roles and a role may multiple ASAs. > As Toerless points out, we CAN (and do) assign roles statically in a > certificate. In the "real" world a diplomatic passport is exactly that: > It's an identity of a person, plus a role (diplomat). But that only > makes sense for fairly static roles, and I would not suggest that for > things like Prefix Manager. > > There are two alternatives: > 1 - We come up with a consensus model (see Toerless' mail). In a > distributed model such as ANI very interesting, but I think needs a lot > more work. Much more common though: > > 2 - We maintain a directory (read: a secured database), where we assign > roles to identities. This is "normal" in standard security. Role based > access control for example, Active Directory, etc. > > I would vote for a directory type of solution at first. This way an > administrator can assign and change roles quite easily. Later we can > look into consensus models. I agree entirely, but it wasn't obvious that Toerless was heading in that direction. > I'd need a lot more convincing that certificates for roles (or ASAs) are > a good idea. And shared private keys (actually: Contradiction in terms, > I probably misunderstood Brian there) definitely not. Again, I agree. I was simply speculating about what I expect operators would do if presented with too much complexity. Brian > > Michael > > > On 08/02/2020 00:04, Brian E Carpenter wrote: >> On 08-Feb-20 03:58, Toerless Eckert wrote: >> >>> Sure, and i am going to run a hacked ACP node thats announcing in GRASP >>> to be the "best-ever" node to provide that service ;-) How to you >>> prohibit me to happen ? -> Anser: i dont have a fitting certificate, or >>> there is some ACP crowd intelligence that says i am untrustworthy. >> I don't see how you can get away from asymmetric crypto to do that. An ASA >> comes up and says 'I support "DANGER"', which is a GRASP objective for doing >> something very dangerous. Take a concrete example: 'I support "PrefixManager"', >> which is defined in draft-ietf-anima-prefix-management and will be in an >> RFC one day soon. So this ASA needs to be trusted to allocate or assign >> IP address space. >> >> How can we check this is OK? As far as I can see, only if we have previously >> decided to trust any PrefixManager ASA that can prove possession of a given >> private key, or more precisely one of a given set of private keys. >> >> In practical reality, I'm sure operators will want to install identical >> binaries of a given ASA on multiple autonomic nodes. So the private key >> will be scattered around the autonomic domain. My guess is that a lot of >> operators would not see this as any better than just trusting the nodes, >> not the individual ASAs. >> >> Brian >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Feb 10 07:58:08 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2B71200FB for ; Sun, 9 Feb 2020 04:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.5 X-Spam-Level: ** X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnoysPANE9pT for ; Sun, 9 Feb 2020 04:13:31 -0800 (PST) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BD71200EC for ; Sun, 9 Feb 2020 04:13:30 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:2524:e9c1:846c:80b1]) by relay.sandelman.ca (Postfix) with ESMTPS id 020631F459; Sun, 9 Feb 2020 12:13:28 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5E9311A29B6; Sun, 9 Feb 2020 13:13:28 +0100 (CET) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-reply-to: <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Fri, 07 Feb 2020 15:58:02 +0100." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sun, 09 Feb 2020 13:13:28 +0100 Message-ID: <21784.1581250408@dooku> Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 12:13:33 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> It seems that in an autonomic network that there ought to be a service that >> can be used to ask, "should I trust node FOO to do X?". > Sure, and i am going to run a hacked ACP node thats announcing in GRASP > to be the "best-ever" node to provide that service ;-) How to you > prohibit me to happen ? -> Anser: i dont have a fitting certificate, or > there is some ACP crowd intelligence that says i am untrustworthy. a) How are you going to connect to the ACP? b) If you say that it is because you are going to attack some existing node, then no number of certificate bits are going to help. >> That could be the (cmc)RA or another node so designated. > Right. Thats the "role" indications in certificate approach. And of > course we want to limit that to really "lifetime role assignments" > (lifetime larger than cert lifetime..). But, that's the only role we need. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl4/92gACgkQlUzhVv38 QpCy/gf/V5SvXKUPImFn7qkDG7Inq6V2BKJkSuSwqsVWP3d+m2SEZTPhNG7RMEXs VVzjef2aue6W9MCh9YRRQyNP+j888AxY80b2JtFhAOTz00Thb8T9tMch4cQpVCPi a40DbZRr2dDxYj32mHnq0T3p+03EP2hzkbFiHO7Usuqwpxcqkq8rx3PVQnMP+qKM 56LMUJ1NPbUM3ZVFCgLJTek1RTlcQoUQW+caTMC7jcN/KESOoW8N9Tfq3QDeevKZ wiYoYzBU7hqOfoqtpegFdLO4lkiT7R4kgUgKQIVfr/oFBSWrW80hn94SIn8/gw2I vdCa3fZ7SWEVkJnD2OAr7pWZwTvjbw== =vRLH -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 10 08:05:23 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D731200B4 for ; Mon, 10 Feb 2020 01:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9sra7H4IWOD for ; Mon, 10 Feb 2020 01:26:42 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2899A12008C for ; Mon, 10 Feb 2020 01:26:42 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id g3so5566825wrs.12 for ; Mon, 10 Feb 2020 01:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=RTu6wpP1hxIEB6BON2k6tPRyH+tq2SrUCLdIYxFmx+0=; b=f7URVcysxPKo1QxjD5BY7qg+eLTb5ytepjXCCufa1G8kMoaLdpuEGuuZdqw+yDKZbz vryEsE+Q61o9/bmiODZq9bBWrtgFujmSIu44jD+kG+d1HRduLNGebDXqQ91+T257KDFE e2Li5sTPQINlzfdUdkdp8MnY1zUXSdTDFDuFHqvezvcK19nKZGeKk0w7a+U6MZ7FJzfW AENjR07kcChOhUaqPlyfoz4S1IQ5lbHC/nvtMS9931sZdIyoxkJWZf1GZVA+Vas7M7lW 3KqXprinvzRdILynxoePB6XAKtbrTpycTxQXIjJoBv3LxZdCzDOALd/kqz0Iwei1gsfB hS4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RTu6wpP1hxIEB6BON2k6tPRyH+tq2SrUCLdIYxFmx+0=; b=aAzfpSPj2pjpdw4hVbmlkKm/Iji3i0DR/tJQNYsPohk80UVgi5soZdxsCxAbibyd9B 5NEo34OJnWC1VW0owS2jmzVFoJUc6RssSR7nYvafJjMxsw0LzHOnA+mgjvBOjBkkL1zn X3IT539Qlq08rA0uftjNPKgPYY6CDuUPIw91uACkTZ57nP92f/ZrNTqNLqXAzL3dknaU W0rL+ny5F9+kAXd/S14GpDox+yGR67V7cs3MRkdxGvbpCq8s1LVG7tsoTXLdtcFe/I2J j6tPzCPyp7hGsmoMaN8MOil8evs7A4s6t6YVpIRVtFr8N976G1f3ThoXoaJ9ZE/jePRW gm3w== X-Gm-Message-State: APjAAAUCj+NGicB8/cjtETPLKH6if0ZHAyMgHLnlnpoIYcSkq6ih2Blp PITj/qeAg9eFltEwbZvF8+bD61ws X-Google-Smtp-Source: APXvYqyj4OShIo7MGZmWe6boMs9tDQe5tbquwA42KTY+r3yc8mLCp5iS84Q+m6bKv0tQRj/koMSKeA== X-Received: by 2002:a5d:51ce:: with SMTP id n14mr887495wrv.426.1581326800120; Mon, 10 Feb 2020 01:26:40 -0800 (PST) Received: from ?IPv6:2a01:cb1d:111:eb00:24ff:9485:d3dd:68b9? ([2a01:cb1d:111:eb00:24ff:9485:d3dd:68b9]) by smtp.gmail.com with ESMTPSA id l8sm14816284wmj.2.2020.02.10.01.26.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Feb 2020 01:26:39 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Brian E Carpenter , anima@ietf.org References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com> Message-ID: <5c85e950-41f1-7fa3-cded-7d6c807b9afd@gmail.com> Date: Mon, 10 Feb 2020 10:26:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Anima] Brian/anima: trust notion of ASA communications X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 09:26:45 -0000 On 08/02/2020 20:05, Brian E Carpenter wrote: > On 08-Feb-20 23:36, Michael H. Behringer wrote: >> Brian, I'm not sure I understand your phrase "the private key will be >> scattered around the autonomic domain." Are you suggesting to create a >> key pair for a role, and if several nodes have the same role, they will >> have the same private key?!? That strikes me as very unusual... > Yes. But if you're a network operator, you're very pragmatic and if you have > an updated binary of an ASA that you need to install on 500 nodes, you won't want > to add a complex key management task to the installation. > > Indeed it's bad security to share a key. I just think that it will happen, if > we propose an alternative that is perhaps as complex as BRSKI itself but is > applied at the ASA level instead of the node level. OK, I think we agree: let's make sure that doesn't happen! :-)   In any case, if the goal is to prevent a potential hacker to spin up any ASA on a hacked node, then a key delivered with the ASA won't do the job, right? Because that could potentially be found on another hacked node, and copied as well. We need to first define the problem statement precisely. (Maybe it's just me who doesn't have it clear?) The problem is that a node runs an ASA which it shouldn't. Right? There is however more than one way to get to this situation: 1) A node may be hacked, have all sorts of ASAs installed manually by the hacker, and use those in ways not intended by the operator. ("malicious case") 2) Autonomic nodes may well decide by themselves to run certain functions if needed. ("Erroneous case") I agree with Toerless: The concept with a special bit in the certificate isn't all that bad. If it's a pretty static function, it's perfectly appropriate. (Like a diplomatic passport). Let's not throw this out. As Toerless said: "crowd intelligence based on client measured service performance experience" would be a solution to the 2nd case. But that's to me for further study, not a short-term goal. And that may well be different for different types of ASA. The middle way would be a centrally controlled directory, that nodes can query. Needs more thinking. Do we want to check permissions for all types of ASAs? How long can you cache permissions? Do we want to define different "security levels" of ASAs, to distinguish between "to be checked at each usage" and "trust crowd intelligence" and "trust implicitly"? Should we just re-use an existing scheme for that? (AAA?) This isn't going to happen in a rush... Michael > >> I think we're back to really old concepts of security: >> >> A node has an identity and a role. The identity is proven by a >> certificate. The role (ex: Prefix Manager) is assigned to an identity. >> And a role may require a specific ASA to fulfil its function. > Make that plural. A node may have mutltiple roles and a role may > multiple ASAs. Yes. The word "a" was not meant as an enumeration. >> As Toerless points out, we CAN (and do) assign roles statically in a >> certificate. In the "real" world a diplomatic passport is exactly that: >> It's an identity of a person, plus a role (diplomat). But that only >> makes sense for fairly static roles, and I would not suggest that for >> things like Prefix Manager. >> >> There are two alternatives: >> 1 - We come up with a consensus model (see Toerless' mail). In a >> distributed model such as ANI very interesting, but I think needs a lot >> more work. Much more common though: >> >> 2 - We maintain a directory (read: a secured database), where we assign >> roles to identities. This is "normal" in standard security. Role based >> access control for example, Active Directory, etc. >> >> I would vote for a directory type of solution at first. This way an >> administrator can assign and change roles quite easily. Later we can >> look into consensus models. > I agree entirely, but it wasn't obvious that Toerless was heading in that > direction. > >> I'd need a lot more convincing that certificates for roles (or ASAs) are >> a good idea. And shared private keys (actually: Contradiction in terms, >> I probably misunderstood Brian there) definitely not. > Again, I agree. I was simply speculating about what I expect operators would > do if presented with too much complexity. > > Brian > >> Michael >> >> >> On 08/02/2020 00:04, Brian E Carpenter wrote: >>> On 08-Feb-20 03:58, Toerless Eckert wrote: >>> >>>> Sure, and i am going to run a hacked ACP node thats announcing in GRASP >>>> to be the "best-ever" node to provide that service ;-) How to you >>>> prohibit me to happen ? -> Anser: i dont have a fitting certificate, or >>>> there is some ACP crowd intelligence that says i am untrustworthy. >>> I don't see how you can get away from asymmetric crypto to do that. An ASA >>> comes up and says 'I support "DANGER"', which is a GRASP objective for doing >>> something very dangerous. Take a concrete example: 'I support "PrefixManager"', >>> which is defined in draft-ietf-anima-prefix-management and will be in an >>> RFC one day soon. So this ASA needs to be trusted to allocate or assign >>> IP address space. >>> >>> How can we check this is OK? As far as I can see, only if we have previously >>> decided to trust any PrefixManager ASA that can prove possession of a given >>> private key, or more precisely one of a given set of private keys. >>> >>> In practical reality, I'm sure operators will want to install identical >>> binaries of a given ASA on multiple autonomic nodes. So the private key >>> will be scattered around the autonomic domain. My guess is that a lot of >>> operators would not see this as any better than just trusting the nodes, >>> not the individual ASAs. >>> >>> Brian >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> From nobody Mon Feb 10 09:25:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B19A12002F for ; Mon, 10 Feb 2020 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV55XbC6Nfnb for ; Mon, 10 Feb 2020 09:25:38 -0800 (PST) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12A4120812 for ; Mon, 10 Feb 2020 09:25:38 -0800 (PST) Received: by mail-qt1-x841.google.com with SMTP id v25so5705121qto.7 for ; Mon, 10 Feb 2020 09:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=soPfSv7VybHrS6PcMnQpIlY31ikZFKKwDKic0sz+A7I=; b=ELlKcyqjms5/rrlwiyk2mbierOI3mFAj0R9HxZiPe4o15yzFNGmMQRW5/gf1/Pk9t6 Uo5Yn8p9ZwTYg11FjZLsNWxzxND9dRE9smWI0FpH3LRwVICgwht0Svp2jCxKp/I7YAdG XuTvC/7bDVd8NOtmMeFUeDjWMYaIBXnbr+LfCfvykPJJIn3xpQNnFBDRplWKKqK66w3i WoNx9OXmAZSirt20sjQqEOtsjg4xkvKGz8goBbtACIcgBC1kkCAXarJV41mWXZm/DWlK eNdf8ivkQDeE+cJ6A2FeSzl1eCdrUgUOJTVKr9K0+USIfGnX/m/Ag93OEaFkUnBUOe71 1eWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=soPfSv7VybHrS6PcMnQpIlY31ikZFKKwDKic0sz+A7I=; b=tbZXXpaWvkv9hirY8iRqVcJki3ijgrrTmVt/+Xbi4sOLVBQfQDTjZOD2wVW/3YJx9F AvnQpBnKX+4ARW7+bV3Yl++RwnvP5ysRyzC57vfYJU7DrO/aqtrOxdImD2TyiL4/Uoo7 f0ivFe+P4+W02k9mdEmXzBeAZmoDo8J4X89GmHY+EOVlCLXpmOSWpugsXHwjKftI1XHy qKnH9doTTEUU43mh2ncC2/HPzbIn0YVf+o65A+2Tl5ZiVD7SvHZpqXAE6T0peJB4TwKM Pph+drc+6c3v/UxjpNKl2CwM4kdN1o2VZbFBP/foJj11XGafZzXybvEz8sJzxB3QZS2q vOhQ== X-Gm-Message-State: APjAAAUCjUODgmsw4brirrRmNSfl6BUpavulYwMomBrLY0uMSkEDUXma 09YKhEx/jlF8qgS4G0ttDSmHf6bPymz8ySCY9beld9MyHXg= X-Google-Smtp-Source: APXvYqwwBgAN/ypXioN9zuTcfzChgRTbgKvI77S/FhuYUGm2ltso7Efaoa7xr/vOMdm+OCCnxmviWqyHygzyFegh0G0= X-Received: by 2002:ac8:5215:: with SMTP id r21mr10744236qtn.77.1581355537021; Mon, 10 Feb 2020 09:25:37 -0800 (PST) MIME-Version: 1.0 References: <157688107174.4079.10454309821544008060.idtracker@ietfa.amsl.com> <5018.1577823353@localhost> <20200103220936.GC57294@kduck.mit.edu> In-Reply-To: <20200103220936.GC57294@kduck.mit.edu> From: Warren Kumari Date: Mon, 10 Feb 2020 12:24:59 -0500 Message-ID: To: Benjamin Kaduk Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 17:25:41 -0000 Heyya Benjamin, I just wanted to make sure that you had seen that the version -35 has been posted, and, I believe, addresses your DISCUSS position - https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ Specifically: ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-34&url2=draft-ietf-anima-bootstrapping-keyinfra-35 I'm going to be traveling soon, and would really appreciate it if you have the time to confirm / clear, W On Fri, Jan 3, 2020 at 5:10 PM Benjamin Kaduk wrote: > > On Tue, Dec 31, 2019 at 03:15:53PM -0500, Michael Richardson wrote: > > > > A diff against -31 is at: https://tinyurl.com/vuls2ge > > and will be posted as -32 in a few minutes. > > Commit with edits here: https://github.com/anima-wg/anima-bootstrap/commit/0bdd9aaf206b0f2d70c51a7c9636a8249fd1366f > > > > BTW: I haven't heard from Roman since IETF107. > > I am also converting to v3 format now, so there are some slight formatting > > changes. (*->o, some extra spaces in places) > > > > I have addressed all of your comments, and I've checked that all the -29 > > comments have been addressed. > > > > Benjamin Kaduk via Datatracker wrote: > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > Thanks for providing a clear specification of the /enrollstatus EST > > > endpoint in the -30. The following two points still seem unaddressed, > > > though. > > > > > The -29 reworks the definition of the 'nonce' field to be: > > > > > strong random or pseudo-random number nonce (see [RFC4086] > > > section 6.2). As the nonce is usually generated very early in the boot > > > sequence there is a concern that the same nonce might generated across > > > multiple boots, or after a factory reset. Difference nonces MUST NOT > > > generated for each bootstrapping attempt, whether in series or > > > concurrently. The freshness of this nonce mitigates against the lack > > > of real-time clock as explained in Section 2.6.1. > > > > > This needs to either be "Different nonces MUST be generated" or "the > > > same nonce MUST NOT be reused"; this mashup is no good. > > > > Fixed. > > > > > Email exchange with mcr notes: > > >> > An RFC Editor note about the RFC 8366 assignment of OID > > > >> 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the > > >> examples > properly use that assigned OID now? > > >> > > >> We got a MASA URL Extension OID for: 1.3.6.1.5.5.7.1.32 > > >> > > >> the examples date from before that, and do not use it yet. > > > > > We need to fix the examples before publication. > > > > Yes, I believe that there will be time to update them while in RFC editor > > queue. I want the examples to be produced by code that has interoperated. > > That's a reasonable desire, but not a compelling reason why the document > has to go to the RFC Editor before the examples are correct. > Perhaps adding an RFC Editor note that the extension OID used must be the > one allocated by IANA, akin to what's done in > https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-08#page-10 , > would be appropriate? > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > A few new comments on the -30 and -31 to start. I think some of my > > > comments on the -29 are still valid, and will try to remove ones that > > > have been addressed. To reiterate: to the best of my knowledge, all > > > the comments in this ballot position are actionable and have not been > > > overtaken by events. > > > > okay. > > > > > In Section 5.9.4: > > > > > In the case of a FAIL, the same TLS connection MUST be used. The > > > Reason string indicates why the most recent enrollment failed. > > > > > I'd suggest something more like "In the case of a failed enrollment, > > > the client MUST send the telemetry information over the same TLS > > > connection that was used for the enrollment attempt, with a Reason > > > string indicating why the most recent enrollment failed. (For failed > > > attempts, the TLS connection is the most reliable way to correlate > > > server-side information with what the client provides.)" (Also, why is > > > "FAIL" capitalized?) > > > > I have used your text. The fail was capitalized because bold is not available. > > Further down, we capitalize SUCCESS. > > > > > Thanks for the text in Section 11.2 about second-preimage-resistance of > > > DomainID calculation; the grammar needs a tweak or two, though. My > > > suggestion would be to either drop "The consequences of" or add "be to" > > > to make "would be to allow" (but not both). > > > > Done. > > > > > Section 11.3 has gone back to just "Devices which are reset to factory > > > default in order to perform a second bootstrap with a new owner MUST > > > NOT use idential seeds", but I think it's important to be clear about > > > what the scope of uniqueness is. The text in Section 5.2 is pretty > > > good in this regard, with respect to the nonces (which are generally > > > derived from the seed); I wonder if we might want to restructure this > > > text to be more like "The random seed used by a device at boot MUST be > > > unique across all devices and all bootstraps. Resetting a device to > > > factory default state does not obviate this requirement." (FWIW, I > > > think the text in the -29 was that way because of my request.) > > > > Done. > > > > > In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies > > > both base64 and base64url, so a section reference is usually > > > appropriate (and in Section 5 we do give a section reference into RFC > > > 4648). > > > > okay, section 4 is "base64", added. > > > > > Section 9.1 > > > > > Other use cases likely have similar, but MAY different requirements. > > > > > nit: ", but MAY have different, requirements" > > > > fixed. > > > > > Section 9.1.1 > > > > > Authentication process. The MASA creates signed voucher artifacts > > > according to a it's internally defined policies. > > > > > nit: s/a it's/its/ > > > > fixed. > > > > > Section 9.1.3 > > > > > (Do we need to say "DULL" specifically again here for Join Proxy > > > discovery? Maybe not...) > > > > yes, I think that we need to say this again, as many people get upset about > > having a full GRASP daemon visible on the insecure side. > > I think I missed this in the -32. > > > > [All new comments for the -28] > > > > rechecking. > > > > > Please respond to the secdir re-review. > > > > This is in message: > > > > to recap: > > 1) 10.3, "The so-called "call-home" mechanism that occurs as part of the > > > > was toned down. > > > > 2) the TLS 1.3 text was already improved. > > > > 3) section 5.4.1, "This document does not make a specific recommendation" > > (regarding whether to use public PKI, DANE, or pinned certificates for MASA > > authentication. > > > > I don't think we can make a statement about the needs here at this point, and > > why we have the PS->IS step. Note that I wrote > > https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > > Okay, thanks for the discussion. > > > > > > Section 2.6.1 > > > > > A pledge with a real time clock in which it has confidence in, MUST > > > check the above time fields in all certificates and signatures that it > > > processes. > > > > > nit: s/in// from "in which it has confidence in" (your choice which > > > one). > > > > I see now, fixed. > > > > > Section 4 > > > > > This section applies is normative for uses with an ANIMA ACP. The > > > > > nit: pick one of "applies to" or "is normative for". > > > > already fixed. > > > > > [...] The use of GRASP mechanism part of the ACP. Other users of > > > BRSKI will need > > > > > nit: missing "is", "the" > > > > fixing. > > > > > Section 5.7 > > > > > The Status field indicates if the voucher was acceptable. Boolean > > > values are acceptable. > > > > > nit: I suggest """acceptable, as a boolean, where "true" indicates the > > > voucher was acceptable""". > > > > already fixed. > > > > > Section 10.6 > > > > > Section Section 7.4.3 describes some ways in which a manufacturer > > > > > nit: duplicate "Section". > > > > already fixed. > > > > > Section 10.7 > > > > > existing products. Said products might be previous deployed and > > > need to be re-initialized, purchased used, or just kept in a warehouse > > > as long-term spares. > > > > > nit: s/previous deployed and need/previously deployed that need/ > > > > already fixed. > > > > > Section 11.2 > > > > > In particular implementations should pay attention to the advance in > > > [RFC4086] section 3, particulary section 3.4. Devices which are reset > > > to factory default in order to perform a second bootstrap with a new > > > owner MUST NOT seed their random number generators in the same way. > > > > > nit: s/same way/same way across bootstraps/ > > > > already fixed with different text. > > > > > Section 11.3 > > > > > We had some discussion around my previous comment: > > > > > % Additionally, in order to successfully use the resulting voucher the > > > % Rm would have to attack the pledge and return it to a bootstrapping % > > > enabled state. This would require wiping the pledge of current > > > % > > > % ... and I think there is a different attack if the Rm is in a > > > position % to delay or drop network traffic between the pledge and the > > > intended % registrar, to cause Rm's voucher to be delivered first even > > > though it is % generated after the intended registrar's authorization > > > process. The % intended registrar would need to require reports on > > > voucher processing % status (or investigate their absence) in order to > > > detect such a case. > > > > > but I can't remember if we decided that we didn't need to discuss the > > > risk in the document. [ed. I also can't remember if we had discussion > > > about this comment] > > > > We did. > > We worked hard to create the Rm attack situation, and had to assume some > > other failures to even get to this discussion. > > I think that this follows into the "if these ten unlikely things all occur, > > then you should consider if you are living in simulation" category. > > Thank you for coping with my poor memory. > > Also for all the updates, and yet again for your patience and > perserverance. > > -Ben > > > > ======================================================================= > > > > > I trimmed all the "Additional comments since posted ballot position on > > > -28" that were in my previous ballot position, as they are likely stale > > > by now. > > > > Thank you. > > > > > -- > > ] Never tell me the odds! | ipv6 mesh networks [ > > ] Michael Richardson, Sandelman Software Works | IoT architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Feb 10 09:55:57 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD94912001B for ; Mon, 10 Feb 2020 09:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSpR-F9-1SIB for ; Mon, 10 Feb 2020 09:55:53 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C00C12001A for ; Mon, 10 Feb 2020 09:55:53 -0800 (PST) Received: from dooku.sandelman.ca (ip5f5bd76d.dynamic.kabel-deutschland.de [95.91.215.109]) by relay.sandelman.ca (Postfix) with ESMTPS id C79BC1F459 for ; Mon, 10 Feb 2020 17:55:51 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3308A1A29B4; Mon, 10 Feb 2020 18:55:51 +0100 (CET) From: Michael Richardson To: anima@ietf.org In-reply-to: References: Comments: In-reply-to Esko Dijk message dated "Mon, 10 Feb 2020 08:00:33 -0800." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Mon, 10 Feb 2020 18:55:51 +0100 Message-ID: <1272.1581357351@dooku> Archived-At: Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 17:55:56 -0000 --=-=-= Content-Type: text/plain In https://github.com/anima-wg/constrained-voucher/issues/49, Esko Dijk asks: > In BRSKI (5.5.2 MASA pinning of registrar) it is clear how the MASA can > get the complete cert chain of the Registrar from the CMS signature > structure. The Registrar's Domain CA cert is included in there and is used > as the pinned domain cert in the Voucher. However, when we now use > COSE-signed Voucher Request by the Registrar, the Registrar's Domain CA > cert is not included in the COSE-sign structure so the MASA cannot > "extract" it per BRSKI 5.5.2. > It would be good to make more explicit how the MASA should extract the > Registrar's Domain CA cert in this case (Note: the Domain CA could be the > Registrar itself but not necessarily.) The obvious candidate is to get it > from the DTLS or TLS handshake that Registrar performs with MASA. This is > already hinted at in the text in section 6.1.3 / 6.2.3 inside the YANG > module description "... it is wasteful ... " but that is not quite > clear. When Registrar is using COSE signing the MASA *has* to get the > certificate from the handshake if the MASA wants to pin the entire > certificate in the Voucher, there seems to be no other option. Section > 6.3.2 now mentions "out of band" distribution but that's not very clever if > you want automated bootstrapping - it needs to go all in-protocol / > in-band. > It should be noted also that this modifies the BRSKI requirement section > 5.5.2 on how the pinned Domain CA cert is obtained. In the more constrained cases, the Registrar is identified by a Raw Public Key. [This works in DTLS and will work in LAKE by design] This is what should be pinned by the MASA, because that's what the pledge saw. If you are using a certificate chain for the Registrar end point, the MASA does not have to pin the Domain CA, it can instead pin the Registrar certificate, since again, that's what the pledge saw (and signed). If you want us to define a way to pin the domain CA, then I think that right answer is to pass that entire chain along to the Pledge in the BRSKI-EST channel in the DTLS header, and have the pledge sign that entire object. This wouldn't be very constrained, so I am not sure why one would do this rather than using TLS in that case. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl5BmSYACgkQlUzhVv38 QpABSAf+Jc6IvWInK7RYtaTOfu7+4JCjIDCJVj/hyZbodRGLT46dkBh9qdhTe08I yWWIGYk2nwkQ/Lnrzt2T70nUA/ucKh6FNdAMiyLaF5jLa1ezB4xuNvaRRkRgxilE W4oJqs16ap86645NiccFe9Ux1/IdZmV0vfg2H35M0N/eJ+XGyLD4unUhnf4TMAaU wfuNvrPqZOTIDkNwkqsanv/pTrvrJQXEtzi+jgxPowHQkcBj+nq+zyDd0WtANyQe vB4K2ToPnVi6uJHEDNALhjQssMYO/OKyQQ0BgrjvuNDQ13ayEGI4rAyuKoGct/ng e71UA8nSfGgKzt9KuRjQ6CaUsP9WMw== =vNOZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 10 10:05:19 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ABC12080E; Mon, 10 Feb 2020 10:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9EGj860GkFw; Mon, 10 Feb 2020 10:05:13 -0800 (PST) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFC012001A; Mon, 10 Feb 2020 10:05:13 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:584d:5a6f:7ed3:c298]) by relay.sandelman.ca (Postfix) with ESMTPS id A494D1F459; Mon, 10 Feb 2020 18:05:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1AB851A29B4; Mon, 10 Feb 2020 19:05:10 +0100 (CET) From: Michael Richardson To: "M. Ranganathan" , Kent Watsen , anima@ietf.org cc: iot-onboarding@ietf.org In-reply-to: References: Comments: In-reply-to "M. Ranganathan" message dated "Sun, 09 Feb 2020 22:27:49 -0500." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Mon, 10 Feb 2020 19:05:10 +0100 Message-ID: <1556.1581357910@dooku> Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 18:05:15 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > I am wondering if the format of the example should be > { > "ietf-voucher:voucher-artifact": { > "voucher": { > "created-on": "2016-10-07T19:31:42Z" > ...... > instead of > { "ietf-voucher:voucher": > { "created-on": "2016-10-07T19:31:42Z", > "assertion": "logged", > Based on the yang hierarchy (tree diagram). No, the tree diagam is wrong. I'm not sure what to do exactly. > I am going by what ygot is producing. I had to change the yang-data to > a container for ygot to work - perhaps this is the reason why the > output is different? Not sure if this is quite right but I thought > I'd just point it out. It seems that there should be an errata. Kent, is there a way we can change the YANG to match things correctly? It seems that we might change: // Top-level statement rc:yang-data voucher-artifact { uses voucher-artifact-grouping; } to: rc:yang-data voucher { === Or, do you think that we should changing the BRSKI document to match? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl5Bm1UACgkQlUzhVv38 QpAjqgf9H48kPs0gbxdQh82DqIYg4H3XYAxyaIbCxS/Ik8oqEjtgXLINOWhdGEjh 6kvo/Ro0jh1UcgyNg0AOpDcOzUnDacqNITPVQBKccaVTmvEx2b+3x1RU5d9VrC1F 2CAL/wpJrG0nEgzxoQbMzk+D98OhvEdRVicvedak1iK3bZb86ClQsasZaeLzkz4S 8YvPn2Jl+Br/UCt5JGACRuoMc6HaH6FmIXHlr2bnfklMYrS4x64AvCBbREs/RMXC td/w1PUmiBvrGweZr4pUfFnamMAYAslvFT8XhIzwN5bDxRpk3xx1KQDTMk0PtuqI SGVgEDll5TJzOKb3C/03sIYxePQZLA== =Qpib -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 10 14:33:30 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3B120878; Mon, 10 Feb 2020 14:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzV6Y1qMk2_9; Mon, 10 Feb 2020 14:33:23 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1381120879; Mon, 10 Feb 2020 14:33:22 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 882D954806B; Mon, 10 Feb 2020 23:33:17 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 80C87440040; Mon, 10 Feb 2020 23:33:17 +0100 (CET) Date: Mon, 10 Feb 2020 23:33:17 +0100 From: Toerless Eckert To: "Eric Vyncke (evyncke)" Cc: Benjamin Kaduk , "anima-chairs@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , The IESG , "anima@ietf.org" , "jiangsheng@huawei.com" Message-ID: <20200210223317.GA31783@faui48f.informatik.uni-erlangen.de> References: <20191230173030.GJ35479@kduck.mit.edu> <20200204044933.GA22702@faui48f.informatik.uni-erlangen.de> <3CF6794C-63E6-4078-A55F-329E874FEFC5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3CF6794C-63E6-4078-A55F-329E874FEFC5@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 22:33:25 -0000 Email last week may have been off-list, so let me repeat for the WG: Working on -23 to address your review, Eric. At a conference mon-wed, so a bit slower finishing it. There are still outstanding points from Ben, he is on PTO this week, but hopefully we can finish those next week. Cheers Toerles On Tue, Feb 04, 2020 at 07:30:34AM +0000, Eric Vyncke (evyncke) wrote: > Toerless > > Thank you for this updated revision. > > About the next steps: > > ???On 04/02/2020, 05:49, "iesg on behalf of Toerless Eckert" wrote: > > Hi Benjamin > > -----%<------%<----- > > > That said, my one Discuss point is not the end of the road for things; > > since as I understand it the WG has already considered the topic > > extensively, it may be time to check with the responsible AD about bringing > > the document back on a telechat with, e.g., an alternate ballot procedure > > ("single-discuss" or the full-on "alternate procedure" from > > https://ietf.org/standards/process/iesg-ballots/). I don't remember > > hearing much from any other IESG members on this topic, at least as of yet. > > Not quite sure i follow everything you say: My understanding is that > E'ric is now the responsible AD for the document, so we authors will simply > follow his guidance for any further necessary AD review . > > Given how we already had a lot of exhaustive and good reviews and resulting > fixes, i hope the poor ADs will not be forced to repeat potentialy unnecessary > work on such a big document given how the fixes are all well documented and > also summarized now in the changelog (summarizing IESG review up to -21 and explaining > that there are no fundamental changes just a good amount of detail fixes > and textual improvements). But this is my first RFC as big as this, > so i have no prior good experience with the process in a case like this. > > As I am the 'poor' responsible AD now, with the amount of changes in the document, an IETF-wide Last Call is required to ensure a swift process. As soon as I am confident that -22 is 'good to go', then I will start this Last Call, then IESG evaluation, ballot and telechat and hopefully the document will be approved before the new IESG. > > Regards, > > -éric > > ----%<-----------%<---------- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Feb 10 14:45:39 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5626C120879; Mon, 10 Feb 2020 14:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5LmnU2ZIzx7; Mon, 10 Feb 2020 14:45:35 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4780120870; Mon, 10 Feb 2020 14:45:35 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6C66F548042; Mon, 10 Feb 2020 23:45:30 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6492F440040; Mon, 10 Feb 2020 23:45:30 +0100 (CET) Date: Mon, 10 Feb 2020 23:45:30 +0100 From: Toerless Eckert To: Warren Kumari Cc: iana-matrix-comment@iana.org, Ignas Bagdonas , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20200210224530.GC31783@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] [IANA #1159845] Upcoming Parameter Expiration: Early IANA Allocations for draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 22:45:37 -0000 On Tue, Jan 21, 2020 at 06:13:42PM -0500, Warren Kumari wrote: > [ - people directly, +ANIMA (for information sharing, and to avoid > tripping the "Too many recipients!" trigger) ] > Dear Chairs / Author / WG, > > I have no history here, but seeing as the document status was changed > to "Submitted to IESG for Publication" on 2018-07-25 (-16) , and has > been updated 18 times (Gadzooks!) since then[0] I have to assume that > the authors are actively working on this, and so it would be churlish > to not approve renewal. > > Can someone summarize for me where this currently stands? (This isn't > my WG, there are literally hundreds of mails on this, and it was a > long time since I last read / balloted on this). I hope that all temporary assignments needed for ongoing prototyping/interop testing are done now, if not, i hope one of the co-authors will chime in and kick my WG chair behind. I did ask for one missing assignment we procrastinated on, that came through ca. 2 weeks ago. Cheers Toerless > W > > > [0]: most recently on January 3rd, 2020 > > > On Tue, Jan 21, 2020 at 5:02 PM Amanda Baber via RT > wrote: > > > > Dear Chairs/ADs, > > > > Please see the renewal request below. > > > > Best regards, > > > > Amanda Baber > > Lead IANA Services Specialist > > > > On Thu Jan 09 04:17:44 2020, amanda.baber wrote: > > > Dear Chairs/ADs: > > > > > > The following registration made on behalf of draft-ietf-anima- > > > bootstrapping-keyinfra is set to expire on 2020-02-20: > > > > > > Registry: SMI Security for PKIX Certificate Extension > > > (1.3.6.1.5.5.7.1) > > > Reference: draft-ietf-anima-bootstrapping-keyinfra > > > URL: https://www.iana.org/assignments/smi-numbers > > > Dates: registered 2019-02-20, expires 2020-02-20 > > > > > > Please let us know whether you want to renew or let the allocation > > > expire. We need replies from both a chair and an AD. > > > > > > If the chairs believe that the RFC 7120 requirements for early > > > allocation renewal have been met, and the AD concurs, we can update > > > the registry now to move the expiration date forward to 2021. > > > > > > Please see RFC 7120, and particularly Section 3.3, for rules > > > concerning the renewal of early allocations: > > > > > > http://www.rfc-editor.org/rfc/rfc7120.txt > > > > > > Please note that a second renewal (from 2021 until 2022) would require > > > permission from the IESG. > > > > > > Best regards, > > > > > > Amanda Baber > > > Lead IANA Services Specialist > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Feb 10 15:12:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EE712088C; Mon, 10 Feb 2020 15:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5YF1zeTEfyL; Mon, 10 Feb 2020 15:12:39 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFDC120880; Mon, 10 Feb 2020 15:12:39 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0FF9B548015; Tue, 11 Feb 2020 00:12:34 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 082F5440040; Tue, 11 Feb 2020 00:12:34 +0100 (CET) Date: Tue, 11 Feb 2020 00:12:33 +0100 From: Toerless Eckert To: anima@ietf.org Cc: draft-liu-anima-grasp-distribution@ietf.org Message-ID: <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> References: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 23:12:41 -0000 We had 5 voices feedback (from non-authors) to support adoption of this document, and no voices objecting. I think this qualifies for adoption of the document. Nevertheless, the supporting voices did indicate a range of improvements they would like to see. So, jere is what i would propose: Dear-authors: A) Please add a section Open Issues, mark it as [RFC-Editor: To Be removed before becoming RFC]. Make it contain the following text: The following issues where identified by the WG when adopting the -00 draft version. These issues will be individually removed in upcoming when they are resolved. 1. More reference to the use cases in the introduction. 2. Better explanation of the required context of the Connected-Car case: Not applicable unless the ACP will be extended to the car, which may not be desirable with the current ACP design, but maybe refocussing on an "autonomous fleet" use-case (e.g.: all cars operated by some taxi like service). 3. Consider use-case/example of firmware update. By abstracting the location of the firmware from the name of the firmware, while providing a way to notify about it, this significantly supports distribution of firmware updates. References to SUIT would appropriate. 4. Issues discussed in https://mailarchive.ietf.org/arch/msg/anima/_0fYQPBcLPt8xzQee7P4dILsn3A 5. Rethink/refine terminology, e.g.: "module" seems to be too prescriptive. Refine proposed extensions. 6. I support adoption, but also support the suggestion (from IETF106) Provide more protocol behavior description instead of only implementation / software module architecture description. Reduce the latter or provide better justification for their presence due to explained interoperability requirements. 7. Better motivation in sections 1..4 of the proposed extensions 8. Consider moving examples from appendices into core-text . Ideally craft a single use-case showing/applying all extensions (most simple use case that uses them all). 9. Refine terminology to better match/reuse-the established terminology from the pre-existing ANIMA documents. B) Add changelog section, equally marked as to be removed before . For this version -00 it should just list above section from A) to be new. C) Designate in the authors list one or two main editors for the time being, doesn't have to be final, just whoever has the main edit pen from you. Post this version as -00 with name draft-ietf-anima-grasp-distribution-00 and replacing draft-liu-anima-grasp-distribution I will then approve that doc as WG chair. D) Feel free to work on -01 and further. In the changelog, please describe for each change which of the above 9 points are addressed by the change and concentrate on those changes first before addressing further enhancements. E) I would strongly suggest you authors consider to create a repo for this document under www.github.com/anima-wg It specifically makees it easier to open for each of the above 10 bullet points possible "Issues" where it would be easier to have focussed discusses. I am not a github is the only way groupie though, so please make sure all discussions are Cc'ed to the mailing list, even though it may primarily be on github to make then easier to track/find. Cheers Toerless On Mon, Jan 13, 2020 at 12:45:33PM +0100, Toerless Eckert wrote: > This message starts a two-week adoption call, it ends on January 27th, 2020. > > draft-liu-anima-grasp-distribution was progressed up to version -13 with > the help of the WG, it was last presented at IETF106 with good interest. > The draft is now clearly in scope of ANIMA charter 2 that was adopted > around IETF106. The authors asked for adoption of the document. > As far as the chairs heard, there was no objection in the room. > > We therefore are asking the ANIMA working group for adoption of the following work: > > Title: Information Distribution in Autonomic Networking > Name: draft-liu-anima-grasp-distribution > Authors: B. Liu, X. Xiao, A. Hecker, S. Jiang, Z. Despotovic > URL: https://datatracker.ietf.org/doc/draft-liu-anima-grasp-distribution/ > > This document is intended to become a standards track ANIMA WG document. > > Standard track is desired because it is meant to become the required > small set of protocol extensions to the GRASP protocol in support of > the self-organization of ASA. > > Please express your support or rejection. If you think this document > should _not_ be adopted, please also explicitly indicate the reasons. > > For the ANIMA WG chairs, > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Feb 10 16:25:27 2020 Return-Path: <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8405A120071; Mon, 10 Feb 2020 16:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-VJLjFlWWlU; Mon, 10 Feb 2020 16:25:22 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C592012089D; Mon, 10 Feb 2020 16:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581380720; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=sV+q+ECW72LvIwH7zCd3nUqni/qLhx5D2RQVsuGGYao=; b=mffRuhl73hE2h6gD384mS2YZ1QoVE3KLmBH+Xa0QppULA3kJvfUEjbYBLE0mI+42 2qpzucwjIf7hP4+c9oXxgXSQLLzxv88LEvJoXc7rTLGEVWVEoIbJyNPyaaFKFXHCCcy 7JbvsSKyJ3fyC5+Zn/ZAhGaRr7KN3+n2WqPNAxAg= From: Kent Watsen Message-ID: <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_152D9D99-5507-481D-A67E-CECAB0D000F6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Feb 2020 00:25:20 +0000 In-Reply-To: <1556.1581357910@dooku> Cc: "M. Ranganathan" , Kent Watsen , anima@ietf.org, iot-onboarding@ietf.org To: Michael Richardson References: <1556.1581357910@dooku> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.11-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 00:25:24 -0000 --Apple-Mail=_152D9D99-5507-481D-A67E-CECAB0D000F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> I am wondering if the format of the example should be >> { >> "ietf-voucher:voucher-artifact": { >> "voucher": { >> "created-on": "2016-10-07T19:31:42Z" >> ...... >> instead of >=20 >> { "ietf-voucher:voucher": >> { "created-on": "2016-10-07T19:31:42Z", >> "assertion": "logged", >=20 >> Based on the yang hierarchy (tree diagram). >=20 > No, the tree diagam is wrong. > I'm not sure what to do exactly. The tree diagram and examples in RFC 8366 are all correct. The examples = were validated via this script: = https://github.com/anima-wg/voucher/blob/master/refs/validate-all.sh = . The confusion is likely because folks expect that the =E2=80=9Cyang-data=E2= =80=9D extension define a node, but it doesn=E2=80=99t. It acts more = like a YANG =E2=80=9Cgrouping=E2=80=9D than a YANG =E2=80=9Ccontainer=E2=80= =9D in that regard. For instance, give the YANG: rc:yang-data foo { leaf bar { type string; } } A valid =E2=80=9Cfoo=E2=80=9D instance document (in JSON) would be: { =E2=80=9Cbar=E2=80=9D: =E2=80=9Cthis is a string.=E2=80=9D } Kent >> I am going by what ygot is producing. I had to change the yang-data = to >> a container for ygot to work - perhaps this is the reason why the >> output is different? Not sure if this is quite right but I thought >> I'd just point it out. >=20 > It seems that there should be an errata. >=20 > Kent, is there a way we can change the YANG to match things correctly? > It seems that we might change: >=20 > // Top-level statement > rc:yang-data voucher-artifact { > uses voucher-artifact-grouping; > } >=20 > to: > rc:yang-data voucher { >=20 > =3D=3D=3D > Or, do you think that we should changing the BRSKI document to match? --Apple-Mail=_152D9D99-5507-481D-A67E-CECAB0D000F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I am wondering if the format of the example should be
{
"ietf-voucher:voucher-artifact": {
"voucher": {
"created-on": = "2016-10-07T19:31:42Z"
......
instead of

{ "ietf-voucher:voucher":
{ "created-on": = "2016-10-07T19:31:42Z",
"assertion": "logged",

Based on the yang hierarchy (tree diagram).

No, the tree diagam is wrong.
I'm not sure what to do exactly.

The = tree diagram and examples in RFC 8366 are all correct.  The = examples were validated via this script: https://github.com/anima-wg/voucher/blob/master/refs/validate-a= ll.sh.


The confusion is likely because folks expect that = the =E2=80=9Cyang-data=E2=80=9D extension define a node, but it = doesn=E2=80=99t.  It acts more like a YANG =E2=80=9Cgrouping=E2=80=9D= than a YANG =E2=80=9Ccontainer=E2=80=9D in that regard. For instance, = give the YANG:

= rc:yang-data foo {
  leaf bar {
  =   type string;
  }
= }

A valid =E2=80=9Cfoo=E2=80=9D= instance document (in JSON) would be:

{
  =   =E2=80=9Cbar=E2=80=9D: =E2=80=9Cthis is a = string.=E2=80=9D
}


Kent



I am going by what ygot is producing. I had to = change the yang-data to
a container for ygot to work - = perhaps this is the reason why the
output is different? =  Not sure if this is quite right but I thought
I'd = just point it out.

It seems = that there should be an errata.

Kent, is = there a way we can change the YANG to match things correctly?
It seems that we might change:

=   // Top-level statement
=   rc:yang-data voucher-artifact {
=     uses voucher-artifact-grouping;
=   }

to:
=   rc:yang-data voucher {

=3D=3D=3D<= br class=3D"">Or, do you think that we should changing the BRSKI = document to match?




= --Apple-Mail=_152D9D99-5507-481D-A67E-CECAB0D000F6-- From nobody Tue Feb 11 03:10:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0F1200B7; Tue, 11 Feb 2020 03:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia6OPySSc7ey; Tue, 11 Feb 2020 03:09:57 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C8812007A; Tue, 11 Feb 2020 03:09:57 -0800 (PST) Received: from dooku.sandelman.ca (ip5f5bd76d.dynamic.kabel-deutschland.de [95.91.215.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 1F3FE1F459; Tue, 11 Feb 2020 11:09:56 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 80CAB1A1478; Tue, 11 Feb 2020 12:09:55 +0100 (CET) From: Michael Richardson To: Toerless Eckert cc: Warren Kumari , Ignas Bagdonas , tte+ietf@cs.fau.de, iana-matrix-comment@iana.org, anima-chairs@ietf.org, anima@ietf.org In-reply-to: <20200210224530.GC31783@faui48f.informatik.uni-erlangen.de> References: <20200210224530.GC31783@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Mon, 10 Feb 2020 23:45:30 +0100." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Tue, 11 Feb 2020 12:09:55 +0100 Message-ID: <27069.1581419395@dooku> Archived-At: Subject: Re: [Anima] [IANA #1159845] Upcoming Parameter Expiration: Early IANA Allocations for draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 11:10:00 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> [ - people directly, +ANIMA (for information sharing, and to avoid >> tripping the "Too many recipients!" trigger) ] >> Dear Chairs / Author / WG, >> >> I have no history here, but seeing as the document status was changed >> to "Submitted to IESG for Publication" on 2018-07-25 (-16) , and has >> been updated 18 times (Gadzooks!) since then[0] I have to assume that >> the authors are actively working on this, and so it would be churlish >> to not approve renewal. >> >> Can someone summarize for me where this currently stands? (This isn't >> my WG, there are literally hundreds of mails on this, and it was a >> long time since I last read / balloted on this). > I hope that all temporary assignments needed for ongoing > prototyping/interop testing are done now, if not, i hope one of the > co-authors will chime in and kick my WG chair behind. I did ask > for one missing assignment we procrastinated on, that came through > ca. 2 weeks ago. Hi, yes, please renew the early allocations. The recent early allocation was for constrained-voucher,btw. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl5Ci4MACgkQlUzhVv38 QpDZxggAh5AVlt48H93Q6GCJlf1ydgXIcgQTQmJdeg5VGVsWINwslXC432brr9D8 D5wG5djNMbf7qobsMJXLav3S/s6QHWb4fTUjHALLlUeP8kBwEVES9hWsUbn4MmIN Yymd5CHK0C9daQIpC2XPTKFOSofX/EnKigHQYqunBLTpMpoM6CBnO3fJMRWf4A18 /ANQTlE7tX/mitcE9cGNHmh6p9G+fmHDG6EN2YNMxZ5qstbngdzUGMqOxJ6B4SBx 9++dN35TsJqNl5RJHyA59jz0ouUU9gjiDvX1m+Rw6DO1zE3898SNrAjRbqajZtRw D+HAbz9rwV4ub2mYiWKg3JmajoY9sw== =A7nb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 11 03:25:26 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98211200B7; Tue, 11 Feb 2020 03:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imZCfNAOvqw0; Tue, 11 Feb 2020 03:25:22 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0F51200BA; Tue, 11 Feb 2020 03:25:21 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:584d:5a6f:7ed3:c298]) by relay.sandelman.ca (Postfix) with ESMTPS id 360581F459; Tue, 11 Feb 2020 11:25:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7CAA31A1478; Tue, 11 Feb 2020 12:25:19 +0100 (CET) From: Michael Richardson To: Kent Watsen cc: "M. Ranganathan" , Kent Watsen , anima@ietf.org, iot-onboarding@ietf.org In-reply-to: <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> References: <1556.1581357910@dooku> <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> Comments: In-reply-to Kent Watsen message dated "Tue, 11 Feb 2020 00:25:20 +0000." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Tue, 11 Feb 2020 12:25:19 +0100 Message-ID: <27564.1581420319@dooku> Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 11:25:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > The confusion is likely because folks expect that the =E2=80=9Cyang-d= ata=E2=80=9D > extension define a node, but it doesn=E2=80=99t. It acts more like a= YANG > =E2=80=9Cgrouping=E2=80=9D than a YANG =E2=80=9Ccontainer=E2=80=9D in= that regard. For instance, give > the YANG: Okay, so are you saying that it has to be a voucher-artifact, not a voucher, and the examples in BRSKI are wrong? (That's really annoying) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl5Cjx8ACgkQlUzhVv38 QpAAKAf9EAEamZFlRj9fQZLfZiGyLo0rKjIN9mbmDobiND0VRZdC9K7HUmbtdnSM 3LnKVBQyyg4AfJM9vNDFMQ/cgshUVkiAgDeRFAptmSY7LB/E/DC3pKIPWhzACec9 Mxs7xLWwNFt+Xsjggo7VWRNiHkpG0PobK6qMSZNSSiard9RIEjCpPgS3REKQ799h 3FpS0fA1DFzuLRRhuCmCo7NX+4r6114qF/oagy/IQHBIRJLYheKS98M/BC+qtqvS oHEk6smBVbSbea8UjGVelBq9ShjyJf6nhdBNhTWuVEk58eFeUjotD4yUJF6XuDUr iHjvEmeNnXmli1OxKdnuPuX/hBuU8A== =4Sbb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 11 07:18:20 2020 Return-Path: <0100017034d44195-102b3d22-0c0f-48dd-b9f2-0487e81270f2-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3D212013D; Tue, 11 Feb 2020 07:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4uBNIS2Ah4U; Tue, 11 Feb 2020 07:18:15 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E54612013F; Tue, 11 Feb 2020 07:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581434293; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=qVfPbUMAwFr+xJZp0O3Sh/1czj31BQI/h6fu3ST3rjQ=; b=HZ4fi2sxkTRS7bu53LO+8d2t6C7dapO/BqqGuPPVP8DD3kblg8XAWI12b0x495Fg BvEYFCy2l29Okqcprox8LSvchlBxnosXT6MTUaHgbzsmpnLidQUxQxlHMLbb0DgXtdN a6JgHF4t+VPtGHC305SIFNE5G/aThP7q2Svc3wEA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <27564.1581420319@dooku> Date: Tue, 11 Feb 2020 15:18:12 +0000 Cc: iot-onboarding@ietf.org, anima@ietf.org, "M. Ranganathan" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017034d44195-102b3d22-0c0f-48dd-b9f2-0487e81270f2-000000@email.amazonses.com> References: <1556.1581357910@dooku> <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> <27564.1581420319@dooku> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.11-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 15:18:17 -0000 > On Feb 11, 2020, at 6:25 AM, Michael Richardson = wrote: >=20 >=20 > Kent Watsen wrote: >> The confusion is likely because folks expect that the =E2=80=9Cyang-dat= a=E2=80=9D >> extension define a node, but it doesn=E2=80=99t. It acts more like a = YANG >> =E2=80=9Cgrouping=E2=80=9D than a YANG =E2=80=9Ccontainer=E2=80=9D in = that regard. For instance, give >> the YANG: >=20 > Okay, so are you saying that it has to be a voucher-artifact, not a = voucher, > and the examples in BRSKI are wrong? > (That's really annoying) I=E2=80=99m unsure what you mean by =E2=80=9Cit=E2=80=9D but, again, the = examples in RFC 8366 are correct. Note that =E2=80=9Cvoucher-artifact=E2=80=9D does NOT appear in the = examples. AFAICT, the examples in Section 3.3 in keyinfra-35 are also correct. K. From nobody Tue Feb 11 13:02:05 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB62120132; Tue, 11 Feb 2020 13:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnAQ6isQnz_u; Tue, 11 Feb 2020 13:02:02 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DE412006F; Tue, 11 Feb 2020 13:02:01 -0800 (PST) Received: from dooku.sandelman.ca (unknown [46.183.103.8]) by relay.sandelman.ca (Postfix) with ESMTPS id 827DD1F459; Tue, 11 Feb 2020 21:02:00 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 64DC81A26A6; Tue, 11 Feb 2020 22:01:53 +0100 (CET) From: Michael Richardson To: Kent Watsen cc: iot-onboarding@ietf.org, anima@ietf.org, "M. Ranganathan" In-reply-to: <0100017034d44195-102b3d22-0c0f-48dd-b9f2-0487e81270f2-000000@email.amazonses.com> References: <1556.1581357910@dooku> <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> <27564.1581420319@dooku> <0100017034d44195-102b3d22-0c0f-48dd-b9f2-0487e81270f2-000000@email.amazonses.com> Comments: In-reply-to Kent Watsen message dated "Tue, 11 Feb 2020 15:18:12 +0000." X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Tue, 11 Feb 2020 22:01:53 +0100 Message-ID: <2056.1581454913@dooku> Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:02:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: >> Kent Watsen wrote: >>> The confusion is likely because folks expect that the =E2=80=9Cyang= -data=E2=80=9D >>> extension define a node, but it doesn=E2=80=99t. It acts more like= a YANG >>> =E2=80=9Cgrouping=E2=80=9D than a YANG =E2=80=9Ccontainer=E2=80=9D = in that regard. For instance, give >>> the YANG: >> >> Okay, so are you saying that it has to be a voucher-artifact, not a = voucher, >> and the examples in BRSKI are wrong? >> (That's really annoying) > I=E2=80=99m unsure what you mean by =E2=80=9Cit=E2=80=9D but, again, = the examples in RFC 8366 are correct. > Note that =E2=80=9Cvoucher-artifact=E2=80=9D does NOT appear in the e= xamples. By, "it", I meant the marker in the JSON: ranga> { ranga> "ietf-voucher:voucher-artifact": { > AFAICT, the examples in Section 3.3 in keyinfra-35 are also correct. okay, I was worried it didn't work out. (Whew!!!) What is it in the YANG that means the serialized JSON is "ietf-voucher:voucher" rather than "ietf-voucher:voucher-artifact"? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl5DFkEACgkQlUzhVv38 QpAwAQf/XKH/OuRka5r1RVBMKuZZ8fzrbIkqC21l9pWpBtdeEPvnYcosZon4kIvr /EcvCe+XbkGQCkUZ/vH46vNqMYE9+fJAzY/dZWYlE0MuoNTGrArOhbT35aS8DOci +mbr3LXZW3VahvJaZuEOdBIndPdiqykK7QG0DNo+HDPZMbCnFv06D9JjS5oj9FcK wneIhcxu73foEdvSoUf2bFzzt1U9pn49GFJ6JKPROre7oM/4SY38b5XfOcxQZ3xH d7Q/5SnK+9fkt5Y0pmRnN3nJZyqcsikAbWYZATtycLSqfd8LFpgcMGhZQP46hIzz /zXP+BUhoNjjuP2kork2XJRwyFDzIQ== =Vlc0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 11 16:01:08 2020 Return-Path: <0100017036b2e734-98b9ea60-f321-4ef1-92cf-c1243dc9d07c-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0512006D; Tue, 11 Feb 2020 16:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLQo5ePRJ02r; Tue, 11 Feb 2020 16:01:01 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAEC12004C; Tue, 11 Feb 2020 16:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581465659; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Do2YJ14hNNIyrh9SmwDZhEhS2PfmWU95FJU08WI5cKQ=; b=CA1U+v+T98dXoR1js8FzGW5ycBS0glDJgAuF8zFyP05ziTer1xFdNckFAoO4rpyt g98U3Dpwdq4Va24PJYSzSBHcdHBClNUYdPhMA6Jsc82edqxdgAU4UtmRV3ri/MBp4go gUfemuh3zAlXBryB4owroRZ5YKsBXdDFc68vvmuA= From: Kent Watsen Message-ID: <0100017036b2e734-98b9ea60-f321-4ef1-92cf-c1243dc9d07c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E78B1EED-B330-47A5-9848-4CFFAE7B38EA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Feb 2020 00:00:59 +0000 In-Reply-To: <2056.1581454913@dooku> Cc: iot-onboarding@ietf.org, anima@ietf.org, "M. Ranganathan" To: Michael Richardson References: <1556.1581357910@dooku> <0100017031a2d6ec-545e8e6a-1259-45da-a7da-1da0a461cce6-000000@email.amazonses.com> <27564.1581420319@dooku> <0100017034d44195-102b3d22-0c0f-48dd-b9f2-0487e81270f2-000000@email.amazonses.com> <2056.1581454913@dooku> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.12-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] RFC 8366: voucher artifact error in example? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 00:01:03 -0000 --Apple-Mail=_E78B1EED-B330-47A5-9848-4CFFAE7B38EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>> The confusion is likely because folks expect that the = =E2=80=9Cyang-data=E2=80=9D >>>> extension define a node, but it doesn=E2=80=99t. It acts more like = a YANG >>>> =E2=80=9Cgrouping=E2=80=9D than a YANG =E2=80=9Ccontainer=E2=80=9D = in that regard. For instance, give >>>> the YANG: >>>=20 >>> Okay, so are you saying that it has to be a voucher-artifact, not a = voucher, >>> and the examples in BRSKI are wrong? >>> (That's really annoying) >=20 >> I=E2=80=99m unsure what you mean by =E2=80=9Cit=E2=80=9D but, again, = the examples in RFC 8366 are correct. >> Note that =E2=80=9Cvoucher-artifact=E2=80=9D does NOT appear in the = examples. >=20 > By, "it", I meant the marker in the JSON: >=20 > ranga> { > ranga> "ietf-voucher:voucher-artifact": { Ranga=E2=80=99s question was if this should be the case. The answer is = =E2=80=9Cno=E2=80=9D and no errata is needed. >> AFAICT, the examples in Section 3.3 in keyinfra-35 are also correct. >=20 > okay, I was worried it didn't work out. (Whew!!!) > What is it in the YANG that means the serialized JSON is > "ietf-voucher:voucher" rather than = "ietf-voucher:voucher-artifact=E2=80=9D? The "ietf-voucher:=E2=80=9D prefix appears because =E2=80=9Cietf-voucher" = is the name of the module (i.e. ietf-voucher@2018-05-09.yang = ). The =E2=80=9Cname=E2=80=9D parameter of the =E2=80=9Crc:yang-data=E2=80=9D= statement has no effect on the serialized encoding. Yes, the name is = =E2=80=9Cvoucher-artifact=E2=80=9D, but that string never appears in = instance documents. What does matter is that the rc:yang-data=E2=80=99s immediate descendent = is a =E2=80=98container=E2=80=99 node called =E2=80=9Cvoucher=E2=80=9D. = This string *does* appear in the serialized form. Hence it is "ietf-voucher:voucher" rather than = "ietf-voucher:voucher-artifact=E2=80=9D. Kent --Apple-Mail=_E78B1EED-B330-47A5-9848-4CFFAE7B38EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The confusion is likely = because folks expect that the =E2=80=9Cyang-data=E2=80=9D
extension define a node, but it doesn=E2=80=99t.  It = acts more like a YANG
=E2=80=9Cgrouping=E2=80=9D than a = YANG =E2=80=9Ccontainer=E2=80=9D in that regard. For instance, give
the YANG:

Okay, so = are you saying that it has to be a voucher-artifact, not a voucher,
and the examples in BRSKI are wrong?
(That's = really annoying)

I=E2=80=99m unsure what = you mean by =E2=80=9Cit=E2=80=9D but, again, the examples in RFC 8366 = are correct.
Note that =E2=80=9Cvoucher-artifact=E2=80=9D = does NOT appear in the examples.

By, "it", I meant the marker in the JSON:

   ranga> {
=    ranga> "ietf-voucher:voucher-artifact": {

Ranga=E2=80=99= s question was if this should be the case.  The answer is =E2=80=9Cno= =E2=80=9D and no errata is needed.



AFAICT, the examples in Section 3.3 in = keyinfra-35 are also correct.

okay, I was worried it didn't work out. = (Whew!!!)
What is it in the YANG that = means the serialized JSON is
=     "ietf-voucher:voucher" rather than = "ietf-voucher:voucher-artifact=E2=80=9D?

The "ietf-voucher:=E2=80=9D prefix appears = because =E2=80=9Cietf-voucher" is the name of the module (i.e. ietf-voucher@2018-05-09.yang).

The =E2=80=9Cname=E2=80=9D parameter of the = =E2=80=9Crc:yang-data=E2=80=9D statement has no effect on the serialized = encoding.  Yes, the name is =E2=80=9Cvoucher-artifact=E2=80=9D, but = that string never appears in instance documents.

What does matter is that the rc:yang-data=E2=80=99s = immediate descendent is a =E2=80=98container=E2=80=99 node called = =E2=80=9Cvoucher=E2=80=9D.  This string *does* appear in the = serialized form.

Hence it = is "ietf-voucher:voucher" rather than = "ietf-voucher:voucher-artifact=E2=80=9D.

Kent





= --Apple-Mail=_E78B1EED-B330-47A5-9848-4CFFAE7B38EA-- From nobody Wed Feb 12 08:56:26 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60C12020A for ; Wed, 12 Feb 2020 08:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om4qX-3RgAoA for ; Wed, 12 Feb 2020 08:56:21 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30097.outbound.protection.outlook.com [40.107.3.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A4A1201B7 for ; Wed, 12 Feb 2020 08:56:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XQwqNrot10rDkmaYla5kCvr3d6KS6PE6UGZ8R6vBXoIJaSAecB6sRctxD7OStSKtxDyVkYpDM0FUXHQonCup4Eyz7ly7ShSBT639k1TtzuNKiLKCEBx4CxUBOGTjDLtoYEyL7+E3Dwbw9oNV8QwjQj6F5NCzBseoFhnUAHk97nDOqu85YELcsVEiGx64WsHmkd1ES69wHsUsqBzsC7qImNQ8q7RX4L449Yga4fHAqvd8H4LiVsVupzP2nCtb8UEDIMtod+PrN1FF/G/KG0sDiGb/r9lTiXKg3uyyUPzlvQp5AYR8UAzFnJ1F5LA+2gXZ7vlUef9mywTmuDAEpkRPoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p/WFLjRCPDA/us7Q0uGyjw6+k41VPgqpH4kJmEXwH2w=; b=SbCb4u2T8XMkEOISWKkpY2xZKZxdFz5hlaP7hDMWppXWEENnqz+kT3bu/WoWm77hyB+qxxD2Pqsr3/cfA9qTf2DliYbzBBMNfXbgLeverUl0YxjYXBbUcn7SC1Fo3Kn1NCQvxOQn+C1ii1j3X+N6tM4nk3yGtOJyFyaX8GNt4DZYliYRXmQDQW7pbG2Er1pPwTsisAJwP4jWUfbIRNXmq25CvBSZ+3hfnieXpUK3GGQaD5QuS/FqG+dK0m4rNp7/oc/bBJzBSiNNpTggHLbyibHXEeVWF4BZRR9gFWGyxgskvYJw7Azke8kMd653Jbia0QmpJst+7djPau1erxGGLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p/WFLjRCPDA/us7Q0uGyjw6+k41VPgqpH4kJmEXwH2w=; b=rYQllkPvEZSmOMDdY7JeX8v9G4ACKSeQTb4ZvrWX9h6W0TxBTWWTYdOsNt9vVTeWtUDiYY9BysDN+afEzy6gcOiqfgWFtgrfYTnLjQcj18/6Eh0D6ZFMg4Y1c4fwBJn98Xwe5xXC/gDPmiS/oJPJCfozimDGZGGroykUlxD+f+Y= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0356.EURP190.PROD.OUTLOOK.COM (10.161.92.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 12 Feb 2020 16:56:16 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f%7]) with mapi id 15.20.2707.030; Wed, 12 Feb 2020 16:56:16 +0000 From: Esko Dijk To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) Thread-Index: AQHV4DtfaEigTItIrkaa5Oarwn0J06gXrSSg Date: Wed, 12 Feb 2020 16:56:15 +0000 Message-ID: References: <1272.1581357351@dooku> In-Reply-To: <1272.1581357351@dooku> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:6d00:4935:1a02:819c:b6b0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1bd394dc-dc27-4e05-a72a-08d7afdc7972 x-ms-traffictypediagnostic: AM5P190MB0356: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39830400003)(396003)(136003)(376002)(189003)(199004)(186003)(8676002)(81156014)(316002)(55016002)(9686003)(8936002)(966005)(53546011)(81166006)(6506007)(110136005)(76116006)(7696005)(86362001)(2906002)(508600001)(52536014)(71200400001)(64756008)(66946007)(66446008)(66476007)(33656002)(44832011)(66556008)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0356; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ijC3iodEnt2JdIscaPuCdMhmGekScSdNnKNdZQlyOZDrqikTIqwi588+HdvCa+sy3v2BlwXu3sXuRDXGLGmkei4c1RXsTCg8SEvlSMmC9nzrDRixm47q5hP2OLaVPw5m9M6DG70HijZrzKWxhM7d9OMZbxBWINXiPEcirtEyc35KbO6lNPfXqQSf0QrifTg/4IIlAFmIwFkJUdQX9lV4UMrwwPVGecfMF0RV1CDvTwL977xoBnT/56xYBuYWaFQKRdF4EQhUGjKePiSV6pczszeZM8qQASPGUwTR0d98nExe8qBBll3j8J1eN4QMrqPjBoEmmyx69xDCXUuwcZBHxTqta6Wdqw4fjoW9ceheiObXmImBsE8c1KbhQAqg5cdmzWDn4yVmoC7Qx5tpMGvXcHEZa39CN/mcTbVu/Ts5K26m4befodpLumcY6I19sloojkCxik72ATsJWOzDT/HLevl/z7WD3Lkx5+poqbeU7HZ8jGhPMrUO0yVlzJIuRTwVmoa8/cOnHGqG+NeOxlHMaA== x-ms-exchange-antispam-messagedata: uNfqiQheWEsnj8XQbC+bIsaV66gutgskrHmQlUD4GMprV0omfmNcHs3B0kJV6Ug7qh1cDcwnTH5rRqthQbGczMDLT4U/trHNiZC8YQ3KH+jQyVuJ4HjAGIgB1pH+toNR9ratFrItNNRjkaUbFwxxgltGt6M8xDtvuOLaP3CLhM4S7NmgVEWoM4LsPEFE9fS+6BsdrIg27hoMzKOnWB/aOQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 1bd394dc-dc27-4e05-a72a-08d7afdc7972 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 16:56:15.8689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mCibp81oENHy24pwfWmeFh5wgJuFjeMds7UVGOvWdjH2TNqyY8fY138RwsS1+GNbfelLubNVz2uaeX57ivKQvJxxsAWV1tTr9GJ7qBzuVj4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0356 Archived-At: Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 16:56:24 -0000 VGhhbmtzLA0KbWVhbndoaWxlIEkgcmVhZCBCUlNLSS0zNSA1LjQgLyA1LjQuMSBiZXR0ZXIgYW5k IEkgYW0gcmVjb25zaWRlcmluZyBteSBwcm9wb3NhbC4gVGhlc2Ugc2VjdGlvbnMgc3RhdGUgdGhh dCB0aGUgUmVnaXN0cmFyJ3MgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHRvd2FyZHMgTUFTQSBtYXkg ZGlmZmVyIGRlcGVuZGluZyBvbiBidXNpbmVzcy1wcm9jZXNzIGFuZCBzZWN1cml0eSBjaG9pY2Vz OyBpbmRlcGVuZGVudCBmcm9tIHRoZSBEb21haW4gKENBKSBhdXRoZW50aWNhdGlvbi4gSW4gQlJT S0kgdGhlIERvbWFpbiBDQSBpcyAiZXh0cmFjdGVkIGZyb20gdGhlIHNpZ25hdHVyZSBtZXRob2Qi ICg1LjUuMiksIHNvIGZyb20gdGhlIFJlZ2lzdHJhcidzIHNpZ25lZCBDTVMgc3RydWN0dXJlOyBu b3QgZnJvbSBpZGVudGl0aWVzIGV4Y2hhbmdlZCBpbiB0aGUgVExTIGhhbmRzaGFrZSBiZXR3ZWVu IFJlZ2lzdHJhci9NQVNBLiBUaGlzIHNvdW5kcyBsaWtlIGFuIGludGVudGlvbmFsIGRlc2lnbiBj aG9pY2Ugb2YgQlJTS0kgd2Ugc2hvdWxkIHN0aWNrIHRvLg0KDQpXaGVuIHRoZSBSZWdpc3RyYXIg dXNlcyBDTVMtc2lnbmluZywgYWxsIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCBieSBNQVNBIGlz IGluIHRoZXJlLiAgV2hlbiB0aGUgUmVnaXN0cmFyIHVzZXMgQ09TRV9TaWduMSwgdGhlcmUgaXMg bm90IGVub3VnaCBpbmZvcm1hdGlvbiAtLSBvbmx5IGEgS0lEIGlkZW50aWZ5aW5nIHRoZSBrZXlw YWlyIG9mIHRoZSBzaWduZXIuIEJ1dCBub3QgYSBjZXJ0aWZpY2F0ZSBvciBjZXJ0IGNoYWluLCBz byB0aGUgTUFTQSB3b3VsZCBtaXNzIHRoaXMgaW5mb3JtYXRpb24gYW5kIGNhbm5vdCBwaW4gYW55 dGhpbmcuIFNvIGFtIEkgcmlnaHQgaW4gY29uY2x1ZGluZyB0aGF0IHRoZSBSZWdpc3RyYXIgKm11 c3QqIHVzZSBDTVMtc2lnbmluZyBpbiBjYXNlIHRoZSBQbGVkZ2UgaGFzIGlkZW50aWZpZWQgaXRz ZWxmIGJ5IGNlcnRpZmljYXRlIGluIHRoZSBEVExTIGhhbmRzaGFrZT8gVGhpcyBmaXRzIHdpdGgg Y29uc3RyYWluZWQtdm91Y2hlci0wNyBzZWN0aW9uIDQ6ICJUaGUgdXNlIG9mIENNUyBzaWduYXR1 cmVzIGltcGxpZXMgdGhlIHVzZSBvZiBQS0lYIGZvcm1hdCBjZXJ0aWZpY2F0ZXMiIC4gVGhlbiBp dCBpcyBhbHNvIHRoZSBvdGhlciB3YXkgYXJvdW5kLCB0aGUgdXNlIG9mIFBLSVggY2VydGlmaWNh dGVzIChieSB0aGUgUGxlZGdlKSBpbXBsaWVzIHRoZSB1c2Ugb2YgQ01TIHNpZ25hdHVyZXMgYnkg dGhlIFJlZ2lzdHJhci4gVGhlIFBsZWRnZSBzaG91bGQgc3RpbGwgYmUgYWJsZSB0byBzaWduIHdp dGggQ09TRV9TaWduMSBJIHRoaW5rIGJlY2F1c2Ugb2YgdGhlIHNtYWxsLXNpemUgYmVuZWZpdC4g SXQgY2FuIHNpbXBseSB1c2UgdGhlIHByaXZhdGUga2V5IG9mIGl0cyBJRGV2SUQtY2VydCB0byBz aWduLg0KDQo+IEluIHRoZSBtb3JlIGNvbnN0cmFpbmVkIGNhc2VzLCB0aGUgUmVnaXN0cmFyIGlz IGlkZW50aWZpZWQgYnkgYSBSYXcgUHVibGljDQo+IEtleS4gW1RoaXMgd29ya3MgaW4gRFRMUyBh bmQgd2lsbCB3b3JrIGluIExBS0UgYnkgZGVzaWduXQ0KDQpBZ3JlZSB0aGF0IGluIHRoZSBtb3N0 IGNvbnN0cmFpbmVkIGNhc2VzIHRoZSBSZWdpc3RyYXIgaXMgaWRlbnRpZmllZCB0b3dhcmRzIHRo ZSBQbGVkZ2UgYnkgYW4gUlBLOyBhbmQgdmljZSB2ZXJzYSBQbGVkZ2UgaWRlbnRpZmllcyB0b3dh cmRzIFJlZ2lzdHJhciB3aXRoIGl0cyBSUEsuIEkgYXNzdW1lIHRoZSBSZWdpc3RyYXIgbWF5IHN0 aWxsIGlkZW50aWZ5IGRpZmZlcmVudGx5IHRvd2FyZHMgdGhlIE1BU0EgZGVwZW5kaW5nIG9uIGJ1 c2luZXNzLXByb2Nlc3MgdGFraW5nIGludG8gYWNjb3VudCB0aGUgNS40IC8gNS40LjEgdGV4dCBh Ym92ZS4gRS5nLiwgdXNpbmcgYSBmdWxsIGNlcnRpZmljYXRlIGNoYWluLCBwb3NzaWJseSBQS0lY LCB3aXRoIGEgY29tcGxldGVseSBkaWZmZXJlbnQgaWRlbnRpdHkgdGhhbiB0aGUgUlBLIGl0IHVz ZWQgdG93YXJkcyB0aGUgUGxlZGdlLiBCdXQgaWYgdGhpcyBhc3N1bXB0aW9uIGlzIG5vdCByaWdo dCBwbGVhc2UgbGV0IG1lIGtub3cuIA0KDQo+IEluIHRoZSBtb3JlIGNvbnN0cmFpbmVkIGNhc2Vz LCB0aGUgUmVnaXN0cmFyIGlzIGlkZW50aWZpZWQgYnkgYSBSYXcgUHVibGljDQo+IEtleS4gW1Ro aXMgd29ya3MgaW4gRFRMUyBhbmQgd2lsbCB3b3JrIGluIExBS0UgYnkgZGVzaWduXQ0KPiBUaGlz IGlzIHdoYXQgc2hvdWxkIGJlIHBpbm5lZCBieSB0aGUgTUFTQSwgYmVjYXVzZSB0aGF0J3Mgd2hh dCB0aGUgcGxlZGdlIHNhdy4NCg0KQWdyZWUgZm9yIHRoaXMgY2FzZTsgdGhlIG9ubHkgdGhpbmcg dGhhdCBjYW4gc2Vuc2libHkgYmUgcGlubmVkIGlzIHRoZSBSZWdpc3RyYXIncyBSUEsuIFF1ZXN0 aW9uOiBJcyBpdCB0aGUgaW50ZW50aW9uIG9mIGNvbnN0cmFpbmVkLXZvdWNoZXItMDcgdGhhdCB0 aGUgUmVnaXN0cmFyIGFsd2F5cyB1c2VzIENPU0VfU2lnbjEgc2lnbmVkIFZvdWNoZXIgUmVxdWVz dCB0byBNQVNBLCBpbiBjYXNlIHRoZSBQbGVkZ2UgaWRlbnRpZmllZCBpdHNlbGYgd2l0aCBSUEsg ZHVyaW5nIHRoZSBEVExTIGhhbmRzaGFrZT8gKEhpbnRlZCBhdCBpbiBjb25zdHJhaW5lZC12b3Vj aGVyLTA3IHNlY3Rpb24gNC4gQnV0IG5vdCBmdWxseSBjbGVhci4pDQoNCj4gSWYgeW91IGFyZSB1 c2luZyBhIGNlcnRpZmljYXRlIGNoYWluIGZvciB0aGUgUmVnaXN0cmFyIGVuZCBwb2ludCwgdGhl IE1BU0ENCj4gZG9lcyBub3QgaGF2ZSB0byBwaW4gdGhlIERvbWFpbiBDQSwgaXQgY2FuIGluc3Rl YWQgcGluIHRoZSBSZWdpc3RyYXINCj4gY2VydGlmaWNhdGUsIHNpbmNlIGFnYWluLCB0aGF0J3Mg d2hhdCB0aGUgcGxlZGdlIHNhdyAoYW5kIHNpZ25lZCkuDQoNCkJSU0tJLTM1IHJlcXVpcmVzIE1B U0EgdG8gcGluIHRoZSBEb21haW4gQ0EgY2VydDsgd2h5IHdvdWxkIHRoZSBNQVNBIG5vdCBkbyB0 aGlzPyAgV2hhdCB0aGUgUGxlZGdlIHNhdyBkdXJpbmcgdGhlIERUTFMgaGFuZHNoYWtlIGlzIHRo ZSBjZXJ0IGNoYWluIFJlZ2lzdHJhci1jZXJ0IC0+IERvbWFpbi1DQS1jZXJ0ICh0eXBpY2FsbHkg MiBjZXJ0cyBsb25nKS4gQXQgdGhlIG1vbWVudCB0aGUgUGxlZGdlIHJlY2VpdmVzIHRoZSBWb3Vj aGVyIHBpbm5pbmcgdGhlIERvbWFpbiBDQSBjZXJ0IGl0IGtub3dzIGl0IGNhbiB0cnVzdCB0aGUg UmVnaXN0cmFyLCB0cnVzdCB0aGUgRFRMUyBzZXNzaW9uLCB0cnVzdCB0aGUgRG9tYWluLCBhbmQg dHJ1c3QgYW55IEVTVCBjZXJ0aWZpY2F0ZSB0aGF0IGlzIGlzc3VlZCBpbiB0aGUgbmV4dCBzdGVw IC0gdGhlIEVTVC1jcmVhdGVkIG9wZXJhdGlvbmFsIChkb21haW4pIGNlcnRpZmljYXRlcyBhcmUg bm90IHNpZ25lZCBieSBSZWdpc3RyYXIgYnV0IGJ5IHRoZSBFU1QgQ0EgPT0gRG9tYWluIENBLiAg U28gaGF2aW5nIERvbWFpbiBDQSBhcyB0cnVzdCBhbmNob3IgdG8gdmFsaWRhdGUgeW91ciBvd24g bmV3IGNlcnRpZmljYXRlLCBhbmQgcG9zc2libHkgYWxzbyBvdGhlciBkZXZpY2UncyBjZXJ0cyBp biB0aGUgc2FtZSBEb21haW4sIG1ha2VzIHNlbnNlLiAgIA0KDQo+IElmIHlvdSB3YW50IHVzIHRv IGRlZmluZSBhIHdheSB0byBwaW4gdGhlIGRvbWFpbiBDQSwgdGhlbiBJIHRoaW5rIHRoYXQgcmln aHQNCj4gYW5zd2VyIGlzIHRvIHBhc3MgdGhhdCBlbnRpcmUgY2hhaW4gYWxvbmcgdG8gdGhlIFBs ZWRnZSBpbiB0aGUgQlJTS0ktRVNUDQo+IGNoYW5uZWwgaW4gdGhlIERUTFMgaGVhZGVyLCBhbmQg aGF2ZSB0aGUgcGxlZGdlIHNpZ24gdGhhdCBlbnRpcmUgb2JqZWN0Lg0KPiBUaGlzIHdvdWxkbid0 IGJlIHZlcnkgY29uc3RyYWluZWQsIHNvIEkgYW0gbm90IHN1cmUgd2h5IG9uZSB3b3VsZCBkbyB0 aGlzDQo+IHJhdGhlciB0aGFuIHVzaW5nIFRMUyBpbiB0aGF0IGNhc2UuDQoNCkkgdGhpbmsgdGhp cyB3YXkgdG8gcGluIHRoZSBEb21haW4gQ0EgaXMgYWxyZWFkeSBzcGVjaWZpZWQgaW4gQlJTS0kt MzUgYW5kIHBhc3NlcyBvbiBxdWl0ZSBuYXR1cmFsbHkgaW50byBjb25zdHJhaW5lZC1CUlNLSSwg YW5kIGFzIGxvbmcgYXMgdGhlIFJlZ2lzdHJhciB1c2VzIENNUyBzaWduaW5nIGluIGl0cyBWb3Vj aGVyIFJlcXVlc3QgdG93YXJkcyBNQVNBIHRoZSBpbml0aWFsIHByb2JsZW0gc3RhdGVtZW50IGlz IG5vdCBzbyByZWxldmFudC4gDQpBbmQgaXQgZG9lcyBub3QgdGFrZSBhIGh1Z2UgYW1vdW50IG9m IHJlc291cmNlcyAobmV0d29yay9tZW1vcnkvY29kZS90aW1lKSBvbiBhIFBsZWRnZS4gIFRoZSBj ZXJ0IGNoYWlucyBjYW4gYmUga2VwdCB0byBhIG1pbmltdW0gKGkuZS4gY2hhaW4gb2YgMikuIE9m IGNvdXJzZSB3b3JraW5nIHdpdGggY2VydGlmaWNhdGVzIGlzIGFsd2F5cyBtb3JlIHJlc291cmNl LWRlbWFuZGluZyB0aGFuIFJQS3Mtb25seSENCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCklvVGNv bnN1bHRhbmN5Lm5sICB8ICBFbWFpbC9Ta3lwZTogZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5s IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEgPGFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NClNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMTAsIDIwMjAgMTg6NTYNClRvOiBhbmltYUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtBbmltYV0gW2FuaW1hLXdnL2NvbnN0cmFpbmVkLXZvdWNoZXJdIFVuY2xlYXIgaG93IE1B U0Egb2J0YWlucyBEb21haW4gQ0EgY2VydCBmb3IgcGlubmluZywgaW4gY2FzZSBvZiBDT1NFLXNp Z25lZCBWb3VjaGVyIFJlcXVlc3QgKCM0OSkNCg0KSW4gaHR0cHM6Ly9naXRodWIuY29tL2FuaW1h LXdnL2NvbnN0cmFpbmVkLXZvdWNoZXIvaXNzdWVzLzQ5LCBFc2tvIERpamsgYXNrczoNCg0KPiBJ biBCUlNLSSAoNS41LjIgIE1BU0EgcGlubmluZyBvZiByZWdpc3RyYXIpIGl0IGlzIGNsZWFyIGhv dyB0aGUgTUFTQSBjYW4NCj4gZ2V0IHRoZSBjb21wbGV0ZSBjZXJ0IGNoYWluIG9mIHRoZSBSZWdp c3RyYXIgZnJvbSB0aGUgQ01TIHNpZ25hdHVyZQ0KPiBzdHJ1Y3R1cmUuIFRoZSBSZWdpc3RyYXIn cyBEb21haW4gQ0EgY2VydCBpcyBpbmNsdWRlZCBpbiB0aGVyZSBhbmQgaXMgdXNlZA0KPiBhcyB0 aGUgcGlubmVkIGRvbWFpbiBjZXJ0IGluIHRoZSBWb3VjaGVyLiAgSG93ZXZlciwgd2hlbiB3ZSBu b3cgdXNlDQo+IENPU0Utc2lnbmVkIFZvdWNoZXIgUmVxdWVzdCBieSB0aGUgUmVnaXN0cmFyLCB0 aGUgUmVnaXN0cmFyJ3MgRG9tYWluIENBDQo+IGNlcnQgaXMgbm90IGluY2x1ZGVkIGluIHRoZSBD T1NFLXNpZ24gc3RydWN0dXJlIHNvIHRoZSBNQVNBIGNhbm5vdA0KPiAiZXh0cmFjdCIgaXQgcGVy IEJSU0tJIDUuNS4yLg0KDQo+IEl0IHdvdWxkIGJlIGdvb2QgdG8gbWFrZSBtb3JlIGV4cGxpY2l0 IGhvdyB0aGUgTUFTQSBzaG91bGQgZXh0cmFjdCB0aGUNCj4gUmVnaXN0cmFyJ3MgRG9tYWluIENB IGNlcnQgaW4gdGhpcyBjYXNlIChOb3RlOiB0aGUgRG9tYWluIENBIGNvdWxkIGJlIHRoZQ0KPiBS ZWdpc3RyYXIgaXRzZWxmIGJ1dCBub3QgbmVjZXNzYXJpbHkuKSAgVGhlIG9idmlvdXMgY2FuZGlk YXRlIGlzIHRvIGdldCBpdA0KPiBmcm9tIHRoZSBEVExTIG9yIFRMUyBoYW5kc2hha2UgdGhhdCBS ZWdpc3RyYXIgcGVyZm9ybXMgd2l0aCBNQVNBLiBUaGlzIGlzDQo+IGFscmVhZHkgaGludGVkIGF0 IGluIHRoZSB0ZXh0IGluIHNlY3Rpb24gNi4xLjMgLyA2LjIuMyBpbnNpZGUgdGhlIFlBTkcNCj4g bW9kdWxlIGRlc2NyaXB0aW9uICIuLi4gaXQgaXMgd2FzdGVmdWwgLi4uICIgYnV0IHRoYXQgaXMg bm90IHF1aXRlDQo+IGNsZWFyLiBXaGVuIFJlZ2lzdHJhciBpcyB1c2luZyBDT1NFIHNpZ25pbmcg dGhlIE1BU0EgKmhhcyogdG8gZ2V0IHRoZQ0KPiBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSBoYW5kc2hh a2UgaWYgdGhlIE1BU0Egd2FudHMgdG8gcGluIHRoZSBlbnRpcmUNCj4gY2VydGlmaWNhdGUgaW4g dGhlIFZvdWNoZXIsIHRoZXJlIHNlZW1zIHRvIGJlIG5vIG90aGVyIG9wdGlvbi4gU2VjdGlvbg0K PiA2LjMuMiBub3cgbWVudGlvbnMgIm91dCBvZiBiYW5kIiBkaXN0cmlidXRpb24gYnV0IHRoYXQn cyBub3QgdmVyeSBjbGV2ZXIgaWYNCj4geW91IHdhbnQgYXV0b21hdGVkIGJvb3RzdHJhcHBpbmcg LSBpdCBuZWVkcyB0byBnbyBhbGwgaW4tcHJvdG9jb2wgLw0KPiBpbi1iYW5kLg0KDQo+IEl0IHNo b3VsZCBiZSBub3RlZCBhbHNvIHRoYXQgdGhpcyBtb2RpZmllcyB0aGUgQlJTS0kgcmVxdWlyZW1l bnQgc2VjdGlvbg0KPiA1LjUuMiBvbiBob3cgdGhlIHBpbm5lZCBEb21haW4gQ0EgY2VydCBpcyBv YnRhaW5lZC4NCg0KSW4gdGhlIG1vcmUgY29uc3RyYWluZWQgY2FzZXMsIHRoZSBSZWdpc3RyYXIg aXMgaWRlbnRpZmllZCBieSBhIFJhdyBQdWJsaWMNCktleS4gW1RoaXMgd29ya3MgaW4gRFRMUyBh bmQgd2lsbCB3b3JrIGluIExBS0UgYnkgZGVzaWduXQ0KVGhpcyBpcyB3aGF0IHNob3VsZCBiZSBw aW5uZWQgYnkgdGhlIE1BU0EsIGJlY2F1c2UgdGhhdCdzIHdoYXQgdGhlIHBsZWRnZSBzYXcuDQoN CklmIHlvdSBhcmUgdXNpbmcgYSBjZXJ0aWZpY2F0ZSBjaGFpbiBmb3IgdGhlIFJlZ2lzdHJhciBl bmQgcG9pbnQsIHRoZSBNQVNBDQpkb2VzIG5vdCBoYXZlIHRvIHBpbiB0aGUgRG9tYWluIENBLCBp dCBjYW4gaW5zdGVhZCBwaW4gdGhlIFJlZ2lzdHJhcg0KY2VydGlmaWNhdGUsIHNpbmNlIGFnYWlu LCB0aGF0J3Mgd2hhdCB0aGUgcGxlZGdlIHNhdyAoYW5kIHNpZ25lZCkuDQoNCklmIHlvdSB3YW50 IHVzIHRvIGRlZmluZSBhIHdheSB0byBwaW4gdGhlIGRvbWFpbiBDQSwgdGhlbiBJIHRoaW5rIHRo YXQgcmlnaHQNCmFuc3dlciBpcyB0byBwYXNzIHRoYXQgZW50aXJlIGNoYWluIGFsb25nIHRvIHRo ZSBQbGVkZ2UgaW4gdGhlIEJSU0tJLUVTVA0KY2hhbm5lbCBpbiB0aGUgRFRMUyBoZWFkZXIsIGFu ZCBoYXZlIHRoZSBwbGVkZ2Ugc2lnbiB0aGF0IGVudGlyZSBvYmplY3QuDQpUaGlzIHdvdWxkbid0 IGJlIHZlcnkgY29uc3RyYWluZWQsIHNvIEkgYW0gbm90IHN1cmUgd2h5IG9uZSB3b3VsZCBkbyB0 aGlzDQpyYXRoZXIgdGhhbiB1c2luZyBUTFMgaW4gdGhhdCBjYXNlLg0KDQotLQ0KTWljaGFlbCBS aWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29y a3MNCiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQoNCg== From nobody Wed Feb 12 22:20:07 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006CA1200B3; Wed, 12 Feb 2020 22:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIlRlVO90GCA; Wed, 12 Feb 2020 22:19:59 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833D512007A; Wed, 12 Feb 2020 22:19:59 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3991553B9DFFABBABAF9; Thu, 13 Feb 2020 06:19:57 +0000 (GMT) Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Feb 2020 06:19:57 +0000 Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 13 Feb 2020 06:19:56 +0000 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 13 Feb 2020 06:19:56 +0000 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.136]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Thu, 13 Feb 2020 14:19:50 +0800 From: "Liubing (Leo)" To: Toerless Eckert , "anima@ietf.org" CC: "draft-liu-anima-grasp-distribution@ietf.org" Thread-Topic: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) Thread-Index: AQHVygcEsjSQ2LGRnESAK6Mv18zwWKgUtPuAgAQf7KA= Date: Thu, 13 Feb 2020 06:19:49 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45DE7333FD@DGGEML532-MBX.china.huawei.com> References: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 06:20:04 -0000 Hi Toerless, Thanks a lot for summarizing the comments! We'll revise a new version as you suggested, and upload it soon. We'll also= try to maintain a github repo. Best regards, Bing > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: Tuesday, February 11, 2020 7:13 AM > To: anima@ietf.org > Cc: draft-liu-anima-grasp-distribution@ietf.org > Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution= (ends > 01/27/2020) >=20 > We had 5 voices feedback (from non-authors) to support adoption of this > document, and no voices objecting. I think this qualifies for adoption of= the > document. >=20 > Nevertheless, the supporting voices did indicate a range of improvements = they > would like to see. So, jere is what i would propose: >=20 > Dear-authors: >=20 > A) Please add a section Open Issues, mark it as > [RFC-Editor: To Be removed before becoming RFC]. > Make it contain the following text: >=20 > The following issues where identified by the WG when adopting the -00 dra= ft > version. These issues will be individually removed in upcoming when they = are > resolved. >=20 > 1. More reference to the use cases in the introduction. >=20 > 2. Better explanation of the required context of the Connected-Car case: > Not applicable unless the ACP will be extended to the car, which may not = be > desirable with the current ACP design, but maybe refocussing on an > "autonomous fleet" use-case (e.g.: all cars operated by some taxi like se= rvice). >=20 > 3. Consider use-case/example of firmware update. By abstracting the loca= tion > of the firmware from the name of the firmware, while providing a way to n= otify > about it, this significantly supports distribution of firmware updates. > References to SUIT would appropriate. >=20 > 4. Issues discussed in > https://mailarchive.ietf.org/arch/msg/anima/_0fYQPBcLPt8xzQee7P4dILsn3A >=20 > 5. Rethink/refine terminology, e.g.: "module" seems to be too prescriptiv= e. > Refine proposed extensions. >=20 > 6. I support adoption, but also support the suggestion (from IETF106) Pro= vide > more protocol behavior description instead of only implementation / soft= ware > module architecture description. > Reduce the latter or provide better justification for their presence due = to > explained interoperability requirements. >=20 > 7. Better motivation in sections 1..4 of the proposed extensions >=20 > 8. Consider moving examples from appendices into core-text . Ideally craf= t a > single use-case showing/applying all extensions (most simple use case tha= t uses > them all). >=20 > 9. Refine terminology to better match/reuse-the established terminology f= rom > the pre-existing ANIMA documents. >=20 > B) Add changelog section, equally marked as to be removed before . For th= is > version -00 it should just list above section from A) to be new. >=20 > C) Designate in the authors list one or two main editors for the time > being, doesn't have to be final, just whoever has the main edit pen > from you. Post this version as -00 with name > draft-ietf-anima-grasp-distribution-00 > and replacing draft-liu-anima-grasp-distribution >=20 > I will then approve that doc as WG chair. >=20 > D) Feel free to work on -01 and further. In the changelog, please > describe for each change which of the above 9 points are addressed by > the change and concentrate on those changes first before addressing > further enhancements. >=20 > E) I would strongly suggest you authors consider to create a repo for > this document under www.github.com/anima-wg It specifically makees > it easier to open for each of the above 10 bullet points possible > "Issues" where it would be easier to have focussed discusses. >=20 > I am not a github is the only way groupie though, so please make sure > all discussions are Cc'ed to the mailing list, even though it may prim= arily be on > github to make then easier to track/find. >=20 > Cheers > Toerless >=20 > On Mon, Jan 13, 2020 at 12:45:33PM +0100, Toerless Eckert wrote: > > This message starts a two-week adoption call, it ends on January 27th, = 2020. > > > > draft-liu-anima-grasp-distribution was progressed up to version -13 > > with the help of the WG, it was last presented at IETF106 with good int= erest. > > The draft is now clearly in scope of ANIMA charter 2 that was adopted > > around IETF106. The authors asked for adoption of the document. > > As far as the chairs heard, there was no objection in the room. > > > > We therefore are asking the ANIMA working group for adoption of the > following work: > > > > Title: Information Distribution in Autonomic Networking > > Name: draft-liu-anima-grasp-distribution > > Authors: B. Liu, X. Xiao, A. Hecker, S. Jiang, Z. Despotovic > > URL: https://datatracker.ietf.org/doc/draft-liu-anima-grasp-distri= bution/ > > > > This document is intended to become a standards track ANIMA WG document= . > > > > Standard track is desired because it is meant to become the required > > small set of protocol extensions to the GRASP protocol in support of > > the self-organization of ASA. > > > > Please express your support or rejection. If you think this document > > should _not_ be adopted, please also explicitly indicate the reasons. > > > > For the ANIMA WG chairs, > > Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > -- > --- > tte@cs.fau.de From nobody Thu Feb 13 02:37:37 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60B1200EC for ; Thu, 13 Feb 2020 02:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrtYdcF7mLon for ; Thu, 13 Feb 2020 02:37:33 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87171200E6 for ; Thu, 13 Feb 2020 02:37:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JJCNK9WG08S4En7fycAp7OLQdbKg154HrIn2w79sJ7Ly7OFyjFLuVeLC4uRQGmUPm/6wzjgiWO9coFybkEcA1pHVVrMsGB3okH9VCDJhaxdP5Ly8Repdsqao293CEAAvepD7vQyUtK/gnt4iea7he5FsgTl8A4KSrPt6X56SM3/NGzZ8zt3PixjCPI19/aNDAuOtxr0hgnaHgy7IFBkstBcgLPOiNK1Osrsa1puTvzVefajTJnBQlGApBQKPIvK+YYj2Ku9+YH+Xns/TFpoY3PBwKACv3IVeKm9EWF69MzzKA7JZNThkPsPmKoD27IyuZXTXRw1Qf4sV9/WPTW2TGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sWSoZOg+AtoeFOALymMDX2Q3k0f9mPqhWgRbkyYAevo=; b=gGZV6Pm0ZBvx8f+I85w5JY+eBj8JBhuAE4rBHBPmx7FDfG4m1xOugTvcLh9LJh0JKicPiNqevUYBFWzhTEf6mVbBWevUN4juIPKzepQHOhFnYscT0xOGugTsOjvag/EeDFLRYgJ8iYbLsDl9FTp00ZDzFJQNqDdBP0xoy5mYJlMOFHMUxmBU9ixeqi4XJ2Ptyv7URFd75MtKja2/Bw2843tIdO22qozdIe3ZMVZ6A3+Dxc/hkMil8DjAUAYclhTjr1K7l/aozEzHc9wlg87DsUAmkGI2lMKA+Xe9oGI6wM7hs2baaX3NH9U342JZnGvB6G6XbD6HYYJRxQbQ8cMJwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sWSoZOg+AtoeFOALymMDX2Q3k0f9mPqhWgRbkyYAevo=; b=QMut8CnROmnToNB2DHv39y4oogJrHKVC8O5qgxVrSo30l2JSCrfvXJ9ThIDUnKt14mM8/qhLoTglN96KoGAj0Yx38Eiz9syAEX6v+jRFpHwejSF6dJ2Aa4PZP7B9IlzspEEjYgKa1+MLBeKC8N8kQ6vqZLoUSIGZvAwhHrAiih4= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0321.EURP190.PROD.OUTLOOK.COM (10.161.92.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Thu, 13 Feb 2020 10:37:29 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f%7]) with mapi id 15.20.2729.025; Thu, 13 Feb 2020 10:37:29 +0000 From: Esko Dijk To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) Thread-Index: AQHV4DtfaEigTItIrkaa5Oarwn0J06gXrSSggAFDguA= Date: Thu, 13 Feb 2020 10:37:29 +0000 Message-ID: References: <1272.1581357351@dooku> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:6d00:7120:9727:b8d4:802a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff7c9b17-10fd-4f1f-54cf-08d7b070b9b5 x-ms-traffictypediagnostic: AM5P190MB0321: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39830400003)(396003)(376002)(366004)(199004)(189003)(316002)(33656002)(66556008)(66446008)(7696005)(64756008)(110136005)(76116006)(66476007)(71200400001)(2906002)(8936002)(66946007)(52536014)(55016002)(44832011)(9686003)(86362001)(81166006)(81156014)(8676002)(6506007)(53546011)(5660300002)(966005)(186003)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0321; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v+D+zSvxwWF1gu4AvIneP60sROBA+p8nGKvxDz13bp4gwAFD03rr33t3v+Nz5PzWqRvUJFeNu1RPgsAoc6pgCYL0sCorrjj4WrgQlGVp3avd+Pio/JfUklW83pxJWs/iXa249FeeneM6iDSDAYLHD+S48/iT5t4AOmnDlJg6rHslJ44NOIX45w2gJ0aZeP8tUAC3dkjILgXLoPvxNFk6NWBHdDsGkV1YflFPyE0gUX9S6aebR83st6YG5qJ6Cfp5Pefssuk3ufc4wfukEizdDDZRDX9HGl6pSuDR7xy7+tTx3OsvtoQRIP1gJpVUa43gv8Jh3U6zmAeRUaNSUEcdi3AaNXxKtlf+JCBSY3DRFg3v3OEdUw1y1uorwGApciO9I6OGGqySB9PfDSkdqOHCMYH1woOqOgCPgE7lWrddzzzY0vexjevTHSweKGSnybkuKG/Aejde/DaFZUF35iKlMk6A25STCJMUiaSXQEprtilwalUXyu+YKyzwHV8uXFPWgX8kKlzIjPI+09hFq466IA== x-ms-exchange-antispam-messagedata: +C6XIpSgAhF05cNNBBI3RZ9qivu9vAc6pA4/Za5pwiA3PUyymbbRXf3zxtJkB+XTeL9ORnHMQzF+iZgssk35O2RRSXEmmo9ZgiFp7//ODvtCqBuFRXRQDXdc4Xo275NznNRejEY+uMTtvY5kgD1rtcxOBvPwJdxeiXHHS3Yx8IDtGq4VVqE5VDPBWjBlongHAVXjMTTPXoHIQnLpqN9DBA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: ff7c9b17-10fd-4f1f-54cf-08d7b070b9b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 10:37:29.3189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YbaVtV9loowBitA8xfrzZkJQnTrOU1eNVfMsEP3HjcZ56qMnHUAniGjMWf5XsKqZmmcVs4gidy297oS6qD0ZZ7I5V7eI5OqjdwaMAef2PEk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0321 Archived-At: Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 10:37:37 -0000 UFMsIGEgc21hbGwgYWRkaXRpb25hbCByZW1hcmsgdG8gbXkgYmVsb3cgZW1haWwgcXVlc3Rpb246 DQoNCj4gQlJTS0ktMzUgcmVxdWlyZXMgTUFTQSB0byBwaW4gdGhlIERvbWFpbiBDQSBjZXJ0OyB3 aHkgd291bGQgdGhlIE1BU0Egbm90IGRvIHRoaXM/ICANCj4gV2hhdCB0aGUgUGxlZGdlIHNhdyBk dXJpbmcgdGhlIERUTFMgaGFuZHNoYWtlIGlzIHRoZSBjZXJ0IGNoYWluIFJlZ2lzdHJhci1jZXJ0 IC0+IERvbWFpbi1DQS1jZXJ0DQo+ICh0eXBpY2FsbHkgMiBjZXJ0cyBsb25nKS4gQXQgdGhlIG1v bWVudCB0aGUgUGxlZGdlIHJlY2VpdmVzIHRoZSBWb3VjaGVyIHBpbm5pbmcgdGhlIERvbWFpbiBD QSBjZXJ0IA0KPiBpdCBrbm93cyBpdCBjYW4gdHJ1c3QgdGhlIFJlZ2lzdHJhciwgdHJ1c3QgdGhl IERUTFMgc2Vzc2lvbiwgdHJ1c3QgdGhlIERvbWFpbiwgYW5kIHRydXN0IGFueSBFU1QgY2VydGlm aWNhdGUgDQo+IHRoYXQgaXMgaXNzdWVkIGluIHRoZSBuZXh0IHN0ZXAgLSB0aGUgRVNULWNyZWF0 ZWQgb3BlcmF0aW9uYWwgKGRvbWFpbikgY2VydGlmaWNhdGVzIGFyZSBub3Qgc2lnbmVkIGJ5IA0K PiBSZWdpc3RyYXIgYnV0IGJ5IHRoZSBFU1QgQ0EgPT0gRG9tYWluIENBLiAgU28gaGF2aW5nIERv bWFpbiBDQSBhcyB0cnVzdCBhbmNob3IgdG8gdmFsaWRhdGUgeW91ciBvd24gDQo+IG5ldyBjZXJ0 aWZpY2F0ZSwgYW5kIHBvc3NpYmx5IGFsc28gb3RoZXIgZGV2aWNlJ3MgY2VydHMgaW4gdGhlIHNh bWUgRG9tYWluLCBtYWtlcyBzZW5zZS4gICANCg0KV2hhdCB0aGUgUGxlZGdlIHNhdyBkdXJpbmcg dGhlIERUTFMgaGFuZHNoYWtlIGNvdWxkIGFsc28gaGF2ZSBiZWVuIHRoZSBSZWdpc3RyYXItY2Vy dCBvbmx5IChzbywgYSBjaGFpbiBvZiAyIHdpdGggdGhlIHNlbGYtc2lnbmVkIHJvb3QgQ0Egb21p dHRlZCAtIDEgY2VydCBzZW50IG92ZXIgdGhlIHdpcmUpLg0KV2hlbiB0aGUgUGxlZGdlIHRoZW4g cmVjZWl2ZXMgdGhlIFZvdWNoZXIgcGlubmluZyB0aGUgRG9tYWluIENBIGNlcnQgaXQgdGFrZXMg dGhlIERvbWFpbiBDQSBjZXJ0IGFuZCB1c2VzIGl0IHRvIHZhbGlkYXRlIHRoZSBSZWdpc3RyYXIg Y2VydCwgdGhlIERUTFMgc2Vzc2lvbiBldGMuICBTbyBpdCBhbHNvIHdvcmtzIHdoZW4gdGhlIERv bWFpbiBDQSBjZXJ0IGlzIG5vdCBzZW50IGR1cmluZyB0aGUgRFRMUyBoYW5kc2hha2UsIHdoaWNo IGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBSZWdpc3RyYXIgRFRMUyBzZXJ2ZXIgaWYgaXQgd291 bGQgc2VuZCBpdCBvciBub3QuIENoYWlucyB3aXRoIGludGVybWVkaWF0ZSBjZXJ0cyBhcmUgYWxz byBwb3NzaWJsZSBidXQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMgZGVmaW5pbmcgYSAobG93KSBj ZXJ0IGNoYWluIGxpbWl0IGlzIHVzZWZ1bCwgaGVuY2UgbXkgZXhhbXBsZXMgd2l0aCBjaGFpbnMg b2YgMi4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEg PGFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBFc2tvIERpamsNClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMjAgMTc6NTYNClRvOiBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGFuaW1hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Fu aW1hXSBbYW5pbWEtd2cvY29uc3RyYWluZWQtdm91Y2hlcl0gVW5jbGVhciBob3cgTUFTQSBvYnRh aW5zIERvbWFpbiBDQSBjZXJ0IGZvciBwaW5uaW5nLCBpbiBjYXNlIG9mIENPU0Utc2lnbmVkIFZv dWNoZXIgUmVxdWVzdCAoIzQ5KQ0KDQpUaGFua3MsDQptZWFud2hpbGUgSSByZWFkIEJSU0tJLTM1 IDUuNCAvIDUuNC4xIGJldHRlciBhbmQgSSBhbSByZWNvbnNpZGVyaW5nIG15IHByb3Bvc2FsLiBU aGVzZSBzZWN0aW9ucyBzdGF0ZSB0aGF0IHRoZSBSZWdpc3RyYXIncyBjbGllbnQgYXV0aGVudGlj YXRpb24gdG93YXJkcyBNQVNBIG1heSBkaWZmZXIgZGVwZW5kaW5nIG9uIGJ1c2luZXNzLXByb2Nl c3MgYW5kIHNlY3VyaXR5IGNob2ljZXM7IGluZGVwZW5kZW50IGZyb20gdGhlIERvbWFpbiAoQ0Ep IGF1dGhlbnRpY2F0aW9uLiBJbiBCUlNLSSB0aGUgRG9tYWluIENBIGlzICJleHRyYWN0ZWQgZnJv bSB0aGUgc2lnbmF0dXJlIG1ldGhvZCIgKDUuNS4yKSwgc28gZnJvbSB0aGUgUmVnaXN0cmFyJ3Mg c2lnbmVkIENNUyBzdHJ1Y3R1cmU7IG5vdCBmcm9tIGlkZW50aXRpZXMgZXhjaGFuZ2VkIGluIHRo ZSBUTFMgaGFuZHNoYWtlIGJldHdlZW4gUmVnaXN0cmFyL01BU0EuIFRoaXMgc291bmRzIGxpa2Ug YW4gaW50ZW50aW9uYWwgZGVzaWduIGNob2ljZSBvZiBCUlNLSSB3ZSBzaG91bGQgc3RpY2sgdG8u DQoNCldoZW4gdGhlIFJlZ2lzdHJhciB1c2VzIENNUy1zaWduaW5nLCBhbGwgdGhlIGluZm9ybWF0 aW9uIHJlcXVpcmVkIGJ5IE1BU0EgaXMgaW4gdGhlcmUuICBXaGVuIHRoZSBSZWdpc3RyYXIgdXNl cyBDT1NFX1NpZ24xLCB0aGVyZSBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIC0tIG9ubHkgYSBL SUQgaWRlbnRpZnlpbmcgdGhlIGtleXBhaXIgb2YgdGhlIHNpZ25lci4gQnV0IG5vdCBhIGNlcnRp ZmljYXRlIG9yIGNlcnQgY2hhaW4sIHNvIHRoZSBNQVNBIHdvdWxkIG1pc3MgdGhpcyBpbmZvcm1h dGlvbiBhbmQgY2Fubm90IHBpbiBhbnl0aGluZy4gU28gYW0gSSByaWdodCBpbiBjb25jbHVkaW5n IHRoYXQgdGhlIFJlZ2lzdHJhciAqbXVzdCogdXNlIENNUy1zaWduaW5nIGluIGNhc2UgdGhlIFBs ZWRnZSBoYXMgaWRlbnRpZmllZCBpdHNlbGYgYnkgY2VydGlmaWNhdGUgaW4gdGhlIERUTFMgaGFu ZHNoYWtlPyBUaGlzIGZpdHMgd2l0aCBjb25zdHJhaW5lZC12b3VjaGVyLTA3IHNlY3Rpb24gNDog IlRoZSB1c2Ugb2YgQ01TIHNpZ25hdHVyZXMgaW1wbGllcyB0aGUgdXNlIG9mIFBLSVggZm9ybWF0 IGNlcnRpZmljYXRlcyIgLiBUaGVuIGl0IGlzIGFsc28gdGhlIG90aGVyIHdheSBhcm91bmQsIHRo ZSB1c2Ugb2YgUEtJWCBjZXJ0aWZpY2F0ZXMgKGJ5IHRoZSBQbGVkZ2UpIGltcGxpZXMgdGhlIHVz ZSBvZiBDTVMgc2lnbmF0dXJlcyBieSB0aGUgUmVnaXN0cmFyLiBUaGUgUGxlZGdlIHNob3VsZCBz dGlsbCBiZSBhYmxlIHRvIHNpZ24gd2l0aCBDT1NFX1NpZ24xIEkgdGhpbmsgYmVjYXVzZSBvZiB0 aGUgc21hbGwtc2l6ZSBiZW5lZml0LiBJdCBjYW4gc2ltcGx5IHVzZSB0aGUgcHJpdmF0ZSBrZXkg b2YgaXRzIElEZXZJRC1jZXJ0IHRvIHNpZ24uDQoNCj4gSW4gdGhlIG1vcmUgY29uc3RyYWluZWQg Y2FzZXMsIHRoZSBSZWdpc3RyYXIgaXMgaWRlbnRpZmllZCBieSBhIFJhdyBQdWJsaWMNCj4gS2V5 LiBbVGhpcyB3b3JrcyBpbiBEVExTIGFuZCB3aWxsIHdvcmsgaW4gTEFLRSBieSBkZXNpZ25dDQoN CkFncmVlIHRoYXQgaW4gdGhlIG1vc3QgY29uc3RyYWluZWQgY2FzZXMgdGhlIFJlZ2lzdHJhciBp cyBpZGVudGlmaWVkIHRvd2FyZHMgdGhlIFBsZWRnZSBieSBhbiBSUEs7IGFuZCB2aWNlIHZlcnNh IFBsZWRnZSBpZGVudGlmaWVzIHRvd2FyZHMgUmVnaXN0cmFyIHdpdGggaXRzIFJQSy4gSSBhc3N1 bWUgdGhlIFJlZ2lzdHJhciBtYXkgc3RpbGwgaWRlbnRpZnkgZGlmZmVyZW50bHkgdG93YXJkcyB0 aGUgTUFTQSBkZXBlbmRpbmcgb24gYnVzaW5lc3MtcHJvY2VzcyB0YWtpbmcgaW50byBhY2NvdW50 IHRoZSA1LjQgLyA1LjQuMSB0ZXh0IGFib3ZlLiBFLmcuLCB1c2luZyBhIGZ1bGwgY2VydGlmaWNh dGUgY2hhaW4sIHBvc3NpYmx5IFBLSVgsIHdpdGggYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBpZGVu dGl0eSB0aGFuIHRoZSBSUEsgaXQgdXNlZCB0b3dhcmRzIHRoZSBQbGVkZ2UuIEJ1dCBpZiB0aGlz IGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0IHBsZWFzZSBsZXQgbWUga25vdy4gDQoNCj4gSW4gdGhl IG1vcmUgY29uc3RyYWluZWQgY2FzZXMsIHRoZSBSZWdpc3RyYXIgaXMgaWRlbnRpZmllZCBieSBh IFJhdyBQdWJsaWMNCj4gS2V5LiBbVGhpcyB3b3JrcyBpbiBEVExTIGFuZCB3aWxsIHdvcmsgaW4g TEFLRSBieSBkZXNpZ25dDQo+IFRoaXMgaXMgd2hhdCBzaG91bGQgYmUgcGlubmVkIGJ5IHRoZSBN QVNBLCBiZWNhdXNlIHRoYXQncyB3aGF0IHRoZSBwbGVkZ2Ugc2F3Lg0KDQpBZ3JlZSBmb3IgdGhp cyBjYXNlOyB0aGUgb25seSB0aGluZyB0aGF0IGNhbiBzZW5zaWJseSBiZSBwaW5uZWQgaXMgdGhl IFJlZ2lzdHJhcidzIFJQSy4gUXVlc3Rpb246IElzIGl0IHRoZSBpbnRlbnRpb24gb2YgY29uc3Ry YWluZWQtdm91Y2hlci0wNyB0aGF0IHRoZSBSZWdpc3RyYXIgYWx3YXlzIHVzZXMgQ09TRV9TaWdu MSBzaWduZWQgVm91Y2hlciBSZXF1ZXN0IHRvIE1BU0EsIGluIGNhc2UgdGhlIFBsZWRnZSBpZGVu dGlmaWVkIGl0c2VsZiB3aXRoIFJQSyBkdXJpbmcgdGhlIERUTFMgaGFuZHNoYWtlPyAoSGludGVk IGF0IGluIGNvbnN0cmFpbmVkLXZvdWNoZXItMDcgc2VjdGlvbiA0LiBCdXQgbm90IGZ1bGx5IGNs ZWFyLikNCg0KPiBJZiB5b3UgYXJlIHVzaW5nIGEgY2VydGlmaWNhdGUgY2hhaW4gZm9yIHRoZSBS ZWdpc3RyYXIgZW5kIHBvaW50LCB0aGUgTUFTQQ0KPiBkb2VzIG5vdCBoYXZlIHRvIHBpbiB0aGUg RG9tYWluIENBLCBpdCBjYW4gaW5zdGVhZCBwaW4gdGhlIFJlZ2lzdHJhcg0KPiBjZXJ0aWZpY2F0 ZSwgc2luY2UgYWdhaW4sIHRoYXQncyB3aGF0IHRoZSBwbGVkZ2Ugc2F3IChhbmQgc2lnbmVkKS4N Cg0KQlJTS0ktMzUgcmVxdWlyZXMgTUFTQSB0byBwaW4gdGhlIERvbWFpbiBDQSBjZXJ0OyB3aHkg d291bGQgdGhlIE1BU0Egbm90IGRvIHRoaXM/ICBXaGF0IHRoZSBQbGVkZ2Ugc2F3IGR1cmluZyB0 aGUgRFRMUyBoYW5kc2hha2UgaXMgdGhlIGNlcnQgY2hhaW4gUmVnaXN0cmFyLWNlcnQgLT4gRG9t YWluLUNBLWNlcnQgKHR5cGljYWxseSAyIGNlcnRzIGxvbmcpLiBBdCB0aGUgbW9tZW50IHRoZSBQ bGVkZ2UgcmVjZWl2ZXMgdGhlIFZvdWNoZXIgcGlubmluZyB0aGUgRG9tYWluIENBIGNlcnQgaXQg a25vd3MgaXQgY2FuIHRydXN0IHRoZSBSZWdpc3RyYXIsIHRydXN0IHRoZSBEVExTIHNlc3Npb24s IHRydXN0IHRoZSBEb21haW4sIGFuZCB0cnVzdCBhbnkgRVNUIGNlcnRpZmljYXRlIHRoYXQgaXMg aXNzdWVkIGluIHRoZSBuZXh0IHN0ZXAgLSB0aGUgRVNULWNyZWF0ZWQgb3BlcmF0aW9uYWwgKGRv bWFpbikgY2VydGlmaWNhdGVzIGFyZSBub3Qgc2lnbmVkIGJ5IFJlZ2lzdHJhciBidXQgYnkgdGhl IEVTVCBDQSA9PSBEb21haW4gQ0EuICBTbyBoYXZpbmcgRG9tYWluIENBIGFzIHRydXN0IGFuY2hv ciB0byB2YWxpZGF0ZSB5b3VyIG93biBuZXcgY2VydGlmaWNhdGUsIGFuZCBwb3NzaWJseSBhbHNv IG90aGVyIGRldmljZSdzIGNlcnRzIGluIHRoZSBzYW1lIERvbWFpbiwgbWFrZXMgc2Vuc2UuICAg DQoNCj4gSWYgeW91IHdhbnQgdXMgdG8gZGVmaW5lIGEgd2F5IHRvIHBpbiB0aGUgZG9tYWluIENB LCB0aGVuIEkgdGhpbmsgdGhhdCByaWdodA0KPiBhbnN3ZXIgaXMgdG8gcGFzcyB0aGF0IGVudGly ZSBjaGFpbiBhbG9uZyB0byB0aGUgUGxlZGdlIGluIHRoZSBCUlNLSS1FU1QNCj4gY2hhbm5lbCBp biB0aGUgRFRMUyBoZWFkZXIsIGFuZCBoYXZlIHRoZSBwbGVkZ2Ugc2lnbiB0aGF0IGVudGlyZSBv YmplY3QuDQo+IFRoaXMgd291bGRuJ3QgYmUgdmVyeSBjb25zdHJhaW5lZCwgc28gSSBhbSBub3Qg c3VyZSB3aHkgb25lIHdvdWxkIGRvIHRoaXMNCj4gcmF0aGVyIHRoYW4gdXNpbmcgVExTIGluIHRo YXQgY2FzZS4NCg0KSSB0aGluayB0aGlzIHdheSB0byBwaW4gdGhlIERvbWFpbiBDQSBpcyBhbHJl YWR5IHNwZWNpZmllZCBpbiBCUlNLSS0zNSBhbmQgcGFzc2VzIG9uIHF1aXRlIG5hdHVyYWxseSBp bnRvIGNvbnN0cmFpbmVkLUJSU0tJLCBhbmQgYXMgbG9uZyBhcyB0aGUgUmVnaXN0cmFyIHVzZXMg Q01TIHNpZ25pbmcgaW4gaXRzIFZvdWNoZXIgUmVxdWVzdCB0b3dhcmRzIE1BU0EgdGhlIGluaXRp YWwgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgbm90IHNvIHJlbGV2YW50LiANCkFuZCBpdCBkb2VzIG5v dCB0YWtlIGEgaHVnZSBhbW91bnQgb2YgcmVzb3VyY2VzIChuZXR3b3JrL21lbW9yeS9jb2RlL3Rp bWUpIG9uIGEgUGxlZGdlLiAgVGhlIGNlcnQgY2hhaW5zIGNhbiBiZSBrZXB0IHRvIGEgbWluaW11 bSAoaS5lLiBjaGFpbiBvZiAyKS4gT2YgY291cnNlIHdvcmtpbmcgd2l0aCBjZXJ0aWZpY2F0ZXMg aXMgYWx3YXlzIG1vcmUgcmVzb3VyY2UtZGVtYW5kaW5nIHRoYW4gUlBLcy1vbmx5IQ0KDQpCZXN0 IHJlZ2FyZHMNCkVza28NCg0KSW9UY29uc3VsdGFuY3kubmwgIHwgIEVtYWlsL1NreXBlOiBlc2tv LmRpamtAaW90Y29uc3VsdGFuY3kubmwgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBbmltYSA8YW5pbWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwg UmljaGFyZHNvbg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAyMCAxODo1Ng0KVG86IGFu aW1hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBbYW5pbWEtd2cvY29uc3RyYWluZWQt dm91Y2hlcl0gVW5jbGVhciBob3cgTUFTQSBvYnRhaW5zIERvbWFpbiBDQSBjZXJ0IGZvciBwaW5u aW5nLCBpbiBjYXNlIG9mIENPU0Utc2lnbmVkIFZvdWNoZXIgUmVxdWVzdCAoIzQ5KQ0KDQpJbiBo dHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvY29uc3RyYWluZWQtdm91Y2hlci9pc3N1ZXMvNDks IEVza28gRGlqayBhc2tzOg0KDQo+IEluIEJSU0tJICg1LjUuMiAgTUFTQSBwaW5uaW5nIG9mIHJl Z2lzdHJhcikgaXQgaXMgY2xlYXIgaG93IHRoZSBNQVNBIGNhbg0KPiBnZXQgdGhlIGNvbXBsZXRl IGNlcnQgY2hhaW4gb2YgdGhlIFJlZ2lzdHJhciBmcm9tIHRoZSBDTVMgc2lnbmF0dXJlDQo+IHN0 cnVjdHVyZS4gVGhlIFJlZ2lzdHJhcidzIERvbWFpbiBDQSBjZXJ0IGlzIGluY2x1ZGVkIGluIHRo ZXJlIGFuZCBpcyB1c2VkDQo+IGFzIHRoZSBwaW5uZWQgZG9tYWluIGNlcnQgaW4gdGhlIFZvdWNo ZXIuICBIb3dldmVyLCB3aGVuIHdlIG5vdyB1c2UNCj4gQ09TRS1zaWduZWQgVm91Y2hlciBSZXF1 ZXN0IGJ5IHRoZSBSZWdpc3RyYXIsIHRoZSBSZWdpc3RyYXIncyBEb21haW4gQ0ENCj4gY2VydCBp cyBub3QgaW5jbHVkZWQgaW4gdGhlIENPU0Utc2lnbiBzdHJ1Y3R1cmUgc28gdGhlIE1BU0EgY2Fu bm90DQo+ICJleHRyYWN0IiBpdCBwZXIgQlJTS0kgNS41LjIuDQoNCj4gSXQgd291bGQgYmUgZ29v ZCB0byBtYWtlIG1vcmUgZXhwbGljaXQgaG93IHRoZSBNQVNBIHNob3VsZCBleHRyYWN0IHRoZQ0K PiBSZWdpc3RyYXIncyBEb21haW4gQ0EgY2VydCBpbiB0aGlzIGNhc2UgKE5vdGU6IHRoZSBEb21h aW4gQ0EgY291bGQgYmUgdGhlDQo+IFJlZ2lzdHJhciBpdHNlbGYgYnV0IG5vdCBuZWNlc3Nhcmls eS4pICBUaGUgb2J2aW91cyBjYW5kaWRhdGUgaXMgdG8gZ2V0IGl0DQo+IGZyb20gdGhlIERUTFMg b3IgVExTIGhhbmRzaGFrZSB0aGF0IFJlZ2lzdHJhciBwZXJmb3JtcyB3aXRoIE1BU0EuIFRoaXMg aXMNCj4gYWxyZWFkeSBoaW50ZWQgYXQgaW4gdGhlIHRleHQgaW4gc2VjdGlvbiA2LjEuMyAvIDYu Mi4zIGluc2lkZSB0aGUgWUFORw0KPiBtb2R1bGUgZGVzY3JpcHRpb24gIi4uLiBpdCBpcyB3YXN0 ZWZ1bCAuLi4gIiBidXQgdGhhdCBpcyBub3QgcXVpdGUNCj4gY2xlYXIuIFdoZW4gUmVnaXN0cmFy IGlzIHVzaW5nIENPU0Ugc2lnbmluZyB0aGUgTUFTQSAqaGFzKiB0byBnZXQgdGhlDQo+IGNlcnRp ZmljYXRlIGZyb20gdGhlIGhhbmRzaGFrZSBpZiB0aGUgTUFTQSB3YW50cyB0byBwaW4gdGhlIGVu dGlyZQ0KPiBjZXJ0aWZpY2F0ZSBpbiB0aGUgVm91Y2hlciwgdGhlcmUgc2VlbXMgdG8gYmUgbm8g b3RoZXIgb3B0aW9uLiBTZWN0aW9uDQo+IDYuMy4yIG5vdyBtZW50aW9ucyAib3V0IG9mIGJhbmQi IGRpc3RyaWJ1dGlvbiBidXQgdGhhdCdzIG5vdCB2ZXJ5IGNsZXZlciBpZg0KPiB5b3Ugd2FudCBh dXRvbWF0ZWQgYm9vdHN0cmFwcGluZyAtIGl0IG5lZWRzIHRvIGdvIGFsbCBpbi1wcm90b2NvbCAv DQo+IGluLWJhbmQuDQoNCj4gSXQgc2hvdWxkIGJlIG5vdGVkIGFsc28gdGhhdCB0aGlzIG1vZGlm aWVzIHRoZSBCUlNLSSByZXF1aXJlbWVudCBzZWN0aW9uDQo+IDUuNS4yIG9uIGhvdyB0aGUgcGlu bmVkIERvbWFpbiBDQSBjZXJ0IGlzIG9idGFpbmVkLg0KDQpJbiB0aGUgbW9yZSBjb25zdHJhaW5l ZCBjYXNlcywgdGhlIFJlZ2lzdHJhciBpcyBpZGVudGlmaWVkIGJ5IGEgUmF3IFB1YmxpYw0KS2V5 LiBbVGhpcyB3b3JrcyBpbiBEVExTIGFuZCB3aWxsIHdvcmsgaW4gTEFLRSBieSBkZXNpZ25dDQpU aGlzIGlzIHdoYXQgc2hvdWxkIGJlIHBpbm5lZCBieSB0aGUgTUFTQSwgYmVjYXVzZSB0aGF0J3Mg d2hhdCB0aGUgcGxlZGdlIHNhdy4NCg0KSWYgeW91IGFyZSB1c2luZyBhIGNlcnRpZmljYXRlIGNo YWluIGZvciB0aGUgUmVnaXN0cmFyIGVuZCBwb2ludCwgdGhlIE1BU0ENCmRvZXMgbm90IGhhdmUg dG8gcGluIHRoZSBEb21haW4gQ0EsIGl0IGNhbiBpbnN0ZWFkIHBpbiB0aGUgUmVnaXN0cmFyDQpj ZXJ0aWZpY2F0ZSwgc2luY2UgYWdhaW4sIHRoYXQncyB3aGF0IHRoZSBwbGVkZ2Ugc2F3IChhbmQg c2lnbmVkKS4NCg0KSWYgeW91IHdhbnQgdXMgdG8gZGVmaW5lIGEgd2F5IHRvIHBpbiB0aGUgZG9t YWluIENBLCB0aGVuIEkgdGhpbmsgdGhhdCByaWdodA0KYW5zd2VyIGlzIHRvIHBhc3MgdGhhdCBl bnRpcmUgY2hhaW4gYWxvbmcgdG8gdGhlIFBsZWRnZSBpbiB0aGUgQlJTS0ktRVNUDQpjaGFubmVs IGluIHRoZSBEVExTIGhlYWRlciwgYW5kIGhhdmUgdGhlIHBsZWRnZSBzaWduIHRoYXQgZW50aXJl IG9iamVjdC4NClRoaXMgd291bGRuJ3QgYmUgdmVyeSBjb25zdHJhaW5lZCwgc28gSSBhbSBub3Qg c3VyZSB3aHkgb25lIHdvdWxkIGRvIHRoaXMNCnJhdGhlciB0aGFuIHVzaW5nIFRMUyBpbiB0aGF0 IGNhc2UuDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4s IFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1h aWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYW5pbWENCg== From nobody Wed Feb 19 09:01:31 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659B01208CC; Wed, 19 Feb 2020 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oh4pVaZCUKr; Wed, 19 Feb 2020 09:01:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAE81208BC; Wed, 19 Feb 2020 09:01:13 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BE65EFE7BF644995551F; Wed, 19 Feb 2020 17:01:10 +0000 (GMT) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Feb 2020 17:01:10 +0000 Received: from fraeml719-chm.china.huawei.com (10.206.15.15) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 19 Feb 2020 18:01:10 +0100 Received: from fraeml719-chm.china.huawei.com ([10.206.15.15]) by fraeml719-chm.china.huawei.com ([10.206.15.15]) with mapi id 15.01.1713.004; Wed, 19 Feb 2020 18:01:10 +0100 From: Xun Xiao To: "Liubing (Leo)" , Toerless Eckert , "anima@ietf.org" CC: "draft-liu-anima-grasp-distribution@ietf.org" Thread-Topic: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) Thread-Index: AQHVygcEixrclYVRzkuIMbNn6stxL6gVKlSAgAOcCoCACjEFYA== Date: Wed, 19 Feb 2020 17:01:09 +0000 Message-ID: <5daa3023ba51435988eb29ccf6f73143@huawei.com> References: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> <8AE0F17B87264D4CAC7DE0AA6C406F45DE7333FD@DGGEML532-MBX.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45DE7333FD@DGGEML532-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.96.35] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 17:01:22 -0000 Dear Toerless, Just followed Bing's reply, we were currently editing to first record all p= rovided comments. We will update a new version for that soon.=20 After that we will start to address all technical issues one by one and kee= p improving the draft. Best Regards, Xun Xiao (=1B$B>S?W=1B(B) Advanced Wireless Technology Lab Munich Research Center Huawei Technologies Co.,Ltd. -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) Sent: Thursday, 13 February 2020 07:20 To: Toerless Eckert ; anima@ietf.org Cc: draft-liu-anima-grasp-distribution@ietf.org Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (= ends 01/27/2020) Hi Toerless, Thanks a lot for summarizing the comments! We'll revise a new version as you suggested, and upload it soon. We'll also= try to maintain a github repo. Best regards, Bing > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: Tuesday, February 11, 2020 7:13 AM > To: anima@ietf.org > Cc: draft-liu-anima-grasp-distribution@ietf.org > Subject: Re: [Anima] Adoption call for=20 > draft-liu-anima-grasp-distribution (ends > 01/27/2020) >=20 > We had 5 voices feedback (from non-authors) to support adoption of=20 > this document, and no voices objecting. I think this qualifies for=20 > adoption of the document. >=20 > Nevertheless, the supporting voices did indicate a range of=20 > improvements they would like to see. So, jere is what i would propose: >=20 > Dear-authors: >=20 > A) Please add a section Open Issues, mark it as > [RFC-Editor: To Be removed before becoming RFC]. > Make it contain the following text: >=20 > The following issues where identified by the WG when adopting the -00=20 > draft version. These issues will be individually removed in upcoming=20 > when they are resolved. >=20 > 1. More reference to the use cases in the introduction. >=20 > 2. Better explanation of the required context of the Connected-Car case: > Not applicable unless the ACP will be extended to the car, which may=20 > not be desirable with the current ACP design, but maybe refocussing on=20 > an "autonomous fleet" use-case (e.g.: all cars operated by some taxi like= service). >=20 > 3. Consider use-case/example of firmware update. By abstracting the=20 > location of the firmware from the name of the firmware, while=20 > providing a way to notify about it, this significantly supports distribut= ion of firmware updates. > References to SUIT would appropriate. >=20 > 4. Issues discussed in > https://mailarchive.ietf.org/arch/msg/anima/_0fYQPBcLPt8xzQee7P4dILsn3 > A >=20 > 5. Rethink/refine terminology, e.g.: "module" seems to be too prescriptiv= e. > Refine proposed extensions. >=20 > 6. I support adoption, but also support the suggestion (from IETF106)=20 > Provide more protocol behavior description instead of only=20 > implementation / software module architecture description. > Reduce the latter or provide better justification for their presence=20 > due to explained interoperability requirements. >=20 > 7. Better motivation in sections 1..4 of the proposed extensions >=20 > 8. Consider moving examples from appendices into core-text . Ideally=20 > craft a single use-case showing/applying all extensions (most simple=20 > use case that uses them all). >=20 > 9. Refine terminology to better match/reuse-the established=20 > terminology from the pre-existing ANIMA documents. >=20 > B) Add changelog section, equally marked as to be removed before . For=20 > this version -00 it should just list above section from A) to be new. >=20 > C) Designate in the authors list one or two main editors for the time > being, doesn't have to be final, just whoever has the main edit pen > from you. Post this version as -00 with name > draft-ietf-anima-grasp-distribution-00 > and replacing draft-liu-anima-grasp-distribution >=20 > I will then approve that doc as WG chair. >=20 > D) Feel free to work on -01 and further. In the changelog, please > describe for each change which of the above 9 points are addressed by > the change and concentrate on those changes first before addressing > further enhancements. >=20 > E) I would strongly suggest you authors consider to create a repo for > this document under www.github.com/anima-wg It specifically makees > it easier to open for each of the above 10 bullet points possible > "Issues" where it would be easier to have focussed discusses. >=20 > I am not a github is the only way groupie though, so please make sure > all discussions are Cc'ed to the mailing list, even though it may prim= arily be on > github to make then easier to track/find. >=20 > Cheers > Toerless >=20 > On Mon, Jan 13, 2020 at 12:45:33PM +0100, Toerless Eckert wrote: > > This message starts a two-week adoption call, it ends on January 27th, = 2020. > > > > draft-liu-anima-grasp-distribution was progressed up to version -13=20 > > with the help of the WG, it was last presented at IETF106 with good int= erest. > > The draft is now clearly in scope of ANIMA charter 2 that was=20 > > adopted around IETF106. The authors asked for adoption of the document. > > As far as the chairs heard, there was no objection in the room. > > > > We therefore are asking the ANIMA working group for adoption of the > following work: > > > > Title: Information Distribution in Autonomic Networking > > Name: draft-liu-anima-grasp-distribution > > Authors: B. Liu, X. Xiao, A. Hecker, S. Jiang, Z. Despotovic > > URL: https://datatracker.ietf.org/doc/draft-liu-anima-grasp-distri= bution/ > > > > This document is intended to become a standards track ANIMA WG document= . > > > > Standard track is desired because it is meant to become the required=20 > > small set of protocol extensions to the GRASP protocol in support of=20 > > the self-organization of ASA. > > > > Please express your support or rejection. If you think this document=20 > > should _not_ be adopted, please also explicitly indicate the reasons. > > > > For the ANIMA WG chairs, > > Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > -- > --- > tte@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Mon Feb 24 11:25:25 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AEE3A0B44; Mon, 24 Feb 2020 11:25:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Toerless Eckert , tte+ietf@cs.fau.de X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158257232254.24363.8909440574783537379.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2020 11:25:22 -0800 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-35: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:25:23 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-35: Discuss 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-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updated examples using the allocated MASA URL extension OID! Unfortunately, I think there are still some inconsistencies in the examples to resolve: The MASA cert/key is identical to the "manufacturer key pair for IDevID signatures" (C.1.1 and C.1.2). (It shows the MASA Subject CN, so maybe just the included file was typo'd?) The example IDevID cert shows an issuer name that doesn't match the cert given. (Also the MASA cert doesn't have a randomized serial number but the registrar one does.) The registrar-to-MASA voucher request in C.2.2 seems to have a CMS SignedData with the SignerIdentifier identifying the "Unstrung Fountain Root" (i.e,. the root CA used for these examples) instead of the expected "fountain-test.example.com". Am I misreading the ASN.1 dump? (We do seem to send both certificates.) The voucher response from MASA to Registrar seems to be signed by the "highway-test.example.com CA" (which would be the "manufacturer key pair for IDevID signatures" that we don't have in the -35 since the MASA certificate is repeated), not the MASA's cert from C.1.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [trimming presumably stale comments] From nobody Mon Feb 24 11:54:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5A3A11FD; Mon, 24 Feb 2020 11:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va_PoAjdMmBN; Mon, 24 Feb 2020 11:53:59 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D2C3A11FC; Mon, 24 Feb 2020 11:53:55 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2B707548005; Mon, 24 Feb 2020 20:53:50 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 22F1F440040; Mon, 24 Feb 2020 20:53:50 +0100 (CET) Date: Mon, 24 Feb 2020 20:53:50 +0100 From: Toerless Eckert To: Xun Xiao Cc: "Liubing (Leo)" , "anima@ietf.org" , "draft-liu-anima-grasp-distribution@ietf.org" Message-ID: <20200224195350.GA46905@faui48f.informatik.uni-erlangen.de> References: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> <8AE0F17B87264D4CAC7DE0AA6C406F45DE7333FD@DGGEML532-MBX.china.huawei.com> <5daa3023ba51435988eb29ccf6f73143@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5daa3023ba51435988eb29ccf6f73143@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:54:01 -0000 Thanks, Xun, Send an email when you have a new version, just in case datatrackers notification to the chairs for accepting the post with the WG name is lost somewhere. Cheers Toerless On Wed, Feb 19, 2020 at 05:01:09PM +0000, Xun Xiao wrote: > Dear Toerless, > > Just followed Bing's reply, we were currently editing to first record all provided comments. We will update a new version for that soon. > > After that we will start to address all technical issues one by one and keep improving the draft. > > Best Regards, > > Xun Xiao (?$B>S?W) > Advanced Wireless Technology Lab > Munich Research Center > Huawei Technologies Co.,Ltd. > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > Sent: Thursday, 13 February 2020 07:20 > To: Toerless Eckert ; anima@ietf.org > Cc: draft-liu-anima-grasp-distribution@ietf.org > Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) > > Hi Toerless, > > Thanks a lot for summarizing the comments! > We'll revise a new version as you suggested, and upload it soon. We'll also try to maintain a github repo. > > Best regards, > Bing > > > -----Original Message----- > > From: Toerless Eckert [mailto:tte@cs.fau.de] > > Sent: Tuesday, February 11, 2020 7:13 AM > > To: anima@ietf.org > > Cc: draft-liu-anima-grasp-distribution@ietf.org > > Subject: Re: [Anima] Adoption call for > > draft-liu-anima-grasp-distribution (ends > > 01/27/2020) > > > > We had 5 voices feedback (from non-authors) to support adoption of > > this document, and no voices objecting. I think this qualifies for > > adoption of the document. > > > > Nevertheless, the supporting voices did indicate a range of > > improvements they would like to see. So, jere is what i would propose: > > > > Dear-authors: > > > > A) Please add a section Open Issues, mark it as > > [RFC-Editor: To Be removed before becoming RFC]. > > Make it contain the following text: > > > > The following issues where identified by the WG when adopting the -00 > > draft version. These issues will be individually removed in upcoming > > when they are resolved. > > > > 1. More reference to the use cases in the introduction. > > > > 2. Better explanation of the required context of the Connected-Car case: > > Not applicable unless the ACP will be extended to the car, which may > > not be desirable with the current ACP design, but maybe refocussing on > > an "autonomous fleet" use-case (e.g.: all cars operated by some taxi like service). > > > > 3. Consider use-case/example of firmware update. By abstracting the > > location of the firmware from the name of the firmware, while > > providing a way to notify about it, this significantly supports distribution of firmware updates. > > References to SUIT would appropriate. > > > > 4. Issues discussed in > > https://mailarchive.ietf.org/arch/msg/anima/_0fYQPBcLPt8xzQee7P4dILsn3 > > A > > > > 5. Rethink/refine terminology, e.g.: "module" seems to be too prescriptive. > > Refine proposed extensions. > > > > 6. I support adoption, but also support the suggestion (from IETF106) > > Provide more protocol behavior description instead of only > > implementation / software module architecture description. > > Reduce the latter or provide better justification for their presence > > due to explained interoperability requirements. > > > > 7. Better motivation in sections 1..4 of the proposed extensions > > > > 8. Consider moving examples from appendices into core-text . Ideally > > craft a single use-case showing/applying all extensions (most simple > > use case that uses them all). > > > > 9. Refine terminology to better match/reuse-the established > > terminology from the pre-existing ANIMA documents. > > > > B) Add changelog section, equally marked as to be removed before . For > > this version -00 it should just list above section from A) to be new. > > > > C) Designate in the authors list one or two main editors for the time > > being, doesn't have to be final, just whoever has the main edit pen > > from you. Post this version as -00 with name > > draft-ietf-anima-grasp-distribution-00 > > and replacing draft-liu-anima-grasp-distribution > > > > I will then approve that doc as WG chair. > > > > D) Feel free to work on -01 and further. In the changelog, please > > describe for each change which of the above 9 points are addressed by > > the change and concentrate on those changes first before addressing > > further enhancements. > > > > E) I would strongly suggest you authors consider to create a repo for > > this document under www.github.com/anima-wg It specifically makees > > it easier to open for each of the above 10 bullet points possible > > "Issues" where it would be easier to have focussed discusses. > > > > I am not a github is the only way groupie though, so please make sure > > all discussions are Cc'ed to the mailing list, even though it may primarily be on > > github to make then easier to track/find. > > > > Cheers > > Toerless > > > > On Mon, Jan 13, 2020 at 12:45:33PM +0100, Toerless Eckert wrote: > > > This message starts a two-week adoption call, it ends on January 27th, 2020. > > > > > > draft-liu-anima-grasp-distribution was progressed up to version -13 > > > with the help of the WG, it was last presented at IETF106 with good interest. > > > The draft is now clearly in scope of ANIMA charter 2 that was > > > adopted around IETF106. The authors asked for adoption of the document. > > > As far as the chairs heard, there was no objection in the room. > > > > > > We therefore are asking the ANIMA working group for adoption of the > > following work: > > > > > > Title: Information Distribution in Autonomic Networking > > > Name: draft-liu-anima-grasp-distribution > > > Authors: B. Liu, X. Xiao, A. Hecker, S. Jiang, Z. Despotovic > > > URL: https://datatracker.ietf.org/doc/draft-liu-anima-grasp-distribution/ > > > > > > This document is intended to become a standards track ANIMA WG document. > > > > > > Standard track is desired because it is meant to become the required > > > small set of protocol extensions to the GRASP protocol in support of > > > the self-organization of ASA. > > > > > > Please express your support or rejection. If you think this document > > > should _not_ be adopted, please also explicitly indicate the reasons. > > > > > > For the ANIMA WG chairs, > > > Toerless > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 25 02:39:22 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613D3A0925; Tue, 25 Feb 2020 02:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdcgv60jv6EQ; Tue, 25 Feb 2020 02:39:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915773A07D2; Tue, 25 Feb 2020 02:39:18 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 06D20318D600BC4D0F1A; Tue, 25 Feb 2020 10:39:16 +0000 (GMT) Received: from fraeml721-chm.china.huawei.com (10.206.15.17) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Feb 2020 10:38:35 +0000 Received: from fraeml719-chm.china.huawei.com (10.206.15.15) by fraeml721-chm.china.huawei.com (10.206.15.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 25 Feb 2020 11:38:35 +0100 Received: from fraeml719-chm.china.huawei.com ([10.206.15.15]) by fraeml719-chm.china.huawei.com ([10.206.15.15]) with mapi id 15.01.1713.004; Tue, 25 Feb 2020 11:38:35 +0100 From: Xun Xiao To: Toerless Eckert , "anima@ietf.org" CC: "draft-liu-anima-grasp-distribution@ietf.org" Thread-Topic: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) Thread-Index: AQHVygcEixrclYVRzkuIMbNn6stxL6gVKlSAgBbDJdA= Date: Tue, 25 Feb 2020 10:38:34 +0000 Message-ID: <4ac62addf69847ffb730c7648143035e@huawei.com> References: <20200113114533.GA42301@faui48f.informatik.uni-erlangen.de> <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200210231233.GD31783@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.166.174] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (ends 01/27/2020) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 10:39:22 -0000 Dear Toerless, Thanks again for taking care of the adoption. As required, we have generate= d the version -00. On behalf of all the other authors, we have uploaded the version -00 to dat= atracker. For some reasons, we did not get any notification of a successful= upload. We hope we upload it correctly and you will get notified. Please also find our replies to your email inline. Thanks a lot! Best Regards, Xun Xiao (=1B$B>S?W=1B(B) Advanced Wireless Technology Lab Munich Research Center Huawei Technologies Co.,Ltd. -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Tuesday, 11 February 2020 00:13 To: anima@ietf.org Cc: draft-liu-anima-grasp-distribution@ietf.org Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-distribution (= ends 01/27/2020) We had 5 voices feedback (from non-authors) to support adoption of this doc= ument, and no voices objecting. I think this qualifies for adoption of the = document. Nevertheless, the supporting voices did indicate a range of improvements th= ey would like to see. So, jere is what i would propose: Dear-authors: A) Please add a section Open Issues, mark it as [RFC-Editor: To Be removed before becoming RFC]. Make it contain the following text: [XX] This is done by adding Appendix A in the draft version -00. The following issues where identified by the WG when adopting the -00 draft= version. These issues will be individually removed in upcoming when they a= re resolved. 1. More reference to the use cases in the introduction. 2. Better explanation of the required context of the Connected-Car case: Not applicable unless the ACP will be extended to the car, which may not be= desirable with the current ACP design, but maybe refocussing on an "autono= mous fleet" use-case (e.g.: all cars operated by some taxi like service). 3. Consider use-case/example of firmware update. By abstracting the locati= on of the firmware from the name of the firmware, while providing a way to = notify about it, this significantly supports distribution of firmware updat= es. References to SUIT would appropriate. 4. Issues discussed in https://mailarchive.ietf.org/arch/msg/anima/_0fYQPBc= LPt8xzQee7P4dILsn3A 5. Rethink/refine terminology, e.g.: "module" seems to be too prescriptive. Refine proposed extensions. 6. I support adoption, but also support the suggestion (from IETF106) Provi= de more protocol behavior description instead of only implementation / sof= tware module architecture description.=20 Reduce the latter or provide better justification for their presence due to= explained interoperability requirements. 7. Better motivation in sections 1..4 of the proposed extensions 8. Consider moving examples from appendices into core-text . Ideally craft = a single use-case showing/applying all extensions (most simple use case tha= t uses them all). 9. Refine terminology to better match/reuse-the established terminology fro= m the pre-existing ANIMA documents. B) Add changelog section, equally marked as to be removed before . For this= version -00 it should just list above section from A) to be new. [XX] This is done by adding Appendix A in the draft version -00. C) Designate in the authors list one or two main editors for the time being, doesn't have to be final, just whoever has the main edit pen from you. Post this version as -00 with name draft-ietf-anima-grasp-distribution-00 and replacing draft-liu-anima-grasp-distribution [XX] Bing Liu and me (Xun Xiao) were specified as Ed. In the author list an= d the draft name was also changed as required. I will then approve that doc as WG chair. [XX] Thanks. D) Feel free to work on -01 and further. In the changelog, please describe for each change which of the above 9 points are addressed by the change and concentrate on those changes first before addressing further enhancements. [XX] Indeed, those comments are not completely independent, some of them ma= y affect each other, so we were considering them as a whole and try to make= a systematic revision in version -01. In parallel with version -00, we alr= eady started to work on the version -01, but need more time. E) I would strongly suggest you authors consider to create a repo for this document under www.github.com/anima-wg It specifically makees it easier to open for each of the above 10 bullet points possible "Issues" where it would be easier to have focussed discusses. [XX] We tried to create a new repo there, but do we have access right to cr= eate a repository under anima-wg? I am not a github is the only way groupie though, so please make sure all discussions are Cc'ed to the mailing list, even though it may primar= ily be on github to make then easier to track/find. Cheers Toerless On Mon, Jan 13, 2020 at 12:45:33PM +0100, Toerless Eckert wrote: > This message starts a two-week adoption call, it ends on January 27th, 20= 20. >=20 > draft-liu-anima-grasp-distribution was progressed up to version -13=20 > with the help of the WG, it was last presented at IETF106 with good inter= est. > The draft is now clearly in scope of ANIMA charter 2 that was adopted=20 > around IETF106. The authors asked for adoption of the document. > As far as the chairs heard, there was no objection in the room. >=20 > We therefore are asking the ANIMA working group for adoption of the follo= wing work: >=20 > Title: Information Distribution in Autonomic Networking > Name: draft-liu-anima-grasp-distribution > Authors: B. Liu, X. Xiao, A. Hecker, S. Jiang, Z. Despotovic > URL: https://datatracker.ietf.org/doc/draft-liu-anima-grasp-distribu= tion/ >=20 > This document is intended to become a standards track ANIMA WG document. >=20 > Standard track is desired because it is meant to become the required=20 > small set of protocol extensions to the GRASP protocol in support of=20 > the self-organization of ASA. >=20 > Please express your support or rejection. If you think this document=20 > should _not_ be adopted, please also explicitly indicate the reasons. >=20 > For the ANIMA WG chairs,=20 > Toerless >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 25 02:42:40 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC423A0937; Tue, 25 Feb 2020 02:42:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <158262735587.15367.716355279808524352@ietfa.amsl.com> Date: Tue, 25 Feb 2020 02:42:35 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-distribution-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 10:42:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Information Distribution over GRASP Authors : Bing Liu Xun Xiao Artur Hecker Sheng Jiang Zoran Despotovic Filename : draft-ietf-anima-grasp-distribution-00.txt Pages : 22 Date : 2020-02-25 Abstract: This document proposes a solution for information distribution in autonomic networks. Information distribution is categorized into two different modes: 1) instantaneous distribution; 2) publication for retrieval. In the former case, the information is sent, propagates and is disposed of after reception. In the latter case, information needs to be stored in the network. The capabilities to distribute information are basic and fundamental needs for an autonomous network ([RFC7575]). This document describes typical use cases of information distribution in ANI and requirements to ANI, such that rich information distribution can be natively supported. The document proposes extensions to the autonomic nodes and suggests an implementation based on GRASP ([I-D.ietf-anima-grasp]) extensions as a protocol on the wire. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-00 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-distribution-00 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/ From nobody Wed Feb 26 12:47:24 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157193A13CE; Wed, 26 Feb 2020 12:47:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <158275003799.22951.1379929556449203703@ietfa.amsl.com> Date: Wed, 26 Feb 2020 12:47:18 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-36.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:47:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-36.txt Pages : 120 Date : 2020-02-26 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-36 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-36 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-36 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/ From nobody Wed Feb 26 14:39:42 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0AA3A09F2; Wed, 26 Feb 2020 14:39:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <158275677184.20947.17733487977839966187@ietfa.amsl.com> Date: Wed, 26 Feb 2020 14:39:31 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-37.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:39:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-37.txt Pages : 121 Date : 2020-02-26 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-37 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-37 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-37 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/ From nobody Wed Feb 26 15:02:52 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89C33A0A11 for ; Wed, 26 Feb 2020 15:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAWwn-iZ1lst for ; Wed, 26 Feb 2020 15:02:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCF33A0A15 for ; Wed, 26 Feb 2020 15:02:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BD93038983 for ; Wed, 26 Feb 2020 18:01:46 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32EE7A0 for ; Wed, 26 Feb 2020 18:02:48 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <158275677184.20947.17733487977839966187@ietfa.amsl.com> References: <158275677184.20947.17733487977839966187@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-37.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 23:02:51 -0000 --=-=-= Content-Type: text/plain I posted keyinfra-36 with updated examples, with some missing key pairs added. I then noticed that the were not the way that I wanted them, and so -37 fixes that. There is a script (examples/checkit) in the git tree that checks the relationships between pieces. You can use rfcstrip: https://github.com/mbj4668/rfcstrip or "extract-figures" from my tree to extract the examples. I have asked for some other people to review the results, and if you want detailed instructions, I can send them. The rfcdiff mechanism seems to be broken today, so try tomorrow. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5W+RcACgkQgItw+93Q 3WWZLQf+OD9nrAl07S6GccaorJgjf3ftqAeWxW6zBNJz8V5EhK/fq1T3MdGL2cP5 ffgOSdsaY5JP3h/9dim23H6un0mxVooafSCSxqHGrzNfkuOy34xhg1v+mbNXZthk 7KQGkXvLpRRXs8ixz/JpVlYOOjdJMAZw5eKkUDTJ2BPv2SqZER0/f1aUjt6yPMgo aNpeYAszecByvRnUcxFCTgm06zGFx4L82OKtYSOweEKQT41BWKNmgJ6bvcLO+4Ez p+jHYhw41zsnG53bD+ABhSZMy/PITZws3MncUQurQUCLFuc3A6UJ9SnSG4zyMDx7 gKC6VLtqs9Gv8EWxTQCGcyrWY9hc2w== =x1Mg -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 27 22:37:47 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145AF3A1147 for ; Thu, 27 Feb 2020 22:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b46jL73j7No for ; Thu, 27 Feb 2020 22:37:43 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9693A1146 for ; Thu, 27 Feb 2020 22:37:43 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6340ECAE5FA861E0AB79 for ; Fri, 28 Feb 2020 06:37:41 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 06:37:40 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 28 Feb 2020 06:37:40 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 28 Feb 2020 06:37:40 +0000 Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.69]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Fri, 28 Feb 2020 14:37:35 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: "anima@ietf.org" Thread-Topic: My comments about draft-richardson-anima-voucher-delegation-00: Thread-Index: AdXuAWluOjgkqUnQTz6LlayjkXYHRQ== Date: Fri, 28 Feb 2020 06:37:35 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.46] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B43DGGEMM531MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] My comments about draft-richardson-anima-voucher-delegation-00: X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 06:37:46 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B43DGGEMM531MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, This is an interesting draft, please see my comments as below: pg 2: o while the use of a nonceless voucher (see {{RFC8366} section 4) can permit the MASA to be offline, it still requires the public key/certificate of the Registrar to be known at issuing time comment: don't think it as one disadvantage of the BRSKI. As even for the DASA solution, the public key of the registrar are still required to be known at issuing time. At least, this sentence has not clarified the real problem clearly. pg 2: o the MASA must also approve all transfers of ownership, impacting the rights of the initial seller to transfer ownership as they see fit. comment: here, the initial seller seems not very accurate. Who is the initial seller? Actually, the term of "any re-seller/distributer" are more accurate here. pg 2: o if the Registrar has any nonceless vouchers, then it can not change it's public key, nor can it change which certification authority it uses comment: How can the DASA address this problem? pg 2: o the creator of an assembly of parts/components can speak for the entire assembly of parts in a transparent way comment: the creator means the vendor? pg 2: 1.1.1. Disconnected or Offline MASA A Registrar wishes to onboard devices while not being connected to the Internet. comment: how to achieve this goal? by pro-provisioning the related delegation vouchers to the device? pg 2: 1.1.2. Resale of devices An owner of a device wishes to resale devices which have previously been onboarded to a third party without specific authorization from the manufacturer. comment: Does the resoled devices have to be onboarded before? pg 3: assembly comment: assembly means? pg 3: The sub-components of the assembly needs to communicate with other sub-components, and so all the parts need to transparently onboarded. comment: clarification requested. pg 3: This delegation can potentially be repeated multiple times to enable second, third, or n-th level of resale. comment: So, there should be 0..n intermediate vouchers and only one end voucher= in the device. right? pg 3: The delegation voucher pins the identity of the delegated authority using a variety of different mechanisms which are covered in Section 7. comment: why do we need a variety of different mechanisms? Is one mechanism defined in this draft not enough? pg 5: Delegation Voucher: a Delegation Voucher is an [RFC8366] format voucher that has additional fields to provide detailed the entity to which authority has been delegated. comment: nit: to provide details of the entity... We need a very clear relation description among the 3 kinds of voucher: delegation voucher, intermediate voucher and end voucher. Leave it to th= e later discussion! pg 5: Intermediate Voucher: a voucher that is not the final voucher linking a pledge to its owner. comment: Does intermediate voucher equal to the delegated voucher? I think so. pg 5: End Voucher: a voucher that is the final voucher linking a pledge to its owner. comment: Does end voucher equal to the normal voucher? I think so. pg 5: There are a few new fields: pinned-delegation-certificate-authority, pinned-delegation-name, delegation-count. comment: we need the definition of this new fields, not only in the description o= f the yang model, I think. and some nits: countdown, miss delegation-voucher and intermediate-identities. pg 7: leaf pinned-certificate-authority { comment: How does the upper-layer MASA/DASA know the pinned-certificate-authority which will delegtate out? pg 7: leaf delegation-voucher { comment: a chain of delegation-vouchers on the delegation path? or a nested vouch= er structure? And the voucher is a CMS structure with signature, right? if there is delegation information, it should be in this delegation-voucher field. And for the MASA created voucher, it should no= t include the delegation-voucher, since it is the up-most entity in the supply chain and no other entity can delegate the authority to it, right= ? How about the new DASA URL? pg 8: leaf delegation-countdown { type int16; description "Number of delegations still available. If zero or omitted, then this is a terminal voucher and may not be further delegated"; comment: terminal voucher is not end voucher! It should be the initial voucher created by the MASA and does not include delegation-voucher field, right? Furthermore, it seems that the countdown field is redundant with the delegation-voucher. pg 8: comment: Who sign the end voucher? Can the intermediate voucher independently exist? pg 8: 3.3. Delegation of multiple devices A MASA MAY delegate multiple devices to the same Registrar by putting an array of items in the "serial-number" attributes. (XXX-how to describe this in the YANG) comment: What is the use case? Current BRSKI does not support this, but should? pg 8: A pledge which has previously stored a delegation voucher and delegated authority, SHOULD include it in its voucher request. This will be in the form of a certificate provided by the "previous" owner. comment: include it =3D include the delegation voucher? I still think that a delegation voucher can not really exist as an instance, it's actually an end voucher including a series of intermediat= e vouchers in itself. pg 9: A certificate from the set of intermediate-identities is expected to validate the signature on this zeroth end-entity voucher. (XXX- This attribute can be replaced by the CMS certificate chain) comment: The intermediate-identities list should have the same order with the intermediate voucher chain backwards along the delegation path to the MASA. In last sentence, it said that the zero voucher has not been signed. Her= e, how to validate its signature? Why is the regarding certificate expected to validate the zero voucher? pg 9: working set of trust anchors. comment: So, the pledge has multiple trust anchors possibly. So, the next question is how does the pledge or the registrar know which trust anchor to choose for next onboarding procedure? B.R. Frank This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, b= ut not limited to, total or partial disclosure, reproduction, or disseminat= ion) by persons other than the intended recipient(s) is prohibited. If you = receive this e-mail in error, please notify the sender by phone or email im= mediately and delete it! --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B43DGGEMM531MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

This is an interesting draft, p= lease see my comments as below:

 

pg 2:

   o  while t= he use of a nonceless voucher (see {{RFC8366} section 4)<= /p>

    &nbs= p; can permit the MASA to be offline, it still requires the public

     &nb= sp;key/certificate of the Registrar to be known at issuing time<= /span>

 

comment:

    &nbs= p; don't think it as one disadvantage of the BRSKI. As even for the DASA

    &nbs= p; solution, the public key of the registrar are still required to be<= /o:p>

    &nbs= p; known at issuing time. At least, this sentence has not clarified the

    &nbs= p; real problem clearly.

 

pg 2:

   o  the MAS= A must also approve all transfers of ownership, impacting=

    &nbs= p; the rights of the initial seller to transfer ownership as they see<= /o:p>

    &nbs= p; fit.

 

comment:

    &nbs= p; here, the initial seller seems not very accurate. Who is the initial

    &nbs= p; seller? Actually, the term of "any re-seller/distributer" are = more

    &nbs= p; accurate here.

 

pg 2:

   o  if the = Registrar has any nonceless vouchers, then it can not

    &nbs= p; change it's public key, nor can it change which certification=

    &nbs= p; authority it uses

 

comment:

    &nbs= p; How can the DASA address this problem?

 

pg 2:

   o  the cre= ator of an assembly of parts/components can speak for the=

    &nbs= p; entire assembly of parts in a transparent way

 

comment:

    &nbs= p; the creator means the vendor?

 

 

pg 2:

1.1.1.  Disconnected or= Offline MASA

 

   A Registrar wis= hes to onboard devices while not being connected to

   the Internet.

 

comment:

    &nbs= p; how to achieve this goal? by pro-provisioning the related delegation

    &nbs= p; vouchers to the device?

 

pg 2:

1.1.2.  Resale of devic= es

 

   An owner of a d= evice wishes to resale devices which have previously

   been onboarded = to a third party without specific authorization from

   the manufacture= r.

 

comment:

   Does the resole= d devices have to be onboarded before?

 

pg 3:

   assembly

 

comment:

   assembly means?=

 

pg 3:

   The sub-compone= nts of the assembly needs

   to communicate = with other sub-components, and so all the parts need

   to transparentl= y onboarded.

 

comment:  clarification= requested.

 

pg 3:

   This delegation= can potentially be repeated multiple times to enable

   second, third, = or n-th level of resale.

 

comment:

    So, there= should be 0..n intermediate vouchers and only one end voucher in the devic= e. right?

 

pg 3:

   The delegation = voucher pins the identity of the delegated authority

   using a variety= of different mechanisms which are covered in

   Section 7.=

 

comment:

   why do we need = a variety of different mechanisms?

   Is one mechanis= m defined in this draft not enough?

 

pg 5:

   Delegation Vouc= her:  a Delegation Voucher is an [RFC8366] format

    &nbs= p; voucher that has additional fields to provide detailed the entity

    &nbs= p; to which authority has been delegated.

 

comment:

   nit: to provide= details of the entity...

   We need a very = clear relation description among the 3 kinds of voucher:<= /p>

   delegation vouc= her, intermediate voucher and end voucher. Leave it to the

   later discussio= n!

 

pg 5:

   Intermediate Vo= ucher:  a voucher that is not the final voucher

    &nbs= p; linking a pledge to its owner.

 

comment:

   Does intermedia= te voucher equal to the delegated voucher? I think so.

 

pg 5:

   End Voucher:&nb= sp; a voucher that is the final voucher linking a pledge to

    &nbs= p; its owner.

 

comment:

   Does end vouche= r equal to the normal voucher? I think so.

 

 

pg 5:

   There are a few= new fields: pinned-delegation-certificate-authority,

   pinned-delegati= on-name, delegation-count.

 

comment:

   we need the def= inition of this new fields, not only in the description of the yang model, = I think.

   and some nits: = countdown, miss delegation-voucher and

   intermediate-id= entities.

 

pg 7:

   leaf pinned-cer= tificate-authority {

 

comment:

   How does the up= per-layer MASA/DASA know the pinned-certificate-authority=

   which will dele= gtate out?

 

pg 7:

   leaf delegation= -voucher {

 

comment:

   a chain of dele= gation-vouchers on the delegation path? or a nested voucher structure?=

   And the voucher= is a CMS structure with signature, right?

   if there is del= egation information, it should be in this

   delegation-vouc= her field. And for the MASA created voucher, it should not

   include the del= egation-voucher, since it is the up-most entity in the

   supply chain an= d no other entity can delegate the authority to it, right?

   How about the n= ew DASA URL?

 

pg 8:

    &nbs= p;      leaf delegation-countdown {

    &nbs= p;        type int16;<= /p>

    &nbs= p;        description<= /p>

    &nbs= p;        "Number of delegations st= ill available. If zero

    &nbs= p;         or omitted, then this is= a terminal voucher and

    &nbs= p;         may not be further deleg= ated";

 

comment:

  terminal voucher is n= ot end voucher!

  It should be the init= ial voucher created by the MASA and does not include

  delegation-voucher fi= eld, right?

  Furthermore, it seems= that the countdown field is redundant with the

  delegation-voucher.

 

pg 8:

   <CODE ENDS&g= t;

 

comment:

  Who sign the end vouc= her?

  Can the intermediate = voucher independently exist?

 

pg 8:

3.3.  Delegation of mul= tiple devices

 

   A MASA MAY dele= gate multiple devices to the same Registrar by putting

   an array of ite= ms in the "serial-number" attributes.  (XXX-how to

   describe this i= n the YANG)

 

comment:

   What is the use= case? Current BRSKI does not support this, but should?

 

pg 8:

   A pledge which = has previously stored a delegation voucher and

   delegated autho= rity, SHOULD include it in its voucher request.  This

   will be in the = form of a certificate provided by the "previous"

   owner.

 

comment:

   include it =3D = include the delegation voucher?

   I still think t= hat a delegation voucher can not really exist as an

   instance, it's = actually an end voucher including a series of intermediate

   vouchers in its= elf.

 

pg 9:

   A certificate f= rom the set of intermediate-identities is

   expected to val= idate the signature on this zeroth end-entity voucher.

   (XXX- This attr= ibute can be replaced by the CMS certificate chain)

 

comment:

   The intermediat= e-identities list should have the same order with the

   intermediate vo= ucher chain backwards along the delegation path to the

   MASA.

   In last sentenc= e, it said that the zero voucher has not been signed. Here,

   how to validate= its signature? Why is the regarding certificate expected=

   to validate the= zero voucher?

 

pg 9:

   working set of = trust anchors.

 

comment:

   So, the pledge = has multiple trust anchors possibly.

   So, the next qu= estion is how does the pledge or the registrar know which=

   trust anchor to= choose for next onboarding procedure?

 

 

B.R.

Frank

 

 

This e-mail and its attachments= contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. A= ny use of the information contained herein in any way (including, but not l= imited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or email immediately and delete it!

 

--_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B43DGGEMM531MBSchi_-- From nobody Thu Feb 27 22:40:30 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236C43A115B for ; Thu, 27 Feb 2020 22:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGHz7iy9WqAs for ; Thu, 27 Feb 2020 22:40:27 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359453A1159 for ; Thu, 27 Feb 2020 22:40:27 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 03E23704BB91C498D5D5 for ; Fri, 28 Feb 2020 06:40:25 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 06:40:24 +0000 Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.69]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Fri, 28 Feb 2020 14:40:21 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: "anima@ietf.org" Thread-Topic: My comments about draft-richardson-anima-masa-considerations-02: Thread-Index: AdXuAaZTd23akt0LRFiEvEAkZcXn1g== Date: Fri, 28 Feb 2020 06:40:20 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.46] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B58DGGEMM531MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] My comments about draft-richardson-anima-masa-considerations-02: X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 06:40:29 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B58DGGEMM531MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, This draft is useful for helping guy to get valuable guidance of deploying = BRSKI MASA service, please see my current comments as below: pg 4: One way to do the transmission is during a manufacturing during a Bed of Nails (see [BedOfNails]) or Boundary Scan. comment: Can the manufacturer internal scep or similar protocols be the other way= s? pg 4: has been started the first time. comment: Both in the manufacturing process and in-field provisioning process? pg 4: A serial number for the device can be assigned and placed into a comment: Is it appropriate to assign the serial number to device, since device ha= s already had its own SN? pg 5: Ongoing access to the root-CA is important, but not as critical as access to the MASA key. comment: MASA key is not relevant with the IDevID three-tier PKI infrastructure. So, does this sentence make sense here? pg 5: The IDevID certificates have very long (ideally infinite) validity lifetimes for reasons that [ieee802-1AR] explains, but once the certificates have been created the intermediate CA has no further obligations as neither CRLs nor OCSP are appropriate. comment: Miss some text here for clarifying how the updated intermediate CAs with new keypair can still be used to validate the old IDevID which is issued with the intermediate CA's old keypair. Can the updated intermediate CA still store and use the old keypair? And why do you say that the intermediate CA has no further obligations f= or its status update once the IDevIDs have been created? pg 6: A plan to escrow the signing keys SHOULD be detailed, and it is likely that customers will want to review it for high-value products. comment: what is the "escrow the signing keys"? pg 7: In order to avoid locking down a single validation key, a PKI infrastruc= ture is appropriate. comment: A PKI infrastructure for MASA? pg 7: a new End-Entity (EE) Certificate with an online private key, and use that to sign voucher requests. The entity used to sign [RFC8366] format vouchers does not need to be a certificate authority. comment: Why is it the EE Certificate? B.R. Frank This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, b= ut not limited to, total or partial disclosure, reproduction, or disseminat= ion) by persons other than the intended recipient(s) is prohibited. If you = receive this e-mail in error, please notify the sender by phone or email im= mediately and delete it! --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B58DGGEMM531MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

This draft is useful for helpin= g guy to get valuable guidance of deploying BRSKI MASA service, please see = my current comments as below:

 

pg 4:

   One way to do t= he transmission is during a manufacturing during a Bed

   of Nails (see [= BedOfNails]) or Boundary Scan.

 

comment:

   Can the manufac= turer internal scep or similar protocols be the other ways?

 

pg 4:

   has been starte= d the first time.

 

comment:

   Both in the man= ufacturing process and in-field provisioning process?

 

pg 4:

   A serial number= for the device can be assigned and placed into a

 

comment:

   Is it appropria= te to assign the serial number to device, since device has

   already had its= own SN?

 

pg 5:

   Ongoing access = to the root-CA is important, but not as critical as

   access to the M= ASA key.

 

comment:

   MASA key is not= relevant with the IDevID three-tier PKI

   infrastructure.= So, does this sentence make sense here?

 

pg 5:

   The IDevID cert= ificates have very long (ideally infinite)

   validity lifeti= mes for reasons that [ieee802-1AR] explains, but once

   the certificate= s have been created the intermediate CA has no further

   obligations as = neither CRLs nor OCSP are appropriate.

 

comment:

   Miss some text = here for clarifying how the updated intermediate CAs with=

   new keypair can= still be used to validate the old IDevID which is issued=

   with the interm= ediate CA's old keypair. Can the updated intermediate CA<= /p>

   still store and= use the old keypair?

   And why do you = say that the intermediate CA has no further obligations for

   its status upda= te once the IDevIDs have been created?

 

pg 6:

   A plan to escro= w the signing keys SHOULD be detailed, and it is

   likely that cus= tomers will want to review it for high-value products.

 

comment:

   what is the &qu= ot;escrow the signing keys"?

 

pg 7:

   In order to avo= id locking down a single validation key, a PKI infrastructure is=

   appropriate.

 

comment:

   A PKI infrastru= cture for MASA?

 

pg 7:

   a new End-Entit= y (EE) Certificate with an online

   private key, an= d use that to sign voucher requests. The entity used

   to sign [RFC836= 6] format vouchers does not need to be a certificate

   authority.=

 

comment:

   Why is it the E= E Certificate?

 

 

B.R.

Frank

 

This e-mail and its attachments= contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. A= ny use of the information contained herein in any way (including, but not l= imited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or email immediately and delete it!

 

--_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B58DGGEMM531MBSchi_-- From nobody Thu Feb 27 22:42:20 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42903A1165 for ; Thu, 27 Feb 2020 22:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDlpwJfNYlZI for ; Thu, 27 Feb 2020 22:42:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071273A1163 for ; Thu, 27 Feb 2020 22:42:16 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ACE3F71221F5EB33E5EC for ; Fri, 28 Feb 2020 06:42:14 +0000 (GMT) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 06:42:13 +0000 Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 28 Feb 2020 06:42:14 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 28 Feb 2020 06:42:13 +0000 Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.69]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Fri, 28 Feb 2020 14:42:08 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: "anima@ietf.org" Thread-Topic: My comments about draft-richardson-anima-registrar-considerations-02: Thread-Index: AdXuAghu59oxbKLhQCWlmRxOrngQHQ== Date: Fri, 28 Feb 2020 06:42:07 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.46] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B67DGGEMM531MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] My comments about draft-richardson-anima-registrar-considerations-02: X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 06:42:18 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B67DGGEMM531MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNClRoaXMgZHJhZnQgaXMgdXNlZnVsIGZvciBoZWxwaW5nIGd1eSB0byBnZXQg dmFsdWFibGUgZ3VpZGFuY2Ugb2YgZGVwbG95aW5nIEJSU0tJIFJlZ2lzdHJhciBlbnRpdHksIHBs ZWFzZSBzZWUgbXkgY3VycmVudCBjb21tZW50cyBhcyBiZWxvdzoNCg0KU2ltaWxhcmlseSB0byB0 aGUgb3RoZXIgZG9jdW1lbnQsIGxldCBtZSBwdXQgeW91ciBjb21tZW50cyBpbnRvIGFuIGVtYWls Lg0KDQpBZ2FpbiwgbWFueSBib3hlcyB3ZXJlIGVtcHR5LCBzbyBJIGRvbid0IGtub3cgaWYgSSBt aXNzZWQgc29tZSB0aG91Z2h0cy4NCg0KDQoNCnBnIDY6DQoNCiAgIHdpdGggQ29BUC9FREhPQywg dGhlbiBhDQoNCiAgIHBsYWluIENvQVAgaW50ZXJmYWNlIGlzIHVzZWQsIGFuZCB0aGUgc2VjdXJp dHkgKEVESE9DIGFuZCBPU0NPUkUpDQoNCiAgIGxpdmVzIGFib3ZlIENvQVAuIEZvciBDb0FQL0RU TFMgKENvQVBTKSB0aGVuIHRoZXJlIGlzIERUTFMgbGF5ZXINCg0KICAgYmVsb3cgdGhlIENvQVAg bGF5ZXIuDQoNCg0KDQpjb21tZW50Og0KDQogICBUaGUgZmlyc3Qgc2VudGVuY2UgY2FuIGNvdmVy IHRoZSBsYXN0IHNlbnRlbmNlLg0KDQoNCg0KcGcgNjoNCg0KICAgVGhlIFBsZWRnZSBJbnRlZmFj ZSBkb2VzIG5vdCByZXF1aXJlIGEgcHVibGljIElQIGFkZHJlc3MsIG5vciBkb2VzIGl0DQoNCiAg IGhhdmUgaGF2ZSB0byBydW4gb24gcG9ydCA0NDMuDQoNCg0KDQpjb21tZW50Og0KDQogICB1c2Ug aXRzIGxpbmstbG9jYWwgaXB2NiBhZGRyZXNzo79ob3cgYWJvdXQgcG9ydD8NCg0KDQoNCnBnIDY6 DQoNCiAgIE91dHNpZGUgb2YgdGhlIEFDUCBjb250ZXh0LCBydW5uaW5nIHRoZSBQbGVkZ2UgaW50 ZXJmYWNlIG9uIGFuIElQDQoNCiAgIGFkZHJlc3MgdGhhdCBoYXMgYSBGUUROIHRoYXQgcmVzb2x2 ZXMgdG8gdGhhdCBJUCBhZGRyZXNzIChpZiBvbmx5DQoNCiAgIGludGVybmFsbHkpLCBhbmQgb3Bl cmF0aW5nIGl0IG9uIHBvcnQgNDQzIG1heSBoYXZlIG9wZXJhdGlvbmFsDQoNCiAgIGFkdmFudGFn ZXMuDQoNCg0KDQpjb21tZW50Og0KDQogICB0aGlzIHBhcmFncmFwaCBpcyBjb25mdXNpbmcsIHBs ZWFzZSByZXdvcmQNCg0KDQoNCnBnIDc6DQoNCiAgIGlmIHRoZSBSZWdpc3RyYXIgd2lsbCBhbHNv IGJlIHByb3ZpZGluZyBmb3INCg0KICAgcmVuZXdhbCBvZiBjZXJ0aWZpY2F0ZXMgdXNpbmcgRVNU LCB0aGVuIGl0IFNIT1VMRCBhbm5vdW5jZSBpdHNlbGYNCg0KICAgaW5zaWRlIHRoZSBBQ1AgdXNp bmcgR1JBU1AuIFVubGVzcyBtYWRlIGltcG9zc2libGUgZHVlIHRvIGxvYWRpbmcNCg0KICAgY29u Y2VybnMsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYWxsIFJlZ2lzdHJhciBpbnN0YW5jZXMgb2Zm ZXINCg0KICAgY2VydGlmaWNhdGUgcmVuZXdhbCBzZXJ2aWNlcyBpbiB0aGlzIGZhc2hpb24uDQoN Cg0KDQpjb21tZW50Og0KDQogICBhbm5vdW5jZSBpdHNlbGYgYXMgdGhlIEVTVCBzZXJ2ZXI/DQoN Cg0KDQpwZyAxMDoNCg0KICAgSW5jaWRlbnRhbCBrZXlzIGZvciBpbnRlcm5hbCBvcGVyYXRpb25z LA0KDQogICBhbmQgZm9yIHRoZSBCUlNLSS1FU1Qgc2VydmVyIGNlcnRpZmljYXRlIGNhbiBiZSBk b25lIHdpdGggdGhpcyBzaW5nbGUNCg0KICAgaW50ZXJtZWRpYXRlIENBLg0KDQoNCg0KY29tbWVu dDoNCg0KICAgPyAtIEkgZ3Vlc3MgdGhlIHF1ZXN0aW9uIGlzLCB3aGF0IGFyZSAiaW5jaWRlbnRh bCBrZXlzIg0KDQoNCg0KcGcgMTI6DQoNCiAgIFRoZSBwcmVzZW50YXRpb24gdGllcg0KDQogICBN VVNUIGFjY2VwdCBhbGwgQ2xpZW50IENlcnRpZmljYXRlcywgbWFueSBvZiB3aGljaCBtaWdodCBp dCBtaWdodCBub3QNCg0KICAgaGF2ZSBhbmNob3JzIGZvci4NCg0KDQoNCmNvbW1lbnQ6DQoNCiAg ID8gLSBJIGd1ZXNzIHRoYXQgbW9yZSBleHBsYW5hdGlvbiBpcyByZXF1aXJlZC4NCg0KDQoNCnBn IDEzOg0KDQogICBJbiBhZGRpdGlvbiB0byBob3N0aW5nIGEgUEtJIHJvb3QsIHRoZSBSZWdpc3Ry YXIgbmVlZHMgc2V2ZXJhbCBvdGhlcg0KDQogICBrZXkgcGFpcnMuIFRoZXkgYXJlOg0KDQoNCg0K Y29tbWVudDoNCg0KICAgSXQncyBub3QgY2xlYXIgYWJvdXQgd2hhdCBpcyB0aGUgUEtJIHJvb3Qg Zm9yPyBmb3IgTUFTQT8NCg0KDQoNCnBnIDE1Og0KDQogICBUaGUgY2VydGlmaWNhdGUgdXNlZCB0 byBzaWduIHRoZSB2b3VjaGVyLXJlcXVlc3QgTVVTVCBiZSB0aGUgc2FtZSBhcw0KDQogICB0aGUg b25lIHRoYXQgaXMgdXNlZCBmb3IgdGhlIFRMUyBTZXJ2ZXIgQ29ubmVjdGlvbi4gVGhpcyBpbXBs aWVzDQoNCiAgIHRoYXQgdGhlIHNpZ25lZCB2b3VjaGVyLXJlcXVlc3QgTVVTVCBiZSBjb25zdHJ1 Y3RlZCBvbiB0aGUgc2FtZQ0KDQogICBtYWNoaW5lIHRoYXQgdGVybWluYXRlcyB0aGUgQlJTS0kt RVNUIE1BU0EgY29ubmVjdGlvbi4NCg0KDQoNCmNvbW1lbnQ6DQoNCiAgIE5JVDogQlJTS0ktRVNU IE1BU0EgY29ubmVjdGlvbj8NCg0KDQoNCkIuUi4NCkZyYW5rDQoNCg0KDQpUaGlzIGUtbWFpbCBh bmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20g SFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3 aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0 bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWlu YXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlz IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0 ZSBpdCENCg0K --_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B67DGGEMM531MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Michael,

This draft is useful for helpin= g guy to get valuable guidance of deploying BRSKI Registrar entity, please = see my current comments as below:

Similarily to the other docu= ment, let me put your comments into an email.

Again, many boxes were empty= , so I don't know if I missed some thoughts.

 

pg 6:

   with CoAP/EDHOC= , then a

   plain CoAP inte= rface is used, and the security (EDHOC and OSCORE)

   lives above CoA= P. For CoAP/DTLS (CoAPS) then there is DTLS layer

   below the CoAP = layer.

 

comment:

   The first sente= nce can cover the last sentence.

 

pg 6:

   The Pledge Inte= face does not require a public IP address, nor does it

   have have to ru= n on port 443.

 

comment:

   use its link-lo= cal ipv6 address=A3=BFhow about port?

 

pg 6:

   Outside of the = ACP context, running the Pledge interface on an IP

   address that ha= s a FQDN that resolves to that IP address (if only

   internally), an= d operating it on port 443 may have operational

   advantages.

 

comment:

   this paragraph = is confusing, please reword

 

pg 7:

   if the Registra= r will also be providing for

   renewal of cert= ificates using EST, then it SHOULD announce itself

   inside the ACP = using GRASP. Unless made impossible due to loading

   concerns, it is= RECOMMENDED that all Registrar instances offer

   certificate ren= ewal services in this fashion.

 

comment:

   announce itself= as the EST server?

 

pg 10:

   Incidental keys= for internal operations,

   and for the BRS= KI-EST server certificate can be done with this single

   intermediate CA= .

 

comment:

   ? - I guess the= question is, what are "incidental keys"

 

pg 12:

   The presentatio= n tier

   MUST accept all= Client Certificates, many of which might it might not

   have anchors fo= r.

 

comment:

   ? - I guess tha= t more explanation is required.

 

pg 13:

   In addition to = hosting a PKI root, the Registrar needs several other

   key pairs. They= are:

 

comment:

   It's not clear = about what is the PKI root for? for MASA?

 

pg 15:

   The certificate= used to sign the voucher-request MUST be the same as

   the one that is= used for the TLS Server Connection. This implies

   that the signed= voucher-request MUST be constructed on the same

   machine that te= rminates the BRSKI-EST MASA connection.

 

comment:

   NIT: BRSKI-EST = MASA connection?

 

 

 

B.R.

Frank

 

 

 

This e-mail and its attachments= contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. A= ny use of the information contained herein in any way (including, but not l= imited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or email immediately and delete it!

 

--_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B67DGGEMM531MBSchi_-- From nobody Fri Feb 28 14:40:07 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54E3A1FD9; Fri, 28 Feb 2020 14:35:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292932862.19931.1570916450838144159@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:28 -0800 Archived-At: Subject: [Anima] anima - Requested sessions have been scheduled for IETF 107 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:36 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (1:30 requested) Monday, 23 March 2020, Afternoon Session II 1550-1750 Room Name: Regency E size: 150 --------------------------------------------- anima Session 2 (1:00 requested) Thursday, 26 March 2020, Afternoon Session III 1740-1840 Room Name: Regency D size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/anima.ics Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: bier pim mboned 6man 6lo 6tisch ace Technology Overlap: emu netconf homenet roll Key Participant Conflict: nmrg panrg dinrg opsarea intarea saag cfrg detnet People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: Please avoid meeting on friday due to travel constraints of chair. It would be nice to have the 1.5 hour meeting first. ---------------------------------------------------------