1 / 18

Directories and PKI

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

sven
Download Presentation

Directories and PKI

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. Directories and PKI Keith Hazelton Senior IT Architect, UW-Madison PKI Summit, Snowmass, 9-Aug-01

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

  3. 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 • Privacy, Authentication, Integrity, Non-repudiation

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

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

  6. 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 email • Simple access control to web pages

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

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

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

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

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

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

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

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

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

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

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

  18. Your Turn • Q & A & Discussion

More Related