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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 11 December 2018 16:29 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7A39C130E3C; Tue, 11 Dec 2018 08:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Uo8Z0n6hyK8t; Tue, 11 Dec 2018 08:29:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC4130E44; Tue, 11 Dec 2018 08:29:25 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27D0020089; Tue, 11 Dec 2018 11:29:18 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id EB30DE1B; Tue, 11 Dec 2018 11:29:23 -0500 (EST)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id E93A1E15; Tue, 11 Dec 2018 11:29:23 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ace@ietf.org, anima@ietf.org
cc: "Panos Kampanakis \(pkampana\)" <pkampana@cisco.com>, Peter van der Stok <stokcons@bbhmail.nl>, max pritikin <pritikin@cisco.com>
In-Reply-To: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 11 Dec 2018 11:29:23 -0500
Message-ID: <3831.1544545763@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/CIVFzUGEx4M-7u1yhy3-TlQRcUI>
Subject: [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: Tue, 11 Dec 2018 16:29:34 -0000

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

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

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

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-