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

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 8 Mar 2021 15:09:03 +0000

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)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Mar 2021 08:00:08 -0800

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.

-Ekr

On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer) <sfluhrer=
[email-masked]> 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.
>
>
>
>                 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
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Mar 2021 11:49:42 -0800

>   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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 08 Mar 2021 13:16:57 -0800

Hi Scott,

On 3/8/21 7:09 AM, Scott Fluhrer (sfluhrer) wrote:
> 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:
>
>                 h – The secret generator that is private to the client 
> and the server
>
> When the server receives this, he selects y (and retrieves the value 
> h); he then transmits (as his keyshare) the value:
>
>                 h^y
>
> 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)
>

   That is an interesting exchange but it is not DPP and it is not TLS-pok.

   regards,

   Dan.

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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 08 Mar 2021 13:17:19 -0800

Hi Eric,

> 2. The client will only connect to servers that know the

   Yes.

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

>   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=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>                     h – The secret generator that is private to the
>     client and the server
>
>     When the server receives this, he selects y (and retrieves the
>     value h); he then transmits (as his keyshare) the value:
>
>                     h^y
>
>     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)
>
>     [email-masked] <mailto:[email-masked]>

---

From: Dan Harkins <[email-masked]>
Date: Mon, 08 Mar 2021 13:46:25 -0800

Hi Christian,

On 3/8/21 11:49 AM, Christian Huitema wrote:
> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Mar 2021 14:27:12 -0800

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

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

-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 9 Mar 2021 07:47:29 -0800

On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins <[email-masked]> wrote:

> [Joe] Technically, I think it would be possible for the supplicant to take
on the TLS server role and the server the TLS client role.  This would be
counter to the way all TLS based EAP protocols work today, but there is
nothing fundamental to EAP that prevents it.

> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
> --

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 10 Mar 2021 07:43:07 +0000

From: TLS <[email-masked]> On Behalf Of Joseph Salowey
Sent: 09 March 2021 23:47
To: Dan Harkins <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hi Eric,

Is this correct?

  Yes.

  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.
[Joe] Technically, I think it would be possible for the supplicant to take on the TLS server role and the server the TLS client role.  This would be counter to the way all TLS based EAP protocols work today, but there is nothing fundamental to EAP that prevents it.
[ofriel] This would be a huge change for EAP, require a lot of standards work, and be massive task to get deployed across the EAP installed base. As you say, it is counter to everything EAP today, and it doesn’t seem practical.

  regards,

  Dan.

-Ekr

On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]<mailto:[email-masked]>> wrote:
Again, last minute reviews…

Variable names:
                h – The secret generator that is private to the client and the server

Client keyshare:
                This is the value g^x

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

TLS mailing list

[email-masked]<mailto:[email-masked]>

--

escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 10 Mar 2021 07:43:34 +0000

From: TLS <[email-masked]> On Behalf Of Eric Rescorla
Sent: 09 March 2021 06:27
To: Dan Harkins <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hi Eric,

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

Is this correct?

  Yes.

Thanks for the clarification. This is party of why it's helpful to understand the requirements.

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.

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)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Mar 2021 04:12:49 -0800

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

>
>
>
>
> *From:* TLS <[email-masked]> *On Behalf Of *Eric Rescorla
> *Sent:* 09 March 2021 06:27
> *To:* Dan Harkins <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
>
>
>
>
>
>
>
> [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.
>
>
>
>
> [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?

> 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
>
> C->S: Ignores server Certificate/CertificateVerify. If handshake reaches
> here, at this stage, server has proven knowledge of Y_c via derived PSK.
>
>
>
> - 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

---

From: Dan Harkins <[email-masked]>
Date: Wed, 10 Mar 2021 07:12:16 -0800

On 3/10/21 4:12 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     *From:*TLS <[email-masked] <mailto:[email-masked]>>
>     *On Behalf Of *Eric Rescorla
>     *To:* Dan Harkins <[email-masked] <mailto:[email-masked]>>
>     *Cc:* <[email-masked] <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>>
>             [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.
>
>
>     [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.
>
>

   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.

>     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
>
>     C->S: Ignores server Certificate/CertificateVerify. If handshake
>     reaches here, at this stage, server has proven knowledge of Y_c
>     via derived PSK.
>
>     - 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
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Mar 2021 07:19:10 -0800

On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins <[email-masked]> wrote:

>   I'm not sure of the distinction you're making here.
>

Well, once again, it seems like the technical requirement is that:

1. You want to authenticate the server to the client (as noted below, I
don't think that the distinction
you are making between "assurance" and "authenticate" is sufficiently crisp
to be helpful).
2. The only secret information that the server shares with the client is
Y_c.

But this doesn't necessarily preclude the client *sending* Y_c, it merely
requires that
it not send it to anyone who hasn't proven they know Y_c first. For
instance, if Y_c
was used as a PSK (as owen suggests), then it might (again, no analysis
here)
allow the client to send Y_c in an RFC 7250 certificate message because it
would
already be being encrypted under a key that required knowing Y_c.

But let me address

>From an analysis perspective, I'm not sure how to model this other than as
it is a secret
with a limited distribution.

-Ekr

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 10 Mar 2021 08:21:52 -0800

<snip>
> supposed to be restricted to those who are legitimate owners of the thing.

What you want I think is a security property akin to an asymmetric
PAKE, although a bit easier to design since everything is high
entropy: the protocol succeeds only if the endpoints each know the
things they are supposed to, even in the face of concurrent sessions
and adversarial corruption of some parties. And we're using these
credentials in an entirely different protocol as well, which needs to
be considered.

Having the public key not be public is unusual. As I stated on the
call lots of signature schemes do reveal the public key.  When you're
working with these unusual needs a lot of care is required.

> the thing will get that the holder of it's public key is legit. Consider that
> to have a higher level of assurance that it's talking to the legitimate owner.

Only if the protocol has the security properties you want.  That's not
clear to me, and the Wifi Alliance should have something to back this
up.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 10 Mar 2021 16:25:57 +0000

1. You want to authenticate the server to the client (as noted below, I don't think that the distinction
you are making between "assurance" and "authenticate" is sufficiently crisp to be helpful).
2. The only secret information that the server shares with the client is Y_c.

But this doesn't necessarily preclude the client *sending* Y_c, it merely requires that
it not send it to anyone who hasn't proven they know Y_c first. For instance, if Y_c
was used as a PSK (as owen suggests), then it might (again, no analysis here)
allow the client to send Y_c in an RFC 7250 certificate message because it would
already be being encrypted under a key that required knowing Y_c.

[ofriel] This makes sense, and should avoid having to use cTLS ‘Known Certificates’ for the client’s Certificate RPK.