Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 28 October 2019 21:50 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974E9120098; Mon, 28 Oct 2019 14:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R4hhJXdvyrj; Mon, 28 Oct 2019 14:50:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6750B120096; Mon, 28 Oct 2019 14:50:13 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 61DAF3897A; Mon, 28 Oct 2019 17:47:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 799CC3BF0; Mon, 28 Oct 2019 17:50:10 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, The IESG <iesg@ietf.org>, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-Reply-To: <20191018012352.GB43312@kduck.mit.edu>
References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 28 Oct 2019 17:50:10 -0400
Message-ID: <22000.1572299410@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/qOvaJq-zBHYXbCYntHtfmcrnkS0>
Subject: Re: [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
Precedence: list
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: Mon, 28 Oct 2019 21:50:17 -0000
Benjamin Kaduk <kaduk@mit.edu> wrote: > I also have some more comments that didn't make it into my ballot position; > please consider them as well. I will put them in the datatracker for > posterity, but will have it not generate an additional mail since the > mostly-duplicate contents would be confusing. > Section 2 > Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of > bidirectional? I guess maybe unidirectional towards the Pledge makes more sense. (Some would argue that the Pledge contains trust anchors pointing at the Vendor) doc> 3. Request to join the discovered registrar. A unique nonce is doc> included ensuring that any responses can be associated with this doc> particular bootstrapping attempt. > This still seems to assume nonce-ful operation, which IIUC remains > required for pledge voucher-requests; only registrar-voucher-requests > have the option of being nonceless. So, this seems okay as-is, right? Correct. doc> 4. Imprint on the registrar. This requires verification of the doc> manufacturer service provided voucher. A voucher contains > nit: hyphenate "manufacturer-service-provided" ok. > Section 2.3.1 doc> The serialNumber fields is defined in [RFC5280], and is a SHOULD doc> field in [IDevID]. IDevID certificates for use with this protocol doc> MUST include the "serialNumber" attribute with the device's unique doc> serial number (from [IDevID] section 7.2.8, and [RFC5280] section doc> 4.1.2.4's list of standard attributes). > This is 4.1.2.2 (or just 4.1.2) from RFC 5280. Thank you. > Section 2.4 doc> I note that both Figure 2 and Figure 4 have a step labeled "Identity", doc> but the description accompanying Figure 2 describes the step as doc> "Identify itself"; perhaps the 'f' form is more appropriate doc> everywhere? okay. > Section 2.8 doc> Note that the registrar can only select the configured MASA URL based doc> on the trust anchor -- so manufacturers can only leverage this doc> approach if they ensure a single MASA URL works for all pledge's doc> associated with each trust anchor. > nit: s/pledge's/pledges/ ok. > Section 3 doc> Voucher-requests are how vouchers are requested. The semantics of doc> the vouchers are described below, in the YANG model. > nit: semantics of vouchers, or voucher requests? voucher-requests, fixed. > Section 3.3 doc> Figure 6: JSON representation of example Voucher-Request > I suggest adding "(unsigned)" or "prior to CMS wrapping". I've added: These examples show the JSON prior to CMS wrapping. to the intro. > Section 3.4 doc> refine "voucher/assertion" { doc> mandatory false; doc> description "Any assertion included in voucher doc> requests SHOULD be ignored by the MASA."; > If this is true, why do we propagate the assertion from pledge > voucher-request to registrar voucher-request? Clarified to say: description "Any assertion included in registrar voucher requests SHOULD be ignored by the MASA."; The assertion in the prior-signed-voucher-request (or Pledge Voucher-Request) may well be examined by the MASA. > Section 4.1 doc> Each possible proxy offer SHOULD be attempted up to the point where a doc> voucher is received: while there are many ways in which the attempt doc> may fail, it does not succeed until the voucher has been validated. > nit: I suggest "valid voucher is received". okay. > Section 5 doc> o The pledge requests and validates a voucher using the new REST doc> calls described below. > nit: I think the validation is local and does not use the REST call. changed to: <t> The pledge requests a voucher using the new REST calls described below. This voucher is then validated. </t> doc> o The registrar forwards the voucher to the pledge when requested. > I suggest "validates and forwards" to cover the case where the registrar > applies policy. the whole text is: <t>The registrar requests and validates the voucher from the MASA.</t> <t>The registrar forwards the voucher to the pledge when requested.</t> so validates is already in the previous point, I think. > Section 5.2 doc> nonce: The pledge voucher-request MUST contain a cryptographically doc> strong random or pseudo-random number nonce. (see [RFC4086]) Doing doc> so ensures Section 2.6.1 functionality. The nonce MUST NOT be > This section reference reads kind of strangely. (Also, full stop after > parenthetical, not before.) reworked some text. doc> proximity-registrar-cert: In a pledge voucher-request this is the doc> first certificate in the TLS server 'certificate_list' sequence doc> (see [RFC5246]) presented by the registrar to the pledge. That doc> is, it is the end-entity certificate. This MUST be populated in a doc> pledge voucher-request if the "proximity" assertion is populated. > nit: there is no "proximity" field to be populated; it's the "assertion" > field that's populated with the value "proximity". we have reworked the text, including the assertion and text. > Section 5.5 doc> serial-number: The serial number of the pledge the registrar would doc> like a voucher for. The registrar determines this value by doc> parsing the authenticated pledge IDevID certificate. See doc> Section 2.3. The registrar MUST verify that the serial number doc> field it parsed matches the serial number field the pledge doc> provided in its voucher-request. This provides a sanity check doc> useful for detecting error conditions and logging. The registrar doc> MUST NOT simply copy the serial number field from a pledge voucher doc> request as that field is claimed but not certified. > (Just to be clear, the serial-number field is optional in the pledge's > voucher-request.) We have a discussion last week about this. We are making it mandatory; it is to be used as check against what is in the IDevID. We had made it optional to avoid repeating and dealing with what if it not equal, but realized that we wanted it as a safety check. > Section 5.6.2 doc> intervals according to the backoff timer described earlier. Attempts doc> SHOULD be repeated as failure may be the result of a temporary doc> inconsistently (an inconsistently rolled registrar key, or some other doc> mis-configuration). The inconsistently could also be the result an doc> active MITM attack on the EST connection. > nit: only one of these "inconsistently"s is correct; the others should > be "inconsistency". okay > Section 5.8 doc> although it results in additional network traffic. The relying MASA doc> implementation MAY leverage internal state to associate this request doc> with the original, and by now already validated, voucher-request so doc> as to avoid an extra crypto validation. > It seems that doing so would turn the voucher-request into a bearer > token for retrieving audit-log information (if the MASA accepts > unauthenticated clients). That's what's intended. > Section 5.8.2 doc> If the "pinned-domain-cert" certificate includes the doc> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be doc> used as the domainID. If not, then it is the SPKI Fingerprint as doc> described in [RFC7469] section 2.4 is to be used. This value needs doc> to be calculated by both MASA (to populate the audit-log), and by the doc> Registrar (to recognize itself). > nit: maybe "to recognize itself in the audit log"? okay. > Section 5.9 doc> The pledge SHOULD follow the BRSKI operations with EST enrollment doc> operations including "CA Certificates Request", "CSR Attributes" and doc> "Client Certificate Request" or "Server-Side Key Generation", etc. doc> This is a relatively seamless integration since BRSKI REST calls > (I think we decided to not call this REST.) It was "RESTful" that was disliked, and we reference "REST", and I've changed these to API calls. > Section 7.3 doc> 4. A registrar MAY ignore unrecognized nonceless log entries. This doc> could occur when used equipment is purchased with a valid history doc> being deployed in air gap networks that required permanent doc> vouchers. > "nonceless" and "permanent" are related but subtly different concepts, > given the potential for an expiration date in a nonceless voucher. s/permanent/offline/ > Section 7.4.3 doc> As a third option, the manufacturer's trust anchors could be entirely doc> overwitten with local trust anchors. A factory default would never doc> restore those anchors. This option comes with a lot of power, but doc> also a lot of responsability: if the new anchors are lost the doc> manufacturer may be unable to help. > nit: perhaps we refer to the private key portions of the anchors. agreed, changed. > Section 11 > I am somewhat embarassed that I did not previously note that the > mechanism used to generate the domainID needs to be > second-preimage-resistant or an attacker can claim to be a registrar for > a domain that already exists. Right now, that's in: 5.8.2. Calculation of domainID The domainID is a binary value (a BIT STRING) that uniquely identifies a Registrar by the "pinned-domain-cert" If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself). We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to replace it appropriately. > Section 11.2 doc> Although the nonce used by the Pledge in the voucher-request does not doc> require a strong cryptographic randomness, the use of TLS in all of doc> the protocols in this document does. > We discuss the need for strong randomness in the nonce in Section 11.3, > so it's not clear this is actually true. We don't think that the voucher nonce has to be of the same quality as something that goes into a KDF. It is at the level of TCP Sequeunce number, not seed for generating a private key... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [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