Update on federations, PKI, and federated PKI for US feds and higher eds

1. Update on federations, PKI, and federated PKI for US feds and higher eds Tom Barton University of Chicago

2. E-Authentication • Problem: design an authentication service supporting access to applications at dozens of huge US Federal agencies by US citizens and others • Solution: use federated identities • Many identity providers (IdPs) • Common federating technologies • Trust built through risk assessment, conformance testing, & audit processes

3. Federating with E-Auth • Two adopted authentication schemes • SAML 1.0 artifact profile • Bridged PKI • through FBCA – Federal Bridge Certificate Authority • E-Authentication Interoperability Lab does conformance testing • Shibboleth v1.2 is conformant federating product, and only privacy preserving one • Growing list of commercial SAML implementations are now also certified

4. E-Auth LoAs • NIST defined 4 levels of authentication assurance to be used by US Feds • LoA 1 - rudimentary • LoA 2 - basic • LoA 3 - medium • LoA 4 – high • risk assessment tool to know what LoA you need • All available for PKI authentication • Only LoA 1 and 2 available for SAML authentication

5. So who are or will be the Identity Providers (IdPs)? • US Federal agencies or their authentication service contractors (using PKI bridged with the FBCA) • Large public IdPs like AOL, MSN, … • AOL in process at LoA 1 (LoA 2 might be value-add) • Universities • University of Washington, Cornell, Penn State in process • Banks • Fidelity Bank already, several others underway

6. E-Auth IdP wannabees • CAF – Credential Assessment Framework • Auditing standards for identity proofing and IdMS operations of an IdP • PIN, password, & PKI profiles • You must be CAFed to be an E-Auth IdP • University CAF experiences • Early reports are that the GAO auditors doing the CAF audit are reasonable and accepting of identity proofing and IdMS operations at Universities • But will they be certified for LoA 2?

7. Early E-Auth applications • Grant submission • NSF, NIH • Agricultural permits • 30 US Federal agencies are required to each put up at least one application by end of 2005 • Maybe just the Department of the Interior blog, we’ll see

8. Inter-federation issues:NSF’s FastLane as example • How will National Science Foundation’s FastLane application (online grant proposal submission) trust a SAML authentication assertion from University of Washington? • Will FastLane need any attributes about the proposal submitter in addition to their IdP’s LoA? • Currently hold an appropriate role at the submitting institution? • How to agree on schema, semantics, and bindings?

9. E-Auth Federation • Present model: eGovernance Certification Authority (eGCA) defines a single SAML federation • Two CAs issue AA certs to IdPs following CAF assessment. One for LoA 1, the other for LoA 2 • Another CA issues certs to Applications (SP’s) • Shortcomings • Potential scaling issue • Attribute assertions aren’t used yet – at present it’s only about LoA for authentication • Muse about an inter-federation future …

10. Bridged PKI to support inter-federations? (ala Gettes)

11. Extending federation model to digitally signed documents • Proposed Phase 5 of PKI Interoperability Project • Demonstrate academic transcript delivery between InCommon members • Demonstrate InCommon member filing a report to a Federal Agency • Issues to be examined & resolved • Digital signatures in federation and inter-federation contexts • Attributes about the document attached to the document

12. Federated document preparation • Document routed intra-campus with local workflow, referencing local roles, using digital signatures local to campus PKI • Strip all local stuff • Sign doc using key verifiable by federation (“enterprise signature”) • Attach XML attribute blob (roles, digital rights & IP, archival status, whatever) to doc signed with enterprise signature • Sign combination to ensure integrity using enterprise signature

13. Federated PKI for signed documents • Signing certs (“enterprise signature”) issued not to servers, not to end users, but to federation member organizations • Standardized roles (to be determined) expressed as attributes attached to the federation document. • Registrar • Purchasing Officer • … ?? • Desirability of inserting 3rd party “testamonial” artifact?? • Example: “American Council on Education attests that this signature belongs to the Registrar of an accredited university in good standing”

14. HEBCA, USHER, FBCA, and InCommon in trust perspective USHER

15. US higher ed PKI and InCommon update • USHER (US Higher Ed Root) • Internet2’s replacement for CREN CA, operated by Dartmouth • Starts up in May 2005 • Policy Authority is InCommon Steering Committee • Cert revocation service is … still jelling • Will cross certify with HEBCA (Higher Ed Bridge CA) • InCommon CA • Operated by Internet2, for now • Same identity proofing framework as USHER (enhanced CREN) • Same one-time & continuing fee as USHER • Will either be signed by USHER or itself cross certify with HEBCA

16. US higher ed PKI and InCommon update • HEBCA • Operated by Dartmouth • Production status June 2005?? • InCommon • Open for business • 12 members so far, including Elsevier & OCLC • Scott Rea’s October 2004 DigitalIDWorld slides http://conference.digitalidworld.com/2004/attendees/slides/1028_1000_E2.pdf

17. Discussion • Are there potential use cases to motivate cross certification of some European CAs with HEBCA? Which CAs? • TACAR+EUGridPMA contrast with bridge CA approach. Would a bridge provide better or worse support for expanding authentication to EU grids? • Nothing TACAR-like in US. Should there be? Should TACAR go there?