Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

[Mališa Vučinić]

Hi Christian,

> On 10 Sep 2022, at 12:30, Christian Amsüss  wrote:
> 
> * Do RFCs 9030/9031 allow that a device uses an explicit frame counter,
> which it increments in its own pace?

As mentioned, we’ve made every attempt to make RFC 9031 applicable to non-TSCH 
use cases, as well. Construction of the link-layer nonce is not mentioned in 
RFC 9031 and, as Tero notes, the procedure is defined by IEEE 802.15.4. That 
means that we can use RFC 9031 to distribute the keys with Key Usage set to the 
values from Table 6. The rekeying procedure also does not depend on the common 
notion of time that is specific to 6TiSCH/TSCH, so that also applies.

> 
>  * If yes, shouldn't there be more stern words in 9031 about allowing a
>new key to be used with the same EUI-64 (considering that the device
>may not get a short identifier)?

As Tero notes, this procedure is defined by IEEE 802.15.4 standard: Once a new 
key is provisioned to the device, the device resets its frame counter. 

> 
>(Plus all concerns about the use of OSCORE Appendix B.2 or its
>replacement KUDOS would be relaxed, because if a device can use its
>own frame counter, it could use the same facilities to not lose its
>OSCORE sender sequence number).

I would say that the text on the use of OSCORE Appendix B.2 in RFC 9031 still 
applies for non-TSCH use cases as 8.3.3. talks about a particular case when the 
JRC fails and looses the mutable security context parameters. JRC is not part 
of the mesh and we’ve never considered the JRC hosted at a constrained device. 
That means that the JRC does not follow 802.15.4 security procedures as it is 
likely using another Layer 2 technology.

Mališa

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

[Mališa Vučinić]

> On 20 Sep 2021, at 12:54, Christian Amsüss  wrote:

> I originally thought I'd just take a K1 and K2 and the existing key
> usage table, but these are actually 6TiSCH specific. It'd be quite a
> waste to repeat the 14 modes to say the same about any other MAC
> (especially as using the K1/K2 separation probably makes sense there
> too); maybe the other parameters can skew the semantics. ("If this
> parameter is present, keys are used for 802.15.4 as in the given 6TiSCH-
> key usage, but with the adaptations described in this document").

I guess you refer to the usage of term “EB” i.e. Enhanced Beacon in the 
“Description” column in Table 6, values 0-8? This could have easily been 
replaced with just “Beacon” to keep applicability to the BE mode and/or noted 
with a sentence. I am not familiar with DSME mode, but from a quick glance over 
the 802.15.4-2015 std, I see that DSME uses the term “EB”, as well.

NBE mode obviously doesn’t need any of the usage values where beacons are 
mentioned, but values 9-14 should do it just fine. I might be missing something?

Other than that, there is the term “6TiSCH” used in all the names, but that 
doesn’t seem to be a technical issue.

So yes, I guess noting such details in your dcoument makes sense.

Mališa

smime.p7s
Description: S/MIME cryptographic signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

[Mališa Vučinić]

Hi Christian,

As you could probably see from RFC9031, we did make an attempt to separate 
TSCH-specific from generally-applicable text, but we indeed never instantiated 
it for non-TSCH setups and additional parameters would need to be registered 
and described. I do concur that the biggest challenge I foresee at this point 
is the notion of time.

The use cases you mention are bound to 15.4 radios. Do you see this effort 
potentially useful for other low-power radio technologies?

Mališa

--
Mališa Vučinić
Research Scientist, Inria
Co-chair, IETF LAKE

> On 20 Sep 2021, at 11:13, Christian Amsüss  wrote:
> 
> Hello Michael,
> 
> On Sun, Sep 19, 2021 at 03:48:44PM -0400, Michael Richardson wrote:
>>> have the discussions in the development of CoJP ever sidetracked to its
>>> applicability for non-TSCH setups?
>> 
>> not really.
> 
> thanks, that's good to know too.
> 
>> I think that the CoJP worked very very hard to keep it at one round trip.
>> 
>> This is due to congestion concerns further up the RPL tree.
>> I don't perceive that these other technologies have this problem to the same
>> degree.
> 
> Running 6LoWPAN in other modes could still be RPL-based. The nodes close
> to the BR would still see much traffic, though they might deal with it
> differently than 6TiSCH. (Especially with the simpler modes, I expect
> congestion to even have worse effects than with 6TiSCH).
> 
> Anyhow, there don't appear to be any parts that are particularly hard to
> implement that could be dropped with a less strict one-roundtrip rule,
> so overall it's still a good property.
> 
> I'll explore this further as time permits, and hope to at some point
> come back asking for opinions on a concrete proposal.
> 
> Thanks
> c
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch



smime.p7s
Description: S/MIME cryptographic signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Mališa Vučinić]

Hi Ben,

There has been an extensive discussion on this issue in the WG. As Tengfei 
stated, since MSF operates exclusively at L2, reading DSCP values from the IPv6 
header would constitute a layer violation. It was decided that MSF would 
implement the recommendation from draft-ietf-6tisch-minimal-security by 
recommending the rate limit on DSCP-tagged traffic, at IPv6 layer as outlined 
in Security Considerations. That said, other scheduling functions that may 
operate higher up in the stack, e.g. to establish end-to-end tracks between 
nodes in a mesh, may adhere to this requirement from minimal-security. 
Therefore, for the sake of future scheduling functions that may get 
standardized, it was deemed appropriate to leave the recommendation in 
minimal-security as-is.

Hope that clarifies.

Mališa

> On 24 Mar 2020, at 20:25, Benjamin Kaduk  wrote:
> 
>> There seems to be some "passing the buck" going on with respect to
>> rate-limiting unauthenticated (join) traffic:
>> draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF
>> "SHOULD NOT allocate additional cells as a result of traffic with code
>> point AF43"; this document is implementing a SF, and yet we try to avoid
>> the issue, saying that "[t]he at IPv6 layer SHOULD ensure that this join
>> traffic is rate-limited before it is passed to 6top sublayer where MSF
>> can observe it".  I think we need a clear and consistent story about
>> where this rate-limiting is supposed to happen.
>> 
>>> Thanks for the comments! This has been discussed in some  previous
>>   revision of MSF.
>>> It is not "passing the buck" but a decision based on the scheduling
>>   function and security context.
>>> In the point of avoiding layer violation, the upper layer information
>>   suppose NOT see-able for linker layer where 6P and MSF are.
> 
> If we assume strict layiner so that IP information is not visible to the
> link layer where the scheduling function lives, then isn't that a flaw in
> draft-ietf-6tisch-minimal-security to say that the scheduling function
> should do [something relying on IP-layer information]?
> 
>>> But regarding to security, it seems it is not avoidable.
>>> IMO, the scheduling function is aiming to provide algorithm to
>>   add/remove cell according to traffic.
>>> The traffic could contains unauthenticated  join request from both
>>   normal devices and malicious devices.
>>> The function does NOT have enough information to differentiate them.
>>> We are assuming some other entity out side of MSF needs to resolve this
>>   issue.
> 
> Nonetheless, we're currently not fulfilling a requirement that a SF should
> meet.  If that requirement is unattainable, the requirement should be
> modified or removed; if not, we should attain the requirement.

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] hepherd write up for draft-ietf-6tisch-msf: IPR statement

[Mališa Vučinić]

I’m not aware of any IPR that applies to this draft.

Mališa

> On 12 Dec 2019, at 18:32, Prof. Diego Dujovne  
> wrote:
> 
> “I’m not aware of any IPR that applies to this draft”
> 
> Le jeu. 12 déc. 2019 à 14:31, Pascal Thubert (pthubert)  > a écrit :
> Dear all
> 
>  
> 
> It is time to publish draft-ietf-6tisch-msf, and as part of the process I 
> need to confirm whether there is IPR on this specification.
> 
>  
> 
> Authors: please confirm whether 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. You may for instance answer with 
> “I’m not aware of any IPR that applies to this draft” or indicate a link to 
> an IETF disclosure.
> 
>  
> 
> Others: If you are aware of IPR that encumbers this draft, please reply to 
> this mail with relevant information.
> 
>  
> 
> Note that there’s oner disclosure against the draft already 
> (https://datatracker.ietf.org/ipr/3270/ 
> ). The title of the IPR disclosure is 
> "Cisco's Statement about IPR related to draft-ietf-6tisch-msf"
> 
>  
> 
> Many thanks
> 
>  
> 
> Pascal
> 
>  
> 
> 
> 
> -- 
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl 
> (56 2) 676 8125
> ___
> 6tisch mailing list
> 6tisch@ietf.org 
> https://www.ietf.org/mailman/listinfo/6tisch 
> 
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-15.txt

[Mališa Vučinić]

Dear all,

We’ve just published the -15 revision of the minimal-security document that 
resolves the remaining points from the IESG review.

Mališa

> On 10 Dec 2019, at 10:40, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG 
> of the IETF.
> 
>Title   : Constrained Join Protocol (CoJP) for 6TiSCH
>Authors : Malisa Vucinic
>  Jonathan Simon
>  Kris Pister
>  Michael Richardson
>   Filename: draft-ietf-6tisch-minimal-security-15.txt
>   Pages   : 53
>   Date: 2019-12-10
> 
> 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 describes how to configure 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-15
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-15
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Mališa Vučinić]

I’ve just published -15 incorporating the remaining feedback from your COMMENT 
points. I also moved RFC5869 to normative references, we forgot to do this in 
the previous revision. Take a look and let me know if you see anything out of 
the ordinary.

Mališa

> On 9 Dec 2019, at 19:21, Benjamin Kaduk  wrote:
> 
> Whoops, this got lost in my inbox; thanks for the (out-of-band) reminder.
> Luckily, basically all of it is include in the -14 and looks good, so I
> have very little left to say :)
> 
> On Thu, Nov 07, 2019 at 05:23:37PM +0100, Mališa Vučinić wrote:
>> 
>> Many thanks for the in-depth review. In this email I am responding inline to 
>> most of the COMMENT points, in order to converge on those first. For the 
>> rest, I created bitbucket issues that we will discuss as part of the WG 
>> meeting in Singapore and get back to you.
>> 
>> The resulting changes discussed here can be found at:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6
>>  
>> <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6>
>> 
>> The list of remaining issues is available at:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new=open
>>  
>> <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new=open>
>> 
>> Mališa
>> 
>> 
>>> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker  
>>> wrote:
>> …
>> 
>>> Section 10
>>> 
>>>  scanning and device-specific vulnerability exploitation.  Since the
>>>  join process occurs rarely compared to the network lifetime, long-
>>>  term threats that arise from using EUI-64 as the pledge identifier
>>>  are minimal.  In addition, the Join Response message contains a short
>>> 
>>> I suspect I just failed to internalize things properly, but isn't the
>>> pledge identifier used with the network IPv6 prefix to form the global
>>> IPv6 address of the joined node?  So in that sense, using the EUI-64 as
>>> the pledge ID transfers into the long-lived address and the privacy
>>> threats are long-term as well.
>> 
>> Not necessarily. If the short identifier is returned as part of the join, 
>> the pledge can configure its IPv6 address using that. 
> 
> But it might happen sometimes?  We could probably still mention the privacy
> consideration for that case.
> 
>> 
>>> 
>>>  Once the join process completes, the new node uses the short
>>>  addresses for all further layer 2 (and layer-3) operations.  This
>>> 
>>> My understanding is that this is the usual case but not strictly
>>> required by any protocol spec.
>> 
>> That’s correct, we don’t go into this sort of configuration description in 
>> minimal-security.
> 
> (I was trying to say that "the new node uses the short address for all
> further" is declarative, but may not be 100% true.  That said, this is only
> a COMMENT, so I'm not going to follow up on anything.)
> 
>>> 
>>>  reduces the aforementioned privacy risks as the short layer-2 address
>>>  (visible even when the network is encrypted) is not traceable between
>>>  locations and does not disclose the manufacturer, as is the case of
>>> 
>>> Why is it not traceable between locations?
>> 
>> Because the assumption is that each network will assign a different short 
>> identifier to the pledge, with the identifiers being uncorrelated among 
>> networks and therefore not traceable. Does that make sense?
> 
> Ah, I was reading this as being different locations within the same
> network.  If different locations necessitate different networks, then I
> agree.
> 
>>> Section 13.2
>>> 
>>> I agree with Barry that RFC 8505 is probably more appropriately
>>> categorized as a normative reference, and further suggest doing so for
>>> draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869.
>> 
>> 
>> Done by Michael on another thread.
> 
> (I didn't find discussion of RFC 5869, but may have been sloppy in my
> search.)
> 
> Thanks!
> 
> -Ben

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Mališa Vučinić]

The “join rate” parameter takes care that any single JP at the edge of the 
network does not inject too much traffic. But this traffic is forwarded along 
multiple hops towards the root, and therefore gets aggregated with (join) 
traffic from other JPs in the network. The purpose of the traffic tagging 
mechanism in minimal-security is for such nodes, closer to the DAG root, to 
avoid allocating cells in response to the join traffic.

Mališa

> On 5 Dec 2019, at 17:48, Yasuyuki Tanaka  wrote:
> 
> Why can't the "join rate" avoid such undesired cell allocations? If the join 
> rate is properly configured, incoming join requests don't cause such 
> allocations, do they?

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Mališa Vučinić]

This text should end up in the next version of the MSF draft, as it is the 
scheduling function that triggers 6P to add/delete cells. We added some text on 
it already for the security considerations, what remains to be done is to align 
the MSF algorithm with the requirement of not adapting to tagged traffic.

Mališa

> On 5 Dec 2019, at 15:47, Michael Richardson  wrote:
> 
> 
> Mirja Kuehlewind  wrote:
 I would think it
 either sets it to AF43 or it does nothing about it because DSCP is not
 really used in that network.
>>> 
>>> In 6tisch networks, different DSCP points can be used to get different
>>> behaviours, see  UHM. Let me get back to you on this, because the
>>> reference has evaporated.
> 
>> A reference would be good (in the draft) :-)
> 
> Hi, we had a long discussion about setting DSCP points on upward and downward
> traffic.   We had said that these code point would *not* cause 6P to add 
> bandwidth.
> Where did we say that?   I feel like that the reference has gone away.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Mališa Vučinić]

Dear Adam,

Please note that we have just published a new version of the minimal-security 
document addressing, we believe, all the issues raised in your review. Could 
you take a look?

Thanks.
Mališa

> On 2 Nov 2019, at 22:40, Michael Richardson  wrote:
> 
> 
> Adam Roach  wrote:
>>> How/where should we reference this?
> 
> 
>> Wherever you prefer. If I were editing the document, I would put it as an
>> indented note paragraph directly under the bulleted list in Section 8.1.1;
>> but I defer to your judgement if you think it works better somewhere else.
> 
> I've a paragraph to added it to 8.1.1, and I've clarified that the
> Parameter Update should have a Uri-Host value of 6tisch.arpa.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Mališa Vučinić]

Dear Ben,

We have just published a new version of the minimal-security document 
addressing, we believe, all your remarks. Would you mind checking it out, 
please?

Mališa

> On 19 Nov 2019, at 09:06, Michael Richardson  wrote:
> 
> On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:
>> --
>> 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?
> 
> Any parameter Update Request occurs between the JRC and the 
> already/previously on-boarded device.  So it occurs over the 802.15.4 L2 
> key(s).  It shouldn't visible against other CoAP traffic such as CoAP GET 
> requests of sensor data.
> 
> There are three kinds of traffic that would be seen by a pervasive monitor:
> 
> 1) L2 traffic that is encrypted. It has a src/dst L2 address visible, which 
> is probably an assigned 2-byte "short" address. (Which is assigned by this 
> protocol.)
> 
> 2) Beacons that are authenticated but not encrypted.  Pledges can not 
> authenticate the beacons as they haven't the right key (yet).  Others can, 
> and this lets them sync to the schedule and update their ASN.
> They have an 8-byte source address.
> 
> 3) Join traffic which is not encrypted or authenticated, which has 8-byte 
> source and 8-byte destinations, probably using vendor assigned EUI-64, but 
> could be randomized EUIs.  ALL of this traffic is probably join traffic.  
> Yes, it is easily visible.
> 
> A PM can probably also guess which encrypted traffic relates to the join 
> messages by a simple co-relation of message sizes, but that's not really that 
> new.
> 
> 
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-minimal-security-14: (with COMMENT)

[Mališa Vučinić]

Dear Mirja,

Thank you for the prompt reaction! The Parameter Update Response message has 
been removed in the latest version as it was indeed redundant given that the 
Parameter Update Message is a CoAP CON. Thank you for that remark!

Regards,
Mališa

> On 5 Dec 2019, at 15:30, Mirja Kühlewind via Datatracker  
> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> 
> 
> --
> 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?
> 
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Mališa Vučinić]

Just a quick note on this as I am going through the mails in preparation for 
the WG meeting:

The intended text was to state that the provisioning of the network identifier 
is RECOMMENDED for the pledge, while it is a MUST for the *6LBR* pledge. The 
distinction between 6LBR pledge and pledge is made in the terminology section. 
Here is the change I made in the document to make this clear:

-Provisioning the network identifier is RECOMMENDED.
+Provisioning the network identifier to a pledge is RECOMMENDED.

The excerpt now reads:

"Provisioning the network identifier to a pledge is RECOMMENDED. However, due 
to operational constraints, the network identifier may not be known at the time 
when the provisioning is done. In case this parameter is not provisioned to the 
pledge, the pledge attempts to join one advertised network at a time, which 
significantly prolongs the join process. This parameter MUST be provisioned to 
the 6LBR pledge."

As per 8.4.1, the parameter is mandatory to be included in the CoJP request. 
Pledge obtains its value from the enhanced beacon frames for the network it is 
currently attempting to join, while the 6LBR pledge must have been provisioned 
with it. Let me know if this clarifies.

Mališa

> On 1 Nov 2019, at 22:15, Michael Richardson  wrote:
> 
>> 
>> 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."+
> 
> You are right. The last sentence does not belong.
> During the join process, the network identifer, returned in the CoJP response
> is a MUST (8.4.1)

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Mališa Vučinić]

Dear Ben,

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

The resulting changes discussed here can be found at:

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


The list of remaining issues is available at:

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


Mališa


> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker  
> wrote:
…

> --
> COMMENT:
> ———
> 


> 
> Abstract
> 
>   secured by OSCORE.  This specification defines the Constrained Join
>   Protocol and its CBOR (Concise Binary Object Representation) data
>   structures, and configures the rest of the 6TiSCH communication stack
>   for this join process to occur in a secure manner.  Additional
> 
> nit: this specification does not "configure the rest of the 6TiSCH
> communication stack" directly; perhaps "describes how to configure" is
> more appropriate.

done

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

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

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

Let me know if that works.

> 
>   [IEEE802.15.4].  The pledge then exchanges CoJP messages with the
>   JRC; these messages can be forwarded by nodes already part of the
>   6TiSCH network, called Join Proxies.  The messages exchanged allow
> 
> nit: I suggest rewording this, as the current wording suggests direct
> pledge/JRC communication with subsequent forarding by proxies, whereas
> reality is the other way around.

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

-The pledge then exchanges CoJP messages with the JRC; these messages can be 
forwarded by nodes already part of the 6TiSCH network, called Join Proxies.
+The pledge then exchanges CoJP messages with the JRC; for this end-to-end 
communication to happen, messages are forwarded by nodes already part of the 
6TiSCH network, called Join Proxies.

> 
> Section 2
> 
>   The term "6LBR" is used interchangeably with the term "DODAG root"
>   defined in [RFC6550], assuming the two entities are co-located, as
>   recommended by [I-D.ietf-6tisch-architecture].
> 
> nit: this wording seems to leave open the possibility that 6LBR and
> DODAG root are not the same, which is allowed by the architecture
> document even if discouraged, but does not tell the reader what happens
> to this document's procedures in that case.  It might be easier to say
> that this is "on the assumption that the two entities are co-located",
> to make it more clear that this document does not apply to that case at
> all.

done


