From nobody Tue Jul 6 15:31:18 2021 Return-Path: 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 ; 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 ; 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 ; Tue, 6 Jul 2021 15:31:12 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id h6so597780iok.6 for ; 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: In-Reply-To: From: Fabien Imbault Date: Wed, 7 Jul 2021 00:30:59 +0200 Message-ID: To: Aaron Parecki Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000090a3fe05c67bfa31" Archived-At: Subject: Re: [GNAP] Key Rotation X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 22:31:17 -0000 --00000000000090a3fe05c67bfa31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0 23:29, Aaron Parecki a =C3= =A9crit : > 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 g= o > 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 tod= ay. > > 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 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, bot= h >> 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. >> >> =E2=80=A2 Access tokens are bound to keys >> =E2=80=A2 We allow rotation of the token value at client= instance >> request... >> =E2=80=A2 Should we allow rotation of the key also? >> =E2=80=A2 Grant transactions are also bound to keys >> =E2=80=A2 Specifically: the continuation access token is= bound to >> a key >> =E2=80=A2 The key is initially the client instance=E2=80= =99s key >> =E2=80=A2 Should the client be able to rotate this key s= eparately? >> =E2=80=A2 Some client instances have registered keys >> =E2=80=A2 What happens when a client=E2=80=99s registere= d 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 b= e 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? >> >> =E2=80=94 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 > --00000000000090a3fe05c67bfa31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 wh= en a certificate expires somewhere).=C2=A0

The exception is caddy server, that does it really well.= Works fine in production.=C2=A0

And then, as a proof of concept, there's DIF Keri that embeds= key rotation as a primary requirement.=C2=A0

Fabien=C2=A0




Le mar. 6 juil. 2021 =C3=A0 23:29, Aaron Pa= recki <aaron@parecki.com> a =C3=A9crit=C2=A0:
I do think it's important that a c= lient instance should be able to rotate its keys, as this is a pretty commo= n practice in other related specs.

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

<= div>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 1= 5, 2021 at 10:52 AM Justin Richer <jricher@mit.edu> wrote= :
In the GNAP pr= otocol, most requests are bound to a key. There are pretty solid mechanisms= for establishing those keys as part of the request, both dynamically and a= s part of some pre-registration step.

However, over time those keys could be rotated out by the parties that cont= rol them, and GNAP needs to be able to handle this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Access tokens are bound to keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 We allow = rotation of the token value at client instance request...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Should we= allow rotation of the key also?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Grant transactions are also bound to = keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifica= lly: the continuation access token is bound to a key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 The key i= s initially the client instance=E2=80=99s key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Should th= e client be able to rotate this key separately?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Some client instances have registered= keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 What happ= ens when a client=E2=80=99s 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 matte= r 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 oth= er methods out there, but this seems simplest.

What situations are people looking at for handling key rotation?

=C2=A0=E2=80=94 Justin
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--00000000000090a3fe05c67bfa31--