Subject: [Trust-router] Considering delaying BOF Request

From: Sam Hartman <[email-masked]>
Date: Wed, 15 May 2013 11:08:18 -0400

folks.
There hasn't been a lot of discussion on the list so far. Some of that
has been caused by us. We've been busy trying to test some aspects of
our documents with early implementation rather than discussing the
protocol.

So far it doesn't seem like there's been enough discussion or interest
to put together a BOF request for IETF 86.  we're still moving forward
on trying to get implementation and deployment experience with the
technology. We're still interested in standardization including making
changes we'd need to make to comply with an eventual standard.

We're interested in thoughts on delaying the BOF request?
Does that seem like a good idea?

Regardless, we will continue to use this list for any discussion of the
protocol or general use cases and the moonshot-community list to discuss
our implementation.

--Sam

---

From: David Chadwick <[email-masked]>
Date: Wed, 15 May 2013 16:32:30 +0100

This is a topic I am very much interested in, and I have a student 
project starting next month to integrate the whole ABFAB infrastructure 
into OpenStack. So I expect to contribute to this discussion from then 
onwards, once we start to get experience of using trust routers and 
understand its your model better.

Currently we have built our own trust rules into OpenStack. Specifically 
we have trust policies for
i) which IDPs are trusted to be used as identity providers (authn trust)
ii) which identity attribute types each IDP is trusted to assert 
(identification trust)
iii) which trusted identity attribute values can be mapped into which 
OpenStack authz attribute types and values (authz trust)

Once we integrate Abfab then we will replace i) above with the name of a 
community of interest instead of the name of an IdP, so that OpenStack 
will trust a specific CoI instead of an IdP to authenticate its users. 
This means that OpenStack will be trusting the trust routers to operate 
correctly and not allow untrusted IdPs to join the CoI. I presume that 
there must be a CoI administrator somewhere who configures one or more 
trust routers to say which IdPs are in the trusted group (and all others 
are not). But I dont yet appreciate how this trust is distributed 
between all the IdPs, and what stops a fraudulent IdP from tricking its 
way in. (Is it like a CA hierarchy for example?)

We can  similarly change policy ii), so that the identity attributes 
returned from ABFAB are trusted to be issued by a CoI member instead of 
a named IdPs. So we will be depending heavily on the trust router 
infrastructure to be trustworthy

regards

David

On 15/05/2013 16:08, Sam Hartman wrote:
> _______________________________________________
> trust-router mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trust-router
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 May 2013 14:04:40 -0400

I think that trust router will work well for that use case.

---

From: Josh Howlett <[email-masked]>
Date: Wed, 15 May 2013 20:26:40 +0000

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

---

From: David Chadwick <[email-masked]>
Date: Wed, 15 May 2013 21:47:19 +0100

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

---

From: Josh Howlett <[email-masked]>
Date: Wed, 15 May 2013 20:59:53 +0000

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.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 16 May 2013 00:57:07 +0200

Hi Josh

I agree with your view, specially in networks where a PKI is already deployed.

Best Regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: David Chadwick <[email-masked]>
Date: Thu, 16 May 2013 10:14:33 +0100

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

---

From: Josh Howlett <[email-masked]>
Date: Thu, 16 May 2013 09:53:12 +0000

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" <[email-masked]> wrote:

>>>> When we talk about Trust Router, we often get push-back along the
>>>>lines
>>>> of

---

From: David Chadwick <[email-masked]>
Date: Thu, 16 May 2013 11:30:36 +0100

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

---

From: Josh Howlett <[email-masked]>
Date: Thu, 16 May 2013 10:57:57 +0000

It's probably easiest if you check out the following slideware!

http://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf

Josh.

---

From: David Chadwick <[email-masked]>
Date: Thu, 16 May 2013 15:56:15 +0100

Sorry it does not help much, and neither does
draft-mrw-abfab-trust-router-02.txt

These only talk about the protocol and model, but not about how actual 
implementations are initially configured. Maybe my questions are only 
ones that Sam and his team of implementors can answer

regards

David

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 May 2013 11:17:26 -0400

>>>>> "David" == David Chadwick <[email-masked]> writes:

    David> These only talk about the protocol and model, but not about
    David> how actual implementations are initially configured. Maybe my
    David> questions are only ones that Sam and his team of implementors
    David> can answer

Well, this list is most a protocol list, so you'll get a
protocol-centered answer here.

The trust router protocol needs to support fairly robust  filtering. In
particular I think it needs to support the following:

1) A COI managed at a single point (plus redundancy).
That COI membership information is flooded throughout the
network. Filters prevent announcements related to that COI from being
made except along the path that the COI administrator's announcements
would take.

