[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 17 October 2019 14:08 UTC
Return-Path: <noreply@ietf.org>
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 CDC0B12000F; Thu, 17 Oct 2019 07:08:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.106.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com>
Date: Thu, 17 Oct 2019 07:08:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/C53ycr9AW6TFvxeSKKyG_Gtsft4>
Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 14:08:50 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: 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 time and attention to detail put into addressing my previous Discuss and Comment points. I have one new Discuss-level point and one that I think may have been missed (probably because I inadvertently numbered two points with the same number). (16) The audit log response (Section 5.8.1) describes the nonce as a JSON string, but the RFC 8366 nonce is a binary value. I think we need to describe some mapping procedure (such as always base64-encoding as is done for domainID, even if the original nonce is itself base64-encoded random data) in order to be fully functional. % (1) The text of the document suffers from lack of clarity throughout about % whether the nonce-ful operation is mandatory or not, with several % figures and discussions making declarative statements about nonce usage % and others saying that nonce usage is optional. (See COMMENT.) [keep in mind when reading] % (5.1) the new /enrollstatus EST endpoint seems under-specified. Shame on me, I reused (5) for two points and have renumbered this to (5.1) so we don't miss it again. We don't anywhere give a formal description of the contents of the POST body; there's just an example JSON object. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [All new comments for the -28] Please respond to the secdir re-review. Abstract nit: hyphenate "manufacturer-installed" or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for nit: maybe "deployment models with less-stringent security requirements"? Section 1 [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default. Other users of the BRSKI protocol will need to provide nit: missing "requirement" between manufacturer and owner: in it's default modes it provides a cryptographic transfer of control to the initial owner. In it's strongest modes, it leverages sales channel information to identify nit: s/it's/its/ Section 1.2 domainID: The domain IDentity is a unique hash based upon the Registrar CA's certificate. Section 5.8.2 specifies how it is calculated. nit: the grammar here is weird; I'd suggest s/hash based upon/value derived from/ MASA Audit-Log: A list of previous owners maintained by the MASA on a per device (per pledge) basis. Described in Section 5.8.1. nit: maybe "anonymized list" since the MASA doesn't really track owners directly? Ownership Tracker: An Ownership Tracker service on the global Internet. The Ownership Tracker uses business processes to accurately track ownership of all devices shipped against domains that have purchased them. Although optional, this component allows vendors to provide additional value in cases where their sales and distribution channels allow for accurately tracking of such ownership. Ownership tracking information is indicated in nit: either "accurate tracking of" or "accurately tracking" ANI: The Autonomic Network Infrastructure as defined by [I-D.ietf-anima-reference-model]. This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. Maybe refer to section 9 specifically? Section 2.3.1 The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]. IDevID certificates for use with this protocol nit: s/fields/field/ Section 2.5.1 The pledge is the device that is attempting to join. The pledge can talk to the Join Proxy using link-local network connectivity. In most cases, the pledge has no other connectivity until the pledge completes the enrollment process and receives some kind of network credential. I'd consider s/can talk to/is assumed to talk to/. Section 2.5.3 The registrar uses an Implicit Trust Anchor database for authenticating the BRSKI-MASA TLS connection MASA certificate. The registrar uses a different Implicit Trust Anchor database for authenticating the BRSKI-EST TLS connection pledge client certificate. Configuration or distribution of these trust anchor databases is out-of-scope of this specification. Configuration or distribution of this trust anchor databases is out- of-scope of this specification. Note that the trust anchors in/ excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. We seem to duplicate the "out-of-scope" text at the end/start of the two paragraphs (and the second paragraph uses the definite article "the" as if it was only talking about one of the two trust anchor databases). 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 ir processes. nits: s/ir/it/, and s/in// from "in which it has confidence in" (your choice which one). Section 2.6.2 year certificate lifetimes. Registrars SHOULD be configurable on a per-manufacturer basis to ignore pledge lifetimes when they did not follow the RFC5280 recommendations. nit: we want "they" to be the manufacturer, not the registrar, so we can't use this pronoun. Section 2.7 be more important in the future. In the ANIMA ACP scope, new devices will be quarantined behind a Join Proxy. I can't decide whether the reader would benefit from being hit with a hammer of "and as such will only have link-local connectivity, to the Join Proxy". The use of "quarantined" makes me lean towards "not"... Section 3 In my previous comment, I said: % The "proximity-registrar-cert" leaf is used in the pledge voucher- % requests. This provides a method for the pledge to assert the % registrar's proximity. % % "proximity" in what sense? How much verification/confidence needs to be % done? (Also, I would have expected the assertion to go the other way; % that the registrar asserts the pledge's proximity -- how does the pledge % have a way to know that the registrar is nearby when the proxy is % transparent?) We talked about this some, but I think we're still making an unstated assumption that there is a link-local or pre-ACP connection involved. Making that an explicit assumption would be helpful. Section 3.3 Example (2) The following example illustrates a registrar voucher- request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example). The pledge's voucher-request is a binary CMS signed object. In the JSON encoding used here it must be base64 encoded. The nonce and assertion MAY be carried forward from the pledge request to the registrar request. The serial-number is extracted from the pledge's Client Certificate from the TLS connection. See Section 5.5. Since this is an example, the "MAY be carried forward" feels out of place -- while it's true in the general case, this is not the place to say it; we can just describe what the example does, here. Also, we should probably give a reference for base64 (not necessarily here), such as Section 4 of RFC 4648. Section 4 This section applies is normative for uses with an ANIMA ACP. The nit: pick one of "applies to" or "is normative for". use of GRASP mechanism part of the ACP. Other users of BRSKI will nit: missing "is" Section 4 Registrar itself. In this scenario the pledge is unaware that there is no proxing occurring. This is useful for Registrars which are nit: s/proxing/proxying/ Section 4.3 The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds. The frequency of sending MUST be such nits: "default period" (or similar); s/be not/NOT be/ Section 5 While EST section 3.2 does not insist upon use of HTTP persistent connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use nit: comma after parenthetical, not before. Section 5.1 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. How painful would it be to require 1.3 at this point? RFC 8446 has been out for more than a year, and the TLS WG is leaning on me to tighten up on this... IDevID certificate is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. I can't tell if we want to bring the division into two distinct trust anchor databases into this discussion as well. A self-signed certificate for the Registrar is acceptable as the voucher will validate it. nit: "will" applies only when everything works, so maybe "can" or "will validate it in the case of successful enrollment". A pledge that can connect to multiple registries concurrently SHOULD nit: s/registries/Regitstrars/ Section 5.3 on the authenticated identity presented. For different networks, examples of Automated acceptance may include: nit: s/A/a/ Section 5.4 Section 2.8. The mechanisms in [RFC6125] SHOULD be used authentication of the MASA. Some vendors will establish explicit (or nit: s/used/used for/ Also, we tend to require that people using 6125 specify what name type in the cert to verify (e.g., DNS-ID) against what expected name. It would be pretty easy to convince me that we don't need to do that here, though. Section 5.4 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. As above, how painful would requiring 1.3 be? client certificate. Registrars SHOULD also permit an HTTP Basic and Digest authentication to be configured. nit: s/an// Section 5.4.1 be uniquely identified. This can be done by any stateless method that HTTPS supports: such as with HTTP Basic or Digest authentication nit: this colon is not appropriate usage. Stateful methods involving API tokens, or HTTP Cookies are not recommended. nit: zero commas or two, around "or HTTP Cookies", but one is right out. This document does not make a specific recommendation as there is likely different tradeoffs in different environments and product nit: s/is/are/ Section 5.5 idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure a uniqueness of the serial-number. In the case of nonceless (offline) voucher-request, then an appropriate value needs to be configured from the same out-of-band source as the serial-number. nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you don't take that, the "a" is superfluous in the current formulation). prior-signed-voucher-request: The signed pledge voucher-request SHOULD be included in the registrar voucher-request. The entire CMS signed structure is to be included, base64 encoded for transport in the JSON structure. I think we need a ref for (which) base64. The MASA verifies that the registrar voucher-request is internally consistent but does not necessarily authenticate the registrar certificate since the registrar MAY not be known to the MASA in advance. The MASA performs the actions and validation checks I suggest s/MAY not be known/MAY be unknown/. Section 5.5.2 The registrar's certificate chain is extracted from the signature method. The entire registrar certificate chain was included in the CMS structure, as specified in Section 5.5. This CA certificate will be used to populate the "pinned-domain-cert" of the voucher being issued. By saying "this CA certificate", are we excluding use cases where the pinned-domain-cert is not the global root CA of the organization (or is the implication just that you don't send the rest of the chain)? Section 5.5.5 voucher-request MUST include a 'proximity-registrar-cert' that is consistent with to the certificate used to sign the registrar nit: s/to// (first one) Section 5.5.6 The MASA populates the audit-log with the nonce that was verified. If a nonceless voucher is issued, then the audit-log is to be populated with the JSON value "null". The quotes around "null" are perhaps anti-helpful. Section 5.6.1 The pledge MUST verify that the voucher nonce field is accurate and matches the nonce the pledge submitted to this registrar, or that the voucher is nonceless (see Section 7.2). In my previous Discuss position I had asked: % Is the pledge supposed to accept a nonceless voucher in response to a % nonce-ful voucher request? and we had some discussion that helped clarify the intent. I just have a suggested rewording, that I *think* is entirely editorial and might reduce the potential for confusion: NEW The pledge MUST verify the nonce information in the voucher. If present, the nonce in the voucher must match the nonce the pledge submitted to the registrar; vouchers with no nonce can also be accepted (according to local policy). 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""". The version, and status fields MUST be present. The Reason field SHOULD be present whenever the status field is negative. The Reason- Context field is optional. nit: no comma after "version". nit: s/negative/false/ The keys to this JSON hash are case-insensitive. Figure 15 shows an example JSON. This (case-insensitivity) seems to be a drastic divergence from the RFC 8259 standard behavior and as such would require some justification. nit: s/hash/object/ Section 5.8.1 It's hard to call Figure 17 an "example" when it doesn't conform to the CDDL schema... The domainID is a binary value calculated SubjectKeyIdentifier according to Section 5.8.2. It is encoded once in base64 in order to be transported in this JSON container. nit: I suggest "binary SubjectKeyIdentifier value calculated" Section 5.8.2 used as the domainID. If not, then it is the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs nit: drop "is to be used" or "then it is". Section 5.8.3 A relatively simple policy is to white list known (internal or external) domainIDs. To require all vouchers to have a nonce. nit: sentence fragment. Alternatively to require that all nonceless vouchers be from a subset nit: comma after "alternatively". (Hmm, this is also a sentence fragment.) Section 5.9.4 In order to communicate this indicator, the client HTTP POSTs the following to the server at the new EST endpoint at "/.well-known/est/ enrollstatus". "The following" is just more text, not a formal description of a protocol element. "reason-context": "Additional information" Is this supposed to be a string or a JSON object similar to /voucher_status? Section 6 When used within BRSKI, the original RFC7030 EST endpoints remain Base64 encoded, but the new BRSKI end points which send and receive binary artifacts (specifically, /requestvoucher) are binary. That The other two occurrences spell this "/.well-known/est/requestvoucher". Section 7.2 The following are a list of alternatives behaviours that the pledge can be programmed to implement. These behaviours are not mutually exclusive, nor are they dependant upon other. Some of these methods nits: singular/plural mismatch "are"/"list"; "upon each other" Section 7.3 A registrar can choose to accept devices using less secure methods. These methods are acceptable when low security models are needed, as the security decisions are being made by the local administrator, but they MUST NOT be the default behavior: I'm having a hard time parsing "low security models"; the best I can come up with is "threat models where low security is adequate". Section 7.4.1 A MASA has the option of not including a nonce is in the voucher, nit: s/is// and/or not requiring one to be present in the voucher-request. This results in distribution of a voucher that never expires and in effect "expires-on" is distinct from the nonce-ful freshness check, so I think some additional wordsmithing is in order. This is useful to support use cases where registrars might not be online during actual device deployment. nit: there's enough intervening text that we should probably replace "this is" with "nonceless vouchers are". authorized to provide this functionality to this customer. The MASA is RECOMMENDED to use this functionality only in concert with an enhanced level of ownership tracking (out-of-scope.) I suggest s/out-of-scope/the details of which are out of scope for this document/. Section 7.4.2 functionality. This provides a proof-of-proximity check that reduces the need for ownership verification. I suggest reiterating the assumption that pledge and JP are on a link-local connection; whether or not to reiterate that JP and registrar have a trust relationship (with respect to not falsifying proximity information) is less clear to me. Section 7.4.3 We might benefit from some introductory text here to suggest that updating/extending trust anchors would be desirable in the case of a vanished or uncooperative manufacturer. This weaker factor reset might leave valuable credentials on the device and this may be unacceptable to some owners. nit: s/factor/factory/ Section 9 Provider organizations. Equivalent enterprises that has significant layer-3 router connectivity also will find significant benefit, nit: s/has/have/ In the ACP, the Join Proxy is found to be proximal because communication between the pledge and the join proxy is exclusively on nit(?) My dictionary doesn't list anything for "proximal" that is a good match for "with proximity"; might be worth double-checking. asssertion is satisfied. Other uses of BRSKI will need make similar analysis if they use proximity. nit: maybe "proximity information" or "proximity assertions". Section 10.3 While the contents of the signed part of the pledge voucher request can not be changed, they are not encrypted at the registrar. The ability to audit the messages by the owner of the network a mechanism to defend against exfiltration of data by a nefarious pledge. Both nit: missing verb ("is a mechanism", "provides a mechanism", etc.) The manufacturer knows the IP address of the Registrar, but it can not see the IP address of the device itself. The manufacturer can not track the device to a detailed physical or network location, only to the the location of the Registrar itself. That is likely to be at nit: we probably don't need the last "itself". is likely on the same network as the device. A manufacturer that sells switching/routing products to enterprises should hardly be surprised if additional purchases switching/routing products are purchased. Deviations from a historical trend or an establish nit: we probably only need one of "purchases" and "purchased". Section 10.6 Section Section 7.4.3 describes some ways in which a manufacturer nit: duplicate "Section". 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/ 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/ 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. Section 11.5 This next section examines the risk due to a compromised MASA key. This is followed by examination of the risk of a compromised manufacturer IDevID signing key. The third section sections below nit: I think these appear in the other order. Section 13.1 [cabforumaudit] and [dnssecroot] probably would be fine as just informative references. Appendix D.2 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?
- [Anima] Benjamin Kaduk's Discuss on draft-ietf-an… Benjamin Kaduk via Datatracker
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Eliot Lear
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Eliot Lear
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Eliot Lear