Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Thu, 17 October 2019 20:05 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 D2E39120974; Thu, 17 Oct 2019 13:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=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=XF69q9zE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A8id5G8s
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 d4DaP8WFVxUN; Thu, 17 Oct 2019 13:05:55 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D47C120241; Thu, 17 Oct 2019 13:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7577; q=dns/txt; s=iport; t=1571342755; x=1572552355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mqpORR8+Ys7aGa7LTdPcHQ1AVlglc+/sTmISs9VJEJk=; b=XF69q9zEknARG/nRDR3BnENg2piM8CjIn9xPlarngmeTPSiCpCH9r23/ j5T48POHr1Gw1saC03nz/PJVZujIllkThGDFKn90VcNjwn4Okmw940bie 9P4w3A4ym15BHHvzsM9Xznd9Va3MJ7d6hGfN7lrzeZH0/7m5lI6Ehy8DC g=;
IronPort-PHdr: =?us-ascii?q?9a23=3ABlcPshzgoA6YmvnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADyyKhd/4cNJK1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBaQMBAQEBCwGBSlAFbFcgBAsqh2wDilCCXIl?= =?us-ascii?q?rjhSBLhSBEANUCQEBAQwBARgNCAIBAYRAAoMGJDYHDgIDCQEBBAEBAQIBBQR?= =?us-ascii?q?thS0MhUsBAQEEAQEQKAYBASoCCAMBCwQCAQgRBAEBHxAhBgsdCAIEAQ0FCBq?= =?us-ascii?q?DAYJGAy4BAgykdgKBOIhhgieCfQEBBYE0AYNWDQuCFwMGgTQBikqBJh0YgUA?= =?us-ascii?q?/gRFGgh4uPoIaRwEBAoEsAQgKAQkEFIM+giyMa6ApQQqCIocMigqEJoI6h1G?= =?us-ascii?q?NXYFfjjCBP4ZlghCMUYI6AgQCBAUCDgEBBYFZATEsO3FwFTuCbBM9EBSBUIN?= =?us-ascii?q?zhRSFP3QKNWqNCQ0XB4InAQE?=
X-IronPort-AV: E=Sophos;i="5.67,308,1566864000"; d="scan'208";a="345487769"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Oct 2019 20:05:53 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x9HK5rXT004786 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2019 20:05:53 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 17 Oct 2019 16:05:51 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KvOnz040zSIWc6Lyrrxff6bMPeTchmusXCNgotPC20QCXurMAUGvLNhWAFhcEswwk3HjFTiFah1cP3aadcVZngvd+9QEUHVlEZnBQ+bQuVDBGMBK2xJ8C9i9e7O+0HTRv27uK48JRh+jk1nuxonWt7wnlK5o0Vg6R1inAfhgoAYisrQgnoose1j6FyxNhSGTjxj0Tkq7nAXyjlSQD0+LM52tOemKNfLPwNP0p1Encq7G6qmOzpZ0yFdVI0HEMOIlwNIxy7IB0gE6mTROeIAowZyIEk/U2BNTURneofl3LWG31QWrLFBKuC7TWSS5iU8g2nCYGi81SoXJLtfAZWga8Q==
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=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=R4Wm2fwim3ythKPCBrqveRC5Mnu2UhQz1yAOm/Exrc9SHT8WMzeD+AxelRU7oqBHNqRBwe6lKAifaNrHTpnZpDCNHuf0ZqCGlg2wycnv/AY7RmvuYcIa7W8gAcRSfNQFsW3ChJoaEUvjRMzqXCUQ0IGXeX/Xi2V5wEDQHbIAiZB68GDXgnHOdsfQKmn5MlcU9euufro1DbStrEWD2wbMZROGrrHsgb87uKuMYo5SdxMqnh15X7LR3BsGsXbIoAekc04/PkVns4D+ouG3zRSC0yoETgidpHpt48ArisfEjxZf8qI32zgHYXqs7Sjf/4iP6cyYrIaJkBg536IQYqcl+w==
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=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=A8id5G8sFqucys1LGS7qHhALMAETfHe3KKtxmH/sT6+hXyFXpEtOCXwcuzdTtQmXBHAsjMSigfYlKG/f5AvnV6ouZDIWzNXHAeFhAHRZrYbGvsd6WIuPgoWgUpWs77kwVxfhRFrYIwNbEo8Fz+0ddrDUxOAiFW0wKb8hoMf6eV4=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2803.namprd11.prod.outlook.com (52.135.246.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 20:05:50 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.024; Thu, 17 Oct 2019 20:05:50 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-ace-coap-est.all@ietf.org" <draft-ietf-ace-coap-est.all@ietf.org>, "ietf@ietf.org" <ietf@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/tiqS6ddYSVAgAHm+LA=
Date: Thu, 17 Oct 2019 20:05:50 +0000
Message-ID: <BN7PR11MB2547D9E3C2BCC9689642FFDFC96D0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> <BN7PR11MB2547FDB1F0D64569496CEDAAC9920@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547FDB1F0D64569496CEDAAC9920@BN7PR11MB2547.namprd11.prod.outlook.com>
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:2090:1009:838:76da:e180:2a19]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 300cd109-7421-408e-a07d-08d7533d6854
x-ms-traffictypediagnostic: BN7PR11MB2803:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BN7PR11MB2803B9A9EAEFEE186527D0E0C96D0@BN7PR11MB2803.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01930B2BA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(199004)(189003)(52084003)(13464003)(476003)(6246003)(186003)(6306002)(4326008)(5660300002)(55016002)(9686003)(81156014)(81166006)(8676002)(76116006)(66476007)(64756008)(8936002)(66946007)(66446008)(86362001)(66556008)(52536014)(76176011)(7696005)(53546011)(2501003)(6506007)(102836004)(33656002)(316002)(966005)(11346002)(7736002)(305945005)(14444005)(256004)(446003)(2906002)(54906003)(99286004)(110136005)(486006)(229853002)(6436002)(46003)(14454004)(6116002)(25786009)(71190400001)(74316002)(71200400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2803; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: HkcfHpbta6pUBpAG/FowYDoUFyCHfnBTQXzF/3ReOjPRCLu4yyk+VYxTqI0AdQFWnWGWGhYlUFQWQBy6QUgFnrUoy9DKn+xn67c9iMdOzJ0KtP5tg/mLNTc5eOziN+My+jhveckOTi1IwHXVXs9Df/IDKszW/rXsQb3cLeSAs7vC52k9jjhQAWt7GqDw0sIDzLE+IfphKEmsHJ7E+eLGib1vER3ngjspEvgCZgSZ6YSwk8VURAAZhGpuTlfDu+/ocHej75pxii0WERIu/B4KzRXCq1a9Y86lD2kN5wLJUTfnMOYJUCUq/XnlhC06nnBbJRbtzp/kqoejPaIKkq1zmXD9fKfmRvTG25H5aaIXUZddYr94IBo48RZ6S3WZT5vkZZMi+jM0phFVH97FRzFkopOUhdGTI/0oN+GLjgu+SjgdKOCP+zncw1XmoXVHVJ+kwutkM1vBIvoufuHH9nCwyg==
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: 300cd109-7421-408e-a07d-08d7533d6854
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 20:05:50.3392 (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: ERho8cwrooHKQteWL8MUrZVXWr2sEeaixdGbj6iOtaOwuPMoj/2DY8JxkRuG7rRCs9dKkT3j+Up0aj6CjcDwMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2803
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/g9YV3m60D3dzQ6Wa1KBz0yTrvu4>
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: Thu, 17 Oct 2019 20:05:59 -0000

Hi Yaron,

I addressed the remaining issues from your responses in the git issue https://github.com/SanKumar2015/EST-coaps/issues/152#issuecomment-543315662 
Please check them out and let me know if you have more comments. 

Rgs, 
Panos


-----Original Message-----
From: Ace <ace-bounces@ietf.org>; On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, October 16, 2019 11:06 AM
To: Yaron Sheffer <yaronf.ietf@gmail.com>;; secdir@ietf.org
Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

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/86d785f2122596f28674fe8e403d30467c98abfb 

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. 

Rgs, 
Panos



-----Original Message-----
From: Ace <ace-bounces@ietf.org>; On Behalf Of Yaron Sheffer via Datatracker
Sent: Sunday, October 13, 2019 9:02 AM
To: secdir@ietf.org
Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org
Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Reviewer: Yaron Sheffer
Review result: Has Issues

This document defines a new profile for EST (simple certificate enrollment) for restricted devices, to be run on top of CoAP and DTLS, instead of the usual HTTP and TLS.

Overall, I tend to be suspicious of "restricted" profiles, and this is a case in point. An implementation of DTLS is no simpler than TLS and most would probably support both protocols. And basically anything supports HTTP. So why would it make sense to define a whole new profile just to avoid using TCP very rarely (say, for daily certificate enrollment), when this profile even needs to include its own fragmentation/buffering mechanisms because the ASN.1 payloads are too long? In other words, we are introducing new and additional complexity with little or no performance gain.

- 2. Only certificate-based client authentication is supported. Hopefully some time soon we'll be able to use PAKE here, to bootstrap the PKI.

- 4. "Crypto agility is important" - this statement is somewhat meaningless: do we require more than one cipher suite, which would ensure some level of agility?

- Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or also the subsections: 4.4.1 etc.

- "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups". This is probably true for an older version of the draft, I couldn't find anything to support it in -32.

- "the Finished message must be computed" - this whole paragraph is unclear.
Are we changing the Finished/MAC computation in DTLS (if so, this must be pointed out very clearly)? Or are we explaining a point about channel binding (if we are, this doesn't come across).

- Similarly for the following paragraph: is this a performance  optimization, or a change to DTLS? And by the way, why are standard session resumption mechanisms not used?

- I don't see value in the short EST URI paths given that most of the "weight"
is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the paths are different, shouldn't this document formally UPDATE RFC 7030? I think it is no longer a profile.

- Non-default server port: the examples include an IPv6 address in addition to the port number. Is there a way to use relative URIs (omitting the IP address) but include a port number? The server may not know its own IP address (IPv4 with NAT) or the address may be dynamic.

- The server MUST support the default /.well-known/est root resource, but then
in the next sentence     we discuss non-default URIs. In the case of the server
having multiple "identities" (the main purpose of the "arbitrary label", AFAIU), the root resource is confusing - which identity is it associated with?
And then how is discovery managed for each identity, and is there a way to discover the identities?

- There is nowhere in this document a full formal definition of content type
TBD287 (a single cert).

- Content type negotiation: I can see how it works for enrollment. But in the case of /cacerts, if the server has a list of certs in its explicit TA store (e.g. to support rollover), how can TBD287 (a single cert) make sense?

- It is mighty confusing to denote "content format" by "ct" (presumably, this stands for "content type").

- "ASN.1 encoded in binary format" - I think this should be, "DER-encoded ASN.1, in its native binary form".

- Please don't use "he" and "she" for the server and the client. Both are merely "it".

- "The Registrar MUST authenticate and optionally authorize the client requests" - this statement is too weak. The Registrar must also ensure that clients only send CSRs that pertain to their authenticated identity (channel binding), even when POP-linking is not used. I think this is worthy of its own subsection, describing the validation required for each particular EST flow.

- The following paragraph is not clear: is PoP-linking useful/recommended/mandated in this scenario? IMO there should be some 2119 word regarding server-side validation of the tls-unique.

- "Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to." But the immediately preceding paragraph describes a case where a server-side generation on the EST-coaps side is mapped to client-side generation on the EST-HTTPS side, which is not a Table 1 mapping!

- "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar" - can this be done without decrypting the blob, IOW must the Registrar be privy to the key wrapping key?

- The Registrar must support resource discovery: does it mean that resource discovery messages are simply proxied upstream, or that the Registrar presents a simpler resource structure (maybe with no discovery) to its clients while performing discovery upstream?

- Security Considerations: there's a long discussion about replacing the implicit TAs with explicit ones. If we (rightly) mandate that the client re-verify the server's cert after getting the /certs response, we are losing most of the minor performance gain that keeping the DTLS connection open might have given us. So why not unambiguously mandate the simpler "MUST close the connection after /certs" instead? Besides, /cacerts is a very rare operation.
Why optimise it at all?

- "Improper CSR requests" - what are they? What's the server supposed to do?
Please give a reference.

- A.3, response: I may be missing something, but the binary blob "3081...9fd9"
does not parse as PKCS#8 to me.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace