Hi Tero: Thanks for this interesting discussion. Please see other comments inline > El 26 oct 2015, a las 23:19, Tero Kivinen <[email protected]> escribió: > > Rafa Marin Lopez writes: >>> Of course the ACL can also be distributed from tje JCE to the JAs, but >>> if the ACL is large, it is better to do the check when the JN joins. >>> This also protects the device association, and the IP address >>> assignments, as all communcation betwee JN-JA is done over 802.15.4 >>> frames, and no IP-address is needed yet. >> >> I guess HIP-DEX could be also used alternatively. In any case, how >> does the JCE know the JN is actually there? Because, in the end, the >> JCE does not authenticate the JN. This has been discussed in the >> past ("peer consent”). In my opinion, the JCE should be in charge of >> first-hand authenticating the JN. > > HIP-DEX is one of the KMPs which can be used with 802.15.9. I have not > really checked HIP-DEX for the set of features, so you might be right > there. > > Of course if the KMP is run only between JN and JA, and the ACL check > is done between JA and JCE, then JCE has to trust JA to check > credentials of the JN before letting it to join. If you do not trust > your JAs enough to do that, then you need to run EAP and run > authentication in the JCE instead of in the JA.
Running EAP is not related with either you trust the JA or not. You can run EAP in standalone mode between the JN and JA and follows the same schema you mention. There, the EAP authenticator is the JA. Or it can be placed on the JCE. I think the problem where you place the EAP authenticator (either in the JA or in the JCE). Or, in general, what is the entity that really authenticates the JN. I personally do not feel too much comfortable with the fact JN does not authenticate the JCE and vice-versa. But it is fine with me if the WG wants to go that way. > > With IKEv2 both options are possible, and which one you want to use > depends on the environment. > >>>> Case 1.B: EAP over PANA >>>> - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ >>>> messages for EAP-TLS ] + 1 packet to provision K2 >>>> - Implementation requirements: PANA, EAP method >>>> - Notes: JA is a passive relay >>> >>> Good thing here is that it is reusing lots of existing protocols, bad >>> thing is that you need lots of messages. Also I think you need to get >>> IP-address before you can run PANA (unless you run PANA over >>> 802.15.9), so that will add overhead and also consume resources. >> >> My understanding is that IKEv2 was designed to be transported on top >> of UDP. Thus, if IKEv2 can be transported in IEEE 802.15.9, >> similarly PANA or CoAP could be transported as well. In the case of >> CoAP, even there is some study with coapie. In case of PANA, there >> was some proposal about it. > > PANA is already defined to be used in the 802.15.9, but PANA defined > in 802.15.9 is used in bootstrapping, > i.e. getting LLCs and then you > need to still run some operational KMP over 802.15.9 to use those > credentials to generate the final keying materials. Btw, to avoid any confusion, from your comment it seems that you have made a distinction of a solution for bootstrapping and for the KMP. EAP over CoAP would be for bootstrapping as well. Thus, are we talking about the bootstrapping or the KMP (the security association protocol) after the bootstrapping? > I am not a PANA > expert, so do not know how it is supposed to work... :-) > > CoAP could be run over 802.15.9, but as it is not KMP it cannot be > used as KMP for generating keys for 802.15.4… It is the EAP over CoAP service that bootstraps the keys. > CoAP could use the > Multiplexing layer of the 802.15.9, and it can be used to fragment and > transport messages from one node to another and identify those > messages as CoAP messages instead of KMP messages. > > Adding new KMPs to 802.15.9 is quite easy as mostly you need to > allocate number for the KMP and define how the 802.15.4 keying > material is extracted from the KMP. > > Using 802.15.9 multiplexing layer is also easy, as there is separate > multiplexing ID, which can be used to multiplex KMP traffic and other > traffic (CoAP or similar) over 802.15.9 IEs. The multiplexing IDs are > ethertypes, so if you already have ethertypes allocated you can use > that directly, or if not, you can allocate one from the reserved > range. This is interesting. > >> Btw, in Zigbee IP they already use PANA and the link-local IPv6 >> address in the JN, as far as I remember. PANA has also a "PANA >> relay" (RFC 6345) defined for the JA. > > If I have understood correctly what is defined in the 802.15.9 Annex D > PANA, is just about what is done in Zigbee IP. > >>>> Case 1.C. EAP-PSK over CoAP + DTLS (e.g. draft-marin-ace-wg-coap-eap-02) >>>> - Traffic load: 10 messages between JN-JCE to establish a unique session >>>> key + >>>> 11 messages for DTLS to establish a session with the established key + 1 >>>> packet to provision K2 >>>> - Implementation requirements: EAP-PSK, (DTLS) >>>> - Notes: JA is a passive relay >>> >>> Same as 1.C. I.e. need IP-address, cannot protect IP-address >>> assignment (and device association, if that is needed before getting >>> IP-address), quite a lot of packets. >> >> As commented above, transporting CoAP in IEs could be a possibility. > > Yep. > >>>> Case 1.D. EAP-PSK over CoAP + custom protection of CoAP header/payload with >>>> the generated key >>>> - Traffic load: 10 messages between JN-JCE to establish a unique session >>>> key + >>>> 1 packet to provision K2 >>>> - Implementation requirements: EAP-PSK, custom CoAP security extension >>>> - Notes: JA is a passive relay >>> >>> Anything that we need to define here as security will be bad idea, >>> i.e. designing KMP is not that easy. There are lots of pitfalls you >>> might trip into, and I would recommend against specifying new KMP here. >> >> I do not think this is referring to a new key management protocol >> (there is no protocol exchanges) but only a way to protect CoAP >> messages at application level with some key material obtained from >> the EAP authentication. For example, OSCOAP could be an example >> (https://tools.ietf.org/html/draft-selander-ace-object-security-03) > > That will be very simple key management protocol, but it still will be > key management protocol. EAP is authentication protocol, and how to > derive keys from the secret it generates to protect something is KMP. The EAP Key Management Framework talks about (unicast or multicast) "security association protocol", and that is the assumption after the EAP authentication. So to me EAP is useful to “bootstrap" key material. Having said that, it is fine to me consider everything as a KMP. In fact, there was an old draft https://tools.ietf.org/html/draft-ohba-6tisch-security-01 with the description of several KMPs that can be used in different phases. > Even if it just defines key hierarchy and how to get keys for > different levels. > > Also quite soon you will realize that we need to have rekeys, and we > need to be able to distribute group keys, and we need to do group > membership management -> you are adding more and more KMP features… > >>>> Option 2: DTLS-based >>>> ——————————— >>>> Case 2.A: JN is a DTLS client >>>> - Traffic load: 11 messages between JN-JCE + 1 packet to communicate K2 >>>> over >>>> the established session >>>> - Implementation requirements: (DTLS), relay application >>>> - Notes: JA is a passive relay >>> >>> This would allow us to use any DTLS authentication methods, i.e. I >>> tihnk we could use raw public keys etc. >> >> The usage of EAP would also provide all the flexibility in term of >> authentication method. That was the main motivation of the EAP >> design. > > But immediately when you move from the built in authentication methods > of the KMPs like DTLS, or IKEv2 to EAP you get more messages, i.e. > more overhead. > Thats why IKEv2 do not use EAP all the time, it uses it > only if base shared key, or public key authentication is not enough… > -- > [email protected] > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
