From nobody Mon Oct 10 14:07:28 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 6E6C7129774; Mon, 10 Oct 2016 14:07:25 -0700 (PDT) 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.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147613364544.31477.1034883317123391032.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 14:07:25 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-09.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, 10 Oct 2016 21:07:25 -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-09.txt Pages : 20 Date : 2016-10-10 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-09 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 Tue Oct 11 08:20:21 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 2D9F012960C; Tue, 11 Oct 2016 08:20:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147619921608.32016.2420038974746081605.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 08:20:16 -0700 Archived-At: Cc: draft-ietf-p2psip-share@ietf.org, marc@petit-huguenin.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Last Call: (A Usage for Shared Resources in RELOAD (ShaRe)) to Proposed Standard X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 11 Oct 2016 15:20:16 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'A Usage for Shared Resources in RELOAD (ShaRe)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 14 20:15:38 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 1D3CF129584; Fri, 14 Oct 2016 20:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Ax6laj8Az_6a; Fri, 14 Oct 2016 20:15:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3F61293E9; Fri, 14 Oct 2016 20:15:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1755CB8208C; Fri, 14 Oct 2016 20:15:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161015031531.1755CB8208C@rfc-editor.org> Date: Fri, 14 Oct 2016 20:15:31 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, p2psip@ietf.org, rfc-editor@rfc-editor.org Subject: [P2PSIP] RFC 7904 on A SIP Usage for REsource LOcation And Discovery (RELOAD) 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: Sat, 15 Oct 2016 03:15:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7904 Title: A SIP Usage for REsource LOcation And Discovery (RELOAD) Author: C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed. Status: Standards Track Stream: IETF Date: October 2016 Mailbox: fluffy@cisco.com, bbl@lowekamp.net, ekr@rtfm.com, sabaset@us.ibm.com, hgs@cs.columbia.edu, t.schmidt@haw-hamburg.de Pages: 20 Characters: 41978 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-p2psip-sip-21.txt URL: https://www.rfc-editor.org/info/rfc7904 DOI: http://dx.doi.org/10.17487/RFC7904 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. This document is a product of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 31 07:07:00 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 BA52C12973E; Mon, 31 Oct 2016 07:06:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147792281676.32457.7489100118055807317.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 07:06:56 -0700 Archived-At: Cc: draft-ietf-p2psip-share@ietf.org, marc@petit-huguenin.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [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 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, 31 Oct 2016 14:06:57 -0000 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? From nobody Mon Oct 31 07:38:11 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 5A87712950C; Mon, 31 Oct 2016 07:38:05 -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 G_xDzpRxcMsF; Mon, 31 Oct 2016 07:38:01 -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 3FB4912960B; Mon, 31 Oct 2016 07:37:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,575,1473112800"; d="scan'208";a="44125159" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2016 15:37:52 +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; Mon, 31 Oct 2016 15:37:51 +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; Mon, 31 Oct 2016 15:37:51 +0100 To: Mirja Kuehlewind , The IESG References: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: Date: Mon, 31 Oct 2016 15:37:49 +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: <02239df0a78b4b218f58e98d27f23405@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] =?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: Mon, 31 Oct 2016 14:38:05 -0000 Hi Mirja, 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. 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. 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. That's why it's like that. 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 °