Bootstrapping Remote Secure Key Infrastructures (BRSKI)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Toerless Eckert <email@example.com>, firstname.lastname@example.org, email@example.com, The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Protocol Action: 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' to Proposed Standard (draft-ietf-anima-bootstrapping-keyinfra-41.txt) The IESG has approved the following document: - 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' (draft-ietf-anima-bootstrapping-keyinfra-41.txt) as Proposed Standard This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
Technical Summary This document specifies a mechanism for automated bootstrapping of an Autonomic Control Plane. To do this, a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. Working Group Summary The document has been through two IETF Last Calls as the first one resulted in significant and substantial changes to the proposed mechanisms. Working Group had sufficient interest from the community on evolving the document since 2016. One topic that raised controversy was the reliance of the proposed mechanism on the manufacturer’s identity management systems. The consensus was eventually reached on this topic. Document Quality There are indications of multiple independent implementations available and in progress, both open and closed source. The document went through multiple iterations of WG LCs by the core interest group, has received several directorate and Doctors’ reviews, and went through two IETF wide last calls. Personnel Document Shepherd is Toerless Eckert. Responsible Area Director is Ignas Bagdonas. Suggested IANA Designated Experts for newly created registries are Michael Richardson and Max Pritikin. IANA Note This document requests to add new entries to existing Well-known EST, PKIX, DNS Service Names, and MUD Extensions registries, as well as creating new registry for BRSKI Parameters.
RFC Ed: There are two issues in this document as approved by the IESG: 1: See thread "Post approval updates to draft-ietf-anima-bootstrapping-keyinfra-41" - May 5, 2020 In Figure 11: OLD: [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, ["AN_Proxy", 4, 1, ""], [O_IPv6_LOCATOR, h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] In Figure 12: NEW: [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [["AN_Proxy", 4, 1, ""], [O_IPv6_LOCATOR, h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]] In Figure 12: OLD: [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, ["AN_join_registrar", 4, 255, "EST-TLS"], [O_IPv6_LOCATOR, h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]] ] NEW: [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, [["AN_join_registrar", 4, 255, "EST-TLS"], [O_IPv6_LOCATOR, h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]] ] 2: "another tiny quibble with the BRSKI GRASP examples. They both use the same session ID value (12340815) which is, strictly speaking, a protocol violation. If the second one could be changed to some other value, 51804321 for example, that would be great." -- Brian Carpenter If these could be addressed before it becomes an RFC, that would be great. I'm also not sure if this is the appropriate/best way to annotate documents which the IESG sends to you. I've usually just done it in email, but this seems like it should work better as it is attached to the document...