Skip to main content

Constrained Join Protocol (CoJP) for 6TiSCH
draft-ietf-6tisch-minimal-security-15

Revision differences

Document history

Date Rev. By Action
2021-05-14
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-05-11
15 (System) RFC Editor state changed to AUTH48
2021-02-16
15 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-01-26
15 (System) RFC Editor state changed to REF from EDIT
2021-01-26
15 (System) RFC Editor state changed to EDIT from MISSREF
2020-01-09
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-01-09
15 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-01-09
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-12-23
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-12-11
15 (System) IANA Action state changed to In Progress
2019-12-11
15 (System) RFC Editor state changed to MISSREF
2019-12-11
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-12-11
15 (System) Announcement was received by RFC Editor
2019-12-11
15 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-12-11
15 Cindy Morgan IESG has approved the document
2019-12-11
15 Cindy Morgan Closed "Approve" ballot
2019-12-11
15 Cindy Morgan Ballot approval text was generated
2019-12-11
15 Suresh Krishnan IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-12-10
15 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-15.txt
2019-12-10
15 (System) New version accepted (logged-in submitter: Mališa Vučinić)
2019-12-10
15 Mališa Vučinić Uploaded new revision
2019-12-09
14 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss and Comment points!
(Note that there is still ongoing email discussion of just a few
comment points …
[Ballot comment]
Thank you for addressing my Discuss and Comment points!
(Note that there is still ongoing email discussion of just a few
comment points from my previous ballot position.)
2019-12-09
14 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2019-12-05
14 Adam Roach [Ballot comment]
Thanks for addressing my DISCUSS and COMMENT points.
2019-12-05
14 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2019-12-05
14 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss points and also other editorial comments!

Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really …
[Ballot comment]
Thanks for addressing my discuss points and also other editorial comments!

Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really good change!

And thanks for removing the Parameter Update Response message!
2019-12-05
14 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-12-05
14 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss points and also other editorial comments!

Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really …
[Ballot comment]
Thanks for addressing my discuss points and also other editorial comments!

Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really good change!

-----------------
I only leave this old comment in here because it wasn't further discussed:

I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all?
2019-12-05
14 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2019-12-05
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-12-05
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-12-05
14 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-14.txt
2019-12-05
14 (System) New version accepted (logged-in submitter: Mališa Vučinić)
2019-12-05
14 Mališa Vučinić Uploaded new revision
2019-11-12
13 Wesley Eddy Closed request for Telechat review by TSVART with state 'Overtaken by Events'
2019-11-01
13 Barry Leiba [Ballot comment]
Thanks for addressing my DISCUSS.
2019-11-01
13 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2019-10-31
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-10-31
13 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-10-31
13 Alexey Melnikov
[Ballot comment]
I agree with DISCUSSes from Adam and Barry. I think I agree with most of DISCUSS points from Mirja and Ben, but I …
[Ballot comment]
I agree with DISCUSSes from Adam and Barry. I think I agree with most of DISCUSS points from Mirja and Ben, but I reviewed them less attentively.
2019-10-31
13 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-10-31
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I have a couple of comments and nits. …
[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I have a couple of comments and nits. Feel free to ignore all of them.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Please add reference to IEEE Std 802.15.4 at first mention.

-- Section 1 --
It is unclear in this section whether the PSK is per pledge (then hitting a scalability issue) or shared by all pledge (then having huge security risk). Section 3 is clearer on this but the reader would benefit by knowing this in section 1.


-- Section 2 --
Please consider not using "secret key" and "symmetric key" interchangeably. Esp as "secret key" is often used in the context of asymmetric key.

-- Section 3 --
Unsure whether the text about provisionning "Physically, ..." brings anything useful.

-- Section 3 --
Please add references to DHCPv6, GRASP, mDNS.

-- Section 4.2 --
It is unclear whether duplicate address detection should be done.

== NITS ==

-- Section 4 --
Please expand L2 at first mention.

-- Section 6.1.2 --
I am not a native English speaker but I wonder whether the word 'convergecast' is well-known.
2019-10-31
13 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-10-30
13 Benjamin Kaduk
[Ballot discuss]
Thanks for this generally well-written document!  It does a great job at
making these fairly difficult topics accessible to the reader.  I have …
[Ballot discuss]
Thanks for this generally well-written document!  It does a great job at
making these fairly difficult topics accessible to the reader.  I have a
few points that should be fairly easy to address, but do need to be
addressed before the document should advance.

My comment on Section 8.4.4 tries to walk through some scenarios
involving a finite lease time on a short address; as a result of that I
think it's necessary to direct the 6LN to interpret the time in units of
ASN as opposed to wall-clock time.


The "parameter_addinfo" field in Unsupported_Parameter (Section 8.4.5)
feels underspecified to me.  The inline text says that only a subset of
the link-layer key set from the Configuration could be included here,
but how is that formally specified?

The string COJP_MAX_JOIN_ATTEMPTS appears only twice in the text, once
in Section 8.3.1 and again in the table in Section 8.5.  The former text
leaves me confused as to what counts as a "join attempt" for this
purpose, and in particular how it differs from the MAX_RETRANSMIT timer
mentioned in the previous sentence.

I couldn't find a clear statement that any node sending EBs needs to be
prepared to act as a join proxy; Section 4.1 notes that:
                  During the remainder of the join process, the node
  that has sent the EB to the pledge acts as the JP.
but I couldn't find where that was enforced.

I think we may need to say more about how a JP knows that "secExempt" is
in effect (see comment in Section 5), since that affects a critical
piece of the security posture of the network.

Finally, can we discuss whether a 32-bit MIC is the most appropriate
default for the key usage?  I lack the domain background to know how
much impact there is in going to an ENC-MIC64 or ENC-MIC128 scheme.
2019-10-30
13 Benjamin Kaduk
[Ballot comment]
There are some seriously low-hanging fruit for traffic analysis with
some of these messages, e.g., any OSCORE request with 'kid' of "JRC" is …
[Ballot comment]
There are some seriously low-hanging fruit for traffic analysis with
some of these messages, e.g., any OSCORE request with 'kid' of "JRC" is
going to be a parameter update, at present.  If someone wanted to throw
out some chaff and muddle up this traffic analysis, what options are
available to them?

Abstract

  secured by OSCORE.  This specification defines the Constrained Join
  Protocol and its CBOR (Concise Binary Object Representation) data
  structures, and configures the rest of the 6TiSCH communication stack
  for this join process to occur in a secure manner.  Additional

nit: this specification does not "configure the rest of the 6TiSCH
communication stack" directly; perhaps "describes how to configure" is
more appropriate.

Section 1

  This document defines a "secure join" solution for a new device,
  called "pledge", to securely join a 6TiSCH network.  The term "secure
  join" refers to network access authentication, authorization and
  parameter distribution, as defined in [I-D.ietf-6tisch-architecture].
  The Constrained Join Protocol (CoJP) defined in this document handles
  parameter distribution needed for a pledge to become a joined node.
  Authorization mechanisms are considered out of scope.  [...]

If "secure join" includes authorization, but authorization is out of
scope, does this document really define a "secure join" solution?

  [IEEE802.15.4].  The pledge then exchanges CoJP messages with the
  JRC; these messages can be forwarded by nodes already part of the
  6TiSCH network, called Join Proxies.  The messages exchanged allow

nit: I suggest rewording this, as the current wording suggests direct
pledge/JRC communication with subsequent forarding by proxies, whereas
reality is the other way around.

Section 2

  The term "6LBR" is used interchangeably with the term "DODAG root"
  defined in [RFC6550], assuming the two entities are co-located, as
  recommended by [I-D.ietf-6tisch-architecture].

nit: this wording seems to leave open the possibility that 6LBR and
DODAG root are not the same, which is allowed by the architecture
document even if discouraged, but does not tell the reader what happens
to this document's procedures in that case.  It might be easier to say
that this is "on the assumption that the two entities are co-located",
to make it more clear that this document does not apply to that case at
all.

Section 3

  o  pledge identifier.  The pledge identifier identifies the (6LBR)
      pledge.  The pledge identifier MUST be unique in the set of all
      pledge identifiers managed by a JRC.  The pledge identifier

I recommend an explicit statement as to whether the pledge identifier is
used after the pledge becomes a joined node or only while a pledge.
(Noting that "while a pledge" does not have to be a contiguous single
block of time, of course.

      pledge MUST be provisioned with a unique PSK.  The PSK SHOULD be a
      cryptographically strong key, at least 128 bits in length,
      indistinguishable by feasible computation from a random uniform
      string of the same length.  How the PSK is generated and/or

[I agree with Roman -- when would the SHOULD be violated?]

  o  Pre-Shared Key (PSK).  A secret cryptographic key shared between
      the (6LBR) pledge and the JRC.  The JRC additionally needs to
      store the pledge identifier bound to the given PSK.  Each (6LBR)

The JRC also needs to be able to look up a PSK given a pledge
identifier, so perhaps it's better to describe the binding as going the
other way (or being bidirectional).

  o  Optionally, a network identifier.  The network identifier
      identifies the 6TiSCH network.  The network identifier MUST be
      carried within Enhanced Beacon (EB) frames.  Typically, the 16-bit

Isn't this an inherent property of EBs and not a new requirement for
minimal-security?  If so, the MUST may not be needed, in favor of
descriptive language.

  o  Optionally, any non-default algorithms.  The default algorithms
      are specified in Section 7.3.3.  When algorithm identifiers are
      not exchanged, the use of these default algorithms is implied.

nit: does this "exchanged" mean something other than the "provisioned"
that introduces this bulleted list?

Section 4

  2.  The pledge configures its link-local IPv6 address and advertises
      it to the JP using Neighbor Discovery.  This step may be omitted
      if the link-local address has been derived from a known unique
      interface identifier, such as an EUI-64 address.

Is it the configuring, the advertisement, or both, that is omitted when
derived from a known unique IID?

  As other nodes in the network, the 6LBR node may act as the JP.  The
  6LBR may in addition be co-located with the JRC.

nit: I think s/As/As for/

Section 4.1

  using the cells contained in the EB.  The pledge can hear multiple
  EBs; the selection of which EB to use is out of the scope for this
  document, and is discussed in [RFC7554].  Implementers should make

nit: This reads as a statement of fact, as if it will universally be
true that the pledge can hear multiple EBs.  I can suggest a specific
rewording if you want, though there should be several possibilities.

Section 4.2

  of the keys.  How JP accepts these unprotected frames is discussed in
  Section 5.

nit: "the JP".

Section 5

  When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames.  The JP accepts these
  unsecured frames for the duration of the join process.  This behavior
  may be implemented by setting the "secExempt" attribute in the IEEE
  Std 802.15.4 security configuration tables.  How the JP learns
  whether the join process is ongoing is out of scope of this
  specification.

This seems like a very important piece of information (whether the join
process is ongoing, i.e., whether to accept and process unauthenticated
frames).  Is it discussed in 802.15.4 or somewhere else?

  means of verifying the authenticity of EB frames.  As an attacker can
  craft a frame that looks like a legitimate EB frame, this opens up a
  DoS vector, as discussed in Section 9.

nit: this (first comma) is a comma splice.

Section 5.1

  the pledge.  The frames should be passed to the upper layer for
  processing using the promiscuous mode of [IEEE802.15.4] or another
  appropriate mechanism.  When the upper layer processing is completed
  and the link-layer keys are configured, the upper layer MUST trigger
  the security processing of the corresponding frame.  Once the

I suggest reiterating whether this upper-layer processing is happening
on the pledge or the JP.

Section 7.1

  This DoS vector on the JP can be mitigated by making the JP act as a
  stateless CoAP proxy, where "state" encompasses the information
  related individual pledges.  The JP can wrap the state it needs to

nit: "related to".

  This DoS vector on the JP can be mitigated by making the JP act as a
  stateless CoAP proxy, where "state" encompasses the information
  related individual pledges.  The JP can wrap the state it needs to
  keep for a given pledge throughout the network stack in a "state
  object" and include it as a CoAP token in the forwarded request to
  the JRC.  The JP may use the CoAP token as defined in [RFC7252], if
  the size of the serialized state object permits, or use the extended
  CoAP token defined in [I-D.ietf-core-stateless], to transport the
  state object.  The JRC MUST support extended token lengths, as
  defined in [I-D.ietf-core-stateless].  Since the CoAP token is echoed

Per [I-D.ietf-core-stateless], the (extended) token is hop-by-hop, so in
addition to the JRC needing to support extended tokens, isn't there in
practice a requirement that either no other proxying than join proxying
occurs or the proxies also support extended tokens?  (I assume this will
~always be the former, since we are expecting to do direct IPv6 from JP
to JRC.)

Section 7.3

  Implementations MUST ensure that multiple CoAP requests, including to
  different JRCs, are properly incrementing the sequence numbers, so
  that the same sequence number is never reused in distinct requests.

I suggest noting that this is also tied to the PSK that the pledge is
attempting to use to secure its communications with the JRC; the
sequence number space would be reset if a different PSK was provisioned
(as might happen if the device was transferred to a different network).

Section 7.3.1

  memory.  A technique that prevents reuse of sequence numbers,
  detailed in Appendix B.1.1 of [RFC8613], MUST be implemented.  Each
  update of the OSCORE Replay Window MUST be written to persistent
  memory.

Just to check: is this mandating specifically the algorithm from
Appendix B.1.1 of RFC 8613 or just some algorithm to do so, of which the
referenced one is one example?

Section 8

  the case of 6LBR pledge.  The JRC may update the parameters at any
  time, by reaching out to the joined node that formerly acted as a
  (6LBR) pledge.  For example, network-wide rekeying can be implemented

nit: the use of the definite article "the" suggests that no parentheses
around "6LBR" were intended, but the next sentence suggests otherwise;
perhaps "the" is better as "a".

  This section specifies how the CoJP messages are mapped to CoAP and
  OSCORE, CBOR data structures carrying different parameters,
  transported within CoAP payload, and the parameter semantics and
  processing rules.

This sentence is pretty hard to parse.  What is the relationship amongst
the items in the comma-separated list?

Section 8.1.1

  Section 7.  If the CoAP at (6LBR) pledge declares the message
  transmission as failure, the (6LBR) pledge SHOULD attempt to join the

nit: I think the language used by RFC 7252 is not quite aligned with
this; if the max retransmissions are hit for a CON message, "the attempt
to transmit the message is canceled and the application process informed
of failure", so perhaps it's not the pledge doing so but rather the CoAP
stack thereupon.  (We do use language regarding the "CoAp
implementation" for the analogous situation in Section 8.2.1 already.)

  next advertised 6TiSCH network.  See Section 7.2 for recommended

nit: "next advertised" could be (mis)interpreted to mean "temporarlly
subsequent EB frame", disregarding all the discussion in Section 4.1
(and RFC 7554).

Section 8.2

Having every joined node act as a CoAP server on its "real" IPv6 address
and claiming the "/j" resource is definitely in conflict with BCP 190,
but let's cover this in Adam's ballot thread.

Section 8.3.1

  When a parameter that cannot be acted upon is encountered while
  processing a CoJP object in a CoAP response (Join Response message),
  a (6LBR) pledge SHOULD reattempt to join.  In this case, the (6LBR)

Is the assumption that the empty 2.04 of a Parameter Update Response
will never encounter an error condition in processing?

Section 8.3.3

  pledge generates locally.  After verifying the join request with the
  new ID Context and the derived OSCORE security context, the JRC
  should consequently take action in mapping the new ID Context with
  the previously used pledge identifier.  How JRC handles this mapping
  is implementation specific.

I understand that this does not need to be specified in this document,
but might there be a need for coordination between the JRC and the
pledge, e.g., to change the PSK between pledge and JRC?  (That would
make it "out of scope of this document" but not
"implementation-specific".)

  The described procedure is specified in Appendix B.2 of [RFC8613] and
  is RECOMMENDED in order to handle the failure events or any other
  event that may lead to the loss of mutable security context
  parameters.  The length of nonces exchanged using this procedure
  SHOULD be at least 8 bytes.

When would this SHOULD be violated?

Section 8.4.1

I do not see IANA registries for (e.g.) the join request 'role' values;
is there any chance that additional values might need to be allocated at
some point?

  Join_Request = {
      ? 1 : uint,                      ; role
      ? 5 : bstr,                      ; network identifier
      ? 8 : Unsupported_Configuration  ; unsupported configuration
  }

"? 5 : bstr" does not seem consistent with the body text that mandates
inclusion of the network identifier.

Section 8.4.2

      contain at least one key.  When a pledge is joining for the first
      time and receives this parameter, before sending the first
      outgoing frame secured with a received key, the pledge needs to
      successfully complete the security processing of an incoming
      frame.  To do so, the pledge can wait to receive a new frame, or
      it can store an EB frame that it used to find the JP and use it
      for immediate security processing upon reception of the key set.

It might be interesting to have some discussion of how this relates to
the time verification discussion in Section 5.1.  (But maybe they're
totally unrelated and it wouldn't.)

      infinity SHOULD be assumed.  Node operating as a JP MAY use
      another mechanism that is out of scope of this specification to
      configure PROBING_RATE of CoAP in the absence of join rate
      parameter from the Configuration object.

nit: s/absence of/absence of a/

Section 8.4.3

  For encoding compactness, the Link_Layer_Key object is not enclosed
  in a top-level CBOR object.  Rather, it is transported as a sequence
  of CBOR elements, some being optional.

Is a reference to draft-ietf-cbor-sequence appropriate?

  o  key_addinfo: Additional information needed to configure the link-
      layer key, encoded as a byte string.  This parameter MAY be
      included.  The processing of this parameter is dependent on the
      link-layer technology in use and a particular keying mode.

Is the reference in the CoJP Key Usage registry going to be expected to
tell me anything I need to know to use key_addinfo, or some other
source?

It seems like the indexing/assignment scheme for key usage values (e.g.,
in Table 3) is going to end up with something of a "combinatorial
explosion" of assignments, with a single codepoint indicating a
combination of five axes of parameters (link layer, cipher, k1 vs k2, k2
as encrypted vs.  authenticated-only, and size of auth tag).  Given the
expected pace of deployment of new algorithms, and the potential
expandability/range of CBOR integer encoding rules, it's probably
tolerable here, though.  I'm not sure how I feel about making a 32-bit
MIC the default, though.

Section 8.4.3.2

  Sending of traffic with the new keys signals to other downstream
  nodes to switch to their new key, and the affect is that there is a

nit: s/affect/effect/

  ripple of key updates in outward concentric circles around each 6LBR.

nit: I suggest avoiding "circles" since the topology is unlikely to be
perfectly regular.

Section 8.4.3.3

I might put a note in here that the contents/lengths of the
Link_Layer_Key fields serve to identify which 802.15.4 Key ID Mode to
use.  The example in Appendix A does make this pretty clear, but not
everyone is going to read the appendices.

      encoded first.  Which address is carried is determined from the
      length of the byte string.

nit: s/address/address type(s)/

  for example.  Pairwise keys could also be derived through a key
  agreement protocol executed between the peers directly, where the
  authentication is based on the symmetric cryptographic material
  provided to both peers by the JRC.  Such a protocol is out of scope
  of this specification.

Would there need to be a key_usage parameter that indicates to perform
such a pairwise key agreement protocol?

Section 8.4.4

I'd like to walk through the lease time with respect to the risk of
key+nonce reuse when a short ID is reassigned.  I see that the units are
given as hours here, but probably it's more relevant to think in terms
of timeslots, so that the lease time is a given number of timeslots
(dependent on the network's parameters, which are fixed constants).
Based on the ASN of the slot in which the CoJP parameters are received,
that means that the lease time specifies a range of ASNs for which this
node is allowed to use the short ID, and a compliant node will not use
the short ID with an ASN outside the range.  Even if the node powers off
and suffers realtime clock skew, when it starts listening again, a valid
EB will give it the current ASN and it will know whether the lease on
the short ID is still valid.  An attacker might replay an old valid) EB
in such a case and get the victim node to send traffic with an old ASN,
but I don't see a way for that to overlap (in terms of nonce reuse) with
any traffic sent by the subsequent recipient of a lease on that short
ID, since the new valid lease will cover a disjoint chunk of ASNs, and
so the nonce would not get reused by the different nodes.
On the other hand, if I relax this logic and have the node just trust
its real-time clock (without doing an ASN computation), then I think
there may be risk of the node going to sleep, suffering clock skew,
coming back online and re-learning the current ASN but erroneously
thinking that its lease is still valid (by wall-clock time) if it does
not do an ASN check.

Section 8.4.4.1

  The JRC MUST ensure that at any given time there are never two same
  short identifiers being used under the same link-layer key.  If the

[as above, the "time" axis that is important is ASN, not wall-clock
time]

Section 9

We should refer to the OSCORE security considerations as also being
relevant for CoJP.  I'm less sure whether we want to say something here
about the security properties of CoJP being dependent on the security
context between pledge and JRC, i.e., the PSK and use of persistent
storage for the mutable state in that security context, since that's
basically inherent to how OSCORE works.  Perhaps it's worth saying
something about how the pledge and JRC share a single security context
for the purpose of joining, and that this context is long-lived (i.e.,
the entire lifetime of the 6LN).

It's probably worth reiterating that while OSCORE provides replay
protection, it does not necessarily provide an indication of "freshness"
in the face of an attacker that can drop/reorder traffic.  We do mention
at least once that a misbehaving JRC could have precomputed a non-fresh
configuration response, and I might reiterate that here as well.  (That
could be relevant if, e.g., the JRC or its key information was
temporarily compromised and control subsequently regained by the
legitimate owner.)

Maybe it's more of an "operational considerations" note than a "security
considerations" one, but I suggest reiterating (e.g., in the second
paragraph) that there is substantial operational overhead in having a
unique PSK between pledge and JRC, but that it is vital to
the security properties of the network to do so.  (This has a fair
amount of overlap with what's already there, so I won't be very put out
if you decline to change anything.)

  The JP forwards the unauthenticated join traffic into the network.  A
  data cap on the JP prevents it from forwarding more traffic than the
  network can handle and enables throttling in case of an attack.  The

It's probably worth noting that this traffic can only be directed at the
JRC, and that the JRC needs to be prepared to handle such unsanitized
input [to a greater extent than ordinary 6LNs].

  Configuration object as it helps pledge fight a DoS attack.  These
  bogus beacons prolong the join time of the pledge, and so the time
  spent in "minimal" [RFC8180] duty cycle mode.  The blacklist
  communicated as part of the CoJP Configuration object helps JP fight
  a DoS attack by a malicious pledge.

nit: The "these" in "These bogus beacons" is probably too far removed
from the referent to be useful; I'd suggest avoiding the pronoun here.

Section 10

I think we should talk about the blacklist in the CoJP Configuration
object, since that's a vector for distributing some potentially
identifying information to a fairly broad audience from the JRC.
Hopefully it's only used for actually malicious nodes, which arguably
don't deserve much in the way of privacy, but it's possible that a more
mundane source of misbehavior could land a node on the blacklist, and I
want to be sure that we consider what the information content of the
blacklist is in that scenario.

  scanning and device-specific vulnerability exploitation.  Since the
  join process occurs rarely compared to the network lifetime, long-
  term threats that arise from using EUI-64 as the pledge identifier
  are minimal.  In addition, the Join Response message contains a short

I suspect I just failed to internalize things properly, but isn't the
pledge identifier used with the network IPv6 prefix to form the global
IPv6 address of the joined node?  So in that sense, using the EUI-64 as
the pledge ID transfers into the long-lived address and the privacy
threats are long-term as well.

  Once the join process completes, the new node uses the short
  addresses for all further layer 2 (and layer-3) operations.  This

My understanding is that this is the usual case but not strictly
required by any protocol spec.

  reduces the aforementioned privacy risks as the short layer-2 address
  (visible even when the network is encrypted) is not traceable between
  locations and does not disclose the manufacturer, as is the case of

Why is it not traceable between locations?

Section 11.1

It feels a little unusual to have a consolidate registry for CoJP
parameters that are used as map labels across different messages, without
some indication of which map labels are valid in which messages.

Section 13.2

I agree with Barry that RFC 8505 is probably more appropriately
categorized as a normative reference, and further suggest doing so for
draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869.

Appendix A

  Response to the correct pledge.  Note that the JP does not possess
  the key to decrypt the CBOR object (configuration) present in the

Nit: this is probably better described as a COSE or OSCORE object than a
CBOR one.

Appendix B

  the compromise of the entire batch.  When using the implementation/
  deployment scheme outlined above, the PSK does not need to be written
  to individual pledges.  As a consequence, even if a shared PSK is
  used, the scheme offers the same level of security as in the scenario
  where each pledge is provisioned with a unique PSK.

I'd be wary of describing this as "the same level of security", since
there does remain the latent risk that the shared PSK is compromised
from the provisioning device.  Something like "a comparable level" is
probably safer (ideally with an explanation of the risk of the PSK
leaking from the provisioning device).
2019-10-30
13 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-10-30
13 Adam Roach
[Ballot discuss]
Thanks to everyone who invested their time in this document. I have one
blocking comment that I believe should be easy to resolve, …
[Ballot discuss]
Thanks to everyone who invested their time in this document. I have one
blocking comment that I believe should be easy to resolve, and one fairly major
comment that should be trivial to fix.

§8.1.1:

>  o  The Uri-Path option is set to "j".

COAP URIs are generally subject to BCP 190 restrictions, which would require
the path to either be provisioned, discovered, or under the ".well-known"
tree. The use of a reserved domain name here may change the rationale; but for
the sake of not establishing a precedent for path squatting in CoAP, this
document needs to clearly explain the rationale of why BCP 190 should not
apply in this case. Alternately, the implied URI can be changed to something
like "coap://6tisch.arpa/.well-known/j"
2019-10-30
13 Adam Roach
[Ballot comment]
>  This document allocates a well-known name under the .arpa name space
>  according to the rules given in [RFC3172].  The …
[Ballot comment]
>  This document allocates a well-known name under the .arpa name space
>  according to the rules given in [RFC3172].  The name "6tisch.arpa" is
>  requested.  No subdomains are expected.  No A, AAAA or PTR record is
>  requested.

Although "No subdomains are expected" is useful text, I don't think it's
sufficient to satisfy RFC 3172's requirements of specifying "the rules for how
the subdomain is administered." I would suggest something like:

"No subdomains are expected, and addition of any such subdomains requires
the publication of an IETF standards-track RFC."
2019-10-30
13 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2019-10-30
13 Roman Danyliw
[Ballot comment]
** Section 3.  Per the definition of the PSK, the text says “The PSK SHOULD  be a cryptographically strong key, at least 128-bits …
[Ballot comment]
** Section 3.  Per the definition of the PSK, the text says “The PSK SHOULD  be a cryptographically strong key, at least 128-bits in length, indistinguishable by feasible computation from a random uniform      string of the same length.

-- Under what circumstances would a MUST not be more appropriate? (i.e., when would one want a cryptographically weak key)?

-- per the “128-bits in length” is that a statement about the actual numbers of bits in the key or a requirement for the key strength?

Section 8.4.2.  Per the “join rate”, how is the average data rate supposed to be calculated?

** Section 8.4.3.1.  Is it fair to say that how the JRC has determined “that the new key has been made available to all” is out of scope for this draft?  If so, it is worth saying explicitly.

** Section 8.4.4.1. Per “If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is eminent”, do you mean s/eminent/imminent/?  If not, could you please clarify what you mean here.

** Section 9.  Per “Many vendors are known to use unsafe practices when generating and provisioning PSKs.”, this is a strong statement (i.e., “many vendors”) to make without supporting evidence.  Either provide citation or weaken the sentence.

** Section 9, Per “As a reminder, recall the well-known problem with Bluetooth headsets with a "0000" pin.”, please provide a citation and short explanation.
2019-10-30
13 Roman Danyliw Ballot comment text updated for Roman Danyliw
2019-10-30
13 Roman Danyliw
[Ballot comment]
** Section 3.  Per the definition of the PSK, the text says “The PSK SHOULD  be a cryptographically strong key, at least 128-bits …
[Ballot comment]
** Section 3.  Per the definition of the PSK, the text says “The PSK SHOULD  be a cryptographically strong key, at least 128-bits in length, indistinguishable by feasible computation from a random uniform      string of the same length.

-- Under what circumstances would a MUST not be more appropriate? (i.e., when would one want a cryptographically weak key)?

-- per the “128-bits in length” is that a statement about the actual numbers of bits in the key or a requirement for the key strength?

Section 8.4.2.  Per the “join rate”, how exactly is the average data rate supposed to be calculated?

** Section 8.4.3.1.  Is it fair to say that how the JRC has determined “that the new key has been made available to all” is out of scope for this draft?  If so, it is worth saying explicitly.

** Section 8.4.4.1. Per “If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is eminent”, do you mean s/eminent/imminent/?  If not, could you please clarify what you mean here.

** Section 9.  Per “Many vendors are known to use unsafe practices when generating and provisioning PSKs.”, this is a strong statement (i.e., “many vendors”) to make without supporting evidence.  Either provide citation or weaken the sentence.

** Section 9, Per “As a reminder, recall the well-known problem with Bluetooth headsets with a "0000" pin.”, please provide a citation and short explanation.
2019-10-30
13 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-10-30
13 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-10-30
13 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-10-30
13 Warren Kumari [Ballot comment]
I'm balloting NoObj because I trust Mirja, Barry to carry the DISCUSS (and Alvaro's good points too). Please also see the OpsDir review.
2019-10-30
13 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-10-30
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-10-30
13 Barry Leiba
[Ballot discuss]
I have some issues with the references here, which should be resolvable simply by making some normative.

RFC 8505 provides terminology as well …
[Ballot discuss]
I have some issues with the references here, which should be resolvable simply by making some normative.

RFC 8505 provides terminology as well as neighbor discovery (in Sections 4.2 and 6), so it seems to me that it should be a normative reference.

As draft-ietf-6tisch-architecture is used for both necessary terminology and concepts, I can’t see how it isn’t normative.  I did find that I had to check it during my review.

In Section 5:
  In an operational 6TiSCH network, all frames MUST use link-layer
  frame security [RFC8180].

This would seem to be a MUST referring to 8180, making that a normative reference as well.  But possibly this might not really be a MUST imposed here, and is instead citing a requirement from elsewhere.  In that case, I would simply remove the word “MUST”, so it is stating a fact, rather than a new requirement.  You might similarly consider the subsequent sentence.  In any case, I do wonder whether  7554 and 8180 should be normative.
2019-10-30
13 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2019-10-30
13 Mirja Kühlewind
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this …
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this part is not sufficient:

Sec 6.1: "The Join Proxy implements a data cap on outgoing
  join traffic through CoAP's congestion control mechanism."

I think this needs an normative requirement here. Congestion control is supposed to avoid network overload but also to make use available resources. The congestion control as currently defined  for CoAP would probably limit the join traffic appropriately (to something like one packet per RTT likely) but CoAP could in theory use any time a different more aggrieve congestion and therefore just relying on congestion control generically doesn't seem to be sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that this can be achieved by congestion control as specified in the base CoAP spec.
Further on there seems to be an implicit requirement that the JP MUST implement rate limit using the PROBING_RATE parameter, however, that is never explicitly spelled out as a normative requirement. However, if this rate is not provided by the JRC, it doesn't seem that any rate limiting has to be enforced. So maybe it would be good to be more strict here.


2) Also, not  sure if this editorial or a real issue but I'm not sure I fully understand this sentence:

Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
  forwarded should set it to zero so that it is compressed out."
If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. I guess it's not a big issue and setting to zero seems fine as well but I'm afraid I don't understand the intent here and when exactly the Proxy is supposed to set to AF43 or bleach.


3) This may also be mostly editorial but just to be sure: Section 7.2 provides default values for some of the CoAP transport parameter (where 2 of 3 are the same as defined in RFC7252) but not for all. Why is that?


4 ) And then finally on references (again):
Given that use of I-D.ietf-core-stateless is recommend, I believe it should be normative (and wait for publication of that doc).
2019-10-30
13 Mirja Kühlewind
[Ballot comment]
I'm putting this one question in the comments section because there is no concern that it does not work as specified but I …
[Ballot comment]
I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all?


