Hi Eduardo, 1. I' not sure what kind of alternative key derivation you are suggesting. Are you thinking about alternative ECDH curves, or RSA maybe? I believe even the low-end devices can do ECDHE these days so it is not obvious to me why that should be sometimes avoided.
2. This is a valid scenario for real-world deployments. Thank you for bringing it up. Managed handovers where the previous authentication / management server is still online and co-operative, are already supported. After copying the EAP-NOOB associations for the peer devices to the new server, the old server can send a new Realm field in the next Reconnect Exchange and then be taken offline. Alternatively, Radius routing can be set at the access networks to capture the old realm, and the new server can send the new Realm in Reconnect. We should check the EAP-NOOB spec though to make sure that there is nothing to prevent such usage. Unmanaged handovers where the old server just goes out of business are messier. We simply need to copy the server-side EAP-NOOB association database because there is nothing else for re-bootstrapping the security association - except of course a new user-assisted OOB step. Regards, Tuomas -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Eduardo Inglés UM Sent: Wednesday, 9 January, 2019 20:25 To: emu@ietf.org Subject: [Emu] Questions about EAP-NOOB draft Importance: High Dear Tuomas, First of all, I would like to say that EAP-NOOB draft is very complete and understandable. Also, with regard to the rest of the solutions I have found, I think it is a great solution so far and I like the way to approach the problems. I am working on implementing EAP-NOOB on resource-constrained devices for our use case. But I have the following 2 questions: 1. Regarding the key derivation section. There, it is explained the use of ECDHE for the key exchange. Do you have in mind to accept any alternatives besides the one explained in the draft? Maybe weaker methods or stronger but not so constrained. 2. I have a concrete use case. Specifically, I am interested in knowing how the Reconnect State works. In the scenario there are some devices that are going to be installed and then they will be inaccessible to be able to repeat the OOB step. These devices already have the corresponding security associations with a specific RealM. For example, a device from the University of Murcia is managed by a company called Odins. Now we assume that Odins stops managing those devices and Ericsson becomes the new manager with his own AAA Infrastructure. To establish the new RealM, I understand that the device should be restarted and the entire process done. Is there a mechanism to allow migration without having to repeat the OOB step? Regards, Eduardo Inglés. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
