15 May 2001© 2001 University of Salford1 Deficiencies in LDAP when used to support Public Key Infrastructures David W Chadwick d.w.chadwick@salford.ac.uk.
Post on 19-Jan-2016
220 Views
Preview:
Transcript
15 May 2001 © 2001 University of Salford 1
Deficiencies in LDAP when used Deficiencies in LDAP when used to support Public Key to support Public Key
InfrastructuresInfrastructures
David W ChadwickDavid W Chadwick
d.w.chadwick@salford.ac.ukd.w.chadwick@salford.ac.uk
15 May 2001 © 2001 University of Salford 2
LDAP DirectoriesLDAP Directories
What are they?What are they? Hierarchical distributed database that stores Hierarchical distributed database that stores
information (called attributes) about objects (called information (called attributes) about objects (called directory entries)directory entries)
Accessible via an Internet and de-facto standard Accessible via an Internet and de-facto standard protocol called the Lightweight Directory Access protocol called the Lightweight Directory Access Protocol (LDAP)Protocol (LDAP)
Supported by a wide range of suppliers, including Supported by a wide range of suppliers, including Microsoft, Netscape, IBM, Novell, Siemens etc.Microsoft, Netscape, IBM, Novell, Siemens etc.
15 May 2001 © 2001 University of Salford 3
LDAP X.521 based NamingLDAP X.521 based NamingRelative
Distinguished
Name of Entry
{null}
{C=DE}
{O=MyOrg Gmbh}
{OU=Sales+
L=Munich}
LDAP
Distinguished
Name of Entry
{null)
{C=DE}
{O=MyOrg Gmbh, C=DE}
{OU=Sales+ L= Munich,
O=MyOrg Gmbh, C=DE}
15 May 2001 © 2001 University of Salford 4
LDAP DC based NamingLDAP DC based NamingRDN of Entry
{null}
{dc=com}
{dc=MyOrg}
{OU=Sales+
L=Munich}
LDAP
Distinguished
Name of Entry
{null)
{dc=com}
{dc=MyOrg,dc=com}
{OU=Sales+ L= Munich,dc=MyOrg, dc=com}
15 May 2001 © 2001 University of Salford 5
Which is Better?Which is Better? Both have their advantagesBoth have their advantages DC naming can leverage the DNS for name DC naming can leverage the DNS for name
registration and DNS look up of LDAP servers. registration and DNS look up of LDAP servers. Also mandated by MS Active DirectoryAlso mandated by MS Active Directory
X.521naming is well established, more intuitive X.521naming is well established, more intuitive and needed for residential people and needed for residential people
The most important point isThe most important point is USE GLOBAL DISTINGUISHED NAMESUSE GLOBAL DISTINGUISHED NAMES
15 May 2001 © 2001 University of Salford 6
RDN Conflicting RequirementsRDN Conflicting Requirements Each child RDN must be unique Each child RDN must be unique numbers numbers DNs should be user friendly as they appear in DNs should be user friendly as they appear in
certificates certificates string based names string based names
15 May 2001 © 2001 University of Salford 7
Standard SolutionStandard Solution PKIX and X.509 suggest use a two valued RDNPKIX and X.509 suggest use a two valued RDN Use Common Name for user friendly partUse Common Name for user friendly part Use Serial Number for guaranteeing uniquenessUse Serial Number for guaranteeing uniqueness E.g. cn=David Chadwick + sn=123456E.g. cn=David Chadwick + sn=123456
Also can include the Email address in the Subject Also can include the Email address in the Subject Alt Names certificate extension to help identify the Alt Names certificate extension to help identify the certificate subjectcertificate subject
15 May 2001 © 2001 University of Salford 8
Storing PKI Information in LDAP Storing PKI Information in LDAP DirectoriesDirectories
CA’s entry holdsCA’s entry holds– Its own self signed certificateIts own self signed certificate– Any certificates issued to this CA by another CAAny certificates issued to this CA by another CA– Any certificates issued by this CA to another CAAny certificates issued by this CA to another CA– Optionally the entire CRL issued by this CAOptionally the entire CRL issued by this CA
User’s entry holdsUser’s entry holds– Any certificates issued to this userAny certificates issued to this user
Distribution point entries holdDistribution point entries hold– CRLs issued by this CACRLs issued by this CA
15 May 2001 © 2001 University of Salford 9
LDAP SchemaLDAP Schema Standard object classes for LDAP entries and standard attribute Standard object classes for LDAP entries and standard attribute
types for informationtypes for information– pkiUser object classpkiUser object class
» may contain: userCertificatemay contain: userCertificate
– pkiCA object classpkiCA object class» may contain: cACertificate, certificateRevocationList, authorityRevocationList, may contain: cACertificate, certificateRevocationList, authorityRevocationList,
and crossCertificatePairand crossCertificatePair
– deltaCRL object classdeltaCRL object class» may contain: deltaRevocationListmay contain: deltaRevocationList
– cRLDistributionPoint object classcRLDistributionPoint object class» must contain: commonNamemust contain: commonName» may contain: certificateRevocationList, authorityRevocationList and may contain: certificateRevocationList, authorityRevocationList and
deltaRevocationListdeltaRevocationList
15 May 2001 © 2001 University of Salford 10
Deficiencies in LDAPDeficiencies in LDAP CanCan’t transfer certificates using LDAPv2 as they ’t transfer certificates using LDAPv2 as they
are converted into ASCII strings and back again are converted into ASCII strings and back again wrecks the signaturewrecks the signature
CanCan’t search for particular certificates as no ’t search for particular certificates as no matching rules are definedmatching rules are defined
Can’t select individual certificates if a user has Can’t select individual certificates if a user has several in their entryseveral in their entry
Little support for distributed directories as LDAP Little support for distributed directories as LDAP was originally conceived as an access protocol onlywas originally conceived as an access protocol only
15 May 2001 © 2001 University of Salford 11
Current WorkaroundsCurrent Workarounds Can’t transfer certificates in LDAPv2Can’t transfer certificates in LDAPv2 Define PKI attributes as binary attributes in LDAPv3 (and Define PKI attributes as binary attributes in LDAPv3 (and
try to retrofit to LDAPv2)try to retrofit to LDAPv2)– userCertificate;binary, cACertificate;binary, userCertificate;binary, cACertificate;binary,
certificateRevocationList;binary, certificateRevocationList;binary, authorityRevocationList;binary etc.authorityRevocationList;binary etc.
Can’t search for certificatesCan’t search for certificates Add mirror attributes to directory entries holding contents Add mirror attributes to directory entries holding contents
of various certificate fields e.g.of various certificate fields e.g.– mail attribute to hold subjectAltName rfc822 fieldmail attribute to hold subjectAltName rfc822 field– certSN to hold certificate serial numbercertSN to hold certificate serial number
15 May 2001 © 2001 University of Salford 12
Current Workarounds (cont.)Current Workarounds (cont.)
Can’t select individual certificatesCan’t select individual certificates Either store different certificates in different Either store different certificates in different
attribute types or in different entriesattribute types or in different entries– Different attribute types is problematical, PKIs Different attribute types is problematical, PKIs
expect the standard attribute userCertificateexpect the standard attribute userCertificate
– Different entries: 3 choicesDifferent entries: 3 choices» Child entriesChild entries
» Sibling entriesSibling entries
» Application specific subtreesApplication specific subtrees
15 May 2001 © 2001 University of Salford 13
O=My Org
OU=Some Unit
CN=I/C Bids
CN=John Smith + SN=1235
CN=Fred Jones + SN=2345
C=DE
CN=Username2
CN=Jane Smith+ SN=44567
CN=Username3CN=I/C Sales
Child EntriesChild Entries
CN=Username1
15 May 2001 © 2001 University of Salford 14
O=My Org
OU=Some Unit
CN=John Smith (I/C Bids)
CN=John Smith+ SN=1235
CN=Fred Jones (I/C Sales)
C=DE
CN=Username1
CN=Jane Smith+ SN=44567
CN=Username2
Sibling EntriesSibling Entries
15 May 2001 © 2001 University of Salford 15
O=My Org
OU=SalesOU=Bids
OU=SomeUnit
CN=Fred JonesCN=John Smith
OU=Unix Accounts
CN=Username1
OU=InternationalCommerce
OU=S/MIMEEncryption
CN=John Smith+ SN=1235
CN=Username2
C=DE
CN=Jane Smith+ SN=44567
Application SubtreesApplication Subtrees
15 May 2001 © 2001 University of Salford 16
Future SolutionsFuture Solutions
Matched Values Internet Draft defines an Matched Values Internet Draft defines an extension for returning single certificatesextension for returning single certificates– <draft-ldapext-matchedval-05.txt><draft-ldapext-matchedval-05.txt>
LDAP Schema Internet Draft defines LDAP Schema Internet Draft defines certificate and CRL matching rulescertificate and CRL matching rules– <draft-pkix-ldap-schema-01.txt><draft-pkix-ldap-schema-01.txt>
15 May 2001 © 2001 University of Salford 17
Distributed Directory ProblemsDistributed Directory Problems Distributed directories needDistributed directories need Ways of finding directory serversWays of finding directory servers
– Bootstrap the user to one or more directory serversBootstrap the user to one or more directory servers
– Knowledge References to link directory servers togetherKnowledge References to link directory servers together
– Certificate extensions to point to directory serversCertificate extensions to point to directory servers Referrals and/or chaining to pass requests between serversReferrals and/or chaining to pass requests between servers
– Referrals are in LDAPv3 (but not LDAPv2)Referrals are in LDAPv3 (but not LDAPv2)
– LDAP chaining is supported by some serversLDAP chaining is supported by some servers Distributed authentication when passing requests between Distributed authentication when passing requests between
serversservers
15 May 2001 © 2001 University of Salford 18
Current WorkaroundsCurrent Workarounds Finding serversFinding servers
– Use the DNS SRV records (as in Win 2000)Use the DNS SRV records (as in Win 2000)
– Pre-configure clients with addresses of servers (as in Netscape and Entrust)Pre-configure clients with addresses of servers (as in Netscape and Entrust)
– Add proprietary knowledge references to serversAdd proprietary knowledge references to servers
– Use an X.500 back end serviceUse an X.500 back end service
– But no magic bullet here - still a difficult problemBut no magic bullet here - still a difficult problem Distributed AuthenticationDistributed Authentication
– Configure client username/passwords into every LDAP server, or use no Configure client username/passwords into every LDAP server, or use no authenticationauthentication
– Use proxy servers that have their own un/pw for remote servers, and map Use proxy servers that have their own un/pw for remote servers, and map local names into thislocal names into this
15 May 2001 © 2001 University of Salford 19
Future Solutions to Finding ServersFuture Solutions to Finding Servers Use PKIX defined certificate extensionsUse PKIX defined certificate extensions
– Authority Information Access points to superior CA– Subject Information Access points to cross certified CAs
Standard knowledge references are being definedStandard knowledge references are being defined– subordinate refs <draft-zeilenga-ldap-namedref-03.txt>subordinate refs <draft-zeilenga-ldap-namedref-03.txt>– other refs <draft-ietf-ldapext-refer-01.txt>other refs <draft-ietf-ldapext-refer-01.txt>
Location mechanisms based on the DNS are being definedLocation mechanisms based on the DNS are being defined– <draft-ietf-ldapext-locate-05.txt> <draft-ietf-ldapext-locate-05.txt> – <draft-ietf-pkix-pkixrep-01.txt><draft-ietf-pkix-pkixrep-01.txt>
Use CIP based referral serverUse CIP based referral server
15 May 2001 © 2001 University of Salford 20
X.500 supports 3 mechanismsX.500 supports 3 mechanisms– signed operationssigned operations– chained requestschained requests– use of Compare operation for UN/PWsuse of Compare operation for UN/PWs
LDAP currently supports noneLDAP currently supports none– no support for signed operationsno support for signed operations– no support for chainingno support for chaining– LDAP servers could be built to support CompareLDAP servers could be built to support Compare
But LDAP could use the proxying feature of SASL so that a local But LDAP could use the proxying feature of SASL so that a local LDAP server can assert the identity of the user to a remote LDAP LDAP server can assert the identity of the user to a remote LDAP serverserver
Future Solutions to Distributed AuthenticationFuture Solutions to Distributed Authentication
15 May 2001 © 2001 University of Salford 21
LDAPclient
LocalLDAPServer
RemoteLDAPServer
User Bindsto local server
Local server SASL Bindsto remote server and specifies user’s namefor authorisation
The Proxying Feature of SASLThe Proxying Feature of SASL
15 May 2001 © 2001 University of Salford 22
SASL ProxyingSASL Proxying Is being added to OpenLDAPIs being added to OpenLDAP BUT a number of problems with itBUT a number of problems with it
– if first server is compromised, then unauthorised if first server is compromised, then unauthorised access to second server is achievedaccess to second server is achieved
– separate SASL Binds are needed between the two separate SASL Binds are needed between the two LDAP servers for each client request. To solve LDAP servers for each client request. To solve this a new control carrying the user’s authorisation this a new control carrying the user’s authorisation identity will need to be added to each LDAP identity will need to be added to each LDAP requestrequest
top related