Re: [GNAP] Key Rotation

Aaron Parecki <aaron@parecki.com> Tue, 06 July 2021 21:29 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC763A128B for <txauth@ietfa.amsl.com>; Tue, 6 Jul 2021 14:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
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 YhJjsU-9SM3k for <txauth@ietfa.amsl.com>; Tue, 6 Jul 2021 14:28:57 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7D43A1288 for <txauth@ietf.org>; Tue, 6 Jul 2021 14:28:56 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id a11so285583ilf.2 for <txauth@ietf.org>; Tue, 06 Jul 2021 14:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfuDtFE5ZdqCPNe6f2WhZIoGcgN5YBZitsRuuphs/uU=; b=iZbnzWGuTAKAFvCyc3anZ+iPNsteaknJF+4Nk8n8gVD7GvLA4ipzQfg6BBsmGD3rSA Mu9nvg2ItI4MhRs90bHjynO9DSBMvhu7Ii3mz82uoGrEUDQHM79esEBmvlCbHAn4m0uY ondFLPkhMu2XZP6zdkxO1HAl2anXdXJZ8S/LupGW8VutSn87I3aJUE3o1YURLEEkfrGJ UOzQ8mhmxQC5wo69pHHom9LsWjnhO/X2v/yTen5GsLiCzGq+8qGs4CerTh3wdbmvtclK 2RCpG3n8XFx+i4ADXY0bmjzYqJNT+5nrlUFIDmYwkAzcYyEsin0/jEnpng7CaRoHRygb 1DfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cfuDtFE5ZdqCPNe6f2WhZIoGcgN5YBZitsRuuphs/uU=; b=YDeUMdGOuDGUrGjIQiYz1wd6489fdN1myn4p4HdnOfUVdJ41Z+uMV4hfExitwOYdeL AwZxsc4Y32+E6gm8gF9Ds6DQbUITUk7R16mes52kXXRaypKZ5z2V1uL3+1Dtg2u3Bl09 jjGgdudbFl5WdEWCm+am1qKHt+2Fzti0z3ebvKLPrHjdmP0aGsrc+BAgtMC99BZ9MzkM srOSkbbBwkw/5xydnnft6H8K2fOAx+7p2cyeJM8uWBw7xc7EJaw26TjZytOyx+s5XyJT 4kw7KxAG/R8ceJc3vaxR9dqB3pY6xBT5XVhVuSY01VgmeEMxmK2VM9Z144MaPEif8itQ yEhg==
X-Gm-Message-State: AOAM532IYx5QdwQw9t9tC1Ae3WWQ62sN6tCskIAgdXzDjyD2oyKSWvnZ iHKUXkFUDhC/4nv6jANLXvM9eerlkyZx5g==
X-Google-Smtp-Source: ABdhPJxJEYSGhCQvjO56FJ75k42A+bgflSV8wSo6wMIUbSPEYLAWrVOv8CY9UNCh5+f1nScD+oHDzQ==
X-Received: by 2002:a92:6610:: with SMTP id a16mr15569226ilc.124.1625606935044; Tue, 06 Jul 2021 14:28:55 -0700 (PDT)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id e14sm8621560ilc.47.2021.07.06.14.28.54 for <txauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 14:28:54 -0700 (PDT)
Received: by mail-io1-f47.google.com with SMTP id y8so378200iop.13 for <txauth@ietf.org>; Tue, 06 Jul 2021 14:28:54 -0700 (PDT)
X-Received: by 2002:a02:866b:: with SMTP id e98mr18980701jai.48.1625606933977; Tue, 06 Jul 2021 14:28:53 -0700 (PDT)
MIME-Version: 1.0
References: <B72A80C0-0579-43F8-9B83-0932C98EB314@mit.edu>
In-Reply-To: <B72A80C0-0579-43F8-9B83-0932C98EB314@mit.edu>
From: Aaron Parecki <aaron@parecki.com>
Date: Tue, 06 Jul 2021 14:28:43 -0700
X-Gmail-Original-Message-ID: <CAGBSGjpzW01d9ym+r6oeSZUd9YjZsg_vmyME+ffJNd8rPaZANw@mail.gmail.com>
Message-ID: <CAGBSGjpzW01d9ym+r6oeSZUd9YjZsg_vmyME+ffJNd8rPaZANw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8234e05c67b1b2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/6VRkYEyreZSXfO7vNAhOpd24Jl8>
Subject: Re: [GNAP] Key Rotation
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2021 21:29:02 -0000

I do think it's important that a client instance should be able to rotate
its keys, as this is a pretty common practice in other related specs.

You mentioned pre-registered clients which I think is an interesting case.
I would expect in those cases the client instance wouldn't actually be
rotating its keys on its own, instead the developer/administrator would go
into the management console to rotate the keys there, and deploy the new
keys to the client instance, more like how typical OAuth clients work today.

Coming up with the actual rotation method is definitely an interesting
challenge, but there must be some prior art to draw from here. Wouldn't
existing specs like Mutual TLS or even PGP have some mechanism that could
be reused?

Aaron


On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <jricher@mit.edu> wrote:

> In the GNAP protocol, most requests are bound to a key. There are pretty
> solid mechanisms for establishing those keys as part of the request, both
> dynamically and as part of some pre-registration step.
>
> However, over time those keys could be rotated out by the parties that
> control them, and GNAP needs to be able to handle this.
>
>         • Access tokens are bound to keys
>                 • We allow rotation of the token value at client instance
> request...
>                 • Should we allow rotation of the key also?
>         • Grant transactions are also bound to keys
>                 • Specifically: the continuation access token is bound to
> a key
>                 • The key is initially the client instance’s key
>                 • Should the client be able to rotate this key separately?
>         • Some client instances have registered keys
>                 • What happens when a client’s registered key rotates?
>
>
> Secure rotation of a key would require some way for the presenter to prove
> possession of both the old and new keys simultaneously. It could be a
> matter of signing the request with the new key and include some artifact
> signed by the old key in the request, or the inverse of that. There are
> likely other methods out there, but this seems simplest.
>
> What situations are people looking at for handling key rotation?
>
>  — Justin
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>