Transcript Document 7226238

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-yourown, 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-toOIDs.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