Hi Eric,
On 3/8/21 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?
Yes.
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.
This breaks the use of (T)EAP. In the case of EAP, the server is the
one that grants access to the network and the client is the one that
asks for access (which is why it's known as the "supplicant"). The
EAP roles match the TLS roles so it wouldn't be possible for an EAP
client to act as a TLS server in the EAP method.
- 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.
There's no certs involved here. There is trust by the server in a
raw public key and there's an assurance (not quite authentication) of
the client based on who knows that public key (this is modeled on the
"Resurrecting Duckling" paper).
regards,
Dan.
-Ekr
On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer)
<sfluhrer=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>> wrote:
Again, last minute reviews…
It would appear that the exact computations that both the client
and the server need to perform needs to be explicitly spelled out,
as there are several possibilities.
Here is the one I could see that appear to have the security
properties that you appear to be looking for:
Variable names:
g – Well known group generator
h – The secret generator that is private to the
client and the server
z – The secret value known to the client; g^z = h
x – The client’s ephemeral DH private value
y – The server’s ephemeral DH private value:
Client keyshare:
This is the value g^x
When the server receives this, he selects y (and retrieves the
value h); he then transmits (as his keyshare) the value:
h^y
and stirs the value (g^x)^y into his KDF
When the client receives this (h^y), he computes:
(h^y) ^ (x z^-1)
(where z^-1 is the modular inverse of z modulo the group order),
and stirs that value into his KDF.
With this protocol, it appears that the client needs to know not
only h, but also the value z. However, this really needs to be
spelled out (and run past the CFRG to check for subtle issues)
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--
"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
