| ABFAB | J. Howlett |
| Internet-Draft | R. Smith |
| Intended status: Informational | Janet |
| Expires: October 13, 2013 | M. Wasserman |
| Painless Security | |
| April 11, 2013 |
Trust Requirements in a Federated World
draft-howlett-abfab-trust-router-ps-03
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.
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 October 13, 2013.
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 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.
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.
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.
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:
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".
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:
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 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.
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:
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:
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 standards that many entities will not be willing to opt into due to the high costs it imposes on them to meet these standards.
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:
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.
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.
First of all, we will look at the main general requirements.
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.
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.
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 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.
Alongside the general requirements presented above, there are some more specific requirements. These are discussed next.
Entities must be able to establish trust with an arbitrary number of partners - scale should not be an issue.
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.
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 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.
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:
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.
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 matter what technology is used for trust establishment in each Authentication Policy Communities. This will help increase the flexibility of communities.
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).
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.
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.
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.
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.
TODO: Can use PKIX, or directly established public/private keys through metadata, to establish trust. In the former case, all of 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.
TODO:
TODO:
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.
TODO: The document authors would like to thanks Jim Schaad and Klaas Wierenga for providing review.
TODO.
TODO.
This document does not require actions by IANA.
| [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. |