On Mar 29, 2022, at 12:53 PM, Michael Richardson wrote:
>> Use the normal SSID. Unauthenticated EAP-TLS. User ID of
>> "provision...@eap.arpa".
>
> 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
Alan DeKok wrote:
> On Mar 28, 2022, at 9:00 AM, Michael Richardson
> 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
On Mar 28, 2022, at 8:56 AM, Michael Richardson wrote:
> 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
On Mar 28, 2022, at 9:00 AM, Michael Richardson 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.
> The
>>> reconfiguration - how does a device with an existing configuration
>>> update it? When / where / why / how?
>>
>> 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
Alan DeKok 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.
> That's good, but I still have concerns with the process of using EAP
> for, well, almost
On Mar 26, 2022, at 12:01 PM, Michael Richardson 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.
That's good, but I still have concerns with the process of using EAP for,
On Mar 26, 2022, at 11:57 AM, Michael Richardson wrote:
> 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.
That's good.
>> reconfiguration - how
Alan DeKok wrote:
> 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
Alan DeKok wrote:
> 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.
> bootstrapping - starting from nothing, or
On Mar 25, 2022, at 3:18 PM, Oleg Pekar wrote:
>
> >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.
>
>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
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
13 matches
Mail list logo
