Re: [TLS] Selfie attack

John Mattsson <john.mattsson@ericsson.com> Fri, 11 October 2019 12:48 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09971120088 for <tls@ietfa.amsl.com>; Fri, 11 Oct 2019 05:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNHZt8UJZ7A0 for <tls@ietfa.amsl.com>; Fri, 11 Oct 2019 05:48:40 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30057.outbound.protection.outlook.com [40.107.3.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DB1120019 for <tls@ietf.org>; Fri, 11 Oct 2019 05:48:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FAXBPaZtMn2a1YHfxSuvdbQaopPkz8wEyRDTOpmUOLJa7Rd06OG5C6GXo/19pum8WuoG2irN1WOyIbDuy3rwacHJdqLlBPo0ucYdKeRTsMjdcg7v4uIMK7Gq5hUtBMRgtiyrK+CydySLfZwkixfyGf3K5YKxZOvDuZnZ3zEbxb4ATZVvph/bCl0K3IrIQhsPX+Le1O3xiwIS8CW0mOq0I50UDBaGL4et9WAjbTAopZL50FzIIjFPLy6LWoKs0kKCLyOJwc/LlLgBpIC5ZKhHI+r6rSH9XAb4+nja4DRbrT4vgCa7d6P1um5vCKEA4iiLQt0tqrPolXeXpoOLduUMKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nGk7/oi7aJS6RcnaSzC/Bo+lRqUuV/m1vmIdyD1ib4Q=; b=RPWPdbQjry90S+2BtjxP3OemOpqL5tyckGEHjMIoe21Z41EmaRuHvZHlZ4pXTufOVLU8xWyme1TtPCfaRH1QkJ4RdATLw/bhHSdgzkoxr8sUwrQbSM2rhrpr2uR8LzvZPdjYjdl8fEihZ2V6WwENxtcz0WW3OEa210eW6ih1MjHyMw1fGgRqtChYwBI5lI+DvWTDELTGycriXJZywOIa+8txKch6LVjeQl+llpJcFXtcpC8zQD8u4ACVECOH1ZHq2gDWoGpRqSomys4K8ZdJNQ0aVLfNx0ublHw93/fchUBSgmexVctUJceBhiG8DUk/qh+OQVL777YuE5d1MuGBKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nGk7/oi7aJS6RcnaSzC/Bo+lRqUuV/m1vmIdyD1ib4Q=; b=m09GOXJjWM02YoM9SiqRH4LCZlX7VpM1KtD1TXxIPX9OwBBo5NWoHkQ9ftNhqVugavYBvAcc4xieXOQXmz+YLCFo4jxJkX5pNinFLByMeJ33hNKLsa+z5xrVn0jawW1njFhwx8yKK5oocC7PDCpYO3FD0NJwMQzIr9FRS5o6TvU=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4316.eurprd07.prod.outlook.com (20.176.168.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Fri, 11 Oct 2019 12:48:34 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 12:48:34 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>, Christopher Wood <caw@heapingbits.net>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, "TLS@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Selfie attack
Thread-Index: AQHVfb7LOQnBEvPvDUirCjFHsuP0MadQ9FsAgARv9oCAACYaAA==
Date: Fri, 11 Oct 2019 12:48:34 +0000
Message-ID: <80FA66B9-C275-4BED-93CF-C70CA42E3A1C@ericsson.com>
References: <CY4PR1101MB227834A5DF828F000C6D1144DB890@CY4PR1101MB2278.namprd11.prod.outlook.com> <CACykbs2qp0EDa3pGfFpQY6rgruJD1f-6mZ_B5KF8kBkrXD9caw@mail.gmail.com> <CY4PR1101MB227871FEF520A88CF65BADF6DB890@CY4PR1101MB2278.namprd11.prod.outlook.com> <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <AE2F1D6C-39AD-4C2F-BE03-FA2F189BBF4B@live.warwick.ac.uk> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <FE583332-1915-4B5A-AAAB-AD854CF336B8@live.warwick.ac.uk> <bb410c2a-6836-48a8-ac3d-de395f4c57d8@www.fastmail.com> <a0c560b0-8bca-d843-dac8-57c90c0488de@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> <16d43a2e-7995-5036-5a67-649b360be497@ericsson.com>
In-Reply-To: <16d43a2e-7995-5036-5a67-649b360be497@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f124d0da-cf42-4beb-5d4d-08d74e495437
x-ms-traffictypediagnostic: HE1PR07MB4316:|HE1PR07MB4316:
x-ms-exchange-purlcount: 8
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB4316EF9346EA6821ABF8D38789970@HE1PR07MB4316.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0187F3EA14
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(396003)(346002)(39860400002)(53754006)(199004)(189003)(13464003)(76116006)(64756008)(66446008)(66556008)(5660300002)(91956017)(229853002)(478600001)(66946007)(110136005)(30864003)(14454004)(86362001)(8676002)(256004)(316002)(36756003)(14444005)(7736002)(966005)(58126008)(81166006)(81156014)(6512007)(6116002)(3846002)(102836004)(6306002)(53546011)(6506007)(2501003)(26005)(2906002)(66476007)(25786009)(99286004)(76176011)(6246003)(71190400001)(2616005)(476003)(446003)(33656002)(486006)(44832011)(8936002)(11346002)(186003)(71200400001)(6486002)(66066001)(6436002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4316; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JSIMFdQy2gNq6xll1UEYejNzger6sDdHZvVUrms4ZQoCSOv1rt/hfWJ3FA1jOxDiCC0OPRyPOFebjrh6VSzj3Peo4Df7BLibdvc0tmOVOG2/fUOfWd35MinTcpJWek9laY1xOCeOeuF8S2rpVSXzUOkQU9a1yroeigA62K8a95tvJK9THQ5Duq9YnWGapqaL6ZnBp04H5nMlQx1qfxZioFhKARpkQ0YwYJAV89zsT9G1bNs4c/qJaLx+lVv9yEdg0GANePeS8QiqDAh+gKJRkWPYiMTbM1fY0sPBGU1H5dapX1aEIZ0BYSk99eO3Dwsn9DO5uyHjMkscBuIZB7wMppU/m8Tfzdduszb7sJQHU7VdtZAfd7qQ/8AwStdc0Eu4C4ua3YSKhfU0rw2lNNaNDkIKNXtH9Nu/5jCpoS7+ojFxF+R/0zMtOnv35BHbfMbGzDDUFpcmuo0p4jE81kXoag==
Content-Type: text/plain; charset="utf-8"
Content-ID: <05D848505E165A40B40BB8DF632AC080@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f124d0da-cf42-4beb-5d4d-08d74e495437
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 12:48:34.7688 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OI8FLvEraK+N8MNiY2H96zbP6uql6ADdtXa3uMhGA/ZGZxMRjHs4A8CTsCQs/zUNV7mCNfEcXfgBe/i/76i9X6F0C/RsJWi+QQHoUAEGmtE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4316
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WPlpZMAyB5S2BV2YNwSa-xwo22c>
Subject: Re: [TLS] Selfie attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Oct 2019 12:48:44 -0000

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-bounces@ietf.org>; on behalf of Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>;
Date: Friday, 11 October 2019 at 14:32
To: Christopher Wood <caw@heapingbits.net>;, Mohit Sethi M <mohit.m.sethi@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.mattsson@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-bounces@ietf.org>; on behalf of "Hao, Feng"
    >>>> <Feng.Hao@warwick.ac.uk>;
    >>      Date: Tuesday, 24 September 2019 at 16:09
    >>      To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>;,
    >> "Owen Friel (ofriel)" <ofriel@cisco.com>;, Jonathan Hoyland
    >>>> <jonathan.hoyland@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-bounces@ietf.org on behalf of
    >> mohit.m.sethi=40ericsson.com@dmarc.ietf.org>;
    >> <mailto:tls-bounces@ietf.orgonbehalfofmohit.m.sethi=40ericsson.com@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