And some minor comments (mostly editorial proposals):

0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document title to make clear that this is a protocol spec and not "only" and abstract framework or something...

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED."
And then at the end of that paragraph: "This parameter MUST be provisioned to the 6LBR pledge."+

2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
"The JP operates as the application-layer proxy."
Maybe "... operates as an application-layer proxy" or probably even better "operates as application-layer proxy" ? Also at this part of the document it is not clear that the proxy actually interprets the CoAP message. I recommend to mention this earlier in the doc and maybe add a forward reference to section 7.

3) Sec 5: Maybe just to be absolutely clear:
OLD: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames."
NEW: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames at the link layer."

4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional
  network interface ..."
MAYBE: "As a special case, the 6LBR pledge may have an additional
  network interface ..." ?
2019-10-30
13 Mirja Kühlewind Ballot comment and discuss text updated for Mirja Kühlewind
2019-10-30
13 Alvaro Retana
[Ballot comment]
I have a couple of important issues I want to bring up.  I don't think they raise to the level of a DISCUSS, …
[Ballot comment]
I have a couple of important issues I want to bring up.  I don't think they raise to the level of a DISCUSS, but would like to talk about them before the document is published.

(1) What is the relationship between this document and rfc8180?  Both documents define "minimal" operation in a 6TiSCH network.  This document seems to build on rfc8180.  Should it formally Update it?  Should it also be a BCP?

