Re: [Trust-router] Considering delaying BOF Request

David Chadwick <d.w.chadwick@kent.ac.uk> Thu, 16 May 2013 10:30 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 97C5D21F8F9E for <trust-router@ietfa.amsl.com>; 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 <trust-router@ietfa.amsl.com>; 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 <trust-router@ietf.org>; 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 <d.w.chadwick@kent.ac.uk>) 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 <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: <CDBA6659.23018%josh.howlett@ja.net>
In-Reply-To: <CDBA6659.23018%josh.howlett@ja.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "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 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" <d.w.chadwick@kent.ac.uk> 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" <d.w.chadwick@kent.ac.uk> 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
>