From nobody Wed Jul 7 07:20:58 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 AF2DD3A1970 for ; Wed, 7 Jul 2021 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 N-Dn0IDZ2rOG for ; Wed, 7 Jul 2021 07:20:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E6D3A1977 for ; Wed, 7 Jul 2021 07:20:50 -0700 (PDT) Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 167EKlwu003110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Jul 2021 10:20:48 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_411BF9A3-E1FC-4F01-9F94-FF0D4D6F9F9B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 7 Jul 2021 10:20:47 -0400 In-Reply-To: Cc: Fabien Imbault , GNAP Mailing List , Aaron Parecki To: Thomas Hardjono References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.7) 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: Wed, 07 Jul 2021 14:20:56 -0000 --Apple-Mail=_411BF9A3-E1FC-4F01-9F94-FF0D4D6F9F9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My take as an individual: Keys are so intrinsic to GNAP=E2=80=99s architecture, for both client = instances and tokens, I argue we=E2=80=99d be amiss to not mention their = management over time, which would include rotation. There=E2=80=99s = nothing in the spec right now except that it=E2=80=99s allowed to happen = (ie, =E2=80=9Cthe client instance=E2=80=99s key or its most current = rotation=E2=80=9D), and this discussion is to raise exactly how much we = ought to specify that throughout GNAP. I think Aaron=E2=80=99s point is an important one though: if you have a = key management scheme in place, you should be able to just use that = as-is without GNAP knowing anything about it at the protocol level. What = we=E2=80=99re talking about is an in-protocol dynamic way to manage the = associated keys. =E2=80=94 Justin > On Jul 7, 2021, at 10:14 AM, Thomas Hardjono wrote: >=20 >=20 > As much as I like the direction of GNAP, is key-rotation (i.e. key = management) even part of the GNAP charter?=20 >=20 > Key-rotation is a common problem for everyone, starting from the early = days of IPsec/IKE. >=20 > Best >=20 > --thomas >=20 >=20 > ________________________________________ > From: TXAuth [txauth-bounces@ietf.org = ] on behalf of Justin Richer = [jricher@mit.edu ] > Sent: Wednesday, July 7, 2021 9:57 AM > To: Fabien Imbault > Cc: GNAP Mailing List; Aaron Parecki > Subject: Re: [GNAP] Key Rotation >=20 > Aaron, that=E2=80=99s 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? >=20 > 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=E2=80=99s the GNAP = key proofing mechanism. The trick is carrying a signed object with the = key material internally somehow =E2=80=94 is there a way to handle that = consistently across different proofing types? >=20 > 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=E2=80=99d get = something like a nested JWT). MTLS is a strange one, but if you=E2=80=99re= in certificate space you have other options like CA=E2=80=99s 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? >=20 > Still, something in me says that we should be able to do this in one = consistent pattern, and I=E2=80=99d 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. >=20 > =E2=80=94 Justin >=20 > On Jul 6, 2021, at 6:30 PM, Fabien Imbault >> wrote: >=20 > Hi there, >=20 > 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). >=20 > The exception is caddy server, that does it really well. Works fine in = production. >=20 > And then, as a proof of concept, there's DIF Keri that embeds key = rotation as a primary requirement. >=20 > Fabien >=20 >=20 >=20 >=20 > 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. >=20 > 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. >=20 > 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? >=20 > Aaron >=20 >=20 > 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, both dynamically and as part of some pre-registration step. >=20 > However, over time those keys could be rotated out by the parties that = control them, and GNAP needs to be able to handle this. >=20 > =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=99= s key > =E2=80=A2 Should the client be able to rotate this key = separately? > =E2=80=A2 Some client instances have registered keys > =E2=80=A2 What happens when a client=E2=80=99s = registered key rotates? >=20 >=20 > 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. >=20 > What situations are people looking at for handling key rotation? >=20 > =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 = --Apple-Mail=_411BF9A3-E1FC-4F01-9F94-FF0D4D6F9F9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = take as an individual:

Keys are so intrinsic to GNAP=E2=80=99s architecture, for = both client instances and tokens, I argue we=E2=80=99d be amiss to not = mention their management over time, which would include rotation. = There=E2=80=99s nothing in the spec right now except that it=E2=80=99s = allowed to happen (ie, =E2=80=9Cthe client instance=E2=80=99s key or its = most current rotation=E2=80=9D), and this discussion is to raise exactly = how much we ought to specify that throughout GNAP.

I think Aaron=E2=80=99s = point is an important one though: if you have a key management scheme in = place, you should be able to just use that as-is without GNAP knowing = anything about it at the protocol level. What we=E2=80=99re talking = about is an in-protocol dynamic way to manage the associated keys.

 =E2=80= =94 Justin

On Jul 7, 2021, at 10:14 AM, Thomas Hardjono = <hardjono@mit.edu> wrote:


As much as I like the direction = of GNAP, is key-rotation (i.e. key management) even part of the GNAP = charter? 

Key-rotation is a common problem = for everyone, starting from the early days of IPsec/IKE.

Best

--thomas


________________________________________
From: TXAuth [txauth-bounces@ietf.org] on behalf of Justin Richer [jricher@mit.edu]
Sent: Wednesday, July 7, 2021 9:57 AM
To: Fabien Imbault
Cc: GNAP Mailing List; Aaron = Parecki
Subject: Re: = [GNAP] Key Rotation

Aaron, that=E2=80=99s 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=E2=80=99s the GNAP key proofing mechanism. The = trick is carrying a signed object with the key material internally = somehow =E2=80=94 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=E2=80=99d = get something like a nested JWT). MTLS is a strange one, but if you=E2=80=99= re in certificate space you have other options like CA=E2=80=99s 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=E2=80=99d 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.

=E2=80=94 = Justin

On Jul 6, = 2021, at 6:30 PM, Fabien Imbault <fabien.imbault@gmail.com<mailto: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 =C3=A0 23:29, Aaron Parecki = <aaron@parecki.com<mailto:aaron@parecki.com>> 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 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<mailto: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.

       =E2=80=A2 Access = tokens are bound to keys
          &nb= sp;    =E2=80=A2 We allow rotation of the token = value at client instance request...
          &nb= sp;    =E2=80=A2 Should we allow rotation of the key = also?
       =E2=80=A2 Grant = transactions are also bound to keys
          &nb= sp;    =E2=80=A2 Specifically: the continuation = access token is bound to a key
          &nb= sp;    =E2=80=A2 The key is initially the client = instance=E2=80=99s key
          &nb= sp;    =E2=80=A2 Should the client be able to rotate = this key separately?
       =E2=80=A2 Some = client instances have registered keys
          &nb= sp;    =E2=80=A2 What happens 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 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<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_411BF9A3-E1FC-4F01-9F94-FF0D4D6F9F9B--