Re: [GNAP] Key Rotation

Fabien Imbault <fabien.imbault@gmail.com> Wed, 07 July 2021 14:10 UTC

Return-Path: <fabien.imbault@gmail.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 3EDE33A191F for <txauth@ietfa.amsl.com>; Wed, 7 Jul 2021 07:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 Bvd9ZII_Ovej for <txauth@ietfa.amsl.com>; Wed, 7 Jul 2021 07:10:47 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 7EEEC3A191E for <txauth@ietf.org>; Wed, 7 Jul 2021 07:10:47 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id a6so3685399ioe.0 for <txauth@ietf.org>; Wed, 07 Jul 2021 07:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEugg1OpzZOFDRTPSY0iEEVwkSqx7vVU02ZS720DXU4=; b=hRMSEgiFkpjGBW26Af2uBAoTBc5JKT+RmTLt3AaLxPQ7S3A8DhgTuiUk+ebkN5V+yz cx4cDjYLsQqhcSbnc1pU1AXKBUBEjvCbIpY5E1o1CUglCEePrAGpXrdYalLPXfPQ2x3g q4Q4bgxZ/eB57LouD1pQULvrkSgtQFJKetp2Bi3I8H2x0hZgNgrRYIG5U2GIKDPITvzx a7daSl2M9pmcVcfZJRzrPqw7bkJpTJn4FsvwiXwKkcBZVL0ySsKGAGAqyyHXqbE3XGNG GO//ZvlDP2MwRL1G93PRw9xcYC3/922qobQGhnEPS9Fc5TWx3MMVzrl99lGG3S/S+hWD BsdA==
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=cEugg1OpzZOFDRTPSY0iEEVwkSqx7vVU02ZS720DXU4=; b=lXiQ6mBFOGxqTZDB7Brx0QFssWvxcViU/DdsDurlfwBlehIg4V2YQ+Hxug6tIouX0l Ai2qp9kzTfmd5WQFfW9u03epl8kdppQd8u/UB28RyHmpz6a1NIiNBD1Di9aKb2ooNgbO zUU4j46WZfe0TSgLD8sWS4FUQHaFvbCzWikOjE5pYJEYpom7A7VPM8gEVvuAPLJYF1Xy mOfAh8tZPAbLOEd+4lxoH9uQHni2F2tYlYADRePTALL3mkIFgvfYi18uffrTw+39lXIJ hdpN/WbIyicrKil5CLp+hVOB7UTmSWFct/GifjvVtHLMd1bNajA2sYBoKCTzwEzE56Eh Rydg==
X-Gm-Message-State: AOAM531+e+KEfKZCatlzDuUPaBnnI8pm5f6T7H0z65AvDQuwEPHdqq2g RWmOsgZhcvf9EsOpl1LZoQxLuUJKFB12fpywKOA=
X-Google-Smtp-Source: ABdhPJwUL3qEKDx8XeXri40UhUnTnnU4X8SUMVMO1gf5oyDV9c7Fko8A6/Oa+u1v4vdveyHu5NC1itz/7FYtF31qcfc=
X-Received: by 2002:a05:6638:bc5:: with SMTP id g5mr10062853jad.47.1625667045027; Wed, 07 Jul 2021 07:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <B72A80C0-0579-43F8-9B83-0932C98EB314@mit.edu> <CAGBSGjpzW01d9ym+r6oeSZUd9YjZsg_vmyME+ffJNd8rPaZANw@mail.gmail.com> <CAM8feuTUDpEUkKkN9DQC6doqeqKKOpaS1KS3+PUF99R1MzGUZw@mail.gmail.com> <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu>
In-Reply-To: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 07 Jul 2021 16:10:33 +0200
Message-ID: <CAM8feuQ3wNZf-9J1GggAA2QRcwhrgSvuKqOqzgmWTrHtaiwLFg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Aaron Parecki <aaron@parecki.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bdf20705c6891a9b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/Wq1LtfPRy1dnfMgChXryddoHbgA>
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: Wed, 07 Jul 2021 14:10:52 -0000

Hi Justin,

I suggest
https://github.com/decentralized-identity/keri/blob/master/kids/kid0005.md
as a potential method (at least for discussion on a pre-rotation scheme).

Fabien


Le mer. 7 juil. 2021 à 15:57, Justin Richer <jricher@mit.edu> a écrit :

> Aaron, that’s a great point about static registration. That leaves
> ephemeral or otherwise runtime keys, which might be good enough to just
> start a new request when needed?
>
> Ben had previously posited a functional approach like sign(k2, sign(k1,
> (k2))): you use the old key (k1) to sign the new key (k2), then use the new
> key to sign that signature and present it. The thing that I get hung up on
> is having a way to do the key proofing for a new key that works
> consistently for all the different key types in use. The outer signature,
> signing with the new key, is easy: that’s the GNAP key proofing mechanism.
> The trick is carrying a signed object with the key material internally
> somehow — is there a way to handle that consistently across different
> proofing types?
>
> There are a bunch of ways that it could be done with different proofing
> mechanisms and that might be the right approach. HTTP Message Signatures
> can attach multiple signatures. JWK-based-keys could use JWS to wrap the
> key content as part of the payload (so you’d get something like a nested
> JWT). MTLS is a strange one, but if you’re in certificate space you have
> other options like CA’s and OCSP to help manage your keys at a different
> level. So maybe GNAP just specifies the functional requirement at a high
> level and each proofing mechanism or deployment has to fill that somehow in
> its definition?
>
> Still, something in me says that we should be able to do this in one
> consistent pattern, and I’d love to hear more ideas on how that could be
> handled. If we can crack that, then it becomes a matter of applying that to
> a bunch of different requests: grant update, token rotation, initial
> request, etc. This piece, at least, I believe can be applied pretty
> generically.
>
>  — Justin
>
> On Jul 6, 2021, at 6:30 PM, Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
> Hi there,
>
> As far as I know, key rotation remains a cumbersome process in most cases,
> to say the least. It's quite impressive how often that breaks (usually when
> a certificate expires somewhere).
>
> The exception is caddy server, that does it really well. Works fine in
> production.
>
> And then, as a proof of concept, there's DIF Keri that embeds key rotation
> as a primary requirement.
>
> Fabien
>
>
>
>
> Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <aaron@parecki.com> a écrit :
>
>> 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
>>>
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>