Re: [Emu] Re-Charter Considerations

[Owen Friel (ofriel)]

From: Emu  On Behalf Of Dr. Pala
Sent: Friday 20 July 2018 23:21
To: emu@ietf.org
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.  PAC 
Provisioning  . . . . . . . . . . . . . . . . . .  
21

   3.8.2.  Certificate 
Provisioning within the Tunnel  . . . . .  
22

   3.8.3.  Server 
Unauthenticated Provisioning Mode  . . . . . .  
23


   4.2.16. PKCS#7 TLV  
. . . . . . . . . . . . . . . . . . . . .  
53

   4.2.17. PKCS#10 TLV 
. . . . . . . . . . . . . . . . . . . . .  
54

   4.2.18. 
Trusted-Server-Root TLV . . . . . . . . . . . . . . .  
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 

Re: [Emu] Comments on draft-lear-eap-teap-brski

[Owen Friel (ofriel)]

Thanks Alan. These suggestions make sense and will help clear up the confusion. 
They can be incorporated in draft-01.

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Saturday 21 July 2018 15:12
To: emu@ietf.org
Subject: [Emu] Comments on draft-lear-eap-teap-brski

  One of the confusions from the meeting was "How can a device authenticate via 
802.1X if it doesn't trust the network?"

  I think the confusion is due to terminology.  The discussion in the meeting, 
and in the draft was about the device "authenticating" to the network during 
initial bootstrapping.  The authors may correct me if I'm wrong, but this step 
is really "provisioning".

  i.e. the device gets on the network without authenticating itself in the 
traditional sense (password, certificate, etc.)

  The document isn't clear on this, which makes it more difficult to understand.

  From Section 3.1 of the document:

   The device establishes an outer TEAP tunnel with the TEAP server and
   does not validate the server certificate.

  I would also add that the TEAP server does not authenticate the device (as 
such).  Instead, this step is about provisioning.

  Continuing from Section 3.1:

   The device sends a BRSKI-RequestVoucher TLV to the TEAP server.  The
   TEAP server forwards the RequestVoucher message to the MASA server,
   and the MASA server replies with a signed voucher.  The TEAP server
   sends a BRSKI-Voucher TLV to the device.

   If the MASA server does not issue a signed voucher, the TEAP server
   sends an EAP-Error TLV with a suitable error code to the device.

  It would help to say that neither the TEAP server nor the MASA server has (as 
yet) authenticated the device.  Which means that the device has established a 
secure tunnel to an unknown endpoint.  That endpoint may later reject the 
device, at which point the device tries another SSID.

  As a practical example, there may be two businesses who wish to install WiFi 
cameras.  Each business has their own SSID.  Any new device will randomly 
connect to one of the SSIDs.  If the device is known (somehow) to the business, 
it will be provisioned and allowed onto the network.  If the device is not 
known, it will be rejected, and will try the other SSID.

  I think it would help future discussions to consistently refer to this phase 
as "provisioning", and not "authentication".

  i.e. "the device provisionally connects to the 802.1X network".  Or "the 
device connects to the 802.1X network for initial provisioning".

  Once the device is provisioned, it can "authenticate" to the 802.1X network 
as normal.  i.e. from Section 3.1 again:

   Once step 5 is complete, the device has completed the BRSKI flow and
   has established trust with the network.

  I would add "the device can then perform normal 802.1X authentication with 
it's provisioned credentials, and with the provisioned network information."

  From section 4.1:

If the client is bootstrapping and has
   not yet completed a BRSKI flow, it will not have trust anchors
   installed yet, and thus will not be able to validate the server's
   certificate.

  It would help instead to use consistent terminology:

If the client is in the provisioning phase and has
   not yet completed a BRSKI flow, it will not have trust anchors
   installed yet, and thus will not be able to validate the server's
   certificate.


  And the same applies later:

   It is recommended that the client validate the certificate presented
   by the server in the server's Certificate message, but this may not
   be possible for bootstrapping clients that do not have appropriate
   trust anchors installed yet.

to:

   It is recommended that the client validate the certificate presented
   by the server in the server's Certificate message, but this may not
   be possible for clients which have not yet been provisioned with
   the appropriate trust anchors.

  The referenced IDs use the term bootstrapping", 
(ietf-anima-bootstrapping-keyinfra).  But RFC 7170 (TEAP) uses "bootstrapping" 
once, and "provisioning" many times.

  My $0.02 is that "provisioning" is clearer in this context than 
"bootstrapping".

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu