Re: [Emu] Provisioning, configuration, etc. and EAP

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 28 March 2022 20:38 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5F53A1535 for <emu@ietfa.amsl.com>; Mon, 28 Mar 2022 13:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.366
X-Spam-Level:
X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 TOJzFUf0G5Rr for <emu@ietfa.amsl.com>; Mon, 28 Mar 2022 13:38:36 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF433A1917 for <emu@ietf.org>; Mon, 28 Mar 2022 13:38:34 -0700 (PDT)
Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 3DDDD1F4AF; Mon, 28 Mar 2022 20:38:32 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7E6441A0285; Mon, 28 Mar 2022 14:56:39 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <aland@deployingradius.com>, EMU WG <emu@ietf.org>
In-reply-to: <88AA8004-A40E-44B1-AD00-E2F949F24F22@deployingradius.com>
References: <8C03CE4A-B987-4962-9AA3-5DF8FB32ECB5@deployingradius.com> <69074.1648310244@dooku> <88AA8004-A40E-44B1-AD00-E2F949F24F22@deployingradius.com>
Comments: In-reply-to Alan DeKok <aland@deployingradius.com> message dated "Sun, 27 Mar 2022 09:48:35 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 28 Mar 2022 14:56:39 +0200
Message-ID: <93966.1648472199@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/sq-j58N5NK-_TYBmIn6S7CV5Lc4>
Subject: Re: [Emu] Provisioning, configuration, etc. and EAP
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2022 20:38:41 -0000

    >>> reconfiguration - how does a device with an existing configuration
    >>> update it?  When / where / why / how?
    >> 
    >> Why is this step different than configuration?

    >   I put that in, in part because of EAP-CREDS.  In part because I'm not
    > sure that updates fall within the bounds of provisioning / onboarding.

    >   i.e. I already have something, and I can get onto the network.  How
    > often do I refresh those credentials?  What happens if my authorization
    > changes?  How do I get told if my credentials are withdrawn?

I understand.
For mechanisms like BRSKI (and CSP/MATTER, and probably UPC UA) where the end
product of onboarding is a certificate issued to the device, then the
question about when to refresh is mostly given by the notAfter parameter.
In most cases one should start refreshing those credentials at the 50% mark.

The ACME WG is discussing having the certificate renew point be better
specified (in the ACME protocol), but I think that we will learn from this
and wind up with something in the certificate if the protocol can't carry
additional meta-data.

    >   Perhaps this could better be described as policies and signalling for
    > refresh and updates of provisioned data.  The act of doing the update
    > is just provisioning.  Knowing when / where / how / why to do that
    > update isn't quite part of the provisioning process.

Agreed.
There are advantages of having renewals spread across time, but there are
also disadvantages as it spreads the failure signal across time as well which
makes it harder to see that there is a real problem.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [