Re: [TLS] Imported Keys/PR #22

[Mohit Sethi M <[e-mail]>]

I believe that my pull request was indeed covering the different cases you talk about. See in-line pieces of text from my pull request:

On 11/21/19 10:48 AM, Eric Rescorla wrote:
To recap what I was saying at the microphone earlier today about
selfie/reroute issues, there are actually three separate issues.

- A reflection attack where an outside attacker makes the client also
  act as a server.

- A reroute attack where an outside attacker makes the client talk to
  another server with the same PSK as the intended server.

- An attack where an inside attacker impersonates another attacker
  who also has the PSK.

The reflection attack is a special case of the reroute attack.  The
general solution to the reroute attack is to carry the identities of
the communicating endpoints in the handshake [0]; AFAIK it's not
necessary to have separate keys, though the current text actually
generates distinct keys for each pair as well.  It's not a problem to
have distinct keys, but it's important to know what piece does what.

Selfie attack {{Selfie}} is a special case of the rerouting attack against a group member that can act both as TLS server and client. In the selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint.

Rerouting and selfie attacks can be detected by binding the TLS handshake to globally unique node identifiers using the following context string:
struct {
       opaque client_id<0..2^16-1>;
       opaque server_id<0..2^16-1>;
  } Context;


However, that doesn't generally solve the third class of attack if the
inside attacker is configured with the input key rather than the
fanned out pairwise keys.


When the PSK is a group key: To prevent malicious rerouting in groups, each endpoint needs to know the identifier of the other endpoint with which they want to connect and compare it with the other endpoint’s identifier in context. Of course, this only prevents attacks by non-members; the endpoints that share the group key can always impersonate each other.

The last part was explicitly referring to the case that you can't do much about insider attacks in group PSK scenarios.

-Ekr

[0] As John Mattson has pointed out, you can fix just the reflection
attack by comparing the random values you have outstanding in each
direction.


I find the current text in draft-ietf-tls-external-psk-importer inadequate (although I understand that I am in the rough). For example, it doesn't explicitly say that client_mac should never be the same as the server_mac. If the WG wants to address this in a separate document, then so be it. I am happy to help.

--Mohit






_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls