Hello Robert, Thanks for this detailed insight. One question below:
On Nov 6, 2015, at 5:43 PM, Robert Cragie wrote: > Some comments on some of the items raised in the thread so far: > > * It is not about messages, it is more about how many flights occur between > initiator and responder. For example, with (D)TLS, it is normal to > incorporate a number of records in a single flight. > > * The concept of an initial phase of PANA (PCI, PAR) is often needed for DoS > and rate-limiting purposes. If DTLS were used, you would still want to use > HelloVerifyRequest for the reasons it was developed for DTLS, there is no > overhead using PANA in this case. > > * Whilst it seems straightforward to use DTLS, it may not be the case where a > JA is involved and it is likely that the DTLS records will need to be relayed > via the JA. The only IP address which can be effectively autoconfigured at > this stage is a link local address and therefore it can only go one hop to > the JA (or possibly JCE direct). > > * Note that autoconfiguration of a link local address is pretty much zero > cost as it is simply forming an IID from the L2 address and prepending > fe80::/64. There may be some concerns about the privacy aspects but I think > privacy concerns are much more significant for global addresses and if L2 > addresses have some sort of treatment for privacy, that it probably adequate > for link local addresses. > > * Conceptually, all these mechanisms are fundamentally the same and when it > comes down to it, there is often little to choose between them. The weight of > the exchanges is based on the credentials and underlying crypto used for > authentication. > > * Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK. EAP by > definition requires and EAP transport and an EAP method. An EAP transport can > be PANA, 802.15.9 (i.e. IEs). EAPOL, RADIUS etc. and there are numerous EAP > methods (EAP-TLS, EAP-PSK, EAP-AKA, EAP-IKEV2). Therefore, I would focus on > those three layers as that is fundamentally what it comes down to: > > 1. Transport > 2. Protocol > 3. Crypto > > To summarise the two authentication schemes I am familiar with: > > ZigBee IP: > Transport: PANA/PANA relay > Protocol: EAP/EAP-TLS > Crypto: ECDHE-ECDSA, PSK > > Thread: > Transport: Direct/CoAP relay > Protocol: DTLS > Crypto: ECJPAKE > > One might ask why a different approach was taken for Thread. The main reasons > are that DTLS is considered a key protocol for Thread applications (which > will likely use CoAP) and thus reuse of DTLS was considered paramount. Also, > the Commissioner model is substantially different to the Authenticator model > for ZigBee IP and it was considered more appropriate to use protocols a > phone/tablet app. would be more familiar with, i.e. CoAP and DTLS as opposed > to PANA/EAP/EAP-TLS. I would imagine the 6tisch architecture is closer to > ZigBee IP than Thread. > > * The simplicity of PSK is offset by the need to manage confidential > information across the devices. It is always IMHO worth including PSK as a > minimal level, as it is very useful for testing purposes if nothing else > > * In my experience, using EAP-TLS as an EAP method in conjunction with PANA > and EAP (i.e. ZigBee IP approach) allows for reuse of TLS library with > application layer, thus potentially saving code. > > * EAP-TLS has a lot of functionality that DTLS has so one could consider > using DTLS in conjunction with an appropriate transport. That transport could > be PANA, CoAP or a combination of L2/L3 based. > > * Whatever solution is proposed for transport MUST take into consideration > the JN-JA-JCE architecture, i.e. need to consider a point-to-point > communication between JN and JA (unauthenticated network) and normal > communication between JN and JCE. > > * If CoAP is used as a transport, it must be distinguishable from other CoAP > traffic. This could either be through port or URI. > > * Whilst PANA is an additional protocol, it is pretty lightweight and is > purely an authentication transport. The main issue I heard regarding PANA is > the fact it uses UDP and this can cause issues for stacks (especially > Linux-based stacks) > What exactly is the issue there? > * Using PANA in 802.15.9 is a case of transporting the data in IEs. We took a > different (IMHO simpler) approach in ZigBee IP and transported the PANA UDP > datagrams using 6LoWPAN over unsecured 802.15.4 packets. However, note > comment above re. use of UDP. > > * One bonus of using PANA is the resultant PANA session, which is basically a > secure session between PAC and PAA, where the PAC (PANA client) is the device > requiring network access. This can be used for securely configuring network > parameters on the device, for example, in ZigBee IP it was used to securely > deliver the network key. There was an idea for it to deliver other parameters > as well but this was considered "treading on the toes" of 6LowPAN ND's > address registration and DHCP, although in both those cases, there is no way > to provide the secure session with which to transport the data. So I think > Tero has this wrong - PANA definitely can be used to distribute keys and be > used for rekeying, however I mean this independent of the pairwise key > established as part of the authentication between JN and JCE. > > * I agree with Rafa's point that the JCE and JN should mutually authenticate > each other. > Alper > Robert > > On 5 November 2015 at 00:06, Malisa Vucinic <[email protected]> wrote: > > > On 05 Nov 2015, at 00:18, Michael Richardson <[email protected]> wrote: > > > > > > It seems to me that we need to write a document that explains the join > > *environment* in terms of radio and energy considerations. > > Some of this discussion happened orally in security design team discussions, > > but was perhaps assumed to be well known, or was simply assumed. > > Some of the information is available in the introduction section of minimal, > but I definitely agree that it would be useful to spell out somewhere the > repercussions this has on the energy consumption during the join. > > > One goal of this document is to define the simplest set of rules for > > building a TSCH-compliant network, at the necessary price of lesser > > efficiency. Yet, this minimal mode of operation MAY also be used > > during network bootstrap before any schedule is installed into the > > network so nodes can self-organize and the management and > > configuration information be distributed. In addition, the minimal > > configuration MAY be used as a fall-back mode of operation, ensuring > > connectivity of nodes in case that dynamic scheduling mechanisms fail > > or are not available. > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