> 
> Section 3
> 
>   o  pledge identifier.  The pledge identifier identifies the (6LBR)
>  pledge.  The pledge identifier MUST be unique in the set of all
>  pledge identifiers managed by a JRC.  The pledge identifier
> 
> I recommend an explicit statement as to whether the pledge identifier is
> used after the pledge becomes a joined node or only while a pledge.
> (Noting that "while a pledge" does not have to be a contiguous single
> block of time, of course.

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

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

> 
>  pledge MUST be provisioned with a unique PSK.  The PSK 

Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

[Mališa Vučinić]

Dear Éric,

Many thanks for your review. You can find the responses to your comments inline 
and the overall diff following your review at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14
 


Mališa

> On 31 Oct 2019, at 11:04, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> 
> 
> --
> 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.

done

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

-The configuration defined in this document assumes that the pledge and the JRC 
share a secret cryptographic key, called PSK (pre-shared key).
+The configuration defined in this document assumes that the pledge and the JRC 
share a unique symmetric cryptographic key, called PSK (pre-shared key).

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

I made the change throughout the document to use the term “symmetric key” 
exclusively.


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

If there is no strong opinion here, I left this text for now as in our opinion 
it gives an idea to the reader on how the provisioning can be done.


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

done


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

Section 5.6 of RFC8505 that we reference is clear on this that DAD needs not be 
done for link-local addresses. I added the following sentence to clarify this 
in our draft:

+As per {{RFC8505}}, there is no need to perform duplicate address detection 
for the link-local address.

> 
> == NITS ==
> 
> -- Section 4 --
> Please expand L2 at first mention.

done

> 
> -- Section 6.1.2 --
> I am not a native English speaker but I wonder whether the word 'convergecast'
> is well-known.

rephrased to avoid the use of the term “convergecast”. 

-Due to the convergecast nature of the DODAG, the 6LBR links are often the most 
congested, and from that point down there is progressively less (or equal) 
congestion.
+The 6LBR links are often the most congested within a DODAG, and from that 
point down there is progressively less (or equal) congestion.___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

[Mališa Vučinić]

Dear Alvaro,

Many thanks for your review. I responded to your comments inline and you can 
find the proposed changes in the working version of the document at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/408b01c51282aa2cf04407de2bf6fcf0a4628a95
 


Please let me know if these changes sufficiently respond to your comments.

Mališa

> On 30 Oct 2019, at 15:04, Alvaro Retana via Datatracker  
> wrote:
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> 
> 
> --
> 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.


I think that there is a confusion here around the type of keys used. Keys that 
RFC8180 mentions in Section 4.6 are link-layer keys that according to that 
document can be either pre-configured or “learned during a key distribution 
phase”. The minimal-security document defines that key distribution phase 
through the Constrained Join Protocol (CoJP) and accompanying framework. In 
that context, RFC8180 specifies a more general case allowing for out-of-band 
configuration of link-layer keys, with the minimal-security document defining 
how to obtain the link-layer keys when they are not pre-configured. The 
minimal-security document is consequently written on the assumption that 
“pledge…initially…does not possess the link-layer keys”, but is provisioned 
with a long-term pre-shared key (PSK), used for encryption and authenticity of 
CoJP messages transporting the link-layer keys.

The text in RFC8180 is still valid so I do not believe there is a need for 
minimal-security to update that document. I added the following in Section 3 
attempting to clarify the difference between the PSK and K1/K2 keys from 
RFC8180.

NEW: Note that the PSK is different from the link-layer keys K1 and K2 
specified in {{RFC8180}}. The PSK is a long-term secret used to protect the 
execution of the secure join protocol specified in this document whose one 
output are link-layer keys.

Please let me know if this clarifies.

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

Thanks for the comment, I moved RFC7554, RFC8180 and IEEE802.15.4 to normative 
references.

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

As Barry Leiba proposed in another review, I resolved this comment by removing 
the normative keywords and simply re-stating the requirement 

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-13.txt

[Mališa Vučinić]

Dear all,

The version -13 of the minimal-security draft addresses the received OPSDIR and 
SECDIR reviews, and fixes a couple of nits that were found in the previous 
version related to outdated references and the stateless token draft.

Mališa

> On 28 Oct 2019, at 18:44, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG 
> of the IETF.
> 
>Title   : Minimal Security Framework for 6TiSCH
>Authors : Malisa Vucinic
>  Jonathan Simon
>  Kris Pister
>  Michael Richardson
>   Filename: draft-ietf-6tisch-minimal-security-13.txt
>   Pages   : 50
>   Date: 2019-10-28
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-13
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-13
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Security review of draft-ietf-6tisch-minimal-security-12

[Mališa Vučinić]

Dear Hilarie,
Thank you for going over the document. Please see the responses inline. 
Proposed changes to the working version of the document following your review 
can be found at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8d77145e63531b604a7d4df4197515ffebde0927
 

Kind regards,
Mališa

>Security review of Minimal Security Framework for 6TiSCH
>   draft-ietf-6tisch-minimal-security-12
> 
> Do not be alarmed.  I generated this review of this document as part
> of the security directorate's ongoing effort to review all IETF
> documents being processed by the IESG.  These comments were written
> with the intent of improving security requirements and considerations
> in IETF drafts.  Comments not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
> network) by issuing a request that is validated using pre-shared
> keys.  The document defines the Constrained Join Protocol and its
> data structures.
> 
> The security considerations section has been done well.
> 
> The "short identifier" space consideration on page 34 might be
> problematic under extreme conditions.  If almost all values have
> been used, a set of nodes might cause trouble by constantly
> sending join requests.  The JRC(s) would have to time out their
> previous information, and there might be long delays before a
> short identifier could be freed up.  Perhaps there should be a rate
> limit on join requests from any single node.  (If there is such
> a limit I didn't see it).

On page 26, we define a parameter called “join rate” which sets the rate at 
which a Join Proxy (JP) forwards the requests on behalf of different pledges 
into the network. We discuss the use of join rate also in the Security 
Considerations section where I made the following change to stress the 
applicability of the parameter to the scenario you consider:
OLD: A data cap on the JP prevents it from forwarding more traffic than the 
network can handle.
NEW: 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.
Please let me know if the existing and the amended text sufficiently clarifies 
the use of the join rate parameter.

> 
> Page 20 and page 23 mention "the user", but it is unclear what "user"
> means in this framework.

OLD: ...the (6LBR) pledge SHOULD signal to the user the presence of an error 
condition,...
NEW: ...the (6LBR) pledge SHOULD signal the presence of an error condition,...

> 
> Page 34 says that "the loss of security properties is eminent".  That
> intended word was probably "imminent".  I suggest rephrasing.

Fixed.

> 
> Page 37 asks the reader to recall a "well-known" Bluetooth problem, but
> there is no citation for it.  Either document it or remove it.

Thanks, I removed this sentence as it wasn’t critical for the comprehension of 
the rest of the paragraph.

> 
> Hilarie Orman
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Genart last call review of draft-ietf-6tisch-minimal-security-12

[Mališa Vučinić]

Dear Vijay,

I just wanted to thank you for going over the document, it is much appreciated!

Mališa

> On 18 Oct 2019, at 18:18, Vijay Gurbani via Datatracker  
> wrote:
> 
> Reviewer: Vijay Gurbani
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-6tisch-minimal-security-??
> Reviewer: Vijay K. Gurbani
> Review Date: 2019-10-18
> IETF LC End Date: 2019-10-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is ready for publication as a proposed standard.
> 
> Major issues: 0
> 
> Minor issues: 0
> 
> Nits/editorial comments: 0
> 
> The document is well written; while I am not intimately familiar with the
> 6TiSCH network and the CoAP framework, I read the document as a generalist and
> could not spot much that warrants a comment from that perspective.
> 
> Thanks.
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

[Mališa Vučinić]

Dear Linda,

After a second look, I noticed that the ASN acronym only had a couple of 
occurrences in the text. To address your comment, I replaced the occurrences of 
“ASN" with the expanded version “absolute slot number” without defining the 
acronym in our document. The changes following your review can be found at:

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

Please let me know whether I should go ahead and upload the new version to the 
datatracker.

Mališa

> On 10 Oct 2019, at 18:42, Linda Dunbar  wrote:
> 
> Malisa, 
> 
> Thanks for the changes. 
> 
> I didn't realize that IEEE802.15 uses ASN for completely different purpose 
> than the IETF's ASN. Maybe add a note stating "this ASN is completely 
> different from the BGP's ASN". 
> 
> Linda
> 
> -Original Message-
> From: Mališa Vučinić  <mailto:malisa.vuci...@inria.fr>> 
> Sent: Monday, October 07, 2019 10:39 AM
> To: Linda Dunbar  <mailto:linda.dun...@futurewei.com>>
> Cc: ops-...@ietf.org <mailto:ops-...@ietf.org>; 6tisch <6tisch@ietf.org 
> <mailto:6tisch@ietf.org>>; i...@ietf.org <mailto:i...@ietf.org>; 
> draft-ietf-6tisch-minimal-security@ietf.org 
> <mailto:draft-ietf-6tisch-minimal-security@ietf.org>
> Subject: Re: [6tisch] Opsdir last call review of 
> draft-ietf-6tisch-minimal-security-12
> 
> Dear Linda,
> 
> Many thanks for your review. Please find the responses inline.
> 
> Kind regards,
> Mališa
> 
>> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker  
>> wrote:
>> 
>> Reviewer: Linda Dunbar
>> Review result: Has Nits
>> 
>> Reviewer: Linda Dunbar
>> Review result: Has Nits  & with comment
>> 
>> I am the assigned Ops area reviewer for this draft. The Ops 
>> directorate reviews all IETF documents being processed by the IESG for 
>> the IETF Chair.  Please treat these comments just like any other last call 
>> comments.
>> 
>> This document is written very clear, specifying a framework for a new 
>> device to securely join a 6TiSCH network.
> 
>> 
>> One question: the document assumes that there is pre-shared key (PSK) 
>> between the device and the controller. The Security Consideration does 
>> describe the common pitfall of  a single PSK shared among a group of 
>> devices. Is there any way to prevent it? Is it necessary to require 
>> the Key to be periodically changed?
> 
> Please note that the document mandates unique PSKs between each device and 
> the JRC (Section 3, PSK), thus a compromise of a single device does not leak 
> the PSK of other devices in the network. The discussion you refer to in the 
> Security Consideration section makes an attempt to draw attention to the 
> unsafe practices, but beyond mandating the PSK to be unique for each pledge, 
> which is already a strong requirement, I am not sure we can do much more 
> about it. Requiring the PSK to be periodically changed would require periodic 
> in-situ manipulation of devices (by the 100s or even 1000s), something that 
> is not realistically going to happen…What we could do, however, is to mandate 
> the PSK to be changed upon device re-commissioning to a new owner, when it is 
> likely that a device needs to be manipulated, so I would propose the 
> following sentence be added at the end of Section 3, PSK:
> 
> NEW:
> In case of device re-commissioning to a new owner, it is REQUIRED to change 
> the PSK.
> 
> Would that work?
> 
>> Another  suggestion:
>> Section 5.1 introduces an acronym ASN to represent "Absolute slot number".
>> 
>> Can you use a different acronym because ASN has been widely used in 
>> networking as the Autonomous System Number.
> 
> ASN for "Absolute slot number” was defined in the IEEE 802.15.4 specification 
> and the acronym is widely used in our community. I would refrain from 
> re-defining it as it would cause confusion, given that is already used in 
> other documents produced by the 6TiSCH working group (RFC8180, RFC7554).
> 
>> ---
>> An autonomous system number (ASN) is a unique number that's available 
>> globally to identify an autonomous system and which enables that 
>> system to exchange exterior routing information with other neighboring 
>> autonomous systems.
>> 
>> Thank you.
>> 
>> Linda Dunbar
>> 
>> 
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://na

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

[Mališa Vučinić]

Dear Linda,

Many thanks for your review. Please find the responses inline.

Kind regards,
Mališa

> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker  
> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits  & with comment
> 
> I am the assigned Ops area reviewer for this draft. The Ops directorate 
> reviews
> all IETF documents being processed by the IESG for the IETF Chair.  Please
> treat these comments just like any other last call comments.
> 
> This document is written very clear, specifying a framework for a new device 
> to
> securely join a 6TiSCH network.

> 
> One question: the document assumes that there is pre-shared key (PSK) between
> the device and the controller. The Security Consideration does describe the
> common pitfall of  a single PSK shared among a group of devices. Is there any
> way to prevent it? Is it necessary to require the Key to be periodically
> changed?

Please note that the document mandates unique PSKs between each device and the 
JRC (Section 3, PSK), thus a compromise of a single device does not leak the 
PSK of other devices in the network. The discussion you refer to in the 
Security Consideration section makes an attempt to draw attention to the unsafe 
practices, but beyond mandating the PSK to be unique for each pledge, which is 
already a strong requirement, I am not sure we can do much more about it. 
Requiring the PSK to be periodically changed would require periodic in-situ 
manipulation of devices (by the 100s or even 1000s), something that is not 
realistically going to happen…What we could do, however, is to mandate the PSK 
to be changed upon device re-commissioning to a new owner, when it is likely 
that a device needs to be manipulated, so I would propose the following 
sentence be added at the end of Section 3, PSK:

NEW:
In case of device re-commissioning to a new owner, it is REQUIRED to change the 
PSK.

Would that work?

> Another  suggestion:
> Section 5.1 introduces an acronym ASN to represent "Absolute slot number".
> 
> Can you use a different acronym because ASN has been widely used in networking
> as the Autonomous System Number.

ASN for "Absolute slot number” was defined in the IEEE 802.15.4 specification 
and the acronym is widely used in our community. I would refrain from 
re-defining it as it would cause confusion, given that is already used in other 
documents produced by the 6TiSCH working group (RFC8180, RFC7554).

> ---
> An autonomous system number (ASN) is a unique number that's available globally
> to identify an autonomous system and which enables that system to exchange
> exterior routing information with other neighboring autonomous systems.
> 
> Thank you.
> 
> Linda Dunbar
> 
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Intelligent JP / validating the MASA

[Mališa Vučinić]

Hello Pascal,

The issue that Ben outlines was solved through two separate mechanisms that are 
detailed in draft-ietf-6tisch-minimal-security:

1) The traffic that JP redirects into the network on behalf of unauthenticated 
pledges is tagged using IPv6 DSCP such that it can be distinguished from the 
legitimate network traffic. This allows e.g. the 6tisch scheduling function to 
explicitly ignore the unauthenticated traffic when adapting link resources to 
traffic requirements. This is detailed in Section 6.1 of 
draft-ietf-6tisch-minimal-security.

2) The use of the CoJP “join_rate” parameter that allows the JRC to set the 
rate at which each JP in the network forwards the unauthenticated traffic. This 
mechanism serves as the bandwidth cap for the unauthenticated traffic before it 
is being forwarded into the network. The details are in Section 8.4.2 of 
draft-ietf-6tisch-minimal-security, and there is also a paragraph in the 
Security Considerations detailing the issue.

Mališa

> On 20 Aug 2019, at 18:20, Pascal Thubert (pthubert)  
> wrote:
> 
> Dear all:
>  
> I’m looking for a consensus on how to address the following review comment on 
> the 6TiSCH Architecture by Benjamin:
>  
> > I'd like to see some discussion somewhere that the Join Proxy needs to take 
> > care
> > to not be an open redirector by which an unauthenticated pledge can attack
> > arbitrary network elements (whether within the LLN or on the broader
> > network), e.g., by performing some validation on the claimed MASA 
> > identifier.
> > Similarly, that the JRC will be exposed to lots of untrusted input and 
> > needs to be
> > implemented in an especially robust manner.
>  
> Then again I’d like to discuss the split of what goes in the architecture and 
> what goes in Minimal security or elsewhere.
>  
> What do you think?
>  
> Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] ASN replay attack -- proposed text

[Mališa Vučinić]

Pascal,

As Tero outlined, this information is typically available as the metadata to 
the frame being received. It is up to the implementations to ensure that such 
information is available when processing the frame with a delay, otherwise 
things won’t really work..

Mališa

> On 26 Jul 2019, at 23:20, Pascal Thubert (pthubert)  
> wrote:
> 
> Agreed:
> 
> I'm wondering about the delayed security processing. That processing may be 
> delayed beyond the current ASN. Is the ASN of the receive time attached to 
> the frame as a meta of sorts to enable the delayed validation?
> 
> All the best,
> 
> Pascal
> 
>> -Original Message-
>> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Thomas Watteyne
>> Sent: vendredi 26 juillet 2019 17:08
>> To: Mališa Vučinić 
>> Cc: 6tisch <6tisch@ietf.org>
>> Subject: Re: [6tisch] ASN replay attack -- proposed text
>> 
>> Malisa,
>> The text IMO explains both the problem and the solution very well, congrats.
>> Thomas
>> 
>>> On 26 Jul 2019, at 20:23, Mališa Vučinić  wrote:
>>> 
>>> Dear all,
>>> 
>>> I worked on the initial version of the text describing the ASN replay attack
>> and its resolution discussed during the Montreal meeting.
>>> 
>>> The text can be found at:
>>> 
>>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-
>> security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31
>>> 
>>> Please let me know if you have any comments.
>>> 
>>> Mališa
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-12.txt

[Mališa Vučinić]

Dear all,

This is a version of the minimal-security draft that incorporates the 
resolutions to the two issues discussed during the Montreal meeting: ASN replay 
attack and the usage of different authentication tag lengths with the same CCM 
key.

Mališa

> On 29 Jul 2019, at 17:59, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG 
> of the IETF.
> 
>Title   : Minimal Security Framework for 6TiSCH
>Authors : Malisa Vucinic
>  Jonathan Simon
>  Kris Pister
>  Michael Richardson
>   Filename: draft-ietf-6tisch-minimal-security-12.txt
>   Pages   : 50
>   Date: 2019-07-29
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-12
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-12
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-12
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] ASN replay attack -- proposed text

[Mališa Vučinić]

Dear all,

I worked on the initial version of the text describing the ASN replay attack 
and its resolution discussed during the Montreal meeting.

The text can be found at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31

Please let me know if you have any comments.

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Mališa Vučinić]

f the nonce derives from the short address (e.g., assigned by the JRC) 
> then
> the JRC must ensure that it never assigns short addresses that were 
> already
> given to this or other nodes with the same keys. In other words, the 
> network
> must be rekeyed before the JRC runs out of short addresses.
> 
> 
> These issues is are discussed in more details in 
> .
> 
> 
>  
> All the best,
>  
> Pascal
>  
> From: Mališa Vučinić  
> Sent: jeudi 27 juin 2019 12:48
> To: Pascal Thubert (pthubert) 
> Cc: Michael Richardson ; 6tisch@ietf.org; Tero Kivinen 
> 
> Subject: Re: [6tisch] [secdir] secdir review of 
> draft-ietf-6tisch-architecture-21
>  
> Pascal,
>  
> Before the pledge selects a JP, the text from RFC8180 that is relevant seems 
> to be (Section 6.2):
>  
> When a node joins a network, it may hear EBs sent by different nodes
>already in the network.  The decision of which neighbor to
>synchronize to (e.g., which neighbor becomes the node's initial time-
>source neighbor) is implementation specific.  For example, after
>having received the first EB, a node MAY listen for at most
>MAX_EB_DELAY seconds until it has received EBs from
>NUM_NEIGHBOURS_TO_WAIT distinct neighbors.  Recommended values for
>MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5.
>When receiving EBs from distinct neighbors, the node MAY use the Join
>Metric field in each EB to select the initial time-source neighbor,
>as described in Section 6.3.6 
> <https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4 
> [IEEE.802.15.4 <https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>].
>  
> To me, this text is ambiguous on whether the pledge should duty cycle its 
> radio according to the schedule found in the first received EB. In case the 
> pledge does not duty cycle its radio upon receiving the first EB that happens 
> to be a replay, the attacker cannot really desync the pledge due to its radio 
> being on 100% of the time waiting for additional beacons. Eventually, as 
> Michael noted, one fresh EB will arrive from a legitimate node with a higher 
> ASN, at which point it becomes critical for the pledge to select the JP with 
> the largest available ASN for a given advertised PAN ID. I believe this text 
> deserves expanded discussion in the Security Considerations of 
> minimal-security but I am not convinced on the need for a special mechanism 
> to exchange/sign the ASN.
>  
> Mališa
> 
> 
> On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert)  <mailto:pthub...@cisco.com>> wrote:
>  
> Hello Michael
> 
> Both ASN and sync create event horizons.
> * A wrong ASN will cause MIC processing to fail and the packet will be 
> ignored.
> * If an attacker syncs a pledge outside of the network sync's beyond guard 
> time, the pledge will not even see that legitimate nodes are sending.
> 
> In both cases, a node that believes an attacker has no way to validate ASN 
> right there. It needs an additional one-hop authenticated exchange with a 
> legitimate node with a, e.g., random nonce in payload. Some people will want 
> that step even if the window is narrow. I think we should describe it in 
> archie and in minimal sec.
> 
> 6P or MSF could be used for that purpose when present but cannot be the only 
> way since they are optional.
> 
> All the best,
> 
> Pascal
> 
> 
> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org <mailto:6tisch-boun...@ietf.org>> On 
> Behalf Of Michael Richardson
> Sent: mercredi 26 juin 2019 17:49
> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?=  <mailto:malis...@gmail.com>>
> Cc: Pascal Thubert (pthubert)  <mailto:pthub...@cisco.com>>; 6tisch@ietf.org <mailto:6tisch@ietf.org>; Tero
> Kivinen mailto:kivi...@iki.fi>>
> Subject: Re: [6tisch] [secdir] secdir review of 
> draft-ietf-6tisch-architecture-21
> 
> 
> Mališa Vučinić mailto:malis...@gmail.com>> wrote:
> 
> Mališa Vučinić mailto:malis...@gmail.com>> wrote:
> 
> Instead, as with traditional TSCH, the joined node can obtain its time
> information from its time source neighbor, i.e. RPL preferred parent,
> by triggering an exchange of link-layer frames with L2 security
> features enabled. The MSF draft already mandates that the first
> outgoing message from the joined node after joining is the 6P ADD
> message to its preferred parent, which consequently gets protected
> with
> 
> L2 security.
> 
> But, how can the L2-security work if the newly-joined node has an
> ancient
> 
> ASN?  Won't the parent just drop the packet as being a replay, a

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Mališa Vučinić]

Pascal,

Before the pledge selects a JP, the text from RFC8180 that is relevant seems to 
be (Section 6.2):

When a node joins a network, it may hear EBs sent by different nodes
   already in the network.  The decision of which neighbor to
   synchronize to (e.g., which neighbor becomes the node's initial time-
   source neighbor) is implementation specific.  For example, after
   having received the first EB, a node MAY listen for at most
   MAX_EB_DELAY seconds until it has received EBs from
   NUM_NEIGHBOURS_TO_WAIT distinct neighbors.  Recommended values for
   MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5.
   When receiving EBs from distinct neighbors, the node MAY use the Join
   Metric field in each EB to select the initial time-source neighbor,
   as described in Section 6.3.6 
<https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4 
[IEEE.802.15.4 <https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>].

To me, this text is ambiguous on whether the pledge should duty cycle its radio 
according to the schedule found in the first received EB. In case the pledge 
does not duty cycle its radio upon receiving the first EB that happens to be a 
replay, the attacker cannot really desync the pledge due to its radio being on 
100% of the time waiting for additional beacons. Eventually, as Michael noted, 
one fresh EB will arrive from a legitimate node with a higher ASN, at which 
point it becomes critical for the pledge to select the JP with the largest 
available ASN for a given advertised PAN ID. I believe this text deserves 
expanded discussion in the Security Considerations of minimal-security but I am 
not convinced on the need for a special mechanism to exchange/sign the ASN.

Mališa

> On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert)  
> wrote:
> 
> Hello Michael
> 
> Both ASN and sync create event horizons.
> * A wrong ASN will cause MIC processing to fail and the packet will be 
> ignored.
> * If an attacker syncs a pledge outside of the network sync's beyond guard 
> time, the pledge will not even see that legitimate nodes are sending.
> 
> In both cases, a node that believes an attacker has no way to validate ASN 
> right there. It needs an additional one-hop authenticated exchange with a 
> legitimate node with a, e.g., random nonce in payload. Some people will want 
> that step even if the window is narrow. I think we should describe it in 
> archie and in minimal sec.
> 
> 6P or MSF could be used for that purpose when present but cannot be the only 
> way since they are optional.
> 
> All the best,
> 
> Pascal
> 
>> -Original Message-
>> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
>> Sent: mercredi 26 juin 2019 17:49
>> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= 
>> Cc: Pascal Thubert (pthubert) ; 6tisch@ietf.org; Tero
>> Kivinen 
>> Subject: Re: [6tisch] [secdir] secdir review of 
>> draft-ietf-6tisch-architecture-21
>> 
>> 
>> Mališa Vučinić  wrote:
>>>> Mališa Vučinić  wrote:
>>>>> Instead, as with traditional TSCH, the joined node can obtain its time
>>>>> information from its time source neighbor, i.e. RPL preferred parent,
>>>>> by triggering an exchange of link-layer frames with L2 security
>>>>> features enabled. The MSF draft already mandates that the first
>>>>> outgoing message from the joined node after joining is the 6P ADD
>>>>> message to its preferred parent, which consequently gets protected
>> with
>>>>> L2 security.
>>>> 
>>>> But, how can the L2-security work if the newly-joined node has an
>> ancient
>>>> ASN?  Won't the parent just drop the packet as being a replay, and then
>> what?
>> 
>>> Yes, so the node will desynchronize eventually, fall out of network and
>>> restart the join process, hopefully with a different network.
>> 
>> hmm.   Or, it sees a new beacon, which it can integrity check, and then sees
>> the ASN jump forward.  This would be the same as if it had slept for awhile.
>> 
>> Unless the attacker can continuously *block* the node from seeing the latest
>> beacons, and continuously feeds it old beacons, the problem should go away.
>> 
>> So maybe this is really not as a big a deal as I thought.
>> 
>>>>> What needs to be specified clearly is that this first 6P
>>>>> exchange should not be encrypted but only authenticated at L2.
>>>>> Upon successful completion of the first 6P exchange with its time
>> (routing)
>>>>> parent, the joined node obtains a negotiated cell and as a side effect
>>>>> proves f

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Mališa Vučinić]

> On 25 Jun 2019, at 17:36, Michael Richardson  wrote:
> 
> 
> Mališa Vučinić  wrote:
>> Instead, as with traditional TSCH, the joined node can obtain its time
>> information from its time source neighbor, i.e. RPL preferred parent,
>> by triggering an exchange of link-layer frames with L2 security
>> features enabled. The MSF draft already mandates that the first
>> outgoing message from the joined node after joining is the 6P ADD
>> message to its preferred parent, which consequently gets protected with
>> L2 security.
> 
> But, how can the L2-security work if the newly-joined node has an ancient
> ASN?  Won't the parent just drop the packet as being a replay, and then what?

Yes, so the node will desynchronize eventually, fall out of network and restart 
the join process, hopefully with a different network. 

>> What needs to be specified clearly is that this first 6P
>> exchange should not be encrypted but only authenticated at L2.
>> Upon successful completion of the first 6P exchange with its time (routing)
>> parent, the joined node obtains a negotiated cell and as a side effect
>> proves freshness of the ASN used.
> 
> I'd rather that we added a new exchange, rather than special casing some 6P
> interaction here.   An RPL DIS would be a better choice here, I think, with
> an RPL DAO unicast reply.  Still, I hate to special case this as being
> authenticated only.
> Doesn't that have to happen first?

Whatever packet we send here, be it DIS or 6P, they need to have special 
handling in terms of L2 security… Is DIS mandatory to send upon preferred 
parent selection?

> 
> Is the DIS unicast or multicast. Hmm.
> How do we put something unique in it that has to be replied to proving the
> freshness of the ASN against a reply attack.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Mališa Vučinić]

Pascal, Tero,

The issue raised seems valid and going through minimal-security and the MSF 
draft it seems that some clarification is needed. We purposely avoided keeping 
the network notion of time at the JRC in order to facilitate deployments where 
JRC is outside of the local network and is managing multiple 6tisch networks. I 
do not believe we want to change that, as it would be quite challenging to 
require the synchronization of the JRC with each 6tisch network. 

Instead, as with traditional TSCH, the joined node can obtain its time 
information from its time source neighbor, i.e. RPL preferred parent, by 
triggering an exchange of link-layer frames with L2 security features enabled. 
The MSF draft already mandates that the first outgoing message from the joined 
node after joining is the 6P ADD message to its preferred parent, which 
consequently gets protected with L2 security. What needs to be specified 
clearly is that this first 6P exchange should not be encrypted but only 
authenticated at L2. Upon successful completion of the first 6P exchange with 
its time (routing) parent, the joined node obtains a negotiated cell and as a 
side effect proves freshness of the ASN used. 

What seems missing is some text in minimal-security adding guidance for other 
scheduling function and stressing this issue beyond the text in the last 
paragraph of Section 9 of draft-ietf-6tisch-minimal-security-11 that is rather 
vague.

Mališa

> On 25 Jun 2019, at 09:29, Pascal Thubert (pthubert)  
> wrote:
> 
> Hello Malisa:
> 
> I went through the security section of minimal-security and found that the 
> text below would be useful there to. Alt a pointer to the security section of 
> the architecture would do once I incorporate some of the below.
> (Though I thought it did at a time) minimal-security does not indicate that 
> the JRC should be aware of the network ASN to enable the protection that Tero 
> is discussing below, does it?
> 
> All the best,
> 
> Pascal
> 
> 
> 
>> -Original Message-
>> From: David Mandelberg 
>> Sent: mardi 25 juin 2019 02:31
>> To: Tero Kivinen ; Pascal Thubert (pthubert) 
>> 
>> Cc: sec...@ietf.org; i...@ietf.org; 
>> draft-ietf-6tisch-architecture@ietf.org;
>> Thomas Watteyne ; Michael Richardson 
>> ; Mališa Vučinić 
>> Subject: Re: [secdir] secdir review of 
>> draft-ietf-6tisch-architecture-21
>> 
>> 
>> 
>> On 6/24/19 7:45 PM, Tero Kivinen wrote:
>>> Pascal Thubert (pthubert) writes:
>>>> Hello David:
>>>> 
>>>> Many thanks for your review. I do hope that you found it interesting.
>>>> 
>>>>> Sections 4.2.1 and 4.3.4 talk about the security of joining a 
>>>>> network, and time synchronization, respectively. Do any of the 
>>>>> security mechanisms in 4.2.1 rely on having an accurate clock?
>>>>> (E.g., to distrust old/expired keys.) Is time synchronization done 
>>>>> before the join process, and is there any way to exploit time 
>>>>> synchronization in order to cause a node to join a malicious 
>>>>> network?
>>>> 
>>>> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who 
>>>> was one of the inventors of TSCH, as well as Michael and Malisa who 
>>>> led the join process study.
>>>> 
>>>> Time synchronization (date):
>>>> --
>>>> For all I know, the time sync is about giving a epoch time from 
>>>> which an Absolute Slot Number (ASN, expressed in slot duration 
>>>> e.g.,
>>>> 10ms) is derived. ASN plays a key role as it is used in NONCE. An 
>>>> attack that one could think of would be to fool the new node into 
>>>> thinking that ASN is earlier. This could happen before the keys are 
>>>> exchanged, or if an authorized peer is compromised. For the former, 
>>>> I'll defer to the others to answer fully how we protect the new 
>>>> comer. For the latter, 6TiSCH provides an additional protection 
>>>> since we derive time from a RPL parent. RPL has its own 
>>>> protections, some of them in the standard itself, some of them in 
>>>> zerotrust papers that need publishing.
>>> 
>>> In normal TSCH in 802.15.4 the joining node will listen to beacons 
>>> sent by the nodes already part of the network, and they will find 
>>> out the ASN from there. As they do not yet have keys for the network 
>>> they cannot verify the message integrity code authenticating the 
>>> beacon, and even if they did have the keys, they still cannot verify 

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-11.txt

[Mališa Vučinić]

