Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?

Jim Schaad <ietf@augustcellars.com> Wed, 09 September 2020 22:40 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 5C6B23A0FBD for <ace@ietfa.amsl.com>; Wed, 9 Sep 2020 15:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oVkk6fWaSEQX for <ace@ietfa.amsl.com>; Wed, 9 Sep 2020 15:40:37 -0700 (PDT)
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 BBC1F3A0F78 for <ace@ietf.org>; Wed, 9 Sep 2020 15:40:36 -0700 (PDT)
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; Wed, 9 Sep 2020 15:40:31 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>, ace@ietf.org
References: <007201d6807a$9febe250$dfc3a6f0$@augustcellars.com> <86E83EED-DCF5-4665-B77F-15A7E8DA9E21@ericsson.com> <01ad01d6826e$5e498be0$1adca3a0$@augustcellars.com> <46BBE2A4-67C2-4224-BDC0-33CB44EEBFD6@ericsson.com> <4476.1599527043@localhost> <C868440B-9359-4347-BD04-2145E04275E7@ericsson.com> <2810.1599665526@localhost>
In-Reply-To: <2810.1599665526@localhost>
Date: Wed, 09 Sep 2020 15:40:29 -0700
Message-ID: <000301d686fa$397c1ef0$ac745cd0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIUjZayyRm134bGenvevfaaL5wBNgEX3XoeAc3OX0QBKET/WQI1z+awAYHgvL0CeIRQy6iS3/7A
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/SyP9BTPITYeJQKRaPa9JXhZo3JA>
Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
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, 09 Sep 2020 22:40:46 -0000


-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Wednesday, September 9, 2020 8:32 AM
To: ace@ietf.org
Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?


Göran Selander wrote:
    > We have been working on lightweight procedures for an IoT device to
    > join a network. The join process may include a number of components
    > such as authentication, remote attestation, authorization, enrolment of
    > locally significant certificate, etc. Much of current standards are
    > based on doing things in sequence, one thing at a time. This may be a
    > good idea but it introduces some redundancies. One way to reduce
    > overhead is to reuse elements from the authentication protocol in the
    > authorization or certificate enrolment processes. So, instead of
    > passing public keys and signatures multiple times between the same
    > endpoints over constrained links during different phases of the joining
    > procedure, we try to make more use of the authentication protocol while
    > ensuring that the security properties are as expected.

...

    >     The link: Generic Animation of BRSKI - Bootstrapping Remote Secure
    > Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast)
    > points to: https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5
    > minutes long.

    >     I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained
    > enrollment.

Thinking a day later, I think that presenting a well animated view of ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what fits into ACE and what does not, would help out small design team clarify/debug our message, should we go to secdispatch, or whatever.
[Jim: does that answer your question better?] I mean, we could also just hold our own virtual meeting too :-)

[JLS] Yes this does a much better job of telling me what you are trying accomplishment.  Having an idea of what the document is trying to do and what the problem that you are trying to solve makes it easier to slot in time for this.   I am more than willing to have ACE sponsor a different time slot if you want to have a known amount of time up front for the presentation.  I am willing to schedule it into the next meeting.  But you never know how much time is going to get consumed dealing with adopted documents.  

[JLS] I still need to do a deep read on this document.

Jim


I am personally more interested in writing code than wrangling documents from WG to WG in the next ~4 months.  I think that some other things in the IETF will sort themselves out in that timeframe, and a path forward will become clear.
In the meantime, explaining things to others helps me get it right.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide