From: Emu <[email protected]> On Behalf Of Dr. Pala
Sent: Friday 20 July 2018 23:21
To: [email protected]
Subject: [Emu] Re-Charter Considerations
Hi Emu-ers,
I wanted to follow up the discussion from today's meeting. In particular, there
is some work that has been proposed that might require re-chartering as
indicated by Ekr and supported by the Chair(s).
I would like to push forward the request for re-chartering, in particular, I
would like to add the definition of one (or more) EAP-based credentials
provisioning mechanisms that would fit many use cases that we are currently
working on in different organizations.
In particular, the use cases that I am referring to are the following:
* Cellular Networks. The provisioning of Certificates (or other
credentials) to enable the use of EAP methods in different environments (e.g.,
CBRS Alliance, MutleFire, etc.) has been a problem that the current ecosystem
have not addressed efficiently. The use of OSU servers and the complexity (and
associated risks) of allowing (partial) IP access to non-authenticated devices
has limited the possibility for in-line provisioning of devices. The use of an
EAP-based mechanism that can be used for credentials provisioning (and renewal)
would greatly improve the feasibility of in-band credentials deployment. This
authentication mechanism would improve the possibility to use 4G\LTE (and
future 5G) networks for IoT credentials management which, today, seems to be
ignored because of the complexity required on the device.
* Cable Networks. With the deployment of the new DOCSIS 3.1 FDX
specifications and its newly defined support for EAP authentication via X.509
certificate throughout the whole ecosystem, the ability to provide an EAP-based
mechanism that can be used for credentials provisioning and renewal, would
greately improve the feasibility of in-band credentials deployment also in this
case and the possibility to further secure the infrastructure by allowing for
better certificates management (i.e., renewal, deployment, etc.)
* 802.1x / WBA / HS2.0. Also in these ecosystems, the possibility to
provision (and re-provision) dynamically credentials opens up the possibility
for more secure management of identities. As in the previous use-cases, the
management directly at layer 2 allows for a simple (and extensible :D) approach
to credentials provisioning for devices.
Therefore, counting the fact that all these ecosystems are looking at a
standardized / common solution to solve the same issue, I think it is the right
time to evaluate the possibility to work on this important aspect.
In my opinion, the WG should open up to evaluate the possibility to work on the
standardization of EAP-based provisioning mechanisms that would allow for
easier management options safer life-cycles of device and subscribers
credentials.
On the need to re-charter, I would like to point out that this type of work has
been done in the past, therefore is not a completely new territory (i.e., TEAP
/ EST).
[ofriel] Agreed. TEAP already supports provisioning mode of operation, and
provisioning of PAC, certificates and server trusted roots:
3.8.1<https://tools.ietf.org/html/rfc7170#section-3.8.1>. PAC
Provisioning . . . . . . . . . . . . . . . . . .
21<https://tools.ietf.org/html/rfc7170#page-21>
3.8.2<https://tools.ietf.org/html/rfc7170#section-3.8.2>. Certificate
Provisioning within the Tunnel . . . . .
22<https://tools.ietf.org/html/rfc7170#page-22>
3.8.3<https://tools.ietf.org/html/rfc7170#section-3.8.3>. Server
Unauthenticated Provisioning Mode . . . . . .
23<https://tools.ietf.org/html/rfc7170#page-23>
4.2.16<https://tools.ietf.org/html/rfc7170#section-4.2.16>. PKCS#7 TLV
. . . . . . . . . . . . . . . . . . . . .
53<https://tools.ietf.org/html/rfc7170#page-53>
4.2.17<https://tools.ietf.org/html/rfc7170#section-4.2.17>. PKCS#10 TLV
. . . . . . . . . . . . . . . . . . . . .
54<https://tools.ietf.org/html/rfc7170#page-54>
4.2.18<https://tools.ietf.org/html/rfc7170#section-4.2.18>.
Trusted-Server-Root TLV . . . . . . . . . . . . . . .
55<https://tools.ietf.org/html/rfc7170#page-55>
So while provisioning is out of scope of the current charter, it must have
previously been in scope during TEAP standardisation. For the specific ANIMA
use case we had in mind, we proposed reusing existing TEAP Provisioning Mode,
PKCS enrolment, and Trusted-Server-Root provisioning, and extending that to
support the ANIMA BRSKI specifics.
What we need now is the possibility to address (a) the bootstrapping problem,
and (b) the need for supporting additional provisioning protocols that address
different ecosystems (i.e., simpler approaches that can be implemented in
sub-systems like micro-controllers - this would facilitate the integration of
credentials management independent from the application layer / wifi module /
etc.), and (c) the possibility of defining provisioning protocols that might be
used with or without additional layers (e.g., EAP-tunneling).
I hope we will have the possibility to work on this important topic that, IMO,
have the possibility to impact many millions of people around the world and the
security of our networks (Cellular, WiFi, Corporate, and Home).
Looking forward to a productive discussion!
Cheers,
Max
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