Dear all,

The version -11 of minimal-security resolves comments raised in the shepherd’s 
review, thanks Pascal.

Mališa


> On 13 Jun 2019, at 17:42, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG 
> of the IETF.
> 
>Title   : Minimal Security Framework for 6TiSCH
>Authors : Malisa Vucinic
>  Jonathan Simon
>  Kris Pister
>  Michael Richardson
>   Filename: draft-ietf-6tisch-minimal-security-11.txt
>   Pages   : 49
>   Date: 2019-06-13
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-11
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-11
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] shepherd review of draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Hello Pascal,

Thanks for the review. See resolutions and some comments inline.

Mališa


> On 12 Jun 2019, at 11:54, Pascal Thubert (pthubert)  
> wrote:
> 
> Dear authors;
>  
> As part of shepherding the draft for publication, please find review comments 
> below:
>  
> Very well written draft altogether! A few things still:
>  
>  
> Section 4.2:
> “ The pledge MAY perform the Neighbor
>Solicitation / Neighbor Advertisement exchange with the JP, as per
>Section 5.5.1 of [RFC6775] 
> . 
> “
>  
> This reference is outdated. I suggest referring to section 5.6.  of [RFC8505].

Fixed, see resolution at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/c9bbe0efbe4
 


>  
>  
> Section 6:
>  
> Again a ref to RFC 6775. In  a general manner please use RFC 8505.

See above.

>  
>  
>“The JRC can be co-located on the 6LBR.  In this special case, the
>IPv6 address of the JRC can be omitted from the Join Response message
>for space optimization.  The 6LBR then MUST set the DODAGID field in
>the RPL DIOs [RFC6550 ] to its IPv6 
> address.  The pledge learns the
>address of the JRC once joined and upon the reception of the first
>RPL DIO message, and uses it to operate as a JP.”
>  
> Note that the expectation is that the 6LBR is the RPL root as suggested in 
> the 6TiSCH architecture.
> When they are not the same box I expect the all the text about 6LBR 
> throughout this doc is really about the RPL root.
> This should be indicated somewhere.

In Section 2, there is a sentence stating:

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


IMO this makes it clear that we assume they are the same box but let me know if 
this is not the case for you.


> Section 6.1:
> There are a number of SHOULD there, but no explanation of what happens if the 
> SHOULD is not respected.
> Maybe a sentence that says that the SHOULDs are about protecting the network 
> against the threats discussed in the section and that failing to follow the 
> recommendation may create congestion and more sensitivity to attacks?

You are right, the SHOULDs are poorly elaborated, mostly due to the fact that 
the attack they protect against is explained beforehand. As suggested, I added 
a sentence to reference the attack description:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/91830c80f0cc
 

 


I also fixed a couple of nits in the IANA considerations, the commit is at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/673105a5e4
 



The overall diff is available at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-11#diff
 

 

Let me know if these resolutions work for you and I will publish -11.

Mališa

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] shepherd write up for draft-ietf-6tisch-minimal-security: IPR statement

[Mališa Vučinić]

I’m not aware of any IPR that applies to this draft.

Mališa

> On 12 Jun 2019, at 10:39, Pascal Thubert (pthubert)  
> wrote:
> 
> Dear all
>  
> It is time to publish draft-ietf-6tisch-minimal-security, and use part of the 
> process I need to confirm whether there is IPR on this specification.
>  
> Authors: please confirm whether 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. You may for instance answer with 
> “I’m not aware of any IPR that applies to this draft” or indicate a link to 
> an IETF disclosure.
>  
> Others: If you are aware of IPR that encumbers this draft, please reply to 
> this mail with relevant information.
>  
> Many thanks
>  
> Pascal
> ___
> 6tisch mailing list
> 6tisch@ietf.org 
> https://www.ietf.org/mailman/listinfo/6tisch 
> 
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-10.txt

[Mališa Vučinić]

Dear all,

We have submitted the new version of the minimal-security draft fixing the 
remaining issues that were brought during the 2nd WGLC and the Prague meeting. 
In particular, this version:
- Resolves the JRC failure issue by relying on the mechanism specified in 
OSCORE Appendix B.2
- Revisits the CoJP error handling parameters to enable stateless handling of 
CoJP requests by the JRC
- Clarifies the network-wide rekeying process through separate sections for 
6LBR and 6LN handling

Mališa

> On 5 Apr 2019, at 23:25, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG 
> of the IETF.
> 
>Title   : Minimal Security Framework for 6TiSCH
>Authors : Malisa Vucinic
>  Jonathan Simon
>  Kris Pister
>  Michael Richardson
>   Filename: draft-ietf-6tisch-minimal-security-10.txt
>   Pages   : 49
>   Date: 2019-04-05
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-10
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Mališa Vučinić]

> On 5 Apr 2019, at 20:15, Michael Richardson  wrote:
> 
> If we could delay the switch to the new schedule until *after*
> COJP_REKEYING_GUARD_TIME has elapsed, then that might work.
> Alternatively, if we could number the rekeys then a EB could signal the
> switch to the new schedule some time after the keys are changed.

Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME would work, 
different nodes receive the new keys at different instants so it would be hard 
to sync them. I like better the trigger with an EB, it originates at 6LBR that 
is trusted and the frame can be authenticated by the nodes that have installed 
the new keys.

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Mališa Vučinić]

On 5 Apr 2019, at 20:22, Michael Richardson  wrote:
> 
> Also so that the many unicast conversations needed to do the rekey can be 
> spread
> across a large amount of time, letting the JRC reach out to even very sleepy
> nodes.

Good point indeed, sleepy nodes may miss the reception slots and appear 
disconnected but as long as they are in the network they will eventually get 
the CoJP Parameter Update Request and the new keys, assuming JRC implements the 
default retransmission mechanism.

Mališa___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

[Mališa Vučinić]

The original intent was to allow the pledge to signal “I can act on this 
parameter but not on that value that you gave me”, cherry-picking specific keys 
from the key set or just copying the whole thing if nothing works. The previous 
text optimized for that by mandating the value or its CBOR-encoded subset to be 
included all the time. 

I rewrote the paragraph now in order to allow the pledge to send a null for the 
case where the JRC should not bother to retry configuring that specific 
parameter again.

The commit is at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/60e2a8a2acbae5cca624932e88c1f650a95d9ca6?at=minimal-security-10
 


Let me know if it reads better.

Mališa

> On 5 Apr 2019, at 16:32, Christian Amsüss  wrote:
> 
> Only a small question remains: When a pledge sends [0 /* unsupported */,
> 42 /* some fancy extension */, X] as an Unsupported Configuration, why
> should it send the full value that was sent with the join response and
> not just a syntactic placeholder (null)?



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Mališa Vučinić]

It seems i have permuted slotOffset and channelOffset below :-) This may be a 
piste if slotOffset permutation is kept but there would likely be problems for 
nodes with higher bandwidth requirements and many cells in the schedule to 
guarantee zero slotOffset collisions in one own’s schedule across slotframe 
iterations. Don’t really like it though for the reason of breaking the 
scheduling function.

As a reminder, in minimal-security we resorted to the current rekeying 
mechanism and not the one using the exact timestamp in the future when the 
whole network switches to new keys in order to avoid having to know the network 
notion of time at the JRC.

Mališa

> On 4 Apr 2019, at 19:33, Mališa Vučinić  wrote:
> 
> My understanding is that the problem in the permuted schedule arises during 
> COJP_REKEYING_GUARD_TIME after nodes in the network started using the new 
> keys, but have still kept the old key in case someone has not yet switched. 
> When coupled with a rekeyed permutation key to calculate the schedule, this 
> means that during COJP_REKEYING_GUARD_TIME a node would need to follow two 
> schedules, one with the old permutation key and one with the new one. The 
> problem in following two schedules for COJP_REKEYING_GUARD_TIME is that 
> draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset and 
> the channelOffset be permuted so that it may occur that there can be a 
> collision in slotOffset between the new and the old schedule.
> 
> The problem that draft-tiloca-6tisch-robust-scheduling solves seems to be the 
> predictability of the channel on which a transmission is going to take place. 
> With that in mind, I have second thoughts about the recommendation on 
> permuting the slotOffset, especially taking into account that this will break 
> any scheduling function that optimizes for latency, as discussed in Section 
> 6.3.
> 
> Mališa
> 
> 
>> On 4 Apr 2019, at 17:40, Michael Richardson > <mailto:m...@sandelman.ca>> wrote:
>> 
>> Can you see how the old/new key issue interacts poorly with the permuted
>> schedule?
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Mališa Vučinić]

My understanding is that the problem in the permuted schedule arises during 
COJP_REKEYING_GUARD_TIME after nodes in the network started using the new keys, 
but have still kept the old key in case someone has not yet switched. When 
coupled with a rekeyed permutation key to calculate the schedule, this means 
that during COJP_REKEYING_GUARD_TIME a node would need to follow two schedules, 
one with the old permutation key and one with the new one. The problem in 
following two schedules for COJP_REKEYING_GUARD_TIME is that 
draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset and the 
channelOffset be permuted so that it may occur that there can be a collision in 
slotOffset between the new and the old schedule.

The problem that draft-tiloca-6tisch-robust-scheduling solves seems to be the 
predictability of the channel on which a transmission is going to take place. 
With that in mind, I have second thoughts about the recommendation on permuting 
the slotOffset, especially taking into account that this will break any 
scheduling function that optimizes for latency, as discussed in Section 6.3.

Mališa


> On 4 Apr 2019, at 17:40, Michael Richardson  wrote:
> 
> Can you see how the old/new key issue interacts poorly with the permuted
> schedule?

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Mališa Vučinić]

Should be covered in 
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 


Mališa

> On 4 Apr 2019, at 16:04, Michael Richardson  wrote:
> 
> I was looking for some text from 6tisch-minimal that explains how the rekey
> actually occurs.
> 
> Malisa, it seems like this text has been lost.
> Or did we move this process to another document?

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Progress zero-touch document

[Mališa Vučinić]

How about we form a focused design team to start working out the details and we 
can do the editorial work and publish once the EDHOC decision is out?

Mališa

> On 2 Apr 2019, at 17:04, Michael Richardson  wrote:
> 
>> 
>> What are your thoughts on this?
> 
> If you want to start now, please go ahead, but I'd prefer if you waited three
> weeks.

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Progress zero-touch document

[Mališa Vučinić]

Hello Pascal,

Are you suggesting that we should start working out the details on using EDHOC 
but keep an alternative as an appendix in the document? Since we have stalled 
on this work for some time for reasons outside of the working group control, I 
think it would make sense to catch up..

Let me know.

Mališa

