From nobody Fri Jul 2 15:06:23 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 855AE3A0AC8; Fri, 2 Jul 2021 15:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337953.26814.9078477587918505504@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:59 -0700 Archived-At: Subject: [GNAP] gnap - Requested session has been scheduled for IETF 111 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:11 -0000 Dear Yaron Sheffer, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gnap Session 1 (2:00 requested) Monday, 26 July 2021, Session I 1200-1400 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/gnap.ics Request Information: --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: People who must be present: Leif Johansson Roman Danyliw Yaron Sheffer Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jul 5 08:20:51 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 6D4FA3A1B45 for ; Mon, 5 Jul 2021 08:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 NuEVLrSaVebU for ; Mon, 5 Jul 2021 08:20:44 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 1A63F3A1B48 for ; Mon, 5 Jul 2021 08:20:43 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id a6so21393807ioe.0 for ; Mon, 05 Jul 2021 08:20:43 -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=Z6jhJhBtgp/bJOTZTF04SOr0Ykonb+WnexLtQ0Gwg7M=; b=G5US0xr6Hnq4ZJ946sjp/+UwnDA4cAE+PXxWTjcRWX0F6nrav8HbtRrkc0qrXYpQAI nlP2d+1/ej2QodX0gKvxMSJt3CKK+0yMbz1c8uPcjGlAJk6zKZVpHlP1bEH1sexteeHq 2W9CRzNDqo83aVMEHAqypfxEgi3OuUlXJh/qbyy+EALW6lIhR+0Pz643w0jg+mRtBJCs UT7m2SGGIs3J7YqHXaaENhRf9UHnyqYBfvszRbc9aSNDVCKzWopDfmjnpBzSViMYAn+F r2vx0Ckf3JG653v1XSfgushNWcOtOXDdouFKAUB1D/WE+Q+VvU88CWQsOei4rJ+rctcB iUWQ== 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=Z6jhJhBtgp/bJOTZTF04SOr0Ykonb+WnexLtQ0Gwg7M=; b=cxR3wH2HsGOomrG7nN4X23B592MVApx9yeIANax3OTItqtZwIL8KKYSqnFNEiNRDGx 6MBk0WLiupImtl+tdxAkTp7+MKWcdA9AOh566tPH0h4Ddlh8SXaG6gZ/9rSvX//XvRYW Q2nrW1v13bbKik1d/BZX8qPVEc6uuMxJuq2gBk/RvJfN97eB+NHFqO1v6ooxauDwUXsj 2Yf994guiWhHorSDoBDfgfDguvFlqoLZ+iU618OCsTawBIvzx2g39lr2mYUTraVtLk+3 L5910vGtP5f8+6B5LeeFER2LOr+osIudteu9bEtQ5YZTuq7jpIzoF5cLPtfGGv3qGYDI AylA== X-Gm-Message-State: AOAM531xqz8D8Y5w2ji8TiNn7xdJMeoq76C3JfUHxpnk0x1EEoNjnmLH 13fAnxnFOZ29jX2eZE74wkwPCsR8LZevyok71l8= X-Google-Smtp-Source: ABdhPJxOgfGTQttXrnthZydzGWKMim6FPgfcXQIRiK3WcWlqXlgmI3Ez9P0suFKAakTae4c8Md2dLWzwwYfAH1whgeA= X-Received: by 2002:a05:6638:3789:: with SMTP id w9mr12706703jal.77.1625498442455; Mon, 05 Jul 2021 08:20:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 5 Jul 2021 17:20:31 +0200 Message-ID: To: Dave Tonge Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003edd0905c661d944" Archived-At: Subject: Re: [GNAP] Signature Methods 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: Mon, 05 Jul 2021 15:20:50 -0000 --0000000000003edd0905c661d944 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I've created the 2 PRs to remove DPoP ( https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271) and PoP ( https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272). I personally would also favor removing JWS detached and attached. My rationale for that : - not everyone likes JOSE, so not having a strong dependency opens to a wider community - we can still support those cases as extensions, if it makes the transition from oauth easier On top of that, Dave's arguments for simplification make very good sense. The main downside of having only HTTP signatures is that it is fairly new, so the adoption requires the ecosystem to catch up (not sure what's the issue with its aesthetics, could you explain further?). But in general, it's quite nice I think. Fabien On Mon, Jun 21, 2021 at 11:03 PM Dave Tonge wrote= : > I'm definitely in favour of simplification. > > Mutual TLS is an interesting one. I would prefer that it isn't included i= n > core as it mixes the transport and application layers and in my experienc= e > is fairly brittle (not the spec, but how it is implemented in a lot of > places). > > Purely in terms of aesthetics, I don't like the http signatures spec, but > if it is going to become mainstream then it makes sense to make it the > primary signing mechanism. As you mentioned the good thing about it is th= at > it can work for all HTTP requests, and can also be used for signing > responses. > > I think some work will need to be done to get the http signature spec > supported by standard HTTP client libraries in popular languages. This wi= ll > make it a lot easier for implementers (i.e. I can call > > ``` > myHttpClientLibary.post({ > body: {...}, > uri: "https://example.com/continue", > sign: { > key: {} // reference to key to use to sign, > digest: "SHA-256" > additionalHeaders: ["authorization", "content-type"] > } > }) > ``` > > So my suggestion would be to only have the http signature spec in core. > > GNAP is a new protocol - I see no need to add unnecessary optionality. > > Dave > > > > On Tue, 15 Jun 2021 at 19:50, Justin Richer wrote: > >> In GNAP, most requests are signed in some way, or at least bound to a ke= y >> being presented or referenced with the request. This is true for >> connections from the client instance to the AS and to the RS, as well as >> introspection requests from the RS to the AS. GNAP has always sought to = be >> flexible with regard to cryptographic binding mechanisms, but there=E2= =80=99s a >> question as to what should remain defined in the core document. Right no= w, >> core has six methods defined. The editors are proposing that we keep at >> least two and drop two, and the others could either both be kept, both b= e >> dropped, or one kept. The rationale for each proposal is discussed below= : >> >> Proposed to keep: >> >> - HTTP Method Signatures: general purpose mechanism, being defined in >> HTTP WG. Can be bound to symmetric and asymmetric keys. Usable for nativ= e, >> web, and SPA clients. Suggested MTI for the AS (but not mandatory to use= ) >> for interoperability. Side note, possible use for AS to sign responses (= but >> not explored here yet =E2=80=94 that=E2=80=99s another topic). >> >> - Mutual TLS: based on OAuth MTLS, ties the keys at the TLS layer to the >> application protocol (GNAP). >> >> >> Proposed to drop: >> >> - OAuth PoP: expired draft, due to be replaced with new draft based on >> HTTP Message Signatures. >> >> - OAuth DPoP: only works for asymmetric keys, requires key be presented >> in the header (duplicating information from GNAP messages). It was never >> meant to be a general purpose signing mechanism, though the FAPI group i= n >> OIDF is considering it as an option in current proposed work. >> >> >> This leaves the two JWS based methods, detached and attached. Since >> attached JWS depends on the detached JWS method to handle body-less >> requests like GET, DELETE, OPTIONS, etc., if we remove the detached meth= od >> then we have to remove both. The methods could be pulled to an extension= , >> left in core, or removed entirely. >> >> The editors would appreciate feedback on this proposal, including >> specific feedback on the JWS methods from implementors who are targeting >> them. >> >> >> =E2=80=94 Justin >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003edd0905c661d944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0





On Mon, Jun = 21, 2021 at 11:03 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I'm definitely = in favour of simplification.

Mutual = TLS is an interesting one. I would prefer that it isn't included in cor= e as it mixes the transport and application layers and in my experience is = fairly brittle (not the spec, but how it is implemented in a lot of places)= .

Purely in terms of aesthetics, I d= on't like the http signatures spec, but if it is going to become mainst= ream then it makes sense to make it the primary signing mechanism. As you m= entioned the good thing about it is that it can work for all HTTP requests,= and can also be used for signing responses.

