Directories and PKI Keith Hazelton Senior IT Architect, UW-Madison PKI Summit, Snowmass, 9-Aug-01

Agenda PKI and Directories: Complementary Middleware Services Directories for Certificate Management Directories for Authorization Information: Attributes and Roles Directory Support for Privacy and Other Security Services Work Items for Consideration

PKI and Directories are Complementary Credo: Middleware services assist application roll-out Applications bring people and services together …in a controlled fashion We need both directory and security services to do apps But PKI and Directory complementary in a stronger sense Most I’s in PKI hand off key functions to directories Not all do (see PKI Ultra-Lite) Secure directories of the future may leverage PKI for PAIN –P rivacy, A uthentication, I ntegrity, N on-repudiation

Directories for Certificate Management Certificate management services via directories Certificate Repository Where apps can find X.509 certificates Find the person entry, then look for userCertificate attribute –Carl Ellison asks: How do you know you’ve got the right Tom Smith? Open question: as we issue multiple certificates, how do we get the right one?

Directories for Certificate Management Certificate Revocation Lists (CRLs) Certs can contain a CRL Distribution Point extension That extention MAY contain a URI pointing to the CRL Needed because vision of a global X.500 directory remains just that An alternative to CRLs is the Online Certificate Status Protocol (OCSP) service Certs can contain an Authority Information Access extension That extension MAY contain the name for an associated OCSP server

Directories for Certificate Management Certificate Repositories and CRLs Commercial PKI software suites may do this for you However, you will need to integrate with enterprise directory If you roll your own PKI, this is an item on the long list of tasks NOTE: PKI Lite and Ultra-Lite can live without directories Signed, encrypted Simple access control to web pages

Directories for Authorization Info Attributes and Roles tend to live in directories Good place to put them so apps can find them easily Proposed principle: Whatever else we do, let’s issue simple Identity certificates as a first step Why? Such a cert merely asserts a binding between a public key and a principal (a person, for this discussion) That assertion is likely to remain valid for some time Lessens frequency of revocation, reissuance But it creates a need for tight PKI-Directory integration PRIVACY ALERT!!! Threat to anonymity

Directories for Authorization Info Identity certificates and PKI-Directory integration Use the certificate for the authentication step Access control decisions depend on role-service mappings Roles are carried by authenticated principals So given a cert, app must be able to learn more about the subject Subject field in the certificate is a Distinguished Name (DN) So if we know where to look, we can ask more about subject

Directories for Authorization Info Identity certificates and PKI: Where should we go to ask more about subject? A good use for the Directory of Directories for Higher Education (?) For Federal PKI, reliance on X.500 chaining and referrals (?) What about apps that are supposed to work in both domains? Once you’ve found the directory, a simple lookup will find the subject’s full entry

Directories for Authorization Info More on Role-Service Mappings: Our policies (institutional and inter-institutional) will determine which roles (or groups) are eligible for which services In turn, roles and groups are defined by policy or business practice

Directories for Authorization Info More on Role-Service Mappings: Directories are the logical place to express roles and group memberships Groups in directories is a current hot item for MACE-Dir Communities of interest will need to define roles and groups Communities of interest will need to be in deep agreement Two basic varieties of groups: attribute based and ad hoc

Directories for Authorization Info What if we opt for attribute certificates? The directory is still the place to find authoritative attribute assertions from which to build attribute certificates Shifts the burden of community of interest agreement from directory schema to attribute certificate profiles

Directory Support for Privacy PRIVACY ALERT!! A simple Identity certificate will lead you right to the cache of information in the bearer’s directory entry One counter-measure: Control access to directory Means directory clients must themselves authenticate to directory Means non-person security principals Means directory support for access control information –How fine-grained? –Not yet standardized (LDAP-Ext work in progress) Another avenue: Pseudonymous Identity Certificates The DN of the subject of a pseudonymous cert reveals nothing about the subject

Directory Support for Privacy Pseudonymous Identity Certificates: Inspired by DLF, shaped by MACE-Shibboleth The DN of the subject of a pseudonymous cert reveals nothing about the subject Paired with authenticated binds to the directory, a powerful privacy protection mechanism “I’m App X, tell me about “XhJSedrtE’” But means more work for the PKI-Directory Integration Team And if persistent, nefarious interests can leverage it

Directory Support for Info Integrity The higher the risk, the more we must secure our directories One aspect is directory client confidence in the returned attributes Signed assertions as attributes in the directory I can decide if I trust the signer of the assertion I can be assured that the attribute value has not been altered in transit See Oasis-open work on Security Assertions Markup Language (SAML) Rare vendor convergence (except MS) on ways to express authentication and authorization assertions

Caution: Work Zone Ahead Repositories and CRL services in roll-your-own PKIs Integration of PKI Suite repositories with enterprise directory How do we get the right cert from the repository? Picking the apps to work on first (avoiding insanity and ennui) Community of interest role definition and maintenance

Caution: Work Zone Ahead Support for pseudonymous identity certificates Support for privacy and other security services (big) Oh yes, what about support for mobility (IETF-Sacred) OID-vey Policies are coming: CP, sure, but DP!?!?!

Your Turn Q & A & Discussion