Subject: [Emu] Re-Charter Considerations

From: "Dr. Pala" <[email-masked]>
Date: Fri, 20 Jul 2018 18:20:43 -0400

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

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 25 Jul 2018 10:47:17 +0000

From: Emu <[email-masked]> On Behalf Of Dr. Pala
Sent: Friday 20 July 2018 23:21
To: [email-masked]
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.

  *   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).

Cheers,
Max
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]