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

"Panos Kampanakis (pkampana)" <> Tue, 11 December 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 913F2130ED6; Tue, 11 Dec 2018 09:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Status: No, score=-15.961 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uVhrIw20vEV9; Tue, 11 Dec 2018 09:57:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19899130EC7; Tue, 11 Dec 2018 09:57:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3305; q=dns/txt; s=iport; t=1544551053; x=1545760653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SLDjphjuKfzoOT0xIfTPUYK0xiFyZzNKoLj7TFSd2C4=; b=TRSTR8Zq/sX2R4jieZGJz8QOqRsKjTCvr2a4zHPjdoQ+f7b+9fcUnRjJ bbu8mJ4qIE5STg+JoXcIt5/B14kEbaCWVWpU/ovx4Zwt6J1e8NdsyooAM U6K58KOlG/D2U/zTeYAsZ+HvPm7jHPQV1PsAppIWAEWQUS5VItWzoUFDX Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADW+Q9c/4UNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCA2aBAicKjAqMEYINl1KBegsBAYF3gnUCgmw?= =?us-ascii?q?iNAkNAQMBAQIBAQJtKIU8AQEBAQM6PwwEAgEIEQQBAR8QMh0IAgQBDQUIgxq?= =?us-ascii?q?CAacoii+Jc4JIF4FAP4ERgxKEa4VxAolRhW6QZ1UJApFHIJFAiSOPaQIRFIE?= =?us-ascii?q?nHziBVnAVO4JskFtBMYpLgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208";a="497489908"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2018 17:57:31 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id wBBHvVKO022224 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Dec 2018 17:57:31 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 11:57:31 -0600
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 11:57:31 -0600
From: "Panos Kampanakis (pkampana)" <>
To: Michael Richardson <>, "" <>, "" <>
CC: Peter van der Stok <>, "Max Pritikin (pritikin)" <>
Thread-Topic: est-coaps clarification on /att and /crts
Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4Kg
Date: Tue, 11 Dec 2018 17:57:30 +0000
Message-ID: <>
References: <> <3831.1544545763@localhost>
In-Reply-To: <3831.1544545763@localhost>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Ace] est-coaps clarification on /att and /crts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Dec 2018 17:57:36 -0000

Hi Michael,

I thought about this for the EST-coaps draft. EST allowed for unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you are suggesting. It is not as simple in EST-coaps. Two reasons: 
1) There are constrained networks where an easy amplification attack could take place. For example the /crt request is very small and the response can be big (a few KBs in the context of a constrained network is big). If unauthenticated, then /crts could be an easy amplification attack to saturate a constrained network. We don't want that to happen. We want all our clients to be authenticated by DTLS before they start loading up our RF network.
2) Additionally, there is a practical challenge of COAPS. When the DTLS handshake is taking place the server does not know what the request will be. In EST the server would send an HTTP WWW-Authenticate header to ask the client to authenticate. Such a mechanism does not exist in COAP, so it would not be straightforward unless we introduced a bunch of new things into COAP.

I think it is still right to authenticate clients even for /crt and /att in the EST-coaps context. Maybe that is something to be revisited in Constrained-BRSKI/voucher, but not taken lightly. 


-----Original Message-----
From: Michael Richardson <> 
Sent: Tuesday, December 11, 2018 11:29 AM
Cc: Panos Kampanakis (pkampana) <>om>; Peter van der Stok <>nl>; Max Pritikin (pritikin) <>
Subject: est-coaps clarification on /att and /crts

* PGP Signed by an unknown key

A clarification question from an implementor (me) in the context of constrained BRSKI state machine.

The /att and /crts requests do not do anything to change the state of client or server.  It would seem that it might be safe to permit clients which have not yet authenticated to do this operation.
(/att gets CSR attributes, and /crts gets the list of trust anchors)

When EST-COAPS is used on its own, there usually needs to be a manufacturer trust anchor installed on the Registrar before any connection will be permitted.

When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the Registrar will accept any (and all) connections depends upon configuration of the operator.  Some devices might not be doing BRSKI (not need to, they already trust the operator, but they might still have IDevID only.  This might happen during a transition)

If the Registrar is "open" to new manufacturers, should the Registrar permit /att and /crts actions to be done by clients that it does not
recognize?   The /att call on an ANIMA ACP network would reveal to the
client the ULA that would be used for that client (and perhaps other interesting things), and the /crts would show the name of the operator.
Note that the later info probably is revealed just by doing the TLS handshake.

I think that they should be restricted in general, but I'm concerned that there might be some situation I've missed.

Michael Richardson <>ca>, Sandelman Software Works  -= IPv6 IoT consulting =-

* Unknown Key
* 0xDDD0DD65