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/