Re: [Trust-router] Considering delaying BOF Request

[David Chadwick <[e-mail]>]

Hi Sam

On 17/05/2013 14:08, Sam Hartman wrote:
>>>>>> "David" == David Chadwick <[e-mail]> writes:
>
> I've read Josh's responses; I want to take a slightly different approach
> in responding here focusing on the protocol; on the moonshot-community
> list I'd focus on the pilot.
>
>      David> Having a Janet hosted community may be too restrictive. We
>      David> need to be able to move to model that gives the freedom of
>      David> the grid VOMS capability, but on an Internet scale, and
>      David> without needing to run a separate VOMS server.
>
> It would be valuable if you'd write up this use case including
>   requirements as an internet draft.
> I think that would be very useful in the trust router BOF context.

I dont know how ABFAB on its own can replace VOMS. I think you need the 
support of the SP as well to do some attribute mapping.  We have 
implemented this in OpenStack with attribute mapping from IdP attributes 
to OpenStack attributes so that we can replace VOMS. But this is 
federation protocol independent and not specific to ABFAB.

>
>
>      David> Why do I think a Janet hosted community too restrictive?
>      David> Because I might want to set up a COI containing people from
>      David> Europe, Australia and China who I work with. So their IdPs
>      David> will need to join the community.
>
> So, when I say Janet-hosted community I mean that  the routes in that
> community will be injected by Janet-controlled trust routers.
> Regardless of who injects the routes, routes to any IDP can be injected.

Routes to any IDP can be injected and Trusted Routes to any IDP can be 
injected are different things. We need a mechanism of determining a 
trusted route from an untrusted one, and discarding the latter.


>
>      David> So we need an Internet wide base community that provides
>      David> generic interconnectivity at the federation level between all
>      David> IdPs and SPs, in much the same way that IP does at the
>      David> network level. Then any and every specialised community of
>      David> interest can be built on top of this. The
>
> Yes, but we were talking about how to manage communities of interest.
> The base community is an APC (authentication policy community), not a
> COI.

That's good, since it gives a solid foundation from which to build. But 
how are you ensuring that each IDP can authenticate to the level that it 
claims? Auditor certificates? Self certification?

>
> You're absolutely right that for scaling reasons some APCs will require
> delegation.
> The base APC is definitely such.
>
> It's possible some large COIs will require this as well.
> I've been unable to find a use case for a COI that required distributed
> management, but I agree the protocol should support this.
>
>
>
>      David> Janet community
>      David> would be one such community, which could be used to replace
>      David> the UK AMF. So a Janet hosted community should not be the
>      David> base, but rather a specialised academic CoI on the base.
>
> You're mixing several things here:
>
> 1) The base APC. We agree that the base APC should not be hosted, but
> instead various parties will inject routes.

I would like to see the trust model for the above so as to ensure that 
the routes are trustworthy.

>
> 2) A Janet hosted community. This can be about anything and contain any
> members.  The interesting point is that Janet injects the routes.
>
> I think we agree that the protocol needs to support hosted communities.

agreed. But it isnt just the protocol that needs to be considered. Each 
member needs to know who the COI administrator is (Janet in this case) 
by some out of band means so that it can verify that messages are really 
from Janet.

>
> 3) a community that janet uses for organisations in the UK.  This could
> be janet-hosted or otherwise.  i think we agree that this is distinct
> from the base APC.

Sorry, but I am not sure what this use case is.

>
>
>      David> So this brings up one other requirement. How can a researcher
>      David> such as myself, add an SP to the Internet base community so
>      David> that it can be subsequently configured to trust a specialised
>      David> COI? I can do this now at the IP level, but not at the
>      David> federation level.
>
> Agreed.
> the protocol supports this.
> determine whether a SP is in an APC with respect to a given IDP is
> somewhat different than determining whether that SP is in a COI with
> respect to an IDP, but there are approaches for both.

I dont follow what relationship an SP has to an APC, since an SP is not 
performing user authentication. Surely only IDPs are assured to various 
APC levels. SPs are the RPs who rely on this. So an SP could 
theoretically join any and every APC couldn't it?


>
>      David> Having an administrator for a COI being the only person who
>      David> can inject a new route/membership (I prefer to think about
>      David> COI membership rather than route) into the Internet base COI
>      David> is fine for small COIs, but is not scalable for very large
>      David> scale COIs such as the base Internet CoI itself.
>
> I recommend that you think about it in terms of routes rather
> than memberships.

