Re: [Trust-router] Considering delaying BOF Request

[David Chadwick <[e-mail]>]

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" <[e-mail]> 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
>