Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Mon, 18 November 2019 19:06 UTC
Return-Path: <pkampana@cisco.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187AE120B00; Mon, 18 Nov 2019 11:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HJs5bDlb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ETqftQwj
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 8ywRIwi7qURz; Mon, 18 Nov 2019 11:06:53 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85731120AC6; Mon, 18 Nov 2019 11:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5939; q=dns/txt; s=iport; t=1574104013; x=1575313613; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Il9KvJj4U2TzXau7b0rV6c14my3cJRGtPMCD1ozifcI=; b=HJs5bDlb612iMSrKqgK9s5wE3F9VAE/6JEotYyPw5+8Ms8dPvKw2vpTN F1pdQhmnO96eoMMK1NM5Og2s2aulKGq9idbPx6yiS7SNWsWtiB3wGSOnW AmvsyJ7JylQaqPYK8nMJCGmer4VYxslqpaMrl7URLK+jeFae+BLB1nsvK I=;
IronPort-PHdr: 9a23:k7UQcBJZMg0qUtxYU9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CAAAD36tJd/4gNJK1lDgsBAQEBAQEBAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF+gUspJwVsWCAECyqHcAOKb4JeiViOKIFCgRADVAkBAQEMAQElCAIBAYRAAoIjJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQEDEigGAQE3AQsEAgEIEQQBAQEeECERHQgCBA4FCBqCNUyCRgMuAQIMph4CgTiIYIIngn4BAQWBNAGDSA0LghcDBoE2jBUYgUA/gRFGgh4uPoIbRwEBgRsTARIBCRiDQIIsrT8tQQqCKocaih2EM4I+h2iOB4FklwCCE489AgQCBAUCDgEBBYFpIkQjcXAVgydQERSRGgwXg1CKGDt0CoEeincNFwGCGQEB
X-IronPort-AV: E=Sophos;i="5.68,321,1569283200"; d="scan'208";a="373221449"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2019 19:06:52 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAIJ6qkk001384 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2019 19:06:52 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 13:06:52 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 13:06:50 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 13:06:50 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E6DEjOR2zjxzAaedm6jjqkYBp+grlN1diHECmUTMjR6Vl4HmWjGKq9MrsdGCkmf2TCSt8FwyvRWej16+a0dFTDskk8CLniHf7l2oD/R9W4SzO8est1WDQqLKNZk61gVTnjEOmodRVQhU476S2NrSLsC1Y2GfzDVOrjqAKJou63JskpPlQeInE+verVO6uTfkVciFWOFlRtBviPZ+SIKhLiUnDf3zPA5v3Dy0lQR/mhyDGySCFlHrSeaYujToes/wwDgXctB312dKcWhhiWYZnbaDUQFy+t78E71Ay9S3ljL0EkCMguXYHIfhsNhIJU/atDk6i9FZjOHPV4stwuBJrg==
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=5adEeuhBAhf99a90/ZwK6s+bIL+t/bwUz4NlAFJpQDs=; b=LnWCF48v4F9xRjVYWScf8Oltmu4JR5RsEwdGyTX4Ssb4sVlubJ7/wgOY3lUwBovYVhpP463y8opLhzvHMTXoM89DehqMmbRLg6q2mj2f6G6U4v70WtvoCRcZzihpfwitf7evAgcyn2jFyosu56eXNeum9aOSXGQ05zZe7qavzKG18pIXb1hIMZqerGTawa9n8LCZQFvktMTSlbjdTkgpIFV53bJIv8y1s+/Cv5ePslKj7oBnfwLL9K2GD+gFfkPQ+jXvoNQ8IDIMbvVyx5g13DmvxTGvjjKAcySnmU47wk1GmY8n2nF0d4PeHW0mra/8AFIYEIR5L25VBdhc/RBHVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5adEeuhBAhf99a90/ZwK6s+bIL+t/bwUz4NlAFJpQDs=; b=ETqftQwjcBVg4U+TKs2UWCnUAmv0dpMaNpOP2KaKHJvE6o00NqFmeizTQqpY3q5oRwqXxZTLYu1Xi5puUNmt2vzFLLboeDEAJvPqGwtlh0cW9I/VdD8Av/zxEvPkd4PGdQ0+LKudkt7sW3VnPwKq5qb0y/DHGn8QB5QFs/0v2Ls=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2819.namprd11.prod.outlook.com (52.135.246.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 19:06:49 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 19:06:49 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Yaron Sheffer <yaronf.ietf@gmail.com>, "draft-ietf-ace-coap-est.all@ietf.org" <draft-ietf-ace-coap-est.all@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVAgCr2zQCACSCUsA==
Date: Mon, 18 Nov 2019 19:06:49 +0000
Message-ID: <BN7PR11MB2547EF1967DB0D86AD6810BEC94D0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> <BN7PR11MB2547FDB1F0D64569496CEDAAC9920@BN7PR11MB2547.namprd11.prod.outlook.com> <20191112230600.GJ32847@kduck.mit.edu>
In-Reply-To: <20191112230600.GJ32847@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com;
x-originating-ip: [2001:420:c0c4:1006::94]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fdfd70d1-907a-49f4-d2bf-08d76c5a770f
x-ms-traffictypediagnostic: BN7PR11MB2819:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BN7PR11MB2819CA95BBCFBB8B35F7A390C94D0@BN7PR11MB2819.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(346002)(39860400002)(396003)(376002)(366004)(136003)(189003)(199004)(51444003)(13464003)(66446008)(66556008)(86362001)(66476007)(14454004)(14444005)(256004)(71200400001)(64756008)(71190400001)(966005)(66574012)(5660300002)(229853002)(52536014)(81166006)(46003)(478600001)(81156014)(8676002)(74316002)(486006)(305945005)(8936002)(11346002)(446003)(186003)(99286004)(53546011)(6506007)(54906003)(316002)(25786009)(6116002)(102836004)(6916009)(76116006)(7736002)(476003)(4326008)(6436002)(76176011)(6246003)(2171002)(66946007)(7696005)(33656002)(2906002)(55016002)(6306002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2819; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yY/jdEC30Lyk1U8oocyDMVyRrzipT52f6zn6ypg+qK53zrRppbTYdWdDoOK5CFQY5vde25iXzlY2/Xih+A66xRumFS9xNZ3JGEjsJHMA/bcHdvQTVUGQMNP4TLZpKox3jXdGodhFQk2iEmtL7E48+pWF6H7P34ohJHNpBLH9NsDIrE48wvuUw4POpL2XfWMKMocjgr8A6qIYTxX0yqRfjqbGEvNTf6IHe3DCmPVoQ43iJ6gC/8oqlDDTWwMM2xeEuSLfG5Y46XxVY0q1UBIn9N/tN9x+G1rYk69qinu3GYSL95pw4LBdE5cPdTBETf5UeaxPoThPLl0d7nyZyrfsIAYnSv//aoSRliX+mT9AC4NMMMeE9FZpLTU295r8M29/JGtKmSQlGLG3GqByif3pw1WwSXi5kxLhZGVckP9Dnr6NXVXWX3r3BpW3bPYgGV4cm9aStxsD279ZrOho/Xy31dK1iNamFVJStF7IVE/Z2QoqhLmBHZkUMqoSLcmOquoItmw5Xs6E0leriNEdRGwHNttVO3806uwVK0zYUwgTtu8BNDtEmh6Y88K2PCtAnK/9
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fdfd70d1-907a-49f4-d2bf-08d76c5a770f
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 19:06:49.4288 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: csm7tpl0Qgx5hWa2RHFacf3Gj8NxkyJClxUaspdXaTOlTeH9ydQKZ14dmM2hrrGhLskwixBBK6ztz7v9iQcxDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2819
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/uqUlxk0eFZV9ndIVk7sjd131ST0>
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 19:06:56 -0000
Hi Ben, All addressed, except for the last one. The diff is here https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 My responses below in Pk> I will wait for your confirmation before I upload version 17. Panos -----Original Message----- From: Benjamin Kaduk <kaduk@mit.edu> Sent: Tuesday, November 12, 2019 6:06 PM To: Panos Kampanakis (pkampana) <pkampana@cisco.com> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Hi Panos, On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote: > Hi Yaron, > > Thank you for the thorough review and feedback. > > To make sure I don't miss any of your comments over an email thread, I track all your feedback in git issue 152 https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address all your comments and question and clarify some points. > > I also pushed minor changes to fix a few of the issues you brought up. > The diff of the changes pushed is here > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f > e8e403d30467c98abfb > > Please review the git issue and let us know if there are pending concerns. Otherwise I am planning to reupload a new iteration next week. Thanks for uploading the -16, and thanks again to Yaron for the very thoughtful review. Sadly, I seem to have not looked at the github diff closely enough/in a timely fashion, so I think we'll need to publish a -17 before I can move this into IESG evaluation. Here's my remaining notes: Section 4 Private keys can be transported as responses to a server-side key generation request as described in Section 4.4 of [RFC7030] and discussed in Section 5.8 of this document. I think that, since Yaron brought it up, we should say "Section 4.4 of [RFC7030] (and subsections)". PK> Fixed. curve. After the standardization of [RFC7748], support for Curve25519 will likely be required in the future by (D)TLS Profiles for the Internet of Things [RFC7925]. Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 is Informational, not even Standards-Track, let alone full Internet Standard). Pk> Replaced "standardization" with "publication". In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. However, when a cacerts request is I think we can also clarify that this "MAY remain open" is changing expectations from RFC 7030, where the expectation was that the TLS connection did not remain open. Pk> I added " which was not the case in [RFC7030]" Section 10.1 the first DTLS exchange. Alternatively, in a case where a /sen request immediately follows a /crts, a client MAY choose to keep the connection authenticated by the Implicit TA open for efficiency reasons (Section 4). A client that interleaves EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. I think Yaron was saying that "even if the optimization of keeping the DTLS connection open is useful in the general case, it is very risky and prone to misimplementation when combined with /crts". So, if I can rephrase the propsal to be that we say something more like "even though in general the DTLS connection can remain open for efficiency (Section 4), after a /crts response, the client MUST close the DTLS connection and establish a new DTLS connection for subsequent EST exchanges", are there reasons that we shouldn't use that behavior? Pk> I am not sure it is worth to add more complexity specific to /crts. We would be adding more complexity for the client to track if this TLS connection is a cacerts connection then I need to close it, if it is any other connection then I can interleave requests. I am not convinced that the risk is that big either. A malicious user that was authenticated by the Implicit DB could easily craft a cacerts response that allows him to be authenticated by the Explict DB. In other words an active attacker would have no problems of fooling the Explicit DB if he was allowed in by the Implicit DB. I think the whole issue here is conceptual. The moment we get a new Trust DB we need to trust it and not use the old one, but I don't think that keeping the connection open for one or two more requests is that risky. Even RFC7030 allows for it in the event that the client does not have an Implicit DB when it is starting " The client MAY provisionally continue the TLS handshake to completion for the purposes of accessing the /cacerts or /fullcmc method. " I think the language as it is now is pretty clear on what we are trying to do. And the Security Considerations spells out clearly. Of course, as always, some implementer could make a mistake, but that could happen with RFC7030 and any other RFC as well.
- [Ace] Secdir last call review of draft-ietf-ace-c… Yaron Sheffer via Datatracker
- Re: [Ace] Secdir last call review of draft-ietf-a… Panos Kampanakis (pkampana)
- Re: [Ace] Secdir last call review of draft-ietf-a… Panos Kampanakis (pkampana)
- Re: [Ace] Secdir last call review of draft-ietf-a… Benjamin Kaduk
- Re: [Ace] Secdir last call review of draft-ietf-a… Panos Kampanakis (pkampana)
- Re: [Ace] Secdir last call review of draft-ietf-a… Panos Kampanakis (pkampana)
- Re: [Ace] Secdir last call review of draft-ietf-a… Benjamin Kaduk