[Ace] When does a KDC need to roll the keys over

Jim Schaad <ietf@augustcellars.com> Sun, 04 August 2019 18:46 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 5497A120047 for <ace@ietfa.amsl.com>; Sun, 4 Aug 2019 11:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 aXG2hM0PPp0U for <ace@ietfa.amsl.com>; Sun, 4 Aug 2019 11:46:38 -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 1AF55120033 for <ace@ietf.org>; Sun, 4 Aug 2019 11:46:38 -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; Sun, 4 Aug 2019 11:46:32 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <ace@ietf.org>
Date: Sun, 4 Aug 2019 11:46:29 -0700
Message-ID: <02f401d54af4$ef450050$cdcf00f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdVK8Oc4dYRNXiLZStCJZw0G1K4U/Q==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/bDuQvYeqks78UB_DDKmzFXWROMI>
Subject: [Ace] When does a KDC need to roll the keys over
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: Sun, 04 Aug 2019 18:46:40 -0000

I have been writing down some logic to deal with when  KDC needs to change
epochs.  This is in part because I need to figure out what should be
constant and what needs to be exposed in the user interface for
configuration purposes.  Some of the inputs are pretty easy to see such as:
If X amount of time has passed then do a key roll over or, Don't roll keys
over if less than Y time has passed.  Some of the checks can get really
weird such as:  I have issued you a kid but have not given you key material
in the current epoch, so I can just give you the same kid with the new key
material.  On the other hand if I have given you key material in the current
epoch, I should not need to roll over the key material but do need to
provide a new kid so that you do not reuse the save IV values.
Alternatively, it could be that rolling the key material would be more
efficient in terms of traffic on the wire depending on if one things that
retrieving key material or retrieving signatures for every entity is going
to be smaller.

The one case that I have not been able to get a good handle on is as
follows:  The KDC persists keys and key ids in a database.  The KDC at some
point crashes and then restarts.  Should the KDC roll the epoch and the key
material on re-start or should it just load the current key material and
continue with it?  A client that tries to JOIN would be unable to do so
because the KDC does not respond so that would not force a roll over.  A
client that tries to do a RENEWAL because of IV exhaustion would be unable
to do so and would have to go quiet until the KDC because alive and that
would not force a roll over.  A client that tries to do an LEAVE would not
be able to tell the KDC that.  This is the one case that having the KDC do
the roll over of the keys would make sense.  However the KDC would be unable
to tell anybody of that decision as all of the observe relationships would
have been lost at the point so that in some respects the damage of allowing
an entity that left to continue reading messages would continue.

Does anybody have an opinion or different analysis that they would be
willing to share?

Jim