What I'm interested here is the ability to leverage the 802.15.9 KMP *code* to assist with the join process. While I love IKEv2 and HIPDEX, I'm not convinced that there is code+ram space for those KMPs as well as the DTLS that 6top/CoAP is going to require. I'd like it to all converge :-)
Tero Kivinen <[email protected]> wrote: >> Tero Kivinen <[email protected]> wrote: >> > You can also run IKEv2 over 802.15.9 using raw public keys, which will >> > simply be 4 messages between JN-JA, and then you do need to run some >> > protocol between JA-JCE, where the JA sends the hash of public key + >> > EUI-64 to the JCE, and JCE says whether that device should be allowed >> > to connect (i.e. ACL check done on the JCE). >> >> Yes, that's good, but how does the device authenticate the JCE? > Same way as how the JCE authenticates JN. I.e. there is ACL in the JN. That's just not workable. > When using pre-shared keys you configure shared secret between the JN > and JCE. With raw public keys you configure hash of the public keys to > be allowed to connect. When using pre-shared keys, the JN comes with a secret on some media (XLS file with packing slip, QR code, etc.). It's a bearing key. Anyone with that key can cause that JN to join. It's not great, but how bad it is depends upon the security of the container of the key. One can also imagine online systems where the PSK is returned to an authorized host (the JCE) upon presentation of some other token. But, if you are going to do that, you might as well return a certificate (signed by the vendor, perhaps via a chain) that the JN can verify. > The JCE quite often have some kind of user interface which allows it > to be configured, i.e. how you can add new allowed JNs to it. The JN > might not have real UI, but quite often you do the bootstrap / > provision step in such way that when you first time boot up the > device, it will trust the first JCE it will see, and it will then take > that public key and start trusting that. That's been deemed unacceptable by many. >> Do you think the EUI-64 should be signed by the public key? > Another question is, how the JN then starts trusting to JA when the > KMP is run directly between JN and JA. Yes, that definitely another question I had, but I hadn't gotten to it yet. > In this case the JA only does > ACL checks from JCE, and JN does not know anything about JA > beforehand. For that you most likely need some kind of certificates > generated by JCE, i.e. JCE can give JA a certificate which is signed > by JCE and which has public key of JA in it, and when JN sees that and > it knows from bootstrap / provision step that it can trust JCE, it > then knows it can trust JA also, when the certificate has EUI-64 in it > too... In this case JCE can act as very simple local CA with short > lived certificates. Yes, this is definitely doable. > Perhaps it could even use ASN instead of timestamp to tell when the > certificate expires, i.e. it could give JA a certificate which is > valid for 8 hours, and tell that this means it will expire at ASN > number 0x1251451244. One way to do that would be to define certificate That's a really good idea! > All of these will depend on the environment, and what kind of features > is needed in the devices. As I explained earlier, quite often the JN > is not really even interested on the authentication of JCE. For > example for temperature sensor, it does not care to whom it sends the > information. JCE is interested to authenticate JN as it wants to know > it can trust the sensor reading. Sometimes that's true, but the problem is that if the temperature sensor is not on the correct network, then it's broken, and has to be replaced. >> Would you include some nonce from the JCE to assure freshness? > I assume the KMP is properly defined, and it provides freshness, i.e. > if KMP is run between JN and JA that will be fresh. The JCE already > trusts JA and I do not think there is need to provide freshness > information in the ACL check from JA to JCE. If the JCE wants to allow > JA to cache ACL results, it will need to provide information how long > the JA can cache the ACL check results received from JCE. This nonce is not used in the KMP, but rather, in the protocol where the JA sends the JN's (signed) EUI-64 to the JCE. The nonce would be included by the JN into that signature, so that the JCE would know that the JN did the signature now, and wasn't being subject to some kind of tunneling attack. (that's not the right term) -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
