There has been a push to perform provisioning and/or configuration over EAP. e.g. TEAP, NOOB, and various other proposals. There are both costs and benefits to this approach.
The benefits are that admins can configure end-user systems with minimal effort. "Download things over EAP" is simply to explain, and simple to administer. When it works, it's great. No one has to deploy additional systems, or do additional configuration. Just poke the authentication servers, and they will configure the clients / supplicants. However, there are multiple standards for doing provisioning over EAP, and more are proposed. This would seem to indicate that the solutions are designed for specific needs, and that there is no over-arching design theory, requirements, or process. On top of that issue, the costs of using EAP are non-zero, and the failure modes are significant. When this configuration process fails or does not work, there is typically no way to inform the user or administrator as to what went wrong. Which makes it essentially impossible to debug configuration and compatibility issues. EAP implementations are limited to exchanging ~64K of data before supplicant and/or server gives up. If there is a need to exchange more data than this, it's impossible. Configuration data tends to grow over time, because of a tendency to just use the existing system, even though it isn't really intended for that use. People tend to (ab)use existing systems in surprising ways, too. As Bernard noted in the meeting, RFC 3748 Section 1.3 says that EAP is not a general transport protocol: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more. I've been pushing for provisioning via standard internet protocols. RFC 9190 Section 5.6 explicitly provides for unauthenticated EAP-TLS, where the client may not even verify the servers certificate. This practice has not been widely used. IIRC, either the WiFi alliance or the WBA defines unauthenticated EAP-TLS for provisioning, but uses a vendor-specific EAP type. It's not clear why EAP-TLS was insufficient here. This method also has a cost. Administrators now have to set up additional services in order to do provisioning. This may not always be possible. As Eliot pointed out, there are also security issues with exposing additional servers (EST, etc.) to unauthenticated users. However, the benefit of this approach is that the provisioning system becomes infinitely flexible. It can use any existing internet protocol. It can download any amount of data. I think it's useful to take a step back, and discuss the requirements. There are many users of EAP, and each are creating solutions largely in a vacuum. It would be helpful to get a good description of the problem statements, as it relates to EAP. I would split this up into: bootstrapping - starting from nothing, or almost nothing, how does a device get on the network, and get a minimal configuration enabled? provisioning - how does a device with some existing network access / configuration get onto a new network, perhaps with a new identity? reconfiguration - how does a device with an existing configuration update it? When / where / why / how? I'm sure that there are good reasons for using EAP here. But I can't help but wonder if there's a better way that 3-4 different methods which all layer on top of EAP. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu