Hi Alper, Ideally, you would need some type of multiplexing of layer-2 to cleanly pull this off…maybe the upcoming LLC work for 802.15.4 will make this kind of thing easier.
R. On Nov 7, 2015, at 4:26 PM, Alper Yegin <[email protected]<mailto:[email protected]>> wrote: Hi Robert, The MAC has the ability to carry both encrypted traffic and also unencrypted traffic, right? If so, it's just about telling the MAC which traffic uses encrypted path and which does not. I don't see anything to do with layer violation here. I'd not call it a "side stack" either. It's just demultiplexing. Same stack, different code path executed depending on the characteristic of the traffic, which is explicitly conveyed by the upper layer to the lower layer. Btw, this has to be done for any above-MAC solution. Alper Given that the MAC can support transporting IP (with whatever payload it carries, be it PANA/UDP, or anything else), it should be able to carry both encrypted traffic and unencrypted traffic. On Nov 7, 2015, at 7:42 PM, Robert Cragie wrote: Hi Alper, The perceived issue is that, in ZigBee IP, the authentication traffic over PANA on the single hop between the unauthenticated joiner and the relay (or authenticator) has to be sent at the MAC layer without any protection. This is because MAC layer protection is used for all authenticated nodes sending and receiving traffic in the mesh and the key used is delivered at the end of the authentication process over the established secure session. Note there is no particular issue with having no MAC layer protection as the only traffic carried is for authentication purposes and thus does not carry any confidential information and is checked using verify exchanges at the end. This means there is effectively a "side stack" alongside the normal stack, which is used to handle the PANA traffic on an enforcement point. On one hand, some perceive the necessity for this side stack as layer violation, although I view this more as control plane traffic, where cross-layer interactions are not uncommon (look at what they are doing in anima with the ASAs, for example). It is also perceived as complicating the use of a typical IP stack, which is normally used for data plane traffic. Specifically, having to provide an extra parameter at the socket layer to indicate whether it should be transmitted unprotected or protected (and similar for receive) is viewed as problematic. In practice, given the fact that the 7 platform implementers managed to successfully implement PANA-based authentication, I am not sure actually how much of an issue it really is. Robert On 7 November 2015 at 11:00, Alper Yegin <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> wrote: > On 05 Nov 2015, at 00:18, Michael Richardson > <[email protected]<mailto:mcr%[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
