Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Brian Sipos <BSipos@rkf-eng.com> Wed, 18 November 2020 22:21 UTC

Return-Path: <BSipos@rkf-eng.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215793A0DEE; Wed, 18 Nov 2020 14:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=rkf-eng.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 EmYZbXbErmhD; Wed, 18 Nov 2020 14:20:59 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2087.outbound.protection.outlook.com [40.107.244.87]) (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 3D74B3A0E11; Wed, 18 Nov 2020 14:20:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=krlmQiH5smBUlYk2rcXSAYvnLebHKR5l+xZcHzYfFVM3LM/N5xyWjYaXRc7nmwWdhVn3O5uxGRls9kfEUNHbQiI7QWqAwosHuXHwvbO3UW8SMbWH5y0CKxODcSdryDZCB5DMjBErZhFyi/zqxnaNfXq8ImX/mSRlPgdkTWieeYl1Q9DghM0atdt3P41os86YW8NJnR0XekdH8EN7L9DW8IkJvoVGOH6Yrz07Ncd8Z4zExE40E/Qx/aOgSZlFelQ5rMzQoip7L4PG9FygPgWM/WS0EO53Xl7jkhsfj/NcOiwTqosH88P1DpKfKJRqCqcTBn/h9+5KVk0AkLwe2Ag03Q==
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=nCJizZu683FVtmNNIXT2alWoiWqy2NOEJ9ioseJTmsE=; b=oX1u9X2/yhU7o0ntBgZmqL6HAfFtfCTtveWcpKqsw/tlFVoFh7MI9gx1oaDubPFdMUV4UfUF6OzJ73FQKZPJO2XqL8qDt4wxXyGYy5XxFl4XOLNH3k36NLFc0c6kZyxSBuQTsiGc2KgldCN/2HNuU/XB2yCe0CfICgj1sXlFotzgF7nHr2Tn9y7Z1i/jK9wwEOoJqTyfbjC8wCLZViwVmTR2PquB2W+Z6sCtuHDw+i/1ELWIeM00VUBJKAgA9xNGyQk15+EHymzIZpu5mY/+y973VsEN1B7+vD8JJp/QEM5hm6tjv229GBT2IP64VUcTrs7nqGwNLR4bLJvxH7oYOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkf-eng.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nCJizZu683FVtmNNIXT2alWoiWqy2NOEJ9ioseJTmsE=; b=mMHSUcHxym/xb8KInhILpjQI00dQvLRqcvx1jsHN09D4IYoO6pMp146rLYF/6SKHg0ps1B6uOYduHTCwXpNpndTuWWSNnGPKIEaBNfL4cgOyNTuTn7Q3P4xjLO+i/gyLy08zi53vqUSshqRhs1IEMBTGg/k7SruLuV0xtWQyheM=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by BL0PR13MB4209.namprd13.prod.outlook.com (2603:10b6:207:1c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.9; Wed, 18 Nov 2020 22:20:54 +0000
Received: from MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::54f4:962e:10e5:a2e1]) by MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::54f4:962e:10e5:a2e1%7]) with mapi id 15.20.3611.011; Wed, 18 Nov 2020 22:20:54 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Thread-Index: AQHV53Zb41S7JLUh9UuyQty5MZTUgag7HDOAgUhAaQCAKPLSGIAg5puAgAAeS/+AAX+3gIABOICw
Date: Wed, 18 Nov 2020 22:20:54 +0000
Message-ID: <DM6PR13MB3562830777F7EB3FE81F2F659FE10@DM6PR13MB3562.namprd13.prod.outlook.com>
References: <158215235500.17580.7759757155303566523.idtracker@ietfa.amsl.com> <50c5dae1bc26ade7d0fcd9388873665868f7284c.camel@rkf-eng.com> <20201001015416.GE89563@kduck.mit.edu> <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com> <20201117013925.GB39170@kduck.mit.edu> <MN2PR13MB356779F92D179B1BE33D1FD59FE20@MN2PR13MB3567.namprd13.prod.outlook.com>, <20201118022113.GZ39170@kduck.mit.edu>
In-Reply-To: <20201118022113.GZ39170@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [96.241.16.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89c02c62-ea2b-4ac5-357b-08d88c103731
x-ms-traffictypediagnostic: BL0PR13MB4209:
x-microsoft-antispam-prvs: <BL0PR13MB4209C6CE9268D9B54EA29EEF9FE10@BL0PR13MB4209.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NVWJCUIUt8JcYyC1SD+4ksWIKcff0LSYUZwYvufWvuQWM7dRJCuJbrOFau/kSHcqZGyKBArFy4sQlXLAGnznQ2yWpSjzFmrm1w5o1+4yyI8RBN9aKEXkMhfykLUduuLr0eEwhk9qubIuACsV26IrLFLGhL5tA51uyNSaCSaEeYeo5HpM6dC2b0OUWLA/EhUt8ibuwQr4Y2yQQBpPo8R8gK9HDWZQSOqsmB5BkT0TIlbZPfcAXpVsekPRrDeosV0ZIuQ4a455qIyTQ9Bq8AiMSYzBPNq0zF3oQRo3C8MOUWBjLxox97Wbgsf/szPigZHemzPQEGzLA5SE1sxNiJDswg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3567.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(396003)(39830400003)(366004)(8676002)(71200400001)(26005)(8936002)(52536014)(53546011)(6506007)(19627405001)(54906003)(316002)(33656002)(186003)(5660300002)(6512007)(9686003)(83380400001)(66574015)(478600001)(4326008)(64756008)(66946007)(6486002)(66556008)(76116006)(66476007)(2906002)(66446008)(86362001)(6916009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 1WDVFdbaUjyuZzhrtmlrWsfUvRHiYG+5bno2ut6bl+TgJBLA5Bfb2RPyppbscxTBGV9uRpWB2OkFhtMKmrbIZz7HANvfKpsjo5pN4KSadRkgAZoAvR9DM7ey9NQB+r9LBryAb5ja9bonXBFQeDdm/x9lEHt2/HIFwi2BcuLpm/gg93A/yRIwzLUZKny/rV2Qyyx/ULgoiPbpbeBiYkIaWQjHGKpGPwV0m0h96dwOBmYXbkzbDJSZjRuFfNTj5w1HvMwiPoINUcVxZPeJLvsR1Hhafx+1iRObCakWwD4OOR7ChpUyZQxrEBTxz7Vt9l/DLWMcSUxz7Gu6wLEmhp9TDHfq5+BvO3YKASKcZX35Hze5YX+hVgGkCLavu/Hng/tSa8D59yXVPcO74r5+PgVj1yygCbuf6lQYmWsGWeZiM12VEaerk+F+w3Bm6TFtj4KjC2d9yQ0MuL787D19deaidX7kJWqObPVcNAoZlBjFINehWn6T91CBoG0Qw5aGONCrKKv501JLXdPKefP7153jHnweEWzUA69FJZsO6c4jQng/THCLEpYPVGC4Jhr00iYtmN6Wr6OFcGlr7BeaXOUsOhIAxi736znkS2vVenqQe6XWDmaFTUGouBtVoIstLdr4OGo7221rkBNQVtxoginBBpOqzmuQfe/uQbx4NcaRUeW24HX7MkvF3sdGjRYjMNXfOD0jfc/wrOY+aLMy/kv3olPPEdS2CAs7pKo/hoXWa+Lg423MzwJK36a+NNv8WLQdwo+slBWdAVyIiG2wRktFMTXnRtzp3UglR/hUXo2rwZFDwsB4zycQ5gFEr5SW3APNe9hlVj9TlVefej27WuLgw1h6OGyDXnpAW7bdmRssCvSgud3VhNxyQzw/nhlyNNH96H33tvboKQChx1VBzxNa1A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR13MB3562830777F7EB3FE81F2F659FE10DM6PR13MB3562namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3567.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89c02c62-ea2b-4ac5-357b-08d88c103731
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 22:20:54.4733 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UXy8VTv7R5Vuv9gEqNyTfDCPkIkbQle7ibiPq94oHf+cKR8iSfLAK3IsxdR8ZkSxXRCK1MKlDEdMbde26L8qbw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR13MB4209
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/HQLk1zpi4VpCMjXxpb-OQp2VFHQ>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 22:21:09 -0000

Ben,
I see your concerns and I'm looking along a couple of different axes: what other specifications using TLS say to do (relative to RFC6125) and how some implementations behave relative to multiple identifiers and identifier types in PKIX certs.

My current thinking is that there really are two separate "Verifying Service Identity" (Section 6 of RFC6125) searches:

  1.  Search based on both DNS-ID (if a name was used/relevant) and IPADDR-ID reference identifier. This verification succeeds if either identifier matches the cert.
  2.  Search based on NODE-ID reference identifier.

Unfortunately, there is a catch-22 about ordering because #1 is the typical peer authentication which is "built in" in many cases to existing tools (though TLS client address verification seems to be sporadic) while #2 is the new behavior based on post-handshake exchanged data, but the recommended policy is to do #2 unconditionally and only do #1 as a fallback. This means that #1 cannot occur until after the completion of #2 and evaluation by security policy.

So massaging this recommended policy becomes that either one of the following must succeed (no order):

  *   Verification #1 along with requiring an EKU for DTN security, or
  *   Verification #2

This avoids an order or time dependence but does prohibit an implementation from failing early if #1 does not succeed. There's already a security threat for Node Impersonation and a user of the recommended policy just needs to be aware of this threat.

Does any of this sound reasonable?
________________________________
From: Benjamin Kaduk <kaduk@mit.edu>
Sent: Tuesday, November 17, 2020 21:21
To: Brian Sipos <BSipos@rkf-eng.com>
Cc: draft-ietf-dtn-tcpclv4@ietf.org <draft-ietf-dtn-tcpclv4@ietf.org>rg>; dtn@ietf.org <dtn@ietf.org>rg>; edward.birrane@jhuapl.edu <edward.birrane@jhuapl.edu>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

On Tue, Nov 17, 2020 at 04:56:11AM +0000, Brian Sipos wrote:
> Ben,
> I really appreciate the critical eye for security implications and know that small oversights can lead to big problems.
> Part of the reason for this somewhat slow drag toward a solid set of TLS requirements is the starting point of web-PKI-focused tools and TCPCLv3 statement that "Nothing in TCPCL prevents the use of the TLS protocol to secure a connection" leaves gaps to fill.

Understood.

> Related to your earlier reply, I think that allocating a EKU OID for DTN will help to turn some of these assumptions about CA behavior into actual encoded claims of purpose. Do you think that these two can be treated as equivalent for the goal of recommended security policy?

It will help to some extent, though in practice it might not help very much
-- existing Web PKI CAs are pretty unlikely to start signing new EKUs
without a fair bit of work.  (Mostly on non-technical aspects of things, as I
understand it, though I am sure I will learn a lot at tomorrow's SAAG
presentation on what is needed to set up a PKI.)

>   1.  A certificate with an exact NODE-ID (and EKU either absent or including DTN). This leaves no doubt about the claim.
>   2.  A certificate with a DNS-ID or IPADDR-ID and with a EKU including DTN. Indicates that the CA is aware that the host is intended as a DTN node.

The two are of course not exactly equivalent, but for the purposes of a
default security policy it will probably be fine to accept either of them.
(We will want to be clear in the definition of the EKU that the semantics
include the holder of the certificate being trusted to provide a Node ID if
one is not in the certificate, though.)

> Should #2 be explicitly related to the use of opportunistic security? Only if an entity has enabled opp. sec. does the DNS-ID or IPADDR-ID matter. Otherwise, only the NODE-ID matters.
> Do other protocols make a hard separation between "enabled or disabled" in relation to opportunistic security?

In my mind #2 is a variation on non-opportunistic (or "full") security,
rather than a form of opportunistic security, though in some sense there is
a hierarchy or continuum and this is just one point on that ladder.
Usually I see "opportunistic security" used to refer to just not attempting
to authenticate the peer at all, ignoring failure to validate the expected
hostname against the presented certificate, etc., but the #2 is still doing
some partial validation, just at a different level of naming than #1.  So
I'm not entirely sure that I understand the question about a hard
separation for enabled/disabled.

> For background on how this would be used in DTN: Because DTN is an overlay network, bundle routing always requires a node to have logic related to "when a bundle needs to go to endpoint X, it's next hop should be node Y over convergence layer Z" where "Y" is the next-hop Node ID and "Z" is the transport which (for internet transports) includes either a DNS name or IP address (i.e. some way to contact the node). The idea is that a peer already has an idea of "what node am I looking to send this to" and uses that DNS name or IP address to contact that node.
> I think that this means that the in-band Node ID is superfluous for this use, and is more useful as a diagnostic "oops, I was trying to contact Z but you claim to be W" warning mode. This is how some existing DTN stacks behave.
> The benefit to having a certificate claim on a Node ID directly is that there is added agility to use multiple DNS names or IP addresses over time as network topology or access change (as a DTN is wont to do).

Thank you for this background; it is very reassuring to hear.  (It matches
my intuition on how things should work, but I don't have much confidence
that my intuition will always be correct, since this area is pretty far
from my normal areas of expertise.)  I heartily agree about the benefits of
having a Node ID directly in the certificate.

> One last topic of the authentication logic: I did originally look at requiring it that way, but the current text has a behavior which that type of logic does not; if a certificate does contain an IPADDR-ID then the current text requires it to match the connection. The different claim types are ANDed together. If a cert has a NODE-ID and an IPADDR-ID they both must authenticate the peer, regardless of policy. Policy may only allow the absence of a claim type it may not allow a failed claim type.

I think this is actually a bad property to have, leading the system to
become unnecessarily "fragile".  In particular, the semantics of a
certificate are "the holder of the private key corresponding to this
certificate can act as the various entities named in the Subject fields",
but not "this is an exhaustive list of the names for the holder of the
private key corresponding to the certificate".  So, we might end up in a
scenario where the same entity can be named by any/all of Node-IDs A and B,
and IP addresses X and Y.  But if those identities are bundled to gether
into one certificate with A and X, and a second certificate with B and Y,
then no single certificate could satisfy a peer that is trying to talk to
node A on address Y -- with the current validation policy in the -23 the
peer would have to fail the connection no matter what certificate is
presented.

To put it more pithily: just because I have one IP address in my
certificate does not mean that all of my IP addresses are in my
certificate.

Does that help clarify my thinking?

Thanks again,

Ben