Subject: [Emu] EAP-CREDS - Question about Implementations

From: "Dr. Pala" <[email-masked]>
Date: Tue, 22 Mar 2022 07:31:05 -0600

Hello EMU,

I would like to address a question I could not answer during today's 
meeting.

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 like to thank the Chairs for the opportunity to present at IETF 
113 and we hope we can bring more details at the next meeting (spec and 
code).

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.

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.

If we look at the proposal for leveraging DPP credentials to deliver 
PKCS#7 in TEAP from the EAP-CREDS angle, we can see how the two 
proposals work really well together: the DPP/bootstrapping allows the 
delivery of network-specific credentials, while EAP-CREDS allows network 
controllers to enforce security policies by, for example, implementing 
the [ PKCS#10/PKCS#7 ] TLVs negotiation built in EAP-TEAP as a tunneled 
mechanism of EAP-CREDS (thus allowing the use of the same provisioning 
protocol for bootstrapping and for subsequent management).

Looking forward to great conversations!

Have a wonderful day!

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Mar 2022 12:14:34 -0400

On Mar 22, 2022, at 9:31 AM, Dr. Pala <[email-masked]> 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.