One aspect that jumps at me is the fact that both documents declare key distribution/provisioning out of scope.  rfc8180 describes the behavior of a Joining Node (which I interpret to be the same as a pledge) "depending on which key(s) are pre-configured" (§4.6), but this document seems to assume only the case where the "pledge...initially...does not possess the link-layer key(s)" so that "during the join process, the pledge sends unencrypted and unauthenticated frames." (§5)  Leaving key distribution/provisioning out of scope is fine, but the assumptions of the operation are not congruent.  Given that rfc8180 is a BCP, then it seems that this document doesn't follow the Best Practices or maybe tries to update (?) them with this new minimal security framework.

(2) Normative References

§1: "This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]."  Why are these references not Normative?  If the content of this document is based on the descriptions in those RFCs, I believe they should be.

Also, IEEE802.15.4 seems to be important to understand in a 6TiSCH document.

(3) §5: The Normative keywords in this paragraph are out of place because the specification is already made in rfc8180.  IOW, there's no need to specify here what is already specified elsewhere.

  In an operational 6TiSCH network, all frames MUST use link-layer
  frame security [RFC8180].  The IEEE Std 802.15.4 security attributes
  MUST include frame authenticity, and MAY include frame
  confidentiality (i.e. encryption).
2019-10-30
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-10-29
13 Mirja Kühlewind
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this …
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this part is not sufficient:

