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). _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