I think some work will need to be done to get the http signatu= re spec supported by standard HTTP client libraries in popular=C2=A0languag= es. This will make it a lot easier for implementers (i.e. I can call=C2=A0<= /div>

```
myHttpClientLib= ary.post({
=C2=A0 body: {...},
=C2=A0 uri= : "https://= example.com/continue",
=C2=A0 sign: {
=C2=A0 =C2=A0 key: {} // reference to key to use to sign,
=C2=A0 =C2=A0 digest: "SHA-256"
=C2=A0 =C2= =A0 additionalHeaders: ["authorization", "content-type"= ]
=C2=A0 }
})
```

So my suggestion would be to only have= the http signature spec in core.


Dave

=


On Tue, 15 Jun 2021 at 19:50, Justin Richer <jricher@mit.edu> wro= te:
In GNAP, mos= t requests are signed in some way, or at least bound to a key being present= ed or referenced with the request. This is true for connections from the cl= ient instance to the AS and to the RS, as well as introspection requests fr= om the RS to the AS. GNAP has always sought to be flexible with regard to c= ryptographic binding mechanisms, but there=E2=80=99s a question as to what = should remain defined in the core document. Right now, core has six methods= defined. The editors are proposing that we keep at least two and drop two,= and the others could either both be kept, both be dropped, or one kept. Th= e rationale for each proposal is discussed below:

Proposed to keep:

- HTTP Method Signatures: general purpose mechanism, being defined in HTTP = WG. Can be bound to symmetric and asymmetric keys. Usable for native, web, = and SPA clients. Suggested MTI for the AS (but not mandatory to use) for in= teroperability. Side note, possible use for AS to sign responses (but not e= xplored here yet =E2=80=94 that=E2=80=99s another topic).

- Mutual TLS: based on OAuth MTLS, ties the keys at the TLS layer to the ap= plication protocol (GNAP).


Proposed to drop:

- OAuth PoP: expired draft, due to be replaced with new draft based on HTTP= Message Signatures.

- OAuth DPoP: only works for asymmetric keys, requires key be presented in = the header (duplicating information from GNAP messages). It was never meant= to be a general purpose signing mechanism, though the FAPI group in OIDF i= s considering it as an option in current proposed work.


This leaves the two JWS based methods, detached and attached. Since attache= d JWS depends on the detached JWS method to handle body-less requests like = GET, DELETE, OPTIONS, etc., if we remove the detached method then we have t= o remove both. The methods could be pulled to an extension, left in core, o= r removed entirely.

The editors would appreciate feedback on this proposal, including specific = feedback on the JWS methods from implementors who are targeting them.


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


--
Dave Tonge
CTO
3D"Moneyhub
t:=C2=A0+44 (0)117 280 5120

Moneyhub Enterprise is a= trading style of Moneyhub Financial Technology Limited which is authorised= and regulated by the Financial Conduct Authority ("FCA").=C2=A0M= oneyhub Financial Technology is entered on the Financial Services Register= =C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Moneyhub=C2=A0Financ= ial Technology is registered in England & Wales, company registration n= umber=C2=A0=C2=A0069097= 72=C2=A0.
Moneyhub=C2=A0Financial Technology Limited 2= 019=C2=A0=C2=A9

D= ISCLAIMER: This email (including any attachments) is subject to copyright, = and the information in it is confidential. Use of this email or of any info= rmation in it other than by the addressee is unauthorised and unlawful. Whi= lst reasonable efforts are made to ensure that any attachments are virus-fr= ee, it is the recipient's sole responsibility to scan all attachments f= or viruses. All calls and emails to and from this company may be monitored = and recorded for legitimate purposes relating to this company's busines= s. Any opinions expressed in this email (or in any attachments) are those o= f the author and do not necessarily represent the opinions of Moneyhub Fina= ncial Technology Limited or of any other group company.
<= /div>

Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000003edd0905c661d944-- From nobody Tue Jul 6 14:29:04 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 1BC763A128B for ; Tue, 6 Jul 2021 14:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki.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 YhJjsU-9SM3k for ; Tue, 6 Jul 2021 14:28:57 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 4A7D43A1288 for ; Tue, 6 Jul 2021 14:28:56 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id a11so285583ilf.2 for ; Tue, 06 Jul 2021 14:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfuDtFE5ZdqCPNe6f2WhZIoGcgN5YBZitsRuuphs/uU=; b=iZbnzWGuTAKAFvCyc3anZ+iPNsteaknJF+4Nk8n8gVD7GvLA4ipzQfg6BBsmGD3rSA Mu9nvg2ItI4MhRs90bHjynO9DSBMvhu7Ii3mz82uoGrEUDQHM79esEBmvlCbHAn4m0uY ondFLPkhMu2XZP6zdkxO1HAl2anXdXJZ8S/LupGW8VutSn87I3aJUE3o1YURLEEkfrGJ UOzQ8mhmxQC5wo69pHHom9LsWjnhO/X2v/yTen5GsLiCzGq+8qGs4CerTh3wdbmvtclK 2RCpG3n8XFx+i4ADXY0bmjzYqJNT+5nrlUFIDmYwkAzcYyEsin0/jEnpng7CaRoHRygb 1DfA== 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=cfuDtFE5ZdqCPNe6f2WhZIoGcgN5YBZitsRuuphs/uU=; b=YDeUMdGOuDGUrGjIQiYz1wd6489fdN1myn4p4HdnOfUVdJ41Z+uMV4hfExitwOYdeL AwZxsc4Y32+E6gm8gF9Ds6DQbUITUk7R16mes52kXXRaypKZ5z2V1uL3+1Dtg2u3Bl09 jjGgdudbFl5WdEWCm+am1qKHt+2Fzti0z3ebvKLPrHjdmP0aGsrc+BAgtMC99BZ9MzkM srOSkbbBwkw/5xydnnft6H8K2fOAx+7p2cyeJM8uWBw7xc7EJaw26TjZytOyx+s5XyJT 4kw7KxAG/R8ceJc3vaxR9dqB3pY6xBT5XVhVuSY01VgmeEMxmK2VM9Z144MaPEif8itQ yEhg== X-Gm-Message-State: AOAM532IYx5QdwQw9t9tC1Ae3WWQ62sN6tCskIAgdXzDjyD2oyKSWvnZ iHKUXkFUDhC/4nv6jANLXvM9eerlkyZx5g== X-Google-Smtp-Source: ABdhPJxJEYSGhCQvjO56FJ75k42A+bgflSV8wSo6wMIUbSPEYLAWrVOv8CY9UNCh5+f1nScD+oHDzQ== X-Received: by 2002:a92:6610:: with SMTP id a16mr15569226ilc.124.1625606935044; Tue, 06 Jul 2021 14:28:55 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id e14sm8621560ilc.47.2021.07.06.14.28.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 14:28:54 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id y8so378200iop.13 for ; Tue, 06 Jul 2021 14:28:54 -0700 (PDT) X-Received: by 2002:a02:866b:: with SMTP id e98mr18980701jai.48.1625606933977; Tue, 06 Jul 2021 14:28:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 6 Jul 2021 14:28:43 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d8234e05c67b1b2a" 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 21:29:02 -0000 --000000000000d8234e05c67b1b2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > =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 se= parately? > =E2=80=A2 Some client instances have registered keys > =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 prov= e > 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 > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d8234e05c67b1b2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do think it's important that a client instance shoul= d be able to rotate its keys, as this is a pretty common practice in other = related specs.

You mentioned pre-registered clients whic= h 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 t= he 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 mec= hanisms for establishing those keys as part of the request, both dynamicall= y 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 https://www.ietf.org/mailman/listinfo/txauth
--000000000000d8234e05c67b1b2a-- 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-- From nobody Wed Jul 7 06:58:05 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 7B0713A18B2 for ; Wed, 7 Jul 2021 06:58:03 -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 hVD7ckmfRPuE for ; Wed, 7 Jul 2021 06:57:59 -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 CA4903A18AF for ; Wed, 7 Jul 2021 06:57:58 -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 167Dvsxu025882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Jul 2021 09:57:55 -0400 From: Justin Richer Message-Id: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D85ED454-77D6-44CB-AC8F-653345D0EB3B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 7 Jul 2021 09:57:54 -0400 In-Reply-To: Cc: Aaron Parecki , GNAP Mailing List To: Fabien Imbault References: 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 13:58:04 -0000 --Apple-Mail=_D85ED454-77D6-44CB-AC8F-653345D0EB3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=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? 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: >=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 >=20 > The exception is caddy server, that does it really well. Works fine in = production.=20 >=20 > And then, as a proof of concept, there's DIF Keri that embeds key = rotation as a primary requirement.=20 >=20 > Fabien=20 >=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= =99s 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 >=20 > =E2=80=94 Justin > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_D85ED454-77D6-44CB-AC8F-653345D0EB3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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> 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 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.

        =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 separately?
        =E2=80=A2 Some client instances have = registered keys
                =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
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_D85ED454-77D6-44CB-AC8F-653345D0EB3B-- From nobody Wed Jul 7 07:10:53 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 3EDE33A191F for ; 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 ; 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 ; Wed, 7 Jul 2021 07:10:47 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id a6so3685399ioe.0 for ; 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: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> From: Fabien Imbault Date: Wed, 7 Jul 2021 16:10:33 +0200 Message-ID: To: Justin Richer Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bdf20705c6891a9b" 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:10:52 -0000 --000000000000bdf20705c6891a9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0 15:57, Justin Richer a =C3=A9= crit : > Aaron, that=E2=80=99s a great point about static registration. That leave= s > 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 n= ew > key to sign that signature and present it. The thing that I get hung up o= n > 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 m= echanism. > 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 diffe= rent > 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 y= ou have > other options like CA=E2=80=99s and OCSP to help manage your keys at a di= fferent > 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 c= ould 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 wh= en > 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 rotatio= n > 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 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 wrote: >> >>> In the GNAP protocol, most requests are bound to a key. There are prett= y >>> solid mechanisms for establishing those keys as part of the request, bo= th >>> 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 clien= t >>> 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 i= s 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 >>> separately? >>> =E2=80=A2 Some client instances have registered keys >>> =E2=80=A2 What happens when a client=E2=80=99s register= ed 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 artifac= t >>> 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 >> > > --000000000000bdf20705c6891a9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

I suggest https://github.com/decentralized-identity/keri/bl= ob/master/kids/kid0005.md as a potential method (at least for discussio= n on a pre-rotation scheme).=C2=A0

Fabien


Le mer. 7 juil. 2021 =C3=A0 15:57, Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> a =C3=A9crit=C2= =A0:
Aaron, that=E2=80=99s a great point abou= t static registration. That leaves ephemeral or otherwise runtime keys, whi= ch might be good enough to just start a new request when needed?

Ben had previously posited a functional approach like sign(k2, sig= n(k1, (k2))): you use the old key (k1) to sign the new key (k2), then use t= he 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 cons= istently for all the different key types in use. The outer signature, signi= ng with the new key, is easy: that=E2=80=99s the GNAP key proofing mechanis= m. The trick is carrying a signed object with the key material internally s= omehow =E2=80=94 is there a way to handle that consistently across differen= t proofing types?

There are a bunch of ways that i= t could be done with different proofing mechanisms and that might be the ri= ght approach. HTTP Message Signatures can attach multiple signatures. JWK-b= ased-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?
<= div>
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 rota= tion, initial request, 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.imbault@gmail.com> wrote:

Hi there,

As f= ar as I know, key rotation remains a cumbersome process in most cases, to s= ay the least. It's quite impressive how often that breaks (usually when= a certificate expires somewhere).=C2=A0

<= div dir=3D"auto">The exception is caddy server, that does it really well. W= orks fine in production.=C2=A0

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

Fabien=C2=A0




Le mar. 6 juil. 2021 =C3=A0 23:29, Aaron Par= ecki <aaron@parecki.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I do think it's importan= t that a client instance should be able to rotate its keys, as this is a pr= etty common practice in other related specs.

You mention= ed pre-registered clients which I think is an interesting case. I would exp= ect in those cases the client instance wouldn't actually be rotating it= s keys on its own, instead the developer/administrator would go into the ma= nagement console to rotate the keys there, and deploy the new keys to the c= lient instance, more like how typical OAuth clients work today.
<= br>
Coming up with the actual rotation method is definitely an in= teresting challenge, but there must be some prior art to draw from here. Wo= uldn't existing specs like Mutual TLS or even PGP have some mechanism t= hat 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 pr= etty solid mechanisms for establishing those keys as part of the request, b= oth dynamically 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
https://www.ietf.org/ma= ilman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth

--000000000000bdf20705c6891a9b-- From nobody Wed Jul 7 07:14: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 51F383A193B for ; Wed, 7 Jul 2021 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 yKnzd9CZg2DE for ; Wed, 7 Jul 2021 07:14:51 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 B6C133A193A for ; Wed, 7 Jul 2021 07:14:51 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 167EEWZH000537; Wed, 7 Jul 2021 10:14:47 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 7 Jul 2021 10:14:37 -0400 Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 7 Jul 2021 10:14:37 -0400 Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1497.015; Wed, 7 Jul 2021 10:14:37 -0400 From: Thomas Hardjono To: Justin Richer , Fabien Imbault CC: GNAP Mailing List , Aaron Parecki Thread-Topic: [GNAP] Key Rotation Thread-Index: AQHXcq30x3d65dOot0G/DKz6SzbJvas2yuKAgAEC+gD//8EV1w== Date: Wed, 7 Jul 2021 14:14:37 +0000 Message-ID: References: , <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.100.88.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:14:57 -0000 As much as I like the direction of GNAP, is key-rotation (i.e. key manageme= nt) even part of the GNAP charter?=20 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=92s a great point about static registration. That leaves epheme= ral or otherwise runtime keys, which might be good enough to just start a n= ew 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=92s the GNAP key proofing mechanism. The trick is= carrying a signed object with the key material internally somehow =97 is t= here a way to handle that consistently across different proofing 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=92d get something like a nested JWT). M= TLS is a strange one, but if you=92re in certificate space you have other o= ptions like CA=92s 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 defi= nition? Still, something in me says that we should be able to do this in one consis= tent pattern, and I=92d love to hear more ideas on how that could be handle= d. If we can crack that, then it becomes a matter of applying that to a bun= ch of different requests: grant update, token rotation, initial request, et= c. This piece, at least, I believe can be applied pretty generically. =97 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 prod= uction. 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 =E0 23:29, Aaron Parecki > a =E9crit : I do think it's important that a client instance should be able to rotate i= ts 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 rota= ting 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 t= o the client instance, more like how typical OAuth clients work today. 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 existin= g specs like Mutual TLS or even PGP have some mechanism that could be reuse= d? 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 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. =95 Access tokens are bound to keys =95 We allow rotation of the token value at client instance= request... =95 Should we allow rotation of the key also? =95 Grant transactions are also bound to keys =95 Specifically: the continuation access token is bound to= a key =95 The key is initially the client instance=92s key =95 Should the client be able to rotate this key separately= ? =95 Some client instances have registered keys =95 What happens when a client=92s 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? =97 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 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-- From nobody Wed Jul 7 07:21:55 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 9D36D3A197B for ; Wed, 7 Jul 2021 07:21:53 -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 C9vVcaDEMKZ6 for ; Wed, 7 Jul 2021 07:21:49 -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 F03573A1979 for ; Wed, 7 Jul 2021 07:21:48 -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 167EKlwv003110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Jul 2021 10:21:46 -0400 From: Justin Richer Message-Id: <61709BF4-787C-403D-80FC-4181A7C985C0@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_60871F9E-9639-42E1-949E-683DE94BC965" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 7 Jul 2021 10:21:46 -0400 In-Reply-To: Cc: Aaron Parecki , GNAP Mailing List To: Fabien Imbault 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:21:54 -0000 --Apple-Mail=_60871F9E-9639-42E1-949E-683DE94BC965 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting, this mechanism seems to assume a specific key type (they = all look to be the same length values, for example). It feels less like = rotation and more like a key derivation function, but I would need to = learn more about how it actually functions. Thank you for passing that along! =E2=80=94 Justin > On Jul 7, 2021, at 10:10 AM, Fabien Imbault = wrote: >=20 > Hi Justin, >=20 > 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).=20 >=20 > Fabien >=20 >=20 > Le mer. 7 juil. 2021 =C3=A0 15:57, Justin Richer > a =C3=A9crit : > 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 >>=20 >> The exception is caddy server, that does it really well. Works fine = in production.=20 >>=20 >> And then, as a proof of concept, there's DIF Keri that embeds key = rotation as a primary requirement.=20 >>=20 >> Fabien=20 >>=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=99s 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 >>=20 >> =E2=80=94 Justin >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_60871F9E-9639-42E1-949E-683DE94BC965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting, this mechanism seems to assume a specific key = type (they all look to be the same length values, for example). It feels = less like rotation and more like a key derivation function, but I would = need to learn more about how it actually functions.

Thank you for passing that = along!

 =E2= =80=94 Justin

On Jul 7, 2021, at 10:10 AM, Fabien Imbault = <fabien.imbault@gmail.com> wrote:

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 =C3=A0 15:57, Justin Richer = <jricher@mit.edu> = a =C3=A9crit :
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> = 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 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.

        =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 separately?
        =E2=80=A2 Some client instances have = registered keys
                =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
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


= --Apple-Mail=_60871F9E-9639-42E1-949E-683DE94BC965-- From nobody Wed Jul 7 07:32:50 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 158823A19E9 for ; Wed, 7 Jul 2021 07:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 AMT43h8PtSiA for ; Wed, 7 Jul 2021 07:32:44 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 7CB7C3A19E5 for ; Wed, 7 Jul 2021 07:32:44 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 167EWZAG021003; Wed, 7 Jul 2021 10:32:42 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 7 Jul 2021 10:32:31 -0400 Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 7 Jul 2021 10:32:31 -0400 Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1497.015; Wed, 7 Jul 2021 10:32:31 -0400 From: Thomas Hardjono To: Justin Richer CC: Fabien Imbault , GNAP Mailing List , Aaron Parecki Thread-Topic: [GNAP] Key Rotation Thread-Index: AQHXcq30x3d65dOot0G/DKz6SzbJvas2yuKAgAEC+gD//8EV14AARVCA//+/IRA= Date: Wed, 7 Jul 2021 14:32:31 +0000 Message-ID: <6cf3416206a545bc916be9c041aceda6@oc11expo23.exchange.mit.edu> References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.100.88.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:32:49 -0000 Yes, keys are so intrinsic to many things in this digital world :-) I'm just pointing out that it may be over-reach for GNAP to define a key-ro= tation mechanism/procedure (TLS WG never did). >>> if you have a key management scheme in place,=20 >>> you should be able to just use that as-is without GNAP knowing anything= about it at the protocol level. Agree. This is true for TLS and IPsec as well, and many other protocols. --thomas ________________________________________ From: Justin Richer [jricher@mit.edu] Sent: Wednesday, July 7, 2021 10:20 AM To: Thomas Hardjono Cc: Fabien Imbault; GNAP Mailing List; Aaron Parecki Subject: Re: [GNAP] Key Rotation My take as an individual: Keys are so intrinsic to GNAP=92s architecture, for both client instances a= nd tokens, I argue we=92d be amiss to not mention their management over tim= e, which would include rotation. There=92s nothing in the spec right now ex= cept that it=92s allowed to happen (ie, =93the client instance=92s key or i= ts most current rotation=94), and this discussion is to raise exactly how m= uch we ought to specify that throughout GNAP. I think Aaron=92s point is an important one though: if you have a key manag= ement scheme in place, you should be able to just use that as-is without GN= AP knowing anything about it at the protocol level. What we=92re talking ab= out is an in-protocol dynamic way to manage the associated keys. =97 Justin On Jul 7, 2021, at 10:14 AM, Thomas Hardjono > wrote: 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 b= ehalf 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=92s a great point about static registration. That leaves epheme= ral or otherwise runtime keys, which might be good enough to just start a n= ew 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=92s the GNAP key proofing mechanism. The trick is= carrying a signed object with the key material internally somehow =97 is t= here a way to handle that consistently across different proofing 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=92d get something like a nested JWT). M= TLS is a strange one, but if you=92re in certificate space you have other o= ptions like CA=92s 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 defi= nition? Still, something in me says that we should be able to do this in one consis= tent pattern, and I=92d love to hear more ideas on how that could be handle= d. If we can crack that, then it becomes a matter of applying that to a bun= ch of different requests: grant update, token rotation, initial request, et= c. This piece, at least, I believe can be applied pretty generically. =97 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 prod= uction. 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 =E0 23:29, Aaron Parecki > a =E9crit : I do think it's important that a client instance should be able to rotate i= ts 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 rota= ting 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 t= o the client instance, more like how typical OAuth clients work today. 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 existin= g specs like Mutual TLS or even PGP have some mechanism that could be reuse= d? 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 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. =95 Access tokens are bound to keys =95 We allow rotation of the token value at client instance = request... =95 Should we allow rotation of the key also? =95 Grant transactions are also bound to keys =95 Specifically: the continuation access token is bound to = a key =95 The key is initially the client instance=92s key =95 Should the client be able to rotate this key separately? =95 Some client instances have registered keys =95 What happens when a client=92s 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? =97 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 From nobody Wed Jul 7 07:40:34 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 C00B43A1A22 for ; Wed, 7 Jul 2021 07:40:32 -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 k3WiCbhgKltR for ; Wed, 7 Jul 2021 07:40:28 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 080423A1A1C for ; Wed, 7 Jul 2021 07:40:27 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id b1so3771266ioz.8 for ; Wed, 07 Jul 2021 07:40:27 -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=DHUdrWhXtUN9WCz0f/e+XNQReGJaRjHYV6SKiFVqYaI=; b=aVdSRKdoFq0XJJbOeJN97dfERUYOWwU681WnCVkb2srIJQ3jRV4t17j1/vwCqz04um fBDtRkOt4tryvv8S/qdQa38BzxwN08tdnpyspKWtPK31GRMDiLvUZRBEi8yyvmrzqXia 1tM5y3Sdy5V9jENUPjHZKJ042/qXBHmF7EaRRa7/xP11Yal/3Oa75obzyBHMd7HdLG+D /cUMTNMC6dR5cQULZSSj2Aw+1OqoVfSqXsN/GbD8bEGjCWo4FCT3fNx9ht3Dp0FxAvMC RY8PDo/slpTRGXNaWNihniOgH2wc4PFJv9aX0gLiapMttBec7kqgWXbjdgVibv5LvxC+ 0ruQ== 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=DHUdrWhXtUN9WCz0f/e+XNQReGJaRjHYV6SKiFVqYaI=; b=XHHWB9dO7JeeBXPLvLK8imnyaHLJM4mC9PUGZ66tjVErHG0y4V0S5YYIAbTuiu1fkb FnwB8LcmoCGxpJ0rfPQTV35WHILh6iCVb07umyhEm7uVCq/PQCVHqPLOmKzOKML0w1sm oVWXB4ubjfZFXpQvg8DgcywXeShDTbeetH1tw+mOrn/Q4YdcZmXXQ2Py7QkwcPsu2IKK 3BqFaLZAJosetsCTjxKdCNXKmC3qss7IDkNFqdrySerZrHQ+SLQd8uReSIkGbbOkcBDr aBbFjNBCWY6qDQ3kU2/eE+fIkTLWHDJsMXiddyZSotZJpTc97Ci4AoKTmWbFWisSzsK+ 1CNg== X-Gm-Message-State: AOAM530RWDW8o10DXaeS7+O408J1c+0x5Avri0egWNxjR8JEFh4xNd+i eMtTzU4s1jZNlj+eiZuklrgEG5KzR4lNBlqwxmIsbvZl X-Google-Smtp-Source: ABdhPJwoBlhxW3alXWEjEIB4UuExyvLGfD9bG4Lzc1Ms3t1hHHkKL5x0jIdVpnffqNXXVxafC1KF4g5FjPh0KH2rln4= X-Received: by 2002:a05:6638:bc5:: with SMTP id g5mr10174935jad.47.1625668826700; Wed, 07 Jul 2021 07:40:26 -0700 (PDT) MIME-Version: 1.0 References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 7 Jul 2021 16:40:14 +0200 Message-ID: To: Thomas Hardjono Cc: Justin Richer , GNAP Mailing List , Aaron Parecki Content-Type: multipart/alternative; boundary="000000000000f01d1c05c689843f" 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:40:33 -0000 --000000000000f01d1c05c689843f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's a valid point (i.e. you might use whatever system you want, as long as you make sure your keys are managed) although one could argue we should at the very minimum provide practical methods to ensure sufficient security. Which means we could 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 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 leave= s > 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 n= ew > key to sign that signature and present it. The thing that I get hung up o= n > 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 m= echanism. > 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 diffe= rent > 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 y= ou have > other options like CA=E2=80=99s and OCSP to help manage your keys at a di= fferent > 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 c= ould 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 wh= en > 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 rotatio= n > 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 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 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 > =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 se= parately? > =E2=80=A2 Some client instances have registered keys > =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 prov= e > 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 > https://www.ietf.org/mailman/listinfo/txauth > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000f01d1c05c689843f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a valid point (i.e. you migh= t use whatever system you want, as long as you make sure your keys are mana= ged) although one could argue we should at the very minimum provide practic= al methods to ensure sufficient security. Which means we could still provid= e a way native to GNAP, in case people don't have their preferred metho= d already?

Le mer. 7 juil. 2021 =C3=A0 16:14, Thomas Hardjono <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

--000000000000f01d1c05c689843f-- 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-- From nobody Wed Jul 7 11:44:53 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 091EB3A24EB for ; Wed, 7 Jul 2021 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 oBsVGXP9ZjpV for ; Wed, 7 Jul 2021 11:44:41 -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 C72753A24B7 for ; Wed, 7 Jul 2021 11:44:34 -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 167IiWDN006575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 7 Jul 2021 14:44:33 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_FE8EF64F-A5D7-4194-BA8A-26120DFC1505" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <763BEAF4-46AF-4A0C-8E70-2BDE3B22F94C@mit.edu> Date: Wed, 7 Jul 2021 14:44:32 -0400 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [GNAP] Editors Update, IETF111 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 18:44:51 -0000 --Apple-Mail=_FE8EF64F-A5D7-4194-BA8A-26120DFC1505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The editors met today to process a bunch of changes to both the core and = RS drafts.=20 The current plan is to have everything finalized by Monday morning, July = 12, in order to meet the IETF draft publication deadline ahead of the = IETF111 meeting in a few weeks. The goal is to have draft -06 of core = and draft -01 of the RS document for discussion at the meeting. With that in mind, the following PRs have been marked as Pending Merge = for both Core and RS: #269: Split interaction methods discovery value https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/269 = #270: Trim features https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/270 = #32: updated discovery definitions https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/32 = #33: expanded RS resource set registration protocol https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/33 = #34: expanded introspection details https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/34 = #35: added access token format registry https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/35 = #36: expanded RS authentication discussion, with examples https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/36 = In addition, the following PRs were found to need some clean-up so they = haven=E2=80=99t been marked for merge yet, but the intent is to merge = these as well before the deadline: #217: trim dpop https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271 = #272: trim oauthpop https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272 = #31 gnap terminology ref https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31 = On top of that, we anticipate at least one more PR that the editors are = working on that will align the response and request formats for token = flags. Aaron will send a note to the list when he=E2=80=99s got that = ready. As always, please take a look at the proposed changes, review, and = comment as you can. A reminder, the deadline for these is the morning of = Monday July 12, ahead of the IETF deadline. We=E2=80=99ll be discussing = these changes, along with all the others done since IETF110, at the = meeting in a few weeks. Thank you, =E2=80=94 Justin= --Apple-Mail=_FE8EF64F-A5D7-4194-BA8A-26120DFC1505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = editors met today to process a bunch of changes to both the core and RS = drafts. 

The = current plan is to have everything finalized by Monday morning, July 12, = in order to meet the IETF draft publication deadline ahead of the = IETF111 meeting in a few weeks. The goal is to have draft -06 of core = and draft -01 of the RS document for discussion at the = meeting.

With = that in mind, the following PRs have been marked as Pending Merge for = both Core and RS:

#269: Split interaction methods discovery value
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/269=

#270: Trim = features
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/270=

#32: updated = discovery definitions
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/32

#33: = expanded RS resource set registration protocol
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/33

#34: = expanded introspection details
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/34

#35: added = access token format registry
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/35

#36: = expanded RS authentication discussion, with examples
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/36


In addition, the following PRs were = found to need some clean-up so they haven=E2=80=99t been marked for = merge yet, but the intent is to merge these as well before the = deadline:

#217: = trim dpop
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271=

#272: trim = oauthpop
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272=

#31 gnap = terminology ref
https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31



On = top of that, we anticipate at least one more PR that the editors are = working on that will align the response and request formats for token = flags. Aaron will send a note to the list when he=E2=80=99s got that = ready.

As = always, please take a look at the proposed changes, review, and comment = as you can. A reminder, the deadline for these is the morning of Monday = July 12, ahead of the IETF deadline. We=E2=80=99ll be discussing these = changes, along with all the others done since IETF110, at the meeting in = a few weeks.

Thank you,
 =E2=80=94 = Justin
= --Apple-Mail=_FE8EF64F-A5D7-4194-BA8A-26120DFC1505-- From nobody Sun Jul 11 00:41:10 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 E3C503A2512 for ; Sun, 11 Jul 2021 00:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=xYbpLVwT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ulahvw8n 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 LUV4Z0OXzZiT for ; Sun, 11 Jul 2021 00:40:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DA93A2515 for ; Sun, 11 Jul 2021 00:40:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5793E5C0243 for ; Sun, 11 Jul 2021 03:34:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 11 Jul 2021 03:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=1fIJ0H4CtMT 8MQk9A7CVg4Jhj1lL7ar9dMGqOxyElgc=; b=xYbpLVwTaFC/fd3O/xDoVrpdw5N pFU1kZeR3CGYjDeoQqIOD45keHt+cDi2+pejnV60l5DYW5ZhK/SZTNRaqKX/ht95 mvFwS9o7mGmW/v0wG54z69orGGO8aDQlIxLV1PU/Z3OwQ0NjbNsZUvXWtlIuIl3p Nbhmok0fqWrfyce0zG2AANWH/xuB2EzGydSJ456Aznvmd1hFCsHFpQHwPJ4l5hgw KPcmfpq4cAe+j8cLNNGOt+3mbwB1bDnBL8CmVEX9y7VwWotbEUKO0w25F0KYwW1g QEElHw5XBpbcrOzt+UTvsW8gxOxyuF2e+uma4Y4i+e2jd9WSWjj6cLgiW8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=1fIJ0H4CtMT8MQk9A7CVg4Jhj1lL7ar9dMGqOxyElgc=; b=ulahvw8n ZcSaUlHEpolh7TPvhFzDTa+LeLA/POddweXvfZbqESXUsjaYh884WMZBisYd6Z9Y 2YxwCIcqGAFNYpI/Zl+FjmCh07uin8/nRIruktk2BCvuyPNC8AnnZTm/Ub6RXG/1 dZBGSGG1V0jN7VyCg3n3n/UE0Guwh8FQBtGXVTZ7wJPfK41E+CObcgA5co5CKmfq 0xynLJkDGlCPb2uDC1xT1wJJrcug7tfbnCjWusDYDRHRu11Pv6OzbW84ioL9SnwF 7H2EuTqejoAX5zhUls/5KUiXPOjI8NUuSSY4kUmaohnuWStMtcTAMvrm9/AlekRM /l6tzIe9CmkaDg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdelgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 11 Jul 2021 03:34:29 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2447621336306568749==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210711074059.61DA93A2515@ietfa.amsl.com> Date: Sun, 11 Jul 2021 00:40:59 -0700 (PDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) 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: Sun, 11 Jul 2021 07:41:05 -0000 --===============2447621336306568749== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/gnap-resource-servers (+0/-1/=F0=9F=92=AC2) 2 issues received 2 new comments: - #23 RS Token derivation (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/23=20 - #5 The privacy drawbacks when implementing an introspection service sho= uld be mentioned (1 by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/5=20 1 issues closed: - The privacy drawbacks when implementing an introspection service should= be mentioned https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/= 5=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-1/=F0=9F=92=AC8) 3 pull requests submitted: - refactor token response details to use flags array (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/273=20 - trim oauthpop (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272=20 - trim dpop (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271=20 4 pull requests received 8 new comments: - #273 refactor token response details to use flags array (2 by aaronpk, = netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/273=20 - #272 trim oauthpop (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272=20 - #271 trim dpop (2 by fimbault, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271=20 - #270 Trim features. (3 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/270 [Pending Me= rge]=20 1 pull requests merged: - add grant endpoint URL to interaction hash to close mix-up proxy vulner= ability https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/268 [Pending Me= rge]=20 * ietf-wg-gnap/gnap-resource-servers (+6/-0/=F0=9F=92=AC6) 6 pull requests submitted: - expanded RS registration discussion, with examples (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/36=20 - added access token format registry (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/35=20 - expanded introspection details (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/34=20 - expanded RS resource set registration protocol (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/33=20 - updated discovery definitions (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/32=20 - gnap terminology ref (by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31=20 6 pull requests received 6 new comments: - #36 expanded RS registration discussion, with examples (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/36=20 - #35 added access token format registry (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/35=20 - #34 expanded introspection details (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/34=20 - #33 expanded RS resource set registration protocol (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/33=20 - #32 updated discovery definitions (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/32 [Pending = Merge]=20 - #31 gnap terminology ref (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============2447621336306568749== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday July 11, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/gnap-resource-servers (+0/-1/=F0=9F=92=AC2)

2 issues received 2 new comments:

1 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+3/-1/=F0=9F=92=AC8)

3 pull requests submitted:

4 pull requests received 8 new comments:

1 pull requests merged:

ietf-wg-gnap/gnap-resource-servers (+6/-0/=F0=9F=92=AC6)

6 pull requests submitted:

6 pull requests received 6 new comments:

Repositories tracked by this digest:

--===============2447621336306568749==-- From nobody Sun Jul 11 07:24:21 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 D64003A0B44 for ; Sun, 11 Jul 2021 07:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 fBuSeevKBlNI for ; Sun, 11 Jul 2021 07:24:17 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 3177E3A0ABE for ; Sun, 11 Jul 2021 07:24:16 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id a5-20020a7bc1c50000b02901e3bbe0939bso9561599wmj.0 for ; Sun, 11 Jul 2021 07:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=a6PgYR1UN99bCZ7JECo+qqEHcpjRwwGaX8/xkXxYcy8=; b=WkVxWX9SmK/CyWSf31/ZZxhn8h/2skMvazVhTAgM3dQspSpkiHCoP7Gggwy2vg+HRy a8vX66LsOWaOFFjCm7UHzRElvgWm+9dpL/lDuZtYu82E4MGws/NaxgHWaO+qOBDyVSJP mIL5DLHWXuEu3R6B40bRZTSv/8richCgLov5av0M7TtBY5pDsouZYj7Xk7Rg1TYds8U9 9yaeo7IkUOtBJkfZHMk/rhr+W57mE7VYxVPnNxOzi2Tr8QRfjTSX1+n5Nhh2JLJyiyvl uQO/W5bkhRunewDc49Iwcp7JSmozwLoJhEZtTKFJ+20zDeX5NtpJnQCjNj+oeZj+J4m/ IZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=a6PgYR1UN99bCZ7JECo+qqEHcpjRwwGaX8/xkXxYcy8=; b=sKR90Aq+/VWtYQIs7lltRmnv9Whii0bS7Z2p/qOIUODnHM596CjmmzYXtk1nGAc9vg 8wli9qNL6q3P/vSaOm7zP125zl5d6d7LB2Y5w5jFRd4mKCOiTU0x5igobQ5oLTBg03Q8 mmHNionftENxyQKFG8r9iJ6ojWyqaunwXFpiC+i9uVKYcEyiYvP4Fb7VXrtYdr7BelJr 43Cmd3eo+2w+Fie/5OVcK190YDCc7dOmWxx9TBwwgHk5/29izVYlv//ZYwZkrZw0hkpc Wj4W7yfLiX3j5ptg9gA8sTKeJo0o0g/kyuG8trH6mQnFzuZUdG+IZK99T7mfNgJnAmlw soaw== X-Gm-Message-State: AOAM531wml9//5xZ+0MmRdpHLsR2HuZhiWgfX6q+ERXaUmCm2zHQlkrG 462meZKoMb7HkBJ8jfuPYYrCZtKvsSU= X-Google-Smtp-Source: ABdhPJzM+tumTBO+FX+QxT8C7425NNynkwXDc9hru4HI4FGHu7y1v9TFrLtZyFNXjubBNSlYC7l8nw== X-Received: by 2002:a7b:c4d9:: with SMTP id g25mr9387898wmk.108.1626013453794; Sun, 11 Jul 2021 07:24:13 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-182-62-6.red.bezeqint.net. [79.182.62.6]) by smtp.gmail.com with ESMTPSA id b16sm8305565wrw.46.2021.07.11.07.24.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jul 2021 07:24:13 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.50.21061301 Date: Sun, 11 Jul 2021 17:24:12 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: GNAP meeting agenda requests Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3708869053_1151645060" Archived-At: Subject: [GNAP] GNAP meeting agenda requests 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: Sun, 11 Jul 2021 14:24:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3708869053_1151645060 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The GNAP working group will be meeting at IETF-111, on July 26. Please let = me know by EOD Tuesday if you=E2=80=99d like a slot on the agenda. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 --B_3708869053_1151645060 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The GNAP working group will be meeting at IETF-111, on Jul= y 26. Please let me know by EOD Tuesday if you=E2=80=99d like a slot on the agenda= .

 

T= hanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

<= /html> --B_3708869053_1151645060-- From nobody Mon Jul 12 08:59:19 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1A3A2092; Mon, 12 Jul 2021 08:59:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <162610554657.7895.14210931790339374664@ietfa.amsl.com> Date: Mon, 12 Jul 2021 08:59:06 -0700 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-06.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 15:59:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-core-protocol-06.txt Pages : 127 Date : 2021-07-12 Abstract: GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 08:59:32 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF633A20C0; Mon, 12 Jul 2021 08:59:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <162610555119.8540.3539319919543464936@ietfa.amsl.com> Date: Mon, 12 Jul 2021 08:59:11 -0700 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-resource-servers-01.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 15:59:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Resource Server Connections Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-resource-servers-01.txt Pages : 16 Date : 2021-07-12 Abstract: GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This extension defines methods for resource servers (RS) to communicate with authorization servers (AS) in an interoperable fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-resource-servers/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-resource-servers-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 10:51:28 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 365D23A25AC for ; Mon, 12 Jul 2021 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JLUxUxNXlSbm for ; Mon, 12 Jul 2021 10:51:16 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 551E83A254D for ; Mon, 12 Jul 2021 10:51:09 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id p3so407580ilg.8 for ; Mon, 12 Jul 2021 10:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=LFivGdQ/OGUenF2weXupjURlqQiisHCVjRTJh5UBU2M=; b=bUL1ElPe+3hU+IKUypNPkef5LIkVsseX+trWrDcr1by9g+SM5Hglmk1KVlMX0bTObc f/UHol8A2EJjaYf3TB6Cmv9tvErtJ6dFTVY1Y8faNb1BUQOcj/vm76c4GjdwlE2tX1qo dVs0weaumCm4BYRq+mKBUFR+xzp0j7FvrOQ45zR9jnk/OIYujilsOagFuygWvcHywpgY rNBIVN2qoPG6PqYCRiNNoE5ToP2sfo36FMzTnGmetpWZJmx9Pinz672GakYIwyuS6VgV vf+qmLchTMrEp7j4Fm4zul9uQIAXEONOWpyk6F74Jtuy6X5iggTegCYOxxIzS1F/2opR p/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=LFivGdQ/OGUenF2weXupjURlqQiisHCVjRTJh5UBU2M=; b=mUyTOYMnMQjuVkDm69WrWNAVHQYG4cjUMbzXrVj8gGMMyFo3jWkh859bbqkc8Wn6Ug IR8MjIp1oFrB0P8hP4ikXnHA6fPjKUNS08OfcrIAqGO+XImvNMEsVsH2NlETrAVAX4Vg NwA09pZgSN3hUx4FjzX2hM43E5gkmL496LyMwZJl7pBmbHpC4cQu3oEEwQh/Yejfc8tx ioXvJX8AcCqECJImTKi9hiWbCkwi892twAVWoZRUIjNDuzqEojipzYsUlWco5Ct5+HLP HGmL2Rx+yGGebExPLLZyQ8prYOAWHAhlc3ntaJelKPu7zZn8Rdd1fiNRk7/UgSYHZFor N2bg== X-Gm-Message-State: AOAM531Xs+Xv4TbXHvjp4anpHZdkHE3s3QsxHOaB/XHiAzjCuhkda0LJ 0PoncKsxa4rKJlm0ZiIoa8s= X-Google-Smtp-Source: ABdhPJx9b3bX9yr3QdbL05iwKYLcDQVosgzZrlW7b1KjEmShoIqXYrnA/y33N85HUq+qQYXy8D2hYg== X-Received: by 2002:a92:d943:: with SMTP id l3mr36135ilq.37.1626112267912; Mon, 12 Jul 2021 10:51:07 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-182-62-6.red.bezeqint.net. [79.182.62.6]) by smtp.gmail.com with ESMTPSA id e17sm5245558ilr.51.2021.07.12.10.51.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 10:51:07 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.50.21061301 Date: Mon, 12 Jul 2021 20:51:04 +0300 From: Yaron Sheffer To: Adrian Gropper , Fabien Imbault CC: Justin Richer , Thomas Hardjono , GNAP Mailing List , Aaron Parecki Message-ID: Thread-Topic: [GNAP] Key Rotation References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3708967866_439354522" 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: Mon, 12 Jul 2021 17:51:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3708967866_439354522 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We absolutely need to support key rotation, and I don=E2=80=99t think we should a= ssume an external key management service. =20 To me key rotation simply means a way to identify keys (a key ID) and the e= xpectation that protocol parties should manage more than one key at a time: = the current key and potentially older keys, up to some validity period. =20 If access tokens are bound to long-lived keys, we might need to add an expl= icit, non-opaque, key ID to access tokens. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: TXAuth on behalf of Adrian Gropper Date: Wednesday, July 7, 2021 at 18:28 To: Fabien Imbault Cc: Justin Richer , Thomas Hardjono , GN= AP Mailing List , Aaron Parecki Subject: Re: [GNAP] Key Rotation =20 Whatever we do in terms of scope, GNAP should not ignore this key rotation = issue.=20 =20 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 t= he transition to zero-trust architectures. As I understand it, we're seeing = part of this as the difference between OAuth2 client credentials and GNAP.=20 =20 If GNAP can do or say something useful about key rotation and client creden= tials, then I hope we do. =20 - Adrian =20 On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault w= rote: That's a valid point (i.e. you might use whatever system you want, as long = as you make sure your keys are managed) although one could argue we should a= t the very minimum provide practical methods to ensure sufficient security. = Which means we could still provide a way native to GNAP, in case people don'= t have their preferred method already? =20 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 manageme= nt) even part of the GNAP charter?=20 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 epheme= ral or otherwise runtime keys, which might be good enough to just start a ne= w 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 h= aving 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 n= ew key, is easy: that=E2=80=99s the GNAP key proofing mechanism. The trick is carr= ying 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 mec= hanisms and that might be the right approach. HTTP Message Signatures can at= tach multiple signatures. JWK-based-keys could use JWS to wrap the key conte= nt 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 optio= ns like CA=E2=80=99s and OCSP to help manage your keys at a different level. So ma= ybe 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 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 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 prod= uction. 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 i= ts 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 rotat= ing its keys on its own, instead the developer/administrator would go into t= he management console to rotate the keys there, and deploy the new keys to t= he client instance, more like how typical OAuth clients work today. 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 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 so= lid mechanisms for establishing those keys as part of the request, both dyna= mically 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. =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 separately= ? =E2=80=A2 Some client instances have registered keys =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 https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3708967866_439354522 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We absolutely need to= support key rotation, and I don=E2=80=99t think we should assume an external key = management service.

 