Sec 6.1: "The Join Proxy implements a data cap on outgoing
  join traffic through CoAP's congestion control mechanism."

I think this needs an normative requirement here. Congestion control is supposed to avoid network overload but also to make use available resources. The congestion control as currently defined  for CoAP would probably limit the join traffic appropriately (to something like one packet per RTT likely) but CoAP could in theory use any time a different more aggrieve congestion and therefore just relying on congestion control generically doesn't seem to be sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that this can be achieved by congestion control as specified in the base CoAP spec.

Further there seems to be an implicit requirement that the JP MUST implement rate limit using the PROBING_RATE parameter, however that is never explicitly spelled out as a normative requirement. However, if this rate is not provided by the JRC, it doesn't seem that any rate limiting has to enforced. So maybe it would be good to be more strict here.


2) Also, not  sure if this editorial or a real issue but I'm not sure I fully understand this sentence:

Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
  forwarded should set it to zero so that it is compressed out."
If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. I guess it's not a big issue and setting to zero seems fine as well but I'm afraid I don't understand the intent here and when exactly the Proxy is supposed to set to AF43 or bleach.


3) This may also be mostly editorial but just to be sure. Section 7.2 provide default value for some of the CoAP transport parameter (where 2 or 3 are the same as defined in RFC7252) but not for all. Why is that?


