I agree with Robert that PANA needs to be viewed as a side stack. It involves more than just restricted forwarding rules and hooks for the upper layers. It also involves resource isolation at the lower layers to help ensure that unauthorized traffic cannot interfere with authorized traffic. Logically they need to be separate, isolated stacks. Although, an implementation may choose to share a bunch of components.
Also, I'd caution that specification and basic functional testing alone does not prove a robust solution. How much security or penetration testing has been done on existing implementations? I would argue large-scale deployment certainly helps build confidence beyond what specification and basic functional testing can do. -- Jonathan Hui On Tue, Nov 10, 2015 at 3:00 AM, Robert Cragie <robert.cra...@gridmerge.com> wrote: > Alper - I completely agree with what you say and did note earlier that, > given the 7 independent implementations for ZigBee IP, it clearly isn't a > serious obstacle. However, it is useful to understand potential issues with > any given solution; any solution will have certain issues which have to be > addresses. > > Robert > > On 8 November 2015 at 23:28, Alper Yegin <alper.ye...@yegin.org> wrote: > >> Robert, >> >> Right. Even though PANA is a UDP-based protocol, one cannot assume it >> shall be implementable just like any "UDP-based user-land application". >> Like you said it's a control plane traffic/application, and it needs some >> hooks from the stack. This is very much similar to other UDP-based >> protocols like Mobile IPv4 and DHCP. They also need hooks with lower layers. >> >> Alper >> >> >> >> On Nov 9, 2015, at 1:01 AM, Robert Cragie wrote: >> >> Hi Alper, >> >> PANA is UDP traffic, which is typically sent using sockets. There is no >> defined socket option (in e.g Linux socket API) to specify options for >> sending the packet when it is processed 2 layers down at the MAC layer. So >> some might say that specifying a layer 2 concept at layer 4 is layer >> violation. Also, the unprotected PANA only goes one hop and should not be >> routed, therefore it is treated differently from other IP packets. This is >> in addition to the enforcement point policing for unprotected MAC traffic. >> Hence thinking about it like a "side stack". >> >> Other comments inline. >> >> Robert >> >> >> On 7 November 2015 at 21:26, Alper Yegin <alper.ye...@yegin.org> 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. >>> >> >> <RCC>Some stacks don't work like that though. Sure, if you have control >> over the stack, it is easy enough to implement and as you say, it is simply >> demultiplexing and conceptually quite easy to understand but there are >> certain points in the layer traversal that do have to be treated >> differently</RCC> >> >> >>> 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 <alper.ye...@yegin.org> 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 <malisa.vuci...@imag.fr> >>>> wrote: >>>> >>>>> >>>>> > On 05 Nov 2015, at 00:18, Michael Richardson <mcr+i...@sandelman.ca> >>>>> 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 >>>>> 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 >>> >>> >>> >> _______________________________________________ >> 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 > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
