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