To me key rotation simply means a way to identify keys (a k= ey ID) and the expectation that protocol parties should manage more than one= key at a time: the current key and potentially older keys, up to some valid= ity period.

 

If access tokens are bound to long-lived keys, we might need to add= an explicit, non-opaque, key ID to access tokens.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of Adrian Gropper &l= t;agropper@healthurl.com>
Date: Wednesday, July 7, 2021 at 18:2= 8
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Thomas Hardjono <hardjono@mit.ed= u>, GNAP Mailing List <txauth@ietf.org>, Aaron Parecki <aaron@pa= recki.com>
Subject: Re: [GNAP] Key Rotation

 

Whatever we do in terms of scope, GNAP should not ignore this key rot= ation issue. 

 

Regardless of what happened in the era of TL= S and IPsec, today we're seeing the limits of federated security architectur= es 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.

 

<= div>

- Adrian

 

On Wed, Jul 7, 2021 at 10= :40 AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:

That's a valid point (= i.e. you might use whatever system you want, as long as you make sure your k= eys are managed) although one could argue we should at the very minimum prov= ide practical methods to ensure sufficient security. Which means we could st= ill 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 Hardjono = <hardjono@mit.edu&g= t; 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
<= br>
________________________________________
From: TXAuth [txauth-bounces@ietf.org] o= n 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 R= otation

Aaron, that=E2=80=99s a great point about static registration. That= leaves ephemeral or otherwise runtime keys, which might be good enough to j= ust start a new request when needed?

Ben had previously posited a fun= ctional 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 prese= nt it. The thing that I get hung up on is having a way to do the key proofin= g for a new key that works consistently for all the different key types in u= se. The outer signature, signing with the new key, is easy: that=E2=80=99s the GNA= P 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 co= uld be done with different proofing mechanisms and that might be the right a= pproach. HTTP Message Signatures can attach multiple signatures. JWK-based-k= eys 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 manag= e your keys at a different level. So maybe GNAP just specifies the functiona= l requirement at a high level and each proofing mechanism or deployment has = to fill that somehow in its definition?

Still, something in me says t= hat we should be able to do this in one consistent pattern, and I=E2=80=99d love t= o hear more ideas on how that could be handled. If we can crack that, then i= t becomes a matter of applying that to a bunch of different requests: grant = update, token rotation, initial request, etc. This piece, at least, I believ= e 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>&g= t; wrote:

Hi there,

As far as I know, key rotation remains a c= umbersome process in most cases, to say the least. It's quite impressive how= often that breaks (usually when a certificate expires somewhere).

Th= e exception is caddy server, that does it really well. Works fine in product= ion.

And then, as a proof of concept, there's DIF Keri that embeds ke= y 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 th= ink 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 ment= ioned pre-registered clients which I think is an interesting case. I would e= xpect in those cases the client instance wouldn't actually be rotating its k= eys on its own, instead the developer/administrator would go into the manage= ment 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?

Aar= on


On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:<= br>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 dy= namically and as part of some pre-registration step.

However, over ti= me those keys could be rotated out by the parties that control them, and GNA= P needs to be able to handle this.

        =E2=80=A2 Ac= cess tokens are bound to keys
            &= nbsp;   =E2=80=A2 We allow rotation of the token value at client instance req= uest...
                =E2=80=A2 Shoul= d we allow rotation of the key also?
        =E2=80=A2 Gran= t transactions are also bound to keys
          =       =E2=80=A2 Specifically: the continuation access token is boun= d to a key
                =E2=80=A2 Th= e key is initially the client instance=E2=80=99s key
       = ;         =E2=80=A2 Should the client be able to rotate this k= ey separately?
        =E2=80=A2 Some client instances have= registered keys
                = =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 possess= ion of both the old and new keys simultaneously. It could be a matter of sig= ning the request with the new key and include some artifact signed by the ol= d key in the request, or the inverse of that. There are likely other methods= out there, but this seems simplest.

What situations are people looki= ng at for handling key rotation?

 =E2=80=94 Justin
--
TXAuth mai= ling list
TXAuth@ietf.or= g<mailto:TXAuth@ietf= .org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth = mailing list
TXAuth@ietf= .org<mailto:TXAuth@i= etf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
<= a href=3D"mailto:TXAuth@ietf.org" target=3D"_blank">TXAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/txauth

-- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/m= ailman/listinfo/txauth