4 ) And then finally on references (again):
Given that use of I-D.ietf-core-stateless is recommend, I believe it should be normative (and wait for publication of that doc).
2019-10-29
13 Mirja Kühlewind
[Ballot comment]
I'm putting this one question in the comments section because there is no concern that it does not work as specified but I …
[Ballot comment]
I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all?


And some minor comments (mostly editorial proposals):

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED."
And then at the end of that paragraph: "This parameter MUST be provisioned to the 6LBR pledge."+

2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
"The JP operates as the application-layer proxy."
Maybe "... operates as an application-layer proxy" or probably even better "operates as application-layer proxy" ? Also at this part of the document it is not clear that the proxy actually interprets the CoAP message. I recommend to mention this earlier in the doc and maybe add a forward reference to section 7.

3) Sec 5: Maybe just to be absolutely clear:
OLD: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames."
NEW: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames at the link layer."

4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional
  network interface ..."
MAYBE: "As a special case, the 6LBR pledge may have an additional
  network interface ..." ?
2019-10-29
13 Mirja Kühlewind Ballot comment and discuss text updated for Mirja Kühlewind
2019-10-29
13 Mirja Kühlewind
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this …
[Ballot discuss]
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this part is not sufficient:

Sec 6.1: "The Join Proxy implements a data cap on outgoing
  join traffic through CoAP's congestion control mechanism."