> On 2 Apr 2019, at 15:34, Pascal Thubert (pthubert)  wrote:
> 
> Hello Malisa
> 
> Speaking for myself here, I'm happy that you start on that direction already; 
> but would like to see the edhoc group formed and progressing before 
> committing fully to it.
> 
> All the best,
> 
> Pascal
> 
>> -Original Message-
>> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Mališa Vucinic
>> Sent: mardi 2 avril 2019 14:55
>> To: Michael Richardson 
>> Cc: 6tisch <6tisch@ietf.org>
>> Subject: [6tisch] Progress zero-touch document
>> 
>> Michael, all,
>> 
>> With the EDHOC specification finally seeing progress (see [1]), it seems 
>> like a
>> good time to restart the work on zero touch and progress the adopted working
>> group document.
>> 
>> Reading the current version of 
>> draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it
>> seems that there are many options available, including the choice between
>> DTLS and EDHOC for authentication. Many available options may pose
>> interoperability challenges and also add unnecessary code complexity. Given
>> that the working group decided on using OSCORE during network access [2], as
>> well as for application purposes [3], the implementation of the 6TiSCH stack
>> includes the CBOR/COSE primitives in the footprint, as well as the support to
>> go through an application-layer proxy as specified in [2]. EDHOC protocol is
>> built on these primitives, can be easily carried within messages specified 
>> in [2]
>> for network access to go through an application-layer proxy, and is quite
>> efficient when it comes to the encoding overhead using CBOR resulting in a
>> small number of L2 frames to complete the key exchange. It seems as a natural
>> way forward for the working group to focus on using EDHOC in [4].
>> 
>> Therefore, I would like to propose to keep track of the EDHOC progress and to
>> work on a more streamlined zero-touch solution. Doing these changes in [4]
>> seems to make the most sense at this point.
>> 
>> What are your thoughts on this?
>> 
>> Mališa
>> 
>> [1]
>> https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWj
>> XIm0c
>> [2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>> [3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
>> [4] https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-
>> join/
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Progress zero-touch document

[Mališa Vučinić]

Michael, all,

With the EDHOC specification finally seeing progress (see [1]), it seems like a 
good time to restart the work on zero touch and progress the adopted working 
group document.

Reading the current version of draft-ietf-6tisch-dtsecurity-zerotouch-join-03, 
it seems that there are many options available, including the choice between 
DTLS and EDHOC for authentication. Many available options may pose 
interoperability challenges and also add unnecessary code complexity. Given 
that the working group decided on using OSCORE during network access [2], as 
well as for application purposes [3], the implementation of the 6TiSCH stack 
includes the CBOR/COSE primitives in the footprint, as well as the support to 
go through an application-layer proxy as specified in [2]. EDHOC protocol is 
built on these primitives, can be easily carried within messages specified in 
[2] for network access to go through an application-layer proxy, and is quite 
efficient when it comes to the encoding overhead using CBOR resulting in a 
small number of L2 frames to complete the key exchange. It seems as a natural 
way forward for the working group to focus on using EDHOC in [4].

Therefore, I would like to propose to keep track of the EDHOC progress and to 
work on a more streamlined zero-touch solution. Doing these changes in [4] 
seems to make the most sense at this point. 

What are your thoughts on this?

Mališa

[1] 
https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c
[2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
[3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
[4] 
https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Secdispatch] EDHOC Summary

[Mališa Vučinić]

+1

We are happy to contribute to this effort through feedback on the design, 
implementation for constrained devices and its evaluation in 6TiSCH networks.

Mališa

> On 30 Mar 2019, at 18:31, Thomas Watteyne  wrote:
> 
> The 6TiSCH WG has produced a set of documents [1,2] that specify the use of 
> OSCORE to secure message exchanges at the application layer including network 
> access. At the side meeting in Prague two years ago involving several ADs and 
> WG chairs, the 6TiSCH chairs have indicated the need for an efficient 
> authenticated key exchange protocol that we could use during the network 
> access to key OSCORE. We have also restated this request at the SECDISPATCH 
> interim a couple of weeks ago.
> 
> The EDHOC specification was discussed on numerous occasions during the 6TiSCH 
> working group meetings and the approach on using it for the extension of [1] 
> towards zero-touch [3] deployments had a wide consensus. We welcome the work 
> in this area to be done, and strongly support any decision of the security 
> ADs that leads to the fast progress of this specification.
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ 
>  
> [2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ 
> 
> [3] 
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/ 
> 
>  
> 
> ___
> Secdispatch mailing list
> secdispa...@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Done, thanks for the review! I closed the corresponding issues in bitbucket.

Mališa

> On 29 Mar 2019, at 07:19, Göran Selander  wrote:
> 
> Hi Mališa,
> 
> Thanks for the update, this addresses my concerns. 
> 
> Editorial: Replace "entirely defined" with "specified".
> 
> Göran
> 
> On 2019-03-27, 23:16, "Mališa Vučinić"  wrote:
> 
>Dear Göran,
> 
> 
>Many thanks for the review! As we discussed during the WG meeting, I added 
> new text in the draft to stress that the procedure in Appendix B.2 of OSCORE 
> should be used in the case of a failure event occurring at the JRC. The use 
> of this procedure
> is now RECOMMENDED, and in case it is not supported by a particular 
> pledge implementation, we require the reprovisioning of the affected devices 
> with fresh parameters.
> 
> 
>Other comments have also been taken into account and the draft has been 
> aligned with the references in oscore-16.
> 
> 
>The related diff providing changes in respect to your comments is 
> available at:
>
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10-goran#diff
> 
> 
>Please let me know if this addresses your review.
> 
> 
>Mališa
> 
> 
>On 24 Mar 2019, at 23:08, Göran Selander  
> wrote:
> 
>Dear 6TiSCH,
> 
>Sorry for very late response, here are a some post-2nd WGLC comments on 
> draft-ietf-6tisch-minimal-security-09:
> 
>Summary: With one exception detailed below the draft seems to be in good 
> shape and essentially only need some harmonizing updates following the last 
> changes to OSCORE which has now completed IESG review.
> 
>Main concern:
> 
>Section 8.3:
>The recovery from complete failure of the JRC as currently described is 
> not satisfactory and may lead to loss of confidentiality of data sent from 
> the JRC to the pledge.  During reinitialization of pledges due to complete 
> failure of JRC, the new JRC cannot
> detect replays of old initialization messages, nor does it know the 
> latest sequence number used by the failed JRC:
> 
>* It is not described how the new JRC reacts to a received CoJP request to 
> avoid accepting a replay request or why it is not a problem with nonce reuse 
> in the CoJP response.
>* The procedure for the first Parameter Update with randomized payload may 
> have different known CoAP header parameter values than the message with which 
> nonce is reused, leading to a two-time pad which may to break 
> confidentiality. It should at least be described
> why this is not an issue.
>* There is no security consideration about properties of the encryption 
> algorithm, in this case AES-CCM, which limits this attack to confidentiality.
> 
>There are different ways to resolve this. Here are two alternatives:
> 
>Appendix B.2 in OSCORE specifies a challenge-response based protocol for 
> updating the security context based on an exchange of nonces. This protocol 
> can be directly applied here where the replaced JRC in the role of CoAP 
> server would trigger the protocol by
> responding to the reinitialization request with a new security context as 
> is detailed in appendix B.2. The pledge then repeats the CoJP request with 
> another security context and the JRC responds with the CoJP response using 
> the agreed security context. In
> this way the old security context is replaced by a new, thereby removing 
> the risks associated with accepting replayed messages and reusing nonces.
> 
> 
>The procedure in the previous paragraph does however not support the 
> lightweight implementation option in Appendix B of this draft, since the 
> master secret is needed for deriving the new security context. If this is 
> very important to support, considering that
> CoJP is a special application of OSCORE it may be possible to specify a 
> bespoke synchronization protocol. One setting for this is based on a reserved 
> JRC sequence number for responses to reinitialization requests, the Echo 
> option, and transport of the pledge
> record of last used JRC sequence number. This would require a careful 
> analysis in particular of the use of JRC sequence numbers.
> 
> 
>A related concern is on the use of persistent memory: 
> 
>"In case of a reboot on either side, the retrieval of mutable security 
> context parameters is feasible from the persistent memory such that there is 
> no risk of AEAD nonce reuse due to a reinitialized Sender Sequence number, or 
> of a replay attack due to the reinitialized
> replay window."
> 
>Section B.1.1 of OSCORE details some issues with wr

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

[Mališa Vučinić]

Hello Christian,

The intent was indeed to differentiate between “I cannot do what is requested 
with parameter X” and “I understand parameter X but not what you are asking me 
to do with it”. To avoid ambiguity, I now use the terms “unsupported” and 
“malformed” as code values.

Essentially, along the notes of your proposal I modified the text and specified 
two objects:

Unsupported_Configuration = [
   + parameter   : Unsupported_Parameter
]

Unsupported_Parameter = (
 code: int,
 parameter_label : int,
 parameter_value : any
)

with code being either “Unsupported” or “Malformed”. In either case, 
parameter_label and parameter_value are returned. This structure also supports 
the signaling of individual link layer keys, as the "link-layer key set” 
parameter label can be signaled together with the subset of the original keys. 

Note that the message name carrying this response is still called Diagnostic 
Response message. The commit was squashed with the previous one and the diff is 
available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff
 


Let me know what do you think.

Mališa


> On 28 Mar 2019, at 01:29, Christian Amsüss  wrote:
> 
> Hello Mališa,
> 
>> Thank you for summarizing the discussion we had and proposing these changes. 
>> I have modified the text in order to reflect the email below by:
> 
> I'm not sure I understand the distinction between "unsupported" and
> "unexpected" parameters. Are they about having an unknown code vs.
> having an unknown value? If so, the unexpected additional info should
> include the full value in the diagnostic, and not only the label.
> 
> I don't quite see how the arrays come in here, especially given that I
> didn't find the Diagnostic CDDL used anywhere in the updated document
> (JoinRequest still only has Error). Is the intention here that there is
> only one Diagnostic, with only one code and a list of values? With that
> a pledge could say that it won't understand options X and Y, but it
> can't say that it won't understand option X and can't use the link-layer
> key Y.
> 
> (On an editorial note, the "Additional info type" could go away in
> #table_diagnostic_codes, but given the above I think they should rathe
> stay uint / uint (key_id) / Configuration, and have at some point a `?
> 8: [ +Diagnostic ]` or so).
> 
>> - renaming of Error object to Diagnostic, if you have a better naming 
>> proposal, please let me know
> 
> I'd call it UnsupportedConfigurations, but that's really a matter of
> overall document terminology which I'm unfamiliar with.
> 
> Kind regards
> Christian
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

[Mališa Vučinić]

Hello Christian,

Thank you for summarizing the discussion we had and proposing these changes. I 
have modified the text in order to reflect the email below by:
- encoding additional info as a CBOR array allowing multiple parameters to be 
transported within
- removing the previous error code which explicitly was referring to the state 
of a request
- renaming of Error object to Diagnostic, if you have a better naming proposal, 
please let me know
- encapsulating the entire link layer key object(s) that is unsupported by a 
given pledge. I believe this is the simplest handling from the pledge 
implementation point of view as it can simply memcpy the byte string received

I also did some minor edits to align the text in the rest of the document, the 
related diff is available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff
 


Please let me know if you see any issue with this resolution.

Mališa

> On 27 Mar 2019, at 18:29, Christian Amsüss  wrote:
> 
> Hello Mališa,
> 
> we've just talked about server state and the error codes sent with
> subsequent join requests in [1], especially Sections 8.4.1 and Section
> 8.4.5. (Working group, please be aware that I have not read and
> understood the full document but am responding to a particular question
> here).
> 
> My understanding is that the pledge POSTs its Join_Request to the
> server, initially without an Error, and receives a response. If it has
> trouble acting on the response, it sends another request that includes
> the original parameters plus an error object; the server may respond to
> that with a more final error ("Sorry, then I can't help you either") or
> by sending a different response ("OK, if you can't do X, here's a setup
> that works without that"). The question is as whether that agrees with
> the a RESTful design and to the stateless servers we aspire in CoRE.
> 
> The error handling as currently described requires the server to keep
> around information about the previous request. That is not per se a
> violation of the side effect rules of CoAP (as the request is a POST and
> the server may change state as a result), but has non-idempotent POST
> requests which are discouraged in CoRE, and could be avoided easily.
> 
> Suggestion: Chain errors in the requests
> 
> 
> I suggest that only errors be sent in subsequent requests that are
> self-descriptive, and not so much indicate "what happened" but more
> "what the pledge can't do"; then the server does not need to remember
> the history of each pledge's requests.
> 
> If that is to be played back-and-forth (and I understand there are up to
> four attempts), this requires that the pledge can indicate more than one
> thing that went wrong. As long as there is only one error field, if
> (say) the client tells the server after the first round-trip that it
> doesn't support option X and the server offers option Y instead, the
> client could only indicate with the response that it won't support
> option Y, and the server would happily give it X again. Making the error
> field in the Join_Request a list would ease that, and might even allow
> for fewer round-trips if the pledge can issue complaints about several
> options in the first round-trip.
> 
> Having a list of errors does obviously increase complexity a little, and
> it requires the client to keep track of things that it dislikes about
> the server's previous responses. My impression is that pledges can
> probably afford that (it's state of size that's limited by the number of
> attempts it's willing to do, and is only kept during the joining
> process), freeing the serve of keeping around state of every pledge for
> some potentially-hard-to-tell time.
> 
> 
> Suggestion: Require errors to be self-descriptive
> -
> 
> With that alone, a stateless server can be constructed, though the
> conceptualization would be a bit convoluted (the precise rules of
> interpreting the error codes would be "Had I sent you this request with
> one less error, your response would trigger error X in me") --
> stateless, but not particularly elegant to think about or easy to act
> on.
> 
> If the error codes could be limited to statements that are valid truths
> irrespective of hypothetical answers, that would look cleaner but
> supports only error codes that state such valid truths. Conceptually, it
> would not so much be an "error" field but a "things I'm telling you in
> advance I can't do".
> 
> Of the list in Table 4, I'd say that
> 
> * 0 is not applicable (it's a server response)
> * 1 should not be expected to be recoverable, and in this model of
>  thought becomes very fuzzy. ("Give me that, but I know I can't act on
>  it...?")
> * 2 is fine as long as it 

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Dear Göran,

Many thanks for the review! As we discussed during the WG meeting, I added new 
text in the draft to stress that the procedure in Appendix B.2 of OSCORE should 
be used in the case of a failure event occurring at the JRC. The use of this 
procedure is now RECOMMENDED, and in case it is not supported by a particular 
pledge implementation, we require the reprovisioning of the affected devices 
with fresh parameters.

Other comments have also been taken into account and the draft has been aligned 
with the references in oscore-16.

The related diff providing changes in respect to your comments is available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10-goran#diff
 


Please let me know if this addresses your review.

Mališa

> On 24 Mar 2019, at 23:08, Göran Selander  wrote:
> 
> Dear 6TiSCH,
> 
> Sorry for very late response, here are a some post-2nd WGLC comments on 
> draft-ietf-6tisch-minimal-security-09:
> 
> Summary: With one exception detailed below the draft seems to be in good 
> shape and essentially only need some harmonizing updates following the last 
> changes to OSCORE which has now completed IESG review.
> 
> Main concern:
> 
> Section 8.3:
> The recovery from complete failure of the JRC as currently described is not 
> satisfactory and may lead to loss of confidentiality of data sent from the 
> JRC to the pledge.  During reinitialization of pledges due to complete 
> failure of JRC, the new JRC cannot detect replays of old initialization 
> messages, nor does it know the latest sequence number used by the failed JRC: 
> * It is not described how the new JRC reacts to a received CoJP request to 
> avoid accepting a replay request or why it is not a problem with nonce reuse 
> in the CoJP response.
> * The procedure for the first Parameter Update with randomized payload may 
> have different known CoAP header parameter values than the message with which 
> nonce is reused, leading to a two-time pad which may to break 
> confidentiality. It should at least be described why this is not an issue.
> * There is no security consideration about properties of the encryption 
> algorithm, in this case AES-CCM, which limits this attack to confidentiality.
> 
> There are different ways to resolve this. Here are two alternatives:
> 
> Appendix B.2 in OSCORE specifies a challenge-response based protocol for 
> updating the security context based on an exchange of nonces. This protocol 
> can be directly applied here where the replaced JRC in the role of CoAP 
> server would trigger the protocol by responding to the reinitialization 
> request with a new security context as is detailed in appendix B.2. The 
> pledge then repeats the CoJP request with another security context and the 
> JRC responds with the CoJP response using the agreed security context. In 
> this way the old security context is replaced by a new, thereby removing the 
> risks associated with accepting replayed messages and reusing nonces. 
> 
> The procedure in the previous paragraph does however not support the 
> lightweight implementation option in Appendix B of this draft, since the 
> master secret is needed for deriving the new security context. If this is 
> very important to support, considering that CoJP is a special application of 
> OSCORE it may be possible to specify a bespoke synchronization protocol. One 
> setting for this is based on a reserved JRC sequence number for responses to 
> reinitialization requests, the Echo option, and transport of the pledge 
> record of last used JRC sequence number. This would require a careful 
> analysis in particular of the use of JRC sequence numbers. 
> 
> A related concern is on the use of persistent memory: 
> 
> "In case of a reboot on either side, the retrieval of mutable security 
> context parameters is feasible from the persistent memory such that there is 
> no risk of AEAD nonce reuse due to a reinitialized Sender Sequence number, or 
> of a replay attack due to the reinitialized replay window."
> 
> Section B.1.1 of OSCORE details some issues with writing to non-volatile 
> memory that are applicable in particular to the JRC, and this text should be 
> updated accordingly. Depending on the JRC implementation, this may be another 
> reason why the pledges/joined nodes need to support the protocol in Appendix 
> B.2 in the case of JRC losing context.
> 
> Minor concerns:
>   
> "Implementations MUST ensure that multiple CoAP requests to different JRCs 
> are properly incrementing the sequence numbers "
> 
> I don't know why this is restricted to different JRCs: Implementations MUST 
> ensure that multiple CoAP requests properly incrementing the sequence numbers.
> 
> 
> OLD
> "Since the pledge's OSCORE ID "
> 
> NEW
> "Since the pledge's OSCORE Sender ID "
> 
> 
> " A simple implementation technique is to 

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

[Mališa Vučinić]

Thanks Pascal, looks good!

Mališa

On Wed, Dec 12, 2018 at 1:51 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Mališa
>
>
>
> Please see below ( I pushed the result in the repo, please let me know if
> we are OK now )
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Mališa Vucinic
> *Sent:* mercredi 12 décembre 2018 15:01
>
>
> *To:* Pascal Thubert (pthubert) 
>
> *Cc:* Michael Richardson ; 6tisch@ietf.org
>
>
> *Subject:* Re: [6tisch] WGLC for
> https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt
>
>
>
> Hello Pascal,
>
>
>
> Most of the resolutions to my comments look good. Couple of nits inline.
>
>
>
> Mališa
>
>
>
> *[PT>] *I think we need to define an entry for CoJP, similar to 6P. What
> about;
>
>CoJP (Constrained Join Protocol):  CoJP is a one-touch join protocol
>
>defined in the Minimal Security Framework for 6TiSCH
>
>[I-D.ietf-6tisch-minimal-security].  CoJP requires the
>
>distribution of preshared keys (PSK), and enables a node
>
>to join with a single round trip to the JRC via the JP.
>
>
>
> How about:
>
> CoJP (Constrained Join Protocol): CoJP enables a pledge to securely join a
> 6TiSCH network by distributing network parameters over a secure channel.
> CoJP is defined in the Minimal Security Framework for 6TiSCH
> [I-D.ietf-6tisch-minimal-security]. In the minimal setup with pre-shared
> keys defined in [I-D.ietf-6tisch-minimal-security], CoJP allows the pledge
> to join the network in a single round trip exchange.
>
> *[PT>] *
>
> *The second sentence is extraneous, correct?*
>
> *[PT>] what about*
>
>
>
>CoJP (Constrained Join Protocol):  The Constrained Join Protocol
>
>(CoJP) enables a pledge to securely join a 6TiSCH network
>
>and obtain network parameters over a secure channel.  In
>
>the minimal setup with pre-shared keys defined in
>
>[I-D.ietf-6tisch-minimal-security], CoJP can operate with
>
>a single round trip exchange.
>
>
>
> =
>
> Section 3.1: 6TiSCH Stack
>
>
> - add Constrained Join Protocol in the Figure above CoAP. Use “Constrained
> Join Protocol” instead of “Minimal Security Framework for 6TiSCH”.
>
> - Description of DTLS seems as a remnant. I would stress OSCORE here as
> the primacy choice with DTLS also being an option for applications.
>
> *[PT>] *
>
> *[PT>] *This gives :
>
>
>
>   +++
>
>   |  CoJP  | Applis |
>
>   +++--+-+
>
>   | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
>
>   +-+--+-+
>
>   |   UDP   |  ICMPv6|
>
>   +-++
>
>   | IPv6 |
>
>   +--+--+
>
>   | 6LoWPAN HC   /   6LoRH HC| Scheduling Functions |
>
>   +--+--+
>
>   | 6top (to be IEEE Std 802.15.12) inc. 6top protocol  |
>
>   +-+
>
>   | IEEE Std 802.15.4 TSCH  |
>
>   +-+
>
>
>
> Nit: Swap Applis and CoJP to have control plane "kind of" on the left side
> :-).
>
>
>
> *[PT>] OK*
>
>
>
> Security Considerations in WIP-19:
>
>As detailed in Section 6, a pledge that wishes to join the 6TiSCH
>
>network must participate to a join process to obtain its security
>
>keys.
>
>
>
> Nits: Replace "must participate to a join process" with "must trigger the
> join protocol".
>
> *[PT>] *
>
> *OK, but  “must use” then. You do not trigger a protocol, you trigger its
> operation.*
>
>
>
>The join process can be zero-touch and leverage ANIMA procedures, as
>
>detailed in the 6tisch Zero-Touch Secure Join protocol
>
>[I-D.ietf-6tisch-dtsecurity-zerotouch-join].
>
>Alternatively, the join process can be one-touch, in which case the
>
>pledge is provisioned with a preshared key (PSK), and uses CoJP as
>
>specified in [I-D.ietf-6tisch-minimal-security].
>
>
>
> Proposal to replace the paragraph above with:
>
>
>
> The join protocol used in 6TiSCH is Constrained Join Protocol (CoJP). In
> the minimal setting defined in [I-D.ietf-6tisch-minimal-security], the
> authentication is based on a pre-shared key, based on which a secure
> session is derived. CoJP exchange may also be preceded with a zero-touch
> handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable
> pledge joining based on certificates and/or inter-domain communication.
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

[Mališa Vučinić]

Hello Pascal,

Most of the resolutions to my comments look good. Couple of nits inline.

Mališa

*[PT>] *I think we need to define an entry for CoJP, similar to 6P. What
> about;
>
>CoJP (Constrained Join Protocol):  CoJP is a one-touch join protocol
>
>defined in the Minimal Security Framework for 6TiSCH
>
>[I-D.ietf-6tisch-minimal-security].  CoJP requires the
>
>distribution of preshared keys (PSK), and enables a node
>
>to join with a single round trip to the JRC via the JP.
>
>
How about:
CoJP (Constrained Join Protocol): CoJP enables a pledge to securely join a
6TiSCH network by distributing network parameters over a secure channel.
CoJP is defined in the Minimal Security Framework for 6TiSCH
[I-D.ietf-6tisch-minimal-security]. In the minimal setup with pre-shared
keys defined in [I-D.ietf-6tisch-minimal-security], CoJP allows the pledge
to join the network in a single round trip exchange.

=
>
> Section 3.1: 6TiSCH Stack
>
>
> - add Constrained Join Protocol in the Figure above CoAP. Use “Constrained
> Join Protocol” instead of “Minimal Security Framework for 6TiSCH”.
>
> - Description of DTLS seems as a remnant. I would stress OSCORE here as
> the primacy choice with DTLS also being an option for applications.
>
> *[PT>] *
>
> *[PT>] *This gives :
>
>
>
>   +++
>
>   |  CoJP  | Applis |
>
>   +++--+-+
>
>   | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
>
>   +-+--+-+
>
>   |   UDP   |  ICMPv6|
>
>   +-++
>
>   | IPv6 |
>
>   +--+--+
>
>   | 6LoWPAN HC   /   6LoRH HC| Scheduling Functions |
>
>   +--+--+
>
>   | 6top (to be IEEE Std 802.15.12) inc. 6top protocol  |
>
>   +-+
>
>   | IEEE Std 802.15.4 TSCH  |
>
>   +-+
>
>
Nit: Swap Applis and CoJP to have control plane "kind of" on the left side
:-).

Security Considerations in WIP-19:

>As detailed in Section 6, a pledge that wishes to join the 6TiSCH
>
>network must participate to a join process to obtain its security
>
>keys.
>
>
Nits: Replace "must participate to a join process" with "must trigger the
join protocol".


>The join process can be zero-touch and leverage ANIMA procedures, as
>
>detailed in the 6tisch Zero-Touch Secure Join protocol
>
>[I-D.ietf-6tisch-dtsecurity-zerotouch-join].
>
>Alternatively, the join process can be one-touch, in which case the
>
>pledge is provisioned with a preshared key (PSK), and uses CoJP as
>
>specified in [I-D.ietf-6tisch-minimal-security].
>
>
Proposal to replace the paragraph above with:

The join protocol used in 6TiSCH is Constrained Join Protocol (CoJP). In
the minimal setting defined in [I-D.ietf-6tisch-minimal-security], the
authentication is based on a pre-shared key, based on which a secure
session is derived. CoJP exchange may also be preceded with a zero-touch
handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable
pledge joining based on certificates and/or inter-domain communication.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] POST WGLC: draft-ietf-6tisch-architecture-18.txt

[Mališa Vučinić]

Hello Pascal, Michael,

I just opened a pull request on bitbucket rewriting the join process
description. The PR is at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/pull-requests/1/update-join-process-description/diff


Could you take a look and if you agree, refine further.

Mališa

On Fri, Dec 7, 2018 at 6:15 PM Pascal Thubert (pthubert) 
wrote:

> Dear all:
>
> The WG last call for the architecture draft is now complete.
> We received many comments and hopefully they are all sorted out and
> published in draft 18.
> Reviewers, please look for the changes I made based on your comments in
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-18
>
> There is one pending issue, what we do with ex-section 6.1 that is now
> Appendix A.
>
> An suggestion is welcome, in particular from Malisa and Michael.
> Happy to discuss that as a separate thread.
> When this is sorted out, I guess we can ask for publication as a std track
> document/
>
> All the best,
>
> Pascal
>
>
> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of
> internet-dra...@ietf.org
> Sent: vendredi 7 décembre 2018 18:06
> To: i-d-annou...@ietf.org
> Cc: 6tisch@ietf.org
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-architecture-18.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : An Architecture for IPv6 over the TSCH mode of
> IEEE 802.15.4
> Author  : Pascal Thubert
> Filename: draft-ietf-6tisch-architecture-18.txt
> Pages   : 63
> Date: 2018-12-07
>
> Abstract:
>This document describes a network architecture that provides low-
>latency, low-jitter and high-reliability packet delivery.  It
>combines a high speed powered backbone and subnetworks using IEEE
>802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
>of LowPower wireless deterministic applications.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-18
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-architecture-18
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-18
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

[Mališa Vučinić]

Hello Pascal,

Here are my comments on draft-ietf-6tisch-architecture. I used the latest
version of the draft hosted on bitbucket. In general, an editorial pass on
the whole document would be useful, there are some typos here and there.
The main issue I see is that Section 6.1 is completely outdated as it still
refers to the preliminary discussions in the WG on JP authenticating the
pledge, which is not really the case. Other comments are organized per
sections, as I went through the document.

Mališa

=
Section 1: Introduction

- I think it would be quite useful to add here a high-level description of
TSCH operation, in order to give reader some idea on what TSCH is before
delving into the terminology section
=
Section 2: Terminology

- 6P transaction: It would be useful to describe this term in a generic
manner to cover 3-step transactions. I don't think it's really needed to
talk about individual messages in the protocol.

-Bundle:

-“Bundles are associated for either Layer-2 (switching) or Layer-3
(routing) forwarding operations. a Layer-3 bundle pair maps to an IP Link
with a neighbor, whereas a Layer-2 bundle set corresponds to the relation
of one or more incoming bundle(s) from the previous-hop neighbor(s) with
one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track. “

- I suggest removing the text above from the terminology section.

- CCA: definition is a bit upside down

- centralized cell reservation, centralized track reservation: are these
really needed?

- Enhanced Beacon: add defined in IEEE802.15.4 ?

- link: describe what "link" means in terms of 6tisch

- Constrained Join Protocol (CoJP) is currently not defined. Should we have
a dedicated entry or piggyback within generic “join protocol” term
stressing that 6TiSCH defines CoJP as its implementation.

=
Section 3.1: 6TiSCH Stack

- add Constrained Join Protocol in the Figure above CoAP. Use “Constrained
Join Protocol” instead of “Minimal Security Framework for 6TiSCH”.
- Description of DTLS seems as a remnant. I would stress OSCORE here as the
primacy choice with DTLS also being an option for applications.

- Maybe add block “Applications” alongside with CoJP?

-
Section 3.3: Scheduling TSCH

- Static Scheduling: mention earlier that this is needed for
interoperability during network formation
-
Section 3.7: Join Process and Registration

- at this point, wording “with a preshared key” is not necessary. We expect
zero-touch work to provide a shared key for CoJP execution. Omit “6TiSCH”
in “6TiSCH Constrained Join Protocol” to be consistent with
minimal-security. Replace 6JP with CoJP, applies for text and Figure 5.

=
Section 6: Security Considerations

The Minimal Security Framework for 6TiSCH
[I-D.ietf-6tisch-minimal-security] describes the minimal mechanisms
required to support secure enrollment of a pledge to a 6TiSCH network based
on PSK. The specification allows to establish of Link-Layer keys, typically
used in combination with a variation of Counter with CBC-MAC (CCM)
[RFC3610], and set up a secure end-to-end session between the joining node
(called the pledge) and the join registrar/coordinator (JRC) in charge of
authenticating the node via a Join Proxy (JP). It can also be used to
obtain a Link-Layer short address as a side effect. CoJP uses shared slots
which are a constrained resource, so it is optimized to limit the number of
messages to the strict minimum. As an example, Neighbor Discovery between
the pledge and the JP can be skipped when the IPv6 Link Local addresses
that are used derive from the node's EUI-64 address.


- I think “enrollment” is not the best term here since the pledge is
considered to be already enrolled into the domain from the security
viewpoint during the one-touch provisioning. I would suggest replacing the
text:

support secure enrollment of a pledge to a 6TiSCH network based on PSK


with

enable a pledge to securely join a 6TiSCH network based on a PSK.


- “via a Join Proxy” to me gives an impression that JP participates in the
authentication process, not that it only acts as a relay.

- CoJP appears here out of the blue, maybe mention it in the first sentence
that it is defined as part of the Minimal Security Framework?

CoJP uses shared slots which are a constrained resource, so it is optimized
to limit the number of messages to the strict minimum. As an example,
Neighbor Discovery between the pledge and the JP can be skipped when the
IPv6 Link Local addresses that are used derive from the node's EUI-64
address.


- I am not super happy about the phrasing of the paragraph above. CoJP does
not 

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-09.txt

[Mališa Vučinić]

Dear all,

We submitted the -09 version of the minimal-security draft, incorporating
the changes discussed during IETF 103 and summarized in the "Updates for
minimal-security-09" ML thread:
- Adding optional join rate parameter to Join Response. This enables JRC to
manage JPs.
- Aligning normative text on JRC failure handling with OSCORE.
- Removing "network identifier" from Join Response.

@Chairs: This version resolves all known issues raised during the WGLC.

Kind regards,
Mališa

On Wed, Nov 21, 2018 at 12:59 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : Minimal Security Framework for 6TiSCH
> Authors : Malisa Vucinic
>   Jonathan Simon
>   Kris Pister
>   Michael Richardson
> Filename: draft-ietf-6tisch-minimal-security-09.txt
> Pages   : 48
> Date: 2018-11-20
>
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-09
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Updates for minimal-security-09

[Mališa Vučinić]

Hi all,

As discussed during IETF 103, here is a list of proposed changes for
minimal-security-09 that we will use for the second WGLC:

- Add "join rate" parameter in the Configuration structure present in Join
Responses and Parameter Update requests: As discussed during IETF 103,
allowing the JRC to dynamically set the join rate at each individual JP in
the network may prove useful in order to 1) speed up the network formation
by allocating all the available bandwidth to join; 2) throttling join
traffic sent by JPs in case of an attack; 3) switching off the join
process; 4) enabling/disabling a given node to act as a JP. The value of
this parameter will be used to set CoAP's congestion control mechanism at
the JP. As discussed, the text should not prevent the JP to use another
mechanism, e.g.
https://tools.ietf.org/html/draft-ji-roll-traffic-aware-objective-function-03,
and locally decide on a value that it should use, but in case this
parameter is received in the Configuration object, the value set by the JRC
MUST take precedence. Is this fine?

- Remove "network identifier" from the Configuration structure present in
Join Response and Parameter Update requests: During IETF 102, we agreed on
not managing all of the 6LBR parameters with CoJP protocol, so this
parameter when present in a Join Response is a remnant. It used to be there
to allow the JRC to signal to the 6LBR which network identifier (i.e. PAN
ID) to use to advertise the network. With this parameter removed from
Configuration object, there is an expectation that the JRC and 6LBR
exchange this and other necessary parameters (timeslot duration, template,
slotframe length, etc) through another protocol. The proposed text is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b43a8139052a444e886b3b5a915bc0d545267340?at=minimal-security-09


- Clarification text on handling JRC failures and significant OSCORE
sequence number mismatch, aligning it better with OSCORE. The proposed text
is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/e942995f70b3ded33d9ce5307817ce4a9298b5fe?at=minimal-security-09


If you have any suggestions/recommendations/concerns, please raise them at
the latest a week from now.

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-08.txt

[Mališa Vučinić]

Dear all,

We have just submitted version -08 of minimal-security resolving, to our
knowledge, last remaining issues raised during the WGLC.

I will discuss *some* of these resolutions tomorrow during the IETF 103
presentation but for completeness, please go ahead and take a look at the
document beforehand.

On behalf of the authors,
Mališa

On Thu, Nov 8, 2018 at 12:47 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : Minimal Security Framework for 6TiSCH
> Authors : Malisa Vucinic
>   Jonathan Simon
>   Kris Pister
>   Michael Richardson
> Filename: draft-ietf-6tisch-minimal-security-08.txt
> Pages   : 48
> Date: 2018-11-07
>
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-08
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-08
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

[Mališa Vučinić]

Hi Göran,

Thanks for the feedback and the proposal. I added Appendix B detailing this
deployment option:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b93e8fa6152eb2bb10761264bcf8e47f861fd418


Let me know if the current text works for you.

Also, regarding the comment to explicitly mention OSCORE AEAD keys, here is
the relevant commit:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b50787232346e991d3384916a47faa4a49ed39ee

I have also resolved other pending issues on the document
- making use of the 0-length OSCORE Sender ID for the pledge
- use of CoAP CON messages to transport Join Request from pledge to JP and
NON messages from JP to JRC.

I will discuss these more in detail on Thursday.

The WIP document is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/src/minimal-security-08/


Mališa

On Wed, Oct 31, 2018 at 10:37 PM Göran Selander 
wrote:

> Hi Michael,
>
> Sorry for delayed response, this got hanging in my outbox.
>
> > 25 okt. 2018 kl. 19:52 skrev Michael Richardson :
> >
> >
> > Göran Selander  wrote:
> >> Now, the PSK in the Constrained Join protocol is used as the OSCORE
> Master
> >> Secret, from which the Sender/Recipient Contexts, including
> Sender/Recipient
> >> Keys, are derived. It is these keys, not the PSK, which are used for
> >> authentication and communication security in OSCORE, so they need to be
> >> unique and independent in each pledge. Since the Sender/Recipient
> Contexts
> >> are derived from the PSK and the pledge identifier using HKDF, the
> derived
> >> keys are expected to get these good properties as long as the input to
> HKDF
> >> is different for different endpoints. So, having unique PSKs is a
> sufficient
> >> condition. But having unique pledge identifiers is also sufficient,
> even if
> >> the same PSK is used: Pledges may be provisioned directly with the
> >> Sender/Recipient Context in a 1-touch fashion without access to the
> PSK, and
> >> can then run the Constrained Join protocol. In fact, this is a quite
> >> attractive deployment scheme:
> >
> >> * The pledges do not need to implement HKDF or SHA-256.
> >
> > What I'm hearing is that Pledges may be provisioned (at the factory)
> with:
> > SRContext = HKDF(PSK, PledgeIdentifier, other-stuff)
> >
> > while the JRC can be provisioned with:
> >  1) PSK
> >  2) list of valid PledgeIdentifiers
> >
> > What does not change is that:
> > a) SRContext still must be kept a secret.
> > b) SRcontext is still unique per-pledge (so can't be baked directly
> into firmware!)
> >
> > So this is easier for the JRC, but does not really change anything in
> the way
> > that Pledges have to be "touched".
> >
>
> Right, this was not a comment about changing one-touch, which is the basic
> assumption of minimal security. This was a note that other secrets can be
> provisioned in the same one-touch manner with certain benefits to pledge
> and JRC.
>
> >> But even if you don’t do that, I propose that you do describe the
> deployment
> >> scheme sketched above, for example in an appendix, and explain in that
> >> section why this scheme is secure even though it is not complying with
> >> the
> >
> > I agree that putting it into an appendix would work.
> > A completely separate document might also a good idea. (An operational
> BCP)
> >
> > In particular, leaving it to another document might allow other things
> that
> > need to be baked in uniquely to be described.  I am thinking about a
> > connection to the hash-based signature work that the SUIT WG cares about.
>
> I think that having at least a paragraph in an appendix of this draft
> would be good as it also illustrates how the requirement on PSK uniqueness
> can be slightly eased.
>
> Thanks,
> Göran
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

[Mališa Vučinić]

Hi Jim,

Thanks! Nits are fixed, here are the relevant commits:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/3c13ce3106c00fca2e38cc732359e98039eac528


https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/369c09fd04f785296917554a10797c6dba91e028

Mališa

On Sun, Oct 28, 2018 at 5:17 AM Jim Schaad  wrote:

> Mališa,
>
>
>
> I am happy with the changes that were made to address my original comments.
>
>
>
> Here are a couple of nits you may want to address.
>
>
>
> jim
>
>
>
>1. In section 2 use the updated reference to RFC 8174
>2. In section 4 – You might want to make it explicit as one of the
>item that the pledge identifier is provisioned.
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Tuesday, October 23, 2018 7:07 AM
> *To:* Göran Selander ; Xavi Vilajosana
> Guillen ; Tero Kivinen ; Jim Schaad <
> i...@augustcellars.com>; Tengfei Chang ; Klaus
> Hartke ; William Vignat 
> *Cc:* 6tisch@ietf.org
>
>
> *Subject:* Re: [6tisch] I-D Action:
> draft-ietf-6tisch-minimal-security-07.txt
>
>
>
> Dear WGLC reviewers, working group,
>
> We submitted a new version of minimal security incorporating the
> resolution of most of the issues raised during WGLC. There are two
> remaining issues that still need to be resolved, and I hope to publish
> these in an additional version after the draft submission cutoff period has
> passed.
>
> I will discuss the resolutions during the Bangkok meeting but please go
> ahead an take a look, and let me know if you are happy or not with the
> resolutions.
>
> List of issues with referenced changesets is available at:
>
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?responsible=malishav
>
>
>
> Mališa
>
>
>
> On Tue, Oct 23, 2018 at 8:03 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : Minimal Security Framework for 6TiSCH
> Authors : Malisa Vucinic
>   Jonathan Simon
>   Kris Pister
>   Michael Richardson
> Filename: draft-ietf-6tisch-minimal-security-07.txt
> Pages   : 45
> Date: 2018-10-22
>
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-07
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

[Mališa Vučinić]

Dear WGLC reviewers, working group,

We submitted a new version of minimal security incorporating the resolution
of most of the issues raised during WGLC. There are two remaining issues
that still need to be resolved, and I hope to publish these in an
additional version after the draft submission cutoff period has passed.

I will discuss the resolutions during the Bangkok meeting but please go
ahead an take a look, and let me know if you are happy or not with the
resolutions.

List of issues with referenced changesets is available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?responsible=malishav

Mališa

On Tue, Oct 23, 2018 at 8:03 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : Minimal Security Framework for 6TiSCH
> Authors : Malisa Vucinic
>   Jonathan Simon
>   Kris Pister
>   Michael Richardson
> Filename: draft-ietf-6tisch-minimal-security-07.txt
> Pages   : 45
> Date: 2018-10-22
>
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-07
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] WGLC issues to be addressed for minimal-security-07

[Mališa Vučinić]

Dear all,

I converted the extensive email and F2F discussions during the last two
months around the minimal-security draft into a list of issues to be
resolved.

The list with relevant email discussion snippets is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=wontfix=new


Some of these are obsolete with e.g. work on Stateless-Proxy now happening
in CoRE and other discussions at IETF102. These are marked as "wontfix".

If you see something missing from the list, please let me know.

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

On Fri, Sep 7, 2018 at 6:30 PM Tero Kivinen  wrote:

> Mališa Vučinić writes:
> > Yes, I think it can be made to work, but I think it is quite a lot of
> > work and code just to be able to claim to be "stateless".
> >
> > I don't quite agree that what is typically a one-liner to schedule a
> timeout
> > event and a couple of lines of code in the callback to remove the entry
> can be
> > deemed as "quite a lot of work and code"...
>
> Adding timer will create state, thus the protocol is no longer
> stateless. I think trying to make things very hard so it can be done
> stateless might make things harder.


Please note the difference between the protocol (CoJP), the configuration
of the stack and the implementation decisions.

Yes, in the particular case where the timer needs to be implemented in
order to relieve the state from the stack because the MAC layer was
implemented in such a way that the timer is necessary to get the
communication going, you can regard it as a state that needs to be kept for
a short amount of time. I am arguing that *in this particular case*
implementing it in such a way with a timeout taking into account
(re)transmission on a single hop will reduce vulnerability to DoS in
respect to a timeout to expire 1/N entries end-to-end, as discussed in one
of the previous emails.


> Example of this is when misconfigured node will try to joining again
> and again and again. If you do everything in stateless way you are
> going to act like every single one of those is completely new
> connection and do full processing of all of them. If you do store some
> state, you can remember that this node tried this few seconds ago,
> there is no point of allowing it to do it again, lets just drop the
> frame.
>

I respectively disagree: There is no security association between JP and
the pledge for very practical reasons as any node in the network can play
the role of a JP. What you propose makes sense in the case where the JP can
authenticate the pledge and drop the protocol messages due to failed
security processing. This is simply not the case and you are proposing to
make a blind decision at JP to prevent this pledge from joining, because a
previous authentication with JRC failed.

This is not the decision of the JP, but of the JRC.

By shifting this decision to JP, you are introducing unnecessary complexity
in the JP code which will simply result in more misconfigurations being
made.



> > True, but in B the JP can also protect network and JRC, as it
> actually
> > KNOWS how many pledges have sent messages to JRC through it. In case
> > A, it will always forward messages, as it does not know how many
> > ongoing ones there still is. Of course it could use some kind of
> > statistics counters to limit that number, by saying only n joining
> > operations per minute, but that is again more code and complexity
> than
> > just saying that keep the 20 bytes of state for each pledge doing
> > joining process, and limit the number of those to fixed number of n..
> >
> > For case B, it doesn't seem that you are considering that a malicious
> pledge
> > can spoof its EUI64.
>
> You are now talking about DoS attacks which happen within radiorange
> of the network. For such attacker they can simply do DoS by putting
> few bluetoot devices nearby... I have understood that bluetooth acts
> quite good DoS device for 802.15.4 devices in 2.4 GHz band...
>

Indeed, a hammer also acts as a good DoS device.


> Or simply transmit all the time and nothing will go through. That is
> much easier than spoofing EUI64 for joining purposes.
>

So now it seems we are talking about 802.15.4 attackers. If the attacker
has 16 802.15.4 radios and can jam all the channels at the same time we can
hardly do anything about that. That, however,  requires hardware that is
(significantly) more expensive than a single-radio 15.4 device (see for
example http://www.beamlogic.com/802-15-4-siteanalyzer#price).
Nevertheless, such an attack is our point of reference.

If we now consider single-radio jammer, due to channel hopping the
effectiveness of the attack significantly decreases.

When working on the minimal-security spec, we consider DoS attacks that
would allow the attacker with a typical single-radio 802.15.4 device and a
slightly modified firmware to prevent the network from forming, simply by
sending a couple of radio frames. I hope you see the difference in
investment from the point of view of an attacker to perform such an attack
in respect of getting specialized equipment.

On the other hand having non-malicious node which has wrong parameters
> and cannot join because of that, but will retry every few minutes will
> most likely be much more common case.
>

Agree

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

Hi Tero,

Just getting back to this after my vacation, see inline.

Mališa

On Fri, Jul 27, 2018 at 8:25 PM Tero Kivinen  wrote:

> Mališa Vučinić writes:
> >
> > The question now is when to remove the entry with secExempt for
> > pledge at JP, once it was installed from Stateless-Proxy. From the
> > security point of view, the easiest is to remove it immediately once
> > L2 ACK from the pledge is received at JP, but this will degrade
> > performance in case of future extensions where there are more
> > messages in the protocol before join completes as the first
> > corresponding frame from the pledge to the JP will need to be
> > retransmitted.
> >
> > What do you think?
>
> Yes, I think it can be made to work, but I think it is quite a lot of
> work and code just to be able to claim to be "stateless".
>

I don't quite agree that what is typically a one-liner to schedule a
timeout event and a couple of lines of code in the callback to remove the
entry can be deemed as "quite a lot of work and code"...


>
> > Yes, I see your point. This seems to be a performance vs security
> tradeoff, i.e.:
> >
> > (A) do we want to degrade performance with one L2 retransmission of
> > the first frame coming from the pledge when JP does not have an
> > entry, in order to reduce DoS space at JP.
> >
> > (B) keep this state at JP for the whole duration of the join process
> > of a pledge.
>
> I think B is much easier, as the JP most likely will want to limit
> number of pledges going through it anyways. I.e., it might be easier
> to configure JP so that it will have n (for example 3) slots for
> joining nodes, and after it has that many pedges trying to join
> through it it would simply not ACK on those packets at all.
>

I completely agree that B is easier but as I describe(d) below is also more
prone to DoS. Therefore, we opted for B...


> Also does the join messages going from the pledge to JRC always
> consists of exactly one L2 frame, meaning the size of messages is
> limited to around 100 octets or so? If there is multiple L2 frames to
> be sent and reassemebled in the JP, then that is definately a state
> that is much bigger than storing secExempt flag (which is less than 20
> bytes anyways in total).
>

You raise a good point that when a message results in multiple L2
fragments, which is not the case with default values, JP will need to
reassemble it at 6LoWPAN layer before passing it to CoAP. This should
indeed be discussed in the security considerations as a DoS vector as
setting the reassembly timeout value is critical.


> > Consider that the DoS metric of importance is the number of pledges
> > that can join over a single JP: N / T, where N is the number of
> > insecure entries for pledges at JP,
> > and T is the time JP has to keep them.
> > - N is the same both in (A) and (B).
> > - In (A), T is the worst-case timeout in case of an attack where JP
> > needs to expire the entry, because pledge did not send conformant
> > traffic to JRC in due time. Say a couple of seconds.
> > - In (B), T is the duration of the join process of a pledge. Much
> > greater than a couple of seconds with multiple hops to 6LBR, and JRC
> > in the cloud. With multiple pledges joining and contending for the
> > minimal cell, this is on the order of several minutes [1].
>
> True, but in B the JP can also protect network and JRC, as it actually
> KNOWS how many pledges have sent messages to JRC through it. In case
> A, it will always forward messages, as it does not know how many
> ongoing ones there still is. Of course it could use some kind of
> statistics counters to limit that number, by saying only n joining
> operations per minute, but that is again more code and complexity than
> just saying that keep the 20 bytes of state for each pledge doing
> joining process, and limit the number of those to fixed number of n.
>

For case B, it doesn't seem that you are considering that a malicious
pledge can spoof its EUI64.

For case A, we discuss this bandwidth cap that you mention in Security
Considerations section. Note that the bandwidth cap is for example already
implemented as part of CoAP's congestion control mechanism. By setting
PROBING_RATE from RFC7252 of JP to a value different than those of pledges,
existing code is used to limit how much traffic is forwarded into the
network. We don't have explicit text on the use of CoAP's mechanism for
this but I am discussing with CORE experts about it and I will provide some
text in the next revision.

>
> > Finally, while I understand that there are vendors out there that
> > sell closed implementations of 802.15.4 MAC where the behavior that
> > you describe of having

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Hi Jim,

Apologies for responding to your email only now due to my vacation in
August.

I don't have any objection to your proposed solution and this indeed solves
the issue without introducing an additional message in the protocol.

I am slightly leaning towards the PIV being sent in the Bad Request error
payload instead of within the Request-Tag option, simply to minimize the
implementation effort. I will incorporate this in the next revision of the
draft before Bangkok and validate with you.

Thank you for doing a review, outlining an issue and proposing a solution!

Mališa

On Fri, Aug 3, 2018 at 10:28 PM Jim Schaad  wrote:

> As I remember we had a discussion about this during the creation of OSCORE
> but the results did not make it into the final draft.
>
>
>
> There is never a problem for the second JOIN as the device will have both
> the keys and the saved PIV to use so it will never do a reuse of the same
> PIV assuming correct implementation.
>
>
>
> The first message from the JRC needs to be checked by the pledge to see if
> there is a duplicate PIV used.  If it finds a duplicate PIV used, and the
> PIV is “grossly” below the PIV it is expecting.  Then the pledge sends back
> and an encrypted response to the JRC with the following properties:
>
>
>
>1. The pledge uses its next PIV value (i.e. it will look like an
>observe message to the JRC) and places it’s PIV into the message as the
>partial IV.  Doing so should not create any problems that I can think of.
>As a new PIV is used there is no security leakage.
>2. The pledge sends a request-tag option as part of the response.  The
>value of the request-tag option contains a value greater or equal to the
>next PIV from the JRC that it will allow.  This value is an encrypted
>option and thus not visible.
>3. The JRC can then resend the message to the pledge using the new PIV
>(and optionally the request-tag option) to the pledge which should now
>accept it.
>
>
>
> There are a number of different ways that the value could be send from the
> pledge to the server.  I suggested the request-tag option above, but you
> could for example send “PIV=#” as the payload of a Bad Request error code
> to the JRC.  The only thing would be to define a single way to send this
> information.
>
>
>
> The first message from the JRC would be subject to leakage of data as it
> could be XORed with the first message from the original JRC and thus some
> details extracted.  I don’t know how much of this information ends up as
> being public after a while anyway and thus leaking it would not be a huge
> problem.  Depending on value of the data, the JRC could generate new data
> for the message to the pledge.
>
>
>
> Jim
>
>
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Wednesday, July 18, 2018 12:08 PM
>
>
> *To:* Jim Schaad 
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: Review draft-ietf-6tisch-minimal-security
>
>
>
> Thanks Jim for working on this! When you have time, please drop us a line
> with the proposed solution.
>
>
>
> Mališa
>
>
>
> On Wed, Jul 18, 2018 at 2:13 PM Jim Schaad  wrote:
>
> I think that I have a solution that could be implemented at the cost of
> one additional round trip the first time the JRC wants to update the
> endpoint.
>
>
>
> Jim
>
>
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Tuesday, July 17, 2018 1:22 PM
>
>
> *To:* Jim Schaad 
> *Cc:* 6tisch@ietf.org
>
> *Subject:* Re: Review draft-ietf-6tisch-minimal-security
>
>
>
> Hi Jim,
>
>
>
> It seems we have two use cases where this is relevant:
>
>
>
> 1) Change of ownership without reprovisioning the pledge (and using
> symmetric keys)
>
> 2) Failure of JRC
>
>
>
> Case (1): reuse of PIV can be avoided by mandating the exchange of OSCORE
> mutable parameters.
>
>
>
> Case (2): the context is lost and with it any hope to continue with the
> next PIV. I think that when JRC1 goes "boom", the network continues to
> operate, without even noticing as 6LBR is still operational. Then, we need
> to force all the nodes to rejoin and include PIV in the request, possibly
> by sending a command from the JRC2 to 6LBR of the network. But to send this
> command to 6LBR over OSCORE, JRC2 needs to use a PIV, which it doesn't
> know. At the moment, I don't see how we could trigger this network-wide
> rejoin securely, without relying on another communication channel...
>
>
>
> I will raise this during the 6TiSCH meeting tomorrow to request WG input
> on the best way to proceed. If you have a proposal, please let me know!
>
>
>
> Regarding the persistency issue: I suppo

Re: [6tisch] 6tisch minimal -- when can/should JP throw-away/blacklist pledges?

[Mališa Vučinić]

Michael,

See inline.

Mališa

On Fri, Jul 27, 2018 at 12:04 AM Michael Richardson 
wrote:

>
> (Listening to the youtube recording)
>
> Tero clarified the slide 8, about when the JP could throw away the
> neighbour
> state, and whether or not the JP could blacklist a pledge.
>
> The JP is not entirely stateless: it benefits from maintaining a neighbour
> state entry for the pledge.  However, depending upon how the stateless
> proxy
> token is implemented by the JP, it could essentially store some of the
> neighbour info for the pledge.
>
> The fundamental mis-communication between Tero and Malisa in the audio
> recording is because they are looking at the pledge from different points
> of
> view.  Tero is considering more situations where the Pledge is either
> malicious, or poorly configured, while Malisa is considering situations
> where
> the join fails for (less) non-malicious reasons, but the pledge is
> otherwise well
> behaved.
>

I don't fully agree with this summary: this was discussed in more details
within the "My comments to the draft-ietf-6tisch-minimal-security-06"
thread on the ML. See in particular the last response.



> a) the 6tisch-minimal draft is a one-round-trip process, but, the
> zero-touch process
>requires many round trips.
>

Sure, we discussed this on the same thread.


> b) re: two-step process: this is how the 2014-era join process was going to
>work, with the pledge saying hello, and the JRC would then drive the
>process.  We left that process.
>

I don't understand this comment, is this related to Tero's comment on
having the signaling from JRC to JP on whether the join was successful?


>
> c) the stateless token that needs to be returned to the JP in order to
> route
>the packet to the pledge, *could* be defined to include a "LAST" (FIN)
> flag.
>That would let the JP immediately garbage collect the neighbor entity.
>Whether the JP would then accept the pledge again in another round, is
>another question to me.
>

Yes, the main point here is that all of this does not by any means impact
interoperability and that JP may include in the stateless token whatever it
may need to operate fully statelessly. For example, if it has multiple
interfaces, uses non-default ports, ND entries, etc, etc.


>
> I don't really want the JP to have that kind of history, but I think it
> would
> be useful to have a communication from the edges to the root to indicate
> if they are having resources issues with leaf nodes.  This might be a ROLL
> level thing however, and could have a lot to do with balancing trees.
> In particular, DAOs  are only sent when a parent *accepts* a child, not
> (AFAIK) when they reject the child due to resource constraints.
>

Agreed, I think this approach should be advanced within the enhanced-beacon
draft//


>
> So in the spirit of ROLL's, when a tree-falls-and-nobody-hears-it, maybe we
> only need to solve the resource constraint problem when we run out of
> resources?
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
>
>
>
>
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Link_Layer_Key

[Mališa Vučinić]

Thanks for the clarification. I still have a couple of misunderstandings,
see inline.

Mališa

On Thu, Jul 19, 2018 at 12:47 AM Tero Kivinen  wrote:

> Mališa Vučinić writes:
> > Thanks Tero for the proposal. Is the current "key_usage" registry enough
> to
> > fully configure the security tables for the non-index modes?
>
> I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e.,
> multicast/broadcast keys which are owned by somebody. In the KeyIdMode
> 1 the owner is implicit (usually coordinator or similar well known
> node on the network), in case of KeyIdModes 2 and 3 it is explicit. So
> any of those modes can be used with any ke
> y usage.
>

Ok, I understand this better now, thanks!


>
> For pairwise (KeyIdeMode 0) things are bit different, for example
> sending beacons using pairwise keys is not really useful. So for
> pairwise keys key usages like 6TiSCH-K2-* are something that are
> usuful.
>

I see what you mean. Essentially, key usage will in this case signal to the
node that it should use this pairwise key to send DATA and ACKs.

But my question is related to the signaling of the destination peer.

You say:

For KeyIdMode 0 (pairwise keys), the key_index is set to 0, and
key_source is omitted. The key_index 0 is invalid for other modes, and
KeyIdMode 0 do not have key_index, so this will allow us to transmit
pairwise keys between the peers (the addresses needs to be taken from
the MAC header).


I don't understand the part where "addresses need to be taken from the MAC
header". Node A has neighbors B, C, D, and it receives a pairwise
Link_Layer_Key from the JRC. It needs to know to what node it will use that
key to transmit to: B, C, or D. The JRC should in this case, I suppose,
send 3 different keys, each with a different "destination". I am missing
this destination part.

Similar when node A receives a frame, if it comes from B, it decrypts it
with the corresponding key that the JRC indicated for node B. Is my
understanding correct? If no, discard the text below :-)

If so, we would just need to use "key_source" in this case as well, renamed
perhaps, to carry the address of the destination peer.

All the other modes that you proposed seem still to work.

The proposed change for KeyIdMode 0 is : "key_index" is set to 0,  "key_source"
is present. Can you confirm this works?
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Thanks Jim for working on this! When you have time, please drop us a line
with the proposed solution.

Mališa

On Wed, Jul 18, 2018 at 2:13 PM Jim Schaad  wrote:

> I think that I have a solution that could be implemented at the cost of
> one additional round trip the first time the JRC wants to update the
> endpoint.
>
>
>
> Jim
>
>
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Tuesday, July 17, 2018 1:22 PM
>
>
> *To:* Jim Schaad 
> *Cc:* 6tisch@ietf.org
>
> *Subject:* Re: Review draft-ietf-6tisch-minimal-security
>
>
>
> Hi Jim,
>
>
>
> It seems we have two use cases where this is relevant:
>
>
>
> 1) Change of ownership without reprovisioning the pledge (and using
> symmetric keys)
>
> 2) Failure of JRC
>
>
>
> Case (1): reuse of PIV can be avoided by mandating the exchange of OSCORE
> mutable parameters.
>
>
>
> Case (2): the context is lost and with it any hope to continue with the
> next PIV. I think that when JRC1 goes "boom", the network continues to
> operate, without even noticing as 6LBR is still operational. Then, we need
> to force all the nodes to rejoin and include PIV in the request, possibly
> by sending a command from the JRC2 to 6LBR of the network. But to send this
> command to 6LBR over OSCORE, JRC2 needs to use a PIV, which it doesn't
> know. At the moment, I don't see how we could trigger this network-wide
> rejoin securely, without relying on another communication channel...
>
>
>
> I will raise this during the 6TiSCH meeting tomorrow to request WG input
> on the best way to proceed. If you have a proposal, please let me know!
>
>
>
> Regarding the persistency issue: I suppose you refer to section
> https://tools.ietf.org/html/draft-ietf-core-object-security-13#section-7.5 ,
> i.e. Section 7.5.1 of OSCORE-13, that states:
>
>
>
> To prevent reuse of Sender Sequence Numbers, an endpoint may perform the
> following procedure during normal operations: o Before using a Sender
> Sequence Number that is evenly divisible by K, where K is a positive
> integer, store the Sender Sequence Number in persistent memory. After boot,
> the endpoint initiates the Sender Sequence Number to the value stored in
> persistent memory + K. Storing to persistent memory can be costly. The
> value K gives a trade-off between the number of storage operations and
> efficient use of Sender Sequence Numbers.
>
>
>
> Currently, Section 8.1.1. of *draft-ietf-6tisch-minimal-security* states:
>
>
>
> Implementations MUST ensure that mutable OSCORE context parameters (Sender
> Sequence Number, Replay Window) are stored in persistent memory. A
> technique that prevents reuse of sequence numbers, detailed in Section
> 6.5.1 of [I-D.ietf-core-object-security], MUST be implemented. Each update
> of the OSCORE Replay Window MUST be written to persistent memory.
>
>
>
> In the text above, there is a typo:
>
> s/Section 6.5.1/Section 7.5.1
>
>
>
> Let me know if I am missing something else to add regarding this.
>
>
>
> Mališa
>
>
>
> On Tue, Jul 10, 2018 at 3:20 PM Jim Schaad  wrote:
>
>
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Friday, June 29, 2018 12:34 PM
> *To:* Jim Schaad 
> *Cc:* 6tisch@ietf.org; draft-ietf-6tisch-minimal-secur...@ietf.org
> *Subject:* Re: Review draft-ietf-6tisch-minimal-security
>
>
>
> Hi Jim,
>
>
>
> Thanks a million for going through the document. Regarding the problem you
> outline where the pledge first joins to JRC1 and then later to JRC2, this
> would correspond to the change of ownership of the pledge, without going
> through the trouble of re-provisioning the pledge  with a new PSK/security
> context. While this use case is not ideal to solve with PSKs as JRC2 would
> then need to fully trust JRC1,  do you think it would be sufficient to
> require in such a case that apart from the PSK, the JRC1 would need to
> communicate to JRC2 the full state of the security context, including
> JRC1’s sequence number (ie all mutable parameters)? JRC2 would then simply
> continue with the next seqno, avoiding reuse.
>
>
>
> [JLS] Yes that does avoid the issue.  My worry is that JRC1 might go boom
> and that information is no longer available.  Given that JRC2 would then be
> the same company, there is no problem with needing to re-provision from a
> trust point.  But there may be from a security prospective of re-using IVs.
>
>
>
> Regarding your minor issue, could you check if the text in Section 8.1.1
> covers what you had in mind?
>
>
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-8.1
>
>
>
> [JLS] No 

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

On Tue, Jul 17, 2018 at 10:25 PM Tero Kivinen  wrote:

> If JRC restarts and looses track who is in the network, then it cannot
> send updaes, as it does not know who is in the network. I.e., in that
> case all nodes need to rejoin.
>

How do we detect that JRC restarted at 6LBR if JRC is in the Cloud? I guess
we need to assume that the JRC knows the address of 6LBR upon restart and
can contact it, but this is then related to the issue Jim Schaad raised on
reuse of Partial IVs on the application layer.

If JRC rekeys *only* the 6LBR who starts using the new key for all outgoing
traffic, all the nodes in the network will fall out of sync which will
force them to rejoin, obtain new key and new short addresses. Seems to be
sufficient?


>
> On the other hand if JRC wants to clean up some address space, for
> example if it has given out lots of short address without expirity
> time, and then it cannot take those address back to use ever even if
> the node has already been silent for few weeks. In that case if it
> does the rekey of the network then after the old keys are no longer in
> use anywhere it can start reusing the short addresses for those nodes,
> it did not send key update for.
>

So I guess this would be equivalent to the case of expelling a node from
the network, i.e. rekeying everyone but that node.



> It cannot use the fact that node did not ack the key update sent to it
> to indicate that node has gone from the network, as it is possible
> that the ack got lost, even when the key update actually reached the
> node. So it needs to have list of nodes it will send key updates, and
> those it does not send it, are something it can remove from the
> address pool after the key update.
>

Agreed.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

On Wed, Jul 18, 2018 at 2:36 AM Tengfei Chang 
wrote:

> Hi Malisa and Tero,
>
> Thanks for answering my question! It is clear to me!
>
> I don't fully understand. Do you mean in which case would a node send
>> another Join Request, if it has already completed the join process sometime
>> before and obtained the L2 encryption keys?
>>
>
> My question is exactly what you rephrased :-)
>

For example, if the node goes to sleep for some prolonged period of time
(think energy-harvesting nodes), or falls out of sync, and the L2 keys have
changed in the meantime. Node can detect this by not being able to
authenticate EBs.

Or also, in the draft, we mandate the node to do this if its short address
expired, before JRC was able to send a Parameter Update Request message
with the new address.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

(snip)

On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen  wrote:

>
> I would like at least some text in the security considerations section
> warning about the common wrong ways of generating PSK. The IoT vendors
> are quite often care more about the time to market than the security,
> thus do use unsafe practices as they do not know better.
>

That's fine for me. I will get back to you with specific text/commit when I
implement this.


>
> > In section 5.3.2 there is text saying:
> >
> > The JP operates as the application-
> >layer proxy, and does not keep any state to forward the message.
> >
> > This is not completely true. It needs to keep state to know when the
> > pledge starts joining process and it needs to keep it until the
> pledge
> > finishes it as it needs to allow pledge to send unencrypted and
> > unauthenticated frames through it as explained in section 6.
> >
> > I.e., JP do store state for each pledge, at least for the secExempt.
> > Also during this phase the pledge will be using its extended address,
> > so that is also used by the JP to know which pledges are in progess
> of
> > joining.
> >
> > The point that you bring up here is essentially an implementation
> > decision. There is nothing that prevents a JP from creating an
> > ephemeral unsecured ND entry and setting secExempt for it in MAC
> > security tables once JP receives a CoAP response with
> > Stateless-Proxy option set. The value of Stateless-Proxy option is a
> > byte string meaningful only to the JP, so JP can encode there
> > whatever it may need to operate statelessly. Off the top of my head,
> > I don't really see what else it would need to transport in
> > Stateless-Proxy except for the pledge's EUI-64.
>
> Actually if you follow the 802.15.4 and someone sends you unsecured
> frame the security processing will reject it with
> IMPROPER_SECURITY_LEVEL error (section 9.2.4 f) of 802.15.4-2015). The
> MAC will then indicate (section 6.7.2) this to the upper layer with
> MLME-COMM-STATUS.indication primitive which will get the addresses
> etc, but does not get the actual frame. Then the upper layer can
> install the secExempt flag in the security tables (== creates state),
> and then next packet from the same node will be allowed to go through
> the security processing. So there is always some state stored, just to
> be able to receive the unprotected frame.
>
> Note, that node is allowed NOT to ack the incoming frame if the
> security processing fails, so this second frame will be MAC layer
> retransmit, not upper layer retransmit.
>

Assumption (1): JP has the information that the join process is *allowed*.
I see this as a centralized decision, JP simply enforces it.

Assumption (2): JP removes all the state about the pledge, including L2
security table entry with secExempt set, as soon as it forwards a packet
originating from the pledge towards the JRC.

Assumption (3): JP adds an entry with secExempt set for the pledge as soon
as it receives a Stateless-Proxy. Issue: When does JP remove this entry?
See below.

You seem to agree that there is no problem for the frames going from JP to
the pledge. Right?

The issue you raise on keeping state at JP is to allow the pledge to sends
frame(s) to the JP.

Let me try to summarize:

(1) The very first frame sent by the pledge, in a fully-compliant
implementation of 802.15.4 security processing gets rejected no matter
what. A logical choice for the JP is then *not* to ACK this frame at L2.

(2) Upper layer of JP then adds an entry for the source address of the
rejected frame and sets the secExempt for it. (because join process is
allowed)

(3) L2 retransmission of the frame dropped in (1) is sent by the pledge.
The frame falls into the secExempt case while processing at JP and is
passed to the upper layer.

(4) JP keeps the entry with secExempt (i.e. state) *until* an upper layer
creates a packet destined for the JRC with Stateless-Proxy set. In that
moment, no more state for the pledge exists at JP. Issue: CoAP message sent
by the pledge is malformed and JP discards it, DoS attack where pledge does
ND but does not send Join Request. It would therefore be prudent to expire
this entry at JP after a short timeout.

For the upper-layer protocol, this seems to degrade performance in case a
pledge generates a frame  *after* JP has already forwarded one packet from
the pledge to the JRC and used Stateless-Proxy. In that case, pledge will
need to do one L2 retransmission to get the packet processed by JP. Agreed?

For CoJP, this will be the case for CoAP-layer (CoJP-layer to be precise)
retransmissions. You are also worried for future extensions where pledge
sends more than one *packet* (multiple L2 fragments are OK) before getting
a response from the JP.

The question now is when to remove the entry with secExempt for pledge at
JP, once it was installed from Stateless-Proxy. From the security point of
view, the 

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Hi Jim,

It seems we have two use cases where this is relevant:

1) Change of ownership without reprovisioning the pledge (and using
symmetric keys)
2) Failure of JRC

Case (1): reuse of PIV can be avoided by mandating the exchange of OSCORE
mutable parameters.

Case (2): the context is lost and with it any hope to continue with the
next PIV. I think that when JRC1 goes "boom", the network continues to
operate, without even noticing as 6LBR is still operational. Then, we need
to force all the nodes to rejoin and include PIV in the request, possibly
by sending a command from the JRC2 to 6LBR of the network. But to send this
command to 6LBR over OSCORE, JRC2 needs to use a PIV, which it doesn't
know. At the moment, I don't see how we could trigger this network-wide
rejoin securely, without relying on another communication channel...

I will raise this during the 6TiSCH meeting tomorrow to request WG input on
the best way to proceed. If you have a proposal, please let me know!

Regarding the persistency issue: I suppose you refer to section
https://tools.ietf.org/html/draft-ietf-core-object-security-13#section-7.5 ,
i.e. Section 7.5.1 of OSCORE-13, that states:

To prevent reuse of Sender Sequence Numbers, an endpoint may perform the
following procedure during normal operations: o Before using a Sender
Sequence Number that is evenly divisible by K, where K is a positive
integer, store the Sender Sequence Number in persistent memory. After boot,
the endpoint initiates the Sender Sequence Number to the value stored in
persistent memory + K. Storing to persistent memory can be costly. The
value K gives a trade-off between the number of storage operations and
efficient use of Sender Sequence Numbers.


Currently, Section 8.1.1. of *draft-ietf-6tisch-minimal-security* states:

Implementations MUST ensure that mutable OSCORE context parameters (Sender
Sequence Number, Replay Window) are stored in persistent memory. A
technique that prevents reuse of sequence numbers, detailed in Section
6.5.1 of [I-D.ietf-core-object-security], MUST be implemented. Each update
of the OSCORE Replay Window MUST be written to persistent memory.


In the text above, there is a typo:
s/Section 6.5.1/Section 7.5.1

Let me know if I am missing something else to add regarding this.

Mališa

On Tue, Jul 10, 2018 at 3:20 PM Jim Schaad  wrote:

>
>
>
>
> *From:* Mališa Vučinić 
> *Sent:* Friday, June 29, 2018 12:34 PM
> *To:* Jim Schaad 
> *Cc:* 6tisch@ietf.org; draft-ietf-6tisch-minimal-secur...@ietf.org
> *Subject:* Re: Review draft-ietf-6tisch-minimal-security
>
>
>
> Hi Jim,
>
>
>
> Thanks a million for going through the document. Regarding the problem you
> outline where the pledge first joins to JRC1 and then later to JRC2, this
> would correspond to the change of ownership of the pledge, without going
> through the trouble of re-provisioning the pledge  with a new PSK/security
> context. While this use case is not ideal to solve with PSKs as JRC2 would
> then need to fully trust JRC1,  do you think it would be sufficient to
> require in such a case that apart from the PSK, the JRC1 would need to
> communicate to JRC2 the full state of the security context, including
> JRC1’s sequence number (ie all mutable parameters)? JRC2 would then simply
> continue with the next seqno, avoiding reuse.
>
>
>
> [JLS] Yes that does avoid the issue.  My worry is that JRC1 might go boom
> and that information is no longer available.  Given that JRC2 would then be
> the same company, there is no problem with needing to re-provision from a
> trust point.  But there may be from a security prospective of re-using IVs.
>
>
>
> Regarding your minor issue, could you check if the text in Section 8.1.1
> covers what you had in mind?
>
>
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-8.1
>
>
>
> [JLS] No not really, it would be better covered by pointing to
> https://tools.ietf.org/html/draft-ietf-core-object-security-13#section-5.1
> esp 5.1.1 where they give an algorithm for preventing the problem.
>
>
>
> Mališa
>
>
>
>
>
> On Fri, 29 Jun 2018 at 21:08, Jim Schaad  wrote:
>
> I think I have found a security problem with the document as it currently
> stands. I also have a minor request.
>
> Minor Request:
> I think it might be advisable to explicitly state that the derived context,
> or at least the last partial IV used is stored in non-volatile storage
> after
> use.  (Could just do an update to value + n when you approach that limit.)
>
> Major Problem:
>
> I believe that there is a problem in that there is a designed re-use of
> partial IV values.
>
> 1.  A pledge completes a join operation with JRC1.  There are no problems
> here as the partial IV is correctly changed.  This uses a numbe

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

Hi Tengfei,

Thanks for your review! See my responses and proposed resolutions inline.

Mališa

On Mon, Jul 9, 2018 at 3:44 PM Tengfei Chang  wrote:

> Hi Malisa,
>
> I just reviewed the draft and have several comments below.
>
> *Comment 1: *
> *--*
> In section 9.3.2 when describing link-layer key set:
>
> *When 6LBR receives this*
> *parameter, it MUST remove any old keys it has installed from the*
> *previous key set and immediately install and start using the new*
> *keys for all outgoing and incoming traffic. When a non-6LBR node*
> *receives this parameter, it MUST install the keys, use them for*
> *any incoming traffic matching the key identifier, but keep using*
> *the old keys for all outgoing traffic. A non-6LBR node accepts*
> *any frames for which it has keys: both old and new keys. Upon*
> *reception and successful security processing of a link-layer frame*
> *secured with a key from the new key set, a non-6LBR node MUST*
> *remove any old keys it has installed from the previous key set.*
> *From that moment on, a non-6LBR node MUST use the keys from the*
> *new key set for all outgoing traffic.*
>
> I understand this is for the case when a packet containing the*
> link-layer key set parameter* is received, how the node should handle it.
> This sounds to me like there is a proactive packet from JRC requesting to
> update the key settings.
>

Yes.


> Hence I have two questions:
> 1. in what case JRC or some entity will send such packet?
>

For example if a JRC detects that some node in the network misbehaves,
generates large amount of traffic, is misconfigured or similar. The JRC
would then simply need to rekey the network, providing the new key to every
node except the one that it wants to see expelled.

Then, Tero on another thread also mentioned a couple of cases where this is
necessary, e.g. if JRC restarts.

Finally, note also the good cryptographic practice on rotating the keys for
security reasons: e.g. to limit the amount of traffic encrypted under a
given key; in case the old key was compromised for any reason, etc.


> 2. if the parameter is from a Join response corresponding to a Join
> request sent by the node before, (this implied by Table 2: Join Response
> map labels), then what's the reason a node needs to send Join request if it
> already has key configured (not the PSK).
>

I don't fully understand. Do you mean in which case would a node send
another Join Request, if it has already completed the join process some
time before and obtained the L2 encryption keys?


> Maybe this is just for me that I don't understand the background of this
> paragraph. But I just ask in case not.
>
> *Comment 2:*
> *--*
> Another comment, you talked before, is the required parameters for the
> 6LBR pledge.
> Table 2 listed the parameters in the configuration object. It's generally
> for non-6LBR pledge.
> I made a pre-list for those parameters that required by 6LBR pledge. They
> are from the information that EB should carry.
>
> 1. time slot template
> 2. channel hopping template
> 3. number of slotframes
>
>- slotframe handler
>- slotframe length
>   - number of links
>   - link information (slotoffset, channeloffset, type)
>
>
Thanks for bringing this up. As discussed off-line, I agree with this
change as it would enable the bootstrapping of a 6LBR pledge, at a very low
cost.

When discussing this with Xavi Vilajosana, he raised a point that adding
these parameters relevant only to the 6LBR pledge would reduce the
readability of the spec for people who just care about implementing the
non-6LBR pledge.

As a resolution, I propose to define separate data structures for when 6LBR
pledge joins and when non-6LBR pledge joins, instead of mixing all the
parameters together in a Configuration structure.

Let me know if this works!


Is there anything else we should also add?
>

I will bring this up tomorrow during the meeting to ask for WG input if
there are any other parameters that could be useful for 6LBR joining.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] comments to the “Minimal Security Framework for 6TiSCH” document

[Mališa Vučinić]

Hi Xavi,

Many thanks for sending this review. See my responses inline.

Mališa

On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen 
wrote:

> Hi,
>
> I reviewed the ”Minimal Security Framework for 6TiSCH” document.
>
> Here some comments that have not been mentioned by others.
>
> 1) I miss some section describing how errors are handled at the cbor
> level. This is what if the received Configuration option is wrong, e.g
> there is an element in the map with an unsupported value.
> Or even what if the Join Request contains a wrong role number?. Would be
> good to mention what are the actions taken by the JRC upon receiving a Join
> Request with an incorrect CBOR element. Also from the
> pledge point of view, what if the Join Response contains an unsupported
> parameter. I guess the same will apply for Update Request, from the 6N
> point of view.
>

This makes perfect sense. We focused on error handling in case security
errors are detected on the OSCORE layer, and somehow neglected the
parameter semantics.

My proposal is to add a new CBOR parameter to CoJP objects, e.g.
"error_code" carrying an array of errors codes that were detected.

With that, we'd need to make a table of most common errors on the CoJP
level.

Does that make sense?


>
> 2) The JRC is the origin of Parameter Update Requests which may contain
> for example rekeying material or a new short address. The draft needs to
> describe what happens if the destination 6N is not reachable.
> I understand that there will be a timeout and possibly will retry later or
> do not try anymore (this has to be stated).
> What if the node is no more in the network? when the JRC will stop sending
> the short address updates? When it will remove that node from its
> "database"?
>

I discuss this also during the meeting tomorrow. What you propose is indeed
something that an implementor must consider but I am not sure if we want to
specify any particular behavior in the draft, since this seems to be more
of a policy.

I can add explicit text discussing this issue, but leaving it up to the
implementation of the JRC to decide how transmission errors of CoAP CON
message, that is Parameter Update Request, should be handled. What do you
think?



>
> kind regards
> Xavi
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajos...@uoc.edu 
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> [image: Universitat Oberta de Catalunya]
> ­
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić]

Hi Tero,

Thank you for this extensive review! See my responses inline.

Mališa

On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen  wrote:

> In section 3 there is text saying:
>
>The "network identifier" uniquely identifies the 6TiSCH network in
>the namespace managed by a JRC.  Typically, this is the 16-bit
>Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
>
> Note, that the PAN ID is not stable. The PAN coordinator is expected
> to change to use new PAN ID if it detect another network using the
> same PAN ID, i.e., if there is PAN ID conflict. See section 6.3.2 of
> the IEEE 802.15.4-2015.
>
> Because of this it might be better to use something else as PAN ID if
> stable network identifier is needed. Also in quite many cases the PAN
> ID is not known beforehand, so configuring the PAN ID to the pledge is
> challenging, as is describied in the section 4.
>
> Using something like Network ID from the
> draft-richardson-6tisch-enrollment-enhanced-beacon, would provide
> better alternative.
>

Good point: we use the term "network_identifier" for precisely this purpose
-- allow future extensions where an extended ID from e.g.
draft-richardson-6tisch-enrollment-enhanced-beacon can be used. The current
text in the draft leaves open what ID is actually used, and as such PAN ID
is supported. I wouldn't want to preclude the use of PAN ID now, since this
is how most of the people currently deploy their networks.

Would a following resolution work for you:

OLD:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4]. Companion documents can specify the use of a
different network identifier for join purposes, but this is out of scope of
this specification.  Such identifier needs to be carried within Enhanced
Beacon (EB) frames.

NEW:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4].  *However, PAN ID is not considered a stable
network identifier as it may change during network lifetime if a collision
with another network is detected.* Companion documents can specify the use
of a different network identifier for join purposes, but this is out of
scope of this specification.  Such identifier needs to be carried within
Enhanced Beacon (EB) frames.

In section 4 there is text saying:
>
> o Pre-Shared Key (PSK).  The JRC additionally needs to store the
>   pledge identifier bound to the given PSK.  The PSK SHOULD be at
>   least 128 bits in length, generated uniformly at random.  It is
>   RECOMMENDED to generate the PSK with a cryptographically secure
>   pseudorandom number generator.  Each (6LBR) pledge SHOULD be
>   provisioned with a unique PSK.
>
> This text is fine, but knowing that most of the vendors in this space
> have been known to use unsafe methods like scrambling, encrypting,
> hashing, or macing serial number or EUI-64 address to generate "random
> unique PSKs" (or simply using fixed PSK for all devices), it might be
> good idea to provide bit more emphasis on the unique properly
> generated PSK, even when it is outside the actual scope of this
> document. Or add something like that to the security considerations
> section.
>

Göran Selander also raised an issue about this text. My response was:

> I would like to avoid referencing any particular method of generating the
PSK, I think that it would be enough to stress that the PSK that ends up
being provisioned to the pledge should meet certain statistical properties
(e.g. unpredictability, entropy).

Is this OK for you?


> In section 5.2 there is text saying "How JP accepts these unprotected
> frames is discussed in Section 6. ", but this same thing also applies
> to the section 5.3.1 too. I.e., the Join request from the pledge to JP
> is also unauthenticated and unencrypted.
>
> Perhaps that should be noted also there.
>

Sounds good.

In section 5.3.2 there is text saying:
>
> The JP operates as the application-
>layer proxy, and does not keep any state to forward the message.
>
> This is not completely true. It needs to keep state to know when the
> pledge starts joining process and it needs to keep it until the pledge
> finishes it as it needs to allow pledge to send unencrypted and
> unauthenticated frames through it as explained in section 6.
>
> I.e., JP do store state for each pledge, at least for the secExempt.
> Also during this phase the pledge will be using its extended address,
> so that is also used by the JP to know which pledges are in progess of
> joining.
>

The point that you bring up here is essentially an implementation decision.
There is nothing that prevents a JP from creating an ephemeral unsecured ND
entry and setting secExempt for it in MAC security tables once JP receives
a CoAP response with Stateless-Proxy option set. The value of
Stateless-Proxy option is a byte string meaningful only to the JP, so JP
can encode there whatever it may need to 

Re: [6tisch] preliminary 6TISCH@IETF102 agenda

[Mališa Vučinić]

Hi Thomas, Pascal,

For the minimal-security slot, if possible, I would need an additional 5-10
minutes. We received lots of good reviews and I would like to get input on
some of the issues during the meeting.

Let me know if feasible.

Mališa

On Tue, 3 Jul 2018 at 14:28, Thomas Watteyne 
wrote:

> All,
>
> You will find a (preliminary) agenda for the 6TiSCH WG meeting at:
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-6tisch-02
>
> Please flag issues.
>
> Pascal  & Thomas
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC on the “Minimal Security Framework for 6TiSCH” document

[Mališa Vučinić]

Hello Göran,

Thanks for the review.

See my responses inline.

Mališa

On Wed, Jun 27, 2018 at 3:46 PM Göran Selander 
wrote:

> Dear WG, Pascal, Thomas,
>
> I have reviewed draft-ietf-6tisch-minimal-security-06 and have the
> following feedback:
>
>
>
> Section 3
>
>
> "pledge identifier"
>
>
> The assumptions and application of OSCORE made in this draft requires that
> the pledge identifier is globally unique. Although the first sentence
> states that the pledge identifier uniquely identifies the pledge, there
> is no normative text in this section and it may not be understood that
> uniqueness is a requirement.
>

(For this discussion, pledge identifier == ID Context):

In oscore-13, Section 3.3 states:

"To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID
Context, Sender ID) MUST be unique, i.e. the pair (ID Context, Sender ID)
SHALL be unique in the set of all security contexts using the same Master
Secret and Master Salt."

While we have fixed the Sender ID to 0x00, I believe this OSCORE
requirement is still valid in our case. I am missing the need for requiring
global uniqueness if the ID Context is unique in the "set of all security
contexts using the same Master Secret and Master Salt". What am I missing?

That said, EUI-64 is globally unique and when used as the pledge identifier
/ ID Context, results in unique (Master Secret, Master Salt, ID Context,
Sender ID) no matter if the Master Secret is reused.

My point is that this global uniqueness of EUI-64 comes as a nice-to-have
when provisioning the devices, but that a random string that meets the
requirement cited above is still good enough (and increases privacy by not
sending the vendor-specific EUI-64).

If my understanding on the above is correct, I can clarify the text.


 The last sentence says that the identifier may be "e.g. a random string",
> without any further details. Please include all relevant requirements on
> the pledge identifier in this section so readers can get the complete
> picture, make a reference to a security consideration providing the
> explanation (see below), and apply the requirements to the example with
> random strings.
>

Yes, makes sense to clarify this in security considerations referring to
the OSCORE uniqueness requirements.


>
>
> Section 4
>
>
> "It is RECOMMENDED to generate the PSK with a cryptographically secure
> pseudorandom number generator."
>
>
> There are a number things to consider when generating random numbers.
> Consider replace this specific recommendation about one such component with
> a reference to some existing specification containing recommendations, for
> example NIST SP800-90A Rev 1 (2015):
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
>

I think that this recommendation should indeed be rephrased. I would like
to avoid referencing any particular method of generating the PSK, I think
that it would be enough to stress that the PSK that ends up being
provisioned to the pledge should meet certain statistical properties (e.g.
unpredictability, entropy). What do you think?


>
>
> Section 8.1
>
>
> There is no mention of replay protection mechanism. Is the default replay
> window type and size assumed? (Other default values of OSCORE security
> context are explicitly stated in the draft.)
>

Yes, default replay protection of OSCORE is assumed with the nota bene on
persistency that is already there in Section 8.1.1. I will make this more
apparent.

>
> "Failure to comply will break the confidentiality property of the
> Authenticated Encryption with Associated Data (AEAD) algorithm due to the
> nonce reuse."
>
>
> Nonce reuse also causes loss of authenticity and integrity,
> i.e.essentially breaks the security guarantees.
>

Yes, of course, will state this explicitly.


> The importance of not reusing the nonce with the same key may be repeated
> in the security considerations.
>

I am not sure if discussing nonce uniqueness with a given key really
belongs to this document. To me, that really belongs to OSCORE. That said,
I think it would be really good to add, as you suggest, a discussion in
security considerations on the uniqueness of OSCORE parameters, referring
to the OSCORE document.


>
>
> "This OSCORE security context is used for initial joining of the (6LBR)
> pledge, where the (6LBR) pledge acts as a CoAP client, as well as for any
> later parameter updates, where the JRC acts as a CoAP client and the joined
> node as a CoAP server, as discussed in Section 9.2
> 
> .  A (6LBR) pledge is expected to have exactly one OSCORE security
> context with the JRC."
>
>
> This is correct, not specific to this application of OSCORE, but may be
> good for explaining how it works. In the spirit of explaining OSCORE and
> not specific to this application, you could emphasize that the same Sender
> Context is always used when sending, independently of if the node 

[6tisch] Fwd: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages

[Mališa Vučinić]

Forwarding this review to the ML as part of the WGLC.

-- Forwarded message -
From: William Vignat 
Date: Tue, Jul 3, 2018 at 3:03 PM
Subject: Concerns about the CoJP message size, the need for BLOCK-WISE
options and the use of NON-confirmable messages
To: draft-ietf-6tisch-minimal-secur...@ietf.org <
draft-ietf-6tisch-minimal-secur...@ietf.org>


Hello,


I already opened an issue on the bitbucket, however since this is not only
an editorial matter I seem to remember from the IETF guidelines that a mail
is also necessary.

(You will find the same text bellow, however I strongly recommend you to
view this issue and answer directly on bitbucket here
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the
because
the markdown formatting will be way better. )


Sincerely,

William Vignat




--


Hello,

First, I wanted to thank you for all the efforts you put into this draft,
its simplicty and reliance on already existing technologies truly are among
its greatest assets in my opinion.

After finishing the test implementation of the latest OSCORE draft, I am
starting to do the same with this draft, and while testing the
serialization of messages, I noticed the large message size, which to be
honest I hadn't expected while just reading this draft.

You will find bellow a detailed estimation of both the available CoAP
message size using secured 802.15.4 messages and the CoJP size (at the CoAP
level).

Without getting into the details so far, the conclusion, provided my
predictions and calculations are good enough, is that although the CoJP
request is surprisingly large, it manages to (barely sometimes, depending
on the configuration used) be held into one unique 802.15.4 message.
However the CoJP response will almost always overflow from such a message,
and a way to fragment this message would be needed.

Now the BLOCK-WISE option is being devised just for this, however it is not
really meant to be used with non-confirmable messages for obvious reasons
such as packet loss...

I understand the reasonning behind making the request a NON-confirmable
message to reduce the strain on the JP and the potential DoS, however maybe
the answer should at least be a CONfirmable message so that it can easilly
be fragmented using BLOCK-WISE (since the message is "flagged" by the
stateless-proxy option we can make it so that the JP doesn't store any
state even if the response is CON and just passes the messages along
whether they are CON or NON)?

Since none of this is mentionned in the draft, I would like to know if a
thought has been given to this particular problem, and if so if a solution
that I'm not seeing has been chosen ?


Thank you in advance,

Sincerely




**Rough payload size assessment:**

The maximum 802.15.4 message size is **127B**.

Lets take the example of a CoJP message being relayed on the network
(during one of multiple hops), thus being protected both by OSCORE at the
CoAP level, and by the L2 security that secures all the exchanges inside
the network.

**Typical L2 (802.15.4) overhead with:**

- an 8-byte(medium security) MIC
- a 6-byte aux security header by relying on the fact that both addresses
are present in the frame and thus KeyIdMode 0x00 or 0x01 can be used
- 8-byte MAC addresses since 2-byte short addresses at the L2 level are
currently not supported in a lot of implementations, among which OpenWSN,
but we don't use 10-byte addresses because we assume no PAN-id


In the end:

Frame control: 2 | Sequence nb: 1 | DstMAC@: 8 | SrcMAC@: 8 | Aux security
header: 6 |  ...PAYLOAD...  | MIC: 8 | CRC: 2

TOTAL: **35B**





**Typical IPv6 overhead with:**

- a [2-byte compressed header](
https://tools.ietf.org/html/rfc6282#section-3.1.1 ) (not counting the
addresses)
- 8-byte IPv6 addresses (max would be 16 each, best case could optimize
further by distributing addresses so that the common part can be ommited),
but in this case, let's assume we don't specify the network, and we just
specify the 8 bytes that correspond to the MAC address.


In the end:

LOWPAN_IPHC: 2 | Src IP @: 8 | Dst IP @: 8 ||
TOTAL: **18B**

**UDP overhead**:   8B

***Total message overhead: 61B***

***Thus leaving:  66B***




**Now let's look at the size of the CoAP requests and response we actually
want to send:**

**For all the OSCORE processing, if you want to verify the content of the
messages by decrypting them, the following inputs have been used:**

- Master secret:{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
- Master salt: 
- Client(pledge) sid: {0x00}
- Server(JRC) sid: {0x4a, 0x52,0x43}
- The chosen 8-byte pledge identifier serving as kid/id-context was
{0xaa,0xbb,0xcc,0xdd, 0xee,0xff,0x0a,0x0b}

**/!\ NOTE** that the newest version of the OSCORE draft, available

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

[Mališa Vučinić]

Hi Jim,

Thanks a million for going through the document. Regarding the problem you
outline where the pledge first joins to JRC1 and then later to JRC2, this
would correspond to the change of ownership of the pledge, without going
through the trouble of re-provisioning the pledge  with a new PSK/security
context. While this use case is not ideal to solve with PSKs as JRC2 would
then need to fully trust JRC1,  do you think it would be sufficient to
require in such a case that apart from the PSK, the JRC1 would need to
communicate to JRC2 the full state of the security context, including
JRC1’s sequence number (ie all mutable parameters)? JRC2 would then simply
continue with the next seqno, avoiding reuse.

Regarding your minor issue, could you check if the text in Section 8.1.1
covers what you had in mind?

https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-8..1

Mališa


On Fri, 29 Jun 2018 at 21:08, Jim Schaad  wrote:

> I think I have found a security problem with the document as it currently
> stands. I also have a minor request.
>
> Minor Request:
> I think it might be advisable to explicitly state that the derived context,
> or at least the last partial IV used is stored in non-volatile storage
> after
> use.  (Could just do an update to value + n when you approach that limit.)
>
> Major Problem:
>
> I believe that there is a problem in that there is a designed re-use of
> partial IV values.
>
> 1.  A pledge completes a join operation with JRC1.  There are no problems
> here as the partial IV is correctly changed.  This uses a number of partial
> IVs from pledge space.
>
> 2.  JRC1 performs a number of parameter updates.  This uses a number of
> partial IV values from the JRC1 side.
>
> 3.  JRC1 disappears for some reason leaving no traces behind.
>
> 4.  The pledge is then told to do a second join and it attaches to JRC2.
> Since the pledge keeps the partial IV value there are no problems.
>
> 5.  JRC2 performs a parameter update.  Since JRC2 does not know how many
> messages were sent from JRC1, it does not know what to set the partial IV
> to
> and thus would reuse IV values.
>
> I believe that this could be addressed as follows:
>
> 1. The pledge keeps track of the last partial IV from a JRC
> 2.  When a pledge does a join, it sends that value to the JRC so that the
> JRC knows where to start generating messages.
>
> Jim
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-06.txt

[Mališa Vučinić]

All,

As per the discussions last weeks, I submitted the -06 version of the
minimal-security draft.

This -06 version will be used for the F-Interop 6TiSCH plugtest to be held
in Paris on 26-27 of June.

Kind regards,
Mališa


On Fri, May 25, 2018 at 7:23 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : Minimal Security Framework for 6TiSCH
> Authors : Malisa Vucinic
>   Jonathan Simon
>   Kris Pister
>   Michael Richardson
> Filename: draft-ietf-6tisch-minimal-security-06.txt
> Pages   : 38
> Date: 2018-05-25
>
> 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, a new Stateless-Proxy CoAP option, 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] On minimal-security

