On 3/10/21 4:12 AM, Eric Rescorla wrote:
On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <ofr...@cisco.com
<mailto:ofr...@cisco.com>> wrote:
*From:*TLS <tls-boun...@ietf.org <mailto:tls-boun...@ietf.org>>
*On Behalf Of *Eric Rescorla
*Sent:* 09 March 2021 06:27
*To:* Dan Harkins <dhark...@lounge.org <mailto:dhark...@lounge.org>>
*Cc:* <tls@ietf.org <mailto:tls@ietf.org>> <tls@ietf.org
<mailto:tls@ietf.org>>
*Subject:* Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins <dhark...@lounge.org
<mailto:dhark...@lounge.org>> wrote:
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).
[ofriel]Its not true that the server does not have a valid
TLS cert, the EAP server will have a cert but the client
will have no way of verifying it. Its more
https://tools.ietf.org/html/rfc8446#appendix-C.5.
- 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.
Thanks for the clarification. This is party of why it's helpful to
understand the requirements.
- 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
To clarify, what I was proposing was that that you replace
knowledge of the pubkey
with knowledge of the PSK and have the client (acting as the
server) present its
public key in the RFC 7250 Raw Public Key mode. The reason certs come
into play is that TLS 1.3 prohibits the use of certificate based
exchanges (which
should include Raw Public Key) with PSKs, and 8773 relaxes that.
However, if you can't have the client act as the server, then
we'll need to find
another approach. As I indicated on the call, what would be
helpful to me would
be a description of the externally visible invariants that we need
to satisfy.
[ofriel] Another requirement is that the full public key Y_c is
not transmitted as part of TLS handshake from client to server. We
cannot not use RFC 7250 as is. Instead, something like the Known
Certificates proposal in cTLS
https://tools.ietf.org/html/draft-ietf-tls-ctls-01#section-5.1.3
would work.
Is that a primary requirement or a derived requirement?
I'm not sure of the distinction you're making here. But let me address
a misconception mentioned earlier (not by you, but mentioned nonetheless)
to hopefully clear this up:
In DPP the public key is not secret, but the knowledge of the public key is
supposed to be restricted to those who are legitimate owners of the thing.
The more gratuitously a thing distributes it's public key the less assurance
the thing will get that the holder of it's public key is legit. Consider
that
the Oprah level of bootstrapping-- "you get my public key!, and you get my
public key!, and you get my public key!"-- would end up being TOFU since the
thing doesn't actually know who it ended up talking to (everyone could
theoretically have gotten the public key), but restriction of the thing's
public key to someone who purchased the thing-- consider transfer of data
in the cloud upon delivery of a paid purchase order-- can allow the thing
to have a higher level of assurance that it's talking to the legitimate
owner.
That's what we want to leverage with TLS-pok. It's not that the public key
is secret, it's that the restriction of the public key's knowledge is
directly proportional to the assurance the thing gets that it's talking to
its legitimate owner.
So in TLS-pok, the client is getting an assurance that he's connecting to
the right network by the server proving knowledge of its public key. If the
client starts out by saying, "here's my public key" it will eliminate any
assurance the client could've gotten from restricting access to its key
and reduce TLS-pok's client assurance to TOFU; we don't want to do that.
regards,
Dan.
Something like this could work:
Setup:
Client has X_c, Y_c
Server is provisioned with Y_c (the bootstrap RPK)
Both sides could derive (using some suitable hashing algorithm):
keyID = H1(Y_c)
PSK = H2(Y_c)
Server keeps a map of keyID to Y_c.
keyID could be common or unique for the PSK and RPK.
C->S: Client sends the keyID for the derived PSK
ClientHello
+tls_cert_with_extern_psk
+pre_shared_key identity=keyID
S->C: Server looks up the Y_c, derives PSK, and injects into
key_schedule. Server sends its PKI Certificate/CertificateVerify
which client ignores. Server requests client cert so that client
can prove it knows X_c.
ServerHello
+pre_shared_key selected_identity=keyID
{EncryptedExtensions}
{CertificateRequest}
{Certificate}
{CertificateVerify}
{Finished}
C->S: Ignores server Certificate/CertificateVerify. If handshake
reaches here, at this stage, server has proven knowledge of Y_c
via derived PSK.
{Certificate, cert_data does not include RPK, but instead keyID as
per cTLS}
{CertificateVerify}
{Finished}
Server verifies Finished. At this stage, client has proven
knowledge of X_c.
I believe this meets the requirements that:
- server proves knowledge of Y_c
- client proves knowledge of X_c
- Y_c is not send over the wire in cleartext
- reuse existing RFCs, aligns better with existing TLS flows, no
new extensions (well we need to do something for Certificate
including keyID)
Yes, this might work. I think we would need analysis to demonstrate
that this doesn't allow an attacker to derive Y_c.
-Ekr
--
"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
