1 / 37

PKI 101

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

regina
Download Presentation

PKI 101

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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)

  3. 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

  4. 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.

  5. 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...

  6. 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...

  7. 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

  8. PKI Contexts for Usage • Intracampus • Within the Higher Ed community of interest • In the Broader World

  9. 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...

  10. Cert-enabled applications • Browsers • Authentication • S/MIME email • IPsec and VPN • Globus • Secure multicast

  11. 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.)

  12. 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

  13. 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...

  14. 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

  15. 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

  16. 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)

  17. 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

  18. 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

  19. Certificate Management Systems • Homebrews • Open Source - OpenSSL, OpenCA, Oscar • Third party - Baltimore, Entrust, etc. • OS-integrated - W2K, Sun/Netscape, etc.

  20. 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

  21. 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

  22. 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

  23. 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.

  24. 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

  25. 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

  26. 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.

  27. 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

  28. 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.)

  29. 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

  30. 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

  31. 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)

  32. 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

  33. Activities in Higher Ed community • Federal - ACES, etc. • State Governments - Washington, Virginia, Texas, etc. • HEPKI • the Grid

  34. 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

  35. Key issues • trust relationships among autonomous organizations • interoperability of profiles and policies • interactions with J.Q. Public • international governance issues

  36. Will it fly? • Well, it has to… • Scalability • Performance • OBE • “With enough thrust, anything can fly”

  37. Where to watch • middleware.internet2.edu • www.educause.edu/hepki • www.cren.org • www.pkiforum.org

More Related