Federations: InQueue to InCommon Renee Woodten Frost 19 April 2004

What are federations?  Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions  Built on the premise of: Initially “Authenticate locally, act globally” Now, “Enroll and authenticate and attribute locally, act federally.”  Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) and common attributes (e.g. eduPerson)  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

InQueue  The “holding pond”  Is a persistent federation with “passing-through” membership…  Operational today. Can apply for membership via InQueue Federation guidelines  Requires eduPerson attributes  Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not…  Fees and service profile to be established shortly: cost- recovery basis

InCommon federation  A permanent federation for the R&E US sector  Federation operations – Internet2  Federating software – Shibboleth 1.1 and above  Federation data schema - eduPerson or later and eduOrg or later  Becomes operational April 5, with several early entrants to help shape the policy issues.  Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon 

InCommon Management  Operational services by Internet2 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) Two Executive Committee working groups – Policy – Tracy Mitrano, Chair –Communications, Membership, Pricing and Packaging – Susan Perry, Chair Technical Advisory Group – Scott Cantor (OSU), Steven Carmody (Brown), Bob Morgan (Washington), Renee Shuey (PSU) 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

Trust in InCommon - initial  Members trust the federated operations 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

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

Balancing the work  InCommon CA Identity proofing the enterprise Issuing the enterprise signing keys (primary and spare) Signing the metadata  InCommon Federation Aggregating the metadata Supporting campuses in posting their policies

InCommon Ops Docs  InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1 An outline of the procedures to be used if there is a disaster with the InCommon Federation.  Internet2_InCommon_Federation_Infrastructure_Technical_Referen ce_ver_0.2 Document describing the federation infrastructure.  Internet2_InCommon_secure_physical_storage_ver_0.2 List of the physical objects and logs that will be securely stored.  Internet2_InCommon_Technical_Operations_steps_ver_0.35 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_ver_0.12 Documentation of the proposed hours of operations.

InCommon CA Ops Docs  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.

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.

InCommon Ops Process Steps  InCommon Process Technical Reviewers Scott Cantor, OSU Jim Jokl, UVa RL Bob Morgan, UW Jeff Schiller, MIT  Key Signing Party March 30, 2004 in Ann Arbor Videotaped Witnessed  Phase One Participants

The potential for InCommon  The federation as a networked trust facilitator  Needs to scale in two fundamental ways Policy underpinnings need to move to normative levels among the members; “post and read” is a starting place… Inter-federation issues need to be engineered; we are trying to align structurally with emerging federal recommendations  Needs to link with PKI and with federal and international activities  If it does scale and grow, it could become a most significant component of cyberinfrastructure…