[dtn] BPSec contexts and blocks

Brian Sipos <BSipos@rkf-eng.com> Thu, 30 July 2020 12:16 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 8515F3A10CB for <dtn@ietfa.amsl.com>; Thu, 30 Jul 2020 05:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=rkfeng.onmicrosoft.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 yK6I4UwE-T25 for <dtn@ietfa.amsl.com>; Thu, 30 Jul 2020 05:16:02 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2045.outbound.protection.outlook.com [40.107.220.45]) (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 796533A125D for <dtn@ietf.org>; Thu, 30 Jul 2020 05:15:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BuK36y3ZVY1ze0qB3g+0nsZEiwEE+GbPN0T2oDbe13KkwUEL/QxyazrUoVEmkwLpSKmCecAHBwAZ2ZgAItYLZlkh1D7hxgiGSmEqFtabUPBr7boxMXgujtarQmiTpFuKNumPfPg0TNpksS+RNPlUQxU7Kt1bvD+lAVLMMle8ryUyFotzIe3DIgNxNsKNHct4wctdf3sIwMyClsAjBedRo6yiaQ37ypItjdDLt0eK9IOE+zqenIW1WdOS6fmJZ999NcXBoS5K5eKe57MrOlIWcqCbM7gG+PbOHLeDJ2AsBuXfLccqgz1uxsNuxQC9IQNUfVtBVkzXZonCIPVq/ng1Ig==
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=6erwWVrM92xDWkuHPSSS3Gm1Wu+UyrpHG0wBCla9QHM=; b=W+6hHlrS4wTzKXSSSGnky7rPtYAvaj8wp2lQC9hvfTaklVzIk2gSXaKJG23A7rzeg94gWModmz7TqSCnLF0MTBG3BkVl1g/Rr4Fsy19dlgx6wH/EBx9qQBSXweOa+8jkeRrjYfINMVRc+gOTl1vMwi6ufOBDh5sSprQAS/slG1+rS+hXkIHl4gA+8Xn1+Req9IDPulYtIIkbnXE5MR++j+KushqIH/hQGB2xj4Ujx5hyReR0P9ozeL5LAYLqMAJ8Bxjm5csAC73XpudSucBCHM/WRWmevUJd19MHmvat+ke+/eiWanImX3kGgEOBUS9PmQldc2wcTdlfYFO8qBmYzQ==
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=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6erwWVrM92xDWkuHPSSS3Gm1Wu+UyrpHG0wBCla9QHM=; b=PBmlWB/vfzLONVe1qBDmXCAJNkmRZtv1qsAX1SvWtWr/D/GmFJWlJD4R3GL1bPW8Y1/3X7upXN5jHysnH5DIyX09Z91WSOjmwY7N35Q/eOnXcnYQLg1d2rII9n57imbS2XuXSUK+zjxic/BDvK1bB2Gx+9iX5tFE2b0k2zHY9eE=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by MN2PR13MB3309.namprd13.prod.outlook.com (2603:10b6:208:15a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Thu, 30 Jul 2020 12:15:32 +0000
Received: from MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::2d8f:101:ed5f:2f4c]) by MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::2d8f:101:ed5f:2f4c%3]) with mapi id 15.20.3239.019; Thu, 30 Jul 2020 12:15:31 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: "dtn@ietf.org" <dtn@ietf.org>
CC: "Birrane, Edward J." <edward.birrane@jhuapl.edu>
Thread-Topic: BPSec contexts and blocks
Thread-Index: AQHWZmdKDzZH8mfz40q1HPEbZ6dHmA==
Date: Thu, 30 Jul 2020 12:15:31 +0000
Message-ID: <MN2PR13MB35674B65D7C75A06D648065C9F710@MN2PR13MB3567.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [108.18.140.127]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 408be97b-b6d0-470b-f389-08d834824143
x-ms-traffictypediagnostic: MN2PR13MB3309:
x-microsoft-antispam-prvs: <MN2PR13MB330977E7B0F958240BB331B89F710@MN2PR13MB3309.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 18tn8jq1jnDFX8f+dawCNbhsRGJrqHeZdFjjm27OgV7v5BdTOjrL21vZQ7SQ+IoSSUoelC/XNPIGm41LwSxH9wg902fVMI1O7A0hjJAykhAucZpced8tfQ+twmopVjuK7a3iP7/C84k0B9SzpdwpvPOqdC193YwAj3+iWN3DsYHz730aEEUv0epTpT6BHe/DSr09S1+9UVmcljoNzma0u2AKdvWqII1Dqg9LgjaNvknf9FInkcFeiE+WliTbqbDRmN+fd5x0kj9sf0HDxeQkAbz4NUsBJ/uVMBAPXHrMfuwHLovPWga58LpOHxyIoFKq4Z815qPrRm4rWctNu04WVV7AJ4kSi02Gii2892YkBY2EKJ4Yd6WRjs41FZ9H/nVrAgN34PnYtGN5q7w4aiVAQg==
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; SFTY:; SFS:(366004)(136003)(396003)(346002)(39830400003)(376002)(966005)(508600001)(8936002)(2906002)(6916009)(8676002)(86362001)(3480700007)(66476007)(66946007)(64756008)(66446008)(76116006)(55016002)(9686003)(6506007)(33656002)(66556008)(83380400001)(186003)(316002)(19627235002)(71200400001)(166002)(7696005)(5660300002)(52536014)(26005)(4326008)(19627405001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: cqNYVn3oO155eb9cfoI86Vp86oMopCNJjVMCruuPQQsxGZC/SYvhn3cQFqNKg3FonODwUOjXXdfN8LVtJB5jLBbnRpoRJfoQ4o2B67CvyBYexZzWBG3kuwZ5CGwH+UE7vdHM7V4Qb7hyv+MAILF+oc/6p2b/vkIEeLHseoYS8a/LGsQdxb94f0j8ydFJl6z8AaiKG6Gc5fn1aEXpJe96C203xu39ew/1onoeNYvPT+V2CCTPBcGnqEq6c661Ktx76c5pzEhCzQlKB37drZw8pdCCrATenww/hyeWaMWlOvlTYrGesXf5CT+yVC0ZnYf5NMZIwoMjsFPY40L6tQdw+WSvKAt6g3KqdS+omBmm5l2/C0hKOdYmjzsMssy5X3dS8xT44MSiIVN/5t4B9Au8GB3C6dJnqunMNEGc/KJDK867h29XKhmHD/Y6aBaDtLxlv+pM6PEbjid1JvPfwR3Z2JPq3UzHSV5bIeAHNcDAwQIFdmRtQUmexZFnwTNeQR+sAFNP2/YHGG7ld8SVjzhcYpGy7uA8y+h0irriitSnFLPeGM2aUdcYmlQ6hXEMuNZHXuzdfsmc1YjtWCXKhmeNT9IIdFvNfCv2crJjwDHaFgNFDRXj42G+RxnC87QYMEMMtEa4L0V/SJ819pVihNdJww==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB35674B65D7C75A06D648065C9F710MN2PR13MB3567namp_"
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: 408be97b-b6d0-470b-f389-08d834824143
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 12:15:31.6551 (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: UV5jY9HBWJJXWhIf/HI0zre1IGVjUfuVyT/QD6yH5CdCbZcfUcdLBjso/jdnXFdHLM3wtR3q5BQ9rHa4ACyuTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3309
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/tIzOgMuXHjAZfBGWu6ZMy9KSvVs>
Subject: [dtn] BPSec contexts and blocks
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: Thu, 30 Jul 2020 12:16:06 -0000

Ed,
One thing which has come up in drafting the COSE security context is the notion of a Context ID and security block(s) in which the context can be present. Right now, the registry in Section 11.2 of BPSec [1] does not assign a Context ID to any particular security block(s) and there is no text which requires a Context ID to be present in only one type of security block.
In my initial go at defining the use of COSE in BPSec, I naively assumed that a Context ID would be limited to a single block type so allocated two Context IDs for COSE [2]. But in fact there is no distinction between these two contexts because the Result ID actually defines which operation is present (signature, MAC, or encrypt).

Is it reasonable to define only a single "COSE Context ID" and allow it to be used in either an Integrity or a Confidentiality Block?

Since neither BPSec [1] nor the Security Context Template [3] seem to mention this, can either be updated to to require a security context to explain which types of security block it is expected to be present (or not present) in?
Section 2.5.3 of [3] hints at this but uses the language "a security block" rather than distinguishing between different security block types. I expect that most contexts will only be defined for integrity or confidentiality but not both.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-22
[2] https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-bpsec-cose-01#section-7.1
[3] https://datatracker.ietf.org/doc/html/draft-birrane-dtn-scot-00