That Ol’ STP Stuff: (Security, Trust, Privacy)

1. That Ol’ STP Stuff: (Security, Trust, Privacy) Kenneth J. Klingenstein and Mark A. Luker

2. Topics Shibboleth • Shib in the News • Substance – Shib Basics – Comparisons to WS-Fed and Liberty; likely outcomes Federations, InCommon, etc USHER and some PKI initiatives Other Security, Privacy, Trust stuff What’s important • Leverage • Integration • Understanding the new privacy • P2P trust

3. Unified field theory of Trust Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc. • Passports, drivers licenses • Future is typically PKI oriented Federated enterprise-based; leverages one’s security domain; often role-based • Enterprise does authentication and attributes • Federations of enterprises exchange assertions (identity and attributes Peer to peer trust; ad hoc, small locus personal trust • A large part of our non-networked lives • New technology approaches to bring this into the electronic world. • Distinguishing P2P apps arch from P2P trust Virtual organizations cross-stitch across one of the above

4. The Udell column 7/23/04  http://www.infoworld.com/article/04/07/23/30OPstrategic_1.html  COLUMN Strategic Developer Federating identity Web sites ask for too much information. Instead, federated sites should share just enough By Jon Udell July 23, 2004 In last week’s column, I suggested that individuals and corporations should be the authoritative sources of basic information about themselves. That way, if an application needs my name, address, and phone number, I can refer it to a source that I control and guarantee to be correct. But how many applications really need my name, address, and phone number? Capturing the identity of individuals, along with personal information about them, has become a habit. In a climate of increasing concern about privacy, it’s a bad habit we must learn to resist.

5. Udell, continued Consider a transaction at a liquor store. To prove your age, you present your driver’s license — the all-purpose credential. The card displays two items the clerk requires: your picture (biometric proof of identity) and your birth date (proof of age). It also displays facts that the clerk doesn’t need to know: your name and address. A printed card can’t selectively disclose only the required facts. But an electronic identity token can. Last week, at a PKI summit hosted by Dartmouth College, I heard quite a lot about Shibboleth, an approach to federation of identity that’s rooted in the idea of selective disclosure. Little- known in the commercial world, Shibboleth — a project of the Internet2 consortium’s Middleware Architecture Committee for Education — is gaining real traction in the realm of higher education. The most widely publicized deployment enables students at Penn State University to use their home credentials to log in to Napster.

6. Udell, continued Shibboleth’s protocols overlap in many respects with those of the Liberty Alliance Project. … And in the latest round of specs, Liberty moves closer to the Shibboleth philosophy that users should control the release of their attributes. How do they differ, then? The Shibboleth model is simpler because access to resources is granted by institutional role, not by individual identity. …. It’s true that we often need to establish individual identity. But beyond cross-university resource sharing, there are plenty of cases where role-based access, certified by a remote authority, will suffice. Look for them, because the best way to sidestep liability for collecting too much information is to avoid capturing it in the first place.

7. Global Justice Information Sharing Initiative Security Architecture Committee (SAC) August 18, 2004  8:30 a.m. – 8:45 a.m. Introductions, Welcoming Remarks, and Recap From Last Meeting Gerry Coleman Chair  8:45 a.m. – 9:00 a.m. The National Criminal Intelligence Sharing Plan Update Chief Daniel Oates Global Intelligence Working Group’s (GIWG) Connectivity/Systems Committee Chairman  9:00 a.m. – 9:30 a.m. E-Authentication Terminology Briefing John WandeltGeorgia Tech Research Institute  9:30 a.m. – 10:00 a.m .Discussion Topic: sharing systems already in place. What is “architecture” in these real-life examples? Do different implementations share a common architecture?  Group Discussion 10:00 a.m. – 11:00 a.m. Burton Group Briefing Dan Blum Research Director, Burton Group Doug Moench Senior Consultant, Burton Group  11:00 a.m. – 12:00 Noon Shibboleth and OpenSAML Briefing Scott Cantor Ohio State University  12:00 Noon – 1:00 p.m. “Question and Answer” Working Lunch Scott Cantor and Burton Group There are intelligence information

8. PESC Assembly on the State of E-Authentication 8/20/04 Topics to be discussed include: · Federal Government to e-Authentication · Electronic Authentication Partnership · Shibboleth · Liberty Alliance · Transitive Trust · Project Meteor · SAML and OpenSAML · PKI, Digital Certificates and NSC Services

9. PESC State of e-Authentication in Higher Education Assembly In continuing its focus on standardizing student authentication, the Postsecondary Electronic Standards Council (PESC) is pleased to announce its Assembly on the State of e-Authentication in Higher Education. In hosting this Assembly on e-Authentication, PESC is bringing together various leaders and experts within the higher education and technology communities. Over the coming year, higher education institutions, service providers, systems vendors, state and federal agencies, and all supporting suppliers to higher education will be making serious investments and commitments to online services. With the number of emerging technologies, standards, specifications, and frameworks, PESC is looking to ensure that information is shared and communicated so that decision makers have solid, reliable information on which to make informed decisions. Speakers for the State of e-Authentication in Higher Education include: – David Temoshok – Director of Identity Policy and Management, U.S. General Services Administration – who will provide an update on the various federal government activities and initiatives related to e-Authentication. As Mr. Temoshok is Co-Chair of the Electronic Authentication Partnership (EAP), he will also provide an overview and update on activities related to the EAP. - David Yakimaschak – Chief Technology Officer, JSTOR – who will discuss the general state of authentication and JSTOR's implementation of various authentication protocols, and introduce attendees to the newly formed federation called InCommon. – Howard Gilbert – Senior Research Programmer, Yale University – who will discuss portal authentication issues, activities, and authentication implementation at Yale University. – Robert Morley – Associate Registrar, University of Southern California, and Board of Directors member of both AACRAO and PESC – who will discuss authentication from the admissions and registrar perspective. – Scott Cantor – Senior Systems Developer, Ohio State University and Shibboleth Architect and Core Developer, Internet2 – who will discuss SAML and communicate the future roadmap for Shibboleth including: relationships between various projects, how they might evolve over the next 12-24 months, and the interoperability and/or certification work that Shibboleth will be initiating in order to raise the level of interoperability. – Adele Marsh – Vice President, E-Commerce Initiatives, AES – who will update attendees on the Meteor Network, the standards and processes it uses, and discuss the future enhancements to Meteor. – Mark Jones – Vice President, Marketing and Business Development, National Student Clearinghouse – who will address high level business issues related to PKI and some of the specific challenges for higher education. – Bernie Gleason – Executive Consultant, IBM – who will discuss the weakest portion of authentication security -- password security and poor user practices -- and explore ideas how to transition stronger authentication practices for all customers and all interactions across the entire institution. Included will be a look at the way in which security tokens and biometrics may be deployed in the future. The Assembly on the State of e-Authentication in Higher Education is being held in partnership with the US Department of Education’s Office of Federal Student Aid (FSA).           

10. Eduserve News July 2004 Interoperability the catchword! Eduserv Athens has confirmed its plans to develop full interoperability between its existing Athens services - one of the largest federated access management systems in the world - and Shibboleth origins and targets. In addition, Eduserv reiterates its commitment to common standards and to the development of Athens in compliance with new standards and future user needs. Eduserv CTO Ed Zedlewski commented, "We think the Shibboleth architecture is likely to become the international standard for academia, and therefore we will be offering an access management service, both in the UK and beyond, incorporating that architecture".

11. Federal government Federal E-Authentication has a number of pilots under way. One of them is now Shib.  Phase 1 and Phase 2 efforts funded, with deliverables due over the next six months Potential phase 3 and 4 would include working on a federal federation and peering with Higher Ed and other federations.

12. Phase 1 and 2 Deliverables Phase 1 Deliverables  Analysis Doc on SAML profiles and futures for e-Auth and Shib  Analysis Doc comparing InCommon and e-Auth concepts, terminology, etc.  Proof of concept demonstration of a Shibboleth federation inter-operating with the E-Authentication architecture Phase 2 Deliverables  A document that identifies how the Shibboleth demonstration was set up, including lessons learned  A white paper providing recommendations to both the E-Authentication PMO and U.S. Higher Education Shibboleth federations on continued policy convergence between the communities based on the findings of this pilot

13. OK, I redirect your request now to Please tell me where are you from? Shibboleth AA Process the Handle Service of your home org. I don’t know you. Not even which home org you are from. I redirect your request to the WAYF WAYF I don’t know you. Please authenticate Using WEBLOGIN 2 3 4 5 6 1 Users Home Org Resource Owner 7 Credentials HS SHIRE 8 Handle Resource Resource Manager Handle User DB 9 Handle AA SHAR OK, I know you now. I redirect your request to the target, together with a handle Attributes 10 Attributes I don’t know the attributes of this user. Let’s ask the Attribute Authority Let’s pass over the attributes the user has allowed me to release OK, based on the attributes, I grant access to the resource

14. Shibboleth Architecture

15. Shibboleth Architecture -- Managing Trust Federation Attribute Server Shib engine Target Web Server Browser Target Site Origin Site

16. Milestones  Project formation - Feb 2000 Stone Soup  Process - began late summer 2000 with bi-weekly calls to develop scenario, requirements and architecture.  Linkages to SAML established Dec 2000  Architecture and protocol completion - Aug 2001  Design - Oct 2001  Coding began - Nov 2001  Alpha-1 release – April 24, 2002  OpenSAML release – July 15, 2002  v1.0 April 2003  v1.1 July 2003  V1.2 April 2004  V2.0 likely end of the major evolution

17. Shibboleth Status Open source, privacy preserving federating software Being very widely deployed in US and international universities Target - works with Apache(1.3 and 2.0) and IIS targets; Java origins for a variety of Unix platforms. V2.0 likely to include portal support, identity linking, non web services (plumbing to GSSAPI,P2P, IM, video) etc. Work underway on intuitive graphical interfaces for the powerful underlying Attribute Authority and resource protection Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft. Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc. http://shibboleth.internet2.edu/

18. GUI’s to manage Shibboleth

19. SysPriv ARP GUI A tool to help administrators (librarians, central IT sysadmins, etc) set attribute release policies enterprise- wide • For access to licensed content • For linking to outsourced service providers • Has implications for end-user attribute release manager (Autograph) GUI design now actively underway, lead by Stanford Plumbing to follow shortly

20. End-user attribute release manager (Autograph) Intended to allow end-users to manage release policies themselves and, perhaps, understand the consequences of their decisions Needs to be designed for everyone even though only 3% will use it beyond the defaults. To scale, must ultimately include extrapolation on settings, exportable formats, etc.

21. Privacy Management Systems

22. Personal Resource Manager

23. Federating Software Comparison Liberty Alliance • V 1.1 of their functional specs released; 2.0 under discussion • Federation itself is out of scope • Open source implementations not emphasized • Current work is linked identities Shibboleth • V1.2 released; 1.3 and 2.0 under development • Most standards-based; pure open source in widening use • Current work is attribute release focused; linking identities in 2.0. WS-* • Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem space, but which need to closely interact with each other to do so. • Standards process and IPR issues uncertain • Will need considerable convention and detail to resolve into a working instantiation

24. WS-Fed and Shib Verbal agreements to build WS-Fed interoperability • Contract work commissioned by Microsoft, executed by Shib core development; contracts executed by mid-September, but work likely not til Spring Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed Devils in the details • Can WS-Fed-based SPs work in InCommon without having to muck up federation metadata with WS-Fed-specifics? • All the stuff besides WS-Fed in the WS-* stack • The best way to do Shib over SOAP • etc

25. Liberty, SAML and Shib Liberty is also SAML-based. Liberty 1.1 has an “open-source” implementation by Ping- ID that is not quite open SAML 2.0 extracts much of the best of Lib and the best of Shib. It leaves a lot of Shib (the privacy management) and not much of Liberty… Shib will be refactored Does Liberty move on to the apps (calendaring, presence, etc) or declare victory and go home?

26. Shib Issues going forward Doing OpenSAML 2.0 Refactoring Shib Dealing with old code bases, security patches, etc. Organizing a Shibboleth Project • International coordination on development • Moving more into the Shib-related development (versus the current Shib-core focus) • Promoting Shib-enhanced applications

27. Federations Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions Enroll and authenticate and attribute locally, act federally. Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision. Several federations now in construction or deployment

28. Business drivers - corporate Need to link consumer identities among disparate service providers Link corporate employees through a company portal to outsourced employee services transparently Allow supply chain partners to access each others internal web sites with role based controls

29. Business drivers – R&E Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then Federate (multilateral) those enterprise deployments with interrealm attribute transports, trust services, etc. and then Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we Be cautious about the limits of federations and look for alternative fabrics where appropriate.

30. Three Types of federation Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations. Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Many will be bi-lateral, short-term or otherwise constrained. Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.

31. Requirements for federations Federation operations Federating software • Exchange assertions • Link and unlink identities Federation data schema Federation privacy and security requirements Non web services can also leverage federations

32. Policy Basics for federations Enterprises that participate need to establish a trusted relationship with the operator of the federation; in small or bilateral federations, often one of the participants operates the federation Participants need to establish trust with each other on a per use or per application basis, balancing risk with the level of trust Participants need to agree on the syntax and semantics of the information to be shared Privacy issues must be addressed at several layers All this needs to be done on a scalable basis, as the number of participants grow and the number of federations grow

33. Federal guidelines of relevance NIST Guideline on Risk Assessment Methodologies NIST Guideline on Authentication Technologies and their strengths Federal e-Authentication

34. US Shibboleth federations InQueue InCommon • Uses • Management • Policies • Shared schema Club Shib NSDL

35. InCommon federation Federation operations – Internet2 Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Becomes fully operational August 15 or so, with several early entrants already in to help shape the policy issues. Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon http://www.incommonfederation.org

36. InCommon Principles Support the R&E community in inter-institutional collaborations InCommon itself operates at a high level of security and trustworthiness InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc InCommon will be constructive and help its participants move to higher levels of assurance as applications warrant InCommon will work closely with other national and international federations

37. InCommon Uses Institutional users acquiring content from popular providers (Napster) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.) Institutions working with outsourced service providers, e.g. grading services, scheduling systems Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.

