From nobody Sun Aug 1 01:31:17 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 9A9913A3249 for ; Sun, 1 Aug 2021 01:31:14 -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_H4=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=LvygFV/E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AZ/M0QCj 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 wzaRxulBLCjn for ; Sun, 1 Aug 2021 01:31:09 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4D63A3247 for ; Sun, 1 Aug 2021 01:31:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 47BBF320084E for ; Sun, 1 Aug 2021 03:34:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 01 Aug 2021 03:34:45 -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=bz3JcXT7jL5 2G6H24xoirlAqdn522ob4lX4UQ/oZTWw=; b=LvygFV/EDbVy1P9A3/MD1v4TQ5m lzi3oQ/v6sJXoSQk+Aob8dYZvPEFnQ4EHHOFQ5FM26aa/N09aLxYxejm1GS91QVg gFmMN7XxXQXa09nnaxCdjI1CyckTF+cJcHHntt7wuR7Kd3vvxcPXTjG9OuPESyDC 3fo3vKy7wuAJYDFtoW0eQRcib60FtmoCQkUcNng+L+Uxo6PKYGjG52+FS8k0PVXL yt3FU+uYJ3VMDiX6iYPW5BaTAO1/RpLk1M//9jZO4Jf+4jToKfjk78D4lQXUyrbw C+2GP74pELaX/lT5QVryoojzF5h5qiDIOBl0JP5EQ0nndAqxn2dHjnqfLjg== 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=bz3JcXT7jL52G6H24xoirlAqdn522ob4lX4UQ/oZTWw=; b=AZ/M0QCj AZdNmSinzp4ZNRrzkqGY4yNnjVrI+akfO1Cb6zUMcVaa5Jh7gbLRLA5Et5ivX/RY XajnAeRtr/78iduU5ThUd9spB16aKiPNTa19PYHtodkuuTPznojqQ9LFrQ2iv0u6 7CDMAjlsVm8aCntszr0aP+TccYEVvE32aVy8qlkzYYmFun1CpYa5ZdcFdYZxW31B pu6paKrWMDE9i49PfyvAk8+r9ANR0bp4CMrFo2EQi7WqokF6z6X5MLV9bastoJ9R tSuOwaELZ6SLgsKxlXZyKzT2bbjlABOkpEKkBZ+jJpvpwmNqoFjqMmu7EgnhHgfn mrEhgfqtvsw6Uw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheelgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmnecujf gurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhihucet tghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeugfef hfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 1 Aug 2021 03:34:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1680938252125354846==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210801083108.DB4D63A3247@ietfa.amsl.com> Date: Sun, 1 Aug 2021 01:31:08 -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, 01 Aug 2021 08:31:15 -0000 --===============1680938252125354846== 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 (+4/-3/=F0=9F=92=AC98) 4 issues created: - Trust relationships for a model using TLS and no client instance keys (= by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/301=20 - Editorial: references in running text (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/300=20 - Why do we even support symmetric keys? (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/299=20 - Untrusted security-critical information from the Client (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/298=20 9 issues received 98 new comments: - #299 Why do we even support symmetric keys? (4 by agropper, fimbault, j= richer, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/299=20 - #298 Untrusted security-critical information from the Client (2 by jric= her, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/298=20 - #295 In practice, only rights are supported but attributes should als= o be supported (2 by Denisthemalice, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/295=20 - #292 Does a client instance really need to be identified by a unique ke= y ? (51 by Denisthemalice, aaronpk, agropper, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/292=20 - #290 Checks needed to defeat user collaborative attacks are unfortunate= ly out of the scope of the document (35 by Denisthemalice, aaronpk, fimbaul= t, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/290=20 - #288 Since both rights and resource locations must be disclosed to the = AS, the AS can act as Big Brother (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/288=20 - #113 Applicability of OAuth PoP (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/113=20 - #112 Use of OAuth PoP without access tokens (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/112=20 - #68 Syntax for single and multiple access tokens (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/68=20 3 issues closed: - Syntax for single and multiple access tokens https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/68=20 - Use of OAuth PoP without access tokens https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/112=20 - Applicability of OAuth PoP https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/113=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============1680938252125354846== 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 August 01, 2021

Events without label "editorial"

Issues

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

4 issues created:

9 issues received 98 new comments:

3 issues closed:

Repositories tracked by this digest:

--===============1680938252125354846==-- From nobody Sun Aug 1 15:08: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 816153A14B1 for ; Sun, 1 Aug 2021 15:08:33 -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, 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 zevDBn-Hv60a for ; Sun, 1 Aug 2021 15:08:28 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 D98C23A14AC for ; Sun, 1 Aug 2021 15:08:28 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id m10-20020a17090a34cab0290176b52c60ddso22011185pjf.4 for ; Sun, 01 Aug 2021 15:08:28 -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:mime-version:content-disposition :in-reply-to; bh=sb50A1Tw6/FJ7FJU0eR4g/0QsIXjC3yiA4wPe01goeQ=; b=f6Vffhmit1b3SPi5MOhOf6Txw258lV+CUKPhY200B3Cb5QRI89OexzVPfpHOgrll0d aulkB5F/KoYRns/1bxKcbQf/j5keht5iLWL4N3g7m9r01Wg5zS5f+YyjsDqNar2MS1jG +5EQ+1YLVqjv1DMRVK2GG+K+0zhAKRHIGfatQ= 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:mime-version :content-disposition:in-reply-to; bh=sb50A1Tw6/FJ7FJU0eR4g/0QsIXjC3yiA4wPe01goeQ=; b=VmrntBq8Oy0npfotAfKjEFbbqG7VFdymHqI3g+B6OfvIGQu05+lS63X0l90ZXuCqoM qH9fMePmDpF7xoE7J/au7fD+BqAslN6TvtUkeufB36ngh2y6XSatL2wfJPuZfdXehMha CuvrOgW5s3PSa6Iph585qsiKhGYgqHOzN+VZ3U6KLSgpV5BnxoZKIkfuROQu5ZeqKHJO JeYQanU3TwSYLgx3rNbv+4lDKzl80J172zJeFeAqP41ZNH6QMnGn8dcPIzwCkW2EqAqh 6RoFwRMZb/0Hmm+KTdHp/08EZIGkTzGKQFpmplMhluxC9JxJxlh0jkOdFUVhSPtpu5Fk Lgeg== X-Gm-Message-State: AOAM53269eGZ7iRUkwLUcf0igbift3cYcLezidMSKkmgy3H7Iam8DE8k 8IFblMILgz3MBpHzRoTgAUj9Gw== X-Google-Smtp-Source: ABdhPJyoDIhbPuRsHQ1UDLAkWBqyoxLzwM+t/jJtUyHzZ+8FoI/SHz3XIUV04oWWYALlnavCEuHXqA== X-Received: by 2002:a63:4e51:: with SMTP id o17mr3834890pgl.126.1627855707307; Sun, 01 Aug 2021 15:08:27 -0700 (PDT) Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id t8sm754708pja.41.2021.08.01.15.08.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Aug 2021 15:08:26 -0700 (PDT) Received: by eh (sSMTP sendmail emulation); Sun, 01 Aug 2021 15:08:25 -0700 Date: Sun, 1 Aug 2021 15:08:25 -0700 From: Jamey Sharp To: Justin Richer , Fabien Imbault Cc: txauth@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline 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: Sun, 01 Aug 2021 22:08:34 -0000 Hi Justin and Fabien! Thanks for your kind responses. You both provided helpful information about the process and requirements, but I'm less clear on what my next steps should be. In the interests of trying something, here's some text that I propose as a starting point for an appendix in the core draft. I welcome edits or complete rewrites. Many resources have simple access policies which map well onto standard HTTP semantics. For example, authorization for WebDAV can generally be defined in terms of a WebDAV collection and a set of HTTP methods which the client instance is permitted to apply to members of that collection. (NB: I haven't touched WebDAV in years, I have no idea if this is a good example) This resource type supports such generic HTTP access policies. HTTP user agents which implement RFC7235 MAY support GNAP with this resource type as an alternative to other generic authentication schemes such as Basic (RFC7617) or Digest (RFC7616). type (string): "urn:ietf:gnap:http" locations (array of strings): URL prefixes to which the client instance MAY issue requests using this access token without first sending a preflight RS-first AS discovery request. This array MUST NOT be absent or empty. Each URL in this array MUST use a scheme of "http" or "https", MUST be an absolute URI, and MUST have a non-empty path component. actions (array of strings): HTTP methods which the client instance MAY use at the RS. Per RFC7230, the request method is case-sensitive. If this array is absent or empty, this access object permits all methods. If an access object permits a request, that is not a guarantee that issuing that request to the RS will succeed. However, if an access object does not permit a request, then the client instance MUST NOT issue that request using that access token without first performing an RS-first AS discovery. A client instance without any prior knowledge of the resource types in use at an RS MAY attempt to use this generic HTTP resource type during GNAP requests to the AS. An AS MUST NOT implement a resource type with the same value of "type" as given here but with different semantics. A client instance which performs RS-first AS discovery SHOULD be prepared to accept an access policy from the AS which uses this generic HTTP resource type. An RS which uses this resource type SHOULD respond to RS-first AS discovery with an `access` parameter which the AS is configured to expand to an access object of this type. If it does so, the AS SHOULD return an access list containing both the resource reference given in the `access` parameter as well as the full access object of this type. Returning the full access object enables the client instance to avoid issuing preflight RS-first AS discovery requests for any request that the access object permits. If the client later performs RS-first AS discovery again and recieves the same `as_url` parameter in response, then returning the resource reference in the access list enables the client instance to discover that it has a valid access token for that resource reference, so it doesn't need to query the AS again. I kind of want to add something like this as well, but started confusing myself about what the client can and can't do with it: datatypes (array of strings): Media types or ranges which the client instance MAY send in request bodies. The syntax for each string is given by the "media-range" EBNF production in RFC7231. If this array is absent or empty, this access object does not permit request bodies. To allow any request body, use a media range of "*/*". Note that if an access object permits the "POST" method for resources which are expected to be the target of HTML form submissions, then that object likely needs to list "multipart/form-data" and/or "application/x-www-form-urlencoded" as permitted datatypes. Thoughts and feedback? Thanks, Jamey From nobody Wed Aug 4 10:48: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 830603A0DC0 for ; Wed, 4 Aug 2021 10:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-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=mitre.org 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 3LZWP0-_lAUm for ; Wed, 4 Aug 2021 10:47:56 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (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 8C3AD3A0DC4 for ; Wed, 4 Aug 2021 10:47:56 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 132C673C005 for ; Wed, 4 Aug 2021 13:47:54 -0400 (EDT) Received: from smtprhmv1.mitre.org (unknown [10.20.200.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id A9BC06CC00F for ; Wed, 4 Aug 2021 13:47:53 -0400 (EDT) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id 23E8C80D547 for ; Wed, 4 Aug 2021 13:47:53 -0400 (EDT) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GfzjP3R1Tz29psd; Wed, 4 Aug 2021 17:43:36 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2104.outbound.protection.outlook.com [104.47.64.104]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GfzcR1DQtz29psh for ; Wed, 4 Aug 2021 17:43:34 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EpoKlDy2e/y4m+dTfzlQx7ZgiY1Kt7cQ6H0CO1LG2f0pXu1lqizasHF8fSk6uTIJzTEolZ8qI5poOX5g5uHDKfKY/LjOwWRygwgkGXf4a+3MAWlHrzHzTzZMdV/CTvpOYaPjAp+DM8WX9M4yizem02UKSk3I7ekoEJNqz2xWx3bZUOIo3iBWNs0SALmvI1ZN5hvynUL1VOYJ4qcZ6pXBzD1BWLhlgGJiZxLohtlTBIkdk0dCiFB+CI6v4KsWG/0fUoTHi2nXUChOCD2UI7g9EApNI3f4W6VYjJgGLyLkMY8/H5ctIAxs81aSPRenMTTQCJdnCJ9mpISZ642zYfKQLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/JPaXlJYZJeh/Z8U1CSmtMkuiZY35WrWUqjNd+rHeiI=; b=RCmlPMQflBfLbAmfSRZ0AQFDgES0JaXz0sNGZB+Vex8k2R6bOrFXrx7tJCbE9KGVU7M7W8XuHcf/nH3ClYxNaBkbR+rOaEq0sfSHF4bJlHkJLoHJuSv2NwRh3UBPFzNzh0sofnw7g1hVN8a7Zih7cqxV/4pIPHdTKvmoIf5RFJNJM1Hc3UkzLlaZYHf4PEdzH4Mc/IsvUuU00yrqM1ul+O+qol5pha1nTbWiRIr+JNs4KLzIvS9bbTzZyV+SAi3RXPQ8M1mRjsDQG3RdDbKa3yzll1+jodxiE+l7UDokBzO6GRHUrxslhuC/Qgfpihz1QpTD+BcOFg4lRzfD/dI14Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB8544.namprd09.prod.outlook.com (2603:10b6:806:170::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15; Wed, 4 Aug 2021 17:43:33 +0000 Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::153f:4e8c:eadd:935d]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::153f:4e8c:eadd:935d%7]) with mapi id 15.20.4373.027; Wed, 4 Aug 2021 17:43:33 +0000 From: "Dr. Kelley W Burgin" To: "txauth@ietf.org" Thread-Topic: OAuth 2.0 Token Exchange profiles feedback request Thread-Index: AQHXiVfJb87UEDW1QkiXUfBYpryPXA== Date: Wed, 4 Aug 2021 17:43:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce14707c-58b7-4edb-47dc-08d9576f610d x-ms-traffictypediagnostic: SA1PR09MB8544: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qi3h9jt+OQj0jDWXI/34jnj7LwCf6ZSJVLk7Z6V6VS4lE+G6sv6hG3qFWjAeqztbpHyhGdllwEgblF/qB5U8NW7qTVJNCcHjjJojHivXm6CjCrWf05ssZuGs3+hF7tDB7EXbllkBQFAifAR8EtkqTq52FluQCnro/odb76S1kxml0DM8rvtJzM2unXdi9tyVqWCwdEu7LGNipC1gbYnVXkV7cntGtoblMB6kwMok/JDTWDvbWkgAWdWxJr0dorUUR8kOUCME0+jB7kSHyW2Toosk2pcolBCXF1s7v7lvcEbtMzDWjB9yTsWXUzxYO0RLmrZPKPvEi4e8PkckXrpmzQFEJyuvAud2QZOWbnARnk50jeadzUe6fgfzVfmKI7qkGrZE7coj8c2r76fsbXE3oyYlgsVk+k+UL+uw7iaEfJuQMmJTjuxd+WRX36mqNNI8bOw7p46CKfRkHWBr19DG3mLXpsjEurNLWNGZQWWUdQ2A1+Oz3m2oNrv80BPiUT+buyZdNkNsMh3o4K5ai63Ii+dk6UUG6zK6FTwenAS3KT1DoS53MHEHnV+cQj8cHP/5WoH1CcYh+q+nQ3EtLKVWV0yUULn0NkepH+sYebNKJa4/DuO74/8z6Udp2iMEGPSjAxKcjQnjR+cgx/NxxG9S2Hp7UlgDx4Q3LIRsX/HJJk7jSjoBYWDd1spQcA9jNCbdXphlt6egX052x7NAdpArBFN3ZLDV+OpA8Fah70rMsiXEXTpvxHORg4nepGELfNGATMWgRFZCFI96V9cInta3ZcoTCc+JHTY5fdryxmfrZ3tO9LEGtCHRsJ+nYDUAiPCBilvkzH42/Fvnmgt7/88Cig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(136003)(39860400002)(346002)(55016002)(478600001)(316002)(38100700002)(166002)(38070700005)(122000001)(33656002)(91956017)(26005)(5660300002)(83380400001)(6506007)(66946007)(8936002)(64756008)(186003)(66556008)(52536014)(66476007)(66446008)(76116006)(6916009)(2906002)(71200400001)(9686003)(8676002)(86362001)(7696005)(73022008)(41612003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?NFFBG4N4s9tuKJGM+kBzHq4WIOwd/KcjVv0TWikl33P0LMpJ7DY8MSvd?= =?Windows-1252?Q?jNn73X5l79gpF5Bo1jmJV7xoVGuvczWuoCZK+CixMRVqC/ZI7k6xBDMX?= =?Windows-1252?Q?ygx8nywleXMlIc2xiehVw5Izp5MSV5hhcwx747NstF+erCivrJeUTp7y?= =?Windows-1252?Q?7HIzpswNIOXOF7F/AYmAiXTGnUD11OLS406iabK3nidZVQosOSK4GPQh?= =?Windows-1252?Q?q1/KeIavcjnKjsY9LVaof85Pls0jrxEs5Ng9ygWa7XbgSEFUByn+hsUS?= =?Windows-1252?Q?afhcK7jai73onguEQQZLuKZVYib/hVZJnrBXxFdw+e0hzkDOVx7AeYwU?= =?Windows-1252?Q?c+oDl4VAW+PgRqHheX5hJ91pdbFTYUuJmYPQVvJTtPwYFcqebUlSQE7m?= =?Windows-1252?Q?HNVT8e1TXdyFS9plwY2AgBhEoFVE15yNzUyrTrilDd0y7GCRIiUhl5Pi?= =?Windows-1252?Q?YJOi/M/qpFsvlTHZ1KvvQ1SNPoSslAQ2lIGG35lUr8B6qUAp0jPep76b?= =?Windows-1252?Q?Q1RfDh5L8MeFfbDMaJqA0/D36+BWoFc8lNwUk1ngIkEh2c7Xxxjki/8V?= =?Windows-1252?Q?kFyUwqu4aMfVHsnsduMPmPsPdbp8RSHgQDalg2u7NA2iwmzNcWaEHE/E?= =?Windows-1252?Q?oiIk9RjmIzV+QyHn3FRBEfSgQMD95VZPwXhfvnQxvIawYDpg1biAWxpF?= =?Windows-1252?Q?frSAJ+RTOcaTOoO6psRCDmBPyGUmoQno5ny2/Wq4NAVizbsdJzhYEerf?= =?Windows-1252?Q?P2d0JmzuTC+X/uceQFhBQbD6E9EGwoUbQl+y/0xBNMXRR3nMM+2pnnvQ?= =?Windows-1252?Q?oKKuXvefTbnp9BZS45rUcGAMC3Yyhw4lCZYd0lYTfyeMeW7G2s/vTo0P?= =?Windows-1252?Q?9bJL3gP4+Zkt8Kgy7Rx3ecGSr18SqfOM2XJJNVzA/F9p8MgpWiyz5bPk?= =?Windows-1252?Q?xo9j9RAIlrkb2WWPoJ14QY0eMT3PUpROyfMEBvse2o0YxWSqPd2JWaG5?= =?Windows-1252?Q?e2ER7tFAgkxqntMwbE4tXJ10i2QIhHMlUus/5xb2tOLhkB3hW26rxfhB?= =?Windows-1252?Q?hkScBF5wObEBMGCjEd2rZWa7bYZdVw+bYjIuxLTq5EjyCIblfFCkIxFB?= =?Windows-1252?Q?pSzyEkn4x82p50YvU4+XTORewEUj4eUpbdAoNNOz5sggnKwof3qpVmVE?= =?Windows-1252?Q?+8uv94FShW7YdIGwotVNZKuqNPVnMJh4wzrSlv635EAETH7TGkHkqNWZ?= =?Windows-1252?Q?v6Uh+QjDcHbKUOuGLFsJJzOOV8PB+5dZtAbbVsdlV3Sjl+mnSaUdPPnc?= =?Windows-1252?Q?yb/AZYAa6Upgycx9JFxa4u8lPGtBg+Avk5Tbfwgs64MPl425Di/HbblX?= =?Windows-1252?Q?m1w/SIDkGQZTtFhVzMXyu4CgBdppBFhUXLtqs8B8jPcxpZbUpgjGy1X7?= =?Windows-1252?Q?JgVJt/iSoq7WAT7lW5OnMg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR09MB81426793F4B8F9A514AB4A7BA7F19SA1PR09MB8142namp_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce14707c-58b7-4edb-47dc-08d9576f610d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2021 17:43:32.9807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB8544 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:content-type:mime-version; s=BTxNELhf; bh=/JPaXlJYZJeh/Z8U1CSmtMkuiZY35WrWUqjNd+rHeiI=; b=Uz5Ruvtfbgn0ibukFX6r6rRCpMGRoV/NjVcTJIeSbov6ieE+wtcRcJ+z5qA5HSwOFkZNrXAyvaqWHfhO4qv8Q6udEvvvmIA3bAMoi5yOX3ghhSsJDqb1dBeLWxk099BfmgqepwPrf/nv2C/0/B+Ply5u9sBCamWsghaDP+O9CTI= Archived-At: Subject: [GNAP] OAuth 2.0 Token Exchange profiles feedback 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: Wed, 04 Aug 2021 17:48:02 -0000 --_000_SA1PR09MB81426793F4B8F9A514AB4A7BA7F19SA1PR09MB8142namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, MITRE, in support of the U.S. Government, has developed tailored OAuth 2.0 = Token Exchange profiles for use in an enterprise environment. These documen= ts build on the OAuth 2.0 profile MITRE released whose requirements have been incorporated into OAuth 2.1. = The documents enable =93identity chaining=94 by ensuring that the identitie= s of the user, client, and protected resources are propagated in the issued= access tokens to make appropriate access decisions. Token and Identity Chaining between Protected Resources in a Single ICAM Ec= osytem using OAuth Token Exchange Token and Identity Chaining between Protected Resources in a Multiple ICAM = Ecosytem using OAuth Token Exchange Please note, we will be working with the standards bodies to move these con= cepts forward. These current profiles and this email should be considered a= s informational as we seek additional feedback from Subject Matter Experts = throughout the Community. We welcome your comments and suggestions at OAuth= OIDCProfiles@groups.mitre.org . Regards, Kelley _________________________ Kelley Burgin, Ph.D. Cybersecurity Engineer The MITRE Corporation (865) 255 - 6699 --_000_SA1PR09MB81426793F4B8F9A514AB4A7BA7F19SA1PR09MB8142namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

All,

 

MITRE, in support o= f the U.S. Government, has developed tailored OAuth 2.0 Token Exchange prof= iles for use in an enterprise environment. These documents build on the OAuth 2.0 profile MITRE released who= se requirements have been incorporated into OAuth 2.1. The documents enable= =93identity chaining=94 by ensuring that the identities of the user, clien= t, and protected resources are propagated in the issued access tokens to make appropriate access decisions. <= o:p>

 

Token and Identity Chaining between Protected Resources in a Single IC= AM Ecosytem using OAuth Token Exchange

Token and Identity Chaining between Protected Resources in a Multiple = ICAM Ecosytem using OAuth Token Exchange

 

Please note, we wil= l be working with the standards bodies to move these concepts forward. Thes= e current profiles and this email should be considered as informational as = we seek additional feedback from Subject Matter Experts throughout the Community. We welcome your comments and sugg= estions at OAuthOIDC= Profiles@groups.mitre.org .

 

Regards,=

Kelley

___________________= ______

Kelley Burgin, Ph.D= .

Cybersecurity Engin= eer

The MITRE Corporati= on

(865) 255 - 6699

--_000_SA1PR09MB81426793F4B8F9A514AB4A7BA7F19SA1PR09MB8142namp_-- From nobody Sun Aug 8 00:50: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 5784F3A1FFF for ; Sun, 8 Aug 2021 00:50:53 -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=s+nNbbEC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C0O4+zAL 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 5pzFlcfz344v for ; Sun, 8 Aug 2021 00:50:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0724B3A1FFD for ; Sun, 8 Aug 2021 00:50:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 54E375C0107 for ; Sun, 8 Aug 2021 03:34:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 08 Aug 2021 03:34:15 -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=9F98Be6D+8v 5W4IjOFUJnMAn+4KUpH8Om1lYrWq5Rbc=; b=s+nNbbECEZZA/8iFui57Vopi8AD kuEvLz+cGbEVJrmpSGTrGLd2TpYHsk19n+Pf1uUCh0rbkaE3jk4Uioau2/5LTDYg WVYAIDTyqNisB6PlSOUI/XCTMF/E/Y5ET+jvbbZm1iMz6ZJ+TmqdhXr0uFoMtne1 h26fC2bcKgMLN5kG4PrWlKrkgcgztJw8QjTleAOTSACFArrAllZcqBu6lEiaamoJ mh7WG5PXM0rPQDgpnWL4/iJ4IGJOxlCGZgvgKC8j3yNnhRLKLHP5R6ZfLuB7N4uu CLUVNS1nXyGvrmNnrn2C//jVhU8Dqdq1bNdezRcaGnWvyHtqVuAOPdz3Gig== 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=9F98Be6D+8v5W4IjOFUJnMAn+4KUpH8Om1lYrWq5Rbc=; b=C0O4+zAL RbqPKcZKQwCvaiGxMIkUMpKfIoMXfmbY+9fuBgKdFjTfYjvDcTGD2PEPq8qxUwLS I+ibhHP3cRUGeTEsInh9Gcd7xCcN+zTSuW8CAS3zM518v67n4T81V1j8ajWbR9JB 8kbPh0NajOHBRGfou6LpdmGt/Qw9JnIKoghaWG3XPLfEhkVmEh8m+6qJxS3hCQBw CV6rMVrF/cJCQsMoTP7cg7f2/cDtygI3AMQ4awYulfTv51LrDb0OI0uCU8lCnSKE OkjQ9RIlTK7Wu1H03juYCQKVrrJ26g0IlGzdUyTRxUQ6Ms6T0BA2CxB55+k5r/1m 5YZpGvt89v1iJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeeggddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 8 Aug 2021 03:34:15 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6626891008199727413==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210808075048.0724B3A1FFD@ietfa.amsl.com> Date: Sun, 8 Aug 2021 00:50:48 -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, 08 Aug 2021 07:50:54 -0000 --===============6626891008199727413== 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 (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #288 Since both rights and resource locations must be disclosed to the = AS, the AS can act as Big Brother (2 by Denisthemalice, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/288=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============6626891008199727413== 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 August 08, 2021

Events without label "editorial"

Issues

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

1 issues received 2 new comments:

Repositories tracked by this digest:

--===============6626891008199727413==-- From nobody Tue Aug 10 10:20: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 911563A1540 for ; Tue, 10 Aug 2021 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, 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 j2YCBiHTDODd for ; Tue, 10 Aug 2021 10:20:03 -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 B4DAA3A153E for ; Tue, 10 Aug 2021 10:19:51 -0700 (PDT) Received: from himiko.fios-router.home (c-73-143-178-250.hsd1.ct.comcast.net [73.143.178.250]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17AHJljC002002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Aug 2021 13:19:48 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9A42DBDA-7055-40FD-8941-87B463C5DDD8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 10 Aug 2021 13:19:47 -0400 In-Reply-To: Cc: Fabien Imbault , GNAP Mailing List , Torsten Lodderstedt , Brian Campbell To: Jamey Sharp References: 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, 10 Aug 2021 17:20:09 -0000 --Apple-Mail=_9A42DBDA-7055-40FD-8941-87B463C5DDD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jamey, The editors discussed this and if you can, we would like to see a PR = that incorporates this idea as an appendix to the core document. We = filed an issue to track this here: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/303 = While this work could eventually end up as a separate document (and = there are some good arguments for that already), the editors think it = makes sense to at least get this written down as an appendix to start = the discussion in context of where it would be used.=20 Would you be willing/able to create a PR to add this text in? = Alternatively, if you think it should be separate, could you submit an = I-D with this proposal? Also, I=E2=80=99m copying the co-editors of the OAuth 2 RAR = specification, since anything like this defined for GNAP is also = immediately usable in OAuth 2 RAR. This is another argument for this = work being its own document, but wherever it lands, we think this is = worth talking about more. =E2=80=94 Justin (on behalf of the GNAP editors) > On Aug 1, 2021, at 6:08 PM, Jamey Sharp wrote: >=20 > Hi Justin and Fabien! Thanks for your kind responses. You both = provided helpful information about the process and requirements, but I'm = less clear on what my next steps should be. In the interests of trying = something, here's some text that I propose as a starting point for an = appendix in the core draft. I welcome edits or complete rewrites. >=20 >=20 > Many resources have simple access policies which map well onto = standard HTTP semantics. For example, authorization for WebDAV can = generally be defined in terms of a WebDAV collection and a set of HTTP = methods which the client instance is permitted to apply to members of = that collection. (NB: I haven't touched WebDAV in years, I have no idea = if this is a good example) >=20 > This resource type supports such generic HTTP access policies. HTTP = user agents which implement RFC7235 MAY support GNAP with this resource = type as an alternative to other generic authentication schemes such as = Basic (RFC7617) or Digest (RFC7616). >=20 > type (string): "urn:ietf:gnap:http" >=20 > locations (array of strings): URL prefixes to which the client = instance MAY issue requests using this access token without first = sending a preflight RS-first AS discovery request. This array MUST NOT = be absent or empty. Each URL in this array MUST use a scheme of "http" = or "https", MUST be an absolute URI, and MUST have a non-empty path = component. >=20 > actions (array of strings): HTTP methods which the client instance MAY = use at the RS. Per RFC7230, the request method is case-sensitive. If = this array is absent or empty, this access object permits all methods. >=20 > If an access object permits a request, that is not a guarantee that = issuing that request to the RS will succeed. However, if an access = object does not permit a request, then the client instance MUST NOT = issue that request using that access token without first performing an = RS-first AS discovery. >=20 > A client instance without any prior knowledge of the resource types in = use at an RS MAY attempt to use this generic HTTP resource type during = GNAP requests to the AS. An AS MUST NOT implement a resource type with = the same value of "type" as given here but with different semantics. >=20 > A client instance which performs RS-first AS discovery SHOULD be = prepared to accept an access policy from the AS which uses this generic = HTTP resource type. >=20 > An RS which uses this resource type SHOULD respond to RS-first AS = discovery with an `access` parameter which the AS is configured to = expand to an access object of this type. If it does so, the AS SHOULD = return an access list containing both the resource reference given in = the `access` parameter as well as the full access object of this type. >=20 > Returning the full access object enables the client instance to avoid = issuing preflight RS-first AS discovery requests for any request that = the access object permits. >=20 > If the client later performs RS-first AS discovery again and recieves = the same `as_url` parameter in response, then returning the resource = reference in the access list enables the client instance to discover = that it has a valid access token for that resource reference, so it = doesn't need to query the AS again. >=20 >=20 > I kind of want to add something like this as well, but started = confusing myself about what the client can and can't do with it: >=20 > datatypes (array of strings): Media types or ranges which the client = instance MAY send in request bodies. The syntax for each string is given = by the "media-range" EBNF production in RFC7231. If this array is absent = or empty, this access object does not permit request bodies. To allow = any request body, use a media range of "*/*". >=20 > Note that if an access object permits the "POST" method for resources = which are expected to be the target of HTML form submissions, then that = object likely needs to list "multipart/form-data" and/or = "application/x-www-form-urlencoded" as permitted datatypes. >=20 >=20 > Thoughts and feedback? > Thanks, > Jamey --Apple-Mail=_9A42DBDA-7055-40FD-8941-87B463C5DDD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jamey,

The editors = discussed this and if you can, we would like to see a PR that = incorporates this idea as an appendix to the core document. We filed an = issue to track this here:

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/303

While this = work could eventually end up as a separate document (and there are some = good arguments for that already), the editors think it makes sense to at = least get this written down as an appendix to start the discussion in = context of where it would be used. 

Would you be willing/able to create a = PR to add this text in? Alternatively, if you think it should be = separate, could you submit an I-D with this proposal?

Also, I=E2=80=99m = copying the co-editors of the OAuth 2 RAR specification, since anything = like this defined for GNAP is also immediately usable in OAuth 2 RAR. = This is another argument for this work being its own document, but = wherever it lands, we think this is worth talking about more.

 =E2=80=94 Justin = (on behalf of the GNAP editors)

On Aug = 1, 2021, at 6:08 PM, Jamey Sharp <jamey@minilop.net> wrote:

Hi = Justin and Fabien! Thanks for your kind responses. You both provided = helpful information about the process and requirements, but I'm less = clear on what my next steps should be. In the interests of trying = something, here's some text that I propose as a starting point for an = appendix in the core draft. I welcome edits or complete rewrites.


Many resources have simple = access policies which map well onto standard HTTP semantics. For = example, authorization for WebDAV can generally be defined in terms of a = WebDAV collection and a set of HTTP methods which the client instance is = permitted to apply to members of that collection. (NB: I haven't touched = WebDAV in years, I have no idea if this is a good example)

This resource type supports such generic HTTP = access policies. HTTP user agents which implement RFC7235 MAY support = GNAP with this resource type as an alternative to other generic = authentication schemes such as Basic (RFC7617) or Digest (RFC7616).

type (string): "urn:ietf:gnap:http"

locations (array of strings): URL prefixes to = which the client instance MAY issue requests using this access token = without first sending a preflight RS-first AS discovery request. This = array MUST NOT be absent or empty. Each URL in this array MUST use a = scheme of "http" or "https", MUST be an absolute URI, and MUST have a = non-empty path component.

actions (array of = strings): HTTP methods which the client instance MAY use at the RS. Per = RFC7230, the request method is case-sensitive. If this array is absent = or empty, this access object permits all methods.

If an access object permits a request, that is not a = guarantee that issuing that request to the RS will succeed. However, if = an access object does not permit a request, then the client instance = MUST NOT issue that request using that access token without first = performing an RS-first AS discovery.

A = client instance without any prior knowledge of the resource types in use = at an RS MAY attempt to use this generic HTTP resource type during GNAP = requests to the AS. An AS MUST NOT implement a resource type with the = same value of "type" as given here but with different semantics.

A client instance which performs RS-first AS = discovery SHOULD be prepared to accept an access policy from the AS = which uses this generic HTTP resource type.

An RS which uses this resource type SHOULD respond to = RS-first AS discovery with an `access` parameter which the AS is = configured to expand to an access object of this type. If it does so, = the AS SHOULD return an access list containing both the resource = reference given in the `access` parameter as well as the full access = object of this type.

Returning the full = access object enables the client instance to avoid issuing preflight = RS-first AS discovery requests for any request that the access object = permits.

If the client later performs = RS-first AS discovery again and recieves the same `as_url` parameter in = response, then returning the resource reference in the access list = enables the client instance to discover that it has a valid access token = for that resource reference, so it doesn't need to query the AS = again.


I kind of want to add = something like this as well, but started confusing myself about what the = client can and can't do with it:

datatypes = (array of strings): Media types or ranges which the client instance MAY = send in request bodies. The syntax for each string is given by the = "media-range" EBNF production in RFC7231. If this array is absent or = empty, this access object does not permit request bodies. To allow any = request body, use a media range of "*/*".

Note that if an access object permits the "POST" method for = resources which are expected to be the target of HTML form submissions, = then that object likely needs to list "multipart/form-data" and/or = "application/x-www-form-urlencoded" as permitted datatypes.


Thoughts and feedback?
Thanks,
Jamey

= --Apple-Mail=_9A42DBDA-7055-40FD-8941-87B463C5DDD8-- From nobody Sun Aug 15 00:51:08 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 1A8E83A0B87 for ; Sun, 15 Aug 2021 00:51:06 -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=doRaRHBf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GvE6T135 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 1SXPtHnGwF_c for ; Sun, 15 Aug 2021 00:51:00 -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 503033A0B88 for ; Sun, 15 Aug 2021 00:51:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AE7D55C00FD for ; Sun, 15 Aug 2021 03:34:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 15 Aug 2021 03:34:28 -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=30HyeGkjW/3 Eo9SaQAg8a1um8wgWf0GcYiNZrSLpcrk=; b=doRaRHBfMzRB6UZ/zL2mQ9XoBu6 0fF6zgvLZiMLkLNOEf6He9CO3l8apjE++ygolPS7RmEMZrs6s1IA8oxp+/xs5O/s ma20G3LgvUnr+d4oSRNuZXzR0lTkfD6ml2YOfen77++NfFuP1U7FJD3q7kO5vO7/ io7xKq+XCK8KWdCUhoq4iuV5KvKWzp20rqULYQPwhtcDowWXdGa2lUiMtzNPCUiC Xs/P2bO3VU1/Df25OwFYYmHmfg2cw7cDYf02gwPLZ6jujBW6PB34Qc5RMzJjR0QZ dNXdv/SFtUMrPWw/w79p99erYG4A+d589kFMkYcQY5J3OARKmGzJJ6/SstA== 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=30HyeGkjW/3Eo9SaQAg8a1um8wgWf0GcYiNZrSLpcrk=; b=GvE6T135 uoktrnr7XwFPZTsKzJRmMCbW+HTqLGVi6kDlvpUxFmwZx/PLBXPXo5f3shiTTxF1 5tVslGZVB11XsLn/BtquXVwzPmM+3r8M+6uUg+//X1eyCarwjSfF9XjE5jeRSyo5 aRTsg3XANy0CmUrfI31bQtnRL79EoR0fZh96xLtbHM5pzHxqus46F8/tp19aqBPl 6oSfZBFxsU3TLodTyHkLfVjDmkpwObuy275FC/KZmQBFK0NVyu9cpnK+G3rDo6k+ SKQKxBH81p6HW6/5wf4dtCp1kxiGMljAu5KPZPMsicNhU1giilgj1spuEh0ReA04 3YDqU4xjh2OJ2A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeekgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 15 Aug 2021 03:34:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============9044457457157163021==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210815075100.503033A0B88@ietfa.amsl.com> Date: Sun, 15 Aug 2021 00:51:00 -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, 15 Aug 2021 07:51:06 -0000 --===============9044457457157163021== 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/-0/=F0=9F=92=AC5) 2 issues created: - Generic HTTP access control (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/303=20 - Use opaque identifer instead of user handle (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/302=20 3 issues received 5 new comments: - #303 Generic HTTP access control (2 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/303=20 - #301 Trust relationships for a model using TLS and no client instance k= eys (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/301=20 - #288 Since both rights and resource locations must be disclosed to the = AS, the AS can act as Big Brother (2 by Denisthemalice, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/288=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============9044457457157163021== 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 August 15, 2021

Events without label "editorial"

Issues

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

2 issues created:

3 issues received 5 new comments:

Repositories tracked by this digest:

--===============9044457457157163021==-- From nobody Sun Aug 15 02:38:26 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 436293A09AD; Sun, 15 Aug 2021 02:38:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: gnap-chairs@ietf.org, rdd@cert.org, txauth@ietf.org, yaronf.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162902030325.19973.8272233571754150491@ietfa.amsl.com> Date: Sun, 15 Aug 2021 02:38:23 -0700 Archived-At: Subject: [GNAP] gnap - New Meeting Session Request for IETF 112 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: Sun, 15 Aug 2021 09:38:24 -0000 A new meeting session request has just been submitted by Yaron Sheffer, a Chair of the gnap working group. --------------------------------------------------------- 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: Yaron Sheffer Roman Danyliw Leif Johansson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Aug 19 10:24:31 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 AE4953A0890 for ; Thu, 19 Aug 2021 10:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ITkejrRaZM69 for ; Thu, 19 Aug 2021 10:24:24 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E3A3A088F for ; Thu, 19 Aug 2021 10:24:23 -0700 (PDT) Received: from [192.168.1.11] ([90.26.88.110]) by mwinf5d06 with ME id jVQK2500D2Nqh1E03VQLKz; Thu, 19 Aug 2021 19:24:20 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 19 Aug 2021 19:24:20 +0200 X-ME-IP: 90.26.88.110 From: Denis To: "txauth@ietf.org" Message-ID: Date: Thu, 19 Aug 2021 19:24:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------38542D0ECE02F0A84E7ACF46" Content-Language: en-GB Archived-At: Subject: [GNAP] New I-D: draft-pinkas-gnap-core-protocol 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: Thu, 19 Aug 2021 17:24:29 -0000 This is a multi-part message in MIME format. --------------38542D0ECE02F0A84E7ACF46 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yaron (the chair of the GNAP WG) and myself have had a video conference call last week. At the end of this call, Yaron asked me if I could write an I-D that would summarize the main concepts on how to support an Attribute Based Access Control (ABAC) mechanism. I have accepted. Since during that call, I mentioned that the current description of the protocol was both insecure and not interoperable, I indicated that I will provide a draft describing the main concepts on how to support both an Attribute Based Access Control (ABAC) mechanism as well as a Capability Based Access Control (CBAC) mechanism, both in a secure and in an interoperable way. The draft re-uses many portions of text that I have provided in the issues that I have posted on Github. In order to understand the motivations of the proposal, here after is a quick analysis of draft-ietf-gnap-core-protocol-06. The charter of the GNAP WG states, close to its end :            "The initial work will focus on using HTTPS for communication between the client and the authorization server, (...)"            See: https://datatracker.ietf.org/doc/charter-ietf-gnap/ Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06 does not comply with the GNAP charter. Instead, draft-ietf-gnap-core-protocol-06 makes use of "client instance keys" between the client and the AS and is mute about the relationships between a "client instance key" and an end-user. From oral explanations recently obtained from one of the co-editors, a "client instance key" is a key attached to a device owned by an end-user. How the identity or an identifier of the end-user relates to a device is left undefined. If an end-user has four devices (e.g. a laptop, a desktop, a smart phone and a tablet), he will need to register with the AS each of these four devices. This is done using "out-of-bands" means. If he looses one of these four devices, he will need to revoke the client instance key associated with that device and then, if he has not taken one of the three of other devices with him, he will need to register a new device (i.e. a new client instance key). Here again, this is done using "out-of-bands" means. All that information is not present in draft-ietf-gnap-core-protocol-06 and has only be inferred from the oral explanations provided by one of the co-editors. Furthermore, the client indicates (i.e. claims) to the AS the identity/identifier of the end-user. However, since the AS has no way to know whether the client software can be trusted, the AS cannot rely on that claimed information. This means that the client/AS protocol, as currently described, is insecure. In draft-ietf-gnap-core-protocol-06, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it possesses, or both an access token and key proof together. Such a protection is illusory, since a collaborative client is able to perform all the cryptographic computations that another collaborative client needs to claim to be the "owner" of the access token. With the use of an Hardware Security Module (HSM), the same situation remains. This means that the client/RS protocol, as currently described, is insecure. Does the description that is present in draft-ietf-gnap-core-protocol-06 allows to demonstrate that the protocol is secure? Unfortunately, the response to this question is negative, since the "Security Considerations section" is nearly empty. Does the description that is present in draft-ietf-gnap-core-protocol-06 allows to interoperate ? Unfortunately, the response to this questions is also negative, since the structure of the access tokens is left undefined. In particular, the verifications that a RS *SHALL* perform on the content of an access token to make sure that it is valid are left undefined. Currently, GNAP is a framework, like OAuth 2.0 (RFC 6749) and OAuth 2.1 (draft-ietf-oauth-v2-1-01), and is not an interoperable protocol. At the moment, draft-ietf-gnap-core-protocol-06 only supports "rights". In the security literature, this is a Capability based access control (CBAC) scheme. Since a privilege is currently described as being a right and/or an attribute, an Attribute based access control (ABAC) scheme should also be supported. This is not the case at the moment. I have successfully submitted and posted to the IETF repository an Individual Submission of an I-D.    Name:        draft-pinkas-gnap-core-protocol    Revision:    00    Title:           Grant Negotiation and Authorization Protocol    Document date:    2021-08-19    Group:         Individual Submission    Pages:         33    URL: https://www.ietf.org/archive/id/draft-pinkas-gnap-core-protocol-00.txt    Status: https://datatracker.ietf.org/doc/draft-pinkas-gnap-core-protocol/    Htmlized: https://datatracker.ietf.org/doc/html/draft-pinkas-gnap-core-protocol *Abstract:*       This protocol enables an Authorization Server (AS) to issue access  tokens to permit an end-user using a client software to perform       operations on a protected resource hosted by a Resource Server (RS).  These access tokens allow to support capabilities and/or user       attributes.       The protocol includes means of specifying how the end-user can  potentially be involved in an interactive fashion during the       process.  The client and/or the RS will use these interaction mechanisms to involve the end-user, as necessary, to take decisions.       The protocol uses HTTPS for all communications between the client and the AS, as well as between the client and the RS. Being a version -00, this 33 pages document explains the main concepts but does not provide the details of the protocols. The document includes a Trust Relationships section (1.5) and both a Security Considerations section (4) and a Privacy Considerations section (5). The flow of operations for an access to a protected resource is illustrated in Figure 2, on page 26. The creation of RS user accounts is not illustrated on this figure but is explained in the text before. Denis --------------38542D0ECE02F0A84E7ACF46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Yaron (the chair of the GNAP WG) and myself have had a video conference call last week. At the end of this call, Yaron asked me if I could write
an I-D that would summarize the main concepts on how to support an Attribute Based Access Control (ABAC) mechanism. I have accepted.

Since during that call, I mentioned that the current description of the protocol was both insecure and not interoperable, I indicated
that I will provide a draft describing the main concepts on how to support both an Attribute Based Access Control (ABAC) mechanism
as well as a Capability Based Access Control (CBAC) mechanism, both in a secure and in an interoperable way.

The draft re-uses many portions of text that I have provided in the issues that I have posted on Github.

In order to understand the motivations of the proposal, here after is a quick analysis of draft-ietf-gnap-core-protocol-06.

The charter of the GNAP WG states, close to its end :

           "The initial work will focus on using HTTPS for communication between the client and the authorization server, (...)"

           See: https://datatracker.ietf.org/doc/charter-ietf-gnap/

Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server
and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
does not comply with the GNAP charter.

Instead, draft-ietf-gnap-core-protocol-06 makes use of "client instance keys" between the client and the AS and is mute about the relationships
between a "client instance key" and an end-user. From oral explanations recently obtained from one of the co-editors, a "client instance key" is a key attached
to a device owned by an end-user. How the identity or an identifier of the end-user relates to a device is left undefined. If an end-user has four devices
(e.g. a laptop, a desktop, a smart phone and a tablet), he will need to register with the AS each of these four devices. This is done using "out-of-bands" means.
If he looses one of these four devices, he will need to revoke the client instance key associated with that device and then, if he has not taken one of the three
of other devices with him, he will need to register a new device (i.e. a new client instance key). Here again, this is done using "out-of-bands" means.
All that information is not present in draft-ietf-gnap-core-protocol-06 and has only be inferred from the oral explanations provided by one of the co-editors.

Furthermore, the client indicates (i.e. claims) to the AS the identity/identifier of the end-user. However, since the AS has no way to know whether the client
software can be trusted, the AS cannot rely on that claimed information. This means that the client/AS protocol, as currently described, is insecure.

In draft-ietf-gnap-core-protocol-06, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it possesses,
or both an access token and key proof together. Such a protection is illusory, since a collaborative client is able to perform all the cryptographic computations that
another collaborative client needs to claim to be the "owner" of the access token. With the use of an Hardware Security Module (HSM), the same situation remains.
This means that the client/RS protocol, as currently described, is insecure.

Does the description that is present in draft-ietf-gnap-core-protocol-06 allows to demonstrate that the protocol is secure? Unfortunately, the response to this question
is negative, since the "Security Considerations section" is nearly empty.

Does the description that is present in draft-ietf-gnap-core-protocol-06 allows to interoperate ? Unfortunately, the response to this questions is also negative,
since the structure of the access tokens is left undefined. In particular, the verifications that a RS SHALL perform on the content of an access token to make sure
that it is valid are left undefined. Currently, GNAP is a framework, like OAuth 2.0 (RFC 6749) and OAuth 2.1 (draft-ietf-oauth-v2-1-01), and is not an interoperable protocol.

At the moment, draft-ietf-gnap-core-protocol-06 only supports "rights". In the security literature, this is a Capability based access control (CBAC) scheme.
Since a privilege is currently described as being a right and/or an attribute, an Attribute based access control (ABAC) scheme should also be supported.
This is not the case at the moment.

I have successfully submitted and posted to the IETF repository an Individual Submission of an I-D.

   Name:        draft-pinkas-gnap-core-protocol
   Revision:    00
   Title:           Grant Negotiation and Authorization Protocol
   Document date:    2021-08-19
   Group:         Individual Submission
   Pages:         33
   URL:             https://www.ietf.org/archive/id/draft-pinkas-gnap-core-protocol-00.txt
   Status:         https://datatracker.ietf.org/doc/draft-pinkas-gnap-core-protocol/
   Htmlized:    https://datatracker.ietf.org/doc/html/draft-pinkas-gnap-core-protocol

   Abstract:

      This protocol enables an Authorization Server (AS) to issue access  tokens to permit an end-user using a client software to perform
      operations on a protected resource hosted by a Resource Server (RS).  These access tokens allow to support capabilities and/or user
      attributes.

      The protocol includes means of specifying how the end-user can  potentially be involved in an interactive fashion during the
      process.  The client and/or the RS will use these interaction mechanisms to involve the end-user, as necessary, to take decisions.

      The protocol uses HTTPS for all communications between the client and the AS, as well as between the client and the RS.


Being a version -00, this 33 pages document explains the main concepts but does not provide the details of the protocols. The document includes
a Trust Relationships section (1.5) and both a Security Considerations section (4) and a Privacy Considerations section (5).

The flow of operations for an access to a protected resource is illustrated in Figure 2, on page 26. The creation of RS user accounts is not illustrated
on this figure but is explained in the text before.

Denis


--------------38542D0ECE02F0A84E7ACF46-- From nobody Thu Aug 19 11:03:57 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 4F22E3A1261 for ; Thu, 19 Aug 2021 11:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, 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 cW7NixvY5miO for ; Thu, 19 Aug 2021 11:03: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 63C093A125F for ; Thu, 19 Aug 2021 11:03:51 -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 17JI3ksj010413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 14:03:46 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_01ECEFAF-4291-4BBB-8B5D-9841E5C72674" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 19 Aug 2021 14:03:45 -0400 In-Reply-To: Cc: "txauth@ietf.org" To: Denis References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [GNAP] New I-D: draft-pinkas-gnap-core-protocol 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: Thu, 19 Aug 2021 18:03:57 -0000 --Apple-Mail=_01ECEFAF-4291-4BBB-8B5D-9841E5C72674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I want to clarify one point of confusion here: > The charter of the GNAP WG states, close to its end : >=20 > "The initial work will focus on using HTTPS for = communication between the client and the authorization server, (...)" >=20 > See: https://datatracker.ietf.org/doc/charter-ietf-gnap/ = >=20 > Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the = use of HTTPS for communication between the client and the authorization = server=20 > and does not take advantage of the security properties obtained thanks = to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06=20 > does not comply with the GNAP charter. >=20 This was quoted out of context and misrepresents the goal. If you read = the rest of that sentence, you=E2=80=99ll see that it=E2=80=99s talking = about HTTP versions: The initial work will focus on using HTTPS for communication between the = client and the authorization server, taking advantage of optimization features = of HTTP/2 and HTTP/3 where possible, and will strive to enable simple = mapping to other protocols such as CoAP when doing so does not conflict with the = primary focus. What this is saying is that we shouldn=E2=80=99t make something that is = only deployable on HTTP/1. Additionally, the GNAP core draft does already require HTTPS. While the = security considerations section (section 12) is not yet filled out = (though note =E2=80=94 this one of the topics the editors are actively = working on), the one item it does have in there mandates HTTPS: All requests have to be over TLS or equivalent as per [BCP195 = ]. Therefore, the statement as asserted in this email, and the conclusions = that follow it, are not accurate. =E2=80=94 Justin= --Apple-Mail=_01ECEFAF-4291-4BBB-8B5D-9841E5C72674 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = want to clarify one point of confusion here:

The = charter of the GNAP WG states, close to its end :


           "The initial work = will focus on using HTTPS for communication between the client and the authorization server, (...)"

           See: = https://datat= racker.ietf.org/doc/charter-ietf-gnap/

Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server
and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
does not comply with the GNAP charter.

This was quoted out of context = and misrepresents the goal. If you read the rest of that sentence, = you=E2=80=99ll see that it=E2=80=99s talking about HTTP = versions:

The=
 initial work will focus on using HTTPS for communication between the =
client
and the authorization server, taking advantage of optimization features =
of
HTTP/2 and HTTP/3 where possible, and will strive to enable simple =
mapping to
other protocols such as CoAP when doing so does not conflict with the =
primary
focus.
What this is saying is that we = shouldn=E2=80=99t make something that is only deployable on HTTP/1.

Additionally, the GNAP = core draft does already require HTTPS. While the security considerations = section (section 12) is not yet filled out (though note =E2=80=94 this = one of the topics the editors are actively working on), the one item it = does have in there mandates HTTPS:

All requests have to be over TLS = or equivalent as per [BCP195].


Therefore, the statement = as asserted in this email, and the conclusions that follow it, are not = accurate.

 =E2=80=94 Justin
= --Apple-Mail=_01ECEFAF-4291-4BBB-8B5D-9841E5C72674-- From nobody Fri Aug 20 01:09:29 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 7864B3A12BC for ; Fri, 20 Aug 2021 01:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 2RgOCgeH6pUQ for ; Fri, 20 Aug 2021 01:09:22 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBDE3A12BA for ; Fri, 20 Aug 2021 01:09:22 -0700 (PDT) Received: from [192.168.1.11] ([90.26.88.110]) by mwinf5d87 with ME id jk9K250072Nqh1E03k9KlP; Fri, 20 Aug 2021 10:09:20 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 20 Aug 2021 10:09:20 +0200 X-ME-IP: 90.26.88.110 To: Justin Richer Cc: "txauth@ietf.org" References: From: Denis Message-ID: Date: Fri, 20 Aug 2021 10:09:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FF66F3282214D15841042375" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] New I-D: draft-pinkas-gnap-core-protocol 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, 20 Aug 2021 08:09:28 -0000 This is a multi-part message in MIME format. --------------FF66F3282214D15841042375 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, There is a difference between the following two sentences :         All *requests *have to be over TLS or equivalent as per [BCP195 ].        (from : draft-ietf-gnap-core-protocol-06 on *page 105*) Which "requests" ? Access token requests ? Requests from which entity to which other entity ? and       The protocol uses HTTPS for all *communications *between the client and the AS, as well as between the client and the RS.       (from: draft-pinkas-gnap-core-protocol-00 on *page 1*). IMO, the first one is ambiguous  while the second one is crystal clear. As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is taking advantage of the security properties obtained thanks to the use of HTTPS. Nevertheless, there are many other major issues raised about draft-ietf-gnap-core-protocol-06, that draft-pinkas-gnap-core-protocol-00 attempts to address and to solve. The very first version of draft-pinkas-gnap-core-protocol has been written from scratch with a Trust Relationships section (1.5) and both a Security Considerations section (4) and a Privacy Considerations section (5). Writing these three sections in a very first version is a good way to have a document understandable and coherent. Denis > I want to clarify one point of confusion here: > >> The charter of the GNAP WG states, close to its end : >> >> >>            "The initial work will focus on using HTTPS for >> communication between the client and the authorization server, (...)" >> >>            See: https://datatracker.ietf.org/doc/charter-ietf-gnap/ >> >> Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the >> use of HTTPS for communication between the client and the >> authorization server >> and does not take advantage of the security properties obtained >> thanks to the use of HTTPS. This means that >> draft-ietf-gnap-core-protocol-06 >> does not comply with the GNAP charter. >> > This was quoted out of context and misrepresents the goal. If you read > the rest of that sentence, you’ll see that it’s talking about HTTP > versions: > > The initial work will focus on using HTTPS for communication between the client > and the authorization server, taking advantage of optimization features of > HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to > other protocols such as CoAP when doing so does not conflict with the primary > focus. > > What this is saying is that we shouldn’t make something that is only > deployable on HTTP/1. > > Additionally, the GNAP core draft does already require HTTPS. While > the security considerations section (section 12) is not yet filled out > (though note — this one of the topics the editors are actively working > on), the one item it does have in there mandates HTTPS: > > All requests have to be over TLS or equivalent as per [BCP195 > ]. > > > Therefore, the statement as asserted in this email, and the > conclusions that follow it, are not accurate. > >  — Justin --------------FF66F3282214D15841042375 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Justin,

There is a difference between the following two sentences :

        All requests have to be over TLS or equivalent as per [BCP195].
       (from : draft-ietf-gnap-core-protocol-06 on page 105)

Which "requests" ? Access token requests ? Requests from which entity to which other entity ?

and

      The protocol uses HTTPS for all communications between the client and the AS, as well as between the client and the RS.
      (from: draft-pinkas-gnap-core-protocol-00 on page 1).


IMO, the first one is ambiguous  while the second one is crystal clear.

As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is taking advantage of the security properties obtained thanks to the use of HTTPS.

Nevertheless, there are many other major issues raised about draft-ietf-gnap-core-protocol-06, that draft-pinkas-gnap-core-protocol-00 attempts
to address and to solve.

The very first version of draft-pinkas-gnap-core-protocol has been written from scratch with a Trust Relationships section (1.5) and both
a Security Considerations section (4) and a Privacy Considerations section (5). Writing these three sections in a very first version is a
good way to have a document understandable and coherent. 

Denis

I want to clarify one point of confusion here:

The charter of the GNAP WG states, close to its end :


           "The initial work will focus on using HTTPS for communication between the client and the authorization server, (...)"

           See: https://datatracker.ietf.org/doc/charter-ietf-gnap/

Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server
and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
does not comply with the GNAP charter.

This was quoted out of context and misrepresents the goal. If you read the rest of that sentence, you’ll see that it’s talking about HTTP versions:

The initial work will focus on using HTTPS for communication between the client
and the authorization server, taking advantage of optimization features of
HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to
other protocols such as CoAP when doing so does not conflict with the primary
focus.
What this is saying is that we shouldn’t make something that is only deployable on HTTP/1.

Additionally, the GNAP core draft does already require HTTPS. While the security considerations section (section 12) is not yet filled out (though note — this one of the topics the editors are actively working on), the one item it does have in there mandates HTTPS:

All requests have to be over TLS or equivalent as per [BCP195].


Therefore, the statement as asserted in this email, and the conclusions that follow it, are not accurate.

 — Justin


--------------FF66F3282214D15841042375-- From nobody Fri Aug 20 03:48:45 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 16D6D3A20DD for ; Fri, 20 Aug 2021 03:48:44 -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 h0CB1BKfk3-M for ; Fri, 20 Aug 2021 03:48:39 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 00AEC3A20D9 for ; Fri, 20 Aug 2021 03:48:38 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id j18so9079532ile.8 for ; Fri, 20 Aug 2021 03:48:38 -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=kfMQUbLsYqS8/iZ4V59OgmKcjoQXFqdDcZqE2eY87iQ=; b=QOR4G+ZREg3zPvQZGKEquSVlPlo34mz3ZNdCWuj2kNHCY6LnhP+HCtCAlty6r6yVj4 Cd8r7YnAgfIfDn7h4JTRtpLiWoYwhnBg8DdwIeXgq/DaX1HZ/aebVcPCHWMpERa7tahm /VzL+tGS5n4/EO2vbQMYHlUlIpGTj71luzW2baslK/54eo+7x0AQl2qnGBIz7psiZPNB khxRGMeSts+RsvFfst+qqCUlmP1gdY/ea+utTWRByXNRXVTz3lD/qVKaFVkXsM56zFqM duK8clXpStIf4Hv03S/5/0VaNuNYwhUeqwlO6oiU1UrFPGW8I0V1Lb9i7R0XDvecLtRY ykPA== 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=kfMQUbLsYqS8/iZ4V59OgmKcjoQXFqdDcZqE2eY87iQ=; b=a/2dPrS7T4q9Ra+KgcaZvBM6RNw/qfbC/Y2zRVk0UNv0vUjcvUjhPCPW1d7qMWoiOu odo5BfaA16VEm+pp2uiGWX7HbekVGxgb9VDZxNhm8mRZa98sCrviqaHvZJHxDgv1boWk gum7aYb2v28m5AbxwIacxOIPq4saPdNoi53QMSHFWshgdabtN0yk4c6iSA1Fl2NIH6OK uQpWkssnH0BbUsWO7pxbkPiZ3dga62K4ICmXJrwqKuhob71vpr+TyJ+GluPNKp3ZOyNF 6gJ3NKKuNZaACLoRdV9qWTXgVX2QCrAOmaD5UeAyicjaJsx11iybY3nx1b6wzhmEkIfM cPfg== X-Gm-Message-State: AOAM530wM44HsxcBAt0hB0ceBCLGAtIfWjfp5KbnnAdWM61mGONpnIUH pEBnthvzWvtMCg4y8SvnwcpW9kv8Jj+MO7yvO/g= X-Google-Smtp-Source: ABdhPJzFe0C0Ypwq1D0Taj2Y2qFOis6cwY5vXqWIhfp3xX8E90tBmXXc9CMXwvtd15/xjY9PieJVXRxH/Iv6ZF+uE0c= X-Received: by 2002:a92:7d07:: with SMTP id y7mr13379546ilc.68.1629456517532; Fri, 20 Aug 2021 03:48:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Fri, 20 Aug 2021 12:48:25 +0200 Message-ID: To: Denis Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e7922205c9fb6896" Archived-At: Subject: Re: [GNAP] New I-D: draft-pinkas-gnap-core-protocol 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, 20 Aug 2021 10:48:44 -0000 --000000000000e7922205c9fb6896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I don't understand why you believe the wording in the draft is unclear, but if so a PR is always welcome. There's no ambiguity as to whether HTTPS is what we ask for. The editors always said there would be sections dedicated to trust / privacy / security. It should land into the github repository soon, but the underlying assumptions are different. As for the rest of your draft, there are interesting ideas, but seems to me that some are either case specific or out of scope of our charter. Cheers Fabien Le ven. 20 ao=C3=BBt 2021 =C3=A0 10:09, Denis a =C3=A9= crit : > Hi Justin, > > There is a difference between the following two sentences : > > All *requests *have to be over TLS or equivalent as per [BCP195 > ]. > > (from : draft-ietf-gnap-core-protocol-06 on *page 105*) > > Which "requests" ? Access token requests ? Requests from which entity to > which other entity ? > > and > > The protocol uses HTTPS for all *communications *between the client > and the AS, as well as between the client and the RS. > (from: draft-pinkas-gnap-core-protocol-00 on *page 1*). > > > IMO, the first one is ambiguous while the second one is crystal clear. > > As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is > taking advantage of the security properties obtained thanks to the use of > HTTPS. > > Nevertheless, there are many other major issues raised about > draft-ietf-gnap-core-protocol-06, that draft-pinkas-gnap-core-protocol-00 > attempts > to address and to solve. > > The very first version of draft-pinkas-gnap-core-protocol has been writte= n > from scratch with a Trust Relationships section (1.5) and both > a Security Considerations section (4) and a Privacy Considerations sectio= n > (5). Writing these three sections in a very first version is a > good way to have a document understandable and coherent. > > Denis > > I want to clarify one point of confusion here: > > The charter of the GNAP WG states, close to its end : > > > "The initial work will focus on using HTTPS for communication > between the client and the authorization server, (...)" > > See: https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the use > of HTTPS for communication between the client and the authorization serve= r > and does not take advantage of the security properties obtained thanks to > the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06 > does not comply with the GNAP charter. > > This was quoted out of context and misrepresents the goal. If you read th= e > rest of that sentence, you=E2=80=99ll see that it=E2=80=99s talking about= HTTP versions: > > The initial work will focus on using HTTPS for communication between the = client > and the authorization server, taking advantage of optimization features o= f > HTTP/2 and HTTP/3 where possible, and will strive to enable simple mappin= g to > other protocols such as CoAP when doing so does not conflict with the pri= mary > focus. > > What this is saying is that we shouldn=E2=80=99t make something that is o= nly > deployable on HTTP/1. > > Additionally, the GNAP core draft does already require HTTPS. While the > security considerations section (section 12) is not yet filled out (thoug= h > note =E2=80=94 this one of the topics the editors are actively working on= ), the one > item it does have in there mandates HTTPS: > > All requests have to be over TLS or equivalent as per [BCP195 > > ]. > > > Therefore, the statement as asserted in this email, and the conclusions > that follow it, are not accurate. > > =E2=80=94 Justin > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e7922205c9fb6896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,

I = don't understand why you believe the wording in the draft is unclear, b= ut if so a PR is always welcome. There's no ambiguity as to whether HTT= PS is what we ask for.

T= he editors always said there would be sections dedicated to trust / privacy= / security. It should land into the github repository soon, but the underl= ying assumptions are different.=C2=A0

As for the rest of your draft, there are interesting ideas, b= ut seems to me that some are either case specific or out of scope of our ch= arter.=C2=A0

Cheers
Fabien=C2=A0


Le ven. 20 ao=C3=BBt 2021 = =C3=A0 10:09, Denis <denis.ietf@fr= ee.fr> a =C3=A9crit=C2=A0:
=20 =20 =20
Hi Justin,

There is a difference between the following two sentences :

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 All requests have to be ov= er TLS or equivalent as per [BCP195].
=C2=A0=C2=A0 =C2=A0 =C2=A0 (from : draft-ietf-gnap-core-protocol-06 on page 105)

Which "requests" ? Access token requests ? Requests from which entity to which other entity ?

and

=C2=A0=C2=A0 =C2=A0=C2=A0 The protocol uses HTTPS for all communications between the client and the AS, as well as between the client and the RS.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (from: draft-pinkas-gnap-core-protoc= ol-00 on page 1).


IMO, the first one is ambiguous=C2=A0 while the second one is crystal clear.

As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is taking advantage of the security properties obtained thanks to the use of HTTPS.

Nevertheless, there are many other major issues raised about draft-ietf-gnap-core-protocol-06, that draft-pinkas-gnap-core-protocol-00 attempts
to address and to solve.

The very first version of draft-pinkas-gnap-core-protocol has been written from scratch with a Trust Relationships section (1.5) and both
a Security Considerations section (4) and a Privacy Considerations section (5). Writing these three sections in a very first version is a
good way to have a document understandable and coherent.=C2=A0

Denis

=20 I want to clarify one point of confusion here:

The charter of the GNAP WG states, close to its end :


=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "The ini= tial work will focus on using HTTPS for communication between the client and the authorization server, (...)"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 See: https://datatrac= ker.ietf.org/doc/charter-ietf-gnap/

Unfortunately, draft-ietf-gnap-core= -protocol-06 does not mandate the use of HTTPS for communication between the client and the authorization server
and does not take advantage of the security properties obtained thanks to the use of HTTPS. This means that draft-ietf-gnap-core-protocol-06
does not comply with the GNAP charter.

This was quoted out of context and misrepresents the goal. If you read the rest of that sentence, you=E2=80=99ll see that it=E2= =80=99s talking about HTTP versions:

The initial work will focus on using HTTPS for communication=
 between the client
and the authorization server, taking advantage of optimization features of
HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping =
to
other protocols such as CoAP when doing so does not conflict with the prima=
ry
focus.
What this is saying is that we shouldn=E2=80=99t make something that = is only deployable on HTTP/1.

Additionally, the GNAP core draft does already require HTTPS. While the security considerations section (section 12) is not yet filled out (though note =E2=80=94 this one = of the topics the editors are actively working on), the one item it does have in there mandates HTTPS:

All requests have to be over TLS or equivalent as per [BCP195].


Therefore, the statement as asserted in this email, and the conclusions that follow it, are not accurate.

=C2=A0=E2=80=94 Justin


--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000e7922205c9fb6896--