I think this needs an normative requirement here. Congestion control is supposed to avoid network overload but also to make use available resources. The congestion control as currently defined  for CoAP would probably limit the join traffic appropriately (to something like one packet per RTT likely) but CoAP could in theory use any time a different more aggrieve congestion and therefore just relying on congestion control generically doesn't seem to be sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that this can be achieved by congestion control as specified in the base CoAP spec.


2) Also, not  sure if this editorial or a real issue but I'm not sure I fully understand this sentence:

Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
  forwarded should set it to zero so that it is compressed out."
If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. I guess it's not a big issue and setting to zero seems fine as well but I'm afraid I don't understand the intent here and when exactly the Proxy is supposed to set to AF43 or bleach.

3) This may also be mostly editorial but just to be sure. Section 7.2 provide default value for some of the CoAP transport parameter (where 2 or 3 are the same as defined in RFC7252) but not for all. Why is that?


And then finally on reference again:
Given that use of I-D.ietf-core-stateless is recommend, I believe it should be normative (and wait for publication of that doc).
2019-10-29
13 Mirja Kühlewind
[Ballot comment]
Some minor comments (mostly editorial proposals):+

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED." …
[Ballot comment]
Some minor comments (mostly editorial proposals):+

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED."
And then at the end of that paragraph: "This parameter MUST be provisioned to the 6LBR pledge."+

2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
"The JP operates as the application-layer proxy."
Maybe "... operates as an application-layer proxy" or probably even better "operates as application-layer proxy" ? Also at this part of the document it is not clear that the proxy actually interprets the CoAP message. I recommend to mention this earlier in the doc and maybe add a forward reference to section 7.

3) Sec 5: Maybe just to be absolutely clear:
OLD: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames."
NEW: "When sending frames during the join process, the pledge sends
  unencrypted and unauthenticated frames at the link layer."

4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional
  network interface ..."
MAYBE: "As a special case, the 6LBR pledge may have an additional
  network interface ..." ?
2019-10-29
13 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2019-10-29
13 Mirja Kühlewind Requested Telechat review by TSVART
2019-10-28
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-10-28
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-10-28
13 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-13.txt
2019-10-28
13 (System) New version accepted (logged-in submitter: Mališa Vučinić)
2019-10-28
13 Mališa Vučinić Uploaded new revision
2019-10-25
12 Suresh Krishnan IESG state changed to IESG Evaluation from Waiting for Writeup
2019-10-24
12 Amy Vezza Placed on agenda for telechat - 2019-10-31
2019-10-23
12 Suresh Krishnan Ballot has been issued
2019-10-23
12 Suresh Krishnan [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan
2019-10-23
12 Suresh Krishnan Created "Approve" ballot
2019-10-23
12 Suresh Krishnan Ballot writeup was changed
2019-10-18
12 Vijay Gurbani Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list.
2019-10-18
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Hilarie Orman. Submission of review completed at an earlier date.
2019-10-18
12 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Linda Dunbar was marked no-response
2019-10-14
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Hilarie Orman.
2019-10-04
12 Linda Dunbar Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list.
2019-10-04
12 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-10-04
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6tisch-minimal-security-12. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6tisch-minimal-security-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, IANA understands that this document proposes to allocate a well-known name under the .arpa name space according to the rules given in [RFC3172]. IANA understands that the name "6tisch.arpa" is requested. Upon approval of this document by the IESG, the IAB will request the IANA to add the 6tisch subdomain to the .arpa domain in accordance with the provisions of RFS 2860 and RFC 3172.

Second, a new registry is to be created called the Constrained Join Protocol Parameters Registry. The new registry will be located on the IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH) registry page located at:

