Subject: [Emu] Provisioning, configuration, etc. and EAP

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Mar 2022 14:36:50 -0400

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.

---

From: Oleg Pekar <[email-masked]>
Date: Fri, 25 Mar 2022 22:18:40 +0300

>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-masked]>
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.
>
>
>   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.
>
>     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.
>
> 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?
>
>   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-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Mar 2022 16:09:25 -0400

On Mar 25, 2022, at 3:18 PM, Oleg Pekar <[email-masked]> wrote:
> [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? 

  It's not about tracking, it's about debugging.

  The administrator may see "failed at step 4 out of 5".  OK, what can be done with that information?  There is no path to the end-user system which allows for manual correction or updates.

  Since provisioning is part of EAP, there is no path to the user to inform the user as to what went wrong, or how to fix it.

  If instead configuration is done via a "real" network (even a limited one), things get better.  The administrator can still see which steps went wrong, but may also have a "back channel" to the device in order to fix things.  The user can run a local tool, perhaps even with a GUI, which presents useful error messages.

  RFC 3748 Section 5.2 provides for EAP notifications, but most supplicants treat those as failure.  And don't display anything to the user.

  I think we don't want to shoe-horn a general-purpose notification system into EAP.  Even if we add something internal to an EAP type, that information still has to be carried (somehow) through to the user interface.

> [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.  

  I support such standardization.  Ideally using existing networking protocols.

  For example, RFC 8572 provides for similar tools (DNS SRV records + YAML / RESTCONF) for provisioning devices.  If it works for devices, why not do something similar for end-user devices?

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Mar 2022 16:57:24 +0100

>   I would split this up into:

I'm gonna quibble with your choice of terms, because there has been some
progress/convergence in the terminology.  This is good news, because sharing
terminology is an important leap forward.

    > configuration get onto a new network, perhaps with a new identity?

The term "onboarding" is now used for this step.
(Yes, BRSKI gets it wrong)
I'm a bit unclear about how these steps differ.

The term "provisioning" has come to mean when the "almost nothing" is
provided to the device in the factory.  That's come to mean an IDevID, but it
can also mean an (e)SIM, or other long-term shared secret.

The term "commissioning" has come to mean provisioning + configuration.
That is, the device is recognized, it is joined to the network, and it might
be told what it's role in the Superbowl 3000-drone display is.

    > update it?  When / where / why / how?

Why is this step different than configuration?

There is a plan to unify/contrast the terminology in section 4 of:
      draft-irtf-t2trg-secure-bootstrapping/

but that section hasn't happened yet.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Mar 2022 17:01:41 +0100

Alan DeKok <[email-masked]> wrote:
    > 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.

64K is plenty to run RFC8995.  Probably we can get away with a total of less
than 10K exchanged in the worst case situations,  with 2K being more typical.

    > additional services in order to do provisioning.  This may not always
    > be possible.  As Eliot pointed out, there are also security issues with

Specifically, my original notion was to have an SSID called "ONBOARDING",
which was unencrypted.  (I would run on DHCPv4, which makes smartphones give
up and go away.  IPv6-LL only)

I can live with it being trivially encrypted via EAP-TLS with a "well-known"
username/password like we do with the "ietf" network at meetings.

The cost is that it has to be setup and available across a potentially large
enterprise situation.  At the small scale of one or two home routers, it's
just not a problem.

We will have to give up on WPA-PSK for the home, because RCM (Madinas) just
can't cope with maintaining policies for different devices when the devices
all have the same PSK.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Mar 2022 09:48:35 -0400

> terminology is an important leap forward.

  That's good.

> Why is this step different than configuration?

  I put that in, in part because of EAP-CREDS.  In part because I'm not sure that updates fall within the bounds of provisioning / onboarding.

  i.e. I already have something, and I can get onto the network.  How often do I refresh those credentials?  What happens if my authorization changes?  How do I get told if my credentials are withdrawn?

  Perhaps this could better be described as policies and signalling for refresh and updates of provisioned data.  The act of doing the update is just provisioning.  Knowing when / where / how / why to do that update isn't quite part of the provisioning process.

> but that section hasn't happened yet.

  I saw that.  :(

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Mar 2022 09:58:07 -0400

> than 10K exchanged in the worst case situations,  with 2K being more typical.

  That's good, but I still have concerns with the process of using EAP for, well, almost everything.

  Anonymous / unauthenticated EAP-TLS exists.  I'd like to know why that's unacceptable for provisioning general-purpose devices.

  For example, see any number of device management products.  These products download large amounts of configuration, and even applications to end-user devices.  This process is part of provisioning the device, and can't be done via tunnelling that data in EAP.  So if we're not using EAP for most of that complex provisioning, why not just use the same methods for all of it?

> up and go away.  IPv6-LL only)

  Similar things are done in the 3G/4G/5G space.  But either via other standards bodies, or vendor-specific means.  i.e. people are laying additional things on top of EAP, because (a) they can, and (b) the IETF won't.

  The result is that there is a "grab bag" of solutions, instead of a unified approach.

> enterprise situation.  At the small scale of one or two home routers, it's

  I'm not clear how a large enterprise causes any issues.  For my proposal, just put records into DNS, and various data into web pages.  Anyone with corporate credentials can then get on the secure WiFi network.

> can't cope with maintaining policies for different devices when the devices

  I agree.

  It's 2022... why is it difficult to get onto a friends WiFi network, securely, and easily?

  The answer I see is that the products are a collection of things from different standards bodies, who often don't communicate well with each other.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 15:00:03 +0200

Alan DeKok <[email-masked]> wrote:
    >> 64K is plenty to run RFC8995.  Probably we can get away with a total
    >> of less than 10K exchanged in the worst case situations, with 2K being
    >> more typical.

    >   Anonymous / unauthenticated EAP-TLS exists.  I'd like to know why
    > that's unacceptable for provisioning general-purpose devices.

    >   For example, see any number of device management products.  These
    > products download large amounts of configuration, and even applications
    > to end-user devices.  This process is part of provisioning the device,
    > and can't be done via tunnelling that data in EAP.  So if we're not
    > using EAP for most of that complex provisioning, why not just use the
    > same methods for all of it?

Well, this is not something I'd do as part of onboarding, but rather as part
of _configuration_, and I agree that it would be better to just use IP for that.

    >> The cost is that it has to be setup and available across a potentially
    >> large enterprise situation.  At the small scale of one or two home
    >> routers, it's just not a problem.

    >   I'm not clear how a large enterprise causes any issues.  For my
    > proposal, just put records into DNS, and various data into web pages.
    > Anyone with corporate credentials can then get on the secure WiFi
    > network.

The issue is that new SSIDs have to deployed over hundreds of access points.
This new "LAN" has to have VLANs deployed for it,  and if done wrong, might
need DHCPv4.
There is a limit in air-time for the number of beacons that the APs have time
for as well, but it's not a concern, AFAIK, until you get into the O(10^2) range.

    >   It's 2022... why is it difficult to get onto a friends WiFi network,

Two out of three?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 14:56:39 +0200

>   I put that in, in part because of EAP-CREDS.  In part because I'm not
    > sure that updates fall within the bounds of provisioning / onboarding.

    >   i.e. I already have something, and I can get onto the network.  How
    > often do I refresh those credentials?  What happens if my authorization
    > changes?  How do I get told if my credentials are withdrawn?

I understand.
For mechanisms like BRSKI (and CSP/MATTER, and probably UPC UA) where the end
product of onboarding is a certificate issued to the device, then the
question about when to refresh is mostly given by the notAfter parameter.
In most cases one should start refreshing those credentials at the 50% mark.

The ACME WG is discussing having the certificate renew point be better
specified (in the ACME protocol), but I think that we will learn from this
and wind up with something in the certificate if the protocol can't carry
additional meta-data.

    >   Perhaps this could better be described as policies and signalling for
    > refresh and updates of provisioned data.  The act of doing the update
    > is just provisioning.  Knowing when / where / how / why to do that
    > update isn't quite part of the provisioning process.

Agreed.
There are advantages of having renewals spread across time, but there are
also disadvantages as it spreads the failure signal across time as well which
makes it harder to see that there is a real problem.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Mar 2022 17:35:20 -0400

> of _configuration_, and I agree that it would be better to just use IP for that.

  I'd argue that onboarding is just a special case of configuration.

> The issue is that new SSIDs have to deployed over hundreds of access points.

  Use the normal SSID.  Unauthenticated EAP-TLS.  User ID of "[email-masked]".

> This new "LAN" has to have VLANs deployed for it,  and if done wrong, might

  Yes.  I'm not sure that VLANs are a limited resource, or are difficult to provision.  GVRP has existed for a while...

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Mar 2022 17:37:17 -0400

> and wind up with something in the certificate if the protocol can't carry

  That's a good chunk of what I'm proposing in my document.  There are often existing cert fields which contain the information needed for configuration.  It would be nice to use them.

> makes it harder to see that there is a real problem.

  Generally if people can't renew, the server should log errors, or the end user device has a real network where it can report errors.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Mar 2022 12:53:25 -0400

Alan DeKok <[email-masked]> wrote:
    >> Well, this is not something I'd do as part of onboarding, but rather
    >> as part of _configuration_, and I agree that it would be better to
    >> just use IP for that.

    >   I'd argue that onboarding is just a special case of configuration.

Yes, many have tried to that, including NETMOD.
But it's a special case.
I don't mind using IP, but to do that, 

    >   Use the normal SSID.  Unauthenticated EAP-TLS.  User ID of

But that could be even worse in many settings!
To do this safely means setting up layer-2 isolation for the device so that
it can't talk to (or attack) any other device (nor be attacked).

Or do you have some other idea on how to support this?

    >> This new "LAN" has to have VLANs deployed for it, and if done wrong,
    >> might need DHCPv4.

    >   Yes.  I'm not sure that VLANs are a limited resource, or are
    > difficult to provision.  GVRP has existed for a while...

It's not just the cost of the VLAN, it's the management functions associated
with them as well.   But, I'm just the messenger here:  I actually would
prefer this.

-- 
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Mar 2022 14:25:13 -0400

> Or do you have some other idea on how to support this?

  Layer 2 isolation is the main one.

  There's also the realization that modern access devices are fairly powerful, and many contain walled gardens / captive portals.  It shouldn't be difficult to extend that functionality with basic provisioning methods based on DNS / web.  Which the systems already have.

  Alan DeKok.