From nobody Wed Jul 7 08:27:59 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 BF2033A1BD1 for ; Wed, 7 Jul 2021 08:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 txAmzNee9JRf for ; Wed, 7 Jul 2021 08:27:53 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (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 F00593A1BD4 for ; Wed, 7 Jul 2021 08:27:52 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id k184so3690246ybf.12 for ; Wed, 07 Jul 2021 08:27:52 -0700 (PDT) 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=FktpPHgODudYB1lfBlaidqxVBqlZ2VPv2VDEAMsWcp0=; b=InJao8YeIbMfaB/Ga0lMxjAnFH26mmUw2ewki66hhw+aDPg2tvCuRaKtLl0aUgeki8 ZPCaIi1TYsRvR/nd1dxdeoXgYDfPB/Qn7wnqCIM9EajVv2y45aNPDgVRQocxqC1H56KY 2FYSRJTuYtTmJBFrIvT0pShJO3T/VSHYiucx83RL0+MUB9Nb+5VdRO8CKOcXOiQSY/Z2 zLbUpzsVrDDImr7cInk62mzW2oNTcnc0TJIfUei8qA70EFiwRfBh/8Wd7IZ+j4okIr7j 2FgwoN0p8C/thnC8cAFDUhxnyqM2axNpDCtIsAzakNIVhEfXw4KyPWzmgsWK9MMtGrAe 5qUA== X-Gm-Message-State: AOAM533ky5r8Mn0DvBGowNd72u7q0pkCJYNbcEJ0QgsfVawgB+StIRqq psrb8ljrD09R/CDen1fHy4GL1s51pV78Wti1n9U= X-Google-Smtp-Source: ABdhPJwFStM3obuAchTR18u1hnGQcJbOCZD7S7yfm8HkwZsSzwds9RwgqvwnVo34Y3Mvl4TxLx74l1kurERZ0igip9A= X-Received: by 2002:a25:dac9:: with SMTP id n192mr31819186ybf.37.1625671671699; Wed, 07 Jul 2021 08:27:51 -0700 (PDT) MIME-Version: 1.0 References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: From: Adrian Gropper Date: Wed, 7 Jul 2021 11:27:39 -0400 Message-ID: To: Fabien Imbault Cc: Thomas Hardjono , Aaron Parecki , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000835d7605c68a2eaa" 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 15:27:58 -0000 --000000000000835d7605c68a2eaa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Whatever we do in terms of scope, GNAP should not ignore this key rotation issue. Regardless of what happened in the era of TLS and IPsec, today we're seeing the limits of federated security architectures and everyone needs help in the transition to zero-trust architectures. As I understand it, we're seeing part of this as the difference between OAuth2 client credentials and GNAP. If GNAP can do or say something useful about key rotation and client credentials, then I hope we do. - Adrian On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault wrote: > That's a valid point (i.e. you might use whatever system you want, as lon= g > as you make sure your keys are managed) although one could argue we shoul= d > at the very minimum provide practical methods to ensure sufficient > security. Which means we could still provide a way native to GNAP, in cas= e > people don't have their preferred method already? > > Le mer. 7 juil. 2021 =C3=A0 16:14, Thomas Hardjono a = =C3=A9crit : > >> >> 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 leav= es >> 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 diff= erent >> 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=99re in certificate space = you have >> other options like CA=E2=80=99s and OCSP to help manage your keys at a d= ifferent >> 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 > > 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>> a =C3=A9crit : >> I do think it's important that a client instance should be able to rotat= e >> 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 actuall= y >> be rotating its keys on its own, instead the developer/administrator wou= ld >> 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 to= day. >> >> 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 coul= d >> 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, 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 >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000835d7605c68a2eaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whatever we do in terms of scope, GNAP should not ignore t= his key rotation issue.=C2=A0

Regardless of what happene= d in the era of TLS and IPsec, today we're seeing the limits of federat= ed security architectures and everyone needs help in the transition to zero= -trust architectures. As I understand it, we're seeing part of this as = the difference between OAuth2 client credentials and GNAP.=C2=A0
=
If GNAP can do or say something useful about key rotation an= d client credentials, then I hope we do.

- Adrian<= /div>

On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
That's a valid poin= t (i.e. you might use whatever system you want, as long as you make sure yo= ur keys are managed) although one could argue we should at the very minimum= provide practical methods to ensure sufficient security. Which means we co= uld still provide a way native to GNAP, in case people don't have their= preferred method already?

Le mer. 7 juil. 2021 =C3=A0 16:14, Thomas Hardjon= o <hardjono@mit.edu> a =C3=A9crit=C2=A0:
=
As much as I like the direction of GNAP, is key-rotation (i.e. key manageme= nt) 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 Jus= tin 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 sta= rt 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 ke= y 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 t= he new key, is easy: that=E2=80=99s the GNAP key proofing mechanism. The tr= ick is carrying a signed object with the key material internally somehow = =E2=80=94 is there a way to handle that consistently across different proof= ing types?

There are a bunch of ways that it could be done with different proofing mec= hanisms and that might be the right approach. HTTP Message Signatures can a= ttach multiple signatures. JWK-based-keys could use JWS to wrap the key con= tent as part of the payload (so you=E2=80=99d get something like a nested J= WT). 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 a= t a high level and each proofing mechanism or deployment has to fill that s= omehow in its definition?

Still, something in me says that we should be able to do this in one consis= tent 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 reque= st, etc. This piece, at least, I believe can be applied pretty generically.=

=C2=A0=E2=80=94 Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <fabien.imba= ult@gmail.com<mailto:fabien.imbault@gmail.com&g= t;> 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 prod= uction.

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

Fabien




Le mar. 6 juil. 2021 =C3=A0 23:29, Aaron Parecki <aaron@pareck= i.com<mailto:aaron@parecki.com>> a =C3=A9crit :<= br> I do think it's important that a client instance should be able to rota= te 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 ke= ys to the client instance, more like how typical OAuth clients work today.<= br>
Coming up with the actual rotation method is definitely an interesting chal= lenge, but there must be some prior art to draw from here. Wouldn't exi= sting specs like Mutual TLS or even PGP have some mechanism that could be r= eused?

Aaron


On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <jricher@mit.edu<= /a><mailto:jricher@mit.edu>> wrote:
In the GNAP protocol, most requests are bound to a key. There are pretty so= lid mechanisms for establishing those keys as part of the request, both dyn= amically and as 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<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000835d7605c68a2eaa--