IETF Logo Mail Archive

Re: [Ace] est-coaps clarification on /att and /crts

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Wed, 12 December 2018 19:13 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 9912D131261; Wed, 12 Dec 2018 11:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level:
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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
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 WLkkqA68c7Xl; Wed, 12 Dec 2018 11:13:15 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EBE130F08; Wed, 12 Dec 2018 11:13:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1544641995; x=1545851595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2bDVMT/5S4OowiKsOl/doUUuWhaqaBa6tMGPCaLmadU=; b=E/xvRBfNQi70TCl5DOKgDWh23y4uvBmKN33KhwLX36Jc+dz9C2XrmvOZ lEBHShI4AE54iN1sSjcRsxFjVY98u6ak+bk9j+vXk3/nARnbREuyKj6UF XRuVkXXy8m/7ITUFTb15t8+9akjNY6LSZQWq1H35MMvtXOqBjkn2Xyg/0 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADRXBFc/5RdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopgWgnCowLjBGCDZdTFIFmCwEBhGwCgnwiNAkNAQMBAQIBAQJtKIU8AQEBAQIBOjYJBQcEAgEIEQQBAR8QMh0IAgQBDQUIhRMIqBeKKYsfgR0XgUA/JmuDEoROARIBCR0xhSMCiSGXawkCjWiDZSCBXCOEd4pQiSmPbwIRFIEnHzhlcXAVO4Jsgz0BAo0bQTGLSYEfgR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,345,1539648000"; d="scan'208";a="211545458"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 19:13:14 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wBCJDEEN010235 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 19:13:14 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 13:13:13 -0600
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Wed, 12 Dec 2018 13:13:13 -0600
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "ace@ietf.org" <ace@ietf.org>, "anima@ietf.org" <anima@ietf.org>
CC: Peter van der Stok <stokcons@bbhmail.nl>, "Max Pritikin (pritikin)" <pritikin@cisco.com>
Thread-Topic: est-coaps clarification on /att and /crts
Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4KggADGBID//+UPkIABQvEA///E8MA=
Date: Wed, 12 Dec 2018 19:13:13 +0000
Message-ID: <de390a455e90491eb096822874b13491@XCH-ALN-010.cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com> <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> <e5c042393be24304b0275ed07ea6ba2b@XCH-ALN-010.cisco.com> <VI1PR0801MB2112BE91B53B96FEB3C35E80FAA70@VI1PR0801MB2112.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR0801MB2112BE91B53B96FEB3C35E80FAA70@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.34.173]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/a7YiI4hxB19p8MeySzLl2QnOXyY>
Subject: Re: [Ace] est-coaps clarification on /att and /crts
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: Wed, 12 Dec 2018 19:13:19 -0000

Hi Hannes,
Michael was only asking if allowing any anonymous entity to get the cacerts (trusted root cert list) is worth it. RFC7030 allows for this. Of course an enrollment would still require authentication/authorization. 
I was making the case that it is not worth to even allow anonymous get cacerts. 
Panos


-----Original Message-----
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com> 
Sent: Wednesday, December 12, 2018 11:01 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Michael Richardson <mcr+ietf@sandelman.ca>; ace@ietf.org; anima@ietf.org
Cc: Peter van der Stok <stokcons@bbhmail.nl>; Max Pritikin (pritikin) <pritikin@cisco.com>
Subject: RE: est-coaps clarification on /att and /crts

Hi Panos, Hi Michael,

> We want all our clients to be authenticated by DTLS before they start loading up our RF network.
> I'm not suggesting that the DTLS be skipped, I'm suggesting that the client certificate presented might be meaningless to the EST server.

I am curious what security model you have in mind? If you don't do client authentication then you are essentially issuing certificates to an anonymous entity. This feels like a very bad idea, particularly since the CA is supposed to assert the identifier of the client via the certificate.

What am I missing here?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

v2.23.0 | Report a Bug | By Email