Re: [Trust-router] Considering delaying BOF Request
David Chadwick <d.w.chadwick@kent.ac.uk> Fri, 17 May 2013 11:21 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 F41BE21F93D1 for <trust-router@ietfa.amsl.com>; 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 <trust-router@ietfa.amsl.com>; 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 <trust-router@ietf.org>; 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 <d.w.chadwick@kent.ac.uk>) 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 <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: Josh Howlett <Josh.Howlett@ja.net>
References: <CDBBBE81.23201%josh.howlett@ja.net>
In-Reply-To: <CDBBBE81.23201%josh.howlett@ja.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman <hartmans@painless-security.com>, "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: 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" <d.w.chadwick@kent.ac.uk> 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 >
- [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