hepki - pag: an update
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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
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
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
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
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
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/