38. InCommon Management Operational services by I2 • Member services • Backroom (CA, WAYF service, etc.) Governance • Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR). • Project manager – Renee Frost (Internet2) Membership open to .edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc…) Contractual and policy issues being defined now… Likely to take 501(c)3 status in the long term

39. InCommon participants Two types of participants: • Higher ed institutions - .edu-ish requirements • Service providers – partners sponsored by higher ed institutions, e.g. content providers, outsourced service providers (WebAssign, Roomschedulers, etc) Participants can function in roles of credential providers and resource providers • Higher ed institutions are primarily credential providers, with the potential for multiple resource providers on campus • Service providers are primarily offering a limited number of services, but can serve as credential providers for some of their employees as well

40. InCommon pricing Goals • Cost recovery • Manage federation “stress points” Prices • Application Fee: $700 (largely enterprise I/A, db) • Yearly Fee – Higher Ed participant: $1000 per identity management system – Sponsored participant: $1000 – All participants: 20 Resourceproviderids included; additional resourceproviderids available at $50 each per year, available in bundles of 20

41. Trust in InCommon - initial Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties • Enterprises read the procedures and decide if they want to become members Origins and targets trust each other bilaterally in out-of- band or no-band arrangements • Origins trust targets dispose of attributes properly • Targets trust origins to provide attributes accurately • Risks and liabilities managed by end enterprises, in separate ways

