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 |