[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, 04 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