In this message I'm using terminology that a lot of you may not have
seen yet.  If you have been following all the Moonshot meetings you
might be able to guess what it means.  However given some internal
disconnects between Margaret, Josh and myself, this message may be a bit
easier to re-read after the document defining this terminology comes
out in a few days.


                       Trust Links and Filtering

The integrity of information carried in trust links is critical to the
overall security of the Moonshot system. When a trust router accepts a
trust link into its database  from a peer, it trusts that peer to
provide communication with the entity and to correctly map the name to
the right entity. Integrity of the trust links depends on the
correctness of the data and the correct operation of trust routers along
a trust path. In accepting a trust link, a trust router is choosing to
trust the correctness of the information contained in the link and trust
the correct operation of the peer with regard to resources reached over
that link.

As a result, filtering is going to be critical  at many layers of the
system. It's possible that  an end-site that receives trust router
service from one or two service providers will have no or very
permissive filters on the peerings with those service providers.

However, service providers MUST strictly filter routes they
accept. Typically a service provider will expect a limited set of realms
to be announced over a given peering and will accept only those
announcements. Typically a service provider will have a specific set of
COIs that are accepted with any given announcement and will only permit
those COIs. 

Filtering for COIs can be particularly challenging. If a COI's policy is
not set by the service provider then the service provider MAY NOT have
necessary information to set up appropriate filtering. In this case the
service provider SHOULD peer with a trust router that is authoritative
for the COI and accept routes for the COI only from this peer. As a
consequence, organizations wishing to announce routes into the routing
database for the COI would need to peer with the organization running
the COI. Such peerings SHOULD have strict filters on both sides. The
organization running the COI SHOULD accept only routes towards realms
known to be in the COI and SHOULD only accept the COI for these
announcements. The organization making the announcement SHOULD only
accept routes pertaining to the COI over this peering.

A trust router MUST support filtering the set of COIs associated with a
trust link as that link is accepted in order to facilitate these
deployments. Also, filtering the set of realms and realm/COI
combinations is required. Trust routers will probably also need to
support mapping COIs as links are accepted and flooded.

                             COI Referrals

One value of Moonshot is making it easy to establish a new COI. So, the
system needs to support a large number of COIs. As a consequence,
security risks if untrustworthy routes are injected for one COI need to
be managed. Security concerns with one COI should not adversely affect
the overall security of the system or the security of other COIs.

Users do not typically know which COI is in use for a given
authentication. Even if users could be reliably informed about the COI,
users are unlikely to be able to make informed decisions about the level
of trust to place in routing information received from a COI. However,
the consequences of introducing a malicious trust path for the user's
IDP realm into the COI used for authentication are quite serious. In
this case the attacker can observe the authentication
exchange and resulting session keys. That can be sufficient to mount a
phishing attack. More seriously, this can complicate EAP channel binding
which is critical to permitting users to confirm they have connected to
the correct server.

However, the primary purpose of COIs is to collect a group of related
IDPs and RPs and to describe attributes of these entities. Being
involved in the authentication path is not important to this purpose.

Instead we propose that there be a new type of entity ("c") for
community referral. This entity type includes a valid_cors attribute
containing a list of communities.
The semantics are that any authentication needs to be resolved against
one of these communities.

The trust path query server has a valid_cors attribute which is a list
of communities. If the trust path query server is responding to a trust
path query for one of these communities then it simply forwards a Trust
Path Forwarding Request. Otherwise, it looks up a trust path in the
community for the realm in question. It only considers Trust Paths
ending in "c" entity types. If any of these include a community in the
valid_cors list, and if a trust path in that new community exists to the
target realm, then the Trust Path forwarding Request is generated in
that new community.