[Mališa Vučinić]

On Thu, 24 May 2018 at 20:44, Michael Richardson <mcr+i...@sandelman.ca>
wrote:

>
> Mališa Vučinić <malis...@gmail.com> wrote:
> > @Michael, @Christian
>
> > I am re-reading RFC7252, Section 5.7.2:
>
> okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules
> given in 7252.



Sure it is, every attempt was made to have JP just a regular CoAP proxy
with no application code. I claim that the current text is fully compliant
with RFC7252 proxy and also takes into consideration processing rules of
OSCORE-aware proxy.

It started as just a circuit proxy (i.e. algorithm gateway), but
> we wanted it to be stateless, so we (ab)used some CoAP things to do that.
> I never intended it go into the contents of the packet, interpret CoAP in
> any
> way.


It seems we have misunderstandings on this :-)


>
> >> Unless a proxy is configured to forward the proxy request to
> another proxy,
> >> it MUST translate the request as follows: the scheme of the request
> URI
> >> defines the outgoing protocol and its details (e.g., CoAP is used
> over UDP
> >> for the "coap" scheme and over DTLS for the "coaps" scheme.) For a
> >> CoAP-to-CoAP proxy, the origin server's IP address and port are
> determined
> >> by the authority component of the request URI, and the request URI
> is
> >> decoded and split into the Uri-Host, Uri- Port, Uri-Path and
> Uri-Query
> >> Options. This consumes the Proxy-Uri or Proxy-Scheme option, which
> is
> >> therefore not forwarded to the origin server.
>
> We don't use Proxy-URI or Proxy-Scheme.


Sure we do, we use Proxy-Scheme in order to keep OSCORE-aware proxy
processing to a minimum. See the section on the mappings of join protocol
messages to CoAP.


>
> > It seems to be OK, and doesn't prevent much of the CoAP proxy
> functionality
> > for other purposes. I am waiting for the confirmation from Christian
> of
> > there is any other RFC7272 pitfall with this before doing the
> changes in
> > the draft.
>
> > I kind of liked the 6tisch.arpa "thing", but no argument with
> ~13-byte
> > savings :-).
>
> I don't think we need it.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić]

All,

I resolved the issues we had open on minimal-security and reworked
editorially the document quite heavily. Since the protocol we define is
quite generic, I renamed it to "Constrained Join Protocol (CoJP)",
suggested pronunciation as "cojeep". Let me know if you dislike the new
name, or if you have a better suggestion.

I plan to publish -06 before EOB tomorrow, if you have any comments that
you would like to see in for -06, please send them to the list before.

The source of the document in Markdown is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/src/master/draft-ietf-6tisch-minimal-security.mkd


Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] On minimal-security

[Mališa Vučinić]

@Michael, @Christian

I am re-reading RFC7252, Section 5.7.2:

Unless a proxy is configured to forward the proxy request to another proxy,
> it MUST translate the request as follows: the scheme of the request URI
> defines the outgoing protocol and its details (e.g., CoAP is used over UDP
> for the "coap" scheme and over DTLS for the "coaps" scheme.) For a
> CoAP-to-CoAP proxy, the origin server's IP address and port are determined
> by the authority component of the request URI, and the request URI is
> decoded and split into the Uri-Host, Uri- Port, Uri-Path and Uri-Query
> Options. This consumes the Proxy-Uri or Proxy-Scheme option, which is
> therefore not forwarded to the origin server.
>

I suppose you are referring to this implicit configuration of the proxy
that would forward to the JRC anything received on a link-local address, if
the request does not have the Uri-Host option?

It seems to be OK, and doesn't prevent much of the CoAP proxy functionality
for other purposes. I am waiting for the confirmation from Christian of
there is any other RFC7272 pitfall with this before doing the changes in
the draft.

I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte
savings :-).

Mališa

On Sat, May 19, 2018 at 3:17 PM Michael Richardson 
wrote:

understood so far sar the CoAP URI host is the same as the http host:
> > header parameter. If I m correct then this is normally a string with
> > the dns name and port to reach the server. Without it, the proxy
> > wouldn’t know how to reach the server in the first place. Without
> it, a
> > multihomed server wouldn’t know which instance it reached. This is
> why
> > I understood it became mandatory in http 1.1.
>
> 1) apparently it's not mandatory in CoAP (I thought it was until a few
>minutes ago).We can save ~15 bytes here.
>
> 2) The proxy knows where the JRC is because it's been told the IP address
> of
>the JRC, either implicitely (it's the DODAG root, aka 6LBR), or
>explicitely via the response.
>
> Remember that we can type https://[fde4:8dba:82e1::1234]/ or, in this
> case,
> we want the pledge to say: coap://[fe80::1234]/j, which the Join Proxy
> forwards to coap://[fde4:8dba:82e1::1234]/j (of ourse, using OSCORE).
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

@Tero,

Getting back to this, see inline.

On Thu, May 17, 2018 at 12:36 AM Tero Kivinen <kivi...@iki.fi> wrote:

> Mališa Vučinić writes:
> > Thanks Tero for this feedback! Could you check if this commit takes care
> of
> > it:
> >
> >
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2
> >
> > The algorithm identifier is added, it is optional and if it is not
> present the
> > IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the key length,
> I also
> > added the nonce length in the description of the algorithm in the
> registry.
>
> Looks good. Formatting the algorithm ids as negative numbers is bit
> wierd, but I assume it allows making the field optional as you can
> detect from the the nint that it is algorithm identifier not key
> usage...
>

Yes, that was the intent but see below.

>
> Other option could be to combine the key_usage and algorithm to same
> field, i.e., add algorithm to key_usage tables, and when AES-CCM-256
> is added then double the key_usage entries to contain both possible
> algorithms. This might have the same problems TLS have with cipher
> suites, that we end up with quite large table with all possible
> combinations.
>

I've just adopted this "TLS" approach: key_usage and algorithm are merged,
and a new column "Algorithm" was added in the registry to explicitly state
the link-layer techno / algorithm in use. I believe this is quite enough
for our purposes and simplifies the CBOR decoder that needs to be
implemented. We are back to integers now, and I allow both unsigned and
negative in order to have larger 1-byte ranges in the registry.

The changes are at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/15133e113e2efaa3c42d5f844f12c28100e5f17b


Could you also take a look at the "Key Usage values" table and see if you
can recommend any other setting for the initial inclusion in the registry?

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] On minimal-security

[Mališa Vučinić]

Hi Pascal,

See responses inline.

Mališa

On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Mališa
>
>
>
> As you are getting ready to publish a next rev, please find simple
> comments on 05 that you may want to act upon in 06.
>
>
>
> ·As mentioned earlier in the draft,  the most probable
> collocation for the JRC would be the 6LBR, and probably not a JP deep in
> the network.
>
> Why did you point on the JP in the below?
>
>
>
> the JRC, which may be co-located on the JP or another device.
>
> This was assuming a special case of a pledge that is one hop away from the
6LBR, where 6LBR is co-located with the JP.

I removed "which may be co-located on the JP or another device" to avoid
confusion and added the following two sentences at the end of the Join
Process Overview section:

"
As other nodes in the network, the 6LBR node plays the role of the JP.
The 6LBR may in addition be co-located with the JRC.
"



>
>
>
>
> ·This sentence is too complex :
>
>
>
>4.  In case of successful processing of the request, the pledge
>
>receives a join response from JRC (via the JP) that sets up one
>
>or more link-layer keys used to authenticate and encrypt
>
>subsequent transmissions to peers, and a short link-layer address
>
>for the pledge.
>
>
>
> Who sets up what is unclear. Could you make it 2 sentences?
>

done

>
>
> ·I see what you mean there
>
>
>
> It deeply duty cycles its radio, switching the radio on when the provided
> schedule indicates slots which the pledge may use for the join process.
>
>
>
> But this seems to make the process very specific to TSCH when it could
> easily apply to IEEE Std. 802.15.4 at large. It is my reading that for the
> most part the protocol is not dependent of TSCH and that it could easily
> have  larger applicability. Is there a way to word it as “in the case of
> TSCH, …” ? also suggestion to reword “It deeply duty cycles” to follows
> the indicated schedule or something.
>

The join *process*, as described in the draft, is specific to TSCH because
of the EB assumption. The join *protocol*, however, is not and applies to
15.4 at large, as well as it could easily be applied to other IoT technos
with a registration of additional configuration parameters.

I rephrased "It deeply duty cycles" to "It follows the provided schedule"

I also added the following paragraph in the introduction:

"
The 6TiSCH Join Protocol defined in this document is generic and can be
used as-is in modes of IEEE 802.15.4 other than TSCH, that 6TiSCH is based
on.
The 6TiSCH Join Protocol may as well be used in other (low-power)
networking technologies where efficiency in terms of communication overhead
and code footprint is important.
In such a case, it may be necessary to register configuration parameters
specific to the technology in question, through the IANA process.
The overall join process described in {{join-process-overview}} and the
configuration of the stack is, however, specific to 6TiSCH.
"



>
> ·On paper the 6LoWPAN concept of 6LBR (a central registrar,
> though the 6LoWPAN definition indicates a border router function) is not
> necessarily the same guy as the RPL root, though it makes full sense that
> they are – and the 6TiSCH architecture recommends that they be. Maybe we
> could enforce that they are in another spec.
>

I added the following sentence in the terminology section:

"
The term "6LBR", as used throughout the document, also denotes the function
of the "DODAG root" defined in {{RFC6550}}, assuming the two entities are
co-located, as recommended by {{I-D.ietf-6tisch-architecture}}.
"

I guess this should be enforced by the architecture draft?


> The JRC can be co-located on the 6LBR. In this special case, the IPv6
> address of the JRC can be omitted from the Join Response message for space
> optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs
> {{RFC6550}} to its IPv6 address. The pledge learns the address of the JRC
> once joined and upon the reception of a first RPL DIO message, and uses it
> to operate as a JP.
>
>
>
> I’d add a sentence at the beginning of the spec that the text makes the
> assumption that the 6LBR is the RPL root per the architecture and that in
> case they are separate, you really mean the RPL root?
>

See if the sentence above takes care of this.

>
>
> ·We should not say the following:
>
>
>
> When the JRC is not co-located with the 6LBR, then the code point provides
> a clear indication to the 6LBR that this is join response traffic.
>
This seems to indicate that the traffic class may only be applied to join
> response. In the future, we may apply that behavior to other traffic.
> That’s linked to the point of having a class.
>
Deleted the sentence you cited.


> ·This could be listed as a dependency or an expectation, or just
> be declared out of scope:
>
>
>
> Companion SF documents SHOULD specify 

[6tisch] A terminology issue in minimal-security: (6LBR) pledge

[Mališa Vučinić]

All,

With the latest developments on minimal-security-06, we have homogenized
the join protocol so that it equally applies to regular pledges and the
6LBR device. Essentially, 6LBR just sets some parameters differently in the
request, and it receives the keys, network prefix and PAN ID of the network
it should advertise. 6LBR join happens over a non-IEEE802.15.4 interface
that is out-of-scope of the document.

With that, depending on the role the pledge requests to play in the
network, we have non-6LBR pledges and the 6LBR pledge.

There are portions of text in the document that apply to: 1) 6LBR pledges
only; 2) non-6LBR pledges only; 3) both.

The terminology section was amended to state:

> The term "pledge", as used throughout the document, explicitly denotes
non-6LBR devices attempting to join over an IEEE 802.15.4 network interface..
> The device that attempts to join as the 6LBR of the network and does so
over another network interface is explicitly denoted as the "6LBR pledge".
> When the text equally applies to the pledge and the 6LBR pledge, the
"(6LBR) pledge" form is used.

This is a bit cumbersome and I am not too happy with it as it turned out
there are quite some places where the "(6LBR) pledge" form had to be used.
If you have a better idea, shout it out.

The commit updating the whole document to explicitly state what text refers
to what kind of a pledge is at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/c14b803905d7


Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

Thanks Tero for this feedback! Could you check if this commit takes care of
it:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2

The algorithm identifier is added, it is optional and if it is not present
the IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the key length,
I also added the nonce length in the description of the algorithm in the
registry.

Mališa

On Tue, May 15, 2018 at 11:47 PM Tero Kivinen <kivi...@iki.fi> wrote:

> Mališa Vučinić writes:
> > I also worked out a new key signaling mechanism using a "key usage"
> parameter,
> > where a single uint value from the registry specifies the IEEE 802.15.4
> > security level to be used and the appropriate frame types the key can be
> used
> > with. The mechanism is flexible in that it allows us to transport a key
> that
> > is both K1 and K2, separate K1 and K2, different security levels for
> each, and
> > we can also define new combinations of security levels/frame types in
> future.
> > The solution only supports KeyIndex mode of IEEE 802.15.4. Supporting
> other
> > modes required mimicking 15..4 security structures to configure the
> security
> > module and would have required maps everywhere and extensive overhead.
> If you
> > have any better idea how to add support for other keying modes of
> 802.15.4,
> > let me know.
>
> Note, that there is work ongoing in the IEEE to add algorithm agility
> to the IEEE 802.15.4, i.e., make it possible to use other algorithms
> than AES-CCM with 128-bit keys. To make it so that this structure
> would also allow that it would be good idea to include algorithm
> parameter to the Link-Layer Key structure with only one value of
> AES-CCM-128 now. Also restructuring the text about the key_value to
> say "key length of the algorithm" instead of fixed 16, i.e., say that
> ignore this key if the length of the key_value does not match the
> length of the key specified by the algorithm.
>
> This TG15.4y SECN work is just starting and will most likely be
> finished in few years time. The main reason for that work, is to add
> AES-CCM-256 option for the IEEE 802.15.4. This will make it possible
> for 802.15.4 to conform with requirements that some organizations
> have, i.e., allow using 256 bit keys to provide some protection
> against quantum computers.
>
> Makeing this minimal-security draft to only allow AES-CCM-128 and not
> even allow easy extensibility for other algorithms would be bad idea
> now.
> --
> kivi...@iki.fi
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

On Tue, May 15, 2018 at 8:54 PM Michael Richardson 
wrote:

>
>
> > I generalized the rekeying text so that it falls under the
> processing rules
> > of the CBOR Link-Layer Key parameter. The first join of a pledge just
> > becomes a special case but there is a distinction between the 6LBR
> and
> > non-6LBR nodes. I don't see how the JRC that is not colocated with
> the 6LBR
> > can trigger the sending of a link-layer frame secured with the new
> > keys...
>
> In such a situation, there will need to be an additional control protocol,
> which might be proprietary or future work, but in any case, I think it's
> okay
> if we clearly mark it as out-of-scope.
>

There shouldn't be any need for an additional control protocol with the
current text. In the processing rules, we differentiate between 6LBR
receiving a key parameter and non-6LBR nodes. Essentially, 6LBR upon
reception of the key parameter immediately removes the old keys and starts
using the new keys for all outgoing traffic. Non-6LBR nodes wait until they
receive one frame secured with the new keys and upon that event remove the
old keys.

The pledge joining for the first time follows the same behavior, albeit
with a note that it is possible to speed up the process by storing an EB
that was used to discover the JP.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] On minimal-security

[Mališa Vučinić]

Thanks for this review, Pascal. I went quickly through your comments and I
should be able to fix all of this for -06. My goal is to have -06 ready for
WGLC.

On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Mališa
>
>
>
> As you are getting ready to publish a next rev, please find simple
> comments on 05 that you may want to act upon in 06.
>
>
>
> ·As mentioned earlier in the draft,  the most probable
> collocation for the JRC would be the 6LBR, and probably not a JP deep in
> the network.
>
> Why did you point on the JP in the below?
>
>
>
> the JRC, which may be co-located on the JP or another device.
>
>
>
>
>
> ·This sentence is too complex :
>
>
>
>4.  In case of successful processing of the request, the pledge
>
>receives a join response from JRC (via the JP) that sets up one
>
>or more link-layer keys used to authenticate and encrypt
>
>subsequent transmissions to peers, and a short link-layer address
>
>for the pledge.
>
>
>
> Who sets up what is unclear. Could you make it 2 sentences?
>
>
>
> ·I see what you mean there
>
>
>
> It deeply duty cycles its radio, switching the radio on when the provided
> schedule indicates slots which the pledge may use for the join process.
>
>
>
> But this seems to make the process very specific to TSCH when it could
> easily apply to IEEE Std. 802.15.4 at large. It is my reading that for the
> most part the protocol is not dependent of TSCH and that it could easily
> have  larger applicability. Is there a way to word it as “in the case of
> TSCH, …” ? also suggestion to reword “It deeply duty cycles” to follows
> the indicated schedule or something.
>
>
>
> ·On paper the 6LoWPAN concept of 6LBR (a central registrar,
> though the 6LoWPAN definition indicates a border router function) is not
> necessarily the same guy as the RPL root, though it makes full sense that
> they are – and the 6TiSCH architecture recommends that they be. Maybe we
> could enforce that they are in another spec.
>
>
>
> The JRC can be co-located on the 6LBR. In this special case, the IPv6
> address of the JRC can be omitted from the Join Response message for space
> optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs
> {{RFC6550}} to its IPv6 address. The pledge learns the address of the JRC
> once joined and upon the reception of a first RPL DIO message, and uses it
> to operate as a JP.
>
>
>
> I’d add a sentence at the beginning of the spec that the text makes the
> assumption that the 6LBR is the RPL root per the architecture and that in
> case they are separate, you really mean the RPL root?
>
>
>
> ·We should not say the following:
>
>
>
> When the JRC is not co-located with the 6LBR, then the code point provides
> a clear indication to the 6LBR that this is join response traffic.
>
>
>
> This seems to indicate that the traffic class may only be applied to join
> response. In the future, we may apply that behavior to other traffic.
> That’s linked to the point of having a class.
>
>
>
> ·This could be listed as a dependency or an expectation, or just
> be declared out of scope:
>
>
>
> Companion SF documents SHOULD specify how traffic with code point AF42 is
> handled with respect to cell allocation.
>
>
>
> I’m not too happy with a SHOULD directed to an unnamed future spec as
> opposed to an implementer. Unsure how the IESG will react to that.
>
>
>
>
>
> ·The URI host of the request may point on something more specific
> to any jrc as opposed to other nodes:
>
>
>
> The Uri-Host option is set to "6tisch.arpa". This is an anycast type
> of identifier of the JRC that is resolved to its IPv6 address by the JP
>
>
>
> Suggestion: "default-jrc.6tisch.arpa".
>
> ·The text below is not future proof
>
>
>
> If the decoded CBOR unsigned integer value is larger than 255 (length
> defined by {{IEEE802.15.4-2015}})
>
>
>
> I’d rather say larger than the “max MAC-Layer security key size, which is
> 255 with {{IEEE802.15.4-2015}}”
>
>
>
> ·About the lease ASN, how is the JRC aware of the current ASN?
>
>
>
> ·Some  acronyms like AEAD could be spelled out on first use
>
>
>
> ·I think we were told to use a form like “IEEE Std. 802.15.4” to
> refer to the IEEE standards. Note that one should avoid dating the IEEE
> spec references unless there is a quote or a pointer that is specific to a
> particular year.
>
>
>
>
>
> All in all, this is an excellent and very clear document, congratulation.
>
>
>
> Do you expect 06 to be ready for WGLC?
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

Michael,

See inline.

Mališa

On Thu, May 10, 2018 at 8:05 PM Michael Richardson 
wrote:

>
> I see that you have an IANA registry for the Join Request and Join Response
> key values.  These tables need to have names and the IANA instruction needs
> to ask them to create the tables, and then to populate them with the table
> From section 9.


> May I also suggest:
> 1) instead of "unsigned integer", that we just say integer.
> 2a) that the 1-byte positive and negative integers may be allocated by IETF
>Standard.
> 2b) that the 2-byte, 3-byte and 4-byte positive integers may be allocated
> by IANA
> First Come First Served (
> https://tools.ietf.org/html/rfc8126#section-4.4)
> 2c) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as
> an experimental range.
>
>> 9.2.1.1.  Link-Layer Key
>This probably needs an IANA Registry, even if it is closed to just IETF
>Standard Action.
>
> (I can write text next week on this)
>

Yes, this is all fine with me. If you could provide a PR on the latest
minimal-security-06 branch, that would be great!

>
> Did you see my "new-key-start" branch from last week, btw?
>

Yes, just worked on this today. I cherry-picked two of your commits but
reorganized the text heavily. CBOR objects are now a separate subsection,
two new CoAP messages for "parameter update exchange" are defined.  The
Parameter Update message (CoAP POST from JRC to the joined node) carries
the same CBOR object as the Join Response. This is the conclusion of the
discussions I had with Christian.

I generalized the rekeying text so that it falls under the processing rules
of the CBOR Link-Layer Key parameter. The first join of a pledge just
becomes a special case but there is a distinction between the 6LBR and
non-6LBR nodes. I don't see how the JRC that is not colocated with the 6LBR
can trigger the sending of a link-layer frame secured with the new keys...

Here is the relevant commit, check it out:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/968a9450dde7c93849d6bec278fe28522e9c4c76


>
> On to 6LBR stuff:
> As a special case, when the pledge is configured to play the role of
> the 6LBR, and 6LBR is not co-located with the JRC, the pledge
> additionally needs to be provisioned with:
>
> okay, so I understand the situation.  I think that such a 6LBR probably
> have
> two interfaces, one of them Ethernet, and that it does a join over
> ethernet.
> (It would probably also do a join request over 15.4 as well, since it might
> have no idea what's where)
>

Yes, another interface for the 6LBR to join is an assumption that we need
to state clearly.


>
> I'm fine with that, but in that case, we need to tell such a pledge how to
> find a Join Proxy and/or the actual JRC.   At present, we use the 15.4
> specific Enhanced Beacon.  There a bunch of options:
>   1) DHCPv6
>   2) GRASP
>   3) mDNS (DNS-SD)
>   4) RA option
>

In the current text somewhere in the one-touch section, there is simply a
requirement that 6LBR needs to be provisioned with the IPv6 address of the
JRC. Then, it can contact it over CoAP/IPv6 directly using global
addressing. I still need to do some changes to CoAP message mapping to
cover this case clearly, but I don't think another protocol is necessary.
Of course, the current text does not preclude the use of another protocol
for that purpose.


>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

Michael, all,

tl;dr: The relevant WIP commit is at
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/21ad042639b4617bf7a6993e9140a65d702680ef
..

I did quite a bit of work in the document, including some CBOR wizardry,
and defined new parameters and IANA registries with the goal of
homogenizing the join for 6LBR and regular nodes. For now, I added an
optional "network prefix" parameter in the Join Response, carrying the IPv6
prefix of the network for the 6LBR. If there are some pitfalls with this
that I forgot, we can remove it. Similarly, I also added the "network
identifier" parameter in the Join Response, carrying PAN ID for the 6LBR.

Regarding CBOR, the top-level types in Join Request and Join Response are
now all maps, but I removed the use of COSE_Key and COSE_Keyset and defined
our own structures in order to save bytes when transporting keys.
Essentially, this means that we are flexible to add new parameters in the
future in top-level Join Request and Join Response objects, but the inner
objects are fully optimized and poorly extensible due to the use of arrays
and uints.

I also worked out a new key signaling mechanism using a "key usage"
parameter, where a single uint value from the registry specifies the IEEE
802.15.4 security level to be used and the appropriate frame types the key
can be used with. The mechanism is flexible in that it allows us to
transport a key that is both K1 and K2, separate K1 and K2, different
security levels for each, and we can also define new combinations of
security levels/frame types in future. The solution only supports KeyIndex
mode of IEEE 802.15.4. Supporting other modes required mimicking 15.4
security structures to configure the security module and would have
required maps everywhere and extensive overhead. If you have any better
idea how to add support for other keying modes of 802.15.4, let me know.

Feedback is welcome, I am continuing with the work on the rekeying
mechanism that we discussed.

Mališa

On Tue, Apr 24, 2018 at 11:06 PM Michael Richardson <mcr+i...@sandelman.ca>
wrote:

>
> Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
> mcr> I'd say that you always do this with any new key if you
> mcr> have no keys.
> mcr> I don't think we need a flag.
>
> mcr> In fact, even for the "0th key", you would start using it
> mcr> as soon as you see
> mcr> something that passes with that key, such as
> mcr> authenticating the Beacon that
> mcr> you used to find the Proxy in the first place
>
> > Authenticating a beacon that was received long time ago would require
> > the pledge to store the beacon(s) for potentially an extensive
> > period... I don't think we need to do that.
>
> No, I'm not suggesting one keeps it for along time.
>
> What I'm saying is that, just after getting the Join Response, a pledge
> now has
> some set of keys.  It will have an authentication key.  It could
> immediately
> authenticate the Beacon that it used to find the Proxy.  That does a few
> things:
>
> 1) validate the Beacon!
> 2) since the key successfully validates the Beacon, it proves that the key
> the
>pledge got is a current key, and so the key would be marked as
> activated.
>
> Of course, if the pledge doesn't have enough ram to keep the beacon
> around, then
> it shouldn't do that.  It can validate the next beacon instead.
>
> > Essentially:
> > - 6LBR: installs the new key, starts using it for outgoing traffic
> > immediately, removing old keys, if any.
>
> > - joined node and pledge: installs the new key, keeps using the old
> > keys for outgoing traffic until it receives incoming traffic secured
> > with the new key, with all L2 security checks passed. In the special
> > case of a pledge, there shouldn't be any outgoing traffic before it
> > decrypts DIO(s) and selects a preferred parent.
>
> Exactly.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Optimizing Neighbor Discovery during the join process

