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
>