Hi Christian,
On 3/8/21 11:49 AM, Christian Huitema wrote:
The list of requirement reminds me of two scenarios: the Anima problem
of "bringing a clean device into the new owner's network"; and the
corporate Wi-Fi problem of "connecting a device to the corporate
Wi-Fi". In the Anima problem, the server can verify that the device
identity corresponds to something that the owner bought, but the
device has no knowledge of where it is connecting to. Anima proposed
to close the security loop by having the device connect to the
enterprise first, then check a certificate issued by the manufacturer
to device owner. The Wi-Fi scenario uses EAP over TLS and the classic
solution is a variation of TOFU: ask the device user to verify that
the key is what it expects for the SSID, then remember that for the
following connections. In this scenario, the Wi-Fi server is always
entitled to verify the client's identity and authorization.
Yes, this is the scenario. Although there is no "expects for the
SSID". The client
has no knowledge of anything, no provisioning, no credentials, and in
many cases no
UI by which someone would provision an SSID and some credential. It's a
classic
catch-22-- I need a credential to get on the network but I need to get
on the network
to get a credential.
Wi-fi solves this problem by doing DPP over special 802.11 frames
which are sent
pre-association. So the client doesn't need to know an SSID or connect
to anything
in order to engage in a handshake. The network entity authenticates the
client based
on the bootstrapped public key and the client gets an assurance that
this is the
right network because the network entity knew its public key (based on
the resurrecting
duckling model from [1]).
For the wired case, which is what TLS-pok is addressing, the network
is whatever
port the device is plugged into and it wants to get an assurance that
the entity on
the other side of that port knows its public key. It's a bit more than TOFU
because if the other end doesn't know its public key (if it's not the
legitimate
network) then it won't complete the TLS handshake.
I don't think that these scenarios lend themselves easily to
"reversing the roles". At least, not easily.
You're right, they don't.
regards,
Dan.
[1] https://link.springer.com/chapter/10.1007/10720107_24
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
