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

Miika Komu <miika.komu@ericsson.com> Thu, 20 February 2020 15:38 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 131F91208EF; Thu, 20 Feb 2020 07:38:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 RRs-9rkM2u-4; Thu, 20 Feb 2020 07:38:27 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (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 AB1BF1208E6; Thu, 20 Feb 2020 07:38:26 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EGQsVapCdNL7fSrDhP76kUzETaoPjyrXIN+LHwkIjWZEVWrrlzHxkuJIDPXN/8pyqWUct+W/uFT9U1MT7HbCilWonyUE0taCc4o1tZGkkwwCZGxKojrCUle4l/gkvr89L3FzD11S2uvAcEWTtNyAPXxOcwfntSj8/GdwhM81m9u3ZYXF8VszLS9daplLQMSQyJKqbEipvU3I4OMiux14XJatrEtd6rZzmdpoHDyKfKrQr35Fqf7mdqP2efMB3HTzpA7PzCnhmimxFW65BjILCQDdPmXlF+YgeJTyFSZP2rq+3UDWT4fZqwn864EOxDn5Veh/uLybmdNgdTAqJelFqA==
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=wfTTmY6ethTHKR6OLUdIOP+HMMSTkv9mFjrez4eodTw=; b=RWVvU8VOr6pzDLwkJHHUssxjWFq5GBgscOB/PrXzHphcFLs2N355cH56F4+eKQeZ5w03+nrzw5ZBUoxIxKzBhWuBwN35snALYY+lz5IO3ysNH9X/oBoKilZL+Bz+koX6L15Eg+k+jlkYYh1sTZhO08ULf1cL/pakIVCA144bjDu4IddCi8JqM8jrThuUbS6lL+8huhiCQAqsKmhZ9jHC9INwRidmBPpHP3dp5YTcw+wZ7eN+Tua8dmbVoEGZWUdz+UJzxOy3xO8kORVIhC4SYdoatwYtCDLLIlAQImykhOJzrlsnaGPBcGcMZAnnlO49Nc0A8bADfG2w+DMzwCDdbg==
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=wfTTmY6ethTHKR6OLUdIOP+HMMSTkv9mFjrez4eodTw=; b=FKSBGfKHwVw9r3FWHGpv+3Ew+8Ocw9IsPOtco+M8O+F+nVyCh1QetAvAlwqUwULFUhrBOry1Kuhnm9qJucwqf8tD8CtT+mebYbFqrniZQfhve2WB7WKd5fukcDisX8fO0FlKW2VdmOFrJzRrExaUW4ZSgKx972OnMDbzf2Kmbdc=
Received: from AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) by AM0PR07MB4499.eurprd07.prod.outlook.com (52.135.150.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Thu, 20 Feb 2020 15:38:24 +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; Thu, 20 Feb 2020 15:38:24 +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/FUAgE08J4CCk9E3AIAAA4SAgACfMACAAHlIgIAAGiSA
Date: Thu, 20 Feb 2020 15:38:24 +0000
Message-ID: <82ded3745fe403d24c3866845f5f202f182f9d1e.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>
In-Reply-To: <CABcZeBNVBEATYW6-OKK8C0dJ=NzvhRp2N2xmStgNWqTYqQ7-xQ@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: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3bc59f88-ddbd-46b8-5d33-08d7b61aec05
x-ms-traffictypediagnostic: AM0PR07MB4499:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB4499F7A8BA0DC417F130B9DAFC130@AM0PR07MB4499.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(189003)(199004)(81166006)(316002)(4326008)(8676002)(5660300002)(8936002)(6486002)(66446008)(71200400001)(76116006)(54906003)(81156014)(2906002)(66946007)(44832011)(66476007)(64756008)(2616005)(66556008)(86362001)(186003)(36756003)(53546011)(6506007)(6512007)(478600001)(6916009)(26005)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4499; 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: 7RjjBNy8YqqNAXEWPmN1XIKkqVfqTs01yJ4LlM4XfZSXsKW3Yvk8Tj46ErOrtrjO6zbVrMldCrOtawbfPBHbq8nRP7fBp60FjA9WYDdvOE2UwSshLVNNSFZ8Ne0N8wwwM5onl+DEfqoVqJyMn8YfFhAVOh3TAD1UaF8mc78HxkpFo/uoDUIchurnr3Fuv1yayO0puGixF2NR6LUqFy2dNyMGNKH1/dtwYEr8c87UIR5dbQ/MKIsRctoRlX6BMZZj9AFNBH0ijawPTEcG+PH4Ed3e46RlTeTbR7rCxj+XjXelw/SHhWjWCbRwVZApKgqjpTgpGJdJxgV6lW52Wbkdn7fwxXRYek4AdzI5Fmuxuf4hUptJA1Q0VpvllThxE4aILD3gLoNQnQY1cssbyLyybS24GquwvfJTmCHfAS/0g9M1nd776oOHubCRqrk4P9zL2YW23A6YcGChluLUzKQOZMMISbCGyME9ag2wLZ3XSczjGJpkUpT80xTC7C8wh8O2
x-ms-exchange-antispam-messagedata: QpShG/SNbMsuMmyPiEyUWaXKMuuBQlkN4j2VDQZAIuyhZ6PQ0RHjATuTYyVaXyfBsEv+oBiQNlel7nzPe9xjvb3BKnoEuZgx/6KvIbSTrY6vi+qVq7K+Q9zLYE2xBSRM9WznxsMLgJduKdcOsMUhrQ==
Content-Type: text/plain; charset="utf-8"
Content-ID: <D63CDA2BC326DF449983A52E6289944A@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3bc59f88-ddbd-46b8-5d33-08d7b61aec05
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 15:38:24.0794 (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: kHvAmhjRvE2D50eKLAhN2pdKsySS0s4Cs5tpY6MkrUA+ZdS1+gdv0G/Mh33DhS+JuBF3wcoEjamVjBpT93jMnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4499
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/UwPSWXA9RA6gh11sUrFbu-1sUPQ>
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: Thu, 20 Feb 2020 15:38:29 -0000

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?