Trust Router

Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: The IETF plenary session The IESG, or any member thereof on behalf of the IESG Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices Any IETF working group or portion thereof Any Birds of a Feather (BOF) session The IAB or any member thereof on behalf of the IAB The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

Agenda The Problem Trust Router – The Solution

Trust Router – The Problem

What is trust? (in general) Two entities (people/organisations/etc) have confidence and faith in: – Reliability – Truth – Abilities …of each other

Three models of technical trust establishment Web of trust – Transitive establishment with bilateral links E.g. PGP web of trust Using a Trust Arbitrator – Arbitrates community-provided trust information E.g. eBay Using a Trust Advisor – Establishes trust information directly E.g. X509 CAs

What is trust? (in federation) Two entities (IdPs/RPs) can: – Verify each other’s identity – Verify the entity represents a particular partner – Communicate securely – Have certain guarantees about behaviour (e.g. user registration practices)

Two types of trust (in federation) Technical Trust – Is that the server I think it is? – Are comms secured? Behavioral Trust – Does this server represent a particular organisation? – What guarantees are in place? (e.g. LoA)

Federation - Two Types of Communities Collection of organisations “registered” by a particular Trust Advisor/Arbitrator (“Authentication Policy Community”) Vs Community of organisations that want to interact for some purpose (“Community of Interest”)

Conflation of Communities These two are often conflated because trust communities are usually set up with: – A specific purpose – And a specific “registrar” (Advisor/Arbitrator) So – The communities are the same (have the same membership).

This is a problem Where Communities of Interest want to span multiple “Registrars” (APCs) – E.g. research groups spread across SAML federations Where different Communities of Interest want to have different requirements about behavioural trust – E.g. everyone!

Current Solutions Entities join multiple communities. – Lots of effort per organisation - doesn’t scale Trust Bridges between APCs – Lots of effort in ensuring rules of registration are compatible – doesn’t scale well Trust Arbitrators/Advisors manage trust for multiple communites – Either relaxes rules so much that assurances are worth very little, or – Creates standards too high for some communities

In a nutshell Federations need – Good scaling – Flexibility That doesn’t really exist yet.

What do we need? Trust brokering that – Separates “registration” from “use” – Allows “use” to natively be a part of the trust brokering but not be the same as “registration” – Allowing federations to scale massively with: Minimal work for organisations involved new communities to be created easily and cheaply

More specifically (See draft for full list of demands^W requirements) draft-howlett-abfab-trust-router-ps-03

General requirements Identifying Partners – Must allow entities to have confidence in the identity of the entity they’re communicating with – (vetting of organisation)

General requirements Connecting to Partners – Must be able to establish technical trust between entities – Must enable policy to control flow of information

General requirements Delineate Registration from Usage – APC(s) provide technical trust – CoIs overlain on top of APC(s) with behavioural trust

Specific Requirements Many entities – scaling Frequent changes in membership Flexibility about incurred costs Easy/cheap to form new communities Flexibility of communities Multi-Role entities Multi-purpose communities (APC = or != CoI)