https://www.iana.org/assignments/_6tisch/

The new registry will be managed via the following registration policies:

Integer values from -256 to 255 are designated as Standards Action.

Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required.

Integer values greater than 65535 are designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

There are initial registrations in the new registry as follows:

+---------------+-------+----------+-------------------+-------------+
| Name | Label | CBOR | Description | Reference |
| | | type | | |
+---------------+-------+----------+-------------------+-------------+
| role | 1 | unsigned | Identifies the |[ RFC-to-be ]|
| | | integer | role parameter | |
| | | | | |
| link-layer | 2 | array | Identifies the |[ RFC-to-be ]|
| key set | | | array carrying | |
| | | | one or more link- | |
| | | | level | |
| | | | cryptographic | |
| | | | keys | |
| | | | | |
| short | 3 | array | Identifies the |[ RFC-to-be ]|
| identifier | | | assigned short | |
| | | | identifier | |
| | | | | |
| JRC address | 4 | byte | Identifies the |[ RFC-to-be ]|
| | | string | IPv6 address of | |
| | | | the JRC | |
| | | | | |
| network | 5 | byte | Identifies the |[ RFC-to-be ]|
| identifier | | string | network | | | | | identifier | |
| | | | parameter | |
| | | | | |
| blacklist | 6 | array | Identifies the |[ RFC-to-be ]|
| | | | blacklist | |
| | | | parameter | |
| | | | | |
| join rate | 7 | unsigned | Identifier the |[ RFC-to-be ]|
| | | integer | join rate |
| | | | parameter | |
| | | | | |
| unsupported | 8 | array | Identifies the |[ RFC-to-be ]|
| configuration | | | unsupported | |
| | | | configuration | |
| | | | parameter | |
+---------------+-------+----------+-------------------+-------------+

Third, a new registry is to be created called the Constrained Join Protocol Key Usage Registry. The new registry will be located on the IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH) registry page located at:

https://www.iana.org/assignments/_6tisch/

The new registry will be managed via the following registration policies:

Integer values from -256 to 255 are designated as Standards Action.

Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required.

Integer values greater than 65535 are designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

There are initial registrations in the new registry as follows:

+-----------------+-----+------------------+-------------+-------------+
| Name | Val | Algorithm | Description | Reference |
| | ue | | | |
+-----------------+-----+------------------+-------------+-------------+
| 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 |[ RFC-to-be ]|
| -ENC-MIC32 | | CCM-128 | for EBs, | |
| | | | ENC-MIC-32 | |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 |[ RFC-to-be ]|
| -ENC-MIC64 | | CCM-128 | for EBs, | |
| | | | ENC-MIC-64 | |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 |[ RFC-to-be ]|
| -ENC-MIC128 | | CCM-128 | for EBs, | |
| | | | ENC-MIC-128 | |
| | | | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 |[ RFC-to-be ]|
| K1K2-MIC32 | | CCM-128 | for EBs, | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 |[ RFC-to-be ]|
| K1K2-MIC64 | | CCM-128 | for EBs, | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 |[ RFC-to-be ]|
| K1K2-MIC128 | | CCM-128 | for EBs, | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 |[ RFC-to-be ]|
| | | CCM-128 | for EBs. | |
| | | | | |
| | | | | |
| 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 |[ RFC-to-be ]|
| | | CCM-128 | for EBs. | |
| | | | | |
| | | | | |
| 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 |[ RFC-to-be ]|
| 8 | | CCM-128 | for EBs. | |
| | | | | |
| | | | | |
| 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 |[ RFC-to-be ]|
| | | CCM-128 | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 |[ RFC-to-be ]|
| | | CCM-128 | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 |[ RFC-to-be ]|
| 8 | | CCM-128 | for DATA | |
| | | | and ACKNOWL | |
| | | | EDGMENT. | |
| | | | | |
| 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- |[ RFC-to-be ]|
| MIC32 | | CCM-128 | MIC-32 for | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- |[ RFC-to-be ]|
| MIC64 | | CCM-128 | MIC-64 for | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
| | | | | |
| 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- |[ RFC-to-be ]|
| MIC128 | | CCM-128 | MIC-128 for | |
| | | | DATA and AC | |
| | | | KNOWLEDGMEN | |
| | | | T. | |
+-----------------+-----+------------------+-------------+-------------+

Fourth, a new registry is to be created called the Constrained Join Protocol Unsupported Configuration Code Registry. The new registry will be located on the IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH) registry page located at:

https://www.iana.org/assignments/_6tisch/

The new registry will be managed via the following registration policies:

Integer values from -256 to 255 are designated as Standards Action.

Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required.

Integer values greater than 65535 are designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

There are initial registrations in the new registry as follows:

+-------------+-------+--------------------------------+-------------+
| Name | Value | Description | Reference |
+-------------+-------+--------------------------------+-------------+
| Unsupported | 0 | The indicated setting is not |[ RFC-to-be ]|
| | | supported by the networking | |
| | | stack implementation. | |
| | | | |
| Malformed | 1 | The indicated parameter value |[ RFC-to-be ]|
| | | is malformed. | |
+-------------+-------+--------------------------------+-------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-10-04
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-10-01
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-10-01
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-10-01
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-10-01
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-09-26
12 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2019-09-26
12 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2019-09-26
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2019-09-26
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2019-09-20
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-09-20
12 Amy Vezza
The following Last Call announcement was sent out (ends 2019-10-04):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, 6tisch@ietf.org, …
The following Last Call announcement was sent out (ends 2019-10-04):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-minimal-security@ietf.org, suresh@kaloom.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Minimal Security Framework for 6TiSCH) to Proposed Standard


The IESG has received a request from the IPv6 over the TSCH mode of IEEE
802.15.4e WG (6tisch) to consider the following document: - 'Minimal Security
Framework for 6TiSCH'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes the minimal framework required for a new
  device, called "pledge", to securely join a 6TiSCH (IPv6 over the
  TSCH mode of IEEE 802.15.4e) network.  The framework requires that
  the pledge and the JRC (join registrar/coordinator, a central
  entity), share a symmetric key.  How this key is provisioned is out
  of scope of this document.  Through a single CoAP (Constrained
  Application Protocol) request-response exchange secured by OSCORE
  (Object Security for Constrained RESTful Environments), the pledge
  requests admission into the network and the JRC configures it with
  link-layer keying material and other parameters.  The JRC may at any
  time update the parameters through another request-response exchange
  secured by OSCORE.  This specification defines the Constrained Join
  Protocol and its CBOR (Concise Binary Object Representation) data
  structures, and configures the rest of the 6TiSCH communication stack
  for this join process to occur in a secure manner.  Additional
  security mechanisms may be added on top of this minimal framework.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-09-20
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-09-20
12 Suresh Krishnan Last call was requested
2019-09-20
12 Suresh Krishnan Last call announcement was generated
2019-09-20
12 Suresh Krishnan Ballot approval text was generated
2019-09-20
12 Suresh Krishnan Ballot writeup was generated
2019-09-20
12 Suresh Krishnan IESG state changed to Last Call Requested from AD Evaluation
2019-07-29
12 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-12.txt
2019-07-29
12 (System) New version approved
2019-07-29
12 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Kris Pister , Jonathan Simon , Malisa Vucinic
2019-07-29
12 Mališa Vučinić Uploaded new revision
2019-07-11
11 Suresh Krishnan IESG state changed to AD Evaluation from Publication Requested
2019-06-21
11 Pascal Thubert

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 …

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.
 

