Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Eric Rescorla <[e-mail]>]

On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <[e-mail]>
wrote:

>
>
>
>
> *From:* TLS <[e-mail]> *On Behalf Of *Eric Rescorla
> *Sent:* 09 March 2021 06:27
> *To:* Dan Harkins <[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>
> *Subject:* Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
>
>
>
>
>
>
>
> On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins <[e-mail]> 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?



>
> 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