Re: [GNAP] Key Rotation

Fabien Imbault <fabien.imbault@gmail.com> Tue, 06 July 2021 22:31 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 1BF2D3A1866 for <txauth@ietfa.amsl.com>; Tue, 6 Jul 2021 15:31:17 -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 LEn6PBDvBl2i for <txauth@ietfa.amsl.com>; Tue, 6 Jul 2021 15:31:12 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4E9A33A1864 for <txauth@ietf.org>; Tue, 6 Jul 2021 15:31:12 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id h6so597780iok.6 for <txauth@ietf.org>; Tue, 06 Jul 2021 15:31:12 -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=htOdzIC5ZhV8JYDSvBvHbls48Ny2ppbs1YNYL8IWYkc=; b=n8RGm5Ka8wczdyO/hlIoDkkTyFaNfeJzBdPGv13zX3S388rKloRQ7Y2zOjTDzO/2N8 sfxfTr3d5o6+E+f/46xQH7diQVYA2lVadoR14xYgzX06vhVHWgAeOhDDF6CiDn5XVG4Q C/8MsSNZaebFIy984igoAYphSCNYWjKQvPqp+kxjx0CLX+mIscD+sImmee17vpXNrFye PJmg5QcKIkZU/Z84s61J3RUIo3os5j+CtrXAYfgaJAE9fTcbZ1d98CZA8BolNKBZdkTz aHgGppTr2cN22tdwj/I9pdKmjmMLNj/uunv0mGRa7P9k9OZhzGqhiFIweZ7GReJ+7N1q AjAQ==
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=htOdzIC5ZhV8JYDSvBvHbls48Ny2ppbs1YNYL8IWYkc=; b=YxgJFxlIMDXQXr8BDeg4P0cbE+NkbmHsiJD+OLfjewaW+B2WMFDBj17m1pIaeK55co orCqk+WXnzzA3P+Ih0NOH0XCNeCetLvp6wsBkS2Gls6SevVsz344W8V1TvNTwZVZ/yGy 5YZtGgAbCW4/+3BOa8S//JkTwqa0QNdritVotqZC0JmdNy1WcZhxuQRosTdmdtVSfBl1 FkrQJyTHVtckhx1ICKyofHhMkJ7ykjhzzNckBXqxhKVaaNTEdX9YW4j+JyXJPIR/1RrF DCoit+SkEYgTMDgOGlg5LUehlA8CK/Ne2duVp6fbCVctLyfARfSdrHotRsJL8Dl5bUR7 R+KA==
X-Gm-Message-State: AOAM533YUkdeyqFS1LICYwDY+1ilWeqgY8zIjfTBmog0XB+CBKn7NLLJ pmu/yQDMLyHkgdu5+lRBJAoEhUs+GMzmHd16ww6q8xrp
X-Google-Smtp-Source: ABdhPJzHGOjlckamepqtofdXm0jrmQcS9FVfwIREa0sesPzBU1PxJGMgVYiPWdQ69cQLaYMGH9QVWt5/unhDFmB4cVQ=
X-Received: by 2002:a5e:de06:: with SMTP id e6mr3673230iok.74.1625610670611; Tue, 06 Jul 2021 15:31:10 -0700 (PDT)
MIME-Version: 1.0
References: <B72A80C0-0579-43F8-9B83-0932C98EB314@mit.edu> <CAGBSGjpzW01d9ym+r6oeSZUd9YjZsg_vmyME+ffJNd8rPaZANw@mail.gmail.com>
In-Reply-To: <CAGBSGjpzW01d9ym+r6oeSZUd9YjZsg_vmyME+ffJNd8rPaZANw@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 07 Jul 2021 00:30:59 +0200
Message-ID: <CAM8feuTUDpEUkKkN9DQC6doqeqKKOpaS1KS3+PUF99R1MzGUZw@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Cc: Justin Richer <jricher@mit.edu>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000090a3fe05c67bfa31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/TObI1klVEdwNwZC2UGdPZ1YXpvQ>
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 22:31:17 -0000

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
>