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 >> > >
- [GNAP] Key Rotation Justin Richer
- Re: [GNAP] Key Rotation Aaron Parecki
- Re: [GNAP] Key Rotation Fabien Imbault
- Re: [GNAP] Key Rotation Justin Richer
- Re: [GNAP] Key Rotation Fabien Imbault
- Re: [GNAP] Key Rotation Thomas Hardjono
- Re: [GNAP] Key Rotation Justin Richer
- Re: [GNAP] Key Rotation Justin Richer
- Re: [GNAP] Key Rotation Thomas Hardjono
- Re: [GNAP] Key Rotation Fabien Imbault
- Re: [GNAP] Key Rotation Adrian Gropper
- Re: [GNAP] Key Rotation Yaron Sheffer
- Re: [GNAP] Key Rotation Thomas Hardjono
- Re: [GNAP] Key Rotation Andrii Deinega
- Re: [GNAP] Key Rotation Fabien Imbault
- Re: [GNAP] Key Rotation Thomas Hardjono