On 3/8/2021 8:00 AM, Eric Rescorla wrote:
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with information about each
client (in this case, Y_c).
And the desired property you are looking for is that:
1. The client authenticates to the server using X_c
2. The client will only connect to servers that know the
per-client information
Is this correct?
Assuming it is, it seems like we could accomplish this with
less change to TLS. Here is one proposal (warning: not
at all analyzed so may be totally broken).
- Have the client take on the TLS server role, and use RFC 7250 raw
public keys. This addresses requirement 1.
- Store a separate per-client value K_c (this can be derived from the
X_c to ease the burden on the client) and use RFC 8773 external PSK
with cert authentication to inject K_c into the key schedule.
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.
I don't think that these scenarios lend themselves easily to "reversing
the roles". At least, not easily.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
