Re: [Trust-router] Considering delaying BOF Request
David Chadwick <d.w.chadwick@kent.ac.uk> Thu, 16 May 2013 15:54 UTC
Return-Path: <d.w.chadwick@kent.ac.uk>
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 <trust-router@ietfa.amsl.com>; 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 <trust-router@ietfa.amsl.com>; 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 <trust-router@ietf.org>; 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 <d.w.chadwick@kent.ac.uk>) 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 <d.w.chadwick@kent.ac.uk>
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 <hartmans@painless-security.com>
References: <CDBA7A25.23081%josh.howlett@ja.net> <5194F38F.2050906@kent.ac.uk> <tsltxm3c5tl.fsf@mit.edu>
In-Reply-To: <tsltxm3c5tl.fsf@mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Josh Howlett <Josh.Howlett@ja.net>, "trust-router@ietf.org" <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." <trust-router.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trust-router>, <mailto:trust-router-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trust-router>
List-Post: <mailto:trust-router@ietf.org>
List-Help: <mailto:trust-router-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trust-router>, <mailto:trust-router-request@ietf.org?subject=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 <d.w.chadwick@kent.ac.uk> 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 >
- [Trust-router] Considering delaying BOF Request Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… Rafa Marin Lopez
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick