[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 11 July 2019 05:30 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 438B9120018; Wed, 10 Jul 2019 22:30:13 -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.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 22:30:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/oR0POVwZ24EZEVD3S4XCXdNmtSE>
Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (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, 11 Jul 2019 05:30:13 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: 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: ---------------------------------------------------------------------- (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.) (2) There also seems to be internal inconsistency about the proximity assertion process (and, any sort of assertion in a voucher-request at all, it seems). I've tried to note some locations in the Comment section. (3) There are other internal inconsistencies as well, including about section references for when various behaviors occur (see COMMENT). (4) In 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). Is the pledge supposed to accept a nonceless voucher in response to a nonce-ful voucher request? (5) RFC7951 is cited for the audit log response, but I cannot find the underlying YANG module that is JSON-encoded using the RFC 7951 procedures. Furthermore, I don't think the "nonce" handling (with explicit "NULL" string where base64-encoded binary data might be expected) would be consistent with the 7951 rules. (5) the new /enrollstatus EST endpoint seems under-specified. (6) In Section 7.2: The pledge can choose to accept vouchers using less secure methods. These methods enable offline and emergency (touch based) deployment use cases: 1. The pledge MUST accept nonceless vouchers. This allows for a use It's very unclear to me what this "MUST" means, especially so given that the entire section 7 is declared to be non-normative. Is it that the client "can choose" whether it "MUST accept nonceless vouchers"? That would seem to make the MUST basically ineffective. More broadly, if the entire Section 6 is non-normative, why is there any normative language in it? (7) the new /enrollstatus and /voucher_status well-known EST endpoints are not registered in Section 8.1 (7.1) I think we also need to register the "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. (8) The versioning mechanism for Pledge BRSKI Status Telemetry is underspecified, including the interaction with new registered values. (9) The versioning mechainsm for the MASA audit log response is underspecified, including whether a registry of field names is appropriate. (10) The term PKIX seems to be incorrectly used a few times; it refers to the Internet PKI, and so things like a private PKI internal to a manufacturer would probably not be best described as such. Such private PKIs can of course still reuse the protocols and mechanisms developed for PKIX, and it's accurate to describe them as such. (11) In a few places we describe the voucher-request in terms of its YANG structure but do not say that it has to be wrapped in a signed CMS object as is done for the RFC 8366 voucher. (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the domainID calculation? (13) In Section 5.5.1: As described in [RFC8366] vouchers are normally short lived to avoid revocation issues. If the request is for a previous (expired) voucher using the same registrar then the request for a renewed voucher SHOULD be automatically authorized. The MASA has sufficient I don't understand what "for a previous (expired) voucher" means. Is it something like "containing the same content as a previous voucher request for which a voucher was issued", with the presumption that the voucher expired before the pledge could successfully imprint, so it needs to try again? Or does this extend to longer timescales, like a device that gets deployed for a couple years and is then reset to factory settings and has to rebootstrap but is still by the same registrar? (14) In Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, the response data from the MASA MUST be a plaintext human- readable (ASCII, English) error message containing explanatory information describing why the request was rejected. It seems hard to support this stance on internationalization in 2019. (15) In Section 5.9.4: To indicate successful enrollment the client SHOULD re-negotiate the EST TLS session using the newly obtained credentials. This occurs by the client initiating a new TLS ClientHello message on the existing TLS connection. The client MAY simply close the old TLS session and start a new one. The server MUST support either model. Is this supposed to be sending a new TLS ClientHello in the application data channel or as a new handshake message (aka "renegotiation")? The latter is not possible in TLS 1.3 and is generally disrecommended anyways even in TLS 1.2. I would strongly suggest to remove the "renegotiation" option and just leave "close the connection and start a new connection/handshake". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [disclaimer: some of these comments get pretty blunt at the end; it's a long document and I'm tired. Please try not to get too annoyed if I'm failing to see something that's right in front of me.] I concur with the directorate reviewers that expected a high-level security analysis of what information flows where, and what policy choices can be made that affect it. At a *very* high level (skipping over a lot of things that I would expect to see), this would be structured like: On initial bootstrap, a new device uses local service autodiscovery to locate a (proxy to a) local registrar. Having found a candidate registrar, the fledgling pledge sends a fair bit of information about itself to the registrar, including its serial number and device identity (IDevID) along with a voucher request. The registrar can determine whether it expected such a device to appear, and locate a MASA, probably from an extension in the IDevID. Having determined that the MASA is suitable, the entire information from the initial voucher request (including device serial number) is transmitted over the internet in a TLS protected channel to the manufacturer, along with information about the registrar/owner. The manufacturer can then apply policy based onthe provided information and other sources of information, deciding whether to approve the claim by the registrar to own the device; if the claim is accepted, a voucher is issued that directs the device to accept its new owner. The voucher is returned to the registrar, but not necessarily to the device -- the registrar has an opportunity to examine the voucher, the MASA's audit logs, and other sources of information to determine whether the device has been tampered with, whether the bootstrap should be accepted, etc. No filtering of information is possible in the signed voucher, so this is a binary accept-or-not decision. If the registrar accepts the voucher as a proper one for its device, the voucher is returned to the pledge for imprinting. The voucher also includes a trust anchor that the pledge should use as representing the owner, successfully bootstrapping from an environment where only the manufacturer has some (limited) level of trust by the device into an environment where an owner has a PKI footprint on the device. When BRSKI is followed with EST this single footprint is further leveraged into the full owner's PKI and a LDevID for the device. Subsequent reporting steps provide flows of information to indicate success/failure of the process. I also concur with the directorate reviewer that wanted to see more discussion about the tradeoff in the applicability statement between manufacturer control and ease/automation of bootstrap Abstract (side note?) Is there a quick explanation of why bootstrapping can complete with just installation of the PKI (trust anchor?) and provisioning a locally issued certificate is not mandatory? Section 1 This document describes how pledges discover (or be discovered by) an element of the network domain to which the pledge belongs to perform the bootstrap. [...] nit: s/be/are/, IIUC. I think there's also something funky with the wording of "to perform the bootstrap"; we may be looking for an element "that will perform the bootstrap". 4. Pledge authorizing the registrar: "Should I join it?" nit: what is "it"? Surely not the registrar, and presumably the "network domain" in question? This document details protocols and messages to answer the above questions. It uses a TLS connection and an PKIX (X.509v3) certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer points 1 and 2. It uses a new artifact called a "voucher" that the I'm kind of confused by "[IDevID] LDevID", since my understanding was that the LDevID is issued only after all four steps are complete. Also, following the IDevID link lands me at a page that claims to be for a standard of status "superseded". nit: one can use X.509v3 without being PKIX, and it's not entirely clear that the IDevIDs will chain up to the Internet PKI. Section 1.2 RFC 8174 has an updated version of the BCP 14 boilerplate. I'd suggest adding "MASA Audit Log" as a defined term to give advance warning that this is an explicit protocol feature. domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT STRING of the subjectPublicKey of the pinned-domain-cert leaf, i.e. the Registrars' certificate. This is consistent with the subject key identifier (Section 4.2.1.2 [RFC5280]). What would it take to move away from SHA-1 for this purpose? It's unclear how long it will be before finding a second preimage of the SPKI hash is feasible and thus using it as an identifier no longer serves to uniquely identify something. enrollment: The process where a device presents key material to a network and acquires a network specific identity. For example nit: hyphenate "network-specific". Section 1.4 As a result of the protocol described herein, the bootstrapped devices have the Domain CA trust anchor in common. An end entity certificate has optionally been issued from the Domain CA. [...] This end-entity certificate is supposed "to authenticate each bootstrapped device to other parties in the domain", right? The major beneficiary is that it possible to use the credentials deployed by this protocol to secure the Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane]). I might humbly suggest "major intended beneficiary", as there seem to be many possibilities involving BRSKI. Section 1.5 The pledge must perform discovery of the proxy as described in Section 4.1 using GRASP M_FLOOD announcements. Is this DULL GRASP or full-on ACP GRASP flooding? Upon successfully validating a voucher artiface, a status telemetry MUST be returned. See Section 5.7. nit: artifact (right?) The ANI Join Registrar ASA MUST support all the BRSKI and above listed EST operations. nit: probably need to expand ASA the first time. Section 2 The text following Figure 1 suggests that the Domain Registrar is not always (also) a PKI RA, but the parentheticals in the figure itself are easy to read as a clarification and not an optional thing, especially since parentheticals are used in a different manner for the Key Infrastructure box. Section 2.1 3. Request to join the discovered registrar. A unique nonce is included ensuring that any responses can be associated with this particular bootstrapping attempt. But the nonce is not always present! 5. Enroll. After imprint an authenticated TLS (HTTPS) connection exists between pledge and registrar. Enrollment over Secure Transport (EST) [RFC7030] is then used to obtain a domain certificate from a registrar. Isn't this step optional? Section 2.2 A voucher is a cryptographically protected artifact (a digital signature) to the pledge device authorizing a zero-touch imprint on the registrar domain. nit: "using a digital signature" Vouchers provide a signed but non-encrypted communication channel among the pledge, the MASA, and the registrar. The registrar maintains control over the transport and policy decisions allowing the local security policy of the domain network to be enforced. nit: is there supposed to be a comma after "policy decisions" (in that both the transport and policy decisions allow for policy enforcement)? Section 2.3 Pledge authentication and pledge voucher-request signing is via a PKIX certificate installed during the manufacturing process. This is (As noted elsewhere, "PKIX" may not be the best term here.) 1. Uniquely identifying the pledge by the Distinguished Name (DN) and subjectAltName (SAN) parameters in the IDevID. The unique identification of a pledge in the voucher objects are derived from those parameters as described below. These unique identifiers can (by design) be used for tracking, so let's be sure that we talk about any privacy considerations with them, later. I see a mention in passing in Section 10.2, at least... 3. Secure auto-discovery of the pledge's MASA by the registrar (see Section 2.8). I don't think this is an ironclad property, since the crypto chain is slightly limited and you are in effect trusting the pledge to hand you something that says "use this issuer" but without as much crypto to back that up as we might want. We have to know that the given manufacturer that signed the IDevID actually is associated with the device we're trying to bootstrap, which can probably be arranged but I don't remember being called out explicitly. Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage extensions in the IDevID certificate. Any restrictions included I only got my hands on the 2018 rev of [IDevID], but that one does not actually talk about extendedKeyUsage. Section 2.3.1 In the context of BRSKI, pledges are uniquely identified by a "serial-number". This serial-number is used both in the "serial- number" field of voucher or voucher-requests (see Section 3) and in local policies on registrar or MASA (see Section 5). (editorial) if the IDevID is supposed to be a unique identifier, why do we need another one? o The subject field's DN encoding MUST include the "serialNumber" attribute with the device's unique serial number. (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes) side note: I had to think a bit to convince myself that DN is the right thing here; when we use dnsNames it's preferred to put them in subjectAltName to avoid having to pick a preferred/privileged one, but the serial number does seem to be in a privileged position for distinguishing the subject. o The subject-alt field's encoding MAY include a non-critical version of the RFC4108 defined HardwareModuleName. (from [IDevID] section 7.2.9) If the IDevID is stored in a Trusted Platform Module (TPM), then this field MAY contain the TPM identification rather than the device's serial number. If both fields are present, then the subject field takes precedence. "if both fields are present", but the subject field MUST be present, so this field can never take precedence. 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the Distinguished Name "serialNumber" attribute. [RFC4514] indicates this is a printable string so no encoding is necessary. I don't understand why these references were chosen. Why are LDAP specs authoritative about what the encoding format for the serialNumber DN attribute is? E.g., one could look at RFC 5280 to see that X520SerialNumber is a PrintableString. 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is base64 encoded to convert it to a printable string format. Please cite Section 4 of RFC 4648 (unless you mean base64url, in which case use Section 5). Also, it might be nice to somehow (maybe enumerate the first list in the same way) tie these two items to the respective subject ND/subjectAltName fields, to clarify why these are the only two choices. As explained in Section 5.5 the Registrar MUST extract the serial- number again itself from the pledge's TLS certificate. [...] To be clear, this is still the device's IDevID certificate, that just happens to be getting used as a TLS client certificate. Section 2.3.2 nit: maybe put a blank line after the IMPORTS are over? Section 2.4 In Figure 3, I had to think a bit to figure out whether the text that did not fit mid-arrow was supposed to apply to the arrow above or below the text (e.g., "optional: mDNS query RFC6763/RFC6762"). [Hmm, so we send our TLS client cert on the provisional connection, meaning that we have to trust the proxy and registrar to be doing the right thing w.r.t. broadcasting our identity to the world] Section 2.5.1 The pledge is the device that is attempting to join. Until the pledge completes the enrollment process, it has link-local network connectivity only to the proxy. nit(?): I think there is a subtle difference in meaning between "only has link-local network connectivity to the proxy" and this text, and I'm not sure which is intended. Section 2.5.3 This may just be my personal preference (so feel free to ignore), but talking about a "trust store used to authenticate the MASA" and "trust store used to authenticate the pledge" would feel more readable than "trust anchor database for authenticating the [thing] TLS connection [thing] certificate". It may be worth some comment about how this requirement for out-of-band distribution of implicit trust anchors is something that BRSKI is designed to avoid, but that distributing to just the registrar is a much more manageable task than distributing them to all devices/pledges. Section 2.5.5 The Public Key Infrastructure (PKI) administers certificates for the domain of concerns, providing the trust anchor(s) for it and allowing nit: "domain of concern" singular The voucher provides a method for the distribution of a single PKI trust anchor (as the "pinned-domain-cert"). A distribution of the Earlier we talked about the "pinned-domain-cert leaf" in the domainID definition. Was that supposed to be "leaf" in the YANG sense and not in the PKIX "leaf certificate"/"end-entity certificate" sense? The expectations of the PKI are unchanged from EST [[RFC7030]]. This Which parts of RFC 7030 talk about its expectations of the PKI? Section 2.6.1 Many devices when bootstrapping do not have knowledge of the current time. Mechanisms such as Network Time Protocols cannot be secured until bootstrapping is complete. Therefore bootstrapping is defined in a method that does not require knowledge of the current time. A nit: I'd suggest maybe "framework", "scenario", or "environment" rather than "method". Section 2.6.2 [RFC5280] explains that long lived pledge certificates "SHOULD be assigned the GeneralizedTime value of 99991231235959Z". Registrars This misses the important "for the notAfter field" part. Why is 3 years the relevant cutoff here? Section 2.7 There exist operationally open network wherein devices gain nit: "networks" plural unauthenticated access to the internet at large. In these use cases the management domain for the device needs to be discovered within the larger internet. These are less likely within the anima scope but may be more important in the future. nit: less likely than what? There are additionally some greenfield situations involving an entirely new installation where a device may have some kind of management uplink that it can use (such as via 3G network for instance). In such a future situation, the device might use this management interface to learn that it should configure itself to become the local registrar. In order to support these scenarios, the pledge MAY contact a well known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar. I don't see the connection between "configure itself to become the local registrar" and "contact a well-known URI of a cloud registrar". If the pledge uses a well known URI for contacting a cloud registrar an Implicit Trust Anchor database (see [RFC7030]) MUST be used to authenticate service as described in [RFC6125]. This is consistent Would this be more likely to be installed by the manufacturer or device owner? nit: "service" needs an article. Section 2.8 approach if they ensure a single MASA URL works for all pledge's associated with each trust anchor. nit: "pledges" non-possessive Section 3 A pledge forms the "pledge voucher-request" and submits it to the registrar. It would be helpful (at least to me) to know that the request is signed by the IDevID cert, here. 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?) Section 3.3 Example (1) The following example illustrates a pledge voucher- request. The assertion leaf is indicated as 'proximity' and the registrar's TLS server certificate is included in the 'proximity-registrar-cert' leaf. See Section 5.2. { "ietf-voucher-request:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "created-on": "2017-01-01T00:00:00.000Z", "proximity-registrar-cert": "base64encodedvalue==" } } I do not see an 'assertion' leaf populated. 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 object. In the JSON encoding used here it must Why is it a binary object? We just saw a previous example with a JSON (non-binary) encoding. (Hint: CMS-signed,but we didn't say that.) be base64 encoded. The nonce, created-on and assertion is carried forward. The serial-number is extracted from There is (again) no assertion, and the created-on does not match exactly. Section 3.4 The RFC 8174 version of the BCP 14 boilerplate could be used in the module, too. Also, is the 2017 copyright still correct, especially given that it is a 2018-02-14 revision? For example, a pledge might sign a voucher request with a proximity-registrar-cert, and the registrar then includes it in the prior-signed-voucher-request field. nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)? This is a simple mechanism for a chain of trusted parties to change a voucher request, while maintaining the prior signature information. "chain" seems to admit the possibility of more than one modification/resigning event, but the architecture as described seems to only have the registrar doing this. registrar agree on proximity assertions. The MASA SHOULD remove all prior-signed-voucher-request information when signing a voucher for imprinting so as to minimize the final voucher size."; (side note?) This removal would open up some minor exotic attacks in cases where a pledge reuses an existing nonce (potentially from a different device), but is probably an okay tradeoff to make. The first certificate in the Registrar TLS server certificate_list sequence (see [RFC5246]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request if a proximity assertion is requested."; 5246 is replaced by 8446. It might be simplest to just say the "end-entity TLS certificate", at least for TLS practitioners. (Maybe nof for a different audience, though.) How do I know that a proximity assertion is requested? Section 4 The role of the proxy is to facilitate communications. The proxy forwards packets between the pledge and a registrar that has been provisioned to the proxy via GRASP discovery. [same DULL question as above] The proxy does not terminate the TLS handshake: it passes streams of bytes onward without examination. A proxy MUST NOT assume any specific TLS version. Passing bytes without examination is by definition not assuming any version of TLS. So while I think it would make the most sense to just remove that sentence, if it's going to say it might be worth also noting the TLS invariants discussed in https://tools.ietf.org/html/rfc8446#section-9.3 . Section 4.1 through a proxy. The proxy is transparent to the pledge. The communication between the pledge is over IPv6 Link-Local addresses. nit: between the pledge and what? M_FLOOD. The active methods SHOULD exponentially back-off to a maximum of one hour to avoid overloading the network with discovery attempts. Detection of change of physical link status (ethernet carrier for instance) SHOULD reset the exponential back off. Mathematically, "exponential" requires to specify the base of the exponent (or just say "by doubling"). (Also later in the section.) Once all discovered services are attempted (assuming that none succeeded) the device MUST return to listening for GRASP M_FLOOD. It SHOULD periodically retry the manufacturer specific mechanisms. The pledge MAY prioritize selection order as appropriate for the anticipated environment. nit: "manufacturer-specific" takes a hyphen not-nit: what are "the manufacturer-specific mechanisms"? (I don't remember such discussion yet.) Once all discovered services are attempted (assuming that none succeeded) the device MUST return to listening for GRASP M_FLOOD. It SHOULD periodically retry the manufacturer specific mechanisms. The pledge MAY prioritize selection order as appropriate for the anticipated environment. nit: "manufacturer-specific" takes a hyphen not-nit: what are "the manufacturer-specific mechanisms"? (I don't remember such discussion yet.) Section 4.1.1 Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or some other notation? Also, I'm not sure that picking an arbitrary (representative) session-id value, LL address, and port is helpful when describing the formatting of the message. Maybe some different introductory text would change things. Section 4.3 If we're only defining an EST-TLS objective, how will proxies know that the registrar supports BRSKI? It's a little weird to put the reference for GRASP but not ACP. Either none or both would feel more natural (given that we've seen both already a couple times). Section 5 MASA URI is "https://" iauthority "/.well-known/est". nit: "The MASA URI". Is this always the case, with no opportunity for modification, even as included in an IDevID certificate extension? BRSKI uses JSON [RFC7159] for all new operations defined here, and RFC 7159 is obsoleted by RFC 8259. While EST section 3.2 does not insist upon use of HTTP 1.1 persistent connections, BRSKI-EST connections SHOULD use persistent connections. The intention of this guidance is to ensure the provisional TLS state occurs only once, and that the subsequent resolution of the provision state is not subject to a MITM attack during a critical phase. I think we probably want a requirement that if persistent connections are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST check that the exact same certificate is used to authenticate the registrar for all transactions. If the signature in the handshake is valid but you can only chain the certificate up to your trust anchor once you finish imprinting, you still know that the entire session's data has been talking to the now-authenticated party (as opposed to the TLS case where you try to add a new certificate mid-connection, where that boundary is unclear), but things are much easier to reason about if you are sure that each EST transaction is talking to the same peer. o In the language of [RFC6125] this provides for a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. The SERIALNUM-ID whitelist is collated according to manufacturer trust anchor since serial numbers are not globally unique. RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in the model of RFC 6125" or "provides a new SERIAL-ID category" or similar. o The registrar performs log verifications in addition to local authorization checks before accepting optional pledge device enrollment requests. Maybe give us a section reference to what the "log validations" are? Section 5.1 Establishment of the BRSKI-EST TLS connection is as specified in EST [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] wherein the client is authenticated with the IDevID certificate, and the EST server (the registrar) is provisionally authenticated with an unverified server certificate. I'd consider noting that the signature (or other operation) made by the certificate must be validated, and that the received certificate and chain must be retained for later validation. The pledge maintains a security paranoia concerning the provisional state, and all data received, until a voucher is received and verified as specified in Section 5.6.1 Since section 5.6.1 just talks about the voucher verification process, I think we need to say more about what "security paranoia" entails: acknowledging that all data transmitted is sent to an unauthenticated peer, with corresponding privacy considerations, and that all received data is not authenticated by the TLS connection and must be self-authenticating or otherwise considered untrusted. A pledge that can not maintain as many connections as there are eligible proxies. If no connection is making process after 5 seconds nit: that's not a complete sentence. Section 5.2 application/voucher-cms+json The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in Section 3 using the JSON encoding described in [RFC7951]. This Section 3 does not describe any "sign[ing] using a CMS structure" operation. voucher media type is defined in [RFC8366] and is also used for the pledge voucher-request. The pledge SHOULD sign the request using the Section 2.3 credential. To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other credential) to sign? constrained voucher formats are expected in the future. Registrar's and MASA's are expected to be flexible in what they accept. nits: no apostrophes for plurals. proximity-registrar-cert: In a pledge voucher-request this is the first certificate in the TLS server 'certificate_list' sequence (see [RFC5246]) presented by the registrar to the pledge. This MUST be populated in a pledge voucher-request if the "proximity" assertion is populated. [same comment as above about "end-entity certificate"] The registrar validates the client identity as described in EST [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' assertion and associated 'proximity-registrar-cert' are correct. what 'proximity' assertion? Does verifying proximity-registrar-cert just mean checking that it's the same leaf certificate that the registrar presented? What happens if the validation fails? Section 5.3 A Registrar accepts or declines a request to join the domain, based on the authenticated identity presented. Automated acceptance criteria include: I suggest "for different networks, examples of automated acceptance criteria may include". If these validations fail the registrar SHOULD respond with an appropriate HTTP error code. Similarly, "If validation fails". Section 5.4 The BRSKI-MASA TLS connection is a 'normal' TLS connection appropriate for HTTPS REST interfaces. The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8 for [RFC6125] authentication of the MASA. I'd consider mentioning the implicit trust anchor database as well as the MASA URL. The MASA and the registrars SHOULD be prepared to support TLS client certificate authentication and/or HTTP Basic or Digest authentication as described in [RFC7030] for EST clients. This connection MAY also have no client authentication at all (Section 7.4) I don't see discussion of skipping client authentication in Section 7.4. It would be great to have some, there! The authentication of the BRSKI-MASA connection does not affect the voucher-request process, as voucher-requests are already signed by the registrar. Instead, this authentication provides access control to the audit log. I don't understand what "access control to the audit log" means. Is the idea that the TLS client identity in the BSRKI-MASA connection is only used when processing requests to the requestauditlog endpoint and that some clients might be denied access? Section 5.5 created-on: Registrars are RECOMMENDED to populate this field. This provides additional information to the MASA. Earlier we said that this field would be propagated from the pledge voucher-request; we should probably say something like "populate this field; if it was present in the pledge voucher-request it is copied unchanged to the registrar voucher-request; otherwise the current time is used". nonce: This is the value from the pledge voucher-request. The registrar voucher-request MAY omit the nonce as per Section 3.1) I'd suggest "value from the pledge voucher-request, if present" and changing the second sentence to refer to the pledge voucher-request. idevid-issuer: The idevid-issuer value from the pledge certificate is included to ensure a statistically unique identity. There is no "idevid-issuer" field in the pledge certificate; I assume this is supposed to be the Issuer Name of the IDevID certificate. prior-signed-voucher-request: The signed pledge voucher-request SHOULD be included in the registrar voucher-request. (NOTE: what is included is the complete pledge voucher-request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This is a good example of text that implies the signed voucher is binary. (And as such would be a good place to talk about the base64 encoding.) All other fields MAY be omitted in the registrar voucher-request. Should the proximity-registrar-cert field *not* be present? Section 5.5.2 The MASA MUST verify that the registrar voucher-request is signed by a registrar. This is confirmed by verifying that the id-kp-cmcRA extended key usage extension field (as detailed in EST RFC7030 section 3.6.1) exists in the certificate of the entity that signed the registrar voucher-request. This verification is only a consistency check that the unauthenticated domain CA intended the voucher-request signer to be a registrar. Performing this check provides value to the domain PKI by assuring the domain administrator that the MASA service will only respect claims from authorized Registration Authorities of the domain. If the MASA has no prior knowledge of the domain (certificate), this is susceptible to anyone spinning up something that claims to be a domain CA and issuing registrar certs with that extension. We need to document somewhere what other part of the system prevents that from causing an unauthorized voucher to be used. (Perhaps preventing one from being issued is not feasible, but acceptable if the pledge will not accept it, though there remains risk of DoS on the MASA.) Section 5.5.3 If a nonceless voucher-request is submitted the MASA MUST authenticate the registrar as described in either EST [RFC7030] section 3.2, section 3.3, or by validating the registrar's Subsubsection references might be more helpful. In the nonced case, validation of the registrar MAY be omitted if the device policy is to accept audit-only vouchers. I don't see any (SHOULD?) guidance about validating the registrar in the nonced case when other policy is used. Even the previous section does not really say much to indicate there is value in authenticating the signature on the voucher request. Section 5.5.4 authentication or voucher-request signature validation. Similarly, as noted in Section 5.5.2, the MASA performs normal PKIX revocation checking during signature consistency checks (a signature by a registrar certificate that has been revoked is an inconsistency). I think this needs to be noted more clearly in Section 5.5.2. Section 5.5.5 The MASA MAY verify that the registrar voucher-request includes the 'prior-signed-voucher-request' field. If so the prior-signed- voucher-request MUST include a 'proximity-registrar-cert' that is consistent with the certificate used to sign the registrar voucher- request. Additionally the voucher-request serial-number leaf MUST This seems kind of tautological ("if the MASA is checking X, X MUST have happened"). Also, what does "consistent with" mean? match the pledge serial-number that the MASA extracts from the signing certificate of the prior-signed-voucher-request. The MASA is aware of which pledges support signing of their voucher requests and can use this information to confirm proximity of the pledge with the registrar, thus ensuring that the BRSKI-EST TLS connection has no man-in-the-middle. To be clear, this MITM detection is only for the case of pledges that sign their voucher requests, right? And it seems to only hold if pledges that support signing actually do sign, every time. Section 5.5.6 The registrar's certificate chain is extracted from the signature method. The chain includes the domain CA certificate as specified in Section 5.5. This certificate is used to populate the "pinned- I don't think Section 5.5 is the right reference for "includes the domain CA certificate" (both here and in 5.5.2). domain-cert" of the voucher being issued. The domainID (e.g., hash of the root public key) is determined from the pinned-domain-cert and is used to update the audit log. If the pinning takes the whole cert (per RFC 8366), then what do we need the domainID for? Just the audit log? Surely in that case SHA-1 is not a hard requirement... Section 5.5.7 The MASA MUST use the nonce from the registrar voucher-request for the resulting voucher and audit log. The prior-signed-voucher- request nonce is ignored during this operation. I don't understand this requirement. They could only be different if the MUST from the previous paragraph is ignored. Section 5.6 The MASA voucher response to the registrar is forwarded without changes to the pledge; therefore this section applies to both the MASA and the registrar. The HTTP signaling described applies to both the MASA and registrar responses. A registrar either caches prior MASA responses or dynamically requests a new voucher based on local policy (it does not generate or sign a voucher). [...] Do we need to say how this local caching policy interacts with HTTP cache control headers? I got confused by "or dynamically requests a new voucher" the first couple times I read it; I landed on something like "when a voucher request arrives at the registrar, if it has a cached response from the MASA for the corresponding registrar voucher-request, that cached response can be used according to local policy; otherwise the registrar constructs a new registrar voucher-request and sends it to the MASA". type. The registrar SHOULD use this response if it determines the pledge is unacceptable due to inventory control, MASA audit logs, or any other reason. What does "unacceptable due to inventory control" mean? A 415 (Unsupported Media Type) response is approriate for a request that has a voucher-request or accept encoding that is not understood. Isn't "Accept-Encoding:" a more typical spelling? vouchers are described in detail in [RFC8366]. For example, the voucher consists of: { "ietf-voucher:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "assertion": "logging" "pinned-domain-cert": "base64encodedvalue==" "serial-number": "JADA123456789" } } nit: I think "might consist of" is better than "consists of". assertion: The method used to verify assertion. See Section 5.5.5. The method used to verify itself? The pledge MUST be prepared to parse and fail gracefully from a voucher response that does not contain a 'pinned-domain-cert' field. What would such a graceful failure look like? Reverting back to the discovery stage, since without a manufacturer-validated indication of the trust anchor for the domain, the pledge cannot consider itself to be a part of a domain? Section 5.6.2 found. It SHOULD return to the same proxy again after attempting with other proxies. Attempts should be attempted in the exponential But only if those other proxies failed to produce a valid voucher? The pledge's PKIX path validation of a registrar certificate's validity period information is as described in Section 2.6.1. Once the PKIX path validation is successful the TLS connection is no longer provisional. Section 2.6.1 doesn't actually say that the pledge has to check the five listed timestamps in the case that it does have a realtime clock. Section 5.7 To indicate pledge status regarding the voucher, the pledge MUST post a status message. I think we've had other text that implies that providing telemetry is optional; perhaps just "the pledge POSTs a status message"? The client HTTP POSTs the following to the server at the EST well known URI "/voucher_status". The Status field indicates if the I think it's probably more clear to write out ".well-known/est/voucher_status"; there's not a separate registry of EST well-known URIs. We don't actually have anything in this section that declares "this is the structure of the JSON object used as the POST body"; it's only implicitly provided. indicates why. In the failure case this message may be sent to an unauthenticated, potentially malicious registrar and therefore the Reason string SHOULD NOT provide information beneficial to an attacker. The operational benefit of this telemetry information is What sort of information might a pledge consider including that would be beneficial to an attacker? { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail" I guess you should probably close the comment, not that this is a formal comment syntax for JSON... The reason-context attribute is an arbitrary JSON object (literal value or hash of values) which provides additional information specific to this pledge. The contents of this field are not subject to standardization. This still have some privacy considerations, though. Section 5.8 is posted to the /requestauditlog URI instead. The "idevid-issuer" and "serial-number" informs the MASA which log is requested so the appropriate log can be prepared for the response. Using the same Is the implicit point that the other fields are ignored? A registrar MAY request logs at future times. If the registrar generates a new request then the MASA is forced to perform the additional cryptographic operations to verify the new request. Is this statement just supposed to be further justification for using the original voucher-request as the POST body, or describing new behavior? A MASA that receives a request for a device that does not exist, or for which the requesting owner was never an owner returns an HTTP 404 ("Not found") code. What is a "requesting owner"? I thought devices were owned by the domain, not the specific registrar. In order to avoid enumeration of device audit logs, MASA that return URLs SHOULD take care to make the returned URL unguessable. For instance, rather than returning URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD return a randomly generated value (a "slug" in web parlance). The value is used to find the relevant database entry. https://www.w3.org/TR/capability-urls/ may also be a useful reference. Section 5.8.1 A log data file is returned consisting of all log entries associated with the the device selected by the IDevID presented in the request. The audit log may be truncated of old or repeated values as explained below. The returned data is in JSON format ([RFC7951]), and the Content-Type SHOULD be "application/json". For example: If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". This document specifies a simple log format as provided by the MASA service to the registrar. This format could be improved by distributed consensus technologies that integrate vouchers with technologies such as block-chain or hash trees or optimized logging approaches. Doing so is out of the scope of this document but is an anticipated improvement for future work. As such, the registrar client SHOULD anticipate new kinds of responses, and SHOULD provide operator controls to indicate how to process unknown responses. This would be a great place to talk about the "version" field that's otherwise ignored. anticipated improvement for future work. As such, the registrar client SHOULD anticipate new kinds of responses, and SHOULD provide operator controls to indicate how to process unknown responses. Is "registrar client" intended to be both words or just one? A registrar SHOULD use the log information to make an informed decision regarding the continued bootstrapping of the pledge. The I may be confused, but I thought the registrar was asking for the log after the voucher had already been issued. Are these check supposed to keep the registrar from forwarding the voucher to the pledge, or just as a check for future renewal operations? A relatively simple policy is to white list known (internal or external) domainIDs and to require all vouchers to have a nonce and/ or require that all nonceless vouchers be from a subset (e.g. only internal) domainIDs. A simple action is to revoke any locally issued nit: missing "of" credentials for the pledge in question or to refuse to forward the voucher. A registrar MAY be configured to ignore the history of the "simple action" in the case that the registrar doesn't like the audit log results? device but it is RECOMMENDED that this only be configured if hardware assisted NEA [RFC5209] is supported. Probably need to expand NEA. Section 5.9 Although EST allows clients to obtain multiple certificates by sending multiple CSR requests BRSKI mandates use of the CSR Attributes request and mandates that the registrar validate the CSR against the expected attributes. This implies that client requests Where is this requirement stated normatively? Section 5.9.1 This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert (see Section 5.6.1 for a discussion of the limitations inherent in having a single certificate instead of a full CA Certificates response.) Although these I don't see such a discussion in the indicated section. Section 5.9.2 To alleviate these operational difficulties, the pledge MUST request the EST "CSR Attributes" from the EST server and the EST server needs to be able to reply with the attributes necessary for use of the certificate in its intended protocols/services. This approach allows "intended" implies that the EST server has some knowledge of what the pledge is expected to be doing in the network, right? To alleviate these operational difficulties, the pledge MUST request the EST "CSR Attributes" from the EST server and the EST server needs to be able to reply with the attributes necessary for use of the certificate in its intended protocols/services. This approach allows for minimal CA integrations and instead the local infrastructure (EST server) informs the pledge of the proper fields to include in the generated CSR. This approach is beneficial to automated boostrapping in the widest number of environments. This is convenient, but has some security considerations in that it implies that the validation policy on the CA is somewhat lax, since the EST server is expected to be doing most of the policy controls. Thus, a compromised pledge/device could send a CSR with unauthorized fields and it is likely to be signed, allowing for some level of privilege escalation. When the registrar acts as a proxy to the CA as well as its EST role, as described later, this risk is diminished. In networks using the BRSKI enrolled certificate to authenticate the ACP (Autonomic Control Plane), the EST attributes MUST include the "ACP information" field. See [I-D.ietf-anima-autonomic-control-plane] for more details. This MUST seems like it belongs in the ACP spec and need not be repeated here using normative language. Section 5.9.4 administrators concerning device lifecycle status. This might include information concerning attempted bootstrapping messages seen by the client, MASA provides logs and status of credential enrollment. [RFC7030] assumes an end user and therefore does not This looks like a comma splice. In the case of a FAIL, the Reason string indicates why the most recent enrollment failed. The SubjectKeyIdentifier field MUST be included if the enrollment attempt was for a keypair that is locally We haven't talked about POSTing to a new status-report endpoing yet, so this comes out of the blue. It would probably be worth adding above "SHOULD [start a new TLS handshake] and POST a enrollment status message". "Status":TRUE /* TRUE=Success, FALSE=Fail" [same note about JSON comments] "reason-context": "Additional information" Is this supposed to be a string or a JSON object similar to /voucher_status? This allows for clients that wish to minimize their crypto operations to simply POST this response without renegotiating the TLS session - at the cost of the server not being able to accurately verify that enrollment was truly successful. I'd prefer to not have this sort of option available, but I can't disprove the claim of its utility, so I will not object if it stays. Section 5.9.5 Is the idea that the initial BRSKI-EST-issued certificate would authenticate the client for the subsequent EST requests? Section 7 If this is non-normative and will need to be fleshed out in a separate document, would an Appendix be more appropriate? Section 7.1 Pledge: The pledge could be compromised and providing an attack vector for malware. The entity is trusted to only imprint using secure methods described in this document. Additional endpoint How do "could be compromised" and "is trusted to only [...]" go together? Vendor Service, MASA: This form of manufacturer service is trusted to accurately log all claim attempts and to provide authoritative log information to registrars. The MASA does not know which devices are associated with which domains. These claims could be I think this is maybe more of a "does not enforce" than "does not know", since the domainID ends up in the audit logs that the MASA holds. Current text provides only for a trusted manufacturer. nit: not a complete sentence. 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". Lower security modes chosen by the MASA service affect all device deployments unless bound to the specific device identities. In which Is this "unless the lower-security behavior is tied to specific device identities"? case these modes can be provided as additional features for specific customers. The MASA service can choose to run in less secure modes nit: This middle sentence is not a complete sentence. 1. Not enforcing that a nonce is in the voucher. This results in distribution of a voucher that never expires and in effect makes A nonceless voucher can still include an expiration time ... it is just in practice possible for it to never expire, if the target pledge does not have an accurate clock. subsequent bootstrapping attempts. That this occurred is captured in the log information so that the registrar can make appropriate security decisions when a pledge joins the Domain. This is useful to support use cases where registrars might not be online during actual device deployment. Because this results in nit: I think that grammatically the "This" at the start of this sentence refers to the behavior described in the previous sentence (the availability of the log information) rather than the issuance of the nonceless voucher. Section 9 The autonomic control plane that this document provides bootstrap for is typically a medium to large Internet Service Provider organization, or an equivalent Enterprise that has signficant layer-3 router connectivity. (A network consistenting of primarily layer-2 nit: "is used in" -- the ACP is not the entire organization! Section 10.1 The MASA audit log includes a hash of the domainID for each Registrar a voucher has been issued to. This information is closely related to the actual domain identity, especially when paired with the anti-DDoS authentication information the MASA might collect. This could I thought I remembered some discussion of collecting this information and thus what sort of information might be collected, but searching for "DDoS" in the document didn't find it. There are a number of design choices that mitigate this risk. The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain. Is this really "privacy" or just "semi-plausible deniability"? Additionally the domainID captures only the unauthenticated subject key identifier of the domain. A privacy sensitive domain could It's interesting to see "unauthenticated" used here, since the domainID is deterministically generated from the pinned-domain-cert that is included in the voucher and inserted into the pledge's trust store. So in a sense it is a committal by "the domain" to tie that domain cert to that device or have the device otherwise be unusable. The subsequent text here seems to be suggesting that instead of having a single root CA cert used by all devices in the domain, distinct certs would be used for each device, thus attempting to remove an ability to associate devices with each other via joint domain membership. One might imagine doing this by entering intermediate CAs (or even leafs?) into the pinned-domain-cert field, but if those certs ever become visible (e.g., via certificate transparency), then the domainIDs can be independently computed and associated to the MASA audit log, and the issuer chain used to recorrelate the devices by domainID. So to fully protect privacy, the per-device pinned-domain-certs would need to be "root"s (i.e., self-issued), which greatly increases the manageability complexity and is in effect counter to the goals of ANIMA and BRSKI. Section 10.2 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 prevents exfiltration of data by a nefarious pledge. The contents of an I think "prevents" is too strong -- steganography and concealed channels are really hard to completely defend against. "Gives a mechanism to defend against" would be more accurate, in my opinion. The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer: that an enterprise/ISP purchases routing products is hardly worth mentioning. Deviations would, however, be notable. Deviations in what sense? Section 10.3 4. There is a fourth case, if the manufacturer is providing protection against stolen devices. The manufacturer then has a responsability to protect the legitimate owner against fraudulent claims that the the equipment was stolen. Such a claim would cause the manufacturer to refuse to issue a new voucher. Should the device go through a deep factory reset (for instance, replacement of a damaged main board component, the device would not bootstrap. I'm not sure I understand this scenario -- is it talking about where a third party makes a false theft report in the hopes that the real owner will have to do a deep reset and then have the device fail to bootstrap because of the reported theft? Section 11 To facilitate logging and administrative oversight, in addition to triggering Registration verification of MASA logs, the pledge reports I'm not sure if "Registration verification" is a typo or not. registrar. This is mandated anyway because of the operational benefits of an informed administrator in cases where the failure is indicative of a problem. The registrar is RECOMMENDED to verify MASA I'd also expect some comment about the limited value of the additional information to an attacker in the context where the attacker already would know [other information]. To facilitate truely limited clients EST RFC7030 section 3.3.2 requirements that the client MUST support a client authentication model have been reduced in Section 7 to a statement that the registrar "MAY" choose to accept devices that fail cryptographic authentication. This reflects current (poor) practices in shipping But section 7 is non-normative! devices without a cryptographic identity that are NOT RECOMMENDED. I guess if we really wanted to disrecommend this practice we could split it out into a separate document that profiles core BRSKI for such usage. Section 11.1 this might be an issue during disaster recovery. This risk can be mitigated by Registrars that request and maintain long term copies of "nonceless" vouchers. In that way they are guaranteed to be able to bootstrap their devices. This, of course, comes with a different risk of what is something like a long-term credential existing that needs to be protected and stored. The issuance of nonceless vouchers themselves creates a security concern. If the Registrar of a previous domain can intercept protocol communications then it can use a previously issued nonceless voucher to establish management control of a pledge device even after having sold it. This risk is mitigated by recording the issuance of such vouchers in the MASA audit log that is verified by the subsequent Registrar and by Pledges only bootstrapping when in a factory default state. This reflects a balance between enabling MASA independence during future bootstrapping and the security of bootstrapping itself. Registrar control over requesting and auditing nonceless vouchers allows device owners to choose an appropriate balance. I would expect some discussion here about nonceless vouchers with/without expiration times. I also wonder whether the owner or registrar should expect to be doing soem periodic MASA audit log checking, akin to a CT auditor or monitor. of specific pledge devices, helps to mitigate this. Pledge signatures on the pledge voucher-request, as forwarded by the registrar in the prior-signed-voucher-request field of the registrar voucher-request, significantly reduce this risk by ensuring the MASA can confirm proximity between the pledge and the registrar making the request. This mechanism is optional to allow for constrained devices. Supply chain integration ("know your customer") is an And so the protection is only available when all devices served by the MASA are known to produce signed voucher-requests. additional step that MASA providers and device vendors can explore. In terms of adding some more crypto to the BRSKI-MASA flow that would prevent unauthenticated DoS? Section 11.2 I appreciate having this discussion present; thanks! The fake registrar (Rm) can obtain a voucher signed by the MASA either directly or through arbitrary intermediaries. Assuming that I'm not sure what sort of intermediary this is thinking about. This pledge voucher-request would be 'stale' in that it has a nonce that no longer matches the internal state of the pledge. In order to successfully use any resulting voucher the Rm would need to remove the stale nonce or anticipate the pledge's future nonce state. Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce. This gets a bit more complicated to reason about when we assume that a pledge will have multiple voucher requests out in parallel, instead of doing them in sequence and timing out (so that there is literally only one valid nonce at a given time)... 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. o Retreival and examination of MASA log information upon the occurance of any such unexpected events. Rm will be listed in the logs along with nonce information for analysis. How strongly guaranteed is it that a given device will only have a single specific MASA that it trusts to issue vouchers (and thus limit the scope of monitoring needed by the owner)? Section 11.3 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried upon seeing a manufacturer's trust anchor for the first time, and then the trust anchor would be installed to the trusted store. There are risks with this; even if the key to name is validated using something like the WebPKI, there remains the possibility nit: is this "key to name mapping"? Section 11.4 It is not entirely clear to me whether device manufacturers are set up with incentives to maintain a well-run secure CA with strong hardware protections on the offline signing key for the root CA, cycling through various levels of intermediates, etc., that CAs in the Web PKI do today. If the manufacturer uses a less stringent process, that would leave the manufacturer's key as a more tempting attack surface, and it may be worth some discussion here about what damage could be done with a compromised MASA signing key. E.g., would an attack require restoring devices to factory defaults or otherwise waiting for natural bootstrapping events to occur? Would the attacker need to be on-path? Etc. Section 13.2 I think CDDL needs to be a normative reference, as does RFC 7231. RFC 2473 is listed but not referenced in the text, as are RFC 2663, RFC 7217, and RFC 7575. Appendix B Discovery of registrar MAY also be performed with DNS-based service discovery by searching for the service "_brski- registrar._tcp.example.com". In this case the domain "example.com" is discovered as described in [RFC6763] section 11 (Appendix A.2 suggests the use of DHCP parameters). I'd suggest using "<domain>" per 6763 rather than "example.com". If no local proxy or registrar service is located using the GRASP mechanisms or the above mentioned DNS-based Service Discovery methods the pledge MAY contact a well known manufacturer provided bootstrapping server by performing a DNS lookup using a well known URI such as "brski-registrar.manufacturer.example.com". The details of the URI are manufacturer specific. Manufacturers that leverage this method on the pledge are responsible for providing the registrar service. Also see Section 2.7. It seems like there are some security considerations for device owners that may wish to prevent such registrars from being used. Do we need to direct them to run a firewall or similar? Appendix C I don't know how important file "ietf-mud-extension@2018-02-14.yang" is, but it seems a tad generic. Appendix D [Just checking that Michael wants sandelman.ca embedded in the final RFC]
- [Anima] Benjamin Kaduk's Discuss on draft-ietf-an… Benjamin Kaduk via Datatracker
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Adam Roach
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- [Anima] What does PKIX refer to: Re: Benjamin Kad… Michael Richardson
- Re: [Anima] What does PKIX refer to: Re: Benjamin… Michael Richardson
- Re: [Anima] What does PKIX refer to: Re: Benjamin… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- [Anima] Change of authors for draft-ietf-anima-bo… 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… 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… Adam Roach
- 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… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- 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… 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… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] {FINAL} Benjamin Kaduk's Discuss on d… 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… 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… 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… Michael Richardson