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