Re: [Ace] est-coaps clarification on /att and /crts
Jim Schaad <ietf@augustcellars.com> Tue, 11 December 2018 17:50 UTC
Return-Path: <ietf@augustcellars.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 AD00A130ED8; Tue, 11 Dec 2018 09:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 e4VNpQPV75GW; Tue, 11 Dec 2018 09:50:09 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BFC130EC7; Tue, 11 Dec 2018 09:50:08 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 09:45:03 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>, ace@ietf.org, anima@ietf.org
CC: 'Peter van der Stok' <stokcons@bbhmail.nl>, 'max pritikin' <pritikin@cisco.com>, "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com> <3831.1544545763@localhost>
In-Reply-To: <3831.1544545763@localhost>
Date: Tue, 11 Dec 2018 09:50:00 -0800
Message-ID: <036301d49179$f2558bf0$d700a3d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGPjv7lcqlAiUUAise1VV4kpyPAbQIUVGQwpfMyi5A=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/fWtf592L7BTjpVJP8tCXyAh2470>
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: Tue, 11 Dec 2018 17:50:11 -0000
Clarification requested - exactly what element is the Registrar? The one item that I can generally think of that might be a problem is that the answers to /att and /crts may differ based on the entity that is asking the question. In this case not having the entity being validated means that the "wrong" answer may be returned or different answers would be returned before and after validation. Jim > -----Original Message----- > From: Ace <ace-bounces@ietf.org> On Behalf Of Michael Richardson > Sent: Tuesday, December 11, 2018 8:29 AM > To: ace@ietf.org; anima@ietf.org > Cc: Peter van der Stok <stokcons@bbhmail.nl>; max pritikin > <pritikin@cisco.com>; Panos Kampanakis (pkampana) <pkampana@cisco.com> > Subject: [Ace] est-coaps clarification on /att and /crts > > > 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works - > = IPv6 IoT consulting =- > >
- [Ace] est-coaps clarification on /att and /crts Michael Richardson
- Re: [Ace] est-coaps clarification on /att and /cr… Jim Schaad
- Re: [Ace] est-coaps clarification on /att and /cr… Panos Kampanakis (pkampana)
- Re: [Ace] est-coaps clarification on /att and /cr… Michael Richardson
- Re: [Ace] est-coaps clarification on /att and /cr… Michael Richardson
- Re: [Ace] est-coaps clarification on /att and /cr… Max Pritikin (pritikin)
- Re: [Ace] est-coaps clarification on /att and /cr… Panos Kampanakis (pkampana)
- Re: [Ace] est-coaps clarification on /att and /cr… Hannes Tschofenig
- Re: [Ace] est-coaps clarification on /att and /cr… Panos Kampanakis (pkampana)
- Re: [Ace] est-coaps clarification on /att and /cr… Jim Schaad
- Re: [Ace] est-coaps clarification on /att and /cr… Michael Richardson
- Re: [Ace] [Anima] est-coaps clarification on /att… Michael Richardson
- Re: [Ace] est-coaps clarification on /att and /cr… Michael Richardson