Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

Miika Komu <miika.komu@ericsson.com> Fri, 21 February 2020 14:37 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FFD120829; Fri, 21 Feb 2020 06:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 adjTrlapzsOM; Fri, 21 Feb 2020 06:37:00 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20629.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07126120800; Fri, 21 Feb 2020 06:36:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W7MrX4IulOi8cZCrkYpYW6pQPWPb/qFLhEdLzXMTCEP9ITowQLVu+Xmw5BhkUSmfTwUemyTugjM8/DlvTCnmv924+RQPTTwJhSJKgsz8NIPsrgobosQdvL/wl6xllObxBc/qNyYlBEXk+qyEcSQEC9wtolzVhR0YVE2b15jyvnkDPXmvlJiq1JU+EeasLMImkT+OMlIl6B8+rCiSTyfjtk4O1PlYAX9V112iI0LvfrdeRxHvDPyXy6seZFIKLE4vI3nxvLsvBJmO7bTWyk1PMrzfU2C/UVcLuIfkeCvP5u13VHKJ+UYTFYGgOoL7LYz4m5zXwGDuPO1pJtrarax78g==
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=dNLyR1OOPtg04SmVMQtM9aPigFt4TuTWfW48ef/4kcE=; b=BKBVLliP+T7n6TcsFeJlAyTKipX37LIrUHuEEXGBkimY+sIEYM0z/XhPdiPkcEdbL1r/PcmHgc0HIGKDtQKBls0PuKLNcFdywva+aQBeOMX0VbRWxnO4cjKY7FYY3si6d55D5JucOMLavrKsM6usIDHMp2dg7nmLcW+khykuOIfQafkgpLU+A2AKsiPQ1QuUk02c6PD88vVcZ5DQC3zaKTKPi/x8ch/we7UvqFIw238YRja8ISm33mTEfpFKn++eIHbaWkpXhhFAVkaYwXHD/NNUpXFHV0Wl5TUC/ur3Q2HsezBjUm8hNg3nNgGrgT84iwnTk0hxEsPhh1vAtD5V8g==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNLyR1OOPtg04SmVMQtM9aPigFt4TuTWfW48ef/4kcE=; b=HOZWjdFaGMGrm5m/L5d3BuId26wqSoeYB/JrZx2fawf3WxT3BctAeFLSAN8yNAYnT12PX27AL9/Mp2+CyAaT1gqBEUXNVGyMVojT+0mpwgWgjK29oHDiMl908eksdLryrKh29WVkgKOCGVZ1rl7d1PzHIhcxwHy9W0oRmgnllbg=
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB6404.eurprd07.prod.outlook.com (10.186.174.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.14; Fri, 21 Feb 2020 14:36:58 +0000
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::790c:4b51:77d2:7767]) by AM0PR07MB3876.eurprd07.prod.outlook.com ([fe80::790c:4b51:77d2:7767%5]) with mapi id 15.20.2750.016; Fri, 21 Feb 2020 14:36:57 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "ekr@rtfm.com" <ekr@rtfm.com>
CC: "draft-ietf-hip-native-nat-traversal@ietf.org" <draft-ietf-hip-native-nat-traversal@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Thread-Index: AQHT497tUmBXmn8MOU+Q++wdbIVom6VF/FUAgE08J4CCk9E3AIAAA4SAgACfMACAAHlIgIAAGiSAgAAWWQCAAUYlgIAAE0+AgAARXQA=
Date: Fri, 21 Feb 2020 14:36:57 +0000
Message-ID: <163d9a999e5eac1130377dd104f602cfea789506.camel@ericsson.com>
References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <a657ffe0-3574-850e-3b8d-9b21f6f8825b@ericsson.com> <CABcZeBO3gLUZevW0zTN6RHiuYBY+7d-4DefSNBA3FzhXFWfGQw@mail.gmail.com> <47c0cdb7980fa6b9d85d71de926d24ea50a90930.camel@ericsson.com> <CABcZeBOVzKyd1Q6uYi66AFEazhW5OSOwYMBnUqGvjHRk4+0DtA@mail.gmail.com> <20b7460348acc2f3d958ab8ed66a70b49448289a.camel@ericsson.com> <CABcZeBNVBEATYW6-OKK8C0dJ=NzvhRp2N2xmStgNWqTYqQ7-xQ@mail.gmail.com> <82ded3745fe403d24c3866845f5f202f182f9d1e.camel@ericsson.com> <CABcZeBM2Tm5EuF=htBBD0qyYpKarvvgE_LbTKU8n9oBQVPZdsA@mail.gmail.com> <5df6df66bf1d1fdd28d94dfdbf85b17e0f9f4cb2.camel@ericsson.com> <CABcZeBO2LDoB39-7EZo9kk-RGL96Bi4gJ1nwpXxGxwFEsyeuKQ@mail.gmail.com>
In-Reply-To: <CABcZeBO2LDoB39-7EZo9kk-RGL96Bi4gJ1nwpXxGxwFEsyeuKQ@mail.gmail.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-originating-ip: [88.148.205.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4b8599bc-0e14-4677-85b9-08d7b6db8116
x-ms-traffictypediagnostic: AM0PR07MB6404:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB6404EC08A8742A17C97FEBBCFC120@AM0PR07MB6404.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0320B28BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(189003)(199004)(6512007)(91956017)(66476007)(76116006)(66556008)(6486002)(54906003)(4326008)(66946007)(66446008)(64756008)(316002)(2616005)(86362001)(6916009)(44832011)(5660300002)(2906002)(81166006)(81156014)(26005)(71200400001)(6506007)(53546011)(478600001)(36756003)(186003)(8936002)(8676002)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6404; H:AM0PR07MB3876.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: FW64e5AqzpJ9BgvKHxiiJAtCoDvIlA7rW7sVHXwIMkDjoxj4EYAsLxdN5fe1vYXEKowJixKoe0sJ/QcRc3AZ/hfUZc2nhiDsXTK53p7IpAKrukSVLahW2WnTIMdnG81maOZpxo8YwuPjdoMWZFVtpNJBX+YBu1Ok9RIOiroXyGAid/h2+XCdHPDAtdlv2dSWiy1cuzP1y27bVryVf8/Fsy+jV9vyklyNR91M7nQZRlPXYYrYS/cETI6kMe3auxCxjyhjZ/K/HeuP8CWsxDmCERIEA9AxMhD1OtUGh7lLP4uho3gT4SE6B54wj1WJvwD2mDA+14bn29Fngp7DzkqMvZMLtDCWKzUW9xW2AoTq7iwwVrHzBOk71P6m+Q5vUMquh4xSPK9O11h05Qy5YwfmOlbxNtEUMga3OeeieF3tHW1DfrNg5ZeDimER/s5hWEPBhAJGyYjclZw4rMtSJh0Y53GzxbOX75SMHsvFQWaDC9f3yoxxlEHsa//nix6J20zQ
x-ms-exchange-antispam-messagedata: AMPanWYsEhTNw8J1dWK1o8OWAqHcxXwR+adF7pyCbrU9je0buMZFR2oa9S3bdDRhzKfXPgAWTJg4rL4bU0p75W6SkIc9fkYNAqvdVUmWSWFBXEsa5qouliq/JEShPLnRIDMvUU/BCBzZLjfvQhE/6Q==
Content-Type: text/plain; charset="utf-8"
Content-ID: <5D143A3171B5734D887075589BB00E66@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b8599bc-0e14-4677-85b9-08d7b6db8116
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 14:36:57.5584 (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: dugcwU/PVVuZ76nQtgfVwLapHCAh+yMteqLe2aJy1nGlkewYn/8CXH81MzqDiKTLHz+slXIpR9ApHpeDuJ5z6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6404
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/TFvgf1wJbgdJLTZDmVUT9uQloyo>
Subject: Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 14:37:03 -0000

Hi Eric,

so your original question was:

"The concern is what's known as a "cross-protocol" attack. Is there
any situation in which there might be ambiguity about two message
types that are protected with the same key?"

No ambiguity about the message types, because the messages between
relay client and relay server carry always either a RELAY_FROM or
RELAY_TO parameter (depending on direction) and this is covered by the
HMAC.

In the rendezvous case, you have different FROM and VIA_RVS parameters,
also covered by HMACs.

pe, 2020-02-21 kello 05:34 -0800, Eric Rescorla kirjoitti:
> Typically in security protocols we look for demonstrations of this.
> What is your argument for why it cannot?
> 
> -Ekr
> 
> 
> On Fri, Feb 21, 2020 at 4:25 AM Miika Komu <miika.komu@ericsson.com>
> wrote:
> > Hi,
> > 
> > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> > > 
> > > 
> > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <
> > miika.komu@ericsson.com>
> > > wrote:
> > > > Hi Eric,
> > > > 
> > > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > > > 
> > > > > 
> > > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > > miika.komu@ericsson.com>
> > > > > wrote:
> > > > > > Hi Eric,
> > > > > > 
> > > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > > S 5.8.
> > > > > > > > > > >>    
> > > > > > > > > > >>    5.8.  RELAY_HMAC Parameter
> > > > > > > > > > >>    
> > > > > > > > > > >>       As specified in Legacy ICE-HIP [RFC5770],
> > the
> > > > > > > > RELAY_HMAC
> > > > > > > > > > parameter
> > > > > > > > > > >>       value has the TLV type 65520.  It has the
> > same
> > > > > > > > semantics
> > > > > > > > > > as RVS_HMAC
> > > > > > > > > > >>       [RFC8004].
> > > > > > > > > > > 
> > > > > > > > > > > What key is used for the HMAC?
> > > > > > > > > > 
> > > > > > > > > > clarified this as follows:
> > > > > > > > > > 
> > > > > > > > > > [..] It has the same semantics as RVS_HMAC as
> > specified
> > > > in
> > > > > > > > section
> > > > > > > > > > 4.2.1 
> > > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > > RELAY_HMAC
> > > > > > is
> > > > > > > > is
> > > > > > > > > > keyed 
> > > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > > specified
> > > > > > in
> > > > > > > > > > section 6.5 
> > > > > > > > > > in [RFC7401]), established during the relay
> > > > registration
> > > > > > > > procedure
> > > > > > > > > > as 
> > > > > > > > > > described in Section 4.1.
> > > > > > > > > 
> > > > > > > > > This seems like it might have potential for cross-
> > > > protocol
> > > > > > > > attacks on
> > > > > > > > > the key. Why
> > > > > > > > > is this OK>
> > > > > > > > 
> > > > > > > > this is standard way of deriving keys in HIP. The
> > keying
> > > > > > procedure
> > > > > > > > is
> > > > > > > > the same as with specified in RFC8004. If there is some
> > > > attack
> > > > > > > > scenario, please describe it in detail?
> > > > > > > > Or is there some editorial issue here?
> > > > > > > 
> > > > > > > I'm not sure. When I read this text it appears to say
> > that
> > > > you
> > > > > > should
> > > > > > > be using the same key for two kinds of messages. Is that
> > > > correct?
> > > > > > 
> > > > > > the key is always specific to a Host Association, i.e.,
> > unique
> > > > > > between
> > > > > > a Relay Client and a Relay Server. So if there is a
> > Rendezvous
> > > > > > server
> > > > > > (used with RVS_HMAC), this would be a different host and
> > > > different
> > > > > > Host
> > > > > > Association. If the same host provides both rendezvous and
> > > > relay
> > > > > > service, it should be fine to reuse the same key.
> > > > > 
> > > > > Why is that OK? Generally we try not to do this. Do you have
> > a
> > > > proof
> > > > > that it is not possible to have one message mistaken for
> > another?
> > > > 
> > > > so I assume we are talking about the (artificial) case where a
> > > > single
> > > > host provides both Relay and Rendezvous service, and is
> > > > communicating
> > > > with a single registered Client? It's the same control channel,
> > so
> > > > I
> > > > don't see any need to have different HMAC keys for different
> > > > messages
> > > > since it's still the same two hosts. Or maybe I misunderstood
> > your
> > > > scenario, so please elaborate?
> > > 
> > > The concern is what's known as a "cross-protocol" attack. Is
> > there
> > > any situation in which there might be ambiguity about two message
> > > types that are protected with the same key?
> > 
> > I don't see any case where this could occur.