[Mališa Vučinić]

Hi Pascal,

Thanks for the clarifications.

One point I strongly disagree with is about the cost of the ND exchange. ND
is indeed done on one-hop but in 6TiSCH case this maps to the* shared cell*,
where the collisions happen. Once we get pass that critical first hop,
things are much easier as we have dedicated cells towards the 6LBR. So, I
would by no means underestimate the effect of doubling the communication
overhead on the shared cell due to ND.

I also think that a solution where ND is done for the first time once the
pledge becomes a joined node, and JP or pledge do not have to worry about
insecure NCE is quite clean. With that, JP becomes stateless at *all*
levels, including IP, which is quite good from the security point of view
during the join process. It also removes 50% of overhead on the shared cell
in a fully generic setting. To me, it seems that you are recommending to
give up from that because 1) some people will not like it; 2) some stacks
might need to be amended to support either destination all-zeros, or source
all-JPs.

That said, please note that the *existing* text in -05 already mentions ND
as a phase in the join process. We do not detail how ND is done, and I
don't think we should by any means do it in the minimal-security draft. In
the existing text, we reference Section 5.5.1 of RFC6775. We also give a
recommendation that the NCE resulting from the ND exchange should be kept
separately, as the pledge is not yet authenticated.

A specific optimization when JP's LL is constructed from its L2 address
with a bit in the EB is more of a workaround to me, but I can live with it.
I guess this would belong to the richardson-enahnced-beacon document?

Mališa


On Fri, Apr 20, 2018 at 11:20 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Mališa
>
>
>
> The all-0 destination is tricky, not done anymore that I know off. Trying
> that may get us through hell at 6MAN and/or IESG.
>
>
>
> I think that as an RFC you must described the clean way and then the
> optimizations when the LLs are based on EUI 64.
>
>
>
> IMHO, the spec should say that:
>
>
>
> - That the pledge sends an RS to all-JPs at l3, L2 dest = unicast
> MAC of the JP.
>
> - That the pledge registers its LL using ND EARO.
>
>
>
> With that we are clean from the standards perspective.
>
>
>
> And then, to address your concern, the spec would then indicate that if
> the pledge or the JP LL are derived from EUI 64 then some optimizations are
> possible.
>
> If the JP LL derives from EUI 64 you may:
>
> - Have a bit in the beacon that indicates so.
>
>
>
> If the pledge LL derives from EUI 64 you may:
>
> - Skip the ND EARO to register the LL to the JP
>
> - Indicate in the join message that the LL derives from the MAC
>
> - Use it on the way back to skip the look up
>
>
>
> Notes:
>
> - The JP just needs to have a threshold of unsecured NCE, and a
> sensible lifetime for these, but that’s not that difficult.
>
> - If the NCE for the pledge is no more there when the join
> response comes in then the JP needs to do a NS look up.
>
>
>
> Also, I do not necessarily agree that the ND phase is that expensive. It
> is just a one-hop exchange.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* Mališa Vučinić <malisa.vuci...@inria.fr>
> *Sent:* jeudi 19 avril 2018 15:32
> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com>
> *Cc:* Michael Richardson <mcr+i...@sandelman.ca>; 6tisch@ietf.org
>
>
> *Subject:* Re: [6tisch] Optimizing Neighbor Discovery during the join
> process
>
>
>
> Pascal,
>
>
>
> If we were to use the unspecified address, would the following be OK:
>
>
>
> - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2
> source: pledge EUI; L3 destination: JP EUI from the Beacon
>
> - Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2
> source: JP EUI; L2 destination: Pledge EUI
>
>
>
> (Join Request and Join Response refer to packets exchanged between the
> pledge and the JP.)
>
>
>
> This seems to:
>
> - resolve Michael's concern about CoAP libraries expecting the response to
> come from the same IPv6 address where it was sent to
>
> - not introduce any additional packet overhead
>
> - avoid an ND exchange doubling communication overhead
>
> - avoid the need to keep a separate insecure cache at JP. How this would
> be implemented is implementation specific, one example is an ephemeral
> cache entry discussed in previous emails.
>
>
>
> Let me know if you see any pitfalls, to me it looks quite appealing as an
> option.
>
>
>

Re: [6tisch] Optimizing Neighbor Discovery during the join process

[Mališa Vučinić]

Pascal,

If we were to use the unspecified address, would the following be OK:

- Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source:
pledge EUI; L3 destination: JP EUI from the Beacon
- Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2
source: JP EUI; L2 destination: Pledge EUI

(Join Request and Join Response refer to packets exchanged between the
pledge and the JP.)

This seems to:
- resolve Michael's concern about CoAP libraries expecting the response to
come from the same IPv6 address where it was sent to
- not introduce any additional packet overhead
- avoid an ND exchange doubling communication overhead
- avoid the need to keep a separate insecure cache at JP. How this would be
implemented is implementation specific, one example is an ephemeral cache
entry discussed in previous emails.

Let me know if you see any pitfalls, to me it looks quite appealing as an
option.

Mališa

On Thu, Apr 19, 2018 at 2:41 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello all :
>
>
>
> Guessing the Link Local of the JP looks like a very bad idea. Because the
> JP may not form a link local from EUI. This is being discouraged for
> privacy reasons. Guessing is really unclean any way.
>
>
>
> To resolve the address of the device at the JP you could
>
> - Piggy back an ARO in the join request, implicitly associated
> with the link local of the device. The JP may store it or not, I guess it
> could have a bounded amount of NCE for this use. At least, it could
> immediately reject the Join if the LL is a duplicate with another node, in
> which case a NA (status/=0) would work. Otherwise duplicate LL may be an
> issue for a non-EUI64-based LL.
>
> - Lookup the Link Local of the device on the way back, if there
> is no NCE, but that’s a multicast from the JP to locate the JN
>
>
>
> To reverse resolve the IP
>
>
>
> - If the prefix is known, we can define an anycast address “any
> JP on this prefix” similar to the home agent anycast address in RFC 3775.
>
> - Else you can define a multicast all-JPs and use the multicast
> IP over unicast MAC trick by extension to RFC 6085.
>
> - Early implementations / pre standards can ship with FF02::2
> instead of all-JPs, but the standard should be correct otherwise we’ll pay
> it at the IESG.
>
>
>
>
>
> For the mail below:
>
> - There is no such thing as traffic from all-routers. With RFC
> 6085 we are tricking “all” at L3 with a unicast L2 to make the L3 multicast
> become a sort of  anycast and where we get to choose which JP.
>
> - There is such thing as traffic source set to unspecified
> address (all zeroes) though. If that’s enough for you, you may use that.
>
> - With RFC 6775 update, ND registration for a link local is a one
> hop thing, does not fly to the root or what, so the cost is really limited
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Mališa Vucinic
> *Sent:* mercredi 18 avril 2018 19:37
> *To:* Michael Richardson 
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: [6tisch] Optimizing Neighbor Discovery during the join
> process
>
>
>
>
>
> On Wed, 18 Apr 2018 at 19:17, Michael Richardson 
> wrote:
>
>
> > Yes, I guess you could call it an ephemeral cache entry
> > constructed by CoAP at JP when the join response is received,
> > before being forwarded to the pledge. As soon as the packet is
> > passed to L2, the cache entry is removed. Can we do this?
>
> I think that we can do this.
>
> It might be better if the traffic came from ff02::2, but I'm not sure that
> would be acceptable for IPv6 reasons.
> I am concerned that a reply from a different L3 address will not be
> acceptable to some coap libraries.
>
>
>
>
>
> Indeed, good point about a different adress in the response.
>
>
>
> @Pascal, would it be possible for JP to use all-routers as the source IPv6
> address? If not, does it help if we define our own well-known address?
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

Michael,

Reviving the discussion on the rekeying mechanism. See below.

Mališa


>> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson <
>> mcr+i...@sandelman.ca> wrote:
>>
>>>
>>>
>>> I'd say that you always do this with any new key if you have no keys.
>>> I don't think we need a flag.
>>>
>>> In fact, even for the "0th key", you would start using it as soon as you
>>> see
>>> something that passes with that key, such as authenticating the Beacon
>>> that
>>> you used to find the Proxy in the first place
>>>
>>
Authenticating a beacon that was received long time ago would require the
pledge to store the beacon(s) for potentially an extensive period... I
don't think we need to do that.

But, you are right, we do not need a flag in the response, just to specify
the special handling for different roles:

Essentially:
- 6LBR: installs the new key, starts using it for outgoing traffic
*immediately*, removing old keys, if any.
- joined node and pledge: installs the new key, keeps using the old keys
for outgoing traffic until it receives incoming traffic secured with the
new key, with all L2 security checks passed. In the special case of a
pledge, there shouldn't be any outgoing traffic before it decrypts DIO(s)
and selects a preferred parent.
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

[Mališa Vučinić]

(I just realized that I forgot to CC the 6tisch ML for the previous
exchanges.)

See below.

On Thu, Apr 19, 2018 at 10:55 AM Christian M. Amsüss <christ...@amsuess.com>
wrote:

> Hi Mališa,
>
> On Thu, Apr 19, 2018 at 08:24:57AM +, Mališa Vučinić wrote:
> > I agree that sending the path exposed at the pledge would be quite clean
> > but I don't get the benefit of it since we need to hardcode /j at the JRC
> > anyways. For the JRC and the pledge to be interoperable, pledge needs to
> be
> > hardcoded with /j to send the Join Request, and the increment for the JRC
> > to be hardcoded with /j to send the rekeying request to the pledge is
> > minimal IMO.
>
> I think it's one thing to mandate a path to the JRC (which is part of
> the "any-cast group" 6tisch.arpa, which by the way is a trick I find
> very neat), and another for the pledge.
>
> What does ease my concerns a bit is that those resources are anyway
> limited to what I'd call the virtual host induced by the OSCORE context.
>
> > > If CBOR is used to glue the two things (the request hex-stuff, I don't
> > > remember what exactly that was) and the path) together, 16 bytes of
> > > hex-stuff and 1 byte of path become 21 bytes of payload.
>
> Side note: Looking through -05 again I noted that the "hex-stuff" I
> mentioned is already in a join_request CBOR; the overhead associated
> with the path would be further decreased.
>

Yes, that's right, we could extend the join_request struct, if we get
pushback on this.


> But yeah, sticking with /j with the option of adding that to
> join_request if there is pushback sounds like a viable option right now.
>

Sounds good!


> > I am considering POST for both the initial Join Request, and for the
> > rekeying request. That should be fine, right?
>
> The requests for join and re-join from the node to the JRC sound good
> with POST. Who would send a re-keying request -- the node or the JRC?
>

Current text specifies that rekeying is triggered by the joined node, but I
am talking about the update to the text where the rekeying request is sent
by the JRC to /j resource exposed by the joined node. POST should be fine
there, as well, right?
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Optimizing Neighbor Discovery during the join process

[Mališa Vučinić]

On Wed, 18 Apr 2018 at 19:17, Michael Richardson 
wrote:

>
> > Yes, I guess you could call it an ephemeral cache entry
> > constructed by CoAP at JP when the join response is received,
> > before being forwarded to the pledge. As soon as the packet is
> > passed to L2, the cache entry is removed. Can we do this?
>
> I think that we can do this.
>
> It might be better if the traffic came from ff02::2, but I'm not sure that
> would be acceptable for IPv6 reasons.
> I am concerned that a reply from a different L3 address will not be
> acceptable to some coap libraries.



Indeed, good point about a different adress in the response.

@Pascal, would it be possible for JP to use all-routers as the source IPv6
address? If not, does it help if we define our own well-known address?
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Optimizing Neighbor Discovery during the join process

[Mališa Vučinić]

On Wed, 18 Apr 2018 at 18:19, Michael Richardson <mcr+i...@sandelman.ca>
wrote:

>
> Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
> > We had a couple of side discussions regarding Neighbor Discovery
> > (ND) in minimal-security draft.
>
> > The problem is that with the current text in minimal-security and
> > the ND exchange between the pledge and the JP, we double the
> > communication overhead on the shared cell and require the JP to
> > keep separate neighbor caches, one cache for secure, authenticated
> > entries, and another cache for insecure entries.
>
> > It seems to be possible to remove the ND exchange between the
> > pledge and the JP by using something like FF02::2,
> > i.e. all-routers. With the same approach, it seems to be possible
> > to remove the need for separate caches by specifying how the JP
> > handles packets received over the well-known address.
>
> I thought that we eliminated the ND with the R-bit of the Enhanced Beacon
> extension.
> The JP is the link-layer ff80:: of the beacon?
>


Pascal had a concern with pledge guessing JP’s link-local from L2 of the
beacon, I’ll let him expand.


> I'm in favour of eliminating the ND for the JP, but I think that we should
> not
> do this in minimal security, as minimal-security doesn't need to be
> 802.15.4
> specific (the 2-byte assignment is optional, and could assign different
> things for
> different L2-types).


There is nothing 802.15.4-specific in this, see below.



>
> Are you suggesting that the JP would send replies to the pledge using
> ff02::2?


No, pledge constructs its link-local and addresses the join request to the
well-known IPv6, and L2 destination is the source address of the beacon.

For join response, I’d say that the source IPv6 is JP’s link-local and the
destination IPv6 is pledge’s link-local, coming from CoAP. If it happens
that the pledge built its link-local from EUI-64, only those 8 bytes need
to be signaled in CoAP option, but this is internal to JP.



> I don't really understand this eliminates the neighbor cache entries,
> although I
> can imagine that the stateless information in the CoAP could be used to
> construct a neighbor cache entry.


Yes, I guess you could call it an ephemeral cache entry constructed by CoAP
at JP when the join response is received, before being forwarded to the
pledge. As soon as the packet is passed to L2, the cache entry is removed.
Can we do this?


>
>
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

[Mališa Vučinić]

Christian,

See inline.

Mališa

On Thu, Apr 12, 2018 at 3:15 PM Christian M. Amsüss 
wrote:

>
> > What would be the advantage of establishing a dynlink over specifying in
> > the minimal-security draft that once the pledge joins, it needs to
> expose a
> > /j resource that the JRC may use to update the keying material? This
> would
> > essentially be a static link specified in the draft. Do you see any
> pitfall
> > with that?
>
> Apart from that we should not specify statically named resources in
> devices' namespaces outside `.well-known/`, I see no problem with that.
>

So, we had /j exposed at the JRC for long time in the draft and I assumed
this is OK because ACE is using something similar, i.e /token, /authz-info.

Are you saying that we have to add 11 bytes without counting the option
encoding to the Join Request because this is a static resource? Is there
any way around this?


> I wouldn't see it as a matter of being "an advantage of ... over", but
> more of the dynlink being the theoretical background behind and
> justifying what happens here; think of it as a form of compressed
> exchange if you will.
>

Sounds good, I am working on the text tomorrow and will send you the PR to
double check if it makes sense.

> I don't think we have the consensus on the use of CoMI in
> minimal-security.
> > We considered it for future work, but at this point I would refrain from
> > pulling in new specifications..
>
> It might still be convenient to consider, eg. whether a future
> implementor that *does* use CoMI can just treat your /j resource as an
> alias to /c/abc0815 and be done with it, because a POST there with the
> binary data has the desired effect.
>

I am not very familiar with CoMI so it could be a dummy question, but would
we need to specify in the draft to allow this?
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Optimizing Neighbor Discovery during the join process

[Mališa Vučinić]

All,

We had a couple of side discussions regarding Neighbor Discovery (ND) in
minimal-security draft.

The problem is that with the current text in minimal-security and the ND
exchange between the pledge and the JP, we double the communication
overhead on the shared cell and require the JP to keep separate neighbor
caches, one cache for secure, authenticated entries, and another cache for
insecure entries.

It seems to be possible to remove the ND exchange between the pledge and
the JP by using something like FF02::2, i.e. all-routers. With the same
approach, it seems to be possible to remove the need for separate caches by
specifying how the JP handles packets received over the well-known address.

High-level, it looks as a win-win, but I kindly solicit any opinions on how
this could be specified in detail.

Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

[Mališa Vučinić]

See inline.

On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne 
wrote:

>
> *About COSE_Key*
>
> The issue raised is that, during a rekey of key K2 by the JRC, the JRC
> cannot specify an ASN from which the new key is to be used.
>

The JRC would need to guess how long it may take for it to reach every node
in the network. I think that it makes sense that the JRC does not need to
be aware of network specifics. Instead, it can update the key of the 6LBR
last, signaling that it should start using it. Other nodes get the key
before, but don't use it until they see it in the network. Makes sense?


> A strong requirement is for a node NOT have a node rejoin for each rekey.
>

Agreed, this means we need to add the rekeying mechanism in the new version
of minimal-security.


> Must we use the COSE_Key structure?
>

The use of COSE_Key costs us 2 bytes of overhead, for the key type (kty)
parameter which is implicitly symmetric for us but we need to transport it
according to RFC8152.

All the other parameters are optional, and we can extend the COSE registry
with new parameters, if we need to.

We could also specify a 6TiSCH-specific key structure instead of COSE_Key,
going for arrays instead of maps and saving an initial estimate of 4 bytes *per
key*.


> Is the the message sent by the JRC containing the new key end-to-end
> ACK'ed, i.e. does the JRC know it got received?
>

The end-to-end ACK of the message carrying the new key can be issued with
all the mechanisms that we are discussing in the thread "Observe for
rekeying".

In the case of classical Observe, this would be a CON Observe notification,
followed by an empty ACK from the client.

In the case a joined node exposes a resource (e.g. /j) that the JRC POSTs
to, the ACK would be piggybacked with the 2.04 Created response.


>
> Thomas
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić]

Hi Thomas,

See inline.

Mališa

On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne <thomas.watte...@inria.fr>
wrote:

> There are two seperated discussions going on in this thread. @Malisa, if
> you agree, let's split the thread.
> I have clarifying questions about both.
>
> *About OBSERVE*
>
> The issue raised is that, during the join request/response exchange
> between the pledge and the JRC, the JRC never learns the IPv6 address of
> the pledge (thanks to the Stateless-Proxy CoAP option). This means that, if
> the join request is carried by a CoAP FETCH message with Observe, the JRC
> has no means of addressing the joined node when the Observe triggers.
> Doing a second GET with Observe once the pledge has joined defeats the
> purpose of going for FETCH.
> Any other option?
>

This discussion is now under the thread: *Observe for rekeing (was: Updates
to minimal-security-06).*

I agree with your summary. Right now we are discussing whether the joined
node can expose a resource (e.g. /j), that the JRC can POST to and update
the key as it knows implicitly joined node's IPv6 address.


> *About COSE_Key*
>
> The issue raised is that, during a rekey of key K2 by the JRC, the JRC
> cannot specify an ASN from which the new key is to be used.
> A strong requirement is for a node NOT have a node rejoin for each rekey.
> Must we use the COSE_Key structure?
> Is the the message sent by the JRC containing the new key end-to-end
> ACK'ed, i.e. does the JRC know it got received?
>

Moving the discussion about the rekeying mechanism to the thread: *Rekeying
for minimal-security (was: Updates to minimal-security-06).*


>
> Thomas
>
> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
>
>>
>> Mališa Vučinić <malis...@gmail.com> wrote:
>> mcr> I think that the mechanism that was explained at:
>> mcr>
>> https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#
>> mcr> section-4
>>
>> mcr> is a better workable solution.  Deploy all the new keys (it may
>> take some
>> mcr> days on sleep networks), and then have nodes switch when they
>> see traffic
>> mcr> with the new key.
>>
>> > Thanks, Michael, for the reminder on this document, I have to say
>> that I forgot
>> > about it.. IIUC, the issue you have with the mechanism I proposed
>> is that the
>> > JRC in some cases may not know how long it could take to deploy the
>> keys so
>> > that it cannot properly set the ASN. I think that's a valid concern
>> and that it
>> > would indeed be better if we could decouple the JRC from the inner
>> network
>> > specifics as much as possible.
>>
>> Exactly.
>> It does not have to change significantly what you have, it just has to
>> include the (new) keyIndex.
>>
>> > To do this and support rekeying with your proposal, we need to
>> differentiate
>> > between "start using this key" and "install the key but don't start
>> using it
>> > until you see it being used in the network", for 6LBR and joined
>> nodes to
>> > follow, respectively. We can likely do this by extending the
>> COSE_Key map with
>> > an additional parameter for this purpose, which I prefer to pulling
>> in the
>> > whole COMI machinery, as is suggested in the minimal-rekey draft.
>>
>> I agree, we don't need COMI, just the text about when to start using the
>> new key.
>> Shall I suggest some text it github?
>>
>> > Essentially, the process would be:
>> > - the JRC deploys the new key(s) to all the nodes except to the
>> 6LBR.
>> > - nodes will install them, but keep using the old keys because the
>> new COSE_Key
>> > parameter is set to "install the key but don't start using it until
>> you see it
>> > being used in the network".
>>
>> I'd say that you always do this with any new key if you have no keys.
>> I don't think we need a flag.
>>
>> In fact, even for the "0th key", you would start using it as soon as you
>> see
>> something that passes with that key, such as authenticating the Beacon
>> that
>> you used to find the Proxy in the first place
>>
>> > - deploy the key to the 6LBR, with the COSE_Key parameter set to
>> "start using
>> > now".
>> > - once a node sees the new key being used and the replay protection
>> and the
>> > authenticity check at L2 passes

Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić]

On Thu, Mar 22, 2018 at 5:39 PM Michael Richardson <mcr+i...@sandelman.ca>
wrote:

>
> Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
> > in the network. Other than adding the Observe option, together with
> the
> > new link-layer key we also need to carry the ASN at which this key is
> > scheduled to be rolled out. What COSE parameter the ASN will be
>
> I disagree with this method.
>
> I think that the mechanism that was explained at:
>
> https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#section-4
>
> is a better workable solution.  Deploy all the new keys (it may take some
> days on sleep networks), and then have nodes switch when they see traffic
> with the new key.
>

Thanks, Michael, for the reminder on this document, I have to say that I
forgot about it.. IIUC, the issue you have with the mechanism I proposed is
that the JRC in some cases may not know how long it could take to deploy
the keys so that it cannot properly set the ASN. I think that's a valid
concern and that it would indeed be better if we could decouple the JRC
from the inner network specifics as much as possible.

One of my goals with this extension to minimal-security is to remove any
need for an additional protocol between the 6LBR and the JRC.
6LBR can act as any other pledge before triggering the network formation
process by sending a Join Request itself. The only additional parameter
that the 6LBR needs in respect to the pledges is the IPv6 address of the
JRC and this can be done during one-touch provisioning. Once it receives
the Join Response, 6LBR can start advertising the network by using the
link-layer keys it received.

To do this and support rekeying with your proposal, we need to
differentiate between "start using this key" and "install the key but don't
start using it until you see it being used in the network", for 6LBR and
joined nodes to follow, respectively. We can likely do this by extending
the COSE_Key map with an additional parameter for this purpose, which I
prefer to pulling in the whole COMI machinery, as is suggested in the
minimal-rekey draft.

Essentially, the process would be:
- the JRC deploys the new key(s) to all the nodes except to the 6LBR.
- nodes will install them, but keep using the old keys because the new
COSE_Key parameter is set to "install the key but don't start using it
until you see it being used in the network".
- deploy the key to the 6LBR, with the COSE_Key parameter set to "start
using now".
- once a node sees the new key being used and the replay protection and the
authenticity check at L2 passes, it removes the old keys and starts using
the new key for all outgoing traffic

What do you think?

Mališa
-- 
Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić]

On Thu, Mar 22, 2018 at 5:42 PM peter van der Stok 
wrote:

>
> No semantic difference that I know. You expressed a worry about
> addressing the joining node from JRC.
> Not sure any more, but do you use the IP-in-IP proxy? If yes,
> maintaining the encapsulation in all following traffic seems necessary.
>

No, I do not consider IP-in-IP proxy here. The pledge sends the Join
Request to the Join Proxy (CoAP), so the JRC effectively does not know the
IPv6 address of the pledge at this time, when the Observe option is
included. The Join Response is similarly sent over the Join Proxy (using
the Stateless-Proxy mechanism), but my doubt was related to the fact that
subsequent Observe responses for rekeying, for example, should not go over
the Join Proxy (the pledge joined the network, became a joined node,
selected a potentially different parent, etc).

In RFC7641, I see the following text as relevant:

" The entry in the list of observers is keyed by the client endpoint and
the token specified by the client in the request. If an entry with a
matching endpoint/token pair is already present in the list (which, for
example happens when the client wishes to reinforce its interest in a
resource), the server MUST NOT add a new entry but MUST replace or update
the existing one."

I am tempted to say that this does not prevent us from updating the client
endpoint (but not the token) based on implicit knowledge at JRC. Do you
agree?
-- 
Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić]

On Thu, Mar 22, 2018 at 5:03 PM peter van der Stok 
wrote:

>
> > One doubt I have is how does the JRC send the Observe response to the
> > joined node, when the request came over a Join Proxy. Essentially, the
> > JRC needs to send the response to the global IPv6 address of the
> > joined node, that it never used before, but it is able to construct
> > it, as it knows the network prefix and the node identifiers (EUI-64,
> > short address). @Christian, is there any problem of doing this in
> > terms of CoAP?
>
>
> Why not have the joined node, after joining, send a GET with observe to
> the JRC to receive rekeys?
>

Hi Peter,

Would there be any semantical difference to doing that in respect to doing
it in the Join Request? If we can do it in 2 messages, why use 4? I  see it
more as the implementation problem, since JRC+CoAP implementation will need
to override the IP address of the observing client. In terms of compliance
with the security specs, I would say that it's OK, as we use OSCORE, not
DTLS where there is a binding of the session with IP addresses.

Mališa
-- 
Mališa
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch