Hi Alan,
My apologies for the long delay in this reply
On 21.07.18 16:11, Alan DeKok wrote:
> 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 think I caught one instance where "authentication" was really
superfluous. I would be happy to find more cases.
>
> 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.
Added words to this effect.
>
> 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.
This is a really good point. I've added some text along these lines.
>
> I think it would help future discussions to consistently refer to this
> phase as "provisioning", and not "authentication".
I'm sure we'll miss a few. Please keep us on our toes.
> i.e. "the device provisionally connects to the 802.1X network". Or "the
> device connects to the 802.1X network for initial provisioning".
Let's see how the next version reads. We can continue to evolve this text.
>
> 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."
Not quite yet, right? It still needs an LDevID. But yes, later.
>
> 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.
Ok.
>
> 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.
Ok.
>
> 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".
Thank you!
Eliot
> Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
