Shepherd Write-Up based on template version dated 24 February 2012.
(1) Type of RFC being requested: Proposed Standard.
This draft specifies a security exchange for a one-touch join process
in a 6TiSCH network.
(2) Announcement Write-Up
Technical Summary
This document describes a new Constrained Join Protocol (CoJP) and the
associated framework required for a new device, called "pledge", to
securely join a 6TiSCH network by leveraging a central server, the JRC.
The framework requires that the pledge and the JRC share a symmetric key
before the join process starts (pre-shared key). How this key is
provisioned is out of scope of this document.
Through a single CoAP request-response exchange secured by OSCORE, the
pledge requests admission into the network and the JRC configures it
with link-layer keying material and other parameters.
Join Request and Join Response messages defined for this purpose are to
be used as a generic transport based on CoAP for AKE messages between
the pledge and the JRC, through a Join Proxy. This enables bidirectional
communication of the pledge and the JRC, triggered by the pledge.
What AKE transports within those messages is not very relevant,
be it PSK, RPK or cert-authenticated DH. Once AKE completes and a
shared secret is in place at the pledge and the JRC, the join exchange
from this draft can take place, secured with OSCORE keys derived from
the shared secret.
Working Group Summary
There was a controversy on OSCORE that this draft uses. OSCORE is now
approved by IESG. The draft does not have a dependency on EDHOC.
The chairs launched a second shorted WGLC after IETF 103.
More in https://www.mail-archive.com/6tisch@ietf.org/msg02875.html.
Issues raised by Göran Selander are now solved in -10
More in https://www.mail-archive.com/6tisch@ietf.org/msg02973.html
Document Quality
The protocol is implemented in OpenWSN.
Personnel
Document Shepherd: Pascal Thubert
Responsible Area Director: Suresh Krishnan / Éric Vyncke
(3) The shepherd is not a security expert and delegated that aspect of the
Review to his betters (Göran Selander and Christian Amsüss). The shepherd
focused on integration within the 6TiSCH framework, including 6LoWPAN ND.
Review published as https://www.mail-archive.com/6tisch@ietf.org/msg03039.html
yields no major issue
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No concern; the document is well written and complete
(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 document has intricated INT and SEC work.
We had in-depth security reviews from Göran Selander and Christian Amsüss
as part of the WGLC.
(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 concern to report;
(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, all authors confirmed no knowledge of any IPR
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There was no IPR disclosure, see:
https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-6tisch-minimal-security&submit=draft
(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?
The chairs understand there is a solid consensus for this draft.
(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 such thing.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
No nit
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such thing.
(13) Have all references within this document been identified as
either normative or informative?
They are
(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?
All normative references are published as RFC but one, OSCORE, which
was approved by IESG (draft-ietf-core-object-security).
(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.
The nit tool did not indicate so.
(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, this is not the case
(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 8126).
This specification uses OSCORE and CoAP but does not extend them
and their registries. It creates its own registries with
appropriate names and provides initial settings and RFC 8126 rules
(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.
An expert in the art of 6TiSCH and low-power wireless networking security
(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.
No such thing.