Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Mališa Vučinić <[e-mail]>]

Dear Ben,

Many thanks for the in-depth review. In this email I am responding inline to most of the COMMENT points, in order to converge on those first. For the rest, I created bitbucket issues that we will discuss as part of the WG meeting in Singapore and get back to you.

The resulting changes discussed here can be found at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6>

The list of remaining issues is available at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open>

Mališa


> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
…

> ----------------------------------------------------------------------
> COMMENT:
> ———————————————————————————————————
> 
...

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

done

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

The assumption of the document is really that the authorization is implicit to successful authentication of the pledge. I rephrased as follows:

-Authorization mechanisms are considered out of scope.
-Mutual authentication during network access is achieved through the use of a secure channel, as configured by this document.
+Mutual authentication during network access and implicit authorization are achieved through the use of a secure channel, as configured by this document.

Let me know if that works.

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

The intent of that phrasing was to stress the fact that the end-to-end communication happens between the pledge and the JRC. Here is an attempt to keep that while making it clearer:

-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 pledge then exchanges CoJP messages with the JRC; for this end-to-end communication to happen, messages are forwarded by nodes already part of the 6TiSCH network, called Join Proxies.

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

done


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

It may be used, depending on whether short addresses are used. Here is the proposed text:

+Depending on the configuration, the pledge identifier may also be used after the join process to identify the joined node.

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

This was answered by Michael on the thread with Roman:

+ The PSK MUST be a cryptographically strong key, with at least 128 bits of
+ entropy, indistinguishable by feasible computation from a random uniform
+ string of the same length.

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

-The JRC additionally needs to store the pledge identifier bound to the given PSK.
+To look up the PSK for a given pledge, the JRC additionally needs to store the corresponding pledge identifier.

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

There is a draft draft-ietf-6tisch-enrollment-enhanced-beacon that extends this by defining a new network identifier structure in order to overcome the limitations of IEEE 802.15.4 PAN ID. The attempt in minimal-security was made for the text to be generic enough to cover both cases, the use of PAN ID from IEEE802.15.4 that is indeed inherent to the beacon, as well as the use of this new network identifier defined in 6TiSCH. For this reason, MUST is a requirement for such a structure to be carried within EBs. Does that make sense?

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

No. I replaced the term  “exchanged” with “provisioned” to be consistent with the rest of the text.

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

The advertisement:

-    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.
+    The advertisement step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address.

> 
>   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/

done


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

As discussed by Tero, it is indeed generally true that the pledge will hear multiple EBs. Let me know if you disagree with keeping this text as-is.


> Section 4.2
> 
>   of the keys.  How JP accepts these unprotected frames is discussed in
>   Section 5.
> 
> nit: "the JP”.

done


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

As discussed with Tero and proposed by you, here is the new text:

+When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames at the link layer.
+In order for the join process to be possible, the JP must accept 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.
+It is expected that the lower layer provides an interface to indicate to the upper layer that unsecured frames are being received from a device, and that the upper layer can use that information to make a determination that a join process is in place and the unsecured frames should be processed.
+How the JP makes such a determination and interacts with the lower layer is out of scope of this specification.


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

done


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

-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.
+When the upper layer processing on the pledge is completed and the link-layer keys are configured, the upper layer MUST trigger the security processing of the corresponding frame.


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

done


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

Indeed, we haven’t really considered additional (reverse) proxies between the JP and the JRC but I don’t see a good reason why we should prevent that from happening. For the sake of generality, I rephrased the requirement to read as follows:

-The JRC MUST support extended token lengths, as defined in {{I-D.ietf-core-stateless}}.
+The JRC and any other potential proxy on the JP - JRC path MUST support extended token lengths, as defined in {{I-D.ietf-core-stateless}}.

Let me know if that works.

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

-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.
+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 protected under the same PSK.


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

The former. I rephrased as follows to make it clear:

-A technique that prevents reuse of sequence numbers, detailed in Appendix B.1.1 of {{RFC8613}}, MUST be implemented.
+A technique detailed in Appendix B.1.1 of {{RFC8613}} that prevents reuse of sequence numbers MUST be implemented.

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

After going over the cited paragraph, I found it quite hard to parse. I therefore simplified and shortened the sentences as follows:

-CoJP allows the (6LBR) pledge to request admission into a network managed by the JRC, and for the JRC to configure the pledge with the parameters necessary for joining the network, or advertising it in the case of 6LBR pledge.
+CoJP allows a (6LBR) pledge to request admission into a network managed by the JRC.
+It enables the JRC to configure the pledge with the necessary parameters.

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

I removed that sentence altogether, it seems extraneous to the introductory section on CoJP. Let me know if you disagree.


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

Not sure I understand the proposed resolution fully, the current text already states that “CoAP at (6LBR) pledge” is doing so.. I added “CoAP implementation” to be extra clear but not sure if this is what you meant:

