Hi Michael, I think you have outlined the factors well and I agree with what you say about the JA doing as little as possible. It could be a lot to ask of these peripheral devices to perform asymmetric crypto operations as they will generally have less processing power than the JCE (maybe considerably less) and could be overwhelmed by an array of attackers asking them to authenticate. It makes more sense to me to make the JA as stateless and as dumb as possible with regard to authenticating the JN. Therefore, it would just relay authentication traffic to and from the JCE.
Now to the protocols. EAP over CoAP, EAP over PANA, DTLS over foo; at the end of the day, there is little to choose between the amount of actual traffic in the process or the actual fundamental process itself. It comes down to what approach you prefer and if you have a particular protocol you prefer. One advantage of using say, PANA and EAP with an EAP method (e.g. EAP-TLS) is that the authentication mechanism is very well bounded. PANA works well as it can be used on both the unauthenticated point-to-point network between the JN and JA and the authenticated mesh network between JA and JCE, i.e. a common protocol. EAP-TLS is a good choice if you are also using TLS or DTLS at the application layer as the library can be shared. This was the approach in ZigBee IP. The main criticism of this approach is the use of UDP in the unauthenticated point-to-point network and thus having to have effectively two virtual network interfaces and thus stacks on the JA for the unauthenticated point-to-point network and the authenticated mesh network respectively. 802.15.9 would simplify the unauthenticated point-to-point network network part somewhat but doesn't address which protocol you would then use in the authenticated mesh network; RADIUS would be a possibility but is more suited to dial-in modems. An alternative approach is the one we took in Thread, where we assumed there was no end-to-end authentication transport protocol as such and DTLS is the fundamental protocol used for authentication of joining devices. This reduces the layering somewhat, as EAP is no longer required (DTLS performs some of the same functionality as EAP-TLS from a transport perspective), This still requires a means to transport the authentication through the mesh and CoAP is used for that purpose, effectively becoming the authentication transport in lieu of e.g. PANA/RADIUS. This in itself can get carried over DTLS records as application data. The advantages of this approach are DTLS used everywhere and a slightly simpler unauthenticated point-to-point network virtual network interface and stack. The possible disadvantage is now having to treat authentication transport as an application and thus having to specify and write that application. See http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf for more details. However, don't be under any misconception that any particular approach is easier or simpler as any solution has to meet the same fundamental requirements. Robert On 14 September 2015 at 19:22, Michael Richardson <[email protected]> wrote: > > Giuseppe Piro <[email protected]> wrote: > > I'm just thinking to a mechanism that may help JA to authenticate > > locally JN. I've called this mechanism "pre-join" scheme. The name > > could be not correct at all, let's just try to understand if it could > > be useful or not :-) > > It would be valuable if the JA had a way to either recognize potentially > legitimate nodes (and prioritize their traffic), or alternately, could > find a > way to stop talking to malicious nodes. > > > JN sends its certificate to JA ... and other fields that demonstrates > > the posses of the private key associate to the certificate, like the > > sign of the (ASN + Mac address).. or something like that. > > So there is a tension between a number of factors: > > 1) how much work can we insist that a JN do before joining? > (signing the ASN implies freshness, but if can do that, then maybe > you can sign some other challenge that comes from the JCE) > > 2) how much work can the JA be asked to do in order to validate this > pre-join > token? > > 3) how expensive is bandwidth at various depths of the tree vs computation > power? > > 4) given that we are going to bandwidth (energy-limit) the joining process, > how long does the process take even in the absense of attackers? > > This problem is very much like what the IPSECME WG has been discussing > in http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ > > An attacker are able to leverage significant amounts of computational power > From a relative point of view, and usually has an unlimited power budget. > > That's why I felt that the JA should do as little as possible (and have as > little custom code for the join processing: i.e. reuse existing > mechanisms). > That the join process should be driven/managed by the JCE as it potentially > has resources similar to the attacker. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
