From nobody Tue Nov 1 15:43:03 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E8E129524; Tue, 1 Nov 2016 15:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147804017603.23868.11810909537625998494.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 15:42:56 -0700 Archived-At: Cc: draft-ietf-p2psip-share@ietf.org, marc@petit-huguenin.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:42:58 -0000 Ben Campbell has entered the following ballot position for draft-ietf-p2psip-share-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a one set of substantive comments/questions, and some editorial comments: Substantive: - I'm confused about the validation procedure. In step one, is this the user name of the user attempting to write the resource? In step 5, I do not understand how this terminates. Which ACL item is the "previously selected" one. If that refers to the one selected in the last iteration of steps 3 and 4, how do you know there are not more ACL items to iterate through? Editorial: -1, first paragraph, first sentence: s/that/, which -- recurring singular plural mismatch "resources with a variable name". -1, 2nd paragraphs: "It transfers the authorization..." What is the antecedent for "it"? -3. First paragraph after numbered list, "user called Authorized Peer": missing article. -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user actually required to access the array in the first place? - 6.5, first paragraph: Does the MAY grant permission, or is it a statement of fact? -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other (perhaps application specific) reasons one might choose not to write the value? -- 2nd paragraph from end: The MUST seems more like a statement of fact. (E.g. "The resulting ... integer is used...") - 4.1, last paragraph: s/implementations/implementors - 4.2, definition of res_name_ext: The sentence starting with "This name serves..." is hard to parse. -5.1, 4th paragraph (paragraph after example) : s/witch/which From nobody Thu Nov 3 05:02:59 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E628129441; Thu, 3 Nov 2016 05:02:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147817457640.22879.8132643683843846216.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2016 05:02:56 -0700 Archived-At: Cc: draft-ietf-p2psip-share@ietf.org, marc@petit-huguenin.org, rick.casarez@gmail.com, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Benoit Claise's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:02:56 -0000 Benoit Claise has entered the following ballot position for draft-ietf-p2psip-share-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Below is Rick Casarez's OPS DIR review: Section 6.5: "Since stored values could have been modified or invalidated prior to their expiration, an accessing peer SHOULD use a Stat request to check for updates prior to using the data cache" When considering security, and how this works, I would recommend changing this to MUST or advising that the lifetime be set very low. A stale ACL could allow access were none should occur. From nobody Thu Nov 3 05:43:25 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5A212946B; Thu, 3 Nov 2016 05:43:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147817700401.22834.5697062636233393394.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2016 05:43:24 -0700 Archived-At: Cc: draft-ietf-p2psip-share@ietf.org, marc@petit-huguenin.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:43:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-p2psip-share-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: this feels more like an experimental spec. If the authors didn't object I think that'd be more appropriate. - General: can these ACLs be resources to which access is controlled via another of these ACLs? If so, then it seems like there may be some nasty corner-cases where things get lost (so nobody can change 'em in future) and I don't see how one might recover from that. (Apologies if I'm just mixed up here, I read this fairly quickly and didn't reload RELOAD into my little head first;-) - 3.1: 24 bits of collision resistance isn't many. I'm not clear why that's ok - 3.1, last para: SHA-1 isn't a good example really, SHA-256 would be better today. - 5.3: Is the mapping to USER and DOMAIN from certificates well-defined? It may be in RELOAD, I forget, sorry;-) It doesn't seem to be well-defined here anyway. From nobody Thu Nov 3 08:13:28 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6559C129A8C; Thu, 3 Nov 2016 08:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 7Qef_Laq2oDa; Thu, 3 Nov 2016 08:13:08 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87577129A94; Thu, 3 Nov 2016 08:12:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,587,1473112800"; d="scan'208";a="44275856" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 16:12:54 +0100 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 16:12:53 +0100 Received: from [10.134.254.178] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 16:12:53 +0100 To: Benoit Claise , The IESG References: <24cadf5b9faa4e308b95c0313ad36d93@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <624e2178-de09-c640-19c3-754ed803507e@haw-hamburg.de> Date: Thu, 3 Nov 2016 16:12:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <24cadf5b9faa4e308b95c0313ad36d93@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , "rick.casarez@gmail.com" , "p2psip@ietf.org" , "p2psip-chairs@ietf.org" Subject: Re: [P2PSIP] Benoit Claise's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:13:15 -0000 Benoit, I assume your comment resolves after answering Rick. Thanks, Thomas On 03.11.2016 13:02, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-p2psip-share-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Below is Rick Casarez's OPS DIR review: > > Section 6.5: > "Since stored values could have been modified or invalidated prior to > their expiration, an accessing peer SHOULD use a Stat request to check > for updates prior to using the data cache" > > When considering security, and how this works, I would recommend changing > this to MUST or advising that the lifetime be set very low. A stale ACL > could allow access were none should occur. > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Nov 3 08:47:23 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E3E129A88; Thu, 3 Nov 2016 08:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 lsHBIpdWA1hG; Thu, 3 Nov 2016 08:47:12 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CCE1296A4; Thu, 3 Nov 2016 08:47:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,587,1473112800"; d="scan'208";a="30000631" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 16:47:08 +0100 Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 16:47:08 +0100 Received: from [10.134.254.178] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 16:47:03 +0100 To: Ben Campbell , The IESG References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> Date: Thu, 3 Nov 2016 16:45:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , "p2psip@ietf.org" , "p2psip-chairs@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:47:15 -0000 Hi Ben, thanks for your comments. Please see inline. On 01.11.2016 23:42, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-p2psip-share-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a one set of substantive comments/questions, and some editorial > comments: > > Substantive: > > - I'm confused about the validation procedure. In step one, is this the > user name of the user attempting to write the resource? In step 5, I do > not understand how this terminates. Which ACL item is the "previously > selected" one. If that refers to the one selected in the last iteration > of steps 3 and 4, how do you know there are not more ACL items to iterate > through? > You are referring to 6.3 "validating writ access"? In this case, you receive a store request along with a certificate. In step 1, you resolve the user name of the requester, i.e., the user name that corresponds to the certificate in the request. ... then you identify the user in the ACL and walk up the delegation chain. In step 5, you have arrived at the root of the delegation tree. This is the case, when the to_user equals the signer equals the owner of the resources (see see Figure 1). This is also how it terminates - the owner of the resource is the root of the trust chain. > > Editorial: > > -1, first paragraph, first sentence: s/that/, which > -- recurring singular plural mismatch "resources with a variable name". > Thanks, fixed. > -1, 2nd paragraphs: "It transfers the authorization..." > What is the antecedent for "it"? > We meant the "trust delegation mechanism" - but it's ambiguous, you're right. Changed to "...based on a trust delegation mechanism that transfers the authorization .." > -3. First paragraph after numbered list, "user called Authorized Peer": > missing article. > Thanks, fixed. > -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user > actually required to access the array in the first place? > It says "If the data model of the Shared Resource is an array, each Authorized..". So the user is not required to use an array for sharing, but if an array is used, write conflicts MUST not be produced. > - 6.5, first paragraph: Does the MAY grant permission, or is it a > statement of fact? > Good point. The actual statement means that users are enabled to do so. So we replace the may by a "can". > -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other > (perhaps application specific) reasons one might choose not to write the > value? > I believe the MUST is correct: we're in a section that describes the behavior of the storing peer. When receiving a store request, this peer should not behave according to its own application semantic, but to the common overlay rule. > -- 2nd paragraph from end: The MUST seems more like a statement of fact. > (E.g. "The resulting ... integer is used...") > Mhmm, I don't think so. These are all iterative decision steps: try (a), then write ... otherwise try (b), then write ... +++ ... otherwise refuse. > - 4.1, last paragraph: s/implementations/implementors > Thanks, fixed. > - 4.2, definition of res_name_ext: The sentence starting with "This name > serves..." is hard to parse. > O.K., changed to "This name is used by the storing peer for validating..." > -5.1, 4th paragraph (paragraph after example) : s/witch/which > Yep, this document was full of witches, but they have been banned now. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Nov 3 09:01:45 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33221129A7F; Thu, 3 Nov 2016 09:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 Zy1hb7nTO73B; Thu, 3 Nov 2016 09:01:33 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091C6129A3F; Thu, 3 Nov 2016 09:01:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,587,1473112800"; d="scan'208";a="30000760" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 17:01:30 +0100 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 17:01:30 +0100 Received: from [10.19.59.174] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 17:01:29 +0100 To: Stephen Farrell , The IESG References: From: "Thomas C. Schmidt" Message-ID: <6c639771-f141-489e-af64-18460c951708@haw-hamburg.de> Date: Thu, 3 Nov 2016 17:01:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , "p2psip@ietf.org" , "p2psip-chairs@ietf.org" Subject: Re: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:01:37 -0000 Hi, please see inline. On 03.11.2016 13:43, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-p2psip-share-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - General: this feels more like an experimental spec. If the > authors didn't object I think that'd be more appropriate. > Well authors hope(d) for this to serve as an enabling standard ... > - General: can these ACLs be resources to which access is > controlled via another of these ACLs? If so, then it seems like > there may be some nasty corner-cases where things get lost (so > nobody can change 'em in future) and I don't see how one might > recover from that. (Apologies if I'm just mixed up here, I read > this fairly quickly and didn't reload RELOAD into my little head > first;-) > No. The ACL is itself a shared resource owned by the initial creator that will have full rights as long as the resource (and the owner) exist. There is no way of disabling the owner. > - 3.1: 24 bits of collision resistance isn't many. I'm not clear > why that's ok > This actually is meant for small numbers and the storing peer protects against collisions (see SecDir review). > - 3.1, last para: SHA-1 isn't a good example really, SHA-256 > would be better today. > This is from Reload - we are not specifying overlay hash functions in this document. > - 5.3: Is the mapping to USER and DOMAIN from certificates > well-defined? It may be in RELOAD, I forget, sorry;-) It doesn't > seem to be well-defined here anyway. > Yes, certificate and usernames are held in correspondence by reload. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Nov 3 14:42:23 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26D1129AF2; Thu, 3 Nov 2016 14:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 eGD9PwOEsQFU; Thu, 3 Nov 2016 14:42:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EE38A129AD9; Thu, 3 Nov 2016 14:42:18 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA3LgC9F082039 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Nov 2016 16:42:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Thomas C. Schmidt" Date: Thu, 03 Nov 2016 16:42:12 -0500 Message-ID: In-Reply-To: <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 21:42:21 -0000 Hi, thanks for the response. Also see inline. I removed text that doesn't seem to need further discussion. Ben. On 3 Nov 2016, at 10:45, Thomas C. Schmidt wrote: > Hi Ben, > > thanks for your comments. Please see inline. > > On 01.11.2016 23:42, Ben Campbell wrote: [...] >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have a one set of substantive comments/questions, and some >> editorial >> comments: >> >> Substantive: >> >> - I'm confused about the validation procedure. In step one, is this >> the >> user name of the user attempting to write the resource? In step 5, I >> do >> not understand how this terminates. Which ACL item is the "previously >> selected" one. If that refers to the one selected in the last >> iteration >> of steps 3 and 4, how do you know there are not more ACL items to >> iterate >> through? >> > > You are referring to 6.3 "validating writ access"? > > In this case, you receive a store request along with a certificate. In > step 1, you resolve the user name of the requester, i.e., the user > name that corresponds to the certificate in the request. Adding something to the effect of "This is the user requesting the write operation" would be helpful. > > ... then you identify the user in the ACL and walk up the delegation > chain. > > In step 5, you have arrived at the root of the delegation tree. This > is the case, when the to_user equals the signer equals the owner of > the resources (see see Figure 1). This is also how it terminates - the > owner of the resource is the root of the trust chain. I'm probably being dense here, but my confusion is in the phrasing of "the "to_user" value user name of the signer of the previously selected ACL item". Won't that always be true for every ACL item up the chain after the first? As an example, Lets say I have a delegation chain of A,B,C,D, where A is the owner. Would the ACL chain look like the following (in leave-to-root order )? signer to_user 1 C D 2 B C 3 A B 4 A A If so, then ACL 2 seems to have a to_user that matches the signer of ACL 1 (the previously selected ACL), which seems to terminate early. Again, I'm sure I'm missing something. [...] > >> -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user >> actually required to access the array in the first place? >> > > It says "If the data model of the Shared Resource is an array, each > Authorized..". > > So the user is not required to use an array for sharing, but if an > array is used, write conflicts MUST not be produced. This is pedantic, but my issue is that the SHALL does not leave the authorized peer the opportunity to choose not to write anything at all. Being granted permission to write does not imply a decision to write. Perhaps something like "...each Authorized Peer that chooses to write data SHALL..." > >> -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not >> other >> (perhaps application specific) reasons one might choose not to write >> the >> value? >> > > I believe the MUST is correct: we're in a section that describes the > behavior of the storing peer. When receiving a store request, this > peer should not behave according to its own application semantic, but > to the common overlay rule. (pedantic again): So the storing peer couldn't have an application policy that, for example, chooses not to honor a write that violates some data validation rule? It seems to me that this section is saying that you MUST deny the request unless one of the listed is true, which is not the same as saying you MUST accept if one of the conditions is true. > >> -- 2nd paragraph from end: The MUST seems more like a statement of >> fact. >> (E.g. "The resulting ... integer is used...") >> > > Mhmm, I don't think so. These are all iterative decision steps: try > (a), then write ... otherwise try (b), then write ... +++ ... > otherwise refuse. That was a cut and paste error on my part--I meant the 2nd to last paragraph of 3.1. [...] From nobody Fri Nov 4 03:27:53 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A0A129BB1 for ; Fri, 4 Nov 2016 03:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 DEqQ6EhVL7gZ for ; Fri, 4 Nov 2016 03:27:44 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFC5129BC7 for ; Fri, 4 Nov 2016 03:27:44 -0700 (PDT) Received: (qmail 30318 invoked from network); 4 Nov 2016 11:20:59 +0100 Received: from p5dec2f5c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Nov 2016 11:20:58 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 4 Nov 2016 11:20:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BE2DB18-AE9E-4EE3-AD9C-D654C633AD8A@kuehlewind.net> References: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-share-09=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:27:46 -0000 Hi Thomas, this is not a discus and I=E2=80=99m fine your reply. Still a few more = comments: > Am 31.10.2016 um 15:37 schrieb Thomas C. Schmidt = : >=20 > Hi Mirja, >=20 > you are right in the sense that (a) if all previous evaluations have = been performed without a failure, and (b) if no revocation occurred (or = (c) a previous revocation has cleaned up all further delegation = entries), then the write procedure can rely on the single delegation = entry that matches the current user name of the writer. This comes down to me to only one =E2=80=9Aif=E2=80=98 and that is = actually point c. And I=E2=80=99d hope that c would always happen. >=20 > However, this includes several "ifs". For instance, if cleanup of the = delegation list has not been completed at the time of granting write = access, errors in the trust chain may occur. This could introduce = unwanted attack surface. Could you document this attack surface in the doc=E2=80=A6? >=20 > Our rationale behind designing this complete, self-contained procedure = was (a) writing an ACL list is not a frequent operation (so complexity = is not the major concern), and (b) keeping all operations simple, = robust, and of minimal dependence w.r.t. each other. Don=E2=80=99t you have to do the check every time you check write access = for a shared resource? That can be much more often. Mirja >=20 > That's why it's like that. >=20 > Cheers, > Thomas >=20 > On 31.10.2016 15:06, Mirja Kuehlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-p2psip-share-09: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Quick questions on sec 6.3. (Validating Write Access through an ACL): >> Do I really need to validate the authorization chain in the ACL every >> time I give access to a resource? Wouldn't I rather validate the ACL = when >> it's modified and then simply assume that it is sufficient that I = have an >> entry in the ACL to provide access? >>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences = Berliner Tor 7 =C2=B0 > =C2=B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =C2=B0 > =C2=B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =C2=B0 > =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =C2=B0 >=20 From nobody Fri Nov 4 11:35:52 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D51C129632; Fri, 4 Nov 2016 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 bQwkMBvbQnoJ; Fri, 4 Nov 2016 11:35:41 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C89129626; Fri, 4 Nov 2016 11:35:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,444,1473112800"; d="scan'208";a="44337578" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 19:35:38 +0100 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 19:35:38 +0100 Received: from [192.168.178.122] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 19:35:38 +0100 To: "Mirja Kuehlewind (IETF)" References: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de> <860461ddaa1b4cfe9506e9372a0145cc@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: Date: Fri, 4 Nov 2016 19:35:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <860461ddaa1b4cfe9506e9372a0145cc@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-share-09=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:35:44 -0000 Hi Mirja, On 04.11.2016 11:20, Mirja Kuehlewind (IETF) wrote: >> >> However, this includes several "ifs". For instance, if cleanup of the delegation list has not been completed at the time of granting write access, errors in the trust chain may occur. This could introduce unwanted attack surface. > > Could you document this attack surface in the doc…? > Mhmm, if complete validation is performed (as requested by the document), the attack surface is not there. As pointed out in 6.2, valid revocation is a single operation. Otherwise there would be probably a lengthy discussion on "how can I disturb a peer" (DoS, malicious requests, ...) We would rather be robust and skip this set of options ;) >> >> Our rationale behind designing this complete, self-contained procedure was (a) writing an ACL list is not a frequent operation (so complexity is not the major concern), and (b) keeping all operations simple, robust, and of minimal dependence w.r.t. each other. > > Don’t you have to do the check every time you check write access for a shared resource? That can be much more often. > As of Section 6.5, an accessing peer can cache (the list and the validation). So it can memorize previous checks and doesn't have to do them over an over again. However, initially and in the case of actual writing the shared resource, we want a full verification. Cheers, Thomas >> On 31.10.2016 15:06, Mirja Kuehlewind wrote: >>> Mirja Kühlewind has entered the following ballot position for >>> draft-ietf-p2psip-share-09: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Quick questions on sec 6.3. (Validating Write Access through an ACL): >>> Do I really need to validate the authorization chain in the ACL every >>> time I give access to a resource? Wouldn't I rather validate the ACL when >>> it's modified and then simply assume that it is sufficient that I have an >>> entry in the ACL to provide access? >>> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Fri Nov 4 11:47:57 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5B5129499 for ; Fri, 4 Nov 2016 11:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 S6rWa_skMR_x for ; Fri, 4 Nov 2016 11:47:46 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404CD129632 for ; Fri, 4 Nov 2016 11:47:46 -0700 (PDT) Received: (qmail 19865 invoked from network); 4 Nov 2016 19:47:42 +0100 Received: from p5dec2f5c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Nov 2016 19:47:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 4 Nov 2016 19:47:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de> <860461ddaa1b4cfe9506e9372a0145cc@HUB02.mailcluster.haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "p2psip@ietf.org" , "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-share-09=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:47:52 -0000 Hi, that means in the cached case where you know for sure there have been no = modification (because it a non-modifiable copy) you don=E2=80=99t do the = check, but only if you are basically not sure if there has been a = modification in the mean time. That makes more sense. Probably worth = stating this more explicitly in the doc. Mirja > Am 04.11.2016 um 19:35 schrieb Thomas C. Schmidt = : >=20 > Hi Mirja, >=20 > On 04.11.2016 11:20, Mirja Kuehlewind (IETF) wrote: >=20 >>>=20 >>> However, this includes several "ifs". For instance, if cleanup of = the delegation list has not been completed at the time of granting write = access, errors in the trust chain may occur. This could introduce = unwanted attack surface. >>=20 >> Could you document this attack surface in the doc=E2=80=A6? >>=20 >=20 > Mhmm, if complete validation is performed (as requested by the = document), the attack surface is not there. As pointed out in 6.2, valid = revocation is a single operation. Otherwise there would be probably a = lengthy discussion on "how can I disturb a peer" (DoS, malicious = requests, ...) >=20 > We would rather be robust and skip this set of options ;) >=20 >>>=20 >>> Our rationale behind designing this complete, self-contained = procedure was (a) writing an ACL list is not a frequent operation (so = complexity is not the major concern), and (b) keeping all operations = simple, robust, and of minimal dependence w.r.t. each other. >>=20 >> Don=E2=80=99t you have to do the check every time you check write = access for a shared resource? That can be much more often. >>=20 > As of Section 6.5, an accessing peer can cache (the list and the = validation). So it can memorize previous checks and doesn't have to do = them over an over again. However, initially and in the case of actual = writing the shared resource, we want a full verification. >=20 > Cheers, > Thomas >=20 >=20 >>> On 31.10.2016 15:06, Mirja Kuehlewind wrote: >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-p2psip-share-09: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Quick questions on sec 6.3. (Validating Write Access through an = ACL): >>>> Do I really need to validate the authorization chain in the ACL = every >>>> time I give access to a resource? Wouldn't I rather validate the = ACL when >>>> it's modified and then simply assume that it is sufficient that I = have an >>>> entry in the ACL to provide access? >>>>=20 >>>=20 >>> -- >>>=20 >>> Prof. Dr. Thomas C. Schmidt >>> =C2=B0 Hamburg University of Applied Sciences = Berliner Tor 7 =C2=B0 >>> =C2=B0 Dept. Informatik, Internet Technologies Group 20099 = Hamburg, Germany =C2=B0 >>> =C2=B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =C2=B0 >>> =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =C2=B0 >>>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences = Berliner Tor 7 =C2=B0 > =C2=B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =C2=B0 > =C2=B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =C2=B0 > =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =C2=B0 >=20 From nobody Fri Nov 4 14:30:26 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41861296E7; Fri, 4 Nov 2016 14:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 jJprGpocjgB3; Fri, 4 Nov 2016 14:30:21 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2231295C1; Fri, 4 Nov 2016 14:30:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,445,1473112800"; d="scan'208";a="44342270" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 22:30:09 +0100 Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 22:30:09 +0100 Received: from [192.168.178.122] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 22:30:08 +0100 To: Ben Campbell References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: Date: Fri, 4 Nov 2016 22:30:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:30:24 -0000 Hi Ben, please see inline. On 03.11.2016 22:42, Ben Campbell wrote: > >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I have a one set of substantive comments/questions, and some >>> editorial >>> comments: >>> >>> Substantive: >>> >>> - I'm confused about the validation procedure. In step one, is this >>> the >>> user name of the user attempting to write the resource? In step 5, I >>> do >>> not understand how this terminates. Which ACL item is the "previously >>> selected" one. If that refers to the one selected in the last >>> iteration >>> of steps 3 and 4, how do you know there are not more ACL items to >>> iterate >>> through? >>> >> >> You are referring to 6.3 "validating writ access"? >> >> In this case, you receive a store request along with a certificate. In >> step 1, you resolve the user name of the requester, i.e., the user >> name that corresponds to the certificate in the request. > > Adding something to the effect of "This is the user requesting the write > operation" would be helpful. > O.K., done. > >> >> ... then you identify the user in the ACL and walk up the delegation >> chain. >> >> In step 5, you have arrived at the root of the delegation tree. This >> is the case, when the to_user equals the signer equals the owner of >> the resources (see see Figure 1). This is also how it terminates - the >> owner of the resource is the root of the trust chain. > > I'm probably being dense here, but my confusion is in the phrasing of > "the "to_user" value user name of the signer of the previously selected > ACL item". Won't that always be true for every ACL item up the chain > after the first? > No, the selected ACL item from the previous step is the row you are in. It basically says that the "to_user" value equals the username of the signer. This is the "A A" case in row 4 in your example below. This row should be in an ACL only once and the user must be the owner of the resource, which is requested to be verified separately. > As an example, Lets say I have a delegation chain of A,B,C,D, where A is > the owner. Would the ACL chain look like the following (in leave-to-root > order )? > > signer to_user > 1 C D > 2 B C > 3 A B > 4 A A > > If so, then ACL 2 seems to have a to_user that matches the signer of ACL > 1 (the previously selected ACL), which seems to terminate early. > > Again, I'm sure I'm missing something. > I believe the confusion comes from the "previously" - this is meant to refer to the "previous step" and the actual row. We changed "previously" to "previous step" to avoid this confusion. > > [...] > >> >>> -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user >>> actually required to access the array in the first place? >>> >> >> It says "If the data model of the Shared Resource is an array, each >> Authorized..". >> >> So the user is not required to use an array for sharing, but if an >> array is used, write conflicts MUST not be produced. > > This is pedantic, but my issue is that the SHALL does not leave the > authorized peer the opportunity to choose not to write anything at all. > Being granted permission to write does not imply a decision to write. > Perhaps something like "...each Authorized Peer that chooses to write > data SHALL..." > O.K., done. >> >>> -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not >>> other >>> (perhaps application specific) reasons one might choose not to write >>> the >>> value? >>> >> >> I believe the MUST is correct: we're in a section that describes the >> behavior of the storing peer. When receiving a store request, this >> peer should not behave according to its own application semantic, but >> to the common overlay rule. > > (pedantic again): So the storing peer couldn't have an application > policy that, for example, chooses not to honor a write that violates > some data validation rule? It seems to me that this section is saying > that you MUST deny the request unless one of the listed is true, which > is not the same as saying you MUST accept if one of the conditions is > true. O.K., thanks: I got your point. Correspondingly, we reversed the order to a logical chain of denials. >> >>> -- 2nd paragraph from end: The MUST seems more like a statement of >>> fact. >>> (E.g. "The resulting ... integer is used...") >>> >> >> Mhmm, I don't think so. These are all iterative decision steps: try >> (a), then write ... otherwise try (b), then write ... +++ ... >> otherwise refuse. > > That was a cut and paste error on my part--I meant the 2nd to last > paragraph of 3.1. > ... still there it says: Do 1.-3. to obtain an integer, and then use exactly this (and no other). This sounds to me like a normative MUST?? Currently we cannot update due to the cutoff. We'll do so in Seoul. Thanks again Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Fri Nov 4 15:18:05 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C11294B0; Fri, 4 Nov 2016 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 XVJBjDN6CC3s; Fri, 4 Nov 2016 15:17:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 130FC12985A; Fri, 4 Nov 2016 15:17:56 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA4MHp3Q033656 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Nov 2016 17:17:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Thomas C. Schmidt" Date: Fri, 04 Nov 2016 17:17:51 -0500 Message-ID: <7B7A1003-3FE3-4992-8878-8AADF797B5D2@nostrum.com> In-Reply-To: References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 22:17:58 -0000 On 4 Nov 2016, at 16:30, Thomas C. Schmidt wrote: > Hi Ben, > > please see inline. > > On 03.11.2016 22:42, Ben Campbell wrote: >> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I have a one set of substantive comments/questions, and some >>>> editorial >>>> comments: >>>> >>>> Substantive: >>>> >>>> - I'm confused about the validation procedure. In step one, is this >>>> the >>>> user name of the user attempting to write the resource? In step 5, >>>> I >>>> do >>>> not understand how this terminates. Which ACL item is the >>>> "previously >>>> selected" one. If that refers to the one selected in the last >>>> iteration >>>> of steps 3 and 4, how do you know there are not more ACL items to >>>> iterate >>>> through? >>>> >>> >>> You are referring to 6.3 "validating writ access"? >>> >>> In this case, you receive a store request along with a certificate. >>> In >>> step 1, you resolve the user name of the requester, i.e., the user >>> name that corresponds to the certificate in the request. >> >> Adding something to the effect of "This is the user requesting the >> write >> operation" would be helpful. >> > > O.K., done. > >> >>> >>> ... then you identify the user in the ACL and walk up the >>> delegation >>> chain. >>> >>> In step 5, you have arrived at the root of the delegation tree. This >>> is the case, when the to_user equals the signer equals the owner of >>> the resources (see see Figure 1). This is also how it terminates - >>> the >>> owner of the resource is the root of the trust chain. >> >> I'm probably being dense here, but my confusion is in the phrasing of >> "the "to_user" value user name of the signer of the previously >> selected >> ACL item". Won't that always be true for every ACL item up the chain >> after the first? >> > > No, the selected ACL item from the previous step is the row you are > in. It basically says that the "to_user" value equals the username of > the signer. This is the "A A" case in row 4 in your example below. > This row should be in an ACL only once and the user must be the owner > of the resource, which is requested to be verified separately. > >> As an example, Lets say I have a delegation chain of A,B,C,D, where A >> is >> the owner. Would the ACL chain look like the following (in >> leave-to-root >> order )? >> >> signer to_user >> 1 C D >> 2 B C >> 3 A B >> 4 A A >> >> If so, then ACL 2 seems to have a to_user that matches the signer of >> ACL >> 1 (the previously selected ACL), which seems to terminate early. >> >> Again, I'm sure I'm missing something. >> > > I believe the confusion comes from the "previously" - this is meant to > refer to the "previous step" and the actual row. We changed > "previously" to "previous step" to avoid this confusion. I still think I'm confused. Step 5 basically says iterate over steps 3 and 4. If I'm currently looking at the ACL from the Nth iteration of 3 and 4, it seems to me that the "ACL from the previous step" is ACL N-1. If the terminal condition is when you find an ACL where the signer and the to_user are the same, then I you could say _that_ without getting into "previous steps." [...] >>> >>>> -- 2nd paragraph from end: The MUST seems more like a statement of >>>> fact. >>>> (E.g. "The resulting ... integer is used...") >>>> >>> >>> Mhmm, I don't think so. These are all iterative decision steps: try >>> (a), then write ... otherwise try (b), then write ... +++ ... >>> otherwise refuse. >> >> That was a cut and paste error on my part--I meant the 2nd to last >> paragraph of 3.1. >> > > ... still there it says: Do 1.-3. to obtain an integer, and then use > exactly this (and no other). This sounds to me like a normative MUST?? Okay. ( That is, I still don't think it's necessary, but it also does no harm, so I'll withdraw that concern.) Thanks! Ben. From nobody Fri Nov 4 15:51:42 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D431299CB; Fri, 4 Nov 2016 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 BVkmrqRpmizO; Fri, 4 Nov 2016 15:51:38 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7192F129952; Fri, 4 Nov 2016 15:51:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,445,1473112800"; d="scan'208";a="30012011" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail3.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 23:51:35 +0100 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 23:51:35 +0100 Received: from [192.168.178.122] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 23:51:34 +0100 To: Ben Campbell References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de> <2e66251e2d584a139713c44debb5bd8c@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <988577c9-f8a9-1a1a-a077-a522ead6076e@haw-hamburg.de> Date: Fri, 4 Nov 2016 23:51:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2e66251e2d584a139713c44debb5bd8c@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 22:51:41 -0000 HI Ben, On 04.11.2016 23:17, Ben Campbell wrote: >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>> ... then you identify the user in the ACL and walk up the >>>> delegation >>>> chain. >>>> >>>> In step 5, you have arrived at the root of the delegation tree. This >>>> is the case, when the to_user equals the signer equals the owner of >>>> the resources (see see Figure 1). This is also how it terminates - >>>> the >>>> owner of the resource is the root of the trust chain. >>> >>> I'm probably being dense here, but my confusion is in the phrasing of >>> "the "to_user" value user name of the signer of the previously >>> selected >>> ACL item". Won't that always be true for every ACL item up the chain >>> after the first? >>> >> >> No, the selected ACL item from the previous step is the row you are >> in. It basically says that the "to_user" value equals the username of >> the signer. This is the "A A" case in row 4 in your example below. >> This row should be in an ACL only once and the user must be the owner >> of the resource, which is requested to be verified separately. >> >>> As an example, Lets say I have a delegation chain of A,B,C,D, where A >>> is >>> the owner. Would the ACL chain look like the following (in >>> leave-to-root >>> order )? >>> >>> signer to_user >>> 1 C D >>> 2 B C >>> 3 A B >>> 4 A A >>> >>> If so, then ACL 2 seems to have a to_user that matches the signer of >>> ACL >>> 1 (the previously selected ACL), which seems to terminate early. >>> >>> Again, I'm sure I'm missing something. >>> >> >> I believe the confusion comes from the "previously" - this is meant to >> refer to the "previous step" and the actual row. We changed >> "previously" to "previous step" to avoid this confusion. > > I still think I'm confused. Step 5 basically says iterate over steps 3 > and 4. If I'm currently looking at the ACL from the Nth iteration of 3 > and 4, it seems to me that the "ACL from the previous step" is ACL N-1. > The delegation is a tree - so it's not a linear chain. > If the terminal condition is when you find an ACL where the signer and > the to_user are the same, then I you could say _that_ without getting > into "previous steps." > Guess you are right. Why don't we simplify the sentence to "Repeat steps 3 and 4 until the "to_user" value is equal to the user name of the signer of the ACL in the selected item." ? Thanks, thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Fri Nov 4 15:58:12 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C491296AF; Fri, 4 Nov 2016 15:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 2lnvzaEgkwTL; Fri, 4 Nov 2016 15:58:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5DA2D1294C6; Fri, 4 Nov 2016 15:58:10 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA4Mw52s037607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Nov 2016 17:58:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Thomas C. Schmidt" Date: Fri, 04 Nov 2016 17:58:06 -0500 Message-ID: In-Reply-To: <988577c9-f8a9-1a1a-a077-a522ead6076e@haw-hamburg.de> References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de> <2e66251e2d584a139713c44debb5bd8c@HUB01.mailcluster.haw-hamburg.de> <988577c9-f8a9-1a1a-a077-a522ead6076e@haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , The IESG , "p2psip-chairs@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 22:58:11 -0000 On 4 Nov 2016, at 17:51, Thomas C. Schmidt wrote: > HI Ben, > > On 04.11.2016 23:17, Ben Campbell wrote: > >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> > >>>>> ... then you identify the user in the ACL and walk up the >>>>> delegation >>>>> chain. >>>>> >>>>> In step 5, you have arrived at the root of the delegation tree. >>>>> This >>>>> is the case, when the to_user equals the signer equals the owner >>>>> of >>>>> the resources (see see Figure 1). This is also how it terminates - >>>>> the >>>>> owner of the resource is the root of the trust chain. >>>> >>>> I'm probably being dense here, but my confusion is in the phrasing >>>> of >>>> "the "to_user" value user name of the signer of the previously >>>> selected >>>> ACL item". Won't that always be true for every ACL item up the >>>> chain >>>> after the first? >>>> >>> >>> No, the selected ACL item from the previous step is the row you are >>> in. It basically says that the "to_user" value equals the username >>> of >>> the signer. This is the "A A" case in row 4 in your example below. >>> This row should be in an ACL only once and the user must be the >>> owner >>> of the resource, which is requested to be verified separately. >>> >>>> As an example, Lets say I have a delegation chain of A,B,C,D, where >>>> A >>>> is >>>> the owner. Would the ACL chain look like the following (in >>>> leave-to-root >>>> order )? >>>> >>>> signer to_user >>>> 1 C D >>>> 2 B C >>>> 3 A B >>>> 4 A A >>>> >>>> If so, then ACL 2 seems to have a to_user that matches the signer >>>> of >>>> ACL >>>> 1 (the previously selected ACL), which seems to terminate early. >>>> >>>> Again, I'm sure I'm missing something. >>>> >>> >>> I believe the confusion comes from the "previously" - this is meant >>> to >>> refer to the "previous step" and the actual row. We changed >>> "previously" to "previous step" to avoid this confusion. >> >> I still think I'm confused. Step 5 basically says iterate over steps >> 3 >> and 4. If I'm currently looking at the ACL from the Nth iteration of >> 3 >> and 4, it seems to me that the "ACL from the previous step" is ACL >> N-1. >> > > The delegation is a tree - so it's not a linear chain. > >> If the terminal condition is when you find an ACL where the signer >> and >> the to_user are the same, then I you could say _that_ without getting >> into "previous steps." >> > > Guess you are right. Why don't we simplify the sentence to > > "Repeat steps 3 and 4 until the "to_user" value is equal to the user > name of the signer of the ACL in the selected item." ? Assuming that gives the right results (I'll leave that to you to decide), I think it would be easier to understand. Thanks! Ben. > > Thanks, > thomas > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner > Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany ° > ° http://www.haw-hamburg.de/inet Fon: > +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: > +49-40-42875-8409 ° From nobody Sun Nov 13 19:18:52 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52C1293EE; Sun, 13 Nov 2016 19:18:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147909353103.5501.8046133374147790036.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 19:18:51 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-10.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 03:18:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol of the IETF. Title : A Usage for Shared Resources in RELOAD (ShaRe) Authors : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-10.txt Pages : 20 Date : 2016-11-13 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-share-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 24 07:41:33 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C293E129461; Thu, 24 Nov 2016 07:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 s-4182EFNIEx; Thu, 24 Nov 2016 07:41:30 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CA3129646; Thu, 24 Nov 2016 07:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1482; q=dns/txt; s=iport; t=1480001575; x=1481211175; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=gt5x74+Mc96S91BozjQF4Ky3B8571LrUILNseCyp5G8=; b=Z0RsENOcN4K1O+So5fWS51ibPUe12IAlWJk95qTaI/VwvAiUSAy1ggjR GmgmVRvZuZMNmp2lSpoHplr5KFGbTXER5RtMQ1vWooxwlGHVPRkEv2fUp s4OdFZXWqvo5Gx7mMnuv2arJ7JDr7cA9DSymwG1u+aXGKa0Y4GCqUei37 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAQAsBzdY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAXctVY1AlxuSZoIOgggohXkCgjEUAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBBDhBEAsYLlcGAQwIAQGIaQ6wSYtVAQEBAQEBAQEBAQEBAQEBAQEBAQEYB?= =?us-ascii?q?YY+gX2CXoQRChEBhX0BBIhZkXuGSIo+gXKEd4MehiuKEYNghAweN14XEwyFUj0?= =?us-ascii?q?0AYYYgi4BAQE?= X-IronPort-AV: E=Sophos;i="5.31,543,1473120000"; d="scan'208";a="650186999" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2016 15:32:52 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uAOFWqn3026583; Thu, 24 Nov 2016 15:32:52 GMT To: "Thomas C. Schmidt" , The IESG References: <24cadf5b9faa4e308b95c0313ad36d93@HUB01.mailcluster.haw-hamburg.de> <624e2178-de09-c640-19c3-754ed803507e@haw-hamburg.de> From: Benoit Claise Message-ID: <4590bbbb-e896-02ea-42c3-39558a28f41e@cisco.com> Date: Thu, 24 Nov 2016 16:32:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <624e2178-de09-c640-19c3-754ed803507e@haw-hamburg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-p2psip-share@ietf.org" , "marc@petit-huguenin.org" , "rick.casarez@gmail.com" , "p2psip@ietf.org" , "p2psip-chairs@ietf.org" Subject: Re: [P2PSIP] Benoit Claise's No Objection on draft-ietf-p2psip-share-09: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 15:41:32 -0000 On 11/3/2016 4:12 PM, Thomas C. Schmidt wrote: > Benoit, > > I assume your comment resolves after answering Rick. Yes, thanks. Regards, Benoit > > Thanks, > Thomas > > On 03.11.2016 13:02, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-p2psip-share-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Below is Rick Casarez's OPS DIR review: >> >> Section 6.5: >> "Since stored values could have been modified or invalidated prior to >> their expiration, an accessing peer SHOULD use a Stat request to check >> for updates prior to using the data cache" >> >> When considering security, and how this works, I would recommend >> changing >> this to MUST or advising that the lifetime be set very low. A stale ACL >> could allow access were none should occur. >> >