Re: [dtn] PKIX Extended Key Purpose recommendations

Brian Sipos <BSipos@rkf-eng.com> Mon, 23 November 2020 22:28 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 65D583A13E6 for <dtn@ietfa.amsl.com>; Mon, 23 Nov 2020 14:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[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 33AZsxsvx5_a for <dtn@ietfa.amsl.com>; Mon, 23 Nov 2020 14:28:16 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2058.outbound.protection.outlook.com [40.107.220.58]) (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 17D103A13E1 for <dtn@ietf.org>; Mon, 23 Nov 2020 14:28:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CdBmZ7mV5jie3iIaZ6S6qly3unI3CN1VgYb9VMUHo5JYE9ZcMJVP9efqz8keNnNdra8NUAXGCBVFIfKEjAJLloh6R0lm2B8iIWYY0Vg+lnJJpYpI+e3D00dkZLEaAhLXcY2R3tQgivwbdWNu5ZvdLmXh+8CqgJoyRP8B6/02rnimgwg6RCWAFBrUNeWGiEyzM250MqBsSoSsX4K73kkIMnVyf5qHvNTVnffks4WaQX2Lw8+oqnRZAR1Xz/NOlQQN6izLXn35i0JqWZk1U1rbQxDxC2bq5tSb7qv2Y+2Go64tpKgtNBCkNF0rOMouxWZxm5f/fRdkSgmIr6B/Li3qCA==
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=mY1J6zfMdjCuT1le+Ut61qh2u5QMtmpDQNm+pit05To=; b=CQ4vqsOLjUk7eIW+yCNy5aWe0JneewJZotbnGGNci4uQ7OY78+Tc7SUhoxsYDMJwjErTjpoXtd8YGYRgRHu2nYaseKR5PUg+xIjHLIssogRd4gVmkv3Pe1t2ESi8i3JVXsHYLIXWqkwRiF0Lly51qoGmxIQzy3XGv0hb8Lbsp15Mkpi/81QepzbN7437G9KuMf+Lfzyj5mRVgiI8eMuxQ+YwnM7UWgx0737kLRAm6TZbkaofb6GJeEKn3skzclR93EBKZhGEcD/vEfaeKO6d+vqa59GRsKAzVRZFuy8eQpOk6okKgGAdqqChaItTR2/j4sloVkUS5wZ2G0P4vw/YaQ==
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=mY1J6zfMdjCuT1le+Ut61qh2u5QMtmpDQNm+pit05To=; b=CDusFIc+7p9CAZChiH5s1X8zUgKZaoIeCZECB573dntjP4lPCEtYNvcNUknALeUv0EKH20KZElCEYZcAP1iE0Kga2wfuYLTcVJDJKbZAcwPRuzAV5F96uPqPRKw+AdweHU1yyb7/d2l6ZjYvUr3MJGtdJ3Ko8b0Nsi22JT21hX4=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by MN2PR13MB3264.namprd13.prod.outlook.com (2603:10b6:208:13c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.14; Mon, 23 Nov 2020 22:28:13 +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; Mon, 23 Nov 2020 22:28:12 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: Russ Housley <housley@vigilsec.com>
CC: "dtn@ietf.org" <dtn@ietf.org>, Ben Kaduk <kaduk@mit.edu>
Thread-Topic: PKIX Extended Key Purpose recommendations
Thread-Index: AQHWvv0sWy/YaK09E0Ki20F4+VZLK6nS5rOAgAMy6fQ=
Date: Mon, 23 Nov 2020 22:28:12 +0000
Message-ID: <MN2PR13MB35670ACF7A2A7895D234D5959FFC0@MN2PR13MB3567.namprd13.prod.outlook.com>
References: <MN2PR13MB3567A71AA43D243A2ED6989F9FFF0@MN2PR13MB3567.namprd13.prod.outlook.com>, <344A8067-1280-435B-A289-8D5C0FBAA41C@vigilsec.com>
In-Reply-To: <344A8067-1280-435B-A289-8D5C0FBAA41C@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; 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: b1344d67-8c03-43fd-5f80-08d88fff1077
x-ms-traffictypediagnostic: MN2PR13MB3264:
x-microsoft-antispam-prvs: <MN2PR13MB3264A5D6306199F5C1D636619FFC0@MN2PR13MB3264.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: 1CJKGauYlKPSw/eJuDQeC6CCwZcncyjebAIuGJLdigqpvowqk26Q1++BEP9luWUqtHCeS9+kfkCU1dYHNwv2wyu2ojnCmD77twPHk686bmHqtgjDr63gktxsACRCI96h2s+6/OkFauO2P/ArKGSbOPZU7V9uTrXb5XVDEokNgZjN719muVnnCDag8sArH7huVQ8ywFVtE2eUyEJufOHOTmJsD5CrMnv7e72SszqQzy0DTwffXtxvqSoRQk8thadhDh3FXgI/5gP+FAoFoVc0e5/GA0LVk4KCZtEWzX7CV2tr2/AXsa6oxTB4S+h59etIJNfvf7dqS9FvQTOXR0q+ar4MtKoG+0xFLbVG+YrL9bdZssH2Hmx0w3IK4yD6kfbof0b7ShalIjFcQjmnLErG+w==
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)(366004)(346002)(39840400004)(396003)(136003)(376002)(55016002)(9686003)(966005)(316002)(54906003)(478600001)(86362001)(166002)(83380400001)(33656002)(71200400001)(52536014)(5660300002)(4326008)(66556008)(66946007)(66476007)(64756008)(66446008)(76116006)(2906002)(186003)(6506007)(53546011)(7696005)(8936002)(6916009)(8676002)(19627405001)(26005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Vd4GIYcbr/bLCBI0Pn7RmJPelPDETa6FyiHFUF7CTRfZTm7x2Qg9Wx0x1J939eCBiIMfl/3mTSSiEbxpB2yRBWekDSSMS0A03t9mXZCObYhKMp01dLyLA5JFmEEWUrN0QsIcKSUdM5rcpxxZiTzC3NFh05kXg6Pt9+QnA47M2nf6/ulDuerxLNSfsvJ5hWcorqyE6Gxqt+X2s1l65y3fUR4rnqmdnr+u5yXIprjtbwrC8GW7qyI4LHAKhHW4U7dmGpGvDmXx0DqghXbEBhWBsjJqTYKOpHQi8LLpOD6YDzBc0Nc/CJUW6xV5pGGOPUXUAjzBJQKeLJYnr8f6+FfjFQ1BYu7IIGSGkiTdtNM+kUcd7qidG0tdKOtkwUX1rVdjmFJW3tVSLubpgyahDnrjyypM1k/rjaqsGX7wpWz2SLCLa6NzEHxl0gQnBGy7MrRJxtEaBy5XUwMGPj6kczkiB3yHYEhnfuPQtfcK2IizNj55S8MB1S685MDm5I+8lQcY32dPWvz0gCX1Y4HhcKyeDBQhb4xKHt6lbr8UAwnUXN2nmrcEc6ghunnoTFiF8hAO1NxBHgFBm2YgnQqJKWDdSFUbayDhPrhiX7buK5+Ad3ZM78s5L3iE7U93wPuvHi/eV+5AbFZTWgsGKrhoqVRYSU/bUnoyENjoERA2MaNJCzvCHXj/84WS5O+j4StcbnC2p4dlAol5D7njfwhFYh+Us7PwVvAmaLb0B7YzxYjvkI74hRbGEE1Df3hSOlq6Perg2gKOv729aANs8GQJL2Q9eDwFkvNRSoyOrMX24rs5T6Nxqm6P1uafrSgaDuBy9cUF2bBXT+EzplepPWOoWq13xJGTjjoSpJgL1Ia3mtCYvvTuMj8FDwrdVNGzCaMrwO4dKR2z9vDriwygohU96zz4YQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB35670ACF7A2A7895D234D5959FFC0MN2PR13MB3567namp_"
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: b1344d67-8c03-43fd-5f80-08d88fff1077
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 22:28:12.7446 (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: 0vJw6JPeoQtGONfAnSKuV+oGV5vJOm0NbzanCfZSKkckvoNHjjupdA2kieZnpGGeAPocFbEC9Znsz3QI4Rc7zA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3264
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/WJY_dssV4L1D0S2d34vd97-THNo>
Subject: Re: [dtn] PKIX Extended Key Purpose recommendations
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: Mon, 23 Nov 2020 22:28:18 -0000

Russ,
To give a very short background: DTN is an overlay network and uses Endpoint IDs (which are URIs) as bundle destinations and Node IDs (also URIs) as bundle origination and routing hops. This is slightly different from S/MIME in that DTN messaging is not symmetric (a bundle origin is a Node, but its destination is an Endpoint which may be "multicast"). The bundle protocol does have administrative messaging, for which the Node ID is the Endpoint ID, and a draft mechanism for a CA to verify the owner of a Node ID [6].

So there is a way for a CA to know that an end-entity both participates in DTN and has a Node ID for which bundles can be sent and received. The harm of incorrectly including the DTN EKU is a leaking, spoofing, or blackholing of bundles related to an impersonated node. Although based on current DTN implementations, the TCPCL-exchanged Node ID alone is not enough to impersonate a node. Higher-level routing data (mapping Node IDs to CL protocols and network addresses) associated with a bundle protocol agent is really needed to be manipulated to fully impersonate a node.
The harm of excluding the DTN EKU is a peer not being able to distinguish between an end-entity cert validated for and issued for e.g. HTTP being used for DTN authentication of a DNS-ID. This second harm is not so bad in the sense that if a CA has verified a DNS name that the certificate holder is still authenticated to be using that DNS name.

To Ben:
Maybe a better recommended policy is to require authentication of one of the NODE-ID, DNS-ID, or IPADDR-ID but to only use the received peer Node ID as authoritative (e.g. for peer discovery, updating routing tables, etc.) if the certificate has the DTN EKU value..? This allows flexibility in what kind of identity can be issue from a CA to establish the session but limits the use of a not-really-authenticated peer Node ID while still allowing normal routing to occur.

Since the recommended policy still requires mutual authentication, only the passive side can even use a DNS-ID to authenticate. So there are still potentially CA policy issues that need to be worked out e.g., allowing Node ID validation [6].

[6] https://tools.ietf.org/html/draft-ietf-acme-dtnnodeid-00
[7] https://tools.ietf.org/html/rfc4945#section-5.1.3.12

________________________________
From: Russ Housley <housley@vigilsec.com>
Sent: Saturday, November 21, 2020 13:15
To: Brian Sipos <BSipos@rkf-eng.com>
Cc: dtn@ietf.org <dtn@ietf.org>rg>; Ben Kaduk <kaduk@mit.edu>
Subject: Re: PKIX Extended Key Purpose recommendations

Brian:

I was referred to you from Ben Kaduk regarding the design and use of a new PKIX Extended Key Purpose. The use cases for this new purpose are for the IETF DTN WG (CCd on this email) and currently fall under three categories: bundle transport security (using TLS), bundle integrity (signing), and bundle confidentiality (encryption).

The idea is that a new OID is allocated for "DTN Security" and this would be present in the EKU to indicate that a CA has verified the key holder to be trusted to run a DTN node. There is an open question as to whether there is enough distinction between a purpose of "generating or accepting security blocks" and the purpose of "transporting a whole bundle untouched".

The good news for rationale and understanding of these uses are that they are very similar to SMTP/TLS [1] and S/MIME [2] respectively. Although it appears that the id-kp-emailProtection OID was only ever specified for S/MIME and not for email transport between MTAs. I don't know what kinds of policies SMTP MTAs have with regard to PKIX certificates, even recent MTA-STS spec [3] doesn't define or reference a more detailed PKIX profile and doesn't mention any X.509 extensions at all.

id-kp-emailProtection is for use with S/MIME.  It should only appear in certificates that also contain an email address for the subject.

The bad news is that in some very simple testing of adding a new purpose OID I see that OpenSSL, which is used by both of my reference libraries Qt5 and python "ssl" package, appears to assume [4] that when I want "TLS on a socket" what I mean is "TLS for Web client/server purposes" and requires either id-kp-serverAuth or id-kp-clientAuth. There also appear to be quite a number of other implicit uses of the Web purposes in OpenSSL and no real access via higher-level APIs to affect this. The other key purposes seem to be usable only through different APIs unrelated to TLS.

id-kp-serverAuth or id-kp-clientAuth are for use with TLS.  id-kp-serverAuth usually contains a domain name in the for the subject.  In the MTA example, the client also contains a domain name in the for the subject, but that is not the only situation where client authentication is used.

Ben originally referred me to [5] as an example of allocating new OIDs for another recent use of TLS for RPC. That draft doesn't really have a PKIX profile for how the new purposes inter-relate with existing purposes or how validation should treat the new purposes relative to pre-existing purposes.

All that said, the short question is: is there value in allocating an extended key purpose for DTN security?
If so, how much detail for a certificate profile and/or validation logic is either necessary or useful relative to any new purpose?

I do not know enough about DTN to know.  How would a CA know whether a particular certificate out to include the DTN-related EKU value or not?  What would be the harm if it was incorrectly included?  What would be the harm if it was incorrectly omitted?

Russ