1. HEPKI - PAG: An Update Ken Klingenstein Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

2. Agenda Background: HEPKI-PAG and related activities Basics: Draft HE CP and other CP’s Advanced: FERPA, Grids, European efforts Trust issues for authentication and authorization Next steps: HEBCA CP and PMA Directory Policies Reconciliations

3. HEPKI PAG A partnership of Internet2, EDUCAUSE, and CREN Key players – David Wasley, Art Vandenberg Regular conference calls every other Thursday http://www.educause.edu/hepki/

4. HEPKI-PAG Trust issues and trust framework for PKI Lots of practical problems to grapple with Who do you trust? How much trust is enough? Attempt to compare trust models in education, research, government and commercial sectors All over the map! PKI “bridges” require trust mapping Attempt to identify trust requirements of apps

5. D. Wasley’s PKI Puzzle

6. Certificate Policy is … The basis for trust between unrelated entities Not a formal “contract” (but implied) A framework that both informs and constrains a PKI implementation A way of giving advice to Relying Parties One of a number of related documents, incl. Certification Practices Directory Policy

7. Goals A “generic” CP for higher ed PKI All implementation specific details deferred to associated Certification Practices Statement CP requirements intended to foster inter- domain trust Compatible with the Federal BCA policy Multiple “levels of assurance” “Rudimentary” level (PKI Lite, minimal overhead) “High” (requires photo IDs & smartcards)

8. PKI Players Policy Management Authority (PMA) Responsible for developing and enforcing policy Certificate Authority (CA) Operational unit(s) Term also applies to the entire set of functions Registration Authority (RA) Optional, delegated responsibility for I & A Subjects and Relying Parties

9. RFC 2527 CP Sections Introduction General Provisions Identification and Authentication Operational Requirements Physical, Procedural and Personnel Security Ctrls Technical Security Controls Certificate and CARL/CRL Profiles Specification Administration

10. Introduction Distinction between CP and CPS CP is transitive throughout the hierarchy Authorizing CA has responsibility for authorized CA Document identity OID for the CP and OIDs for each LOA Community served is defined in the CPS Relying Party can’t make assumptions unless so stated On-line copy of CP and CPS must be signed

11. Introduction (cont.) Applicability of the issued certificates based on Level of Assurance (LOA) Rudimentary - very low risk apps; data integrity Basic - for apps with minimal risk Medium - modest risk, including monetary loss High - secure apps; transactions of significant financial consequence CPS can proscribe specific application types In case liability is a concern

12. General Provisions Obligations of the parties CA, RA, Subscriber, Relying Party, Repository RP is problematic since there is no “contract” –“Requirements” e.g. checking CRL, are advice –In some cases a contract may be needed, e.g. FERPA Liability – limited to $1,000 Considered necessary to indicate trustworthiness Audit requirements Must be performed by qualified third party

13. Identification and Authentication Types of Subject names If included, must be meaningful Must be unique for all time Different requirements for each LOA Photo ID required for Medium or High LOA Document ID marks must be recorded and archived CA rekey requirements Must notify PKC Subjects …

14. Operational Requirements CA may not generate key pairs for Subjects For encryption certs, an intermediary might… PKC acceptance for Med/High require signature PKC Suspension or Revocation Suspension not used Revocation required at Basic or higher LOA –Requires standard CRL; allows for OCSP –Relying Party required to check for revocation

15. Operational Requirements (cont.) Security Audit Procedure Everything that might affect the CA or RA Simpler for Rudimentary Records Archival Up to 20+ years for High LOA (Electronic archive is an activity unto itself) Disaster Recovery Requirements CA Termination Process

16. Physical, Procedural and Personnel Security Controls CA Roles Administrator - sysadmin; installs & configures Officer - approves issuance and revocation of PKCs Operator - routine system operation & backup Auditor - reviews syslogs; oversees external audit Separation of roles required at least 2 people (Admin./Op. & Officer/Auditor) at least 3 at higher LOAs Some tasks require action by 2 out of 4 persons

17. Technical Security Controls FIPS 140 Technical Security Level depends on LOA Key sizes and private key protection requirements Escrow of end-entity decryption (private) key CA must have possession of key before issuing PKC Must NOT escrow any other private key Computer platform and network controls Engineering and development controls

18. Certificate and CARL/CRL Profiles Certificate profile is x.509v3 or higher Details in CPS CertPolicyID is the LOA OID CPSuri points to the on-line signed CPS –CPS specifies CP OID and URL for on-line copy Certificate serial number must be unique across all PKCs issued by this CA Considering adding URI to authorityKeyIdentifier CARL/CRL is x.509v2 or higher

19. Specification Administration Framework for how the PMA changes or updates this policy document Notifying Subjects is hard –Publication is considered sufficient Notifying Relying Parties is impossible –Policy in force at time of issue prevails Significant change requires new OID(s) See also the Bibliography and Glossary

20. Other Policy Documents Certification Practices Statement All specific details, e.g. community, I&A, etc. HE draft example begun … Directory Policy Statement As critical as the credential Includes access controls, element definitions, etc… Local campus Business Policy Provisions The basis for the institution to issue credentials

21. Similar CPs for Comparison Federal BCA Certificate Policy European PKI certificate policy Globus Grid CP Draft Model Interstate Certificate Policy Commercial PKI CPs (very different) CP for the State of Washington NACHA CARAT guidelines

22. HE CP Acknowledgements Richard Guida, Federal PKI Council Ken Klingenstein and the I2 HEPKI-PAG Judith Boettcher and Dan Burke, CREN Scott Fullerton, Wisconsin-Madison Art Vandenburg, Georgia State Ed Feustel, Dartmouth College Support: Renee Frost, Ellen Vaughan, Nate Klingenstein (I2), Michelle Gildea (CREN)

