[Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-27.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename: draft-ietf-anima-bootstrapping-keyinfra-27.txt Pages : 113 Date: 2019-09-16 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-27 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Eric Vyncke (evyncke) wrote: > - lack of TLS version, I understand your comment. You suggestion to add > some text (justification, clarification, ...) in Section 5.1 about the > TLS version would be a plus (albeit a -27 would be required) but I am > removing my DISCUSS I have included the following text in the two places we specify TLS: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Combining your August 9 and September 3 emails, and removing resolved items. https://tinyurl.com/y2kmjqmm for diffs aginst -26. (also includes changes for Alexey) Submitting -27 in process. Benjamin Kaduk wrote: >> This was asked by Eric as well. >> It's the Subject Key Identifier that we want. >> https://tools.ietf.org/html/rfc5280#section-4.2.1.2 >> >> It's only guaranteed to exist in CA certificates. >> Do you think we can demand that the extension be present in IDevID? > I'm doubtful that we have enough leverage to make that stick. Subsequent discussion with my co-authors has pointed out that the certificate that will be pinned in the voucher (as pinned-domain-cert) is the *domain cert*, that is, the domain's CA. As a CA, will most likely have the right SubjectKeyIdentifier calculated already. We had updated section 5.8.2 in -26 to clarify things. We moved the domainID definition out of the terminology section (which is where the SHA-1 stuff was), to point at 5.8.2, and point to rfc7469, which provides an algorithm agile definition. >> > 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? >> >> so, I can change the word to "can" rather than "is" > (and fix up the grammar, but) sure missing "be" added to section 2.1, point 5. doc> 1. Uniquely identifying the pledge by the Distinguished Name (DN) doc> and subjectAltName (SAN) parameters in the IDevID. The unique doc> identification of a pledge in the voucher objects are derived doc> 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... >> Are you asking for a forward reference to 10.2? I will add this. >> I think that section 10.2 is pretty clear about this. >> I don't think it's mentioned just in passing. > It looks like the main coverage here is: > o the identity of the device being enrolled (down to the serial- > number!). > and the discussion in the last three paragraphs or so. > I do appreciate the importance of distinguishing between the high-end > router and the human users (and we will have a long hard think about it > again when BRSKI profiles for IoT use come through, I'm sure), so thank you > for that. But I'm not sure that we clearly draw the connection to "the > manufacturer knows the identity of the device being enrolled" to "and can > guess where it is, and definitely knows who the owner is, and can > potentially follow that over time if the device has to reenroll". Now, for > the high-end router case there is literally nothing new here -- the vendor > is assumed to already be doing inventory tracking of which customers have > which routers! But I think it's important to make the connection from > "knows identity" to "tracking", since this topic will come up for any use > of BRSKI in other situations. I've tweaked some text, in section 10.3, but I feel I am just moving the chairs around on the Titanic here. doc> 3. Secure auto-discovery of the pledge's MASA by the registrar (see doc> Section 2.8). ben> I don't think this is an ironclad property, since the crypto chain is ben> slightly limited and you are in effect trusting the pledge to hand you ben> something that says "use this issuer" but without as much crypto to back ben> that up as we might want. We have to know that the given manufacturer ben> that signed the IDevID actually is associated with the device we're ben> trying to bootstrap, which can probably be arranged but I don't remember ben> being called out explicitly. mcr> There are two issues here. mcr> One is the question of what is the list of acceptable manufacturers (below). mcr> The second part is whether a pledge could provide a fake IDevID to mcr> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS mcr> has proven that the pledge has the private key corresponding to the mcr> certificate presented. I conclude that an arbitrary IDevID can not be mcr> provided by the Pledge; it has to be linked to SOME manufacturer. Some > Well, it has to be linked to some entity that signed the IDevID. That may > or may not be a manufacturer, but the Registrar does have the capability to > look at what signed the IDevID and apply a whitelist of known, verified, > manufacturers. Yes. Even if we throw full Remote Attestation at the problem, if the Registrar decides to trust Malware Inc. to attest to it's BFR's then it's gonna have
Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-26: (with DISCUSS and COMMENT)
https://tinyurl.com/y2kmjqmm for diff.
Alexey Melnikov via Datatracker wrote:
> --
> DISCUSS:
> --
> Thank you for this document. Despite comments/DISCUSSes raised, this was
a good
> read.
> I agree with DISCUSS points from Alissa, Adam and Roman.
> 1) Resolved
> 2) Resolved
> 3) Resolved
> 4) In 5.8.1:
> Format of different fields is not defined in enough details, so this is
not
> interoperable. Please specify what format is used for dates and nonces.
Date now references rfc3339. (Why doesn't rfc8259 reference 3339?)
The date is in format, which is
consistent with typical JavaScript usage of JSON.
The nonce is a string, as provided in the voucher-request, and
used in the voucher. If no nonce was placed in the resulting
voucher, then a value of null SHOULD be used in preference to
omitting the entry.
While the nonce is often created as a base64 encoded random
series of bytes, this should not be assumed.
> --
> COMMENT:
> --
> Some comments below are still applicable to -26, but some might be out of
date.
> The first mention of HTTP 1.1 needs a Normative reference.
We now refer to HTTP persistent connections, and reference RFC7230 section 6.3.
doc> As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
doc> this extension, including the scheme, iauthority, and ipath. As a
doc> consideration to constrained systems, this MAY be reduced to only the
doc> iauthority, in which case a scheme of "https://; and ipath of
doc> "/.well-known/est" is to be assumed, as explained in section
doc> Section 5.
> This is not a problem per se, but mixing absolute URIs and iauthority in
the
> same field makes me rather uncomfortable. Maybe you can define ABNF for
this
> field to make it crystally clear what is allowed here. This would also
avoid
> the need to use SHOULD and MAY above.
The field contains either:
authority
OR
scheme //: authority / path
As "/" is not legal in authority, which can be deduced, as explained:
The registrar can assume that only the 'authority' is present in the
extension, if there are no slash ("/") characters in the extension.
I'm not sure that ABNF would make it clearer to implementers.
> In 2.3.2: "https" URI scheme needs a Normative reference.
Now references rfc7230 section 2.7.3
> 2.7. 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].
> Just referencing RFC 6125 is not clear enough, as there are lots of
parameters
> that need to be specified:
> a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
> b) are wildcards allowed in any of these?
I don't know, as we haven't defined how the cloud register would work, and
did not intend to define that in this document.
A very drafty draft, draft-friel-anima-brski-cloud-00 has recently been posted.
The only reason we talk about this at all, is that we can it clear how this
option would fit into the pledge state machine. We also say this because we
want to make sure that a built-in trust anchor is used, and not some trust
anchor that might have been received provisionally, or via the /cacerts
EST method.
The pledge would contain the logic to connect, and would know what name to
use, and would know how to validate it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
{clearing out todo items in my inbox}
Joel M. Halpern wrote:
> I presume I am missing something basic.
> I have tried to follow this discussion, as it seems to be about a critical
> aspect of whether the BRSKI work is acceptable.
> I have assumed that what we needed is the ability for a buyer, who has
> physical possession of the device, and possibly some simple (non
> cryptographic) credentials provided by the seller to force the device to
> reset what it thinks it is part of, and to emit in some accessible form
the
> information the buyer needs to be able to make this device part of his
> network, using his authentication servers, etc.
> Have I got the wrong end of the stick?
Joel, you have gotten the resale problem exactly correct.
BRSKI is primarily a protocol for a buyer, who does not wish to be forced
to assert physical possession, to assert ownership of the device.
The #1 reason why they don't want to resort to physical means is that the
local entities possessing ("remote hands") the device don't have the skills
and/or equipment to set the device up.
The #2 reason is that the device is in partial public access, and
it would be a bad thing if the physical possession interface was too easily
accessed. (Bank ATM, Airport checkin kiosk, hotel room interfaces, etc.)
This has been extended to IoT devices.
A third reason is that the devices may be difficult to actually reach
physically due to the structure and activity of the factory/plant/etc. that
they are in. A temperature sensor 50m up a distillation tower in a refinery,
for instance.
The physical mechanisms that make the device hard to physically attack may
also make it hard for the second owner to take control of the device without
the cooperation of the first owners and/or manufacturer.
The current solution in the document is that one should, for enterprise/ISP
equipment that ANIMA applies to, continue to provide the same onboarding
processes that existed prior to ANIMA. Specifically, a "craft" or serial
console.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-26: (with DISCUSS and COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-26: 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: -- Thank you for this document. Despite comments/DISCUSSes raised, this was a good read. I agree with DISCUSS points from Alissa, Adam and Roman. 1) Resolved 2) Resolved 3) Resolved 4) In 5.8.1: Format of different fields is not defined in enough details, so this is not interoperable. Please specify what format is used for dates and nonces. 5) Resolved -- COMMENT: -- Some comments below are still applicable to -26, but some might be out of date. The first mention of HTTP 1.1 needs a Normative reference. In 2.3.2: As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in this extension, including the scheme, iauthority, and ipath. As a consideration to constrained systems, this MAY be reduced to only the iauthority, in which case a scheme of "https://; and ipath of "/.well-known/est" is to be assumed, as explained in section Section 5. This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here. This would also avoid the need to use SHOULD and MAY above. In 2.3.2: "https" URI scheme needs a Normative reference. 2.7. 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]. Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified: a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards allowed in any of these? ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
