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

[Owen Friel (ofriel)]

I have this working on mint - PSK derived from DPP public/private keypair, 
leveraging RFC7250 and RFC8773, was about to fixup draft, but realise that we 
need a flag in the ClientHello to signal to the server that it is a special PSK 
derived from the public part of the public/private keypair.

This could be done via an extension, similar to RFC8773 
tls_cert_with_extern_psk, or Richard pointed me to this: 
https://chris-wood.github.io/draft-tls-extensible-psks/draft-group-tls-extensible-psks.html

Chris, Ekr, I think this could be a good mechanism to define a new type for 
this derived PSK, rather than a new ClientHello extension.

Thoughts?



From: TLS  On Behalf Of Owen Friel (ofriel)
Sent: 11 March 2021 00:26
To: Eric Rescorla ; Dan Harkins 
Cc:  
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01



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

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.

[ofriel] This makes sense, and should avoid having to use cTLS ‘Known 
Certificates’ for the client’s Certificate RPK.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Owen Friel (ofriel)]

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

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.

[ofriel] This makes sense, and should avoid having to use cTLS ‘Known 
Certificates’ for the client’s Certificate RPK.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins  wrote:

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

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

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins  wrote:

>
>
> On 3/10/21 4:12 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) 
> wrote:
>
>> *From:* TLS  *On Behalf Of *Eric Rescorla
>> *Sent:* 09 March 2021 06:27
>> *To:* Dan Harkins 
>> *Cc:*  
>> *Subject:* Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
>>
>>
>>
>> On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins  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.
>

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 an

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

[Dan Harkins]

On 3/10/21 4:12 AM, Eric Rescorla wrote:



On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <mailto:ofr...@cisco.com>> wrote:


*From:*TLS mailto:tls-boun...@ietf.org>>
*On Behalf Of *Eric Rescorla
*Sent:* 09 March 2021 06:27
*To:* Dan Harkins mailto:dhark...@lounge.org>>
*Cc:* mailto: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 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 le

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

[Eric Rescorla]

On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) 
wrote:

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

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

[Owen Friel (ofriel)]

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



On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins 
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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Owen Friel (ofriel)]

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



On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins 
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).
- 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.
[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.

- 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) 
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<mailto: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<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins  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).
> - 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.
>
> [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.


> - 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)  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
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing listTLS@ietf.orghttps://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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins  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).
> - 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.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dan Harkins]

  Hi Christian,

On 3/8/21 11:49 AM, Christian Huitema wrote:


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.


  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

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

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

[Dan Harkins]

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

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

[Dan Harkins]

  Hi Scott,

On 3/8/21 7:09 AM, Scott Fluhrer (sfluhrer) 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)




  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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

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

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

[Eric Rescorla]

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)  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
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Scott Fluhrer (sfluhrer)]

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
https://www.ietf.org/mailman/listinfo/tls