I think things mitigating the Selfie attack should be done in an errata to RFC
8446 or in a draft updating RFC 8446. If draft-ietf-tls-external-psk-importer
is the mitigation against selfie attacks I think it needs to update RFC 8446.
John
-----Original Message-----
From: TLS <tls-boun...@ietf.org> on behalf of Mohit Sethi M
<mohit.m.sethi=40ericsson....@dmarc.ietf.org>
Date: Friday, 11 October 2019 at 14:32
To: Christopher Wood <c...@heapingbits.net>, Mohit Sethi M
<mohit.m.se...@ericsson.com>, "TLS@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Selfie attack
Hi,
I created a pull request for the draft to improve the section on
addressing selfie attacks. For the benefit of the list, here is the
proposed text:
> The TLS external PSK authentication makes the implicit assumption that
> each PSK is known only to one client and one server, which do not
> switch roles with the same PSK.
>
> If multiple clients or multiple servers share a PSK, TLS only
> authenticates the entire group. Not only can a compromised group
> member impersonate another group member, but a malicious non-member
> can reroute handshakes between honest group members to connect them in
> unintended ways. This rerouting is a type of identity misbinding
> attack [Krawczyk][Sethi].
>
> 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;
>
> When the PSK is shared by only two endpoints, it is not necessary to
> know the identifier(s) of the other endpoint. Instead, it is
> sufficient to check that the identifier of the other endpoint in
> context is not equal to any of one’s own identifiers. To simplify
> implementation of this check, it is RECOMMENDED that each endpoint
> selects one globally unique identifier and uses it in all PSK
> handshakes. The unique identifier can, for example, be one of its MAC
> addresses or a 32-byte random number.
>
> When the PSK is a group key, the comparison with one’s own identifiers
> will only prevent selfie attacks but not malicious rerouting of the
> connection to another group member. 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.
--Mohit
On 10/8/19 7:46 PM, Christopher Wood wrote:
> On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>>
>> Hi Chris,
>>
>> For the benefit of the list, let me summarize that the selfie attack is
>> only relevant where multiple parties share the same PSK and use the
>> same PSK for outgoing and incoming connections. These situations are
>> rather rare, but I accept that TLS is widely used (and sometimes
>> misused) in many places.
>>
>> The Selfie attack only happens when an entity with the PSK acts
>> maliciously. So I think the fact that you write in the draft: "each
>> node must be trusted not to impersonate another node's role" does not
>> take into account that there must be a malicious node for the selfie
>> attack to happen in the first place.
>>
>> Drucker and Gueron's paper recommends that "every participating party
>> gets (during the setup of the network) a unique identity" and "the
>> client and the server must verify the validity of the claimed
>> identities.". The reality however is that in most group PSK scenarios,
>> the nodes don't have any strong identities that can be verified.
>>
>> What you should instead (or additionally) say in the text is that a
>> node should check that the client_mac and server_mac (or any other
>> identities used) *are never the same*.
> This seems implicit in the text as written. Could I ask you to submit a
PR against [1] to clarify?
>
> Thanks,
> Chris
>
> [1]
https://protect2.fireeye.com/url?k=bb68fbe7-e7e2d928-bb68bb7c-0cc47ad93ea4-ddab33427b4471c9&q=1&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external-psk-importer
>
>> Without this check, the selfie
>> attack would still be possible. And at least this does not require
>> strong identity verification for preventing selfie attacks.
>>
>> --Mohit
>>
>> On 10/5/19 2:41 PM, Christopher Wood wrote:
>>> Hi Feng,
>> For what it's worth, the latest version of the PSK importers draft
>> includes a "context" field into which identity information can be fed:
>>
>>
>>
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#appendix-B
>>
>> Best,
>> Chris
>>
>> On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote:
>>>> Hi John,
>> Reflection attacks are indeed older, but the selfie attack is a bit
>> different. It's actually a variant of the unknown key share attack. A
>> typical example of the UKS attack is the one reported on MQV by Kaliski
>> in 2001 (see "An unknown key-share attack on the MQV key agreement
>> protocol" in ACM TISSEC 2001). In that example, the adversary plays
>> message between two users to cause confusion in the identity, but in
>> Selfie, the adversary plays message with only one user and uses another
>> instance of the user to cause confusion in the identity. When we
>> reported this variant of UKS in [3], we were not aware of anything like
>> that in the literature.
>>
>> Cheers,
>> Feng
>>
>> On 24/09/2019, 16:17, "John Mattsson" <john.matts...@ericsson.com> wrote:
>>
>> Hi,
>>
>> I think these reflection attacks are much older than this. I quick
>> search for reflection attack security protocol gives a lot of old
>> results, The description of reflection attack in the following lecture
>> material from 2009 looks just like the "selfie attack" on TLS 1.3
>> http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf
>>
>> With multiple sections there are other things that change as well.
>> If two nodes unintentionally initiate simultaneous ClientHello to each
>> other, even if they only want a single secure connection (I have seen
>> live systems where this happens in practice), an attacker can select
>> which ClientHello to block (e.g. the one with the strongest
>> cryptographic parameters). The following security property would then
>> no longer hold :
>>
>> "Downgrade protection: The cryptographic parameters should be the
>> same on both sides and should be the same as if the peers had
been
>> communicating in the absence of an attack"
>>
>> (I have not looked at what the definitions in [BBFGKZ16] say).
>>
>> Cheers,
>> John
>>
>> -----Original Message-----
>> From: TLS <tls-boun...@ietf.org> on behalf of "Hao, Feng"
>>>> <feng....@warwick.ac.uk>
>> Date: Tuesday, 24 September 2019 at 16:09
>> To: Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org>,
>> "Owen Friel (ofriel)" <ofr...@cisco.com>, Jonathan Hoyland
>>>> <jonathan.hoyl...@gmail.com>
>> Cc: "TLS@ietf.org" <tls@ietf.org>
>> Subject: Re: [TLS] Selfie attack was Re: Distinguishing between
>> external/resumption PSKs
>>
>>
>> On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"
>>>> <tls-boun...@ietf.org on behalf of
>> mohit.m.sethi=40ericsson....@dmarc.ietf.org>
>>
<mailto:tls-bounces@ietf.orgonbehalfofmohit.m.sethi=40ericsson....@dmarc.ietf.org>
wrote:
>>
>> Hi all,
>>
>> On the topic of external PSKs in TLS 1.3, I found a
>> publication on the
>> Selfie attack:
>>>>
https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21b-dc6c6f0a5dd21faf&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347
>>
>> Perhaps this was already discussed on the list. I thought
>> that sharing
>> it again wouldn't hurt while we discuss how servers
>> distinguish between
>> external and resumption PSKs.
>>
>> I just read the paper with interest. It occurs to me that the
>> selfie attack is consistent with the "impersonation attack" that we
>> reported on SPEKE in 2014; see Sec 4.1 [1] and the updated version with
>> details on how SPEKE is revised in ISO/IEC 11770-4 [2]. The same attack
>> can be traced back to 2010 in [3] where a "worm-hole attack" (Fig. 5,
>> [3]) is reported on the self-communication mode of HMQV. The essence of
>> these attacks is the same: Bob tricks Alice into thinking that she is
>> talking to authenticated Bob, but she is actually talking to herself.
>> In [3], we explained that the attack was missed from the "security
>> proofs" as the proofs didn't consider multiple sessions.
>>
>> The countermeasure we proposed in [1-3] was to ensure the user
>> identity is unique in key exchange processes: in case of multiple
>> sessions that may cause confusion in the user identity, an extension
>> should be added to the user identity to distinguish the instances. The
>> underlying intuition is that one should know "unambiguously" whom they
>> are communicating with, and perform authentication based on that. The
>> discovery of this type of attacks and the proposed solution are
>> inspired by the "explicitness principle" (Ross Anderson and Roger
>> Needham, Crypto'95), which states the importance of being explicit on
>> user identities and other attributes in a public key protocol; also see
>> [3]. I hope it might be useful to people who work on TLS PSK.
>>
>> [1]
>>>>
https://protect2.fireeye.com/url?k=5a822513-0608efad-5a826588-869a17b5b21b-eb260151f78b0718&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2014%2F585.pdf
>> [2] https://arxiv.org/abs/1802.04900
>> [3]
>>>>
https://protect2.fireeye.com/url?k=d5bf88ff-89354241-d5bfc864-869a17b5b21b-0e9b3bf58e104f32&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F136.pdf
>>
>>
>> _______________________________________________
>> 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 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 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
