v1.1 8/20/2018 removed concern about "voucher" registry in IANA section. Fixed
in -17 rev of document. It is now a BRSKI registry with a voucher status
telemetry table (perfect). Added NIT about request details though (see NITS
section). Recommended Max/Michael as expert reviewers for new IANA registry
(BRSKI parameters). Removed NITs about down-references (fixed in -17). removed
NIT about Pledge authorization (fixed in -17). v1.0 Original version 7/25/2018
-------------------------------------------------------------------------------
Shepherd writeup for For draft-ietf-anima-bootstrapping-keyinfra-16
Shepherd: Toerless Eckert, tte+ietf@cs.fau.de
> https://www.ietf.org/iesg/template/doc-writeup-qa-style.html of 24 February
2012.
> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?
RFC type requested: Proposed Standard. Correctly indicated in title page
header. This document describes a protocol based on EST/RFC730 run between
nodes of different roles - pledge, registrar, masa, proxy. It is intended to
be useable across all type of networks and requires standardization for
products of all roles from different vendors.
> (2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections: > > Technical Summary:
This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using manufacturer installed X.509
certificate, in combination with a manufacturer's authorizing
service (MASA), 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 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:
This document was called draft-pritikin-anima-bootstrapping-keyinfra before
it was adopted. There was unanimous support for it in favor of adoption and
none against, so this document was adopted by the ANIMA WG in February 2016.
There was ongoing interest in this work posts since its adoption. There was
never any opposition for this work. Since it adoption, a core mechanism of
the work called the voucher was seen as useful that it was forked off into a
separate document, which is now https://www.rfc-editor.org/rfc/rfc8366.txt
after it was determined that there wa interest to not only use it in this
documents protocol BRSKI, but also in draft-ietf-netconf-zerotouch.
This document went through a long and intense document development
period (9 months for individual document period, 28 months for WG
document period). It has been reviewed well and passed last call without
opposition.
> Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus
was particularly rough?
The most important change process was the above mentioned fork of the voucher
text from the document. The concept itself grew through the WG work on the
BRSKI document. BRSKI also inspired derived work in further working groups
There was no noteworthy controversy about items of the document, instead,
optional elements that could have delayed the document where forked off into
future work (e.g. IPinIP proxy).
> Document Quality:
> Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification?
There is a range of existing implementations, and seemingly vendors working
on BRSKI. Here are points from the mail thread opened during WG last call.
Starting with <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> (WG Last Call
on draft-ietf-anima-bootstrapping-keyinfra-15 -> references to code)
Toerless: github.com/cisco/libest supports BRSKI
Brian Carpenter, GRASP part of BRSKI: https://github.com/becarpenter/graspy
Eliot Lear: I have reviewed the document and we have a PoC. I am also aware
of
others that have done PoC code.
Eliot Lear: The 2nd piece of code is not open source and not by Cisco.
Michael Richardson (<1234.1527803470@localhost>):
https://minerva.sandelman.ca/https://github.com/AnimaGUS-minerva
there are two MASA "live" on the Internet, see:
https://minerva.sandelman.ca/metasite/2017/10/25/jokeshop-setup.html
- more technical explanation in his email.
An overview of other efforts inspired or related to BRSKI can be found in
https://www.ietf.org/id/draft-richardson-enrollment-roadmap-02.txt
> Are there any reviewers that merit special mention as having done a thorough
review, e.g., one that resulted in important changes or a conclusion that the
document had no substantive issues? If there was a MIB Doctor, Media Type or
other expert review, what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
The document received numerous detailed reviews during its WG time, including,
but not limited to the reviews by Brian Carpenter and the Shepherd, with the
conclusion that the document has no substantive issues.
There was no dedicated expert review for BRSKI IANA allocation requests.
There was YANG review for Voucher RFC8366 which BRSKI inherits and extends so
BRSKI YANG complies to the YANG review conclusions from RFC8366.
> Personnel:
> Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Toerless Eckert
Responsible Area Director: Ignas Bagdonas
> (3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG. >
First shepherd review from 2017:
https://github.com/anima-wg/anima-bootstrap/tree/master/1706-shepherd-review
Second shepherd review 2018:
https://github.com/anima-wg/anima-bootstrap/blob/master/shepherd-review-2.txt
Shepherd also parrticipated often in the authors ongoing work meeting
and provided input.
Summary: extensive repeated shepherd review, primarily focussed on document
clarity, correct integration with the other ANIMA charter items and various
technical an formalistic details.
> (4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?
No concerns. The document is comprehensive and conclusive.
> (5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.
The shepherd thinks that standard IESG review is appropriate. The three
key areas are OPS and SEC:
Operational complexity review: Baked into the documents goal and WG process:
This document automates often very painfull manual processes (secure device
enrollment), so the WG thinks that the document actually is a solution and
not a perpetrator wrt. operational complexity.
Being in OPS, the design choices by the authors and WG did focus on this
aspect. Pretty much all of the options in the document address the problem of
allowing deployability in different operational environment (specifically
different form of vouchers and discovery).
There was to the memory of the shepherd no prior external (non-WG) SEC review
for BRSKI, but the fundamental new security concept voucher introduced for
BRSKI is already an RFC (8366), which includes a SEC review understanding the
whole concept how the voucher is used in BRSKI. The authors also include
experts of prior security protocol standards (e.g.: RFC7030).
> (6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.
No concerns by the document shepherd or the WG (in the memory of the
shepherd).
> (7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?
Yes. The authors, have confirmed in writing or verbally that they are not
aware of other IPR than what is listed on datatracker:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-anima-bootstrapping-keyinfra
> (8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
The Cisco and Silver Sprint disclosures where brought up by the WG when they
where filed (2014/2016) with no concerns raised. All three IPR where brought
up during Shepherd Writeup when it was it was discovered that the Juniper
IPR had only been disclosed against draft-netconf-zerotouch (which shares the
voucher with BRSKI). Juniper immediately also filed the disclosure against BRSKI
because it might be applicable to BRSKI to. No concerns against the document
processing where raised because of any of the disclosures.
> (9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?
There is broad support for this document. It was reviewed by active WG
participants.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is publicly available.)
No. There was unanimous support for this work and nobody raised any
objections.
> (11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.
This document is now free of officially tracked nits.
There is a small number of other nits discoverded through this shepherd
writeup, the authors have been asked to fix them in the next rev, and this
email is appended at the end of this writeup.
> (12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
The document requires IANA review and YANG doctor review.
Datatracker already shows the included YANG definitions to pass YANG
validation.
> (13) Have all references within this document been identified as either
normative or informative?
Yes.
> (14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?
No.
> (15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the Last
Call procedure.
rfc7228 defined terminology is used in this document and therefore that
document is listed as a normative reference even though it is an informational
document. Shepherd thinks this is appropriate because this documents
terminology is now widely accepted and there is no standard document
alternative for this terminology.
> (16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the abstract,
and discussed in the introduction? If the RFCs are not listed in the Abstract
and Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.
No change to existing RFCs suggested.
> (17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).
The All requests in IANA section are correct correct except for the request
details for the voucherstatustelemetry. See NITs below.
> (18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.
The new registry requested is "BRSKI parameters". Shepherd suggests to list two
volunteering authors as experts: Max Pritkin and Michael Richardson.
> (19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.
YANG definitions in the document where generated by YANG toolchain and
are passing datatracker syntax check. For source of toolchain see:
https://github.com/anima-wg/anima-bootstrap/blob/master/Makefile
NITS:
A) - D) resolved
E) IANA
E.1) The text for for requesting pledgestatustelemtry is ok
(reigstry+table), but i think the text for decribing how the table should
look like is incomplete:
The text is just requesting some initial values(version,...), but no
context associated with it.
A comparable JSON table is requested in rfc7519 section 10.1. In
subsection 10.1.1 is defines the requested registration template,
which include (using current BRSKI terminology): "item", "item description",
"change controller", "specification document(s)".
Resulting registry is in https://www.iana.org/assignments/jwt/jwt.xhtml
I would suggest to amend the IANA section text to match such an example
in spirit. The four columns in rfc7519 look reasonable. IMHO the "item"
and "specification document" are mandatory, "change controller" is
very useful, "description" is nice to have.
E.2) There are two unclear text tags in the PKIX registry text:
EDNOTE (if this is meant to be an AUTH48 or RFC-editor action, please
change tag accordingly).
XXX -