42. InCommon Policy Framework Federation-wide: • Charter • Federation Operating Practices Statement (FOPS) • List of common attributes • “The art of federation” Participant-specific • Submitting an application for participation • Participant agreement • Participant Operational Practices Statement (POPS)

43. InCommon Trust - ongoing Use trust  Build trust cycle Clearly need consensus levels of I/A Multiple levels of I/A for different needs • Two factor for high-risk • Distinctive requirements (campus in Bejing or France, distance ed, mobility) Standardized data definitions unclear Audits unclear International issues

44. Participant Agreement Highlights Agree to post policies • Security – Basic identity management • Privacy Inform InCommon on a timely basis of key compromise Be responsible for ResourceProviderIds issued Be responsible for adhering to their POPS statement Shared idemnification

45. Participant Operational Practice Statement Basic Campus identity management practices in a short, structured presentation • Identity proofing, credential delivery and repeated authn • Provisioning of enterprise-wide attributes, including entitlements and privileges Basic privacy management policies • Standard privacy plus • Received attribute management and disposal

46. Trust pivot points in federations In response to real business drivers and feasible technologies increase the strengths of Campus/enterprise identification, authentication practices Federation operations, auditing thereof Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof Relying party middleware infrastructure in support of Shib Moving in general from self-certification to external certification

