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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-minimal-security-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/



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


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