Re: [Trust-router] Considering delaying BOF Request

[David Chadwick <[e-mail]>]

Hi Sam

On 17/05/2013 05:54, Sam Hartman wrote:
>
> david, thanks for bringing up these issues.
> Some of them have been discussed and I'll try to summarize our
> thinking.  Others are new and I'm delighted to get a discussion started
> here.
>
> We assume communities will be named by DNS names.
>
> 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.

Why do I think a Janet hosted community too restrictive? Because I might 
want to set up a COI containing people from Europe, Australia and China 
who I work with. So their IdPs will need to join the community.

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. 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.

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.


> 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.

>
> 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.

>
>
> Why do you think that it's important that Painless's trust router
> believe that it's in a COI?  What's wrong with Painless being co-opted
> into a COI?

Because you would not want me to co-opt you into my Down With Russia, 
Abolish Corporation Tax for Multinationals, and Polygamy for All COIs 
would you, without your agreement? You are essentially asking your TR to 
trust anyone, which is a ridiculous proposition to make (given that 
anyone should be able to set up their own COIs).

  It seems reasonably harmless to me provided that Painless
> does not use an attribute release policy  more liberal than what it
> would use with an unknown service.

Well for privacy protection reasons it should not release any personal 
information to an unknown service. So it would be a pretty pointless 
IDP. "I have authenticated this user, but I am not telling you anything 
about him or her at all. Oh, and by the way, if you ask me to 
authenticate the same person again, I will give you a different 
unrelated random number".


>
> It might be really bad for the COI admin to add Painless without for
> example receiving a signed contract from Painless.

This is too heavy weight. If we go back to my example of me setting up a 
service for you, Josh and me to use, where each of our 3 IDPs and my SP 
form a CoI, we have to work out a way of engineering this. It would not 
be feasible for my university to sign a contract with Painless and 
Janet. Rather, I should be able to tell my local TR admin to include my 
SP and the three IDPs into my COI, and likewise you should tell your 
local TR admins to add the same COI. Today I can ask my local firewall 
admins to add my SP to its firewall policy so that it is visible on the 
Internet. SO I assume they would do likewise for TRs when these become 
available. This is why I think that each COI member will need to get its 
local TR admin to configure in details of the COI.


  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?

>
>
> 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

regards

David
>
> --Sam
>