-If the CoAP at (6LBR) pledge declares the message transmission as failure, the (6LBR) pledge SHOULD attempt to join the next advertised 6TiSCH network.
+If the CoAP implementation at (6LBR) pledge declares the message transmission as failure, the (6LBR) pledge SHOULD attempt to join the next advertised 6TiSCH network.

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

How about:

-to join the next advertised 6TiSCH network.
+to join a 6TiSCH network advertised with a different network identifier.

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

Since Parameter Update Response does not carry any CBOR payload, we don’t deal with its error processing in this section. Any errors therein are to be raised by the CoAP stack. I think that the current name of the section “CoJP CBOR Object Processing” is pretty explicit on this but let me know if you feel additional information should be added in the text.


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

Changed to “out of scope” instead of “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?

Good point, replaced “SHOULD" with a "MUST".


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

From what I remember, we did not define a registry for this parameter as any additional values would require an update of the semantics through another document, at which point the additional values for the parameter can be added. Does that make sense?

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

good catch, I removed the “?”. 

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

This is a good catch and the quoted text is in fact a remnant of the state of the document before Section 5.1 was added. Considering the text in Section 5.1, pledge does link-layer security processing of the frame carrying the Join Response message and consequently this parameter. Since the security processing of the frame is already mandated by 5.1, there is no need to discuss it again here. Therefore, I removed the quoted sentences.


>      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/

done


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

Reference added.

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

Absolutely. In minimal-security, this is defined in Section 8.4.3.3 for IEEE 802.15.4 but in case new technologies/values are added, the document in the reference column should contain enough information on how this parameter is set.

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

(Discussed in-depth by Tero on this thread)

> 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/

done

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

-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 ripple of key updates in outward concentric circles around each 6LBR.
+Sending of traffic with the new keys signals to other downstream nodes to switch to their new key, and the effect is that there is a ripple of key updates around each 6LBR.


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

In Section 8.4.3.3 there is already a note that states:

Signaling of different keying modes of {{IEEE802.15.4}} is done based on the parameter values present in a Link_Layer_Key object.

I added the following to clarify further:

+For instance, the value of the key_id parameter in combination with key_addinfo denotes which of the four Key ID modes of {{IEEE802.15.4}} is used and how.

> 
>      encoded first.  Which address is carried is determined from the
>      length of the byte string.
> 
> nit: s/address/address type(s)/

done


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

Yes, the keying material provided by the JRC would need to be marked with an appropriate (non-existing in terms of this specification) key_usage value.


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

I see your point but 6TiSCH nodes typically do not have a real-time clock making the issue you outline less likely. Just in case, I added the following text in 8.4.4.1 in order to make this super clear, let me know if it works:

+Care needs to be taken on how the pledge (joined node) configures the expiration of the lease.
+Since units of the lease_time parameter are in hours after the reception of the CBOR object, the pledge needs to convert the received time to the corresponding absolute slot number in the network.
+The joined node (pledge) MUST only use the absolute slot number as the appropriate reference of time to determine whether the assigned short identifier is still valid.


> 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]

I agree but note that JRC is not aware of the ASN in the network, as it may be residing somewhere in the cloud. ASN is relevant on the node side but I think the text added above stresses this enough. Let me know if you disagree.


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

(https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/69/reiterate-on-oscore-security-properties-in <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/69/reiterate-on-oscore-security-properties-in>)

> 
> 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 second paragraph in the Security Considerations was updated to resolve the comments as follows:

 This document further mandates that the (6LBR) pledge and the JRC are provisioned with unique PSKs.
+While the process of provisioning PSKs to all pledges can result in a substantial operational overhead, it is vital to do so for the security properties of the network.
 The PSK is used to set the OSCORE Master Secret during security context derivation.
 This derivation process results in OSCORE keys that are important for mutual authentication of the (6LBR) pledge and the JRC.
+The resulting security context shared between the pledge (joined node) and the JRC is used for the purpose of joining and is long-lived in that it can be used throughout the lifetime of a joined node for parameter update exchanges.
 Should an attacker come to know the PSK, then a man-in-the-middle attack is possible.

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

done, I used your wording:

+Note that this traffic can only be directed at the JRC so that the JRC needs to be prepared to handle such unsanitized inputs.

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

done

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

(https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/70/discuss-the-use-of-blacklist <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/70/discuss-the-use-of-blacklist>)

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

Not necessarily. If the short identifier is returned as part of the join, the pledge can configure its IPv6 address using that. 


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

That’s correct, we don’t go into this sort of configuration description in minimal-security.

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

Because the assumption is that each network will assign a different short identifier to the pledge, with the identifiers being uncorrelated among networks and therefore not traceable. Does that make sense?



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

(https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/63/indicate-label-validity-for-each-cojp <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/63/indicate-label-validity-for-each-cojp>)


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


Done by Michael on another thread.

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

replaced CBOR with CoJP


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

-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.
+As a consequence, even if a shared PSK is used, the scheme offers a comparable level of security as in the scenario where each pledge is provisioned with a unique PSK.
+In this case, there is still a latent risk of the shared PSK being compromised from the provisioning device, which would compromise all devices in the batch.