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