2019-06-21
11 Pascal Thubert Responsible AD changed to Suresh Krishnan
2019-06-21
11 Pascal Thubert IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-06-21
11 Pascal Thubert IESG state changed to Publication Requested from I-D Exists
2019-06-21
11 Pascal Thubert IESG process started in state Publication Requested
2019-06-21
11 Pascal Thubert Tag Revised I-D Needed - Issue raised by WGLC cleared.
2019-06-21
11 Pascal Thubert

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 …

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.
 

2019-06-13
11 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-11.txt
2019-06-13
11 (System) New version approved
2019-06-13
11 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Kris Pister , Jonathan Simon , Malisa Vucinic
2019-06-13
11 Mališa Vučinić Uploaded new revision
2019-06-13
10 Pascal Thubert

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 …

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.



(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.
 

2019-06-13
10 Pascal Thubert

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 …

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.



(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.

(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.
 

2019-06-12
10 Pascal Thubert

Shepherd Write-Upbased on template version dated 24 February 2012.

(1) Type of RFC  being requested: Proposed Standard.

  This draft specifies a security exchange for …

Shepherd Write-Upbased 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 intricates 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.



(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.

(13) Have all references within this document been identified as
either normative or informative?

(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?

(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.

(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.


(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).

(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.

(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.

2019-06-12
10 Pascal Thubert Changed consensus to Yes from Unknown
2019-06-12
10 Pascal Thubert Intended Status changed to Proposed Standard from None
2019-06-12
10 Pascal Thubert IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-04-05
10 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-10.txt
2019-04-05
10 (System) New version approved
2019-04-05
10 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Kris Pister , Jonathan Simon , Malisa Vucinic
2019-04-05
10 Mališa Vučinić Uploaded new revision
2019-03-25
09 Thomas Watteyne Added to session: IETF-104: 6tisch  Mon-1120
2018-11-20
09 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-09.txt
2018-11-20
09 (System) New version approved
2018-11-20
09 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Kris Pister , Jonathan Simon , Malisa Vucinic
2018-11-20
09 Mališa Vučinić Uploaded new revision
2018-11-07
08 Thomas Watteyne Added to session: IETF-103: 6tisch  Thu-1610
2018-11-07
08 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-08.txt
2018-11-07
08 (System) New version approved
2018-11-07
08 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Malisa Vucinic , Kris Pister , 6tisch-chairs@ietf.org, Jonathan Simon
2018-11-07
08 Mališa Vučinić Uploaded new revision
2018-10-22
07 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-07.txt
2018-10-22
07 (System) New version approved
2018-10-22
07 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Malisa Vucinic , Kris Pister , Jonathan Simon
2018-10-22
07 Mališa Vučinić Uploaded new revision
2018-07-18
06 Thomas Watteyne Tag Revised I-D Needed - Issue raised by WGLC set.
2018-07-18
06 Thomas Watteyne IETF WG state changed to In WG Last Call from WG Document
2018-07-17
06 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-07-17
06 Thomas Watteyne Removed from session: IETF-102: 6tisch  Wed-1330
2018-07-17
06 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-07-17
06 Thomas Watteyne Removed from session: IETF-102: 6tisch  Wed-1330
2018-07-17
06 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-05-25
06 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-06.txt
2018-05-25
06 (System) New version approved
2018-05-25
06 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Malisa Vucinic , Kris Pister , Jonathan Simon
2018-05-25
06 Mališa Vučinić Uploaded new revision
2018-03-05
05 Thomas Watteyne Added to session: IETF-101: 6tisch  Wed-1330
2018-03-05
05 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-05.txt
2018-03-05
05 (System) New version approved
2018-03-05
05 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Malisa Vucinic , Kris Pister , Jonathan Simon
2018-03-05
05 Mališa Vučinić Uploaded new revision
2018-03-02
04 Thomas Watteyne Added to session: interim-2018-6tisch-03
2017-11-11
04 Thomas Watteyne Added to session: IETF-100: 6tisch  Mon-1550
2017-10-30
04 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-04.txt
2017-10-30
04 (System) New version approved
2017-10-30
04 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , 6tisch-chairs@ietf.org, Malisa Vucinic , Kris Pister , Jonathan Simon
2017-10-30
04 Mališa Vučinić Uploaded new revision
2017-10-30
03 Pascal Thubert Notification list changed to Pascal Thubert <pthubert@cisco.com>
2017-10-30
03 Pascal Thubert Document shepherd changed to Pascal Thubert
2017-07-18
03 Thomas Watteyne Added to session: IETF-99: 6tisch  Mon-1330
2017-06-15
03 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-03.txt
2017-06-15
03 (System) New version approved
2017-06-15
03 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , Jonathan Simon , Kris Pister , Malisa Vucinic
2017-06-15
03 Mališa Vučinić Uploaded new revision
2017-03-27
02 Pascal Thubert Added to session: IETF-98: 6tisch  Tue-0900
2017-03-12
02 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-02.txt
2017-03-12
02 (System) New version approved
2017-03-12
02 (System) Request for posting confirmation emailed to previous authors: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIc=?= , Kris Pister , 6tisch-chairs@ietf.org, Jonathan Simon
2017-03-12
02 Mališa Vučinić Uploaded new revision
2017-02-02
01 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-01.txt
2017-02-02
01 (System) New version approved
2017-02-02
01 (System) Request for posting confirmation emailed to previous authors: "Kris Pister" , 6tisch-chairs@ietf.org, " malisa.vucinic@st.com" , "Jonathan Simon"
2017-02-02
01 Mališa Vučinić Uploaded new revision
2016-12-14
00 Pascal Thubert This document now replaces draft-vucinic-6tisch-minimal-security instead of None
2016-12-14
00 Mališa Vučinić New version available: draft-ietf-6tisch-minimal-security-00.txt
2016-12-14
00 (System) WG -00 approved
2016-12-14
00 Mališa Vučinić Set submitter to "Malisa Vucinic ", replaces to draft-vucinic-6tisch-minimal-security and sent approval email to group chairs: 6tisch-chairs@ietf.org
2016-12-14
00 Mališa Vučinić Uploaded new revision