2) Multiple points of administration equally trusted.  As an example if
Eduroam used this model then each continent could inject routes. There
would not be filters between continents, but there would be filters
rejecting routes from lower levels.

3) A model where some subset of the namespace is permitted to be
injected  by people delegated to administer that.  For example  say that
some entity in  kent.ac.uk is permitted to add any realm ending in
kent.ac.uk to a particular COI. Filters permit this but would reject
other routes.

Other models may be required.

Our current implementation only implements the temporary identity
protocol and does not yet implement the trust router protocol or
flooding.  As a result, the trust router, which really ends up just
being a temporary identity proxy, must be given complete topology of the
entire world at startup.

We have had discussions of configuration and proposed filter types on
the moonshot-community list, but those are not implemented yet.
I don't know how much of that will  make its way into the internet
drafts.  We will probably need to specify minimum filter support that
implementations need to have in order to be able to have secure
topology.

--Sam

---

From: David Chadwick <[email-masked]>
Date: Thu, 16 May 2013 16:54:01 +0100

This is starting to make sense, but other issues also need to be 
addressed. So let us consider that a global network of trust routers 
already exists, that know how to talk to each other, and there is just 
one CoI currently defined, the global Internet, that allows all IDPs to 
talk to all RPs anywhere in the world.

1. Suppose I want to set up a mini CoI comprising just myself at Kent, 
you at painless, and Josh at Janet. I have a cloud document handling 
service that will act as the RP/SP and give you two access along with 
myself (say to write a new IETF draft). I want to call the CoI "New 
RFC". So I need to connect 3 existing IdPs together in this CoI. Here 
are the questions

i) who is the CoI administrator for New RFC? It should be me
ii) how are CoI's named to ensure global uniqueness? Should my CoI be 
named newRFC.kent.ac.uk?
iii) how would I get access to Kent's trust router to add a new CoI? Our 
computer admin staff typically do not give employees access to any 
computer config files e.g. I cant even add any attributes to my entry in 
Kent's LDAP server.
iv) Suppose our computer admin staff did allow new CoI's to be 
dynamically created by its employees. Why would any other trust router 
in the world believe Kent's TR, if it broadcast an admin message which 
said that Kent, Janet and Painless IDPs were now in a new CoI termed New 
RFC? (If it is named newRFC.kent.ac.uk then it could be believed)
v) Why should Painless's TR believe any random message it receives that 
says that its IDP is now part of a new CoI? The answer to this can only 
be if you have previously configured your TR with details about the New 
RFC CoI. Otherwise your TR is destined to believe any message it 
receives from anywhere about any CoI. And you could end up being 
co-opted into dozens of CoIs without any choice in the matter.

I think for these reasons at least, a fully worked out trust model is 
needed for your document

regards

David

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 May 2013 00:54:01 -0400

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

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.

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

It might be really bad for the COI admin to add Painless without for
example receiving a signed contract from Painless.  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.)

I do agree with you that we'll need a trust model as part of security
considerations for any protocol.

--Sam

---

From: David Chadwick <[email-masked]>
Date: Fri, 17 May 2013 08:36:30 +0100

Hi Sam

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

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

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

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

> 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
> if Painless has never agreed to those rules.)

What is an APC policy?

> considerations for any protocol.

then we should start to write it

regards

David

---

From: Josh Howlett <[email-masked]>
Date: Fri, 17 May 2013 10:28:33 +0000

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.

>capability, but on an Internet scale, and without needing to run a

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.

>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 

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.

>the IP level, but not at the federation level.

You would petition the CoI to include you.

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

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

>> if Painless has never agreed to those rules.)

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.

>then we should start to write it

Definitely, any contributions would be very welcome :-)

Josh.

---

From: David Chadwick <[email-masked]>
Date: Fri, 17 May 2013 12:20:59 +0100

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

---

From: Josh Howlett <[email-masked]>
Date: Fri, 17 May 2013 11:57:04 +0000

Hi David,

>Josh regards him as the COI administrator, in which case we are back on

I want to permit all three models, so we're definitely in agreement.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 May 2013 09:08:22 -0400

>>>>> "David" == David Chadwick <[email-masked]> 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.

    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.

    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.

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.

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.

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.

    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.

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

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.

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

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

non-technical measures such as law may give me recourse if I find your
statements objectionable rather than simply ridiculous.
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 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.

---

From: David Chadwick <[email-masked]>
Date: Fri, 17 May 2013 18:39:37 +0100

Hi Sam

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

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

> The base community is an APC (authentication policy community), not a

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?

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

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

> be janet-hosted or otherwise.  i think we agree that this is distinct

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

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

> I recommend that you think about it in terms of routes rather

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.

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

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

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

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

> I'd recommend than no SPs use your community if you're going to do that

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)

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

> 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 don't see why it needs to be the trust router rather than the IDP

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