Re: [Emu] Comments on draft-lear-eap-teap-brski
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
Re: [Emu] Comments on draft-lear-eap-teap-brski
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
[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