47. Balancing the operator’s trust load InCommon CA • Identity proofing the enterprise • Issuing the enterprise signing keys (primary and spare) • Signing the metadata • Could be outsourced InCommon Federation • Aggregating the metadata • Supporting campuses in posting their policies • Less easy to outsource, especially the organic aspects

48. FOPS 1: InCommon Federation Operations InCommon_Federation_Disaster_Recovery_Procedures • An outline of the procedures to be used if there is a disaster with the InCommon Federation. Internet2_InCommon_Federation_Infrastructure_Technical_Referen ce • Document describing the federation infrastructure. Internet2_InCommon_secure_physical_storage • List of the physical objects and logs that will be securely stored. Internet2_InCommon_Technical_Operations_steps • This document lists the steps taken from the point of submitting CSR, Metadata, and CRL to issuing a signed cert, generation of signed metadata, and publishing the CRL. Internet2_InCommon_Technical_Operation_Hours • Documentation of the proposed hours of operations.

49. FOPS 2: InCommon CA Ops  CA_Disaster_Recovery_Procedure_ver_0.14 • An outline of the procedures to be used if there is a disaster with the CA.  cspguide • Manual of the CA software planning to use.  InCommon_CA_Audit_Log_ver_0.31 • Proposed details for logging related to the CA.  Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compro mise_ver_0.2 • An outline of the procedures to be used if there is a root key compromise with the CA.  Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61 • Draft of the PKI-Lite CPS.  Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21 • Draft of the PKI-Lite CP.  Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federa tion_System_Technical_Reference_ver_0.41 • Document describing the CA.

50. FOPS 3: InCommon Key Signing Process  2. Hardware descriptions a. Hardware will be laptop and spare laptop with no network capabilities, thumb drive, CDRW drive, media for necessary software 3. Software descriptions a. OS, OpenSSL, CSP, Java tools for meta data 4. Log into computer 5. Generation of the CA Private Root key and self-signing 6. Generation of the Metadata signing key 7. Generate CSR for Internet2 origin 8. Signing of new metadata sites and trusts files 9. Backup copies of all private keys and other operational backup data are generated. 10. Verify CD's and MD5 checksum 11. Write down passphrase and put in envelopes and sign envelopes 12. Securely store CA hardware and contents of local safe in safe 13. Log that these actions occurred on the log in safe and then close and lock the safe 14. Put thumb drive into secure db and copy data onto secure db 15. Take private key password archive and other contents to Private Key Password safe deposit box and record in log that this was done. 16. Take operational data archive to Operation Data safe deposit box and record in log that this was done.