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
