From hartmans@painless-security.com Wed May 15 08:08:25 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497B821F8F12 for ; Wed, 15 May 2013 08:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEi5UpM++Org for ; Wed, 15 May 2013 08:08:20 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2D621F8F15 for ; Wed, 15 May 2013 08:08:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E4D0C2057B for ; Wed, 15 May 2013 11:05:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0qSakkLg5SS for ; Wed, 15 May 2013 11:05:35 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Wed, 15 May 2013 11:05:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 24C33440A; Wed, 15 May 2013 11:08:18 -0400 (EDT) From: Sam Hartman To: trust-router@ietf.org Date: Wed, 15 May 2013 11:08:18 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:08:25 -0000 folks. There hasn't been a lot of discussion on the list so far. Some of that has been caused by us. We've been busy trying to test some aspects of our documents with early implementation rather than discussing the protocol. So far it doesn't seem like there's been enough discussion or interest to put together a BOF request for IETF 86. we're still moving forward on trying to get implementation and deployment experience with the technology. We're still interested in standardization including making changes we'd need to make to comply with an eventual standard. We're interested in thoughts on delaying the BOF request? Does that seem like a good idea? Regardless, we will continue to use this list for any discussion of the protocol or general use cases and the moonshot-community list to discuss our implementation. --Sam From d.w.chadwick@kent.ac.uk Wed May 15 08:32:38 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D694F21F9092 for ; Wed, 15 May 2013 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Etc47p21J28N for ; Wed, 15 May 2013 08:32:34 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1D99821F908B for ; Wed, 15 May 2013 08:32:33 -0700 (PDT) Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ucdgt-0005Je-Q4; Wed, 15 May 2013 16:32:31 +0100 Message-ID: <5193AA8E.2020109@kent.ac.uk> Date: Wed, 15 May 2013 16:32:30 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trust-router@ietf.org Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:32:39 -0000 This is a topic I am very much interested in, and I have a student project starting next month to integrate the whole ABFAB infrastructure into OpenStack. So I expect to contribute to this discussion from then onwards, once we start to get experience of using trust routers and understand its your model better. Currently we have built our own trust rules into OpenStack. Specifically we have trust policies for i) which IDPs are trusted to be used as identity providers (authn trust) ii) which identity attribute types each IDP is trusted to assert (identification trust) iii) which trusted identity attribute values can be mapped into which OpenStack authz attribute types and values (authz trust) Once we integrate Abfab then we will replace i) above with the name of a community of interest instead of the name of an IdP, so that OpenStack will trust a specific CoI instead of an IdP to authenticate its users. This means that OpenStack will be trusting the trust routers to operate correctly and not allow untrusted IdPs to join the CoI. I presume that there must be a CoI administrator somewhere who configures one or more trust routers to say which IdPs are in the trusted group (and all others are not). But I dont yet appreciate how this trust is distributed between all the IdPs, and what stops a fraudulent IdP from tricking its way in. (Is it like a CA hierarchy for example?) We can similarly change policy ii), so that the identity attributes returned from ABFAB are trusted to be issued by a CoI member instead of a named IdPs. So we will be depending heavily on the trust router infrastructure to be trustworthy regards David On 15/05/2013 16:08, Sam Hartman wrote: > > > folks. > There hasn't been a lot of discussion on the list so far. Some of that > has been caused by us. We've been busy trying to test some aspects of > our documents with early implementation rather than discussing the > protocol. > > So far it doesn't seem like there's been enough discussion or interest > to put together a BOF request for IETF 86. we're still moving forward > on trying to get implementation and deployment experience with the > technology. We're still interested in standardization including making > changes we'd need to make to comply with an eventual standard. > > We're interested in thoughts on delaying the BOF request? > Does that seem like a good idea? > > Regardless, we will continue to use this list for any discussion of the > protocol or general use cases and the moonshot-community list to discuss > our implementation. > > --Sam > _______________________________________________ > trust-router mailing list > trust-router@ietf.org > https://www.ietf.org/mailman/listinfo/trust-router > From hartmans@mit.edu Wed May 15 11:04:48 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0921F8E49 for ; Wed, 15 May 2013 11:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+47ej6HDN4J for ; Wed, 15 May 2013 11:04:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82C21F8D71 for ; Wed, 15 May 2013 11:04:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 42BEC20556; Wed, 15 May 2013 14:01:58 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 404tH6zNJRuy; Wed, 15 May 2013 14:01:57 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 15 May 2013 14:01:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7BC50440A; Wed, 15 May 2013 14:04:40 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <5193AA8E.2020109@kent.ac.uk> Date: Wed, 15 May 2013 14:04:40 -0400 In-Reply-To: <5193AA8E.2020109@kent.ac.uk> (David Chadwick's message of "Wed, 15 May 2013 16:32:30 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: trust-router@ietf.org Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:04:48 -0000 I think that trust router will work well for that use case. From Josh.Howlett@ja.net Wed May 15 13:27:02 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3469E21F86CE for ; Wed, 15 May 2013 13:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aCMZYjkD8Rk for ; Wed, 15 May 2013 13:26:47 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7B111E80E9 for ; Wed, 15 May 2013 13:26:44 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0C83125E7D45_193EF82B; Wed, 15 May 2013 20:26:42 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D9CCF25E7D44_193EF81F; Wed, 15 May 2013 20:26:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Wed, 15 May 2013 21:26:41 +0100 From: Josh Howlett To: David Chadwick Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugA== Date: Wed, 15 May 2013 20:26:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <9586A46E75F2FF46B6D491DDB9410B9A@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:27:02 -0000 Hi David, Sam writes that >I think that trust router will work well for that use case. When we talk about Trust Router, we often get push-back along the lines of "that's a valid use case, but technology Foo already supports that". This is often true if you're willing to apply technology Foo in a non-typical fashion. So you could, for example, employ X509 in ways that mimic Trust Router's CoIs. These may not be particularly practical, but nonetheless it could in principle be done. So -- playing Devil's Advocate -- could I ask why you are interested in Trust Router as opposed to some other trust technology? Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From d.w.chadwick@kent.ac.uk Wed May 15 13:47:34 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC4C11E80AD for ; Wed, 15 May 2013 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8MacrVnwWX4 for ; Wed, 15 May 2013 13:47:22 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id C2FD611E80A3 for ; Wed, 15 May 2013 13:47:22 -0700 (PDT) Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UcibZ-0002n9-8x; Wed, 15 May 2013 21:47:21 +0100 Message-ID: <5193F457.4090601@kent.ac.uk> Date: Wed, 15 May 2013 21:47:19 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:47:35 -0000 Simply because the Trust router is an integral part of ABFAB, and we are integrating ABFAB into OpenStack. So we need to understand what the trust router's trust model is, how it is established and managed, and how we can integrate that into the existing trust fabric that we have already implemented in OpenStack. regards David On 15/05/2013 21:26, Josh Howlett wrote: > Hi David, > > Sam writes that > >> I think that trust router will work well for that use case. > > When we talk about Trust Router, we often get push-back along the lines of > "that's a valid use case, but technology Foo already supports that". > > This is often true if you're willing to apply technology Foo in a > non-typical fashion. So you could, for example, employ X509 in ways that > mimic Trust Router's CoIs. These may not be particularly practical, but > nonetheless it could in principle be done. > > So -- playing Devil's Advocate -- could I ask why you are interested in > Trust Router as opposed to some other trust technology? > > Josh. > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > From Josh.Howlett@ja.net Wed May 15 14:00:10 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CBC11E80CC for ; Wed, 15 May 2013 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZWQi4XRl6R4 for ; Wed, 15 May 2013 14:00:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8721F86CE for ; Wed, 15 May 2013 14:00:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 849694A6B9B_193F751B; Wed, 15 May 2013 21:00:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 7C0724A6B70_193F750F; Wed, 15 May 2013 21:00:00 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Wed, 15 May 2013 21:59:54 +0100 From: Josh Howlett To: David Chadwick Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugP//9Q+AgAAUPgA= Date: Wed, 15 May 2013 20:59:53 +0000 Message-ID: In-Reply-To: <5193F457.4090601@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <16102AC8A3ED6441BB10DCCE4250478E@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 21:00:10 -0000 Thanks David. I am *not* advocating that you do this :-) but I should note that its perfectly valid to employ ABFAB with X.509 PKI (using certificates with RadSec, rather than the PSKs acquired from Trust Router). (I would personally argue that you are able to construct a much more coherent infrastructure using both ABFAB and Trust Router, but architectural coherency is perhaps a matter of taste; in any event we do not have long to wait until we have an operational infrastructure with which to test these notions of coherency and taste to destruction!). In any case, I look forward to hearing about the results of your work when that's done, as that will really help to inform this kind of discussion. Josh. On 15/05/2013 21:47, "David Chadwick" wrote: >Simply because the Trust router is an integral part of ABFAB, and we are >integrating ABFAB into OpenStack. So we need to understand what the >trust router's trust model is, how it is established and managed, and >how we can integrate that into the existing trust fabric that we have >already implemented in OpenStack. > >regards > >David > >On 15/05/2013 21:26, Josh Howlett wrote: >> Hi David, >> >> Sam writes that >> >>> I think that trust router will work well for that use case. >> >> When we talk about Trust Router, we often get push-back along the lines >>of >> "that's a valid use case, but technology Foo already supports that". >> >> This is often true if you're willing to apply technology Foo in a >> non-typical fashion. So you could, for example, employ X509 in ways that >> mimic Trust Router's CoIs. These may not be particularly practical, but >> nonetheless it could in principle be done. >> >> So -- playing Devil's Advocate -- could I ask why you are interested in >> Trust Router as opposed to some other trust technology? >> >> Josh. >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. 2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From rafa@um.es Wed May 15 15:57:22 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AED21F8477 for ; Wed, 15 May 2013 15:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3svw79BxGQGy for ; Wed, 15 May 2013 15:57:17 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 746A221F8470 for ; Wed, 15 May 2013 15:57:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 5E8215D620; Thu, 16 May 2013 00:57:11 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YfoAZIPdgghO; Thu, 16 May 2013 00:57:10 +0200 (CEST) Received: from [192.168.1.64] (3.Red-88-25-26.staticIP.rima-tde.net [88.25.26.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPSA id AFA475D635; Thu, 16 May 2013 00:57:08 +0200 (CEST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: <333DA055-3554-466F-B19A-B5D73FFBA9AC@um.es> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B206) From: Rafa Marin Lopez Date: Thu, 16 May 2013 00:57:07 +0200 To: Josh Howlett Cc: "trust-router@ietf.org" , David Chadwick Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 22:57:22 -0000 Hi Josh I agree with your view, specially in networks where a PKI is already deploye= d. Best Regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- El 15/05/2013, a las 22:59, Josh Howlett escribi=C3=B3= : > Thanks David. >=20 > I am *not* advocating that you do this :-) but I should note that its > perfectly valid to employ ABFAB with X.509 PKI (using certificates with > RadSec, rather than the PSKs acquired from Trust Router). >=20 > (I would personally argue that you are able to construct a much more > coherent infrastructure using both ABFAB and Trust Router, but > architectural coherency is perhaps a matter of taste; in any event we do > not have long to wait until we have an operational infrastructure with > which to test these notions of coherency and taste to destruction!). >=20 > In any case, I look forward to hearing about the results of your work when= > that's done, as that will really help to inform this kind of discussion. >=20 > Josh. >=20 > On 15/05/2013 21:47, "David Chadwick" wrote: >=20 >> Simply because the Trust router is an integral part of ABFAB, and we are >> integrating ABFAB into OpenStack. So we need to understand what the >> trust router's trust model is, how it is established and managed, and >> how we can integrate that into the existing trust fabric that we have >> already implemented in OpenStack. >>=20 >> regards >>=20 >> David >>=20 >> On 15/05/2013 21:26, Josh Howlett wrote: >>> Hi David, >>>=20 >>> Sam writes that >>>=20 >>>> I think that trust router will work well for that use case. >>>=20 >>> When we talk about Trust Router, we often get push-back along the lines >>> of >>> "that's a valid use case, but technology Foo already supports that". >>>=20 >>> This is often true if you're willing to apply technology Foo in a >>> non-typical fashion. So you could, for example, employ X509 in ways that= >>> mimic Trust Router's CoIs. These may not be particularly practical, but >>> nonetheless it could in principle be done. >>>=20 >>> So -- playing Devil's Advocate -- could I ask why you are interested in >>> Trust Router as opposed to some other trust technology? >>>=20 >>> Josh. >>>=20 >>>=20 >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> not-for-profit company which is registered in England under No. 2881024 >>> and whose Registered Office is at Lumen House, Library Avenue, >>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>=20 >=20 >=20 > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 > not-for-profit company which is registered in England under No. 2881024=20= > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >=20 > _______________________________________________ > trust-router mailing list > trust-router@ietf.org > https://www.ietf.org/mailman/listinfo/trust-router From d.w.chadwick@kent.ac.uk Thu May 16 02:14:39 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98321F9113 for ; Thu, 16 May 2013 02:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mStcexSDNl3o for ; Thu, 16 May 2013 02:14:33 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8521F90EA for ; Thu, 16 May 2013 02:14:33 -0700 (PDT) Received: from edue558.kent.ac.uk ([129.12.229.88]) by mx1.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UcuGd-0007Rj-ON; Thu, 16 May 2013 10:14:31 +0100 Message-ID: <5194A379.8090608@kent.ac.uk> Date: Thu, 16 May 2013 10:14:33 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 09:14:39 -0000 Hi Josh can I clarify one thing about trust routers please. Do they have a concept of Community of Interest built into them, so that can they build different trust paths between different CoIs? Or, are they more like eduRoam, and the Internet PKI, in that once a site joins the network, every other site can connect to it and authenticate it and there is no partitioning between members (excluding the fact that PKIs could contain partitioning based on CPs, which browsers most probably dont implement or enforce) regards David On 15/05/2013 21:59, Josh Howlett wrote: > Thanks David. > > I am *not* advocating that you do this :-) but I should note that its > perfectly valid to employ ABFAB with X.509 PKI (using certificates with > RadSec, rather than the PSKs acquired from Trust Router). > > (I would personally argue that you are able to construct a much more > coherent infrastructure using both ABFAB and Trust Router, but > architectural coherency is perhaps a matter of taste; in any event we do > not have long to wait until we have an operational infrastructure with > which to test these notions of coherency and taste to destruction!). > > In any case, I look forward to hearing about the results of your work when > that's done, as that will really help to inform this kind of discussion. > > Josh. > > On 15/05/2013 21:47, "David Chadwick" wrote: > >> Simply because the Trust router is an integral part of ABFAB, and we are >> integrating ABFAB into OpenStack. So we need to understand what the >> trust router's trust model is, how it is established and managed, and >> how we can integrate that into the existing trust fabric that we have >> already implemented in OpenStack. >> >> regards >> >> David >> >> On 15/05/2013 21:26, Josh Howlett wrote: >>> Hi David, >>> >>> Sam writes that >>> >>>> I think that trust router will work well for that use case. >>> >>> When we talk about Trust Router, we often get push-back along the lines >>> of >>> "that's a valid use case, but technology Foo already supports that". >>> >>> This is often true if you're willing to apply technology Foo in a >>> non-typical fashion. So you could, for example, employ X509 in ways that >>> mimic Trust Router's CoIs. These may not be particularly practical, but >>> nonetheless it could in principle be done. >>> >>> So -- playing Devil's Advocate -- could I ask why you are interested in >>> Trust Router as opposed to some other trust technology? >>> >>> Josh. >>> >>> >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> not-for-profit company which is registered in England under No. 2881024 >>> and whose Registered Office is at Lumen House, Library Avenue, >>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>> > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > From Josh.Howlett@ja.net Thu May 16 02:53:21 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1072221F859D for ; Thu, 16 May 2013 02:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ST08qOfmYV for ; Thu, 16 May 2013 02:53:14 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9CF21F85C9 for ; Thu, 16 May 2013 02:53:14 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2381E1AA5174_194AC89B; Thu, 16 May 2013 09:53:13 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C76171A9E144_194AC88F; Thu, 16 May 2013 09:53:12 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 16 May 2013 10:53:12 +0100 From: Josh Howlett To: David Chadwick Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugP//9Q+AgAAUPgCAALyIgIAAG4cA Date: Thu, 16 May 2013 09:53:12 +0000 Message-ID: In-Reply-To: <5194A379.8090608@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <150C7B214A77D546A3198CF882DDA0FF@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 09:53:21 -0000 Hi David, The ability to partition very large numbers of different trust communities over a common, interconnecting technical infrastructure is the core motivation of Trust Router. Eduroam could be one such community that uses this technical infrastructure, but there would be many other communities using the same infrastructure to disambiguate between those that are members of their community, or not, without requiring the use of community-specific artefacts or configuration (such as trust anchors). Josh. On 16/05/2013 10:14, "David Chadwick" wrote: >Hi Josh > >can I clarify one thing about trust routers please. > >Do they have a concept of Community of Interest built into them, so that >can they build different trust paths between different CoIs? Or, are >they more like eduRoam, and the Internet PKI, in that once a site joins >the network, every other site can connect to it and authenticate it and >there is no partitioning between members (excluding the fact that PKIs >could contain partitioning based on CPs, which browsers most probably >dont implement or enforce) > >regards > >David > > > >On 15/05/2013 21:59, Josh Howlett wrote: >> Thanks David. >> >> I am *not* advocating that you do this :-) but I should note that its >> perfectly valid to employ ABFAB with X.509 PKI (using certificates with >> RadSec, rather than the PSKs acquired from Trust Router). >> >> (I would personally argue that you are able to construct a much more >> coherent infrastructure using both ABFAB and Trust Router, but >> architectural coherency is perhaps a matter of taste; in any event we do >> not have long to wait until we have an operational infrastructure with >> which to test these notions of coherency and taste to destruction!). >> >> In any case, I look forward to hearing about the results of your work >>when >> that's done, as that will really help to inform this kind of discussion. >> >> Josh. >> >> On 15/05/2013 21:47, "David Chadwick" wrote: >> >>> Simply because the Trust router is an integral part of ABFAB, and we >>>are >>> integrating ABFAB into OpenStack. So we need to understand what the >>> trust router's trust model is, how it is established and managed, and >>> how we can integrate that into the existing trust fabric that we have >>> already implemented in OpenStack. >>> >>> regards >>> >>> David >>> >>> On 15/05/2013 21:26, Josh Howlett wrote: >>>> Hi David, >>>> >>>> Sam writes that >>>> >>>>> I think that trust router will work well for that use case. >>>> >>>> When we talk about Trust Router, we often get push-back along the >>>>lines >>>> of >>>> "that's a valid use case, but technology Foo already supports that". >>>> >>>> This is often true if you're willing to apply technology Foo in a >>>> non-typical fashion. So you could, for example, employ X509 in ways >>>>that >>>> mimic Trust Router's CoIs. These may not be particularly practical, >>>>but >>>> nonetheless it could in principle be done. >>>> >>>> So -- playing Devil's Advocate -- could I ask why you are interested >>>>in >>>> Trust Router as opposed to some other trust technology? >>>> >>>> Josh. >>>> >>>> >>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>> not-for-profit company which is registered in England under No. >>>>2881024 >>>> and whose Registered Office is at Lumen House, Library Avenue, >>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>> >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. 2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From d.w.chadwick@kent.ac.uk Thu May 16 03:30:41 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C5D21F8F9E for ; Thu, 16 May 2013 03:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTIN3tLrigjW for ; Thu, 16 May 2013 03:30:35 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9B21F8F69 for ; Thu, 16 May 2013 03:30:35 -0700 (PDT) Received: from edue558.kent.ac.uk ([129.12.229.88]) by mx1.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UcvSE-0002rb-OK; Thu, 16 May 2013 11:30:34 +0100 Message-ID: <5194B54C.8040706@kent.ac.uk> Date: Thu, 16 May 2013 11:30:36 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 10:30:41 -0000 Thanks for the answer. That answers my question nicely. My next ones concern administration of a CoI. Is it assumed that there is a CoI administrator (root of trust) who will configure up some subset of trust routers to know which sites/domains/realms are members of his CoI? If not, how is the CoI membership determined by the TR software? What happens when the CoI gets so big (like EduRoam) that it is too big a task for one administrator to configure up the CoI membership? regards David On 16/05/2013 10:53, Josh Howlett wrote: > Hi David, > > The ability to partition very large numbers of different trust communities > over a common, interconnecting technical infrastructure is the core > motivation of Trust Router. > > Eduroam could be one such community that uses this technical > infrastructure, but there would be many other communities using the same > infrastructure to disambiguate between those that are members of their > community, or not, without requiring the use of community-specific > artefacts or configuration (such as trust anchors). > > Josh. > > On 16/05/2013 10:14, "David Chadwick" wrote: > >> Hi Josh >> >> can I clarify one thing about trust routers please. >> >> Do they have a concept of Community of Interest built into them, so that >> can they build different trust paths between different CoIs? Or, are >> they more like eduRoam, and the Internet PKI, in that once a site joins >> the network, every other site can connect to it and authenticate it and >> there is no partitioning between members (excluding the fact that PKIs >> could contain partitioning based on CPs, which browsers most probably >> dont implement or enforce) >> >> regards >> >> David >> >> >> >> On 15/05/2013 21:59, Josh Howlett wrote: >>> Thanks David. >>> >>> I am *not* advocating that you do this :-) but I should note that its >>> perfectly valid to employ ABFAB with X.509 PKI (using certificates with >>> RadSec, rather than the PSKs acquired from Trust Router). >>> >>> (I would personally argue that you are able to construct a much more >>> coherent infrastructure using both ABFAB and Trust Router, but >>> architectural coherency is perhaps a matter of taste; in any event we do >>> not have long to wait until we have an operational infrastructure with >>> which to test these notions of coherency and taste to destruction!). >>> >>> In any case, I look forward to hearing about the results of your work >>> when >>> that's done, as that will really help to inform this kind of discussion. >>> >>> Josh. >>> >>> On 15/05/2013 21:47, "David Chadwick" wrote: >>> >>>> Simply because the Trust router is an integral part of ABFAB, and we >>>> are >>>> integrating ABFAB into OpenStack. So we need to understand what the >>>> trust router's trust model is, how it is established and managed, and >>>> how we can integrate that into the existing trust fabric that we have >>>> already implemented in OpenStack. >>>> >>>> regards >>>> >>>> David >>>> >>>> On 15/05/2013 21:26, Josh Howlett wrote: >>>>> Hi David, >>>>> >>>>> Sam writes that >>>>> >>>>>> I think that trust router will work well for that use case. >>>>> >>>>> When we talk about Trust Router, we often get push-back along the >>>>> lines >>>>> of >>>>> "that's a valid use case, but technology Foo already supports that". >>>>> >>>>> This is often true if you're willing to apply technology Foo in a >>>>> non-typical fashion. So you could, for example, employ X509 in ways >>>>> that >>>>> mimic Trust Router's CoIs. These may not be particularly practical, >>>>> but >>>>> nonetheless it could in principle be done. >>>>> >>>>> So -- playing Devil's Advocate -- could I ask why you are interested >>>>> in >>>>> Trust Router as opposed to some other trust technology? >>>>> >>>>> Josh. >>>>> >>>>> >>>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>>> not-for-profit company which is registered in England under No. >>>>> 2881024 >>>>> and whose Registered Office is at Lumen House, Library Avenue, >>>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>>> >>> >>> >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> not-for-profit company which is registered in England under No. 2881024 >>> and whose Registered Office is at Lumen House, Library Avenue, >>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>> > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > From Josh.Howlett@ja.net Thu May 16 03:58:08 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37321F8EDA for ; Thu, 16 May 2013 03:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT8T1LbtX14Q for ; Thu, 16 May 2013 03:58:03 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9821F8EED for ; Thu, 16 May 2013 03:58:02 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9B80220C7104_194BBB6B; Thu, 16 May 2013 10:57:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 223BF20C70FC_194BBB6F; Thu, 16 May 2013 10:57:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 16 May 2013 11:57:57 +0100 From: Josh Howlett To: David Chadwick Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugP//9Q+AgAAUPgCAALyIgIAAG4cA///5uQCAABhggA== Date: Thu, 16 May 2013 10:57:57 +0000 Message-ID: In-Reply-To: <5194B54C.8040706@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D70C9E22B3FE24F9E9FAD90E377A75D@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 10:58:08 -0000 It's probably easiest if you check out the following slideware! http://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf Josh. On 16/05/2013 11:30, "David Chadwick" wrote: >Thanks for the answer. That answers my question nicely. > >My next ones concern administration of a CoI. Is it assumed that there >is a CoI administrator (root of trust) who will configure up some subset >of trust routers to know which sites/domains/realms are members of his >CoI? If not, how is the CoI membership determined by the TR software? >What happens when the CoI gets so big (like EduRoam) that it is too big >a task for one administrator to configure up the CoI membership? > >regards > >David > >On 16/05/2013 10:53, Josh Howlett wrote: >> Hi David, >> >> The ability to partition very large numbers of different trust >>communities >> over a common, interconnecting technical infrastructure is the core >> motivation of Trust Router. >> >> Eduroam could be one such community that uses this technical >> infrastructure, but there would be many other communities using the same >> infrastructure to disambiguate between those that are members of their >> community, or not, without requiring the use of community-specific >> artefacts or configuration (such as trust anchors). >> >> Josh. >> >> On 16/05/2013 10:14, "David Chadwick" wrote: >> >>> Hi Josh >>> >>> can I clarify one thing about trust routers please. >>> >>> Do they have a concept of Community of Interest built into them, so >>>that >>> can they build different trust paths between different CoIs? Or, are >>> they more like eduRoam, and the Internet PKI, in that once a site joins >>> the network, every other site can connect to it and authenticate it and >>> there is no partitioning between members (excluding the fact that PKIs >>> could contain partitioning based on CPs, which browsers most probably >>> dont implement or enforce) >>> >>> regards >>> >>> David >>> >>> >>> >>> On 15/05/2013 21:59, Josh Howlett wrote: >>>> Thanks David. >>>> >>>> I am *not* advocating that you do this :-) but I should note that its >>>> perfectly valid to employ ABFAB with X.509 PKI (using certificates >>>>with >>>> RadSec, rather than the PSKs acquired from Trust Router). >>>> >>>> (I would personally argue that you are able to construct a much more >>>> coherent infrastructure using both ABFAB and Trust Router, but >>>> architectural coherency is perhaps a matter of taste; in any event we >>>>do >>>> not have long to wait until we have an operational infrastructure with >>>> which to test these notions of coherency and taste to destruction!). >>>> >>>> In any case, I look forward to hearing about the results of your work >>>> when >>>> that's done, as that will really help to inform this kind of >>>>discussion. >>>> >>>> Josh. >>>> >>>> On 15/05/2013 21:47, "David Chadwick" wrote: >>>> >>>>> Simply because the Trust router is an integral part of ABFAB, and we >>>>> are >>>>> integrating ABFAB into OpenStack. So we need to understand what the >>>>> trust router's trust model is, how it is established and managed, and >>>>> how we can integrate that into the existing trust fabric that we have >>>>> already implemented in OpenStack. >>>>> >>>>> regards >>>>> >>>>> David >>>>> >>>>> On 15/05/2013 21:26, Josh Howlett wrote: >>>>>> Hi David, >>>>>> >>>>>> Sam writes that >>>>>> >>>>>>> I think that trust router will work well for that use case. >>>>>> >>>>>> When we talk about Trust Router, we often get push-back along the >>>>>> lines >>>>>> of >>>>>> "that's a valid use case, but technology Foo already supports that". >>>>>> >>>>>> This is often true if you're willing to apply technology Foo in a >>>>>> non-typical fashion. So you could, for example, employ X509 in ways >>>>>> that >>>>>> mimic Trust Router's CoIs. These may not be particularly practical, >>>>>> but >>>>>> nonetheless it could in principle be done. >>>>>> >>>>>> So -- playing Devil's Advocate -- could I ask why you are interested >>>>>> in >>>>>> Trust Router as opposed to some other trust technology? >>>>>> >>>>>> Josh. >>>>>> >>>>>> >>>>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>>>> not-for-profit company which is registered in England under No. >>>>>> 2881024 >>>>>> and whose Registered Office is at Lumen House, Library Avenue, >>>>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>>>> >>>> >>>> >>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>> not-for-profit company which is registered in England under No. >>>>2881024 >>>> and whose Registered Office is at Lumen House, Library Avenue, >>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>> >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. 2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From d.w.chadwick@kent.ac.uk Thu May 16 07:56:53 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B13A21F8F69 for ; Thu, 16 May 2013 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNPv5xaP9BaT for ; Thu, 16 May 2013 07:56:48 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3924421F8F7A for ; Thu, 16 May 2013 07:56:26 -0700 (PDT) Received: from edue558.kent.ac.uk ([129.12.229.88]) by mx1.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UczbK-0006xc-Vg; Thu, 16 May 2013 15:56:15 +0100 Message-ID: <5194F38F.2050906@kent.ac.uk> Date: Thu, 16 May 2013 15:56:15 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 14:56:53 -0000 Sorry it does not help much, and neither does draft-mrw-abfab-trust-router-02.txt These only talk about the protocol and model, but not about how actual implementations are initially configured. Maybe my questions are only ones that Sam and his team of implementors can answer regards David On 16/05/2013 11:57, Josh Howlett wrote: > It's probably easiest if you check out the following slideware! > > http://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf > > Josh. > > On 16/05/2013 11:30, "David Chadwick" wrote: > >> Thanks for the answer. That answers my question nicely. >> >> My next ones concern administration of a CoI. Is it assumed that there >> is a CoI administrator (root of trust) who will configure up some subset >> of trust routers to know which sites/domains/realms are members of his >> CoI? If not, how is the CoI membership determined by the TR software? >> What happens when the CoI gets so big (like EduRoam) that it is too big >> a task for one administrator to configure up the CoI membership? >> >> regards >> >> David >> >> On 16/05/2013 10:53, Josh Howlett wrote: >>> Hi David, >>> >>> The ability to partition very large numbers of different trust >>> communities >>> over a common, interconnecting technical infrastructure is the core >>> motivation of Trust Router. >>> >>> Eduroam could be one such community that uses this technical >>> infrastructure, but there would be many other communities using the same >>> infrastructure to disambiguate between those that are members of their >>> community, or not, without requiring the use of community-specific >>> artefacts or configuration (such as trust anchors). >>> >>> Josh. >>> >>> On 16/05/2013 10:14, "David Chadwick" wrote: >>> >>>> Hi Josh >>>> >>>> can I clarify one thing about trust routers please. >>>> >>>> Do they have a concept of Community of Interest built into them, so >>>> that >>>> can they build different trust paths between different CoIs? Or, are >>>> they more like eduRoam, and the Internet PKI, in that once a site joins >>>> the network, every other site can connect to it and authenticate it and >>>> there is no partitioning between members (excluding the fact that PKIs >>>> could contain partitioning based on CPs, which browsers most probably >>>> dont implement or enforce) >>>> >>>> regards >>>> >>>> David >>>> >>>> >>>> >>>> On 15/05/2013 21:59, Josh Howlett wrote: >>>>> Thanks David. >>>>> >>>>> I am *not* advocating that you do this :-) but I should note that its >>>>> perfectly valid to employ ABFAB with X.509 PKI (using certificates >>>>> with >>>>> RadSec, rather than the PSKs acquired from Trust Router). >>>>> >>>>> (I would personally argue that you are able to construct a much more >>>>> coherent infrastructure using both ABFAB and Trust Router, but >>>>> architectural coherency is perhaps a matter of taste; in any event we >>>>> do >>>>> not have long to wait until we have an operational infrastructure with >>>>> which to test these notions of coherency and taste to destruction!). >>>>> >>>>> In any case, I look forward to hearing about the results of your work >>>>> when >>>>> that's done, as that will really help to inform this kind of >>>>> discussion. >>>>> >>>>> Josh. >>>>> >>>>> On 15/05/2013 21:47, "David Chadwick" wrote: >>>>> >>>>>> Simply because the Trust router is an integral part of ABFAB, and we >>>>>> are >>>>>> integrating ABFAB into OpenStack. So we need to understand what the >>>>>> trust router's trust model is, how it is established and managed, and >>>>>> how we can integrate that into the existing trust fabric that we have >>>>>> already implemented in OpenStack. >>>>>> >>>>>> regards >>>>>> >>>>>> David >>>>>> >>>>>> On 15/05/2013 21:26, Josh Howlett wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Sam writes that >>>>>>> >>>>>>>> I think that trust router will work well for that use case. >>>>>>> >>>>>>> When we talk about Trust Router, we often get push-back along the >>>>>>> lines >>>>>>> of >>>>>>> "that's a valid use case, but technology Foo already supports that". >>>>>>> >>>>>>> This is often true if you're willing to apply technology Foo in a >>>>>>> non-typical fashion. So you could, for example, employ X509 in ways >>>>>>> that >>>>>>> mimic Trust Router's CoIs. These may not be particularly practical, >>>>>>> but >>>>>>> nonetheless it could in principle be done. >>>>>>> >>>>>>> So -- playing Devil's Advocate -- could I ask why you are interested >>>>>>> in >>>>>>> Trust Router as opposed to some other trust technology? >>>>>>> >>>>>>> Josh. >>>>>>> >>>>>>> >>>>>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>>>>> not-for-profit company which is registered in England under No. >>>>>>> 2881024 >>>>>>> and whose Registered Office is at Lumen House, Library Avenue, >>>>>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>>>>> >>>>> >>>>> >>>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>>> not-for-profit company which is registered in England under No. >>>>> 2881024 >>>>> and whose Registered Office is at Lumen House, Library Avenue, >>>>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>>>> >>> >>> >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> not-for-profit company which is registered in England under No. 2881024 >>> and whose Registered Office is at Lumen House, Library Avenue, >>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >>> > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > From hartmans@painless-security.com Thu May 16 08:17:32 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996A621F9227 for ; Thu, 16 May 2013 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkv+YfZE5+hm for ; Thu, 16 May 2013 08:17:28 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6164E21F91D8 for ; Thu, 16 May 2013 08:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 528D12057B; Thu, 16 May 2013 11:14:42 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B46ItrHZUw6Q; Thu, 16 May 2013 11:14:41 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 May 2013 11:14:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E3E2440A; Thu, 16 May 2013 11:17:26 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <5194F38F.2050906@kent.ac.uk> Date: Thu, 16 May 2013 11:17:26 -0400 In-Reply-To: <5194F38F.2050906@kent.ac.uk> (David Chadwick's message of "Thu, 16 May 2013 15:56:15 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:17:32 -0000 >>>>> "David" == David Chadwick writes: David> These only talk about the protocol and model, but not about David> how actual implementations are initially configured. Maybe my David> questions are only ones that Sam and his team of implementors David> can answer Well, this list is most a protocol list, so you'll get a protocol-centered answer here. The trust router protocol needs to support fairly robust filtering. In particular I think it needs to support the following: 1) A COI managed at a single point (plus redundancy). That COI membership information is flooded throughout the network. Filters prevent announcements related to that COI from being made except along the path that the COI administrator's announcements would take. 2) Multiple points of administration equally trusted. As an example if Eduroam used this model then each continent could inject routes. There would not be filters between continents, but there would be filters rejecting routes from lower levels. 3) A model where some subset of the namespace is permitted to be injected by people delegated to administer that. For example say that some entity in kent.ac.uk is permitted to add any realm ending in kent.ac.uk to a particular COI. Filters permit this but would reject other routes. Other models may be required. Our current implementation only implements the temporary identity protocol and does not yet implement the trust router protocol or flooding. As a result, the trust router, which really ends up just being a temporary identity proxy, must be given complete topology of the entire world at startup. We have had discussions of configuration and proposed filter types on the moonshot-community list, but those are not implemented yet. I don't know how much of that will make its way into the internet drafts. We will probably need to specify minimum filter support that implementations need to have in order to be able to have secure topology. --Sam From d.w.chadwick@kent.ac.uk Thu May 16 08:54:17 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D9D21F9343 for ; Thu, 16 May 2013 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDDAblG0kh0t for ; Thu, 16 May 2013 08:54:08 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id F057421F8825 for ; Thu, 16 May 2013 08:54:05 -0700 (PDT) Received: from edue558.kent.ac.uk ([129.12.229.88]) by mx1.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ud0VF-0001FR-8e; Thu, 16 May 2013 16:54:01 +0100 Message-ID: <51950119.1080600@kent.ac.uk> Date: Thu, 16 May 2013 16:54:01 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <5194F38F.2050906@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:54:17 -0000 X-List-Received-Date: Thu, 16 May 2013 15:54:17 -0000 This is starting to make sense, but other issues also need to be addressed. So let us consider that a global network of trust routers already exists, that know how to talk to each other, and there is just one CoI currently defined, the global Internet, that allows all IDPs to talk to all RPs anywhere in the world. 1. Suppose I want to set up a mini CoI comprising just myself at Kent, you at painless, and Josh at Janet. I have a cloud document handling service that will act as the RP/SP and give you two access along with myself (say to write a new IETF draft). I want to call the CoI "New RFC". So I need to connect 3 existing IdPs together in this CoI. Here are the questions i) who is the CoI administrator for New RFC? It should be me ii) how are CoI's named to ensure global uniqueness? Should my CoI be named newRFC.kent.ac.uk? iii) how would I get access to Kent's trust router to add a new CoI? Our computer admin staff typically do not give employees access to any computer config files e.g. I cant even add any attributes to my entry in Kent's LDAP server. iv) Suppose our computer admin staff did allow new CoI's to be dynamically created by its employees. Why would any other trust router in the world believe Kent's TR, if it broadcast an admin message which said that Kent, Janet and Painless IDPs were now in a new CoI termed New RFC? (If it is named newRFC.kent.ac.uk then it could be believed) v) Why should Painless's TR believe any random message it receives that says that its IDP is now part of a new CoI? The answer to this can only be if you have previously configured your TR with details about the New RFC CoI. Otherwise your TR is destined to believe any message it receives from anywhere about any CoI. And you could end up being co-opted into dozens of CoIs without any choice in the matter. I think for these reasons at least, a fully worked out trust model is needed for your document regards David On 16/05/2013 16:17, Sam Hartman wrote: >>>>>> "David" == David Chadwick writes: > > David> These only talk about the protocol and model, but not about > David> how actual implementations are initially configured. Maybe my > David> questions are only ones that Sam and his team of implementors > David> can answer > > Well, this list is most a protocol list, so you'll get a > protocol-centered answer here. > > The trust router protocol needs to support fairly robust filtering. In > particular I think it needs to support the following: > > 1) A COI managed at a single point (plus redundancy). > That COI membership information is flooded throughout the > network. Filters prevent announcements related to that COI from being > made except along the path that the COI administrator's announcements > would take. > > 2) Multiple points of administration equally trusted. As an example if > Eduroam used this model then each continent could inject routes. There > would not be filters between continents, but there would be filters > rejecting routes from lower levels. > > 3) A model where some subset of the namespace is permitted to be > injected by people delegated to administer that. For example say that > some entity in kent.ac.uk is permitted to add any realm ending in > kent.ac.uk to a particular COI. Filters permit this but would reject > other routes. > > Other models may be required. > > Our current implementation only implements the temporary identity > protocol and does not yet implement the trust router protocol or > flooding. As a result, the trust router, which really ends up just > being a temporary identity proxy, must be given complete topology of the > entire world at startup. > > We have had discussions of configuration and proposed filter types on > the moonshot-community list, but those are not implemented yet. > I don't know how much of that will make its way into the internet > drafts. We will probably need to specify minimum filter support that > implementations need to have in order to be able to have secure > topology. > > --Sam > From hartmans@painless-security.com Thu May 16 21:54:10 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5E21F8717 for ; Thu, 16 May 2013 21:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzKoS8H21qR5 for ; Thu, 16 May 2013 21:54:04 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8621F8F2C for ; Thu, 16 May 2013 21:54:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6FE1520584; Fri, 17 May 2013 00:51:16 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mlLzqkMolOu; Fri, 17 May 2013 00:51:16 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 17 May 2013 00:51:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 477B3440A; Fri, 17 May 2013 00:54:01 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <5194F38F.2050906@kent.ac.uk> <51950119.1080600@kent.ac.uk> Date: Fri, 17 May 2013 00:54:01 -0400 In-Reply-To: <51950119.1080600@kent.ac.uk> (David Chadwick's message of "Thu, 16 May 2013 16:54:01 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 04:54:10 -0000 david, thanks for bringing up these issues. Some of them have been discussed and I'll try to summarize our thinking. Others are new and I'm delighted to get a discussion started here. We assume communities will be named by DNS names. In the Janet pilot, there is going to be software that will make it easy for anyone to run their own Janet-hosted community even if their local IT department does not have a good way to make that easy. I don't know if Janet plans to allow individual sites to advertize their own COIs or not; that's a matter of how they configure filters and I believe that the protocol can be made to support either approach. The question of how the end-site trust routers get access to new COIs has received some internal disagreement. I think the current plan is to flood all COIs everywhere and to make sure that in general only the admin for a COI can inject routes for that COI. I think we'll need more and have put forward some proposals for that. I think others agree we may some day need more than that but so far it has not made it onto our implementation or design priority lists. Why do you think that it's important that Painless's trust router believe that it's in a COI? What's wrong with Painless being co-opted into a COI? It seems reasonably harmless to me provided that Painless does not use an attribute release policy more liberal than what it would use with an unknown service. It might be really bad for the COI admin to add Painless without for example receiving a signed contract from Painless. However provided that the COI admin takes on the liability for incorrectly adding Painless, that seems fine. (we certainly don't want to write an APC policy under which Painless would take on responsibility for COI rules if Painless has never agreed to those rules.) I do agree with you that we'll need a trust model as part of security considerations for any protocol. --Sam From d.w.chadwick@kent.ac.uk Fri May 17 00:36:44 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A977121F8F12 for ; Fri, 17 May 2013 00:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK7wELciGWOD for ; Fri, 17 May 2013 00:36:38 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 872F121F8CE9 for ; Fri, 17 May 2013 00:36:38 -0700 (PDT) Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UdFDM-00013j-L9; Fri, 17 May 2013 08:36:32 +0100 Message-ID: <5195DDFE.9000907@kent.ac.uk> Date: Fri, 17 May 2013 08:36:30 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <5194F38F.2050906@kent.ac.uk> <51950119.1080600@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:36:44 -0000 Hi Sam On 17/05/2013 05:54, Sam Hartman wrote: > > david, thanks for bringing up these issues. > Some of them have been discussed and I'll try to summarize our > thinking. Others are new and I'm delighted to get a discussion started > here. > > We assume communities will be named by DNS names. > > In the Janet pilot, there is going to be software that will make it easy > for anyone to run their own Janet-hosted community even if their local > IT department does not have a good way to make that easy. Having a Janet hosted community may be too restrictive. We need to be able to move to model that gives the freedom of the grid VOMS capability, but on an Internet scale, and without needing to run a separate VOMS server. Why do I think a Janet hosted community too restrictive? Because I might want to set up a COI containing people from Europe, Australia and China who I work with. So their IdPs will need to join the community. So we need an Internet wide base community that provides generic interconnectivity at the federation level between all IdPs and SPs, in much the same way that IP does at the network level. Then any and every specialised community of interest can be built on top of this. The Janet community would be one such community, which could be used to replace the UK AMF. So a Janet hosted community should not be the base, but rather a specialised academic CoI on the base. So this brings up one other requirement. How can a researcher such as myself, add an SP to the Internet base community so that it can be subsequently configured to trust a specialised COI? I can do this now at the IP level, but not at the federation level. > I don't know if Janet plans to allow individual sites to advertize their > own COIs or not; that's a matter of how they configure filters and I > believe that the protocol can be made to support either approach. > > > The question of how the end-site trust routers get access to new COIs > has received some internal disagreement. I think the current plan is to > flood all COIs everywhere and to make sure that in general only the > admin for a COI can inject routes for that COI. Given that I can get a new server now and plug it into IP, and have others from anywhere connect to it, means that the way IP routing works should be fine for TR routing, without getting overloaded. (But I leave you to work out the specific details for this). Having an administrator for a COI being the only person who can inject a new route/membership (I prefer to think about COI membership rather than route) into the Internet base COI is fine for small COIs, but is not scalable for very large scale COIs such as the base Internet CoI itself. There needs to be delegation of authority on a global scale to allow new members to be added to large scale COIs. So this should be built into the trust model from the outset. > > I think we'll need more and have put forward some proposals for that. I > think others agree we may some day need more than that but so far it has > not made it onto our implementation or design priority lists. The first step is to get the model agreed at the ABFAB RFC level, then implementations can start. > > > Why do you think that it's important that Painless's trust router > believe that it's in a COI? What's wrong with Painless being co-opted > into a COI? Because you would not want me to co-opt you into my Down With Russia, Abolish Corporation Tax for Multinationals, and Polygamy for All COIs would you, without your agreement? You are essentially asking your TR to trust anyone, which is a ridiculous proposition to make (given that anyone should be able to set up their own COIs). It seems reasonably harmless to me provided that Painless > does not use an attribute release policy more liberal than what it > would use with an unknown service. Well for privacy protection reasons it should not release any personal information to an unknown service. So it would be a pretty pointless IDP. "I have authenticated this user, but I am not telling you anything about him or her at all. Oh, and by the way, if you ask me to authenticate the same person again, I will give you a different unrelated random number". > > It might be really bad for the COI admin to add Painless without for > example receiving a signed contract from Painless. This is too heavy weight. If we go back to my example of me setting up a service for you, Josh and me to use, where each of our 3 IDPs and my SP form a CoI, we have to work out a way of engineering this. It would not be feasible for my university to sign a contract with Painless and Janet. Rather, I should be able to tell my local TR admin to include my SP and the three IDPs into my COI, and likewise you should tell your local TR admins to add the same COI. Today I can ask my local firewall admins to add my SP to its firewall policy so that it is visible on the Internet. SO I assume they would do likewise for TRs when these become available. This is why I think that each COI member will need to get its local TR admin to configure in details of the COI. However provided > that the COI admin takes on the liability for incorrectly adding > Painless, that seems fine. (we certainly don't want to write an APC > policy under which Painless would take on responsibility for COI rules > if Painless has never agreed to those rules.) > What is an APC policy? > > > I do agree with you that we'll need a trust model as part of security > considerations for any protocol. then we should start to write it regards David > > --Sam > From Josh.Howlett@ja.net Fri May 17 03:28:43 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6944121F918C for ; Fri, 17 May 2013 03:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_INXPNS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZsigJIQhW46 for ; Fri, 17 May 2013 03:28:37 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7E21F8733 for ; Fri, 17 May 2013 03:28:36 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 16E931AAE411_1960653B; Fri, 17 May 2013 10:28:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 988E91AAE3E4_1960652F; Fri, 17 May 2013 10:28:34 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Fri, 17 May 2013 11:28:34 +0100 From: Josh Howlett To: David Chadwick , Sam Hartman Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugP//9Q+AgAAUPgCAALyIgIAAG4cA///5uQCAABhggIAAMdiAgAAWviP///lmgAAdWD6/AAOSUAAAB+ocgA== Date: Fri, 17 May 2013 10:28:33 +0000 Message-ID: In-Reply-To: <5195DDFE.9000907@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <12085A5860123A4791A3675C53C8DCD0@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 10:28:43 -0000 Hi David, I regret that I'm a bit short on time this morning, but I'd like to respond to some of your points particularly where these concerns Janet's intentions and on-going work. On 17/05/2013 08:36, "David Chadwick" wrote: >>In the Janet pilot, there is going to be software that will make it easy >> for anyone to run their own Janet-hosted community even if their local >> IT department does not have a good way to make that easy. > >Having a Janet hosted community may be too restrictive. We need to be >able to move to model that gives the freedom of the grid VOMS >capability, but on an Internet scale, and without needing to run a >separate VOMS server. Agreed -- the hosted solution is being provided for those organisations or communities that don't wish to operate their own Trust Router. We certainly anticipate peering with other Trust Routers operated in the community, subject to some kind of peering agreement that has yet to finalised. >So we need an Internet wide base community that provides generic >interconnectivity at the federation level between all IdPs and SPs, in >much the same way that IP does at the network level. Then any and every >specialised community of interest can be built on top of this. This is precisely in line with our expectations; we're describing this as the "baseline", on which all other communities are derived. > The Janet=20 >community would be one such community, which could be used to replace >the UK AMF. So a Janet hosted community should not be the base, but >rather a specialised academic CoI on the base. I consider the UK AMF to be a community focused largely on the needs of content provision. So it wouldn't be replaced, but rather it would be an example of a specific community building on the baseline. >So this brings up one other requirement. How can a researcher such as >myself, add an SP to the Internet base community so that it can be >subsequently configured to trust a specialised COI? I can do this now at >the IP level, but not at the federation level. You would petition the CoI to include you. >> I don't know if Janet plans to allow individual sites to advertize their >> own COIs or not; that's a matter of how they configure filters and I >> believe that the protocol can be made to support either approach. >> >> >> The question of how the end-site trust routers get access to new COIs >> has received some internal disagreement. I think the current plan is to >> flood all COIs everywhere and to make sure that in general only the >> admin for a COI can inject routes for that COI. > >Given that I can get a new server now and plug it into IP, and have >others from anywhere connect to it, means that the way IP routing works >should be fine for TR routing, without getting overloaded. (But I leave >you to work out the specific details for this). > >Having an administrator for a COI being the only person who can inject a >new route/membership (I prefer to think about COI membership rather than >route) into the Internet base COI is fine for small COIs, but is not >scalable for very large scale COIs such as the base Internet CoI itself. >There needs to be delegation of authority on a global scale to allow new >members to be added to large scale COIs. So this should be built into >the trust model from the outset. Yes. This is, as Sam indicates, an area of on-going discussion. Personally I lean towards a model whereby a Trust Router maps bidirectionally between CoIs with equivalent policies, or unidirectionally where one is a policy subset of the other. >> >> I think we'll need more and have put forward some proposals for that. I >> think others agree we may some day need more than that but so far it has >> not made it onto our implementation or design priority lists. > >The first step is to get the model agreed at the ABFAB RFC level, then >implementations can start. We tried that, and failed to get traction in ABFAB. That's why we're here :-) We are building an implementation, as we have customers that need this ASAP, but we will track and be consistent with whatever the IETF decides. > However provided >> that the COI admin takes on the liability for incorrectly adding >> Painless, that seems fine. (we certainly don't want to write an APC >> policy under which Painless would take on responsibility for COI rules >> if Painless has never agreed to those rules.) >> > >What is an APC policy? An Authentication Policy Community; it's a type of community that makes assertions about assurance associated with entities (e.g., how the entities has been validated, the strength of the credential it uses to authenticate itself, etc). We (or perhaps I :-) do not anticipate a large number of APCs: something that roughly corresponds to DNS, something that roughly corresponds on the contemporary Internet PKI, and something somewhat stronger than that. A CoI's policy will describe which APCs it is willing to trust. For example, Janet could accredit Kent to APC1 and assert this to CoIs. This avoids CoIs having to engage in expensive identity validation. >> >> I do agree with you that we'll need a trust model as part of security >> considerations for any protocol. > >then we should start to write it Definitely, any contributions would be very welcome :-) Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From d.w.chadwick@kent.ac.uk Fri May 17 04:21:12 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41BE21F93D1 for ; Fri, 17 May 2013 04:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_INXPNS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGTVcRyiqMqX for ; Fri, 17 May 2013 04:21:06 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id C19A221F93A5 for ; Fri, 17 May 2013 04:21:05 -0700 (PDT) Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UdIib-0003bK-Un; Fri, 17 May 2013 12:21:02 +0100 Message-ID: <5196129B.90506@kent.ac.uk> Date: Fri, 17 May 2013 12:20:59 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 11:21:12 -0000 Hi Josh, Sam and all its seems that Josh and myself are both on the same track with no significant disagreements, which is excellent given that we have approached this from two different starting points and perspectives. One area of difference, might be that I envisage that I am the COI administrator, but Josh assumes that I am not and that I much approach him/her. I assume there will be an organisational TR administrator responsible for configuring the local TR with all its CoIs etc, and I must approach him/her to ask him to add mine to it. It might be that Josh regards him as the COI administrator, in which case we are back on the same track again. My feeling is that, in the area of on-going discussion of propagating COI knowledge, we could use the following trust model: 1. Each TR admin is absolutely in charge of his local TR and can configure it how he wants to (though it may not work properly if he does not follow some set procedures). He does not need to trust anyone else. ie. he is his own root of trust. He can determine which remote entities to trust, and how much to trust them. 2. It should not be possible for a remote TR to send trust path and COI information to a local TR unless either a) a trust relationship already exists between the local TR and the remote TR, or b) the local admin has already configured these details into his local TR, and the agent's message is seen as confirmation of this. If not, such random requests will be thrown away by the local TR since they are not trusted. 3. Trust relationships between TRs can only be mutual and not one way. It makes little sense for one TR to trust messages from another TR but the other TR to not trust any message at all from the former. However the trust relationships can be a symmetrical or asymmetrical trust relationships. An example of an asymmetrical trust relationship is that between (the TR of) a COI administrator and the members of the COI. An example of a symmetrical trust relationship is that between the members of peer COI group. 4. In order to establish a symmetrical pairwise trust relationship between two TRs the following must happen. The local admin configures trust path and COI information into his local TR, which is saying that these remote entities are to be trusted in a particular context. The local TR then sends out messages to these remote TRs saying effectively that they are trusted in this context. When messages are received from the remote TRs which confirm the configured info, then the local TR can assume that pairwise mutual symmetric trust relationships have been established between the local TR and each of these remote TRs (since the remote TR would not have sent the message if it did not likewise trust the local TR). 5. After this, any of the trusted TRs can attempt to update details relating to this relationship e.g. change their location details, add a new member to the CoI etc. Whether the message is believed or not depends upon the trust algorithm that is in force for the relationship e.g. we may need two confirmation messages from different trusted TRs in order to add a new COI member. This allows a PGP-like web of trust to be built up between peers, and means that local admin effort is not needed to manage very large COIs as they can be self managing e.g. a couple of trusted COI members can decide to add a new member to the COI and then all other existing members would trust this. 6. Alternatively when setting up a COI, each member can nominate one of them to be the COI administrator, and after this asymmetrical trust relationships are created between the (TRs of the) COI members and the (TR of the) COI administrator. Now, the COI administrator's TR can update the contents of each member's TR trust information about this COI without requiring the involvement of the local TR administrator. Comments? regards David On 17/05/2013 11:28, Josh Howlett wrote: > Hi David, > > I regret that I'm a bit short on time this morning, but I'd like to > respond to some of your points particularly where these concerns Janet's > intentions and on-going work. > > On 17/05/2013 08:36, "David Chadwick" wrote: >>> In the Janet pilot, there is going to be software that will make it easy >>> for anyone to run their own Janet-hosted community even if their local >>> IT department does not have a good way to make that easy. >> >> Having a Janet hosted community may be too restrictive. We need to be >> able to move to model that gives the freedom of the grid VOMS >> capability, but on an Internet scale, and without needing to run a >> separate VOMS server. > > Agreed -- the hosted solution is being provided for those organisations or > communities that don't wish to operate their own Trust Router. > > We certainly anticipate peering with other Trust Routers operated in the > community, subject to some kind of peering agreement that has yet to > finalised. > >> So we need an Internet wide base community that provides generic >> interconnectivity at the federation level between all IdPs and SPs, in >> much the same way that IP does at the network level. Then any and every >> specialised community of interest can be built on top of this. > > This is precisely in line with our expectations; we're describing this as > the "baseline", on which all other communities are derived. > >> The Janet >> community would be one such community, which could be used to replace >> the UK AMF. So a Janet hosted community should not be the base, but >> rather a specialised academic CoI on the base. > > I consider the UK AMF to be a community focused largely on the needs of > content provision. So it wouldn't be replaced, but rather it would be an > example of a specific community building on the baseline. > >> So this brings up one other requirement. How can a researcher such as >> myself, add an SP to the Internet base community so that it can be >> subsequently configured to trust a specialised COI? I can do this now at >> the IP level, but not at the federation level. > > You would petition the CoI to include you. > >>> I don't know if Janet plans to allow individual sites to advertize their >>> own COIs or not; that's a matter of how they configure filters and I >>> believe that the protocol can be made to support either approach. >>> >>> >>> The question of how the end-site trust routers get access to new COIs >>> has received some internal disagreement. I think the current plan is to >>> flood all COIs everywhere and to make sure that in general only the >>> admin for a COI can inject routes for that COI. >> >> Given that I can get a new server now and plug it into IP, and have >> others from anywhere connect to it, means that the way IP routing works >> should be fine for TR routing, without getting overloaded. (But I leave >> you to work out the specific details for this). >> >> Having an administrator for a COI being the only person who can inject a >> new route/membership (I prefer to think about COI membership rather than >> route) into the Internet base COI is fine for small COIs, but is not >> scalable for very large scale COIs such as the base Internet CoI itself. >> There needs to be delegation of authority on a global scale to allow new >> members to be added to large scale COIs. So this should be built into >> the trust model from the outset. > > Yes. This is, as Sam indicates, an area of on-going discussion. Personally > I lean towards a model whereby a Trust Router maps bidirectionally between > CoIs with equivalent policies, or unidirectionally where one is a policy > subset of the other. > >>> >>> I think we'll need more and have put forward some proposals for that. I >>> think others agree we may some day need more than that but so far it has >>> not made it onto our implementation or design priority lists. >> >> The first step is to get the model agreed at the ABFAB RFC level, then >> implementations can start. > > We tried that, and failed to get traction in ABFAB. That's why we're here > :-) > > We are building an implementation, as we have customers that need this > ASAP, but we will track and be consistent with whatever the IETF decides. > >> However provided >>> that the COI admin takes on the liability for incorrectly adding >>> Painless, that seems fine. (we certainly don't want to write an APC >>> policy under which Painless would take on responsibility for COI rules >>> if Painless has never agreed to those rules.) >>> >> >> What is an APC policy? > > An Authentication Policy Community; it's a type of community that makes > assertions about assurance associated with entities (e.g., how the > entities has been validated, the strength of the credential it uses to > authenticate itself, etc). We (or perhaps I :-) do not anticipate a large > number of APCs: something that roughly corresponds to DNS, something that > roughly corresponds on the contemporary Internet PKI, and something > somewhat stronger than that. > > A CoI's policy will describe which APCs it is willing to trust. For > example, Janet could accredit Kent to APC1 and assert this to CoIs. This > avoids CoIs having to engage in expensive identity validation. > >>> >>> I do agree with you that we'll need a trust model as part of security >>> considerations for any protocol. >> >> then we should start to write it > > Definitely, any contributions would be very welcome :-) > > Josh. > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > From Josh.Howlett@ja.net Fri May 17 04:57:12 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B1021F8F3C for ; Fri, 17 May 2013 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWtz+O5h4yK6 for ; Fri, 17 May 2013 04:57:06 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3879221F8E3C for ; Fri, 17 May 2013 04:57:06 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4FECC1AAE555_1961B11B; Fri, 17 May 2013 11:57:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 2CE901AAE554_1961B11F; Fri, 17 May 2013 11:57:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Fri, 17 May 2013 12:57:05 +0100 From: Josh Howlett To: David Chadwick Thread-Topic: [Trust-router] Considering delaying BOF Request Thread-Index: AQHOUX4T4oIU/b8QxUeVqzFvw/cN/pkGTxIAgAA7ebmAACdugP//9Q+AgAAUPgCAALyIgIAAG4cA///5uQCAABhggIAAMdiAgAAWviP///lmgAAdWD6/AAOSUAAAB+ocgP///2eAgAAaygA= Date: Fri, 17 May 2013 11:57:04 +0000 Message-ID: In-Reply-To: <5196129B.90506@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B70F9A16EAA8F4DA5A758C934064C17@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sam Hartman , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 11:57:12 -0000 Hi David, Bit tight on time again, just want to respond to this point: >One area of difference, might be that I envisage that I am the COI >administrator, but Josh assumes that I am not and that I much approach >him/her. I assume there will be an organisational TR administrator >responsible for configuring the local TR with all its CoIs etc, and I >must approach him/her to ask him to add mine to it. It might be that >Josh regards him as the COI administrator, in which case we are back on >the same track again. I want to permit all three models, so we're definitely in agreement. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From hartmans@painless-security.com Fri May 17 06:08:36 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA62321F8618 for ; Fri, 17 May 2013 06:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fLCkGxoI8Jl for ; Fri, 17 May 2013 06:08:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6397721F8616 for ; Fri, 17 May 2013 06:08:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2EB002057B; Fri, 17 May 2013 09:05:38 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py-23C8q8tPX; Fri, 17 May 2013 09:05:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 17 May 2013 09:05:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DE9DC440A; Fri, 17 May 2013 09:08:22 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <5194F38F.2050906@kent.ac.uk> <51950119.1080600@kent.ac.uk> <5195DDFE.9000907@kent.ac.uk> Date: Fri, 17 May 2013 09:08:22 -0400 In-Reply-To: <5195DDFE.9000907@kent.ac.uk> (David Chadwick's message of "Fri, 17 May 2013 08:36:30 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:08:37 -0000 >>>>> "David" == David Chadwick writes: I've read Josh's responses; I want to take a slightly different approach in responding here focusing on the protocol; on the moonshot-community list I'd focus on the pilot. David> Having a Janet hosted community may be too restrictive. We David> need to be able to move to model that gives the freedom of David> the grid VOMS capability, but on an Internet scale, and David> without needing to run a separate VOMS server. It would be valuable if you'd write up this use case including requirements as an internet draft. I think that would be very useful in the trust router BOF context. David> Why do I think a Janet hosted community too restrictive? David> Because I might want to set up a COI containing people from David> Europe, Australia and China who I work with. So their IdPs David> will need to join the community. So, when I say Janet-hosted community I mean that the routes in that community will be injected by Janet-controlled trust routers. Regardless of who injects the routes, routes to any IDP can be injected. David> So we need an Internet wide base community that provides David> generic interconnectivity at the federation level between all David> IdPs and SPs, in much the same way that IP does at the David> network level. Then any and every specialised community of David> interest can be built on top of this. The Yes, but we were talking about how to manage communities of interest. The base community is an APC (authentication policy community), not a COI. You're absolutely right that for scaling reasons some APCs will require delegation. The base APC is definitely such. It's possible some large COIs will require this as well. I've been unable to find a use case for a COI that required distributed management, but I agree the protocol should support this. David> Janet community David> would be one such community, which could be used to replace David> the UK AMF. So a Janet hosted community should not be the David> base, but rather a specialised academic CoI on the base. You're mixing several things here: 1) The base APC. We agree that the base APC should not be hosted, but instead various parties will inject routes. 2) A Janet hosted community. This can be about anything and contain any members. The interesting point is that Janet injects the routes. I think we agree that the protocol needs to support hosted communities. 3) a community that janet uses for organisations in the UK. This could be janet-hosted or otherwise. i think we agree that this is distinct from the base APC. David> So this brings up one other requirement. How can a researcher David> such as myself, add an SP to the Internet base community so David> that it can be subsequently configured to trust a specialised David> COI? I can do this now at the IP level, but not at the David> federation level. Agreed. the protocol supports this. determine whether a SP is in an APC with respect to a given IDP is somewhat different than determining whether that SP is in a COI with respect to an IDP, but there are approaches for both. David> Having an administrator for a COI being the only person who David> can inject a new route/membership (I prefer to think about David> COI membership rather than route) into the Internet base COI David> is fine for small COIs, but is not scalable for very large David> scale COIs such as the base Internet CoI itself. I recommend that you think about it in terms of routes rather than memberships. Not all parties will have the same policies about who to trust, and partitioning and other affects can cause the topology to appear different at different points in the system even if policy is uniform. Thinking of things as memberships seems like a convenient simplification. For myself, I've found that when I make that simplification my reasoning tends to jump over details that actually matter in terms of coming up with design or security analysis. David> There needs David> to be delegation of authority on a global scale to allow new David> members to be added to large scale COIs. So this should be David> built into the trust model from the outset. if you replace COI with community I'll agree with you. As i said, the use case for this is clear for APCs. It's not clear to me that it is true for COIs, but I see no harm in supporting it. >> Why do you think that it's important that Painless's trust router >> believe that it's in a COI? What's wrong with Painless being >> co-opted into a COI? David> Because you would not want me to co-opt you into my Down With David> Russia, Abolish Corporation Tax for Multinationals, and David> Polygamy for All COIs would you, without your agreement? The key in that statement is that it's your community. If you want to make ridiculous statements about me, the problem comes in when someone trusts those statements. I'd recommend than no SPs use your community if you're going to do that sort of thing. non-technical measures such as law may give me recourse if I find your statements objectionable rather than simply ridiculous. The Internet has many ways for people to group things together already. I see no harm in you creating a useless group that includes me. I see significant harm in someone inappropriately trusting that grouping. it seems David> It seems reasonably harmless to me provided that Painlessl >> does not use an attribute release policy more liberal than what >> it would use with an unknown service. David> Well for privacy protection reasons it should not release any David> personal information to an unknown service. I agree that people concerned about privacy should disclose little (probably nothing) to an unknown service. In this case, the IDP will almost certainly need to know about communities it is part of. i don't see why it needs to be the trust router rather than the IDP though. From d.w.chadwick@kent.ac.uk Fri May 17 10:39:52 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0111E80FE for ; Fri, 17 May 2013 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWmyvJVSHbLg for ; Fri, 17 May 2013 10:39:43 -0700 (PDT) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id E587F11E8111 for ; Fri, 17 May 2013 10:39:42 -0700 (PDT) Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UdOd0-0000fP-T9; Fri, 17 May 2013 18:39:39 +0100 Message-ID: <51966B59.2020200@kent.ac.uk> Date: Fri, 17 May 2013 18:39:37 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <5194F38F.2050906@kent.ac.uk> <51950119.1080600@kent.ac.uk> <5195DDFE.9000907@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "trust-router@ietf.org" Subject: Re: [Trust-router] Considering delaying BOF Request X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:39:53 -0000 Hi Sam On 17/05/2013 14:08, Sam Hartman wrote: >>>>>> "David" == David Chadwick writes: > > I've read Josh's responses; I want to take a slightly different approach > in responding here focusing on the protocol; on the moonshot-community > list I'd focus on the pilot. > > David> Having a Janet hosted community may be too restrictive. We > David> need to be able to move to model that gives the freedom of > David> the grid VOMS capability, but on an Internet scale, and > David> without needing to run a separate VOMS server. > > It would be valuable if you'd write up this use case including > requirements as an internet draft. > I think that would be very useful in the trust router BOF context. I dont know how ABFAB on its own can replace VOMS. I think you need the support of the SP as well to do some attribute mapping. We have implemented this in OpenStack with attribute mapping from IdP attributes to OpenStack attributes so that we can replace VOMS. But this is federation protocol independent and not specific to ABFAB. > > > David> Why do I think a Janet hosted community too restrictive? > David> Because I might want to set up a COI containing people from > David> Europe, Australia and China who I work with. So their IdPs > David> will need to join the community. > > So, when I say Janet-hosted community I mean that the routes in that > community will be injected by Janet-controlled trust routers. > Regardless of who injects the routes, routes to any IDP can be injected. Routes to any IDP can be injected and Trusted Routes to any IDP can be injected are different things. We need a mechanism of determining a trusted route from an untrusted one, and discarding the latter. > > David> So we need an Internet wide base community that provides > David> generic interconnectivity at the federation level between all > David> IdPs and SPs, in much the same way that IP does at the > David> network level. Then any and every specialised community of > David> interest can be built on top of this. The > > Yes, but we were talking about how to manage communities of interest. > The base community is an APC (authentication policy community), not a > COI. That's good, since it gives a solid foundation from which to build. But how are you ensuring that each IDP can authenticate to the level that it claims? Auditor certificates? Self certification? > > You're absolutely right that for scaling reasons some APCs will require > delegation. > The base APC is definitely such. > > It's possible some large COIs will require this as well. > I've been unable to find a use case for a COI that required distributed > management, but I agree the protocol should support this. > > > > David> Janet community > David> would be one such community, which could be used to replace > David> the UK AMF. So a Janet hosted community should not be the > David> base, but rather a specialised academic CoI on the base. > > You're mixing several things here: > > 1) The base APC. We agree that the base APC should not be hosted, but > instead various parties will inject routes. I would like to see the trust model for the above so as to ensure that the routes are trustworthy. > > 2) A Janet hosted community. This can be about anything and contain any > members. The interesting point is that Janet injects the routes. > > I think we agree that the protocol needs to support hosted communities. agreed. But it isnt just the protocol that needs to be considered. Each member needs to know who the COI administrator is (Janet in this case) by some out of band means so that it can verify that messages are really from Janet. > > 3) a community that janet uses for organisations in the UK. This could > be janet-hosted or otherwise. i think we agree that this is distinct > from the base APC. Sorry, but I am not sure what this use case is. > > > David> So this brings up one other requirement. How can a researcher > David> such as myself, add an SP to the Internet base community so > David> that it can be subsequently configured to trust a specialised > David> COI? I can do this now at the IP level, but not at the > David> federation level. > > Agreed. > the protocol supports this. > determine whether a SP is in an APC with respect to a given IDP is > somewhat different than determining whether that SP is in a COI with > respect to an IDP, but there are approaches for both. I dont follow what relationship an SP has to an APC, since an SP is not performing user authentication. Surely only IDPs are assured to various APC levels. SPs are the RPs who rely on this. So an SP could theoretically join any and every APC couldn't it? > > David> Having an administrator for a COI being the only person who > David> can inject a new route/membership (I prefer to think about > David> COI membership rather than route) into the Internet base COI > David> is fine for small COIs, but is not scalable for very large > David> scale COIs such as the base Internet CoI itself. > > I recommend that you think about it in terms of routes rather > than memberships. No, ultimately I dont really care about routes. Routes are only a means to an end. What I care about is CoI membership, and that if I form a CoI of orgs A and B that it is really A and B I am talking to. Now you might say that I can rely on PKI for that, which is true, but then I could also rely on the DNS to get me to A and B as well, and then I dont need trust routers do I? So if TRs are guaranteeing to connect me to A and B directly, they had better do it correctly, without me needing PKI or the DNS. So I do care about routes to the extent that I need to trust them to do the connecting correctly. What does a TR give me that I can rely on, which is equivalent to a CA self signed cert? At the moment I dont know how I can rely on routes. > Not all parties will have the same policies about who to trust, and > partitioning and other affects can cause the topology to appear > different at different points in the system even if policy is uniform. This sounds weird, and non-deterministic. A uniform policy that causes different parties to see different topologies for the same network would seem to give rise to an unusable system. Clearly there is something I dont understand here. But you said that we need to trust the TRs to set up the routes. So all parties must have the same policies for this mustn't they, otherwise they would end up with different topologies for the same trusted network. > > Thinking of things as memberships seems like a convenient > simplification. For myself, I've found that when I make that > simplification my reasoning tends to jump over details that actually > matter in terms of coming up with design or security analysis. Thats probably true, since we need to know on what basis we can have trust in the TR infrastructure. > > > David> There needs > David> to be delegation of authority on a global scale to allow new > David> members to be added to large scale COIs. So this should be > David> built into the trust model from the outset. > > if you replace COI with community I'll agree with you. what is the difference between the two? I thought they were the same. But I guess you mean APC when you say community. Is that true? > As i said, the use case for this is clear for APCs. It's not clear to me > that it is true for COIs, but I see no harm in supporting it. > > >> Why do you think that it's important that Painless's trust router > >> believe that it's in a COI? What's wrong with Painless being > >> co-opted into a COI? > > David> Because you would not want me to co-opt you into my Down With > David> Russia, Abolish Corporation Tax for Multinationals, and > David> Polygamy for All COIs would you, without your agreement? > > The key in that statement is that it's your community. No the key is that you have joined a community that you do not want to be in, since you were coopted into it without your express agreement. So if the community does something you do not agree with, you might be held severally and jointly responsible for this. > If you want to make ridiculous statements about me, the problem comes in > when someone trusts those statements. > I'd recommend than no SPs use your community if you're going to do that > sort of thing. The point is that you are trusting them, since you have joined the community by being coopted in. The community itself could then gain extra trustworthiness by association with you (if everyone sees that Sam is a member then it must be good, mustn't it) > > non-technical measures such as law may give me recourse if I find your > statements objectionable rather than simply ridiculous. They were exaggerated and made to be ridiculous in order to prove the point, which is, you should not have a system which allows members to be co-opted without their express agreement. This does not happen in real life, and it should not in ABFAB. > The Internet has many ways for people to group things together already. > I see no harm in you creating a useless group that includes me. I really do think you need to reappraise this. (On a different tack, you probably do already object to spammers including your email address in a group email list without your permission). > > I see significant harm in someone inappropriately trusting that > grouping. > > it seems David> It seems reasonably harmless to me provided that Painlessl > >> does not use an attribute release policy more liberal than what > >> it would use with an unknown service. > > David> Well for privacy protection reasons it should not release any > David> personal information to an unknown service. > > I agree that people concerned about privacy should disclose little > (probably nothing) to an unknown service. > In this case, the IDP will almost certainly need to know about > communities it is part of. > i don't see why it needs to be the trust router rather than the IDP > though. > For the following reason. If I can have no confidence in the TR system, that when I form a COI of A, B and C, that only A, B and C will be in it, then the COI concept brings me no benefit it all. I might just as well have a COI of the entire Internet, and then use my own mechanisms external to the TR system to enforce the COI membership of A, B and C. So what is the added value that you think the TR system brings to COIs? regards David From ietf@augustcellars.com Thu May 30 14:31:52 2013 Return-Path: X-Original-To: trust-router@ietfa.amsl.com Delivered-To: trust-router@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275521F86AE; Thu, 30 May 2013 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWWAr8GjTvLh; Thu, 30 May 2013 14:31:47 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 94C7521F8696; Thu, 30 May 2013 14:31:44 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2A66C2CA20; Thu, 30 May 2013 14:31:44 -0700 (PDT) From: "Jim Schaad" To: References: <20130530211857.10340.69519.idtracker@ietfa.amsl.com> In-Reply-To: <20130530211857.10340.69519.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 14:30:52 -0700 Message-ID: <04ee01ce5d7c$f7c60240$e75206c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGebNoyW1RF+EXbAdPZfyyPhs4Yspl+HVnw Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org, MOONSHOT-COMMUNITY@JISCMAIL.AC.UK Subject: [Trust-router] FW: New Version Notification for draft-schaad-trust-router-problem-01.txt X-BeenThere: trust-router@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "ABFAB Trust Router discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:31:52 -0000 I present this document for discussion on the IETF Trust Router mailing = list. It is a new and completely different version of the problem statement = from that offered by the Janet people. I think it is a more complete = and more understandable document that the one they have provided. The document was started under an alcoholic haze and frustration over = the fact that the BOF for the group might not occur in Berlin as was = originally envisioned. The primary hope of this document is to try and = get more conversation on this mailing list about the problem itself. = Note that I don't currently care what the solution is. That should be = discussed after the BOF has been completed. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, May 30, 2013 2:19 PM > To: Jim Schaad > Subject: New Version Notification for = draft-schaad-trust-router-problem- > 01.txt >=20 >=20 > A new version of I-D, draft-schaad-trust-router-problem-01.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. >=20 > Filename: draft-schaad-trust-router-problem > Revision: 01 > Title: Trust Router Problem Statement > Creation date: 2013-05-30 > Group: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-trust-router-problem-01.= txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-trust-router-problem > Htmlized: = http://tools.ietf.org/html/draft-schaad-trust-router-problem-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-trust-router-problem-01 >=20 > Abstract: > There are a number of problems with using the current AAA framework > for doing access control, this document looks at a number of these > issues and poses some questions about how to create a new trust > router system. >=20 >=20 >=20 >=20 > The IETF Secretariat