Internet DRAFT - draft-howlett-abfab-trust-router-ps
draft-howlett-abfab-trust-router-ps
ABFAB J. Howlett
Internet-Draft R. Smith
Intended status: Informational Janet
Expires: September 12, 2013 M. Wasserman
Painless Security
March 11, 2013
Trust Requirements in a Federated World
draft-howlett-abfab-trust-router-ps-03
Abstract
TODO: This document outlines the requirements for trust in a
federated environment, and enumerates the requirements for a trust
infrastructure. It also examines existing trust infrastructures
given these requirements and concludes that none fulfil all of the
requirements, and suggests that maybe a new one is required that
does.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Howlett, et al. Expires September 12, 2013 [Page 1]
Internet-Draft Trust March 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. What is Trust? . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Communities of Trust . . . . . . . . . . . . . . . . . . . 5
3.3. Authentication Policy Communities vs Communities of
Interest . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Trust in a federated environment . . . . . . . . . . . . . 8
4. Trust requirements in a federated world . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. Identifying Partners . . . . . . . . . . . . . . . . . 9
4.1.2. Connecting to Partners . . . . . . . . . . . . . . . . 9
4.1.3. Clearly Delineate Registration from Usage . . . . . . 9
4.2. Specific Requirements . . . . . . . . . . . . . . . . . . 10
4.2.1. Many IdPs, Many RPs . . . . . . . . . . . . . . . . . 10
4.2.2. Frequent changes in Community Membership . . . . . . . 10
4.2.3. Costs incurred by community that benefits . . . . . . 10
4.2.4. Minimal Costs/Effort for forming new communities
of Interest . . . . . . . . . . . . . . . . . . . . . 11
4.2.5. Flexible Communities . . . . . . . . . . . . . . . . . 11
4.2.6. Flexible Trust Links . . . . . . . . . . . . . . . . . 11
4.2.7. Multi-Role participation . . . . . . . . . . . . . . . 12
4.2.8. Multi-Purpose communities . . . . . . . . . . . . . . 12
5. Analysis of existing Trust infrastructures . . . . . . . . . . 12
5.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. PGP style web of trust . . . . . . . . . . . . . . . . . . 12
5.3. SAML Metadata . . . . . . . . . . . . . . . . . . . . . . 12
5.4. FreeRADIUS shared secrets . . . . . . . . . . . . . . . . 13
5.5. Other Things? . . . . . . . . . . . . . . . . . . . . . . 13
6. The Future of Trust . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Howlett, et al. Expires September 12, 2013 [Page 2]
Internet-Draft Trust March 2013
1. Introduction
Trust is a concept whose exact definition differs depending on the
exact scenario in which it is being applied, however, there is a
large degree of commonality about the meaning across all contexts -
the idea of "trust" usually centres around two entities (be they
people, organisations, or whatever) establishing confidence and faith
in the reliability, truth, or abilities of each other.
In the world of federated technologies, trust typically means exactly
that: two federated entities being able to establish confidence in
each other. What this means more specifically is that two entities
are able to verify that each other is who they think they are (i.e.,
that it is not another entity pretending to be someone else), that
they represent the organisation they say they do (i.e. an entity
isn't misrepresenting themselves), and that transactions between the
two can be secure, unaltered, and verifiable.
This document examines the requirements of a trust infrastructure in
this context of the federated world. It then looks at existing trust
infrastructures, examining their pros and cons in relation to these
defined requirements. It then draws some conclusions about work
needed to bridge some missing gaps.
2. Terminology
This document uses existing terminology that the reader may not be
familiar with - and also introduces some new terminology - so a small
set of definitions is now included.
o Authentication Policy Community (APC): A set of entities that
share a common trust infrastructure and a common set of
identification requirements for the entities to be admitted to the
community.
o Community of Interest (CoI): A set of federation-capable entities
who want to interact with each other for a common purpose and with
a specific set of requirements.
o Entity: A general term for IdPs and RPs.
o Federation: An agreement between various entities that allows for
delegation of trust based a common set of semantics between an RP
and an IdP.
o Identity Provider (IdP): An entity that asserts identity
information about its principals to RPs.
Howlett, et al. Expires September 12, 2013 [Page 3]
Internet-Draft Trust March 2013
o Principal (or Client): An individual (i.e. a real world person) or
a computer that is registered with an IdP and is attempting to get
service from an RP.
o Relying Party (RP): (a.k.a. Service Provider (SP)) The federated
entity representing an organisation that consumes identity
information about a principal asserted by an IdP in order to
provide a service to that principal.
o Trust Arbitrator: A central point of trust infrastructure that
gathers and passes on crowd-sourced trust recommendations about
members of its APC. The entities within the APC provide trust
recommendations to the arbitrator: the arbitrator does not make
trust recommendations on its won. The entities in the APC trust
that the Trust Arbitrator will ensure that recommendations from
the APC membership are correctly reflected in the trust rating
presented.
o Trust Advisor: A central point of trust infrastructure who
entities rely on it to (make trust recommendations about other
entities and?) trust decisions about who is admitted to a CoR
based on a set of advertised criteria.
o Web of Trust: A mechanism for extending trust between two
different trust infrastructures where an agreement exists that
each of the trust infrastructures can use the judgment of the
other infrastructure to make its own trust decisions. A Web of
Trust can be transitively extended across multiple trust
infrastructure. In other words, you and all your friends become
my friends.
3. Trust
3.1. What is Trust?
Trust is a word and a concept that can mean many things depending on
the context in which it is being discussed, and can encompass a wide
range of requirements. For example:
o In personal relationships, trust between two friends is usually a
mutually established relationship where each can rely on the other
for confidentiality and their help in times of need.
o In airline travel, trust between a consumer and an airline
provider is largely a one way relationship where the trust of the
airline by the consumer means the consumer expects the airline to
keep their aircraft well maintained, to get them to their
destination alive and (roughly) on time, and to (try) not to lose
Howlett, et al. Expires September 12, 2013 [Page 4]
Internet-Draft Trust March 2013
their luggage.
o In e-commerce, trust between a consumer and a vendor is also
largely a one way relationship where the trust of a vendor by a
consumer means that the consumer considers the vendor to be likely
to provide good service, a reasonable price, and to fulfil their
order after it has been paid for.
Many such examples of trust exist in all walks of life and across
many contexts. Across most - if not all - of these, some
commonalities appear in the meaning of trust. Trust usually centres
around two entities being able to prove to each other who they are,
and then use that as a basis to transact in some form in a manner
that is confidential and secure. Indeed, the OED defines trust as
"Confidence in or reliance on some quality or attribute of a person
or thing, or the truth of a statement".
3.2. Communities of Trust
Trust, as defined above, is not something that just appears from
nowhere - it must be established somehow. The simplest way is, of
course, for two entities to build it bilaterally through a process of
slowly increasing the level of trust in each other through a series
of transactions over time. This process can be expedited, however,
through one of three commonly employed methods:
1. Trust can be established transitively through commonly trusted
3rd parties who have previously built up a level of trust with
each other (i.e. a web of trust, such as is seen in the PGP web
of trust)
2. Trust can be bootstrapped indirectly by a Trust Arbitrator - an
entity that is trusted by all who make use of it to appropriately
manage community provided reviews of trust (e.g., recommender
systems such as eBay member ratings)
3. Trust can be bootstrapped directly by a Trust Advisor - an entity
that is trusted by all who make use of it to appropriately manage
directly established trust relationships between it and its
community members (e.g., X509 Certificate Authorities).
In practice, each of these mechanisms can be, and are, used in
different contexts. They are typically deployed on a per-community
basis, such as the eBay community, a research and education SAML
federation, PGP users, web site deployers, etc. - because in a world
of billions of people and many millions of organisations, each of
whom is a member of many communities, finding a single entity, or a
small number of entities, that are commonly trusted by all to be a
Howlett, et al. Expires September 12, 2013 [Page 5]
Internet-Draft Trust March 2013
Trust Arbitrator or a Trust Advisor is simply impossible. So, as a
way of tackling this scaling issue, "Communities of Trust" have
organically appeared in all three guises of expedited trust
establishment: sometimes in a decentralised way (e.g. PGP key
management through a web of trust), sometimes arbitrated by a Trust
Arbitrator (e.g. Trust management between sellers and buyers on
eBay), and sometimes by a Trust Advisor (e.g. X509 CAs, Twitter
"verified accounts", SAML federation metadata managed by the
federation operators, etc).
Within the world of computing, Trust Advisors are a typical way of
establishing trust, as it is essentially a method for people or
organisations to outsource the problem of trust establishment.
However, to achieve this, someone or something needs to set up and
manage the Trust Advisor, and users of it typically need to pay for
the service. Consequently, this method of solving the trust
establishment problem is largely used in business to business and
business to consumer communities. However, for those communities
where no financial transactions are involved, this method of trust
establishment is less appropriate as the community members do not
always want to - or are unable to - pay for the service.
Trust Arbitrators are less commonly seen, and are usually found where
a Trust Arbitrator stands to make financial gain through the use of
its services - either directly (e.g. members pay for its trust
recommendations) or indirectly (e.g. a chargeable service having more
members because of the increased trust these members can have in each
other). Again, this method may not be appropriate for those
communities where financial transactions are not involved.
The Web of Trust method of establishing trust is least seen of the
three methods, since while it is decentralised and appropriate for
any type of community, including those where no financial
transactions are taking place - transitive trust can be built up in a
way without paying for it - it is the hardest and most time consuming
way of establishing trust.
3.3. Authentication Policy Communities vs Communities of Interest
In those scenarios where Trust Arbitrators or Trust Advisors are the
methods of bootstrapping trust, two separate communities actually
exist. However, the two are often conflated as they are typically
equal, by accident of design. These two communities are:
o The Authentication Policy Communities: the set of entities who are
known to a trust infrastructure and for which the trust
infrastructure has a notion of trustworthiness.
Howlett, et al. Expires September 12, 2013 [Page 6]
Internet-Draft Trust March 2013
o The Community of Interest: the set of entities who want to
interact with each for some particular purpose (e.g. to do B2C to
B2B transactions, to collaborate as part of a cross-organisational
project, to communicate securely, etc).
These two types of communities are often conflated because of the
lack of Trust Arbitrators or Trust Advisors that span multiple
communities of interest. This results in each community of interest
using a single (or small amount of) Trust Arbitrators or Trust
Advisors, thus the Authentication Policy Communities and Community of
Interest are one and the same.
In the real world, however, there are many cases where communities of
interest want to span multiple Authentication Policy Communities.
For example, SAML entities in the education sector who are part of
different Authentication Policy Communities (i.e. SAML Federations)
that are often geographically split (each country typically runs its
own SAML federation) often desire to communicate; [TODO other
examples].
When entities from different communities of interest want to transact
in this way, trust has to be established across communities. This
can achieved in one of three ways:
1. Entities can join multiple communities, if the technology allows
this.
2. A Trust Bridge can be set up between Trust Arbitrators/Advisors
to allow entities from different Authentication Policy
Communities to communicate.
3. A Trust Arbitrators/Advisors can attempt to become the arbiter of
trust for multiple communities.
The first of these options is a rather inelegant way of solving the
problem, and will likely involve significant organisational effort
per community the entity joins, and is therefore not a particularly
scalable solution, and is therefore only a workable workaround in
limited circumstances.
The second option scales much better but requires significant effort
by the Trust Arbitrators/Advisors in ensuring that their rules of
registration are compatible.
The third option has significant drawbacks, however - either the
Trust Arbitrators/Advisors has to relax its rules so much to be
inclusive for a range of communities of interest that it becomes very
limited in the assurances it can offer, or it has to impose a set of
Howlett, et al. Expires September 12, 2013 [Page 7]
Internet-Draft Trust March 2013
standards that many entities will not be willing to opt into due to
the high costs it imposes on them to meet these standards.
3.4. Trust in a federated environment
Given the general view of trust presented above, what does trust look
like more specifically in the federated world?
In a federated world, there are a few types of entities and trust
relationships, to whom trust each means slightly different things.
There is:
o Principal to IdP, IdP to principal. Trust here is mostly
organisational around an existing relationship between principal
and their IdP. The principal trusts the IdP to control its data
properly and to assert correct information about them. The IdP
trusts the principal to keep their credentials confidential so
that the IdP can authenticate the principal when required.
o Principal to RPs, RPs to principal. Trust here mostly flows
through guarantees between the principals and its IdP, and that
IdP and the RP, that allow the user to gain access to services
offered by the RP.
o IdP to RP. Trust here centres on the IdP and RP being able to
verify each other's identities, and often associate that
identification with an existing business relationship between the
organizations.
So in a federated world, there are actually two types of trust in
play. Firstly, there is technical trust (i.e., is the server I'm
talking to really the one I think it is, and are all communications
secured?); and secondly there is organisational or behavioural trust
(i.e., the trust that allows two entities to know for sure that that
the other entity represents a particular organisation that they have
a business relationship with, what guarantees are in place with each
other about their relationship, etc).
The second of these is a real world problem to be addressed and not a
technological issue and thus needs to be solved out of band. It
might, of course, have technical components to it (e.g. schema
definitions so the two understand the semantics of the data
transferred back and forth), but those would be part of the out of
band negotiation.
The first, however, is at the core of federation. The next section
looks in more detail at what federation needs from a trust framework
to properly establish technical trust.
Howlett, et al. Expires September 12, 2013 [Page 8]
Internet-Draft Trust March 2013
4. Trust requirements in a federated world
The requirements of technical trust in a federated world largely
centre on entities being able to verify each others identity and
establish secure communications channels to allow for signing,
encryption, etc. To achieve this, various properties of the trust
infrastructure are required. Some of these requirements are
absolutely critical, while some are optional requirements to help
with scale. These are detailed next.
4.1. General Requirements
First of all, we will look at the main general requirements.
4.1.1. Identifying Partners
In most cases, it is necessary for organisations to have confidence
that the configuration that they have for their partners actually
corresponds to their partners and is not, for example, an attacker
claiming to be their partner. This is largely an issue of vetting
the claimed identity of organisations when they join a community.
An additional requirement here is that organisations need to minimise
the cost of validating their partners' identities, and of proving
their own identity to their partners.
4.1.2. Connecting to Partners
This is probably the most obvious requirement. Organisations must be
able to establish trust with each other through configuration, i.e.,
servers representing a particular organisation must be configured to
be able to connect to servers representing partners of that
organisation in a secure verifiable manner.
To be able to connect, the configuration must include such things as
specifying the protocols to be used and the cryptographic operations
to be used.
Additionally, to be able to effectively connect to partners,
organisations must have effective tools for managing policies that
control the flow of information between the two partners.
4.1.3. Clearly Delineate Registration from Usage
As detailed earlier, the conflation of Authentication Policy
Communities vs Comunities of Interest hinders progress of large scale
adoption of federation and transitive trust establishment.
Conceptually splitting those two out gives many advantages, not the
Howlett, et al. Expires September 12, 2013 [Page 9]
Internet-Draft Trust March 2013
least of which is the possibility of being able to better support
communities of interest that span multiple Authentication Policy
Communities. Authentication Policy Communities will provide the
technical trust, while Communities of Interest overlain upon one or
more Authentication Policy Communities can provide the behavioural
trust.
4.2. Specific Requirements
Alongside the general requirements presented above, there are some
more specific requirements. These are discussed next.
4.2.1. Many IdPs, Many RPs
Entities must be able to establish trust with an arbitrary number of
partners - scale should not be an issue.
4.2.2. Frequent changes in Community Membership
It must be possible to support changes in membership (adding new
partners, removing former partners, or changing the configuration of
partners) with minimal operational effort, and without requiring
manual configuration changes that could result in new partners having
delayed or incomplete access to services, or former partners
retaining some access to services beyond the end of their membership.
Additionally, organisations want to minimise the cost of managing
these frequent changes - there should be no requirement for
credential exchange between a large number of parties, no manual
configuration changes on a large number of systems, etc.
This is a requirement for both Authentication Policy Communities and
Communities of Interest, though the scale of changes is likely to be
different in the two.
4.2.3. Costs incurred by community that benefits
Typically in federation, the operational cost related to adding and
removing partners is born by the RPs, who need to maintain bilateral
credentials for each IdP whose users can access the services provided
by the RP. This is fine in a case where a single RP provides
services to a group of IdPs that pay for membership in the community,
or pay for access to specific services.
However, in a less-centralised partnership the costs of exchanging
credentials with each IdP could serve as a disincentive for
organisations to provide services to the community and/or result in
cases where an RP is unwilling or unable to incur the costs of
Howlett, et al. Expires September 12, 2013 [Page 10]
Internet-Draft Trust March 2013
providing access to new partners. Therefore, if a trust framework
supported a mechanism where the operational costs are distributed to
the organisations that are receiving benefit from incurring the
costs, it would help drive adoption and usage.
4.2.4. Minimal Costs/Effort for forming new communities of Interest
To expand the use of federated services, it should be possible for a
group of potential partners to form a new Community of Interest with
minimal infrastructure and the lowest possible operational expense.
In order to minimise start-up costs, it should be possible to
leverage existing shared credentials and use those credentials for a
new Community of Interest.
Practically, this resolves to two problems:
o It must be possible to create a new Community of Interest that
uses credentials from one or more existing Authentication Policy
Communities.
o It must be possible for a partner to join multiple Communities of
Interest using a shared Authentication Policy Community, and for
different entities (such as users or servers) within a partner to
participate in different Communities of Interest. Practically,
this means that information about the Community of Interest in use
needs to be transmitted to an IdP, so it can be used as part the
authentication process.
4.2.5. Flexible Communities
It should be possible for Communities of Interest to grow to
encompass more partners, partners in different regions of the world,
or partners who have different Authentication Policy Communities
available to them.
It must, therefore, be possible for a single Community of Interest to
be serviced by multiple Authentication Policy Communities. While it
might be necessary for any given RP/IdP pair to share at least one
Authentication Policy Community, it should not be necessary for all
of the partners within a given Community of Interest to share a
single Authentication Policy Community.
4.2.6. Flexible Trust Links
Related to the above, it should be possible for Communities of
Interest that span multiple Authentication Policy Communities to be
able to support that transitive establishment of trust over these no
Howlett, et al. Expires September 12, 2013 [Page 11]
Internet-Draft Trust March 2013
matter what technology is used for trust establishment in each
Authentication Policy Communities. This will help increase the
flexibility of communities.
4.2.7. Multi-Role participation
It must be possible for a single partner to participate as both an RP
and an IdP within a single community (either a Community of Interest
or a Authentication Policy Communities).
4.2.8. Multi-Purpose communities
It must be possible for a particular Community of Interest to be
equivalent in membership and configuration as an Authentication
Policy Community. A use case for this requirement would be an
Authentication Policy Community that provides services to its own
customers, perhaps for maintenance of their own Authentication Policy
Community membership.
5. Analysis of existing Trust infrastructures
TODO: Intro to this section. N.B. Much more detail needed, should be
a decent amount of analysis. Not a huge amount though - severa paras
per tech, perhaps.
5.1. PKIX
TODO: A trust advisor (or small set of trust advisors) in the form of
heirarchically signed X509 certs. Only Authentication Policy
Communities, not CoI. Costs incurred by the service, not the user.
Works well but only when governance and management is done properly.
Which it isn't, generally. Can devolve trust establishment a bit
with intermediate certs.
TODO: Not particularly suitable to federation in the real world as
existing X509 heirarchies are usually not run well enough, and
running one well enough is a significant cost.
5.2. PGP style web of trust
TODO: Web of trust style trust establishment, obviously. Works well
but not massively deployed because of the technology understanding
required of users to sign each others keys and whatnot.
5.3. SAML Metadata
TODO: Can use PKIX, or directly established public/private keys
through metadata, to establish trust. In the former case, all of
Howlett, et al. Expires September 12, 2013 [Page 12]
Internet-Draft Trust March 2013
PKIX drawbacks. In the latter, needs a trust advisor controlling the
SAML metadata. Usually conflates APC with CoI (though entity
categories allow for CoI in a very limited sense). Doesn't scale
well because of it! Interfederation as a point solution to scaling
having to be designed.
5.4. FreeRADIUS shared secrets
TODO:
5.5. Other Things?
TODO:
6. The Future of Trust
TODO: Trust is something that needs engineering - trust frameworks
and systems are needed that fulfil all of the requirements stated if
we want a way of establishing trust between two artibrary federation
entities that cross arbitrarily large and diverse communities, and in
a way that empowers the actual users of the systems to make best use
of it all. No particular solution fulfils all of the requirements
above that are necessary for wide adoption of federation in a way
that is easy and cost effective for the communities using it. Any
new solution should consider all of these needs.
7. Acknowledgements
TODO: The document authors would like to thanks Jim Schaad and Klaas
Wierenga for providing review.
8. Security Considerations
TODO.
9. Privacy Considerations
TODO.
10. IANA Considerations
This document does not require actions by IANA.
11. References
Howlett, et al. Expires September 12, 2013 [Page 13]
Internet-Draft Trust March 2013
11.1. Normative References
[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J.,
Hirsch, F., Mishra, P., Philpott, R.,
and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language
(SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os,
March 2005.
11.2. Informative References
Authors' Addresses
Josh Howlett
Janet
Lumen House
Library Avenue
Harwell Oxford
Didcot OX11 0SG
United Kingdom
EMail: josh.howlett@ja.net
Dr. Rhys Smith
Janet
Lumen House
Library Avenue
Harwell Oxford
Didcot OX11 0SG
United Kingdom
EMail: rhys.smith@ja.net
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: ++1 781 405 7464
EMail: mrw@painless-security.com
Howlett, et al. Expires September 12, 2013 [Page 14]
