>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. [Oleg] If the configuration process is conducted by a centralized system (connected to EAP authentication server) then each step of configuring a specific supplicant can be tracked on the system, inducing the final result. So the admin can see it and undertake some recovery action. What are the example scenarios where such tracking is impossible?
>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. [Oleg] There are existing configuration and provisioning methods that require the supplicant to connect to a quarantine network and get the IP layer this way, then the provisioning software or manual user actions do the configuration. But this method is usually proprietary per network access control system and is pretty complicated. We can standardize this method: create a configuration and provisioning protocol over IP (not EAP) that will be supported by supplicants and network access control systems and all they need to do before is to accept the supplicant on the quarantine network. On Fri, Mar 25, 2022 at 9:37 PM Alan DeKok <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
