PKI 101 Ken Klingenstein Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder David Wasley Technology.

PKI 101

Ken Klingenstein

Project Director, Internet2 Middleware Initiative

Chief Technologist, University of Colorado at Boulder

David Wasley

Technology Guru

University of California

Agenda

Fundamentals - Components and Contexts

The missing pieces - in the technology and in the community

Current Activities - Feds, CHIME, ANX, overseas, PKI Forum, etc.

Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@edu, PKI Labs)

PKI: A few observations

Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important

Does it need to be a single infrastructure? What are the costs of multiple solutions? Subnets and ITPs...

Options breed complexity; managing complexity is essential

A few more...

IP connectivity was a field of dreams. We built it and then the applications came. Unfortunately, here the applications have arrived before the infrastructure, making its development much harder.

No one seems to be working on the solutions for the agora.

Uses for PKI and Certificates

authentication and pseudo-authentication

signing docs

encrypting docs and mail

non-repudiation

secure channels across a network

authorization and attributes

and more...

A matrix to structure the issues

Rows: PKI Components - hardware, software, processes, policies

Columns: Contexts for usage - community of interests

Cells: Implementation options (in-source, out-source, roll-your-own, etc.)

Note changes over time...

PKI Components

X.509 v3 certs - profiles and uses

Validation - Certificate Revocation Lists, OCSP, path construction

Cert management - generating certs, using keys, archiving and escrow, mobility, etc.

Directories - to store certs, and public keys and maybe private keys

Trust models and I/A

Cert-enabled apps

PKI Contexts for Usage

Intracampus

Within the Higher Ed community of interest

In the Broader World

PKI Implementation Options

In-source - with public domain or campus unique

In-source - with commercial product

Bring-in-source - with commercial services

Out-source - a spectrum of services and issues

what you do depends on when you do it...

Cert-enabled applications

Browsers

Authentication

S/MIME email

IPsec and VPN

Globus

Secure multicast

X.509 certs

purpose - bind a public key to a subject

standard fields

extended fields

profiles to capture prototypes

client and server issues

v2 for those who started too early, v3 for current work, v4 being finalized to address some additional cert formats (attributes, etc.)

Standard fields in certs

cert serial number

the subject, as x.500 DN or …

the subject’s public key

the validity field

the issuer, as id and common name

signing algorithm

signature info for the cert, in the issuer’s private key

Extension fields

Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, etc.

Key usage is very important - for digsig, non-rep, key or data encipherment, etc.

Certain extensions can be marked critical - if an app can’t understand it, then don’t use the cert

Requires profiles to document, and great care...

Certificate Profiles

per field description of certificate contents - both standard and extension fields, including criticality flags

syntax of values permitted per field

semantics specified

spreadsheet format by R. Moskowitz, XML and ASN.1 alternatives for machine use

centralized repository for higher ed at http://www.educause.edu/hepki

Early Profile Commonalities and Differences

Commonalities -

Signing algs either RSA with MD5 or RSA with SHA-1

Keep the contents simple and generally non-volatile; no-one is doing CRLs yet

Inclusion of some domain component information within the payload

Differences -

Where to put domain information (altsubjname,subjname,issuername, etc)

What fields to mark critical

How to use constraints

OIDs

numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies.

Numbering is only for identification (are two oids equal? If so, the associated objects are the same); no ordering, search, hierarchy, etc.

Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16.602.1, and then creates oids by extending the arc, e.g 1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1, 1.3.4.1.16.602.1.1.1)

Getting an OID

apply at IANA at http://www.iana.org/cgi-bin/enterprise.pl

apply at ANSI at http://web.ansi.org/public/services/reg_org.html

more info at http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc

Cert Management

Certificate Management Protocol - for the creation, revocation and management of certs

Revocation Options - CRL, OCSP

Storage - where (device, directory, private cache, etc.) and how - format (DER,BER, etc.)

Escrow and archive - when, how, and what else needs to be kept

Cert Authority Software or outsource options

Authority and policies

Certificate Management Systems

Homebrews

Open Source - OpenSSL, OpenCA, Oscar

Third party - Baltimore, Entrust, etc.

OS-integrated - W2K, Sun/Netscape, etc.

Public Domain Alternatives

Mozilla

SSLEAY (Open SSL) (www.openssl.org)

Open CA (http://www.openca.org/docs/mission.shtml)

vandyke and Cygnacom libraries in the public domain for path math

Directories

to store certs

to store CRL

to store private keys, for the time being

to store attributes

implement with border directories, or ACLs within the enterprise directory, or proprietary directories

Certificate Policies Address (CP)

Legal responsibilities and liabilities (indemnification issues)

Operations of Certificate Management systems

Best practices for core middleware

Assurance levels - varies according to I/A processes and other operational factors

Certificate Practice Statements (CPS)

Site specific details of operational compliance with a Cert Policy

A single practice statement can support several policies (CHIME)

A Policy Management Authority (PMA) determines if a CPS is adequate for a given CP.

Inter-organizational trust model components

Certificate Policy- uses of particular certs, assurance levels for I/A, audit and archival requirements

Certificate Practices Statement- the nitty gritty operational issues

Hierarchies vs Bridges• a philosopy and an implementation issue

• the concerns are transitivity and delegation

• hierarchies assert a common trust model

• bridges pairwise agree on trust models and policy mappings

Trust Chains

verifying sender-receiver assurance by finding a common trusted entity

must traverse perhaps branching paths to establish trust paths

must then use CRLs etc. to validate assurance

if policies are in cert payloads, then validation can be quite complex

delegation makes things even harder

Trust chains

Path construction• to determine a path from the issuing CA to a trusted CA

• heuristics to handle branching that occurs at bridges

Path validation• uses the path to determine if trust is appropriate

• should address revocation, key usage, basic constraints, policy mappings, etc.

Trust chains

When and where to construct and validate• off-line - on a server - at the discretion of the application

• depth of chain

some revocations better than others - major (disaffiliation, key compromise, etc.) and minor (name change, attribute change)

sometimes the CRL can’t be found or hasn’t been updated

Mobility Options

smart cards

USB dongles

passwords to download from a store or directory

proprietary roaming schemes abound - Netscape, VeriSign, etc.

SACRED within IETF recently formed for standards

Difficulty in integration of certificates from multiple stores (hard drive, directory, hardware token, etc.)

All the stuff we don’t know…

Revocation approaches

Policy languages

Mobility

Path construction in complex trusts

Operating system and token security issues

User interface

Internet2 PKI Labs

At Dartmouth and Wisconsin in computer science departments and IT organizations

Doing the deep research - two to five years out

Policy languages, path construction, attribute certificates, etc.

National Advisory Board of leading academic and corporate PKI experts provides direction

Catalyzed by startup funding from ATT

Activities in other Communities

PKIX (http://www.ietf.org/html.charters/pkix-charter.html)

Federal PKI work (http://csrc.nist.gov/pki/twg/)

State Govts (http://www.ec3.org/)

Medical community (Tunitas, CHIME, HIPAA)

Automobile community (ANX)

Overseas• Euro government - qualifying certs

• EuroPKI for Higher Ed (http://www.europki.org/ca/root/cps/en_index.html)

Ah, the public sector…

almost universal community of interests

cross-agency relationships

complex privacy and security issues

limited budgets and implementation options

sometimes ahead of the crowd and the obligation to build a marketplace

Activities in Higher Ed community

Federal - ACES, etc.

State Governments - Washington, Virginia, Texas, etc.

HEPKI

the Grid

HEPKI

HEPKI - Technical Activities Group (TAG)• universities actively working technical issues

• topics include Kerberos-PKI integration, public domain CA, profiles

• will sponsor regular conf calls, email archives

HEPKI - Policy Activities Group (PAG)• universities actively deploying PKI

• topics include certificate policies, RFP sharing, interactions with state governments

• will sponsor regular conf calls, email archives

Key issues

trust relationships among autonomous organizations

interoperability of profiles and policies

interactions with J.Q. Public

international governance issues

Will it fly?

Well, it has to…

Scalability

Performance

OBE

“With enough thrust, anything can fly”

Where to watch

middleware.internet2.edu

www.educause.edu/hepki

www.cren.org

www.pkiforum.org