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