Michael Richardson writes: > > 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. 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. 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. > 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. 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. 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 extension which maps the real time to ASN inside the certificate. I.e. the certificate could say that the Issue time of this certificate in ASNs is 0x1251400000 and ASN is incremented every 0.01 seconds. Using that the JN can calculate the last ASN when the certificate is still valid. Or we can just assume that clock chips are so cheap and as tsch requires devices to keep track of time even when they are sleeping, they can also keep track of real time too, thus no need to do anything like that, just use normal certificate validity times. 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. Thermostat of course will want to authenticate the commands that are sent to it, but that might be better done using authenticated commands, and not link level security. So what we want out from the KMP is that JCE can limit who can consume resources from his network, i.e. he wants to limit who can join by using ACL. JA wants to verify the from the JCE that JN is allowed to connect before using too much resources. JN can just try to connect all networks, and see which one of them has the services it needs, and quite often those services do require upper layer authentication, and if that authentication fails, it might try to do corrective actions. > 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. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