23. Advanced Issues Student issues what is needed for a student loan signature? what is needed for viewing student loan information? what is permitted in the release of information by certificates and directories? Proliferation of CA’s http://edms.cern.ch/document/340234/2.0 Euro Issues TF-PKICOORD morphs into TF-AACE http://www.terena.nl/projects/pki/

24. WP6 CACG 11 DataGrid Testbed1 CA’s See WP6 web Much effort to run these – growing number of cert requests Several moving to OpenCA US DOE ScienceGrid CA Operational since January 2002 Approved as a DataGrid “trusted” CA (& vice-versa!) First test of transatlantic authentication last month Karlsruhe CA (CrossGrid and HEP Germany) To be incorporated later Seems to attract Grid CA issues that should have gone to GGF!

25. Authentication (2) One of the EDG CA’s (CNRS) acts as a “catch-all” CA CP/CPS will get explicit statements about RA’s Matrix of Trust (work ongoing) – much work! Feature matrix Acceptance matrix (WP6 CA Mgrs check each other against min. requirements) BUT: Still another 7 CrossGrid countries with no CA And many other LHC countries Scaling problems! Automate the feature checking Continue to work with GGF in the GridCP group

26. Authentication (3) DataGrid CA Features matrix

27. Interrealm Trust Structures Federated administration basic bilateral (origins and targets in web services) complex bilateral (videoconferencing with external MCU’s, digital rights management with external rights holders) multilateral Hierarchies may assert stronger or more formal trust requires bridges and policy mappings to connect hierarchies appear larger scale Virtual organizations Grids, digital library consortiums, Internet2 VideoCommons, etc. Share real resources among a sparse set of users Requirements for authentication and authorization, resource discovery, etc need to leverage federated and hierarchical infrastructures.

28. The Continuum of Trust Collaborative trust at one end… can I videoconference with you? you can look at my calendar You can join this computer science workgroup and edit this computing code Students in course Physics 201 @ Brown can access this on-line sensor Members of the UWash community can access this licensed resource Legal trust at the other end… Sign this document, and guarantee that what was signed was what I saw Encrypt this file and save it Identifiy yourself to this high security area

29. Dimensions of the Trust Continuum Collaborative trust handshake consequences of breaking trust more political (ostracism, shame, etc.) fluid (additions and deletions frequent) shorter term structures tend to clubs and federations privacy issues more user-based Legal trust contractual consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.) more static (legal process time frames) longer term (justify the overhead) tends to hierarchies and bridges privacy issues more laws and rules

30. The Trust Continuum, Applications and their Users Applications and their user community must decide where their requirements fit on the trust continuum Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach. Many applications fit somewhere in the middle and the user communities (those that trust each other) need to select a approach that works for them.

31. Integrating Security and Privacy Balance between weak identity, strong identity, and attribute- based access (without identity) Balance between privacy and accountability – keeping the identity known only within the security domain

32. Reconciling Humans and Lawyers Non-repudiation has had a very high bar set… Human nature has been “refined” over a long time We tend to talk globally, think locally and act inconsistently…

33. Of Security, Privacy, and Trust Is it security or is it liability? Liability has other remedies, including disclaimers, contractual sharing of responsibilities, indemnification, etc… Is it privacy or is it discretion? Privacy can only be degraded. How can privacy loss be managed? Should privacy be an active or passive service? When do we want our privacy given up? Is it trust or is it risk management (contracts)? Our notions of trust are soft, contradictory, volatile, intuitive, and critical to how we act in the world. Contracts and current computational approaches are hard and slow to change.

34. The Architecture of Authentication Identification/Authentication has two components the initial determination that a particular subject should be provided a specific credential (identification). i.e. “getting a credential” the continuing processes of that subject establishing their electronic presence (authentication) “using a credential” Examples two forms of photo id in person to be issued a computer account, and then Kerberos to authenticate providing a name and social security number to receive a PIN, and being able to view student loan data with that PIN The “strength” of authentication depends on both processes The need for strong authentication depends on the resources that are being offered to the authenticator

35. The Architecture of Authorization Should the authorization decision be made by the user’s domain, based on business rules provided by the target or by the target, based upon attributes provided by the user’s domain? If at the target, should the user’s domain pass all attributes about a user to a target, to protect the privacy of the target, or a minimal set of attributes, to protect the privacy of the user? The answers depend on point of view, scalability, manageability, and performance

36. We Need A Strong Authentication Service Identity in the real world is very hard. There are some legitimate needs that need formal and high levels of security services Documents must be notarized There are cases where email be signed and encrypted Authentication is in general a “local” service that can be conveyed globally

37. We Need a Flexible Interrealm Authorization Service We are only beginning to understand authorization Permissions are much more volatile than identity Delegation and non-determinism are hard Privacy rests here, and we don’t understand privacy Expressions of permissions require complex data structures

38. Authentication and Authorization On occasion, a screwdriver can be used to drive nails, especially if there is not a hammer handy. Some inter-realm authentication systems can be used for authorization (e.g. Kerberos, X.509) Some inter-realm attribute exchanges can pass identifiers and thus be used for inter-realm “authentication” (e.g. Shibboleth)

39. Next Steps HEBCA CP and PMA Directory Policies Reconciliations of formats and trust

40. Where to watch http://middleware.internet2.edu/ http://www.educause.edu/hepki/ http:// www.cren.org http://middleware.internet2.edu/pkilabs http://csrc.nist.gov/pki/twg/