On Mar 22, 2022, at 9:31 AM, Dr. Pala <direc...@openca.org> wrote: > Specifically, there was a question on the Chat from Alan about EAP-CREDS > adoption in CBRS-A. My information is a bit outdated, but AFAIK there was no > implementation (that I am aware of or publicly disclosed) when the specs were > released and I am not sure what type is used. We need to progress EAP-CREDS > to make sure implementations can be interoperable also outside the CBRS > environment.
I would hope that existing implementations use a vendor-specific EAP type. > One aspect that seemed quite common in some of the presentations and the work > in EMU is that there seem to be few emerging needs that go beyond the > original purpose of EAP: credentials bootstrapping (or provisioning) and > credentials management. There's a lot of work related to this in many working groups and other standards bodies. Hopefully there will be little overlap. > The main difference between the two needs relies in the fact that usually > bootstrapping leverages an identity to provision the "network credentials" > based on the bootstrapping ones, while credentials management deals with the > evolution of such credentials (i.e., updating passwords every x days, > renewing certificates, etc.). From this point of view, we see EAP-CREDS as > adding the "management" part on top of the provisioning part. My opinion is still that we should limit EAP to authentication, and as little else as possible. EAP isn't a generic transport layer. It's useful to treat it like that, but... The more we add to EAP, the sooner we run into the ~64K limit of EAP transport. i.e. in practice, it's difficult to get more than about 50 rounds, and about 64K of data. That makes EAP unsuitable for anything other than the most trivial of bootstrapping / management methods. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