--B_3708967866_439354522-- From nobody Sun Jul 18 01:11:11 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 A34013A145C for ; Sun, 18 Jul 2021 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=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=mnot.net header.b=oVMYQ8GR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MNMS5SvO 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 sON8dQ51sSlE for ; Sun, 18 Jul 2021 01:11:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221113A145D for ; Sun, 18 Jul 2021 01:10:59 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AE95B5C0105 for ; Sun, 18 Jul 2021 03:34:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 18 Jul 2021 03:34:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=8zh799Mx+YT 4SgGlYKLhZFmUv978+ITjaDeSJZq5/5o=; b=oVMYQ8GRX8MKZX7EvkbySzwBkds 9IKNWhMMiyoIgQuaNFqtugzxTwmWapKSjZyZrclf/msR+Lab80A2FO3ALAXvWd9I bsI258RnegwQN5aCxquc7cwpOPssXUgdmzHOiTahlwtWmBzjRkmXBiOULGxUSkMK 3m7R8PDFY97y9W2Uf1FzPDtwCvcQ+R771pBa9gR3tWpkdW4vWz/Q3FFhZTGbM3Ee LmAq0F2zCBjVLEWb0QEkg+3CBd4GH+fhOVpARAYVZPJeQoIMXLnee4Ksi81yh/rC HW2xx3G+9clXhjTaR3h1UHGsvHGUKDUZDiYY7vWGjizzTNs6xSSN+IoHXeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=8zh799Mx+YT4SgGlYKLhZFmUv978+ITjaDeSJZq5/5o=; b=MNMS5SvO HhGFYtz/KecEFrn9uZXaeq9OvjZnhUEdPWvtiRF3V3/ECNkKp3nKH25UwTiSLp3j JCkJpuLWduhcIpWxlndfrwu5FM16l0a0dALSr59KDjyV0gReILuDFMdPYQTaynPQ cl+68/7pj0GHrzKFDv5lgwYFE2m1javb2UETCIRVba9zGi32IiByroUKAy5ruw3q OCr6JnUFO7bXIsSAwrEFGhxRiKZd5zuLVppuSiO8vnBZXnJHDpylf0hhJXQkH4ui 5jZA545ZGq7CwXrrmolJflWR4AEpxh2h6kWR2yy3QKab+vwKrto3bHt6KJAG9rU7 Kg5wp9Oth6SyAQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdejgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmnecujf gurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhihucet tghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeugfef hfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 18 Jul 2021 03:34:20 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7226397037936638696==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210718081100.221113A145D@ietfa.amsl.com> Date: Sun, 18 Jul 2021 01:10:59 -0700 (PDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) 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: Sun, 18 Jul 2021 08:11:06 -0000 --===============7226397037936638696== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+18/-1/=F0=9F=92=AC1) 18 issues created: - Token Management functions are over-engineering (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/293=20 - Does a client instance really need to be identified by a unique key ? (= by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/292=20 - Requesting RO Information or Requesting Subject Information? (by Denist= hemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/291=20 - Checks needed to defeat user collaborative attacks are unfortunately ou= t of the scope of the document (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/290=20 - Bearer tokens should not be supported or be deprecated (by Denisthemali= ce) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/289=20 - Since both rights and resource locations must be disclosed to the AS, t= he AS can act as Big Brother (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/288=20 - About the locations field (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/287=20 - In practice, only rights are supported but attributes should also be su= pported (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/286=20 - The diagram of the exchanges is mandating a pre-configuration between e= ach pair of AS/RS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/285=20 - The document is confusing a Resource Server (RS) with a Protected Resou= rce (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/284=20 - User consent is not supported (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/283=20 - The client has no effective control upon the content of an access token= (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/282=20 - The client is unable to know that a RS is associated with more than one= AS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/281=20 - The access token is opaque to the client instance: transparency cannot = be achieved (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/280=20 - Trust relationships between ROs and ASs and between ROs and RSs are lef= t undefined (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/279=20 - Trust relationships are still undefined (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/278=20 - No access token structure is being defined or referenced (by Denisthema= lice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/277=20 - The document is currently unable to follow the standards track (by Den= isthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/276=20 1 issues received 1 new comments: - #134 Guidance for Extensions (1 by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134=20 1 issues closed: - Mutual exclusivity of instance identifier https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/45=20 * ietf-wg-gnap/gnap-resource-servers (+4/-6/=F0=9F=92=AC0) 4 issues created: - Accessing a secondary RS from a primary RS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/42=20 - In section 3.4, "token_format_required" should be changed into"token_f= ormats_supported" (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/41=20 - Insufficient description of two fields from RS-facing AS Discovery (edi= torial) (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/40=20 - =E2=80=9CRS-Facing API=E2=80=9D versus =E2=80=9CAS-Facing API=E2=80=9D = (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/39=20 6 issues closed: - Ref in Terminology https://github.com/ietf-wg-gnap/gnap-resource-server= s/issues/14 [Editorial]=20 - A section describing the structure of the list of token formats is curr= ently missing https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/= 29=20 - Token Introspection security check https://github.com/ietf-wg-gnap/gnap= -resource-servers/issues/20=20 - Token Introspection https://github.com/ietf-wg-gnap/gnap-resource-serve= rs/issues/24=20 - Token Introspection API: level of detail https://github.com/ietf-wg-gna= p/gnap-resource-servers/issues/19=20 - RS-registered resource reference handle arity https://github.com/ietf-w= g-gnap/gnap-resource-servers/issues/22=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-7/=F0=9F=92=AC6) 2 pull requests submitted: - pre 06 editorial cleanup (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/275=20 - add did example (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/274=20 5 pull requests received 6 new comments: - #275 pre 06 editorial cleanup (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/275 [Editorial]= =20 - #274 add did example (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/274=20 - #272 trim oauthpop (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272=20 - #271 trim dpop (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271=20 - #270 Trim features. (2 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/270 [Pending Me= rge]=20 7 pull requests merged: - pre 06 editorial cleanup https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/275 [Editorial]= =20 - add did example https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/274 [Editorial]= =20 - refactor token response details to use flags array https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/273 [Pending Me= rge]=20 - trim oauthpop https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272 [Pending Me= rge]=20 - trim dpop https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271 [Pending Me= rge]=20 - Trim features. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/270 [Pending Me= rge]=20 - split interaction methods discovery value https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/269 [Pending Me= rge]=20 * ietf-wg-gnap/gnap-resource-servers (+2/-7/=F0=9F=92=AC5) 2 pull requests submitted: - Several pretty minor edits after I read through this doc. (by adeinega) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/38=20 - pre 01 editorial cleanup (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/37=20 3 pull requests received 5 new comments: - #38 Several pretty minor edits after I read through this doc. (3 by ade= inega, jricher, netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/38 [Editoria= l]=20 - #37 pre 01 editorial cleanup (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/37 [Editoria= l]=20 - #31 gnap terminology ref (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31 [Editoria= l]=20 7 pull requests merged: - pre 01 editorial cleanup https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/37 [Editoria= l]=20 - expanded RS authentication discussion, with examples https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/36 [Pending = Merge]=20 - added access token format registry https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/35 [Pending = Merge]=20 - expanded introspection details https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/34 [Pending = Merge]=20 - expanded RS resource set registration protocol https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/33 [Pending = Merge]=20 - updated discovery definitions https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/32 [Pending = Merge]=20 - gnap terminology ref https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/31 [Editoria= l]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============7226397037936638696== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday July 18, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+18/-1/=F0=9F=92=AC1)

18 issues created:

1 issues received 1 new comments:

1 issues closed:

ietf-wg-gnap/gnap-resource-servers (+4/-6/=F0=9F=92=AC0)

4 issues created:

6 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+2/-7/=F0=9F=92=AC6)

2 pull requests submitted:

5 pull requests received 6 new comments:

7 pull requests merged:

ietf-wg-gnap/gnap-resource-servers (+2/-7/=F0=9F=92=AC5)

2 pull requests submitted:

3 pull requests received 5 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============7226397037936638696==-- From nobody Sun Jul 18 05:24:33 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 EF8253A1DB7 for ; Sun, 18 Jul 2021 05:24:31 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mgVGa9LL5dpb for ; Sun, 18 Jul 2021 05:24:26 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 7BDD43A1DAF for ; Sun, 18 Jul 2021 05:24:26 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id k16so16483713ios.10 for ; Sun, 18 Jul 2021 05:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=y94ruHTOe2iDM6UhV20r1SHPjWTLITugeJLWn7896eo=; b=dWJ5GYOh8LQ0rrCoCLpTN2/DoOLfB3ldFQZR7JFqPhTaw6K0Ed9qYm+fwUWNHjUdsL tc4Rjmt6SPLFnNdlhTr9oShg1vnnjP+0AyDAJxLKdqv0SsVUH3KwPuoOE9pjiwHrPMYb QKluVaQFUGI+C47uYsQVIJfeZsvAHDEc1J5D6S7SPhAem5RzGj/JdAJc5MbAdQ94FVtf hBmh1D8ineHOFrsxLpT20T5vEaIoSGe9K3ief49MHjcbOFl7cndyAt2RM4/EVcAzQHQv k/1OQbEI2cDe5rB0uIJmvlsTE6NNzCyaO2B0upJQAZuQ2l2SvsVf50SiTjfWTRZ8NQf8 b2MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=y94ruHTOe2iDM6UhV20r1SHPjWTLITugeJLWn7896eo=; b=h4/xzh+y7XWi4WgIhfLBuLoc0ZwV83yKLSxsZPtqMTcxilnN2UIsXMUgdtYHZ5i1oL UlrQ/1t1emTwIkTh1J4TAJXGw8n1R1KLXUGq40nyXvPMVIsD0wjJx73dRWOBztihk1YQ bVMFHmli83BAbQoCuFJiA/Ff1+nr1vC4enMnXetEk+sr5f+5B4PX7tcu/f3Li9QBf5aB wWyNAEbbHi9W75FqA2EwdBY8vEKYNraLaiwZPTgURq0C8A22sjApBS25nIJxcqUwdTMv YuGu77fiiD4cIwJJVf5ykyze6fY7cM52i3mrMz0RMgbMx2LUs9U9f2I7hqwvNfr0UJed /Reg== X-Gm-Message-State: AOAM533HCo0AXwjd7RaJzW9RYUHg+xLxHYJeX2z3lZtsoy2ahjDjr5E5 Wlz+TS6aYztQLDWESDFHd4/QdgPmKN5brA== X-Google-Smtp-Source: ABdhPJwR3LBOinLive0ZMIyv4z0nHhu3ZTvntOs0tr2NtfMXjGBfedNFusYKMSu2+yzFUo4z1WHW/A== X-Received: by 2002:a02:7f47:: with SMTP id r68mr16966629jac.127.1626611064972; Sun, 18 Jul 2021 05:24:24 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-182-62-6.red.bezeqint.net. [79.182.62.6]) by smtp.gmail.com with ESMTPSA id c4sm8026676ilq.70.2021.07.18.05.24.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jul 2021 05:24:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.51.21071101 Date: Sun, 18 Jul 2021 15:24:21 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <6E114EAE-0441-4CA0-9F3C-9B689A4A13E7@gmail.com> Thread-Topic: [secdir] W3C VC/DID WG Security Review Coordination Request References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [GNAP] FW: [secdir] W3C VC/DID WG Security Review Coordination Request 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: Sun, 18 Jul 2021 12:24:32 -0000 This may be of interest to people on this list. =EF=BB=BFOn 7/18/21, 00:09, "secdir on behalf of Manu Sporny" wrote: Benjamin, Roman, and the IETF Security Area Directorate, I am writing on behalf of the Chairs, Staff, and Members of multiple cu= rrent chartered W3C Working Groups related to Verifiable Credentials[1] (VCs)= and Decentralized Identifiers[2] (DIDs). The outcome of this message also c= ould affect future W3C Working Groups currently in the pre-chartering proces= s related to RDF Dataset Canonicalization and Hashing, and Linked Data In= tegrity[3]. TL;DR: There are two requests in this message. The first is from the DI= D WG, for a best-effort security review of the Decentralized Identifier Core specification[4] by an appropriate IETF group. The second is from the c= urrent VC and DID WGs, on behalf of themselves and the above-mentioned pre-cha= rter WGs, to set up regular and recurring security reviews of specific W3C specifications that will be developed over the next several years, in a capacity that is more coupled than a traditional W3C-IETF liaison relat= ionship. Both requests are further detailed in the rest of this message. Review of DID Core Specification -------------------------------- Mark Nottingham, Co-Chair of the HTTP WG, recently inquired about the s= ecurity and privacy reviews that were performed on DID Core. The W3C DID WG has performed multiple security and privacy reviews on the specification[6]= , per the W3C process. In addition to those reviews, we are hoping that the I= ETF secdir or CFRG will guide us toward receiving additional security revie= ws on the specification. What would be the best path to getting an initial best-effort security review of the DID Core specification, and subseque= nt security reviews every six months or so on iterations of that specifica= tion? I will note two important considerations. The first is that the initial= DID WG charter expires in September 2021, the specification comes out of the 2= nd W3C Candidate Recommendation phase in mid-July 2021, and according to W3C P= rocess, the DID WG has enough implementation experience (32 implementations for= many features) to move on to the W3C Proposed Recommendation phase. The seco= nd consideration is that the DID WG has only defined a data model and has = not defined any cryptographic algorithms or protocols in this iteration of = the specification. That said, the specification is expected to be used with cryptographic systems, and furthermore, protocol work might be included= in the work of a re-chartered (future) group. Thus, we desire more eyes on th= e specification, especially from IETF Security Area Directorate and IRTF = CFRG. Benjamin and Roman, what mechanism would be most effective for achievin= g a timely, best-effort review of the W3C Decentralized Identifiers specifi= cation? Targeted Engagement with Future DID and VC-related work at W3C -------------------------------------------------------------- Since the Recommendation of the W3C Verifiable Credentials specificatio= n[7], and the expected Recommendation of the W3C Decentralized Identifiers specification[4], there has been increased movement in government and t= he private sector towards issuing credentials for a variety of use cases i= n a production capacity. As a result, it is highly likely that both the W3C Verifiable Credentials WG and the W3C Decentralized Identifiers WG will= be re-chartered to maintain and/or advance the work. In addition, new cryptographic packaging formats and protocols[3][8] ba= sed on active IETF work[9][10] and/or RFCs are expected to be advanced in para= llel. The chartered W3C Working Groups are requesting a more direct liaison relationship that goes beyond periodic reviews of the specifications un= der development by these groups. Ideally, participants in the IETF Security= Area would be active members of these W3C Working Groups with an additional = liaison relationship to groups like the IRTF CFRG. There is a strong expectatio= n that newly chartered groups that are related to the technologies mentioned throughout this email will request the same type of relationship. Benjamin and Roman, what mechanism would be most effective for setting = up this more formal and active relationship between the IETF Security Area and = the W3C Working Groups mentioned above? ----------------------------------------------------- Thank you for your time in considering the questions that we have put f= orward in this message. We know that this is only the beginning of the discuss= ion, so don't expect definitive answers in initial responses, but hope for some concrete guidance on next steps. On behalf of the Editors, Chairs, and Staff contacts for W3C Verifiable Credentials WG and the W3C Decentralized Identifiers WG, -- manu [1]https://www.w3.org/2017/vc/WG/ [2]https://www.w3.org/2019/did-wg/ [3]https://w3c.github.io/lds-wg-charter/ [4]https://w3c.github.io/did-core/ [5]https://github.com/w3c/did-core/issues/768 [6]https://github.com/w3c/did-core/issues/768#issuecomment-869209663 [7]https://www.w3.org/TR/vc-data-model/ [8]https://w3c.github.io/lds-wg-charter/explainer.html [9]https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-cu= rves/ [10]https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/ --=20 Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/ _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Jul 19 14:39:00 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 C058F3A0B6A for ; Mon, 19 Jul 2021 14:38:57 -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 ohFf_iOWiwJa for ; Mon, 19 Jul 2021 14:38:53 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 A75723A0B68 for ; Mon, 19 Jul 2021 14:38:47 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id y42so32629821lfa.3 for ; Mon, 19 Jul 2021 14:38: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=I4Ak98SXZJrehBq2GKyAYch23TNaEwC8ZTqy5AZK/+8=; b=gGiaKvhI0OIb/7d41f+AoOuXRbVkYxhGg+g2wk3GYsopUpmiqTYPubueKqSD+pPTen WqZG7jnEnzc4BunjHBb2WBViRWsL66WbDP8eFu+OXC4okFA/sdR+WBbg/B+qQhjmGZ/h qye8tdPoNun1IFCwvXJvG7Hpp5QrGkKCIb0DilZPGOX0vgSXeqZduzWijTcOSgKCx3h0 g5ovV4V1/B+jr/SUD/cYfsU0w6JgTsJQoYCAFTKSgk/0CugBuGRORvz7PA1d78G3b1vp FEmMrmWl2yDFrRv2Sd9nBCcJpVH3Y7xSFt/wYOcwAcwAkaYwJU80xdv5Nql05kurYHl1 4kYQ== 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=I4Ak98SXZJrehBq2GKyAYch23TNaEwC8ZTqy5AZK/+8=; b=MN6HON5Kbt1HkMVk0Ft+rfHcHAaXJudqXblF7Yp4MFP51KTiV6+HIeKu5diOibuWnu j45gJOnRpKsmxaKGdH13tQi5MELzBOGRi0TT5LlXtG/eex0HeoOGQine3vu8AbPuVomg /TNlBQE9L2FeuPeNG8yaYR4lEGP75dzVs6+N+GBrx/x41AS8vXru6Hx6o/5I5MlInEwH I91Z1r2wqwfSn/H3baWlKDTWG3fdz4cJBkVQ+gRXQJTQIwF4/MdKintNavNDwMP2JZip unACPdnwCPvbRQ/qELQUy6y2JV1Z4sLyHr/EX3bzM5K6CRygVshrLrxSx8QYFJQB16H9 Ekgg== X-Gm-Message-State: AOAM5316RaL/r+E74dCqQzLM3Z+ZureJdAOWi5MSEpwZVWegDneYgejg fgNrUqZoCZv2XrUsqOqrIhU3ln+4VvrJ/gDaVhs= X-Google-Smtp-Source: ABdhPJxaIxUjiA2OXrHAiI6YLKSIiRh2148VCK/3FD/fuo+A5722Zs9n2afVZ9oIOjuZ/yIE5Cixmug4LQ4lXMSQBso= X-Received: by 2002:a19:c7c4:: with SMTP id x187mr19507037lff.621.1626730725074; Mon, 19 Jul 2021 14:38:45 -0700 (PDT) MIME-Version: 1.0 References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: From: Andrii Deinega Date: Mon, 19 Jul 2021 14:38:34 -0700 Message-ID: To: Yaron Sheffer Cc: Adrian Gropper , Fabien Imbault , Thomas Hardjono , Aaron Parecki , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000036d3905c780c3df" 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: Mon, 19 Jul 2021 21:38:58 -0000 --000000000000036d3905c780c3df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG, I shared a couple of my thoughts/ideas on this topic in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105#issuecomment-= 806153772 and would like to bring them here again Another option would be to introduce the client key management URI (similar to Token Management URI) which accepts an object with similar properties to what "DPoP proof JWT" has and where the goal of the AS is to make sure that that the client does have key material. Upsides 1. may work for all currently defined, as well as for future key formats pretty much in the same fashion 2. no need to advertise the client key management URI using the Discovery mechanism which is great and inlined with "the protocol minimizes the need for any pre-flight discovery" 3. each client may have its own (independent) client key management URI Basically, this approach looks similar to what was also suggested before with "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"... Regards, Andrii On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer wrote: > We absolutely need to support key rotation, and I don=E2=80=99t think we = should > assume an external key management service. > > > > To me key rotation simply means a way to identify keys (a key ID) and the > expectation that protocol parties should manage more than one key at a > time: the current key and potentially older keys, up to some validity > period. > > > > If access tokens are bound to long-lived keys, we might need to add an > explicit, non-opaque, key ID to access tokens. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Adrian Gropper < > agropper@healthurl.com> > *Date: *Wednesday, July 7, 2021 at 18:28 > *To: *Fabien Imbault > *Cc: *Justin Richer , Thomas Hardjono = , > GNAP Mailing List , Aaron Parecki > *Subject: *Re: [GNAP] Key Rotation > > > > Whatever we do in terms of scope, GNAP should not ignore this key rotatio= n > 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 leave= s > 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 n= ew > key to sign that signature and present it. The thing that I get hung up o= n > 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 m= echanism. > 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 diffe= rent > 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 y= ou have > other options like CA=E2=80=99s and OCSP to help manage your keys at a di= fferent > 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 c= ould 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 wh= en > 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 rotatio= n > 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 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 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 > =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 se= parately? > =E2=80=A2 Some client instances have registered keys > =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 prov= e > 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 > 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 > > -- 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 > --000000000000036d3905c780c3df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

I shared a couple of my thoughts/ideas on th= is topic in https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/105#issuecomment-806153772 and would like to bring the= m here again

Another option would be to introduce the client key man= agement URI (similar to Token Management URI) which accepts an object with = similar properties to what "DPoP proof JWT" has and where the goa= l of the AS is to make sure that that the client does have key material.
Upsides

1. may work for all currently defined, as well as for f= uture key formats pretty much in the same fashion
2. no need to advertis= e the client key management URI using the Discovery mechanism which is grea= t and inlined with "the protocol minimizes the need for any pre-flight= discovery"
3. each client may have its own (independent) client ke= y management URI

Basically, this approach looks similar to what was = also suggested before with "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 signat= ure and present it"...

Regards,
Andrii


<= div class=3D"gmail_quote">
On Mon, Jul= 12, 2021 at 10:51 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

We absolutely need to support key rotation, and I don=E2=80=99t= think we should assume an external key management service.

=C2=A0

To = me key rotation simply means a way to identify keys (a key ID) and the expe= ctation that protocol parties should manage more than one key at a time: th= e current key and potentially older keys, up to some validity period.

=C2=A0

If access tokens are bound to long-lived keys, we might need to add = an explicit, non-opaque, key ID to access tokens.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=

=C2=A0

From: TXAuth <= txauth-bounces@ietf.org> on behalf of Adrian Gropper <agropper@healthurl.com= >
Date: Wednesday, July 7, 2021 at 18:28
To: Fabien = Imbault <f= abien.imbault@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Thomas H= ardjono <hardjono@= mit.edu>, GNAP Mailing List <txauth@ietf.org>, Aaron Parecki <aaron@parecki.com>
Sub= ject: Re: [GNAP] Key Rotation

=C2=A0

= Whatever we do in terms of scope, GNAP should not ignore this key rotation = issue.=C2=A0

=C2=A0<= /u>

Regardless of what happened in the= era of TLS and IPsec, today we're seeing the limits of federated secur= ity architectures and everyone needs help in the transition to zero-trust a= rchitectures. As I understand it, we're seeing part of this as the diff= erence between OAuth2 client credentials and GNAP.=C2=A0

<= /div>

=C2=A0

If GNAP can do or say something useful about key rotation a= nd client credentials, then I hope we do.

=C2=A0

- Adrian

=C2=A0=

On Wed, Jul 7, 2021 at 10:40 AM= Fabien Imbault <fabien.imbault@gmail.com> wrote:

That's a valid point= (i.e. you might use whatever system you want, as long as you make sure you= r keys are managed) although one could argue we should at the very minimum = provide practical methods to ensure sufficient security. Which means we cou= ld still provide a way native to GNAP, in case people don't have their = preferred method already?

= =C2=A0

Le mer. 7 juil. 2021 = =C3=A0 16:14, Thomas Hardjono <hardjono@mit.edu> a =C3=A9crit=C2=A0:

=


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

Key-rotation is a comm= on 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; Aaro= n 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(k= 2, 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 ge= t hung up on is having a way to do the key proofing for a new key that work= s 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 me= chanism. The trick is carrying a signed object with the key material intern= ally somehow =E2=80=94 is there a way to handle that consistently across di= fferent proofing types?

There are a bunch of ways that it could be d= one with different proofing mechanisms and that might be the right approach= . HTTP Message Signatures can attach multiple signatures. JWK-based-keys co= uld use JWS to wrap the key content as part of the payload (so you=E2=80=99= d 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 OCS= P to help manage your keys at a different level. So maybe GNAP just specifi= es the functional requirement at a high level and each proofing mechanism o= r deployment has to fill that somehow in its definition?

Still, some= thing in me says that we should be able to do this in one consistent patter= n, 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. Th= is 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 <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">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 ca= ses, to say the least. It's quite impressive how often that breaks (usu= ally when a certificate expires somewhere).

The exception is caddy s= erver, 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 d= o 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 b= e 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 today= .

Coming up with the actual rotation method is definitely an interes= ting challenge, but there must be some prior art to draw from here. Wouldn&= #39;t existing specs like Mutual TLS or even PGP have some mechanism that c= ould be reused?

Aaron


On Tue, Jun 15, 2021 at 10:52 AM Ju= stin Richer <jriche= r@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 tho= se keys as part of the request, both dynamically and as part of some pre-re= gistration 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.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Access tokens are bound to ke= ys
=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 tr= ansactions are also bound to keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =E2=80=A2 Specifically: 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 is 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 the clien= t 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 happens when a client=E2= =80=99s registered key rotates?


Secure rotation of a key would r= equire some way for the presenter to prove possession of both the old and n= ew keys simultaneously. It could be a matter of signing the request with th= e new key and include some artifact signed by the old key in the request, o= r the inverse of that. There are likely other methods out there, but this s= eems simplest.

What situations are people looking at for handling ke= y rotation?

=C2=A0=E2=80=94 Justin
--
TXAuth mailing list
<= a href=3D"mailto:TXAuth@ietf.org" target=3D"_blank">TXAuth@ietf.org<= mailto:TXAuth@ietf.org= >
https://www.ietf.org/mailman/listinfo/txauth
--
TXAut= h mailing list
TXAu= th@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth=

-- TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

-- TXAuth mailin= g list TXAuth@ietf.org= https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000036d3905c780c3df-- From nobody Mon Jul 19 15:06:12 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 CCEAF3A0CC7 for ; Mon, 19 Jul 2021 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 EvZ5mUZ_fOIp for ; Mon, 19 Jul 2021 15:06:05 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 EC9383A0CC6 for ; Mon, 19 Jul 2021 15:06:04 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 16JM5mOR015633; Mon, 19 Jul 2021 18:06:02 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 19 Jul 2021 18:05:45 -0400 Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Jul 2021 18:05:42 -0400 Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1497.015; Mon, 19 Jul 2021 18:05:42 -0400 From: Thomas Hardjono To: Yaron Sheffer CC: GNAP Mailing List , Justin Richer Thread-Topic: [GNAP] Key Rotation Thread-Index: AQHXcq30x3d65dOot0G/DKz6SzbJvas2yuKAgAEC+gD//8EV14AASr8AgAANP4CACAO6AIALP+IA///BD/c= Date: Mon, 19 Jul 2021 22:05:42 +0000 Message-ID: References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.100.88.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 19 Jul 2021 22:06:10 -0000 Hi Yaron, >>> To me key rotation simply means a way to identify keys (a key ID) and=20 >>> the expectation that protocol parties should manage more than one key a= t a time:=20 >>> the current key and potentially older keys, up to some validity period. So perhaps we need to use tighter words or definitions, specially if the go= al is for GNAP to have wide adoption and co-exist with existing infra. I think a Key-ID makes sense because that's how many systems today identify= keys in their key-database (e.g. SA database in IPsec). The question becomes *what* exactly is a Key-ID in the context of GNAP. Is it an Octet string of a given length (i.e. with length less than or equa= l the key-length in bits)? >>> I don=92t think we should assume an external key management service. Wanting a KeyID to identify crypto keys is different from wanting a key man= agement protocol that implements a key lifecycle (e.g. that includes key-ge= n, key rotation, key deletion, key archiving, etc. etc.). Best --thomas ________________________________________ On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer > wrote: We absolutely need to support key rotation, and I don=92t think we should a= ssume an external key management service. To me key rotation simply means a way to identify keys (a key ID) and the e= xpectation that protocol parties should manage more than one key at a time:= the current key and potentially older keys, up to some validity period. If access tokens are bound to long-lived keys, we might need to add an expl= icit, non-opaque, key ID to access tokens. Thanks, Yaron From: TXAuth > on b= ehalf of Adrian Gropper > Date: Wednesday, July 7, 2021 at 18:28 To: Fabien Imbault > Cc: Justin Richer >, Thomas Hardjon= o >, GNAP Mailing List >, Aaron Parecki > Subject: Re: [GNAP] Key Rotation 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 seein= g 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 creden= tials, 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 long = as you make sure your keys are managed) although one could argue we should = at the very minimum provide practical methods to ensure sufficient security= . Which means we could still provide a way native to GNAP, in case people d= on't have their preferred method already? Le mer. 7 juil. 2021 =E0 16:14, Thomas Hardjono > a =E9crit : 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 b= ehalf 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=92s a great point about static registration. That leaves epheme= ral or otherwise runtime keys, which might be good enough to just start a n= ew 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=92s the GNAP key proofing mechanism. The trick is= carrying a signed object with the key material internally somehow =97 is t= here a way to handle that consistently across different proofing 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=92d get something like a nested JWT). M= TLS is a strange one, but if you=92re in certificate space you have other o= ptions like CA=92s 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 defi= nition? Still, something in me says that we should be able to do this in one consis= tent pattern, and I=92d love to hear more ideas on how that could be handle= d. If we can crack that, then it becomes a matter of applying that to a bun= ch of different requests: grant update, token rotation, initial request, et= c. This piece, at least, I believe can be applied pretty generically. =97 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 prod= uction. 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 =E0 23:29, Aaron Parecki >> a =E9c= rit : I do think it's important that a client instance should be able to rotate i= ts 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 rota= ting 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 t= o the client instance, more like how typical OAuth clients work today. 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 existin= g specs like Mutual TLS or even PGP have some mechanism that could be reuse= d? 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 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. =95 Access tokens are bound to keys =95 We allow rotation of the token value at client instance= request... =95 Should we allow rotation of the key also? =95 Grant transactions are also bound to keys =95 Specifically: the continuation access token is bound to= a key =95 The key is initially the client instance=92s key =95 Should the client be able to rotate this key separately= ? =95 Some client instances have registered keys =95 What happens when a client=92s 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? =97 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 -- 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 From nobody Wed Jul 21 08:09:05 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 12B803A1B38 for ; Wed, 21 Jul 2021 08:09:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xUzoscLmh-3Z for ; Wed, 21 Jul 2021 08:08:58 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 3D17D3A1B37 for ; Wed, 21 Jul 2021 08:08:58 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id r18so2721571iot.4 for ; Wed, 21 Jul 2021 08:08:58 -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=1QYlo13S+ux4+khJINld8EIQ8mw0Vioq7dav5Jh0Km4=; b=H9NMJmIe77ksp73A2SqH/HkMosR/+Q60nRYgPFAoIo9Vm4MhhX+lANf7QIYFxM0/6q EpNG+zIE4414dRHAN2NJbOgfDk3CAvnZ9o3uIhmC0cT1oGetuwLajaKCcbQ0tyzAc+Y5 In1Y5W/KpIj0kYb1Ei5LafX1hTYpMBknrHw2S6Zeq68x7RvvFmUFidOfb2HFwkXJbR0U 6Ou9t0RLO42WYJYgry+HLft1jAEspr045m+Vloe3/jkpDQJsYyxDl9IsNYgRj34JLeXA nJMjzaoaEXbiFRFPtqU1iYb5GX2qKaV7TwaLtI651xWar6N3l9qhhGMdpPfbH2hpWZd/ TCqw== 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=1QYlo13S+ux4+khJINld8EIQ8mw0Vioq7dav5Jh0Km4=; b=M7PlbNnNbbRltKeWsgR1wkNBpEOXVn3z0jpX3uwFr/aomVVwjbCWEjnBvLPpL8KMmN rrL3fvPoPR5mMYzIxFYaW7Y/cDQRAfXZ+8bzewVgaWrfH8P9B5yNCOOYZDuveTeu4h0P yS8wiignTADCG30X2p409MjoxIMjGOlSQo2Lbt9luU1/DxJpYwPMRxS2AgkiyPFHhjHG rBSUJjN0Be4I+vrd6nSfPlgBSzT9GuyOqE6EbCzwFS/8/KTCfBL7a+L4HWbQ3uI3c/x4 h9P9V/rSMRp5AoglXPXpmYKSe4rwJkqT7RK+6mduSRCKsudrPlE+4yu6Gb/e08oV2zdy mRmA== X-Gm-Message-State: AOAM533PQI55C0Xly9nXEX6zbSaBLuu3JgOfR/21BqKgvjaP2IDwa5aE ptghabbQkCJpr8I7WWx8GPAL9H7S1QcL3tE4RSM= X-Google-Smtp-Source: ABdhPJw+H0HMvOG2GY/I7OGGi5cYDg/depA/PkV0zX/qCOrHLMdVyFeczdZWvqrttoCEkszM3WgDZLNCsJAVUFOIOCc= X-Received: by 2002:a02:a38f:: with SMTP id y15mr32013439jak.108.1626880135558; Wed, 21 Jul 2021 08:08:55 -0700 (PDT) MIME-Version: 1.0 References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 21 Jul 2021 17:08:44 +0200 Message-ID: To: Thomas Hardjono Cc: Yaron Sheffer , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000927b0405c7a38c49" 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, 21 Jul 2021 15:09:04 -0000 --000000000000927b0405c7a38c49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, We already identify keys in the protocol, cf 7.1.1 key references. In that same section, we are quite open to any mechanism ("The means of dereferencing this value are out of scope for this specification"). Does that cover your concerns? Cheers Fabien Le mar. 20 juil. 2021 =C3=A0 00:06, Thomas Hardjono a = =C3=A9crit : > > Hi Yaron, > > >>> To me key rotation simply means a way to identify keys (a key ID) and > >>> the expectation that protocol parties should manage more than one key > at a time: > >>> the current key and potentially older keys, up to some validity perio= d. > > So perhaps we need to use tighter words or definitions, specially if the > goal is for GNAP to have wide adoption and co-exist with existing infra. > > I think a Key-ID makes sense because that's how many systems today > identify keys in their key-database (e.g. SA database in IPsec). > > The question becomes *what* exactly is a Key-ID in the context of GNAP. > > Is it an Octet string of a given length (i.e. with length less than or > equal the key-length in bits)? > > > > >>> I don=E2=80=99t think we should assume an external key management se= rvice. > > Wanting a KeyID to identify crypto keys is different from wanting a key > management protocol that implements a key lifecycle (e.g. that includes > key-gen, key rotation, key deletion, key archiving, etc. etc.). > > > > Best > > --thomas > > > > ________________________________________ > > On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer > wrote: > > We absolutely need to support key rotation, and I don=E2=80=99t think we = should > assume an external key management service. > > To me key rotation simply means a way to identify keys (a key ID) and the > expectation that protocol parties should manage more than one key at a > time: the current key and potentially older keys, up to some validity > period. > > If access tokens are bound to long-lived keys, we might need to add an > explicit, non-opaque, key ID to access tokens. > > Thanks, > Yaron > > From: TXAuth > on > behalf of Adrian Gropper agropper@healthurl.com>> > Date: Wednesday, July 7, 2021 at 18:28 > To: Fabien Imbault fabien.imbault@gmail.com>> > Cc: Justin Richer >, Thomas > Hardjono >, GNAP Mailing List < > txauth@ietf.org>, Aaron Parecki > > Subject: Re: [GNAP] Key Rotation > > Whatever we do in terms of scope, GNAP should not ignore this key rotatio= n > 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 hardjono@mit.edu>> 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 leave= s > 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 n= ew > key to sign that signature and present it. The thing that I get hung up o= n > 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 m= echanism. > 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 diffe= rent > 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 y= ou have > other options like CA=E2=80=99s and OCSP to help manage your keys at a di= fferent > 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 c= ould 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>>> 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 wh= en > 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 rotatio= n > 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 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 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 > =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 se= parately? > =E2=80=A2 Some client instances have registered keys > =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 prov= e > 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 TXAuth@ietf.org>> > https://www.ietf.org/mailman/listinfo/txauth > -- > TXAuth mailing list > TXAuth@ietf.org 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 > -- > 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 > --000000000000927b0405c7a38c49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,

We already identify keys in the protocol, = cf 7.1.1 key references. In that same section, we are quite open to any mec= hanism ("The means of dereferencing this value are ou= t of scope for this specification").=C2=A0
Does that cover your concerns?

Cheers
Fabien

Le mar. 20 juil. 2021 =C3=A0 00:06,= Thomas Hardjono <= hardjono@mit.edu> a =C3=A9crit=C2=A0:

Hi Yaron,

>>> To me key rotation simply means a way to identify keys (a key = ID) and
>>> the expectation that protocol parties should manage more than = one key at a time:
>>> the current key and potentially older keys, up to some validit= y period.

So perhaps we need to use tighter words or definitions, specially if the go= al is for GNAP to have wide adoption and co-exist with existing infra.

I think a Key-ID makes sense because that's how many systems today iden= tify keys in their key-database (e.g. SA database in IPsec).

The question becomes *what* exactly is a Key-ID in the context of GNAP.

Is it an Octet string of a given length (i.e. with length less than or equa= l the key-length in bits)?



>>>=C2=A0 I don=E2=80=99t think we should assume an external key m= anagement service.

Wanting a KeyID to identify crypto keys is different from wanting a key man= agement protocol that implements a key lifecycle (e.g. that includes key-ge= n, key rotation, key deletion, key archiving, etc. etc.).



Best

--thomas



________________________________________

On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer <yaronf.ietf@gmail.com= <mailto:yaronf.ietf@gmail.com>> wrote:

We absolutely need to support key rotation, and I don=E2=80=99t think we sh= ould assume an external key management service.

To me key rotation simply means a way to identify keys (a key ID) and the e= xpectation that protocol parties should manage more than one key at a time:= the current key and potentially older keys, up to some validity period.
If access tokens are bound to long-lived keys, we might need to add an expl= icit, non-opaque, key ID to access tokens.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

From: TXAuth <txauth-bounces@ietf.org<mailto:txauth-bou= nces@ietf.org>> on behalf of Adrian Gropper <agropper@heal= thurl.com<mailto:agropper@healthurl.com>>
Date: Wednesday, July 7, 2021 at 18:28
To: Fabien Imbault <fabien.imbault@gmail.com<mailto:f= abien.imbault@gmail.com>>
Cc: Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>>, = Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu>>= , GNAP Mailing List <txauth@ietf.org<mailto:txauth@ietf.org>>= , Aaron Parecki <aaron@parecki.com<mailto:aaron@parecki.com>= >
Subject: Re: [GNAP] Key Rotation

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 se= eing 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 creden= tials, then I hope we do.

- Adrian

On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <fabien.imbault@gma= il.com<mailto:fabien.imbault@gmail.com>> wrote:
That's a valid point (i.e. you might use whatever system you want, as l= ong as you make sure your keys are managed) although one could argue we sho= uld at the very minimum provide practical methods to ensure sufficient secu= rity. Which means we could still provide a way native to GNAP, in case peop= le don't have their preferred method already?

Le mer. 7 juil. 2021 =C3=A0 16:14, Thomas Hardjono <hardjono@mit.edu&l= t;mailto:hardjono@mit.edu>> a =C3=A9crit :

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<mailto:txauth-bounce= s@ietf.org>] on behalf of Justin Richer [jricher@mit.edu<mailto:= jri= cher@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.imbault@gmail.c= om<mailto:fabien.imbault@gmail.com><mailto:f= abien.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 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@parecki.com&l= t;mailto:aaron@parecki.com><mailto:aaron@parecki.com<mailto:= a= aron@parecki.com>>> a =C3=A9crit :
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<mail= to:= jricher@mit.edu><mailto:jricher@mit.edu<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
TXA= uth@ietf.org<mailto:TXAuth@ietf.org><mailto:TXAuth@ietf.org&= lt;mailto:TXAuth@ietf.org>>
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org<mailto:TXAuth@ietf.org><mailto:TXAuth@ietf.org&= lt;mailto:TXAuth@ietf.org>>
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth<= /a>
-- TXAuth mailing list TXAuth@ietf.org<mailto:TXAuth@ietf.org> https://www.ietf.org/mailman/listinfo/txauth<= br> --
TXAuth mailing list
TXA= uth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000927b0405c7a38c49-- From nobody Wed Jul 21 09:04:19 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 E22353A1D2F for ; Wed, 21 Jul 2021 09:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.186 X-Spam-Level: X-Spam-Status: No, score=-4.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 R9t6xhqVhF69 for ; Wed, 21 Jul 2021 09:04:10 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 57B953A1D22 for ; Wed, 21 Jul 2021 09:04:09 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 16LG3nXN006442; Wed, 21 Jul 2021 12:04:07 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 21 Jul 2021 12:03:26 -0400 Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 21 Jul 2021 12:03:40 -0400 Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1497.023; Wed, 21 Jul 2021 12:03:33 -0400 From: Thomas Hardjono To: Fabien Imbault CC: Yaron Sheffer , GNAP Mailing List , Justin Richer Thread-Topic: [GNAP] Key Rotation Thread-Index: AQHXcq30x3d65dOot0G/DKz6SzbJvas2yuKAgAEC+gD//8EV14AASr8AgAANP4CACAO6AIALP+IA///BD/eAAvawAP//yj0L Date: Wed, 21 Jul 2021 16:03:33 +0000 Message-ID: References: <32D204BA-990A-4E91-B0D2-28D3A8AD8474@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.100.88.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 21 Jul 2021 16:04:17 -0000 Thanks Fabien, My general concern was GNAP going into specifying a full key management pro= tocol (which is not a bad idea in itself, but would probably need a separat= e WG). Section 7.1.1 is good (including the line on dereferencing). Also, related to the discussion on "key rotation", I think Section 6.1 and= 6.2 is good. Best --thomas ________________________________________ From: Fabien Imbault [fabien.imbault@gmail.com] Sent: Wednesday, July 21, 2021 11:08 AM To: Thomas Hardjono Cc: Yaron Sheffer; GNAP Mailing List; Justin Richer Subject: Re: [GNAP] Key Rotation Hi Thomas, We already identify keys in the protocol, cf 7.1.1 key references. In that = same section, we are quite open to any mechanism ("The means of dereferenci= ng this value are out of scope for this specification"). Does that cover your concerns? Cheers Fabien Le mar. 20 juil. 2021 =E0 00:06, Thomas Hardjono > a =E9crit : Hi Yaron, >>> To me key rotation simply means a way to identify keys (a key ID) and >>> the expectation that protocol parties should manage more than one key a= t a time: >>> the current key and potentially older keys, up to some validity period. So perhaps we need to use tighter words or definitions, specially if the go= al is for GNAP to have wide adoption and co-exist with existing infra. I think a Key-ID makes sense because that's how many systems today identify= keys in their key-database (e.g. SA database in IPsec). The question becomes *what* exactly is a Key-ID in the context of GNAP. Is it an Octet string of a given length (i.e. with length less than or equa= l the key-length in bits)? >>> I don=92t think we should assume an external key management service. Wanting a KeyID to identify crypto keys is different from wanting a key man= agement protocol that implements a key lifecycle (e.g. that includes key-ge= n, key rotation, key deletion, key archiving, etc. etc.). Best --thomas ________________________________________ On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer >> wrote: We absolutely need to support key rotation, and I don=92t think we should a= ssume an external key management service. To me key rotation simply means a way to identify keys (a key ID) and the e= xpectation that protocol parties should manage more than one key at a time:= the current key and potentially older keys, up to some validity period. If access tokens are bound to long-lived keys, we might need to add an expl= icit, non-opaque, key ID to access tokens. Thanks, Yaron From: TXAuth >> on behalf of Ad= rian Gropper >> Date: Wednesday, July 7, 2021 at 18:28 To: Fabien Imbault >> Cc: Justin Richer >>, Thomas Hardjono >>, GNAP = Mailing List >>, Aaron Parecki >> Subject: Re: [GNAP] Key Rotation 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 seein= g 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 creden= tials, 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 long = as you make sure your keys are managed) although one could argue we should = at the very minimum provide practical methods to ensure sufficient security= . Which means we could still provide a way native to GNAP, in case people d= on't have their preferred method already? Le mer. 7 juil. 2021 =E0 16:14, Thomas Hardjono >> a =E9cri= t : 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 Ju= stin 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=92s a great point about static registration. That leaves epheme= ral or otherwise runtime keys, which might be good enough to just start a n= ew 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=92s the GNAP key proofing mechanism. The trick is= carrying a signed object with the key material internally somehow =97 is t= here a way to handle that consistently across different proofing 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=92d get something like a nested JWT). M= TLS is a strange one, but if you=92re in certificate space you have other o= ptions like CA=92s 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 defi= nition? Still, something in me says that we should be able to do this in one consis= tent pattern, and I=92d love to hear more ideas on how that could be handle= d. If we can crack that, then it becomes a matter of applying that to a bun= ch of different requests: grant update, token rotation, initial request, et= c. This piece, at least, I believe can be applied pretty generically. =97 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 prod= uction. 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 =E0 23:29, Aaron Parecki >>>> a =E9crit : I do think it's important that a client instance should be able to rotate i= ts 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 rota= ting 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 t= o the client instance, more like how typical OAuth clients work today. 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 existin= g specs like Mutual TLS or even PGP have some mechanism that could be reuse= d? 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 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. =95 Access tokens are bound to keys =95 We allow rotation of the token value at client instance= request... =95 Should we allow rotation of the key also? =95 Grant transactions are also bound to keys =95 Specifically: the continuation access token is bound to= a key =95 The key is initially the client instance=92s key =95 Should the client be able to rotate this key separately= ? =95 Some client instances have registered keys =95 What happens when a client=92s 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? =97 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 -- TXAuth mailing list TXAuth@ietf.org> https://www.ietf.org/mailman/listinfo/t= xauth -- 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 From nobody Fri Jul 23 09:28:27 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 89FC93A0A0C for ; Fri, 23 Jul 2021 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g0uJctW4UjfD for ; Fri, 23 Jul 2021 09:28:21 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 2A5433A0A0A for ; Fri, 23 Jul 2021 09:28:21 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id l126so3189455ioa.12 for ; Fri, 23 Jul 2021 09:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=GFju9uKLqJa4jJ+xfL7Lt5rL5TZhJ34OQouxRr5MFrg=; b=t8ubqDE2aBVSt82w0muSVawrrO/AEPRsLda/KbVjaOA+Ql1QeMORorEL8vpvd9x6uw u1LC2k2HlYvYCsl385ehdJGiK+PhVQvNSD6jHqWe9Dv4O1SQU4lovzmig8GvUfwdwTf0 2WMliShLfrscdeBJkStuCC6o8+SRz9MFHFEV+M+mehN3TBUJJzcI06tYUrrepOyX4RHT asJjzog6gMNzHMj/sFvK/2Lraoxa0oPgNEa9mkP3aHDGSedakJnc0va8Bl10WMP4zKCD m8J9Hh3IWamlmvDQ0T/pLo8eUAnZyxDrqsNvgYYwf8Ny2gSIZcoedm5ikzg03YIHRG7Q hdXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=GFju9uKLqJa4jJ+xfL7Lt5rL5TZhJ34OQouxRr5MFrg=; b=PSzTjU7tScBcqGMAzzPoUKuo+axQAHCkpNhykCHHKB8wGGN5eM4ZneFj1mXexKQ/pw 3Q2hjzWYSQy/xu9fKrFGzWNKRz9l1fsLarY7mUOHTGYiBzQeONaaV5zkztS32BeJHvdC AkKPz8aRFjWcp8BsLzix089vd7FvBwBl1nX1IVDJFVBgc1LZCgXusQzMFBi/Pf4n9W5F WdKw2A/8tfme7tenwUcc4wrK2/LRgBsA915DQrxmSLzgGsJXuA36ZJIp5h9YhQtsTbsA +cc/FX96JLeRERBaWUHOxeWlufe1tPkFXUtxFYI6yem8Xqqr+IZ6hf6rVEl6wMSvvcVy YcQA== X-Gm-Message-State: AOAM531wDLvC0TDzYkiEjNszI1medosAihKEm8nGk6+iemfliLTodMSa qU0WeGcVJLxxfpJymSFM6PScMd3dLxM= X-Google-Smtp-Source: ABdhPJxcFPo7PcXAPliCEtjQgX8I6WptBCXv/TgSvU+9XX5/jInibr+h7Z4c5z9pOOxlS00VyET4fQ== X-Received: by 2002:a6b:e417:: with SMTP id u23mr4536263iog.91.1627057699690; Fri, 23 Jul 2021 09:28:19 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-181-28-50.red.bezeqint.net. [79.181.28.50]) by smtp.gmail.com with ESMTPSA id o8sm16651030ils.24.2021.07.23.09.28.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jul 2021 09:28:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.51.21071101 Date: Fri, 23 Jul 2021 19:28:17 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <40B0F7A9-ED22-4142-B72A-D22419B05314@gmail.com> Thread-Topic: Agenda for GNAP at IETF-111 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3709913298_606576197" Archived-At: Subject: [GNAP] Agenda for GNAP at IETF-111 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: Fri, 23 Jul 2021 16:28:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3709913298_606576197 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, =20 I have posted the agenda for the meeting next Monday: https://datatracker.i= etf.org/doc/agenda-111-gnap/ =20 19:00-19:10 UTC - Chair intro =20 19:10-19:30 GNAP interaction with VC-HTTP API W3C work, Adrian Gropper =20 19:30-20:50 Core protocol and Resource Server drafts - editors =20 20:50-21:00 Next steps: chairs =20 =20 =20 Kathleen Moriarty will be co-chairing the session with me =E2=80=93 many thanks f= or your help Kathleen! =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3709913298_606576197 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

I have posted the agenda for the meeting next Monday: https://datatracker= .ietf.org/doc/agenda-111-gnap/

<= span style=3D'font-size:11.0pt'> 

19:00-19:10 UTC - Chair intro

 

19:10-19:30 GNAP = interaction with VC-HTTP API W3C work, Adrian Gropper

<= p class=3DMsoNormal> 

19:30-20:50 Core protocol= and Resource Server drafts - editors

 

20:50-21:00 Next steps: chairs=

 

 

 =

Kathleen = Moriarty will be co-chairing the session with me =E2=80=93 many thanks for your he= lp Kathleen!

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

--B_3709913298_606576197-- From nobody Fri Jul 23 15:06:16 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 ED4103A1E0C for ; Fri, 23 Jul 2021 15:06:13 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 x0k9XvqaJnvC for ; Fri, 23 Jul 2021 15:06:12 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 18CC23A1E07 for ; Fri, 23 Jul 2021 15:06:11 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id 10so2861490ill.10 for ; Fri, 23 Jul 2021 15:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=iK35ycknDo6Nfvj5/cMSjSgkUl8MlIq8/8KeLwTBEoI=; b=I70Uz6hwkIHM5B3guwZQVg96A6TUSEjZCpBBfqzUUlVfAskP8w9mWCODcKnu6vyViU qFuJajqp/MSHDKGswMv1qI2s0I8oQyeYwl6uHSFKpMuPwwR/grDt2ZVLh9nD6NpRBNgL 7ZT4FN7cgH50/L+J2CTmOJHmnT/b6Usuk1Ad5egXPmtrDFRqq9UwT9WubCwkQBnTAUSJ +WDIAKYmIYdXzteeaxVFjE7gpjE89hIf9ZSPpzGVUG0Xze08t9MIGY14T3ysmfnr6i/R CcAIfxE/WXT9LF6EuDQBF9ntrQEved+UOH4WEyJr8x+VlxJnwl0DN8ZKgLwZwkT3JDmb 9S8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=iK35ycknDo6Nfvj5/cMSjSgkUl8MlIq8/8KeLwTBEoI=; b=XC/0RzRDR7EajA6MlK0gfuB3BJBvpBa7g+t4WkEquJPJFIufnOGk45zgOt/FrCiFXL S8qQ2YyE1mdmT+nJ38HO8NIod9D5NQUDxJfvjyJtonaoAfmH5IAtctIRT+9lf2sctxzR bz/My+YQU7Qhexf2NTjJocnuTFhZV3yirKHR8Wzvx6jEE4MOvaSFOyvnDI3QoY0Hm4Ir m7AHH0CNnzXHPBuQk4mmgrro/c4FCmXscUFJnDwuwLgXYZKQRWnbFnkLxGxyDcFGamjI pmofoAuxtVIsmDCe1mUlElzykdPOBY2p6p3dcW32wSqi/GaaV/Ugcuq4w98p+jvvgqSG 3pdw== X-Gm-Message-State: AOAM530QeXDkW8olCsWrozNBWtHRaO/DgVaYPJbfCaqECqXzvOSFpoYz zY5aZ7P+CRio3KcCMP5We3t5TehfrbE= X-Google-Smtp-Source: ABdhPJw4S/SkNoJ2eTCyzPRtqLQsic9yVTksKniDI7XgfoRozuYFq3VQrX0YADYfgkrffURGIXlwsg== X-Received: by 2002:a92:d0d2:: with SMTP id y18mr4841517ila.24.1627077970405; Fri, 23 Jul 2021 15:06:10 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-181-28-50.red.bezeqint.net. [79.181.28.50]) by smtp.gmail.com with ESMTPSA id a1sm9398117ilp.1.2021.07.23.15.06.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jul 2021 15:06:10 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.51.21071101 Date: Sat, 24 Jul 2021 01:06:07 +0300 From: Yaron Sheffer To: GNAP Mailing List CC: Kathleen Moriarty Message-ID: Thread-Topic: Minute taker for the GNAP meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3709933569_2091913888" Archived-At: Subject: [GNAP] Minute taker for the GNAP meeting 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: Fri, 23 Jul 2021 22:06:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3709933569_2091913888 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We are meeting on the very first session of the IETF meeting on Monday. As = usual, we will need a minute taker, please let me and Kathleen know if you=E2=80= =99re willing to volunteer. =20 (If you are new to IETF or GNAP, this is a good opportunity to get to know = the people.) =20 Thanks, and enjoy your pre-IETF weekend! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3709933569_2091913888 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We are meeting on the very first session of the IETF meeti= ng on Monday. As usual, we will need a minute taker, please let me and Kathl= een know if you=E2=80=99re willing to volunteer.

 

(If you are new to IETF or GNAP, thi= s is a good opportunity to get to know the people.)

 

<= p class=3DMsoNormal>Thanks, and enjoy your pre-= IETF weekend!

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

<= /body> --B_3709933569_2091913888-- From nobody Sun Jul 25 00:41:10 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 332223A1AAD for ; Sun, 25 Jul 2021 00:41:05 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=XYdUG35o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NrJKIs1e 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 4s3Nz7F7InR9 for ; Sun, 25 Jul 2021 00:40:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26E03A1AAE for ; Sun, 25 Jul 2021 00:40:58 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D565C5C00F0 for ; Sun, 25 Jul 2021 03:34:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 25 Jul 2021 03:34:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=EE1wkygLrOv MvOVmzEUTL2jApKUk0PbwkjP6qyghhiI=; b=XYdUG35otQXZmRppBRbcUXA0ex+ ax3dz0BsWrwGaifc6m0qo/Fc8dZT7y7irbohgxi49cEMg+f3aWABqxL/aRF6jtk5 jcv4I/C/HI09/LSWi6CNOevJJKLbVZSwSfkMDbxfVrex+oL/IYH7024SlsZ4SD2h AraHoMen9UCCl22RfhkbZ8F9sU0XSD9Q1h3K+lw+miSoReo5clMbndZHNH5qU+13 CCXS9QYqLhAinTRG3MkOz1i8v9mdMh9jWJnWchg67v2hw50anaCPJZAyGOEiHOac TuHLx0Lg/TEytTyqBONYJ63A+QiQironTgBd5x6+huIDfW302yVm+nfh1aQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=EE1wkygLrOvMvOVmzEUTL2jApKUk0PbwkjP6qyghhiI=; b=NrJKIs1e dg/fEFmhr3eTW+CmUuQaDu2TpmrjZ0TQQxfQBR2SVDtRSph7KkLeD6rxEdi2loAZ iW5LHWi5Ie1bgqyDs9RibYZ5ZNX4ekphilDp1UUZvyZkWWYaf79pfDncBYI3v7xG mphC+lNsIYdZqJGZrswMgvtvCEI9z9sPU3xwCT6S972JASu0S5Ypn1jF1wUPa519 cnmAKiP71yaWrLx51xsSHOlWU7fqOeOkOzofKR94r57DzGkF6EpJp/LKepU86YF7 EIHpz3ln+IAXNJqbPHPqNiHxVL4SyP/RzGOcHBTV8jRSg05rRUVAahPfJ3we1BNS Q1Qg2jLE7Wf4qQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgedugdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 25 Jul 2021 03:34:19 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8036894677650947326==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210725074058.E26E03A1AAE@ietfa.amsl.com> Date: Sun, 25 Jul 2021 00:40:58 -0700 (PDT) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) 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: Sun, 25 Jul 2021 07:41:05 -0000 --===============8036894677650947326== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+2/-12/=F0=9F=92=AC68) 2 issues created: - Re-opening of: In practice, only rights are supported but attributes sh= ould also be supported (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/296=20 - In practice, only rights are supported but attributes should also be = supported (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/295=20 23 issues received 68 new comments: - #296 Re-opening of: In practice, only rights are supported but attribut= es should also be supported (11 by Denisthemalice, aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/296=20 - #295 In practice, only rights are supported but attributes should als= o be supported (6 by Denisthemalice, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/295=20 - #293 Token Management functions are over-engineering (3 by Denisthemali= ce, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/293=20 - #292 Does a client instance really need to be identified by a unique ke= y ? (3 by Denisthemalice, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/292=20 - #291 Requesting RO Information or Requesting Subject Information? (2 by= Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/291=20 - #290 Checks needed to defeat user collaborative attacks are unfortunate= ly out of the scope of the document (14 by Denisthemalice, aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/290=20 - #289 Bearer tokens should not be supported or be deprecated (5 by Denis= themalice, aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/289=20 - #288 Since both rights and resource locations must be disclosed to the = AS, the AS can act as Big Brother (4 by Denisthemalice, agropper, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/288=20 - #287 About the locations field (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/287=20 - #286 In practice, only rights are supported but attributes should also = be supported (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/286=20 - #285 The diagram of the exchanges is mandating a pre-configuration betw= een each pair of AS/RS (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/285=20 - #284 The document is confusing a Resource Server (RS) with a Protected = Resource (2 by aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/284=20 - #283 User consent is not supported (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/283=20 - #282 The client has no effective control upon the content of an access = token (2 by aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/282=20 - #281 The client is unable to know that a RS is associated with more tha= n one AS (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/281=20 - #280 The access token is opaque to the client instance: transparency ca= nnot be achieved (2 by aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/280=20 - #279 Trust relationships between ROs and ASs and between ROs and RSs ar= e left undefined (2 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/279=20 - #278 Trust relationships are still undefined (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/278=20 - #277 No access token structure is being defined or referenced (1 by jri= cher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/277=20 - #276 The document is currently unable to follow the standards track (1= by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/276=20 - #244 Refactoring the internals of access request (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/244=20 - #215 User choice and consent, and user notice (1 by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215=20 - #214 Trust relationships (1 by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214=20 12 issues closed: - Refactoring the internals of access request https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/244=20 - Trust relationships between ROs and ASs and between ROs and RSs are lef= t undefined https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/279=20 - In practice, only rights are supported but attributes should also be = supported https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/295=20 - The document is currently unable to follow the standards track https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/issues/276=20 - No access token structure is being defined or referenced https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/277=20 - Trust relationships are still undefined https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/278=20 - The access token is opaque to the client instance: transparency cannot = be achieved https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/280=20 - The client is unable to know that a RS is associated with more than one= AS https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/281=20 - The client has no effective control upon the content of an access token= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/282=20 - User consent is not supported https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/283=20 - The document is confusing a Resource Server (RS) with a Protected Resou= rce https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/284=20 - In practice, only rights are supported but attributes should also be su= pported https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/286=20 * ietf-wg-gnap/gnap-resource-servers (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #39 =E2=80=9CRS-Facing API=E2=80=9D versus =E2=80=9CAS-Facing API=E2=80= =9D (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/39=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC2) 2 pull requests submitted: - added editorconfig processor (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/297=20 - add editorconfig (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/294=20 2 pull requests received 2 new comments: - #297 added editorconfig processor (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/297=20 - #294 add editorconfig (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/294=20 1 pull requests merged: - add editorconfig https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/294=20 * ietf-wg-gnap/gnap-resource-servers (+1/-2/=F0=9F=92=AC1) 1 pull requests submitted: - adds .editorconfig and cleans up trailing spaces (by aaronpk) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/43=20 1 pull requests received 1 new comments: - #43 adds .editorconfig and cleans up trailing spaces (1 by netlify) https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/43=20 2 pull requests merged: - adds .editorconfig and cleans up trailing spaces https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/43 [Editoria= l]=20 - Several pretty minor edits after I read through this doc. https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/38 [Editoria= l]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============8036894677650947326== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday July 25, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+2/-12/=F0=9F=92=AC68)

2 issues created:

23 issues received 68 new comments:

12 issues closed:

ietf-wg-gnap/gnap-resource-servers (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC2)

2 pull requests submitted:

2 pull requests received 2 new comments:

1 pull requests merged:

ietf-wg-gnap/gnap-resource-servers (+1/-2/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============8036894677650947326==-- From nobody Mon Jul 26 15:00: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 1548E3A14B8 for ; Mon, 26 Jul 2021 15:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RkXPJMzq0zVm for ; Mon, 26 Jul 2021 15:00:51 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 514FA3A14B4 for ; Mon, 26 Jul 2021 15:00:51 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id r5so10354716ilc.13 for ; Mon, 26 Jul 2021 15:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=WgCzyojBVN8Ra4sPOYSOpN6OmShCJiHLyQli0hCj2Fo=; b=u53a3Ytx2xf85UWGpfdP5dVbFfUaA79ZT1j6DN3fB0aCMQEV9xqmAF/ksTqh+C7ac+ 6jTP6iRBpC4LDW+7KbWJlA2rcNeaMt+uuznlAv781YDELQzsbBhTK+Fv50079KwD5dy+ n1Sqk5ocxfQqx16XGIPtN8wFUdxug4GDkNhCUqWsotRGh2P2Um/9nIRpdXOzXxUJWFC0 IVO6fxkc/HQzi2KorVafyQtppTJFq6bWDk4fkr34CbLBry5e9OrmzP5HTx4o9/1C9+Ff JwbwK9ucCM5lki61KWQ+4AkQ+yH7BTqHIVagK7Ntqj48bCWb5+cnMbBdti11/oi37zfG kg0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=WgCzyojBVN8Ra4sPOYSOpN6OmShCJiHLyQli0hCj2Fo=; b=dEMZ0frtMkDB8PKP0ntvXhNtJ0bjakbLlLVh1BRcCISoI3YpLNqqe5WxqIBi/wCFV7 yx7uX9VnzYM3Cm+rfHGuOdeQK5QcruH4OfYLr8trutjJX7Cz0/2CnR3T5t+Y8ySkDiNo Pm7u/iad+czgVUnyOI9hMTEXyCdUKQEHD+oi/wMPoeIQaUzQMMyI6PFO8uCBXVppZBJf +8Odgl/98+uITWpaOrLksFYlADeI70G/0H308eEwDj3FkrC07igMC44mU7HzQSNi6M7C Nj/fONAnnfPFDmNMIsKDjfWx52CofmF7/TTOgqoK1qRMaIKFppLoNFlKS1mxVhpY3fyW b6mA== X-Gm-Message-State: AOAM533I2dNqhOTFN6J+0civ2PR5nYH86/bBjstRUm3m0OFuiYiI2Ten aFInmsgE1KDQUTrp19xhn4ysS6clY/E= X-Google-Smtp-Source: ABdhPJw0l7CXyo+L/D4OuhZgX+iDjs5EiGAb4NuOTR1c3ZsguHef7maoxVLzhzzLU+gOrWpWmk9/pw== X-Received: by 2002:a92:c143:: with SMTP id b3mr13993185ilh.145.1627336849775; Mon, 26 Jul 2021 15:00:49 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-181-28-50.red.bezeqint.net. [79.181.28.50]) by smtp.gmail.com with ESMTPSA id z24sm677738iog.46.2021.07.26.15.00.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jul 2021 15:00:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.51.21071101 Date: Tue, 27 Jul 2021 01:00:46 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <7DABDA84-0772-4E06-9EAC-8516F0970E67@gmail.com> Thread-Topic: GNAP meeting minutes Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3710192448_1428200704" Archived-At: Subject: [GNAP] GNAP meeting minutes 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: Mon, 26 Jul 2021 22:00:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3710192448_1428200704 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I uploaded the minutes of today=E2=80=99s meeting, many thanks Kristina! =20 https://datatracker.ietf.org/doc/minutes-111-gnap/ =20 I learned two important things: =20 CodiMD can include images in the Markdown document =E2=80=93 very neat! Datatracker strips these images off when uploading the MD file =E2=80=93 less nea= t but reasonable for several reasons. =20 Thank you everyone for joining the meeting! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 =20 --B_3710192448_1428200704 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I uploaded the minutes of today=E2=80=99s meeting, many thanks K= ristina!

 

https://d= atatracker.ietf.org/doc/minutes-111-gnap/

 

I learned two important things:

&= nbsp;

  1. CodiMD can include images in the Markdown document =E2=80=93 ver= y neat!
  2. Datatracker stri= ps these images off when uploading the MD file =E2=80=93 less neat but reasonable = for several reasons.

 

Thank you everyone for joining the meeting!

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

 

--B_3710192448_1428200704-- From nobody Mon Jul 26 18:04:16 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 677F23A0C7F for ; Mon, 26 Jul 2021 18:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=minilop.net 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 UJ0iXXirI9t1 for ; Mon, 26 Jul 2021 18:04:08 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 C67E73A0C7C for ; Mon, 26 Jul 2021 18:04:08 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id b6so15412673pji.4 for ; Mon, 26 Jul 2021 18:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minilop.net; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=P26p5rE1wv86VDWlbWrlujsvzkBHtvBg0yvh3idvZ6I=; b=FieXwc6LiU22WCDBJMxpnRTmgWbW/cZ5R23haniKNKQGdK0F0Q/yzYBdw2BtraRm8v CtxUJOOiogiBGqPjGgmzyla0leSy2K9+851X7pWeCFUV/CgdAQS4JY3yx2drlyJDWOIO hgi9BHZ5YYwuBgt7gbBg3//9kgHbrlvdmQE9E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=P26p5rE1wv86VDWlbWrlujsvzkBHtvBg0yvh3idvZ6I=; b=q9dj76FT1vXhFu+wBYHN0seoumut7eGa+VEdXkBjGjjAYPWEGAqsRWFBRxhl5R0N1u 139jZ0Z4aWUBQUAo0lGC5mDbGUjLJDqsqv4JOErk1VIIfTyF1HRZNdkDO3T94lptT/RY 9YxbxcOpwyu5fyQ8BqFN1WyBPxDeNM5u24cQvXlU7lGwDbsNJxnWSRjU9L/eYg5Pf3Sx fSl87aWtpG0/qHk2iIERGxgVS1IGkCMWIubMIummfa/X20IMBqA3r9DBZ5DULVUvj0it Hm2luScuWq0YIIlxhStQoz00+RCYUm7KU09P8IOm+J9VoggGWu/tP/qd5B4mjbMoewb/ hxcg== X-Gm-Message-State: AOAM530iB68tCs4vmjVIXpW5iQCjtAGFbGmn5PImzJvhgck4grQPmgAM XXDFpDQAsTQY2CZGiJnGHAFEwUQNov5sbv+F X-Google-Smtp-Source: ABdhPJw9q0P6yk74bMlEusfo7f/ane6hOzleb8wwi704yA86/5F5Dx2Sp1HrUJP0I1NhnM/+vDp1TA== X-Received: by 2002:a17:902:8d96:b029:12b:ac49:79e7 with SMTP id v22-20020a1709028d96b029012bac4979e7mr16629439plo.18.1627347846995; Mon, 26 Jul 2021 18:04:06 -0700 (PDT) Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id fz10sm829330pjb.40.2021.07.26.18.04.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jul 2021 18:04:06 -0700 (PDT) Received: by eh (sSMTP sendmail emulation); Mon, 26 Jul 2021 18:04:04 -0700 Date: Mon, 26 Jul 2021 18:04:04 -0700 From: Jamey Sharp To: txauth@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Archived-At: Subject: [GNAP] generic HTTP resource type 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, 27 Jul 2021 01:04:14 -0000 In today's meeting, I asked about applying GNAP as the HTTP authentication method for arbitrary HTTP resources, such as static files, in the same way that Basic and Digest auth can be used today. Justin asked me to share the question here. Because the current draft includes RS-first AS discovery using the standard WWW-Authenticate response header, it might work for this use case as-is, but I think it can be improved. First: Am I correct in thinking that two access tokens retrieved from the same AS, by the same end user, with the same "access" list, should be indistinguishable to the client? Specifically, if a client receives two `WWW-Authenticate: GNAP` headers with the same "as_url" and "access" parameters, can it reuse the access token it got for the first request on the second request, without consulting the AS again? If so, I think the WWW-Authenticate "access" parameter is equivalent to the "realm" parameter defined in RFC7235 and used in RFC7617 Basic auth. (Perhaps for consistency with HTTP auth, it should in fact be called "realm" when used in that header? RFC7235 even uses "scope" terminilogy to describe it.) Without additional provisions, which I'm pretty sure are not currently in GNAP, checking for matching realm/access parameters still requires an extra unauthenticated request any time the client needs to access a URL it hasn't visited before, even if the response turns out to indicate that an earlier access token can be reused. RFC7617 defines somewhat magic rules for when a client can proactively provide Basic-scheme credentials to a URL where it hasn't previously seen a WWW-Authenticate header, in order to avoid a round-trip in the common case where the same credentials are accepted at similar URLs. In theory, GNAP could specify something similar to make RS-first AS discovery more efficient, but that level of magic seems dangerous to me. The Digest auth scheme in RFC7616 instead allows the server (in this context, the RS) to give an explicit list of URL prefixes which accept the same credentials, in the WWW-Authenticate "domain" parameter. I think that's a closer fit for GNAP, but rather than making it a header parameter, I think it's best to fold it into the token's access rights. I propose standardizing a definition of a "type" value for the rights request that describes HTTP access rights generically, rather than describing actions appropriate to a specific API. I think that would make GNAP usable anywhere that Basic or Digest auth are currently used. It might also enable a wide variety of RESTful APIs and HTTP-based standards to use GNAP without needing to define custom rights types. Here is a concrete suggestion as a starting point for discussion: "access": [{ "type": "http", "locations": ["https://example.com/protected/"], "datatypes": ["text/html", "image/*"], "actions": ["GET", "PUT", "DELETE"] }] A resource request must match all fields to be allowed. If "datatypes" or "actions" are empty or absent, then all are permitted. (Permitting nothing is the same as not granting any rights at all.) The "locations" field is required to be present and non-empty though, and might work like the "domain" parameter in Digest: "The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a prefix [...] MAY be assumed to be in the same protection space." This allows a client to request a limited set of methods or access to a limited portion of the protection space. It also allows the AS to inform the client of exactly which requests it may use the access token on, which may be different than what the client requested. If I'm reading the current draft correctly, if a client sends an opaque resource reference like `"access": "WallyWorld"`, then the AS may choose to send back a non-opaque description of the rights granted by the returned access token, such as the above example for the hypothetical "http" rights type. Is that right? I suppose the downside of the AS transforming an opaque reference into a full rights description is that the client can't indicate which rights types it understands. If a CMS supports a proprietary API for editing blog posts, but also supports WebDAV for file attachments, it might not be clear which rights type to use, yeah? So here's an additional proposal: a client wishing to use this generic HTTP rights type should (must?) explicitly request it in the "access" rights request (and may also include the resource reference given in the "access" parameter of the WWW-Authenticate header, if any). It must specify the exact request URL in the "locations" field, and may also specify the method it tried to use in "actions". As usual, the AS may return a token granting rights to a wider range of locations or methods and is recommended to return the actual granted rights. I hope that's reasonably clear and would love to discuss this further. Jamey From nobody Mon Jul 26 19:31:56 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 88DE53A1251 for ; Mon, 26 Jul 2021 19:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 iJy-q7Q26IS6 for ; Mon, 26 Jul 2021 19:31:50 -0700 (PDT) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (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 D6D193A124D for ; Mon, 26 Jul 2021 19:31:49 -0700 (PDT) Received: by mail-yb1-f174.google.com with SMTP id a201so18194549ybg.12 for ; Mon, 26 Jul 2021 19:31:49 -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=/xndgtC6ymF1QnW+3D0Je/BJpXPIo7/0KNANC8zGGa0=; b=o8v+tihryi+GkcL2pl0zXdan4hwSiUfXRlUH3LhalNMY/ncw1ejQl6CmSDD8wcSHMS hQWfkj8L9hOK9XcBsLHbHLPls9XSDH+yZjytwLHqzAsnPmQNtjtA3Acx5FYNywwtzn+p 9vu9598d271yjZkOzrBchuHg/5Fz4+R1wfmyY4U6Ih6TfCFWVnmKXswX2D+kFeJGJ4vn OQMCutKp2zLCFuLKYmNJejS8NJq/sFRax8SKpCAfSWeXXoG5mZEtTFRvjMJAj5BoEEUK RMf8eIfDW2Bwzh64bCn7Ek8MBBgs3Mdbpe95J22okFP3Lre7Xij+g1qpZsHsN5IPyWQQ ympw== X-Gm-Message-State: AOAM531YXtmGCKRzz+G8ILcfsrvOyoE35WtHQMp7thNFZLdLKSDgnHQh QM/yW6qJ04bLZ34JIvJONyLbNypl4o7ktGs47h7h4tQ6 X-Google-Smtp-Source: ABdhPJwqk3a2rFlTYKSqhrPDCUFZTnG4s6SzqC2hXQwkECkumKDQCO9yxJMDZVfy3sSsdxDHIsdiVaDTtpVr3e/ndy8= X-Received: by 2002:a25:7bc6:: with SMTP id w189mr20197715ybc.160.1627353108564; Mon, 26 Jul 2021 19:31:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Mon, 26 Jul 2021 22:31:37 -0400 Message-ID: To: Jamey Sharp Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f5d0bf05c811ab67" Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 27 Jul 2021 02:31:55 -0000 --000000000000f5d0bf05c811ab67 Content-Type: text/plain; charset="UTF-8" Hi Jamey, I don't understand what's being proposed. Mostly this is due to my inexperience with HTTP APIs, but I'm trying to learn. In cases of RS-first AS discovery, the end-user might or might not be the RO. If the end-user is not the RO, then, from a data minimization perspective, I do not want the client sharing any request information with the RS. In other words, I do not assume that trusting the RS is the same as trusting the AS. Therefore, an RS-first request should not require any authentication. It should just return a link to the AS associated with that resource. A request to the RS by the RO should obviously require authentication. A request to the RS that includes an authorization token is not subject to authentication of the end-user. What am I missing? Adrian On Mon, Jul 26, 2021 at 9:04 PM Jamey Sharp wrote: > In today's meeting, I asked about applying GNAP as the HTTP > authentication method for arbitrary HTTP resources, such as static > files, in the same way that Basic and Digest auth can be used today. > Justin asked me to share the question here. > > Because the current draft includes RS-first AS discovery using the > standard WWW-Authenticate response header, it might work for this use > case as-is, but I think it can be improved. > > First: Am I correct in thinking that two access tokens retrieved from > the same AS, by the same end user, with the same "access" list, should > be indistinguishable to the client? Specifically, if a client receives > two `WWW-Authenticate: GNAP` headers with the same "as_url" and "access" > parameters, can it reuse the access token it got for the first request > on the second request, without consulting the AS again? > > If so, I think the WWW-Authenticate "access" parameter is equivalent to > the "realm" parameter defined in RFC7235 and used in RFC7617 Basic auth. > (Perhaps for consistency with HTTP auth, it should in fact be called > "realm" when used in that header? RFC7235 even uses "scope" terminilogy > to describe it.) > > Without additional provisions, which I'm pretty sure are not currently > in GNAP, checking for matching realm/access parameters still requires an > extra unauthenticated request any time the client needs to access a URL > it hasn't visited before, even if the response turns out to indicate > that an earlier access token can be reused. > > RFC7617 defines somewhat magic rules for when a client can proactively > provide Basic-scheme credentials to a URL where it hasn't previously > seen a WWW-Authenticate header, in order to avoid a round-trip in the > common case where the same credentials are accepted at similar URLs. In > theory, GNAP could specify something similar to make RS-first AS > discovery more efficient, but that level of magic seems dangerous to me. > > The Digest auth scheme in RFC7616 instead allows the server (in this > context, the RS) to give an explicit list of URL prefixes which accept > the same credentials, in the WWW-Authenticate "domain" parameter. I > think that's a closer fit for GNAP, but rather than making it a header > parameter, I think it's best to fold it into the token's access rights. > > I propose standardizing a definition of a "type" value for the rights > request that describes HTTP access rights generically, rather than > describing actions appropriate to a specific API. I think that would > make GNAP usable anywhere that Basic or Digest auth are currently used. > It might also enable a wide variety of RESTful APIs and HTTP-based > standards to use GNAP without needing to define custom rights types. > > Here is a concrete suggestion as a starting point for discussion: > > "access": [{ > "type": "http", > "locations": ["https://example.com/protected/"], > "datatypes": ["text/html", "image/*"], > "actions": ["GET", "PUT", "DELETE"] > }] > > A resource request must match all fields to be allowed. If "datatypes" > or "actions" are empty or absent, then all are permitted. (Permitting > nothing is the same as not granting any rights at all.) The "locations" > field is required to be present and non-empty though, and might work > like the "domain" parameter in Digest: "The client can use this list to > determine the set of URIs for which the same authentication information > may be sent: any URI that has a URI in this list as a prefix [...] MAY > be assumed to be in the same protection space." > > This allows a client to request a limited set of methods or access to a > limited portion of the protection space. It also allows the AS to inform > the client of exactly which requests it may use the access token on, > which may be different than what the client requested. > > If I'm reading the current draft correctly, if a client sends an opaque > resource reference like `"access": "WallyWorld"`, then the AS may choose > to send back a non-opaque description of the rights granted by the > returned access token, such as the above example for the hypothetical > "http" rights type. Is that right? > > I suppose the downside of the AS transforming an opaque reference into a > full rights description is that the client can't indicate which rights > types it understands. If a CMS supports a proprietary API for editing > blog posts, but also supports WebDAV for file attachments, it might not > be clear which rights type to use, yeah? > > So here's an additional proposal: a client wishing to use this generic > HTTP rights type should (must?) explicitly request it in the "access" > rights request (and may also include the resource reference given in the > "access" parameter of the WWW-Authenticate header, if any). It must > specify the exact request URL in the "locations" field, and may also > specify the method it tried to use in "actions". As usual, the AS may > return a token granting rights to a wider range of locations or methods > and is recommended to return the actual granted rights. > > I hope that's reasonably clear and would love to discuss this further. > > Jamey > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f5d0bf05c811ab67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Jamey,

I don't understand w= hat's being proposed. Mostly this is due to my inexperience with HTTP A= PIs, but I'm trying to learn.

In cases of RS-f= irst AS discovery, the end-user might or might not be the RO. If the end-us= er is not the RO, then, from a data minimization perspective, I do not want= the client sharing any request information with the RS. In other words, I = do not assume that trusting the RS is the same as trusting the AS. Therefor= e, an RS-first request should not require any authentication. It should jus= t return a link to the AS associated with that resource.

A request to the RS by the RO should obviously require authenticatio= n.

A request=C2=A0to the RS that includes an autho= rization token is not subject to authentication of the end-user.=C2=A0

What am I missing?

Adrian




On Mon, Jul 26, 2021 at 9:04= PM Jamey Sharp <jamey@minilop.net<= /a>> wrote:
In today's meeting, I asked ab= out applying GNAP as the HTTP
authentication method for arbitrary HTTP resources, such as static
files, in the same way that Basic and Digest auth can be used today.
Justin asked me to share the question here.

Because the current draft includes RS-first AS discovery using the
standard WWW-Authenticate response header, it might work for this use
case as-is, but I think it can be improved.

First: Am I correct in thinking that two access tokens retrieved from
the same AS, by the same end user, with the same "access" list, s= hould
be indistinguishable to the client? Specifically, if a client receives
two `WWW-Authenticate: GNAP` headers with the same "as_url" and &= quot;access"
parameters, can it reuse the access token it got for the first request
on the second request, without consulting the AS again?

If so, I think the WWW-Authenticate "access" parameter is equival= ent to
the "realm" parameter defined in RFC7235 and used in RFC7617 Basi= c auth.
(Perhaps for consistency with HTTP auth, it should in fact be called
"realm" when used in that header? RFC7235 even uses "scope&q= uot; terminilogy
to describe it.)

Without additional provisions, which I'm pretty sure are not currently =
in GNAP, checking for matching realm/access parameters still requires an extra unauthenticated request any time the client needs to access a URL it hasn't visited before, even if the response turns out to indicate that an earlier access token can be reused.

RFC7617 defines somewhat magic rules for when a client can proactively
provide Basic-scheme credentials to a URL where it hasn't previously seen a WWW-Authenticate header, in order to avoid a round-trip in the
common case where the same credentials are accepted at similar URLs. In theory, GNAP could specify something similar to make RS-first AS
discovery more efficient, but that level of magic seems dangerous to me.
The Digest auth scheme in RFC7616 instead allows the server (in this
context, the RS) to give an explicit list of URL prefixes which accept
the same credentials, in the WWW-Authenticate "domain" parameter.= I
think that's a closer fit for GNAP, but rather than making it a header =
parameter, I think it's best to fold it into the token's access rig= hts.

I propose standardizing a definition of a "type" value for the ri= ghts
request that describes HTTP access rights generically, rather than
describing actions appropriate to a specific API. I think that would
make GNAP usable anywhere that Basic or Digest auth are currently used. It might also enable a wide variety of RESTful APIs and HTTP-based
standards to use GNAP without needing to define custom rights types.

Here is a concrete suggestion as a starting point for discussion:

"access": [{
=C2=A0 =C2=A0"type": "http",
=C2=A0 =C2=A0"locations": ["https://example.com/protect= ed/"],
=C2=A0 =C2=A0"datatypes": ["text/html", "image/*&q= uot;],
=C2=A0 =C2=A0"actions": ["GET", "PUT", "= DELETE"]
}]

A resource request must match all fields to be allowed. If "datatypes&= quot;
or "actions" are empty or absent, then all are permitted. (Permit= ting
nothing is the same as not granting any rights at all.) The "locations= "
field is required to be present and non-empty though, and might work
like the "domain" parameter in Digest: "The client can use t= his list to
determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a prefix [...] MAY
be assumed to be in the same protection space."

This allows a client to request a limited set of methods or access to a limited portion of the protection space. It also allows the AS to inform the client of exactly which requests it may use the access token on,
which may be different than what the client requested.

If I'm reading the current draft correctly, if a client sends an opaque=
resource reference like `"access": "WallyWorld"`, then = the AS may choose
to send back a non-opaque description of the rights granted by the
returned access token, such as the above example for the hypothetical
"http" rights type. Is that right?

I suppose the downside of the AS transforming an opaque reference into a full rights description is that the client can't indicate which rights =
types it understands. If a CMS supports a proprietary API for editing
blog posts, but also supports WebDAV for file attachments, it might not be clear which rights type to use, yeah?

So here's an additional proposal: a client wishing to use this generic =
HTTP rights type should (must?) explicitly request it in the "access&q= uot;
rights request (and may also include the resource reference given in the "access" parameter of the WWW-Authenticate header, if any). It mu= st
specify the exact request URL in the "locations" field, and may a= lso
specify the method it tried to use in "actions". As usual, the AS= may
return a token granting rights to a wider range of locations or methods and is recommended to return the actual granted rights.

I hope that's reasonably clear and would love to discuss this further.<= br>
Jamey

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f5d0bf05c811ab67-- From nobody Tue Jul 27 11:25:32 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 9BEC93A083C for ; Tue, 27 Jul 2021 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=minilop.net 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 3dUr2Oft5Iso for ; Tue, 27 Jul 2021 11:25:26 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 967113A083B for ; Tue, 27 Jul 2021 11:25:26 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id t21so16672963plr.13 for ; Tue, 27 Jul 2021 11:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minilop.net; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=06t0GofS9aA2AUO1gSvrg04jrumc/4rkohVVkGaISU4=; b=RyRIReEZOth2Eg4CN9ug/806D/fnECizmAGJ0UE/TE/eYmUlZE8DDiHIObfshAmRFU /3cHlGq/G6v9RkFw6LPOVsB6LhVAjFf/+R5IgXRlLjE6eXzhhWIBl5x99VaYPCva0MYH CPeTm96LToeujBqTu0ruLcGRZFIsleyv9SI6k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=06t0GofS9aA2AUO1gSvrg04jrumc/4rkohVVkGaISU4=; b=gCuu45SEus8ZdULKBq1I9kcCFBaFIzVHYFDnfpF65eY3foYFuYhgaeiXv06M2IcII2 +49eN7ADG73F7SyjJSA93qc8ab80r3g9ZK2m8dExb+sPU6x9vMAnCVEmVkxJ4JbhfkoD c5Y+jzS3FpHg+C7Y02Wt9GetCir4NHVQAxll56JSY0DJ36XRVtkW+jH0w0yXJ1WWK/sd gROY59OkyeYMjnK8dULfgzQP+sOUKCTCI4i9t77oMpyg31Gl8VHIAFyi064X3P6DCpRR VvWES6Zq30GBPoqZJX++hbph8/bvy+LdwuWXgrPR52Ny2BpHKPdzxAR3P48LrgwWH20K 6GfQ== X-Gm-Message-State: AOAM533Z0r01gRMO7yOJaMtpmZbuxxJ2TM+KIM93G4iGvHLaXnviixbU 6+0fqNZscRtmEY1tshROo2ekMw== X-Google-Smtp-Source: ABdhPJydSdr0FHVxbsLVeVBvJI2qZB8nYKpSGd1m1nklMMmORGAQAK08xd7vFP/kbghgmSIn4H6Egw== X-Received: by 2002:a17:90b:1097:: with SMTP id gj23mr24016933pjb.65.1627410325090; Tue, 27 Jul 2021 11:25:25 -0700 (PDT) Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id kr6sm1833285pjb.23.2021.07.27.11.25.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jul 2021 11:25:24 -0700 (PDT) Received: by eh (sSMTP sendmail emulation); Tue, 27 Jul 2021 11:25:23 -0700 Date: Tue, 27 Jul 2021 11:25:23 -0700 From: Jamey Sharp To: Adrian Gropper Cc: GNAP Mailing List Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-TUID: 83v4b+X65LVT Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 27 Jul 2021 18:25:32 -0000 Hi Adrian! I agree with the general principles you're suggesting, but I don't believe my proposal reveals anything new to the RS. A resource server has to know what resource the end-user is requesting in order to serve that resource. (The cryptography notions of "private information retrieval" and "oblivious RAM" would be an interesting challenge to apply to the web, but I'm sure they're well out of scope for this WG. You might enjoy reading the research literature on them though.) My proposal does potentially reveal new information to the AS, and that's worth thinking about. There are two cases: If it's desirable for the AS to reveal to the end-user the set of resources to which they've been granted rights—and I think it is—then that means the RS must have previously informed the AS about what the resource references which the RS uses actually refer to. Otherwise, a reference is an opaque string like "WallyWorld" that means nothing to either the end-user or the AS. (It certainly doesn't mean anything to me: I'm taking that from the original examples in the HTTP Basic auth spec, going back to at least 1996.) Second, I've proposed that the client inform the AS of the specific resource and method which the end-user was trying to request. I'm not sure whether that's either necessary or desirable; I'm hoping other folks will chime in on my questions about whether the client needs to be able to indicate that it understands this generic "http" rights type. I think it's worth noting that the choice of AS is made by the RO/RS, not by the end-user. So the safest assumption you can make when analyzing the privacy properties of GNAP is that the RS and AS may reveal any information they have to each other without the end-user's knowledge or consent. That doesn't change the above analysis though, since the only things the AS may learn are things the RS already knows. Finally, here's context I think will help you on HTTP authentication: An HTTP server can indicate that its response to a resource request might change if the client were authenticated. It does so by sending a "WWW-Authenticate" response header, containing a list of authentication schemes that the server will accept. In the context of GNAP, you can see that in "RS-first Method of AS Discovery", currently section 9.1. If the client chooses to use one of those schemes, then it sends a new request containing an "Authorization" header. The contents of that header are mostly specified by the selected authentication scheme; for GNAP, that's covered in "Securing Requests from the Client Instance", "Presenting Access Tokens", which is currently section 7.2. GNAP departs from older HTTP authentication schemes because in between the above two steps, the client goes off and talks to somebody else (the AS) for a while. But that side conversation is invisible to the RS, which just sees the client send one unauthenticated request and then a second request that contains an access token. If the client already knows that the RS uses a specific GNAP AS, then the RS doesn't even get that first unauthenticated request; the first time it hears anything from the client is after the conversation with the AS is finished. But I'm interested in the case where the client has no prior knowledge about the RS, which means it works as I've described above, just like any other HTTP auth scheme. The problem I'm trying to address is that after the first request, the HTTP auth spec doesn't say whether the client should use the same credentials when requesting resources at other URLs. If the client does not send credentials on the next request, then it may get another "WWW-Authenticate" header back without getting the resource it actually wanted, which wastes time as it has to issue the request again even if it has a valid access token available. But proactively authenticating to a different URL can leak information to a malicious party, since there may be many unaffiliated ROs at a single RS. For the Basic and Bearer schemes, the leaked information is full credentials and a complete security compromise. In other schemes, revealing that the end-user has credentials for some other resources is still a privacy violation, and in addition the leaked information may include identity details such as a username. I briefly discussed in my previous mail how the Basic and Digest schemes approach this. Bearer seems to assume the client has prior knowledge about which resources a token gives it access to—which is reasonable given how OAuth 2.0 has been used, but GNAP's RS-first discovery opens up new use cases with new challenges. So I believe this needs to be addressed somehow, and I've proposed one possible way to do it. I hope this clarified my proposal for you! Jamey On Mon, Jul 26, 2021, 7:31 PM Adrian Gropper wrote: > Hi Jamey, > > I don't understand what's being proposed. Mostly this is due to my > inexperience with HTTP APIs, but I'm trying to learn. > > In cases of RS-first AS discovery, the end-user might or might not be the > RO. If the end-user is not the RO, then, from a data minimization > perspective, I do not want the client sharing any request information with > the RS. In other words, I do not assume that trusting the RS is the same as > trusting the AS. Therefore, an RS-first request should not require any > authentication. It should just return a link to the AS associated with that > resource. > > A request to the RS by the RO should obviously require authentication. > > A request to the RS that includes an authorization token is not subject to > authentication of the end-user. > > What am I missing? > > Adrian > > > On Mon, Jul 26, 2021 at 9:04 PM Jamey Sharp wrote: > >> In today's meeting, I asked about applying GNAP as the HTTP >> authentication method for arbitrary HTTP resources, such as static >> files, in the same way that Basic and Digest auth can be used today. >> Justin asked me to share the question here. >> >> Because the current draft includes RS-first AS discovery using the >> standard WWW-Authenticate response header, it might work for this use >> case as-is, but I think it can be improved. >> >> First: Am I correct in thinking that two access tokens retrieved from >> the same AS, by the same end user, with the same "access" list, should >> be indistinguishable to the client? Specifically, if a client receives >> two `WWW-Authenticate: GNAP` headers with the same "as_url" and "access" >> parameters, can it reuse the access token it got for the first request >> on the second request, without consulting the AS again? >> >> If so, I think the WWW-Authenticate "access" parameter is equivalent to >> the "realm" parameter defined in RFC7235 and used in RFC7617 Basic auth. >> (Perhaps for consistency with HTTP auth, it should in fact be called >> "realm" when used in that header? RFC7235 even uses "scope" terminilogy >> to describe it.) >> >> Without additional provisions, which I'm pretty sure are not currently >> in GNAP, checking for matching realm/access parameters still requires an >> extra unauthenticated request any time the client needs to access a URL >> it hasn't visited before, even if the response turns out to indicate >> that an earlier access token can be reused. >> >> RFC7617 defines somewhat magic rules for when a client can proactively >> provide Basic-scheme credentials to a URL where it hasn't previously >> seen a WWW-Authenticate header, in order to avoid a round-trip in the >> common case where the same credentials are accepted at similar URLs. In >> theory, GNAP could specify something similar to make RS-first AS >> discovery more efficient, but that level of magic seems dangerous to me. >> >> The Digest auth scheme in RFC7616 instead allows the server (in this >> context, the RS) to give an explicit list of URL prefixes which accept >> the same credentials, in the WWW-Authenticate "domain" parameter. I >> think that's a closer fit for GNAP, but rather than making it a header >> parameter, I think it's best to fold it into the token's access rights. >> >> I propose standardizing a definition of a "type" value for the rights >> request that describes HTTP access rights generically, rather than >> describing actions appropriate to a specific API. I think that would >> make GNAP usable anywhere that Basic or Digest auth are currently used. >> It might also enable a wide variety of RESTful APIs and HTTP-based >> standards to use GNAP without needing to define custom rights types. >> >> Here is a concrete suggestion as a starting point for discussion: >> >> "access": [{ >> "type": "http", >> "locations": ["https://example.com/protected/"], >> "datatypes": ["text/html", "image/*"], >> "actions": ["GET", "PUT", "DELETE"] >> }] >> >> A resource request must match all fields to be allowed. If "datatypes" >> or "actions" are empty or absent, then all are permitted. (Permitting >> nothing is the same as not granting any rights at all.) The "locations" >> field is required to be present and non-empty though, and might work >> like the "domain" parameter in Digest: "The client can use this list to >> determine the set of URIs for which the same authentication information >> may be sent: any URI that has a URI in this list as a prefix [...] MAY >> be assumed to be in the same protection space." >> >> This allows a client to request a limited set of methods or access to a >> limited portion of the protection space. It also allows the AS to inform >> the client of exactly which requests it may use the access token on, >> which may be different than what the client requested. >> >> If I'm reading the current draft correctly, if a client sends an opaque >> resource reference like `"access": "WallyWorld"`, then the AS may choose >> to send back a non-opaque description of the rights granted by the >> returned access token, such as the above example for the hypothetical >> "http" rights type. Is that right? >> >> I suppose the downside of the AS transforming an opaque reference into a >> full rights description is that the client can't indicate which rights >> types it understands. If a CMS supports a proprietary API for editing >> blog posts, but also supports WebDAV for file attachments, it might not >> be clear which rights type to use, yeah? >> >> So here's an additional proposal: a client wishing to use this generic >> HTTP rights type should (must?) explicitly request it in the "access" >> rights request (and may also include the resource reference given in the >> "access" parameter of the WWW-Authenticate header, if any). It must >> specify the exact request URL in the "locations" field, and may also >> specify the method it tried to use in "actions". As usual, the AS may >> return a token granting rights to a wider range of locations or methods >> and is recommended to return the actual granted rights. >> >> I hope that's reasonably clear and would love to discuss this further. >> >> Jamey >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > From nobody Tue Jul 27 15:54:51 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 02F4C3A0D7F for ; Tue, 27 Jul 2021 15:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 L58SEuW1DQ4p for ; Tue, 27 Jul 2021 15:54:44 -0700 (PDT) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) (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 A5D573A0D2B for ; Tue, 27 Jul 2021 15:54:44 -0700 (PDT) Received: by mail-yb1-f180.google.com with SMTP id d73so656232ybc.10 for ; Tue, 27 Jul 2021 15:54:44 -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=Cew9d1VNRn4EfWnMEErOee9OKtFsSVWl0HS0J9Qpj3U=; b=OYbch7h8tsq86g802n+e0+vnHwgjSQkCpV2oY7Q5qBSiGXj7bbBudv3M31cDUlS0mo X9lGn/ISy5b1lyDZBdQ+hCmmjzFLErjYUKKFf3/FgHHJboLQYLh5V3h0iYyGKMJDEqe5 dUBWTTIvQEInFhpU8UwzkZJLBm+rgz9FyAIErYPDl72kwkS8fNk4iT7uFI46A7vmNAFS 6fsdJfyhMcl5UjyPYX7XxmyUHRc+zYfp7NBZIYiEzIho9OjBctkG40qz2zlP42CwqKjr R15fB4AqsFmd7JeV3ApaRa4MReMxcUHHPIz8qUqdhgTHabf4bACtqHspPqQCjIcTLK/A BRWg== X-Gm-Message-State: AOAM5311ZA7YAK1l7mqZZMWkxjLJEZrJEuV6JmYG1KhiTBfvfSApu1Tf Z8o+FYraseWKrvAjCX0QrJR8+Yt9B04NSgUbM2c= X-Google-Smtp-Source: ABdhPJwokArUJ3Cg3HXjDyzygujY3gd0m+H4z3uVFMksz2HnVD7kBk63WK9/CC78Iz3gTPSKyH4h2BHz3hZkwsxwMMk= X-Received: by 2002:a25:ac10:: with SMTP id w16mr31658979ybi.37.1627426483558; Tue, 27 Jul 2021 15:54:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Tue, 27 Jul 2021 18:54:31 -0400 Message-ID: To: Jamey Sharp Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000735bc905c822c169" Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 27 Jul 2021 22:54:50 -0000 --000000000000735bc905c822c169 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jamey, tldr: My perspective in the GNAP discussion is to maximize the power of the RO and minimize the power of the RS by assuming that the RO can delegate to _any_ AS they choose. I'm grateful for your conversation because you are helping me tease out which aspects of GNAP are essential for my (fairly common) use-case. My use-case is securing a very complex (HL7-FHIR [1]) and regulated (US Gov API Task Force [2]) API to health records. This work has been evolving for a decade or more in the Kantara UMA WG [3] and the OpenID HEART WG [4] with almost zero commercial uptake. My goal is to use GNAP to replace as much of the OAuth, UMA, and OIDC example implementation of delegated health records access. Links to our repos are on the last slide of yesterday's presentation [5]. continuing inline.... On Tue, Jul 27, 2021 at 2:25 PM Jamey Sharp wrote: > Hi Adrian! > > I agree with the general principles you're suggesting, but I don't > believe my proposal reveals anything new to the RS. A resource server > has to know what resource the end-user is requesting in order to serve > that resource. > Yes. > > (The cryptography notions of "private information retrieval" and > "oblivious RAM" would be an interesting challenge to apply to the web, > but I'm sure they're well out of scope for this WG. You might enjoy > reading the research literature on them though.) > Sure. My concern is RO power and control, not security. > > My proposal does potentially reveal new information to the AS, and > that's worth thinking about. There are two cases: > No problem. I want to maximize the ROs agency by giving their delegated AS as much power (privilege or capability) as the RO wants. > > If it's desirable for the AS to reveal to the end-user the set of > resources to which they've been granted rights=E2=80=94and I think it is= =E2=80=94then > that means the RS must have previously informed the AS about what the > resource references which the RS uses actually refer to. Otherwise, a > reference is an opaque string like "WallyWorld" that means nothing to > either the end-user or the AS. (It certainly doesn't mean anything to > me: I'm taking that from the original examples in the HTTP Basic auth > spec, going back to at least 1996.) > Yes. Seems obvious. > > Second, I've proposed that the client inform the AS of the specific > resource and method which the end-user was trying to request. I'm not > sure whether that's either necessary or desirable; I'm hoping other > folks will chime in on my questions about whether the client needs to be > able to indicate that it understands this generic "http" rights type. > Yes. I have no problem with AS, as the RO's agent, being informed to the extent the end-user is willing to share their attributes and their intent. > > I think it's worth noting that the choice of AS is made by the RO/RS, > not by the end-user. So the safest assumption you can make when > analyzing the privacy properties of GNAP is that the RS and AS may > reveal any information they have to each other without the end-user's > knowledge or consent. That doesn't change the above analysis though, > since the only things the AS may learn are things the RS already knows. > Careful. "Separation of Concerns", avoiding censorship, and data minimization dictate that the choice of AS should be made by the RO. If an RS is unwilling or unable to allow the RO their free choice of agent then I would suggest that the RO should copy the resource to an RS that does allow them to choose the AS. As to the information transfer between AS and RS, it makes a big difference if the end-ser is the RO or not. > > Finally, here's context I think will help you on HTTP authentication: > > An HTTP server can indicate that its response to a resource request > might change if the client were authenticated. It does so by sending a > "WWW-Authenticate" response header, containing a list of authentication > schemes that the server will accept. In the context of GNAP, you can see > that in "RS-first Method of AS Discovery", currently section 9.1. > OK. > > If the client chooses to use one of those schemes, then it sends a new > request containing an "Authorization" header. The contents of that > header are mostly specified by the selected authentication scheme; for > GNAP, that's covered in "Securing Requests from the Client Instance", > "Presenting Access Tokens", which is currently section 7.2. > OK. > > GNAP departs from older HTTP authentication schemes because in between > the above two steps, the client goes off and talks to somebody else (the > AS) for a while. But that side conversation is invisible to the RS, > which just sees the client send one unauthenticated request and then a > second request that contains an access token. > An unauthenticated request to the RS may return a pointer to the AS controlling that resource if the RO wants to allow RS-first flows. Otherwise, discovery of the AS and resources associated with the RO should be out of scope for GNAP. If the client already knows that the RS uses a specific GNAP AS, then > the RS doesn't even get that first unauthenticated request; the first > time it hears anything from the client is after the conversation with > the AS is finished. But I'm interested in the case where the client has > no prior knowledge about the RS, which means it works as I've described > above, just like any other HTTP auth scheme. > I think we agree, as above. > > The problem I'm trying to address is that after the first request, the > HTTP auth spec doesn't say whether the client should use the same > credentials when requesting resources at other URLs. > This is above my pay grade. > > If the client does not send credentials on the next request, then it may > get another "WWW-Authenticate" header back without getting the resource > it actually wanted, which wastes time as it has to issue the request > again even if it has a valid access token available. > In general, "wasting time" is not my concern. I'm on the lookout for giving the RO maximum agency over the RS and if that's seen as a cost, so be it. > > But proactively authenticating to a different URL can leak information > to a malicious party, since there may be many unaffiliated ROs at a > single RS. For the Basic and Bearer schemes, the leaked information is > full credentials and a complete security compromise. In other schemes, > revealing that the end-user has credentials for some other resources is > still a privacy violation, and in addition the leaked information may > include identity details such as a username. > I'm not sure of this. In general, end-user credentials should not be the concern of the RS. For the RS as (GDPR) "processor", there are two possibilities: (a) The RS has some prior understanding of the RO's identity and can associate authentication credentials with that identity. (b) The RS has no prior understanding of the RO identity and simply takes a key or certificate on a Trust on First Use basis. > > I briefly discussed in my previous mail how the Basic and Digest schemes > approach this. Bearer seems to assume the client has prior knowledge > about which resources a token gives it access to=E2=80=94which is reasona= ble > given how OAuth 2.0 has been used, but GNAP's RS-first discovery opens > up new use cases with new challenges. So I believe this needs to be > addressed somehow, and I've proposed one possible way to do it. > I hope my answers above have helped. You may be raising a security issue that does not imply any power shift between the RO and the RS. In cases where the end-user is not the RO, the end-user has legitimate privacy interests relative to both the RS and AS but I don't understand if your proposal impacts this. - Adrian > > > I hope this clarified my proposal for you! > Jamey > [1] https://www.hl7.org/fhir/ [2] https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APIT= FRecommendations.pdf [3] https://kantarainitiative.org/confluence/display/uma/Home [4] https://openid.net/wg/heart/ [5] https://datatracker.ietf.org/meeting/111/materials/slides-111-gnap-gnap-and= -w3c-verifiable-credentials-api-01 - Adrian --000000000000735bc905c822c169 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jamey,

tldr: My perspective in the GNAP discussion is to maximiz= e the power of the RO and minimize the power of the RS by assuming that the= RO can delegate to _any_ AS they choose.=C2=A0

I= 9;m grateful for your conversation because you are helping me tease out whi= ch aspects of GNAP are essential for my (fairly common) use-case. My use-ca= se is securing a very complex (HL7-FHIR [1]) and regulated=C2=A0(US Gov API= Task Force [2]) API to health records. This work has been evolving for a d= ecade or more in the Kantara UMA WG [3] and the OpenID HEART WG [4] with al= most zero commercial uptake.

My goal is to use GNA= P to replace as much of the OAuth, UMA, and OIDC example implementation of = delegated health records access. Links to our repos are on the last slide o= f yesterday's presentation [5].

continuing inl= ine....

On Tue, Jul 27, 2021 at 2:25 PM Jamey Sharp <jamey@minilop.net> wrote:
Hi Adrian!

I agree with the general principles you're suggesting, but I don't =
believe my proposal reveals anything new to the RS. A resource server
has to know what resource the end-user is requesting in order to serve
that resource.
Yes.=C2=A0

(The cryptography notions of "private information retrieval" and =
"oblivious RAM" would be an interesting challenge to apply to the= web,
but I'm sure they're well out of scope for this WG. You might enjoy=
reading the research literature on them though.)
Sure.= My concern is RO power and control, not security.

My proposal does potentially reveal new information to the AS, and
that's worth thinking about. There are two cases:
= No problem. I want to maximize the ROs agency by giving their delegated AS = as much power (privilege or capability) as the RO wants.

If it's desirable for the AS to reveal to the end-user the set of
resources to which they've been granted rights=E2=80=94and I think it i= s=E2=80=94then
that means the RS must have previously informed the AS about what the
resource references which the RS uses actually refer to. Otherwise, a
reference is an opaque string like "WallyWorld" that means nothin= g to
either the end-user or the AS. (It certainly doesn't mean anything to <= br> me: I'm taking that from the original examples in the HTTP Basic auth <= br> spec, going back to at least 1996.)
Yes. Seems obvious= .=C2=A0

Second, I've proposed that the client inform the AS of the specific resource and method which the end-user was trying to request. I'm not <= br> sure whether that's either necessary or desirable; I'm hoping other=
folks will chime in on my questions about whether the client needs to be able to indicate that it understands this generic "http" rights t= ype.
Yes. I have no problem with AS, as the RO's a= gent, being informed to the extent the end-user is willing to share their= =C2=A0attributes and their intent.=C2=A0

I think it's worth noting that the choice of AS is made by the RO/RS, <= br> not by the end-user. So the safest assumption you can make when
analyzing the privacy properties of GNAP is that the RS and AS may
reveal any information they have to each other without the end-user's <= br> knowledge or consent. That doesn't change the above analysis though, since the only things the AS may learn are things the RS already knows.
=
Careful. "Separation of Concerns", avoiding cen= sorship, and data minimization dictate that the choice of AS should be made= by the RO.=C2=A0 If an RS is unwilling or unable to allow the RO their fre= e choice of agent then I would suggest that the RO should copy the resource= to an RS that does allow them to choose the AS.

A= s to the information transfer between AS and RS, it makes a big difference = if the end-ser is the RO or not.

Finally, here's context I think will help you on HTTP authentication:
An HTTP server can indicate that its response to a resource request
might change if the client were authenticated. It does so by sending a
"WWW-Authenticate" response header, containing a list of authenti= cation
schemes that the server will accept. In the context of GNAP, you can see that in "RS-first Method of AS Discovery", currently section 9.1.=
=C2=A0OK.

If the client chooses to use one of those schemes, then it sends a new
request containing an "Authorization" header. The contents of tha= t
header are mostly specified by the selected authentication scheme; for
GNAP, that's covered in "Securing Requests from the Client Instanc= e",
"Presenting Access Tokens", which is currently section 7.2.
OK.=C2=A0

GNAP departs from older HTTP authentication schemes because in between
the above two steps, the client goes off and talks to somebody else (the AS) for a while. But that side conversation is invisible to the RS,
which just sees the client send one unauthenticated request and then a
second request that contains an access token.
An unaut= henticated request to the RS may return a pointer to the AS controlling tha= t resource if the RO wants to allow RS-first flows. Otherwise, discovery of= the AS and resources associated with the RO should be out of scope for GNA= P.

If the client already knows that the RS uses a specific GNAP AS, then
the RS doesn't even get that first unauthenticated request; the first <= br> time it hears anything from the client is after the conversation with
the AS is finished. But I'm interested in the case where the client has=
no prior knowledge about the RS, which means it works as I've described=
above, just like any other HTTP auth scheme.
I think w= e agree, as above.=C2=A0

The problem I'm trying to address is that after the first request, the =
HTTP auth spec doesn't say whether the client should use the same
credentials when requesting resources at other URLs.
T= his is above my pay grade.=C2=A0

If the client does not send credentials on the next request, then it may get another "WWW-Authenticate" header back without getting the re= source
it actually wanted, which wastes time as it has to issue the request
again even if it has a valid access token available.
I= n general, "wasting time" is not my concern. I'm on the looko= ut for giving the RO maximum agency over the RS and if that's seen as a= cost, so be it.=C2=A0

But proactively authenticating to a different URL can leak information
to a malicious party, since there may be many unaffiliated ROs at a
single RS. For the Basic and Bearer schemes, the leaked information is
full credentials and a complete security compromise. In other schemes,
revealing that the end-user has credentials for some other resources is still a privacy violation, and in addition the leaked information may
include identity details such as a username.
I'm n= ot sure of this. In general, end-user credentials should not be the concern= of the RS. For the RS as (GDPR) "processor", there are two possi= bilities:
(a) The RS has some prior understanding of the RO's= identity and can associate authentication credentials with that identity.<= /div>
(b) The RS has no prior understanding of the RO identity and simp= ly takes a key or certificate on a Trust on First Use basis.

I briefly discussed in my previous mail how the Basic and Digest schemes approach this. Bearer seems to assume the client has prior knowledge
about which resources a token gives it access to=E2=80=94which is reasonabl= e
given how OAuth 2.0 has been used, but GNAP's RS-first discovery opens =
up new use cases with new challenges. So I believe this needs to be
addressed somehow, and I've proposed one possible way to do it.
I hope my answers above have helped. You may be raising a sec= urity issue that does not imply any power shift between the RO and the RS. = In cases where the end-user is not the RO, the end-user has legitimate priv= acy interests relative to both the RS and AS but I don't understand if = your proposal impacts this.

- Adrian =C2=A0
<= 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">

I hope this clarified my proposal for you!
Jamey

- Adrian
--000000000000735bc905c822c169-- From nobody Tue Jul 27 16:26:10 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 511D53A0F35 for ; Tue, 27 Jul 2021 16:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Ceb6i3OnbNUG for ; Tue, 27 Jul 2021 16:25:58 -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 7523F3A0F3D for ; Tue, 27 Jul 2021 16:24:48 -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 16RNOiLj014157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 19:24:45 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Justin Richer In-Reply-To: Date: Tue, 27 Jul 2021 19:24:44 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jamey Sharp X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 27 Jul 2021 23:26:04 -0000 Hi Jamey, Thanks for this thorough writeup, this is a fascinating idea, and as an = individual I think it has some merit and warrants discussion. Now the = question is what to do with that idea, and I can think of a handful of = immediate options, detailed below. There are probably others. But first, a note: the =E2=80=9Ctype=E2=80=9D element serves an = important namespace function. In particular, a general-purpose = =E2=80=9Ctype=E2=80=9D value would want to be something that=E2=80=99s = collision-resistant, like a URI. Which URI gets used here depends a lot = on where this definition would go. The documentation that defines the = =E2=80=9Ctype=E2=80=9D element also defines the structure and contents = of the object that contains the =E2=80=9Ctype=E2=80=9D element, so the = language about what goes in =E2=80=9Clocations=E2=80=9D, = =E2=80=9Cdatatypes=E2=80=9D, and =E2=80=9Cactions=E2=80=9D would all be = defined with the =E2=80=9Ctype=E2=80=9D value. Of course, it=E2=80=99s = entirely up to an AS/RS to map a given =E2=80=9Ctype=E2=80=9D value to a = given definition set, but that=E2=80=99s the nature of protecting = general APIs with a common security protocol =E2=80=94 we can=E2=80=99t = dictate that people interpret things a particular way. These are the options for this type definition I can think of right now: 1) Defined as an appendix in GNAP Core. We can also use it in some = examples. It remains optional to interpret or support for a given AS/RS. 2) Defined in a separate GNAP document. 3) Defined by a different WG. Perhaps HTTP-API would want to look at = this? 4) Defined on a webpage on the internet, without a standards body behind = it. The URL would be the URL of the document. All of these have equal functionality inside of GNAP because of the = supremacy of the AS/RS in this decision. And even better, anything = defined for this part of GNAP is immediately usable in OAuth 2 RAR as = well. I=E2=80=99d like to hear what people think about this proposal =E2=80=94 = is it a good one, is it worth writing down, and if so, where? =E2=80=94 Justin > On Jul 26, 2021, at 9:04 PM, Jamey Sharp wrote: >=20 > In today's meeting, I asked about applying GNAP as the HTTP = authentication method for arbitrary HTTP resources, such as static = files, in the same way that Basic and Digest auth can be used today. = Justin asked me to share the question here. >=20 > Because the current draft includes RS-first AS discovery using the = standard WWW-Authenticate response header, it might work for this use = case as-is, but I think it can be improved. >=20 > First: Am I correct in thinking that two access tokens retrieved from = the same AS, by the same end user, with the same "access" list, should = be indistinguishable to the client? Specifically, if a client receives = two `WWW-Authenticate: GNAP` headers with the same "as_url" and "access" = parameters, can it reuse the access token it got for the first request = on the second request, without consulting the AS again? >=20 > If so, I think the WWW-Authenticate "access" parameter is equivalent = to the "realm" parameter defined in RFC7235 and used in RFC7617 Basic = auth. (Perhaps for consistency with HTTP auth, it should in fact be = called "realm" when used in that header? RFC7235 even uses "scope" = terminilogy to describe it.) >=20 > Without additional provisions, which I'm pretty sure are not currently = in GNAP, checking for matching realm/access parameters still requires an = extra unauthenticated request any time the client needs to access a URL = it hasn't visited before, even if the response turns out to indicate = that an earlier access token can be reused. >=20 > RFC7617 defines somewhat magic rules for when a client can proactively = provide Basic-scheme credentials to a URL where it hasn't previously = seen a WWW-Authenticate header, in order to avoid a round-trip in the = common case where the same credentials are accepted at similar URLs. In = theory, GNAP could specify something similar to make RS-first AS = discovery more efficient, but that level of magic seems dangerous to me. >=20 > The Digest auth scheme in RFC7616 instead allows the server (in this = context, the RS) to give an explicit list of URL prefixes which accept = the same credentials, in the WWW-Authenticate "domain" parameter. I = think that's a closer fit for GNAP, but rather than making it a header = parameter, I think it's best to fold it into the token's access rights. >=20 > I propose standardizing a definition of a "type" value for the rights = request that describes HTTP access rights generically, rather than = describing actions appropriate to a specific API. I think that would = make GNAP usable anywhere that Basic or Digest auth are currently used. = It might also enable a wide variety of RESTful APIs and HTTP-based = standards to use GNAP without needing to define custom rights types. >=20 > Here is a concrete suggestion as a starting point for discussion: >=20 > "access": [{ > "type": "http", > "locations": ["https://example.com/protected/"], > "datatypes": ["text/html", "image/*"], > "actions": ["GET", "PUT", "DELETE"] > }] >=20 > A resource request must match all fields to be allowed. If "datatypes" = or "actions" are empty or absent, then all are permitted. (Permitting = nothing is the same as not granting any rights at all.) The "locations" = field is required to be present and non-empty though, and might work = like the "domain" parameter in Digest: "The client can use this list to = determine the set of URIs for which the same authentication information = may be sent: any URI that has a URI in this list as a prefix [...] MAY = be assumed to be in the same protection space." >=20 > This allows a client to request a limited set of methods or access to = a limited portion of the protection space. It also allows the AS to = inform the client of exactly which requests it may use the access token = on, which may be different than what the client requested. >=20 > If I'm reading the current draft correctly, if a client sends an = opaque resource reference like `"access": "WallyWorld"`, then the AS may = choose to send back a non-opaque description of the rights granted by = the returned access token, such as the above example for the = hypothetical "http" rights type. Is that right? >=20 > I suppose the downside of the AS transforming an opaque reference into = a full rights description is that the client can't indicate which rights = types it understands. If a CMS supports a proprietary API for editing = blog posts, but also supports WebDAV for file attachments, it might not = be clear which rights type to use, yeah? >=20 > So here's an additional proposal: a client wishing to use this generic = HTTP rights type should (must?) explicitly request it in the "access" = rights request (and may also include the resource reference given in the = "access" parameter of the WWW-Authenticate header, if any). It must = specify the exact request URL in the "locations" field, and may also = specify the method it tried to use in "actions". As usual, the AS may = return a token granting rights to a wider range of locations or methods = and is recommended to return the actual granted rights. >=20 > I hope that's reasonably clear and would love to discuss this further. >=20 > Jamey >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Jul 27 18:06:25 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 C23DB3A145C for ; Tue, 27 Jul 2021 18:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=minilop.net 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 DZGUGYTok3sS for ; Tue, 27 Jul 2021 18:06:18 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 729B13A145A for ; Tue, 27 Jul 2021 18:06:18 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id m1so2671790pjv.2 for ; Tue, 27 Jul 2021 18:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minilop.net; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Lpho3Fwvd/ps+B4TJmw207oSuGAzSY0yxEC21bzbV4g=; b=UkfC21bw9e5xTCLtYLWBY2+ldTSBtxbkzc3pO3p6udfy6R3dUcmIj8QDgZCACn0GxE t8qkUSc8TUs8G4JBqq7+keCQJR1IrCMiHh+oabtT6LAdUAIk2UYqmHct84NX3Z9pQnVC zFF+r+KA/7XijvKaqWpNoYzbnZEcKfJk/8y7o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Lpho3Fwvd/ps+B4TJmw207oSuGAzSY0yxEC21bzbV4g=; b=EnLSZte5ULMq1quVoQGiaaDMs2dggof6lr2CTdDie6/eUMDp4dZ1JrjNeUxW4362Qd yw/Al48UFpUma/VGwJBvoPy2FDYUUND6DnTfuukLLhCVNt0d9C2POdakYdBRkdUeeUXI mjoOfQrtYKrfqfM99t6Pzrj9X3ZKJVsKRmoFhqs9cv64XlyS2zS4msK78h1XFR7NM2nQ lUJJ/OerpWtme+x0FpICnFQmaVYd7MfoC+2ZKMye4ZVh4veBVaPIS0DyJ+vWzTd9giJg 9y8q+xo3cmuvgDG9md2V/4afiQ/l6VYpGrJaAsEEfhBl5ID4YlYrFcwR80lNL77rUqhC rn8Q== X-Gm-Message-State: AOAM533ptqITxFArsAcTXJQiobVTNtsaxHrc6QMSTvn7dadzpNWwwu2g qKUoXE/0/OHdAcOa2PM2tvDqgVyRgkOxTyd7 X-Google-Smtp-Source: ABdhPJwAE0Cn5pMDnUTb3WE8sxPUWuvbWnl+sG5fsLqRSvTxaWNZmQcjrXgZqkgqLO07KK3I8GBzTA== X-Received: by 2002:a17:90a:24c:: with SMTP id t12mr24699370pje.64.1627434377329; Tue, 27 Jul 2021 18:06:17 -0700 (PDT) Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id e2sm5541239pgh.5.2021.07.27.18.06.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jul 2021 18:06:16 -0700 (PDT) Received: by eh (sSMTP sendmail emulation); Tue, 27 Jul 2021 18:06:15 -0700 Date: Tue, 27 Jul 2021 18:06:15 -0700 From: Jamey Sharp To: Adrian Gropper Cc: GNAP Mailing List Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 28 Jul 2021 01:06:24 -0000 On Tue, Jul 27, 2021 at 06:54:31PM -0400, Adrian Gropper wrote: > Hi Jamey, > I'm grateful for your conversation because you are helping me tease > out which aspects of GNAP are essential for my (fairly common) > use-case. I'm glad it's helping! Just keep in mind that I read the GNAP draft for the first time yesterday. 🤣 I think I have a better understanding of your concern now. I was somewhat confused because if the resources in question are electronic health records, then the RO is the party that needs protection the most, while in the cases I usually think about, it's the end-user's privacy that is most at risk. I don't believe anything I'm proposing affects your use case, because I'm only proposing a resource rights type and possibly some end-user behavior. As far as I can tell, - GNAP's privacy and security promises should not depend on the specifics of any rights type; - your application wouldn't use this rights type and so would not be affected regardless; - and any protections which GNAP offers an RO should apply regardless of the behavior of any end-user. Jamey From nobody Tue Jul 27 21:29:35 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 5141E3A1B70 for ; Tue, 27 Jul 2021 21:29:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iaEBHwH7aD8y for ; Tue, 27 Jul 2021 21:29:29 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 EBEB63A1B6D for ; Tue, 27 Jul 2021 21:29:28 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id n19so1506536ioz.0 for ; Tue, 27 Jul 2021 21:29:28 -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=wHsXuhd3vcClQ5PmHGpp28iz+N/7UCOrfWrnJP7lZSc=; b=dscEFCZYkdtGDeqrWH1t2V7FgCytHOfjGyMeB/IWzd7B62Qjl/M1rgjKN24Wgs/0V1 uSpNlwgpAROC3IEyduXLxHAjjhuLGIsU8dZWV6uzg5bByxtiDHxZWRLPWoZi5UJtNSSK Q1XZEg6+jikTu1TQM1Ob9mkt1o3JMwnyjTJ5HcdVR/j+p9A22Sc5VzYA8mAcmOSErdYn S6CknrWYEXrytcAGtyFNDs0GE7QmvuZ+mIJ1gFoguzB2EZGOonVHg/SoY0hjHJIA3pCG IfQqeGhGCd8kq7j+33dHILUDocw73KcCeUWT4dWt5hmQRMktvKq62CGRIdRIZdlCyMa9 4E7w== 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=wHsXuhd3vcClQ5PmHGpp28iz+N/7UCOrfWrnJP7lZSc=; b=Ql2Mgqs7T8ZRm3mKOYujmqLGTV5a0lnnRsgBvu8FdbNM3wbdo3zJDR8ZdzD4Mo7Pzd gHcFvRHOUKRO5US5Ubgbi6NaTtvmh0fq1cdp7Cg3V12v403be9A4QOLKDTNboIYxCqY+ iUDK7Dywqq4HEf5PMbNLbeA7K6I1TYyywcKrO6rg5IRN8MDGwl/sLyOTtcNhS2eAqmhZ 82M/LXNsuj3DWzZzUEiVTlxqPDymjkMLHlGsX1ihSX8zsrvDBV2hZBIUn5gRzqHoMRdP vZaQMNoEtde8kWKpjt+ew5ifIpDxsRCNPH68Xo1hYSrMPmXAAaVlIfmnzY2H5SARYsKj 7tnA== X-Gm-Message-State: AOAM5300uM+SConav6mkJpEpC7p2Q1Gsm4arD2OmINxx5tSzQgR9Hu28 wU6rsZgGyVp9wKXK0N7c72z1FTQvZf/7WgpyNA8= X-Google-Smtp-Source: ABdhPJwCNAp47LTDAvA0bx8KEOago05QXKT79beIuEl31LkeZ5bbI1MGNEg1apOVdsgN32VPyuNCnPqAB3Sw5Pyp3hI= X-Received: by 2002:a02:a38f:: with SMTP id y15mr24995727jak.108.1627446566998; Tue, 27 Jul 2021 21:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 28 Jul 2021 06:29:15 +0200 Message-ID: To: Justin Richer Cc: Jamey Sharp , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000084571305c8276ec6" Archived-At: Subject: Re: [GNAP] generic HTTP resource type 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, 28 Jul 2021 04:29:34 -0000 --00000000000084571305c8276ec6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The proposal answers a real problem. As a consequence, I'd tend to think it makes a good candidate in core, as chairs where looking for an appendix related to use cases anyways. For the details of what implementing that use case requires, any of the possibilities mentioned by Justin seem fine to me, although it kind of illustrates why I wasn't so fond of "type" in the first place (not in principle, but what it should represent, i.e. a unique namespace). Cheers Fabien Le mer. 28 juil. 2021 =C3=A0 01:26, Justin Richer a =C3= =A9crit : > Hi Jamey, > > Thanks for this thorough writeup, this is a fascinating idea, and as an > individual I think it has some merit and warrants discussion. Now the > question is what to do with that idea, and I can think of a handful of > immediate options, detailed below. There are probably others. > > But first, a note: the =E2=80=9Ctype=E2=80=9D element serves an important= namespace > function. In particular, a general-purpose =E2=80=9Ctype=E2=80=9D value w= ould want to be > something that=E2=80=99s collision-resistant, like a URI. Which URI gets = used here > depends a lot on where this definition would go. The documentation that > defines the =E2=80=9Ctype=E2=80=9D element also defines the structure and= contents of the > object that contains the =E2=80=9Ctype=E2=80=9D element, so the language = about what goes in > =E2=80=9Clocations=E2=80=9D, =E2=80=9Cdatatypes=E2=80=9D, and =E2=80=9Cac= tions=E2=80=9D would all be defined with the > =E2=80=9Ctype=E2=80=9D value. Of course, it=E2=80=99s entirely up to an A= S/RS to map a given =E2=80=9Ctype=E2=80=9D > value to a given definition set, but that=E2=80=99s the nature of protect= ing > general APIs with a common security protocol =E2=80=94 we can=E2=80=99t d= ictate that people > interpret things a particular way. > > These are the options for this type definition I can think of right now: > > 1) Defined as an appendix in GNAP Core. We can also use it in some > examples. It remains optional to interpret or support for a given AS/RS. > 2) Defined in a separate GNAP document. > 3) Defined by a different WG. Perhaps HTTP-API would want to look at this= ? > 4) Defined on a webpage on the internet, without a standards body behind > it. The URL would be the URL of the document. > > All of these have equal functionality inside of GNAP because of the > supremacy of the AS/RS in this decision. And even better, anything define= d > for this part of GNAP is immediately usable in OAuth 2 RAR as well. > > I=E2=80=99d like to hear what people think about this proposal =E2=80=94 = is it a good one, > is it worth writing down, and if so, where? > > =E2=80=94 Justin > > > On Jul 26, 2021, at 9:04 PM, Jamey Sharp wrote: > > > > In today's meeting, I asked about applying GNAP as the HTTP > authentication method for arbitrary HTTP resources, such as static files, > in the same way that Basic and Digest auth can be used today. Justin aske= d > me to share the question here. > > > > Because the current draft includes RS-first AS discovery using the > standard WWW-Authenticate response header, it might work for this use cas= e > as-is, but I think it can be improved. > > > > First: Am I correct in thinking that two access tokens retrieved from > the same AS, by the same end user, with the same "access" list, should be > indistinguishable to the client? Specifically, if a client receives two > `WWW-Authenticate: GNAP` headers with the same "as_url" and "access" > parameters, can it reuse the access token it got for the first request on > the second request, without consulting the AS again? > > > > If so, I think the WWW-Authenticate "access" parameter is equivalent to > the "realm" parameter defined in RFC7235 and used in RFC7617 Basic auth. > (Perhaps for consistency with HTTP auth, it should in fact be called > "realm" when used in that header? RFC7235 even uses "scope" terminilogy t= o > describe it.) > > > > Without additional provisions, which I'm pretty sure are not currently > in GNAP, checking for matching realm/access parameters still requires an > extra unauthenticated request any time the client needs to access a URL i= t > hasn't visited before, even if the response turns out to indicate that an > earlier access token can be reused. > > > > RFC7617 defines somewhat magic rules for when a client can proactively > provide Basic-scheme credentials to a URL where it hasn't previously seen= a > WWW-Authenticate header, in order to avoid a round-trip in the common cas= e > where the same credentials are accepted at similar URLs. In theory, GNAP > could specify something similar to make RS-first AS discovery more > efficient, but that level of magic seems dangerous to me. > > > > The Digest auth scheme in RFC7616 instead allows the server (in this > context, the RS) to give an explicit list of URL prefixes which accept th= e > same credentials, in the WWW-Authenticate "domain" parameter. I think > that's a closer fit for GNAP, but rather than making it a header paramete= r, > I think it's best to fold it into the token's access rights. > > > > I propose standardizing a definition of a "type" value for the rights > request that describes HTTP access rights generically, rather than > describing actions appropriate to a specific API. I think that would make > GNAP usable anywhere that Basic or Digest auth are currently used. It mig= ht > also enable a wide variety of RESTful APIs and HTTP-based standards to us= e > GNAP without needing to define custom rights types. > > > > Here is a concrete suggestion as a starting point for discussion: > > > > "access": [{ > > "type": "http", > > "locations": ["https://example.com/protected/"], > > "datatypes": ["text/html", "image/*"], > > "actions": ["GET", "PUT", "DELETE"] > > }] > > > > A resource request must match all fields to be allowed. If "datatypes" > or "actions" are empty or absent, then all are permitted. (Permitting > nothing is the same as not granting any rights at all.) The "locations" > field is required to be present and non-empty though, and might work like > the "domain" parameter in Digest: "The client can use this list to > determine the set of URIs for which the same authentication information m= ay > be sent: any URI that has a URI in this list as a prefix [...] MAY be > assumed to be in the same protection space." > > > > This allows a client to request a limited set of methods or access to a > limited portion of the protection space. It also allows the AS to inform > the client of exactly which requests it may use the access token on, whic= h > may be different than what the client requested. > > > > If I'm reading the current draft correctly, if a client sends an opaque > resource reference like `"access": "WallyWorld"`, then the AS may choose = to > send back a non-opaque description of the rights granted by the returned > access token, such as the above example for the hypothetical "http" right= s > type. Is that right? > > > > I suppose the downside of the AS transforming an opaque reference into = a > full rights description is that the client can't indicate which rights > types it understands. If a CMS supports a proprietary API for editing blo= g > posts, but also supports WebDAV for file attachments, it might not be cle= ar > which rights type to use, yeah? > > > > So here's an additional proposal: a client wishing to use this generic > HTTP rights type should (must?) explicitly request it in the "access" > rights request (and may also include the resource reference given in the > "access" parameter of the WWW-Authenticate header, if any). It must speci= fy > the exact request URL in the "locations" field, and may also specify the > method it tried to use in "actions". As usual, the AS may return a token > granting rights to a wider range of locations or methods and is recommend= ed > to return the actual granted rights. > > > > I hope that's reasonably clear and would love to discuss this further. > > > > Jamey > > > > -- > > 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 > --00000000000084571305c8276ec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Th= e proposal answers a real problem. As a consequence, I'd tend to think = it makes a good candidate in core, as chairs where looking for an appendix = related to use cases anyways.=C2=A0

For the details of what implementing that use case requires, an= y of the possibilities mentioned by Justin seem fine to me, although it kin= d of illustrates why I wasn't so fond of "type" in the first = place (not in principle, but what it should represent, i.e. a unique namesp= ace).=C2=A0

Cheers
=
Fabien=C2=A0




Le mer. 28 juil. 2021 =C3=A0 01:26, Justin Ri= cher <jricher@mit.edu> a =C3=A9crit=C2=A0:
Hi Jamey,

Thanks for this thorough writeup, this is a fascinating idea, and as an ind= ividual I think it has some merit and warrants discussion. Now the question= is what to do with that idea, and I can think of a handful of immediate op= tions, detailed below. There are probably others.

But first, a note: the =E2=80=9Ctype=E2=80=9D element serves an important n= amespace function. In particular, a general-purpose =E2=80=9Ctype=E2=80=9D = value would want to be something that=E2=80=99s collision-resistant, like a= URI. Which URI gets used here depends a lot on where this definition would= go. The documentation that defines the =E2=80=9Ctype=E2=80=9D element also= defines the structure and contents of the object that contains the =E2=80= =9Ctype=E2=80=9D element, so the language about what goes in =E2=80=9Clocat= ions=E2=80=9D, =E2=80=9Cdatatypes=E2=80=9D, and =E2=80=9Cactions=E2=80=9D w= ould all be defined with the =E2=80=9Ctype=E2=80=9D value. Of course, it=E2= =80=99s entirely up to an AS/RS to map a given =E2=80=9Ctype=E2=80=9D value= to a given definition set, but that=E2=80=99s the nature of protecting gen= eral APIs with a common security protocol =E2=80=94 we can=E2=80=99t dictat= e that people interpret things a particular way.

These are the options for this type definition I can think of right now:
1) Defined as an appendix in GNAP Core. We can also use it in some examples= . It remains optional to interpret or support for a given AS/RS.
2) Defined in a separate GNAP document.
3) Defined by a different WG. Perhaps HTTP-API would want to look at this?<= br> 4) Defined on a webpage on the internet, without a standards body behind it= . The URL would be the URL of the document.

All of these have equal functionality inside of GNAP because of the suprema= cy of the AS/RS in this decision. And even better, anything defined for thi= s part of GNAP is immediately usable in OAuth 2 RAR as well.

I=E2=80=99d like to hear what people think about this proposal =E2=80=94 is= it a good one, is it worth writing down, and if so, where?

=C2=A0=E2=80=94 Justin

> On Jul 26, 2021, at 9:04 PM, Jamey Sharp <jamey@minilop.n= et> wrote:
>
> In today's meeting, I asked about applying GNAP as the HTTP authen= tication method for arbitrary HTTP resources, such as static files, in the = same way that Basic and Digest auth can be used today. Justin asked me to s= hare the question here.
>
> Because the current draft includes RS-first AS discovery using the sta= ndard WWW-Authenticate response header, it might work for this use case as-= is, but I think it can be improved.
>
> First: Am I correct in thinking that two access tokens retrieved from = the same AS, by the same end user, with the same "access" list, s= hould be indistinguishable to the client? Specifically, if a client receive= s two `WWW-Authenticate: GNAP` headers with the same "as_url" and= "access" parameters, can it reuse the access token it got for th= e first request on the second request, without consulting the AS again?
>
> If so, I think the WWW-Authenticate "access" parameter is eq= uivalent to the "realm" parameter defined in RFC7235 and used in = RFC7617 Basic auth. (Perhaps for consistency with HTTP auth, it should in f= act be called "realm" when used in that header? RFC7235 even uses= "scope" terminilogy to describe it.)
>
> Without additional provisions, which I'm pretty sure are not curre= ntly in GNAP, checking for matching realm/access parameters still requires = an extra unauthenticated request any time the client needs to access a URL = it hasn't visited before, even if the response turns out to indicate th= at an earlier access token can be reused.
>
> RFC7617 defines somewhat magic rules for when a client can proactively= provide Basic-scheme credentials to a URL where it hasn't previously s= een a WWW-Authenticate header, in order to avoid a round-trip in the common= case where the same credentials are accepted at similar URLs. In theory, G= NAP could specify something similar to make RS-first AS discovery more effi= cient, but that level of magic seems dangerous to me.
>
> The Digest auth scheme in RFC7616 instead allows the server (in this c= ontext, the RS) to give an explicit list of URL prefixes which accept the s= ame credentials, in the WWW-Authenticate "domain" parameter. I th= ink that's a closer fit for GNAP, but rather than making it a header pa= rameter, I think it's best to fold it into the token's access right= s.
>
> I propose standardizing a definition of a "type" value for t= he rights request that describes HTTP access rights generically, rather tha= n describing actions appropriate to a specific API. I think that would make= GNAP usable anywhere that Basic or Digest auth are currently used. It migh= t also enable a wide variety of RESTful APIs and HTTP-based standards to us= e GNAP without needing to define custom rights types.
>
> Here is a concrete suggestion as a starting point for discussion:
>
> "access": [{
>=C2=A0 "type": "http",
>=C2=A0 "locations": ["https:/= /example.com/protected/"],
>=C2=A0 "datatypes": ["text/html", "image/*&quo= t;],
>=C2=A0 "actions": ["GET", "PUT", "DE= LETE"]
> }]
>
> A resource request must match all fields to be allowed. If "datat= ypes" or "actions" are empty or absent, then all are permitt= ed. (Permitting nothing is the same as not granting any rights at all.) The= "locations" field is required to be present and non-empty though= , and might work like the "domain" parameter in Digest: "The= client can use this list to determine the set of URIs for which the same a= uthentication information may be sent: any URI that has a URI in this list = as a prefix [...] MAY be assumed to be in the same protection space."<= br> >
> This allows a client to request a limited set of methods or access to = a limited portion of the protection space. It also allows the AS to inform = the client of exactly which requests it may use the access token on, which = may be different than what the client requested.
>
> If I'm reading the current draft correctly, if a client sends an o= paque resource reference like `"access": "WallyWorld"`,= then the AS may choose to send back a non-opaque description of the rights= granted by the returned access token, such as the above example for the hy= pothetical "http" rights type. Is that right?
>
> I suppose the downside of the AS transforming an opaque reference into= a full rights description is that the client can't indicate which righ= ts types it understands. If a CMS supports a proprietary API for editing bl= og posts, but also supports WebDAV for file attachments, it might not be cl= ear which rights type to use, yeah?
>
> So here's an additional proposal: a client wishing to use this gen= eric HTTP rights type should (must?) explicitly request it in the "acc= ess" rights request (and may also include the resource reference given= in the "access" parameter of the WWW-Authenticate header, if any= ). It must specify the exact request URL in the "locations" field= , and may also specify the method it tried to use in "actions". A= s usual, the AS may return a token granting rights to a wider range of loca= tions or methods and is recommended to return the actual granted rights. >
> I hope that's reasonably clear and would love to discuss this furt= her.
>
> Jamey
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/= listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--00000000000084571305c8276ec6-- From nobody Fri Jul 30 08:35:04 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E85573A2DB8; Fri, 30 Jul 2021 08:34:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162765929687.10221.12703201565157373845@ietfa.amsl.com> Date: Fri, 30 Jul 2021 08:34:56 -0700 Archived-At: Subject: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-10-05 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 15:34:57 -0000 The Grant Negotiation and Authorization Protocol (gnap) WG will hold a virtual interim meeting on 2021-10-05 from 19:00 to 20:00 Asia/Jerusalem (16:00 to 17:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=68e7c299-7db7-43ec-9c54-332a7502f416