HEPKI - PAG: An Update

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

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

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/

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

D. Wasley’s PKI Puzzle

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

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)

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

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

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

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

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

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 …

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

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

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

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

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

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

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

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

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)

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/

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!

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

Authentication (3) DataGrid CA Features matrix

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.

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

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 Dimensions of the Trust Continuum

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.

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

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…

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.

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

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

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 We Need A Strong Authentication 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 We Need a Flexible Interrealm Authorization Service

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)

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

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/

HEPKI - PAG: An Update