No, ultimately I dont really care about routes. Routes are only a means 
to an end. What I care about is CoI membership, and that if I form a CoI 
of orgs A and B that it is really A and B I am talking to. Now you might 
say that I can rely on PKI for that, which is true, but then I could 
also rely on the DNS to get me to A and B as well, and then I dont need 
trust routers do I? So if TRs are guaranteeing to connect me to A and B 
directly, they had better do it correctly, without me needing PKI or the 
DNS. So I do care about routes to the extent that I need to trust them 
to do the connecting correctly. What does a TR give me that I can rely 
on, which is equivalent to a CA self signed cert?
At the moment I dont know how I can rely on routes.


> Not all parties will have the same policies about who to trust, and
> partitioning and other affects can cause the topology to appear
> different at different points in the system even if policy is uniform.


This sounds weird, and non-deterministic. A uniform policy that causes 
different parties to see different topologies for the same network would 
seem to give rise to an unusable system. Clearly there is something I 
dont understand here.

But you said that we need to trust the TRs to set up the routes. So all 
parties must have the same policies for this mustn't they, otherwise 
they would end up with different topologies for the same trusted network.


>
> Thinking of things as memberships seems like a convenient
> simplification.  For myself, I've found that when I make that
> simplification my reasoning tends to jump over details that actually
> matter in terms of coming up with design or security analysis.

Thats probably true, since we need to know on what basis we can have 
trust in the TR infrastructure.


>
>
>      David> There needs
>      David> to be delegation of authority on a global scale to allow new
>      David> members to be added to large scale COIs. So this should be
>      David> built into the trust model from the outset.
>
> if you replace COI with community I'll agree with you.

what is the difference between the two? I thought they were the same. 
But I guess you mean APC when you say community. Is that true?


> As i said, the use case for this is clear for APCs. It's not clear to me
> that it is true for COIs, but I see no harm in supporting it.
>
>      >> 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?
>
>      David> Because you would not want me to co-opt you into my Down With
>      David> Russia, Abolish Corporation Tax for Multinationals, and
>      David> Polygamy for All COIs would you, without your agreement?
>
> The key in that statement is that it's your community.

No the key is that you have joined a community that you do not want to 
be in, since you were coopted into it without your express agreement. So 
if the community does something you do not agree with, you might be held 
severally and jointly responsible for this.

> If you want to make ridiculous statements about me, the problem comes in
> when someone trusts those statements.
> I'd recommend than no SPs use your community if you're going to do that
> sort of thing.

The point is that you are trusting them, since you have joined the 
community by being coopted in. The community itself could then gain 
extra trustworthiness by association with you (if everyone sees that Sam 
is a member then it must be good, mustn't it)


>
> non-technical measures such as law may give me recourse if I find your
> statements objectionable rather than simply ridiculous.

They were exaggerated and made to be ridiculous in order to prove the 
point, which is, you should not have a system which allows members to be 
co-opted without their express agreement. This does not happen in real 
life, and it should not in ABFAB.

> The Internet has many ways for people to group things together already.
> I see no harm in you creating a useless group that includes me.

I really do think you need to reappraise this.
(On a different tack, you probably do already object to spammers 
including your email address in a group email list without your permission).



>
> I see significant harm in someone inappropriately trusting that
> grouping.
>
> it seems    David>  It seems reasonably harmless to me provided that Painlessl
>      >> does not use an attribute release policy more liberal than what
>      >> it would use with an unknown service.
>
>      David> Well for privacy protection reasons it should not release any
>      David> personal information to an unknown service.
>
> I agree that  people concerned about privacy should disclose little
> (probably nothing) to an unknown service.
> In this case, the IDP will almost certainly need to know about
> communities it is part of.
> i don't see why it needs to be the trust router rather than the IDP
> though.
>

For the following reason. If I can have no confidence in the TR system, 
that when I form a COI of A, B and C, that only A, B and C will be in 
it, then the COI concept brings me no benefit it all. I might just as 
well have a COI of the entire Internet, and then use my own mechanisms 
external to the TR system to enforce the COI membership of A, B and C.

So what is the added value that you think the TR system brings to COIs?

regards

David