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

2. 15 May 2001© 2001 University of Salford2 LDAP Directories n What are they? n Hierarchical distributed database that stores information (called attributes) about objects (called directory entries) n Accessible via an Internet and de-facto standard protocol called the Lightweight Directory Access Protocol (LDAP) n Supported by a wide range of suppliers, including Microsoft, Netscape, IBM, Novell, Siemens etc.

3. 15 May 2001© 2001 University of Salford3 LDAP X.521 based Naming Relative 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}

4. 15 May 2001© 2001 University of Salford4 LDAP DC based Naming RDN 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}

5. 15 May 2001© 2001 University of Salford5 Which is Better? n Both have their advantages n DC naming can leverage the DNS for name registration and DNS look up of LDAP servers. Also mandated by MS Active Directory n X.521naming is well established, more intuitive and needed for residential people n The most important point is n USE GLOBAL DISTINGUISHED NAMES

6. 15 May 2001© 2001 University of Salford6 RDN Conflicting Requirements n Each child RDN must be unique  numbers n DNs should be user friendly as they appear in certificates  string based names

7. 15 May 2001© 2001 University of Salford7 Standard Solution n PKIX and X.509 suggest use a two valued RDN n Use Common Name for user friendly part n Use Serial Number for guaranteeing uniqueness n E.g. cn=David Chadwick + sn=123456 n Also can include the Email address in the Subject Alt Names certificate extension to help identify the certificate subject

8. 15 May 2001© 2001 University of Salford8 Storing PKI Information in LDAP Directories n CA’s entry holds –Its own self signed certificate –Any certificates issued to this CA by another CA –Any certificates issued by this CA to another CA –Optionally the entire CRL issued by this CA n User’s entry holds –Any certificates issued to this user n Distribution point entries hold –CRLs issued by this CA

9. 15 May 2001© 2001 University of Salford9 LDAP Schema n Standard object classes for LDAP entries and standard attribute types for information –pkiUser object class »may contain: userCertificate –pkiCA object class »may contain: cACertificate, certificateRevocationList, authorityRevocationList, and crossCertificatePair –deltaCRL object class »may contain: deltaRevocationList –cRLDistributionPoint object class »must contain: commonName »may contain: certificateRevocationList, authorityRevocationList and deltaRevocationList

10. 15 May 2001© 2001 University of Salford10 Deficiencies in LDAP n Can’t transfer certificates using LDAPv2 as they are converted into ASCII strings and back again  wrecks the signature n Can’t search for particular certificates as no matching rules are defined n Can’t select individual certificates if a user has several in their entry n Little support for distributed directories as LDAP was originally conceived as an access protocol only

11. 15 May 2001© 2001 University of Salford11 Current Workarounds n Can’t transfer certificates in LDAPv2 n Define PKI attributes as binary attributes in LDAPv3 (and try to retrofit to LDAPv2) –userCertificate;binary, cACertificate;binary, certificateRevocationList;binary, authorityRevocationList;binary etc. n Can’t search for certificates n Add mirror attributes to directory entries holding contents of various certificate fields e.g. –mail attribute to hold subjectAltName rfc822 field –certSN to hold certificate serial number

12. 15 May 2001© 2001 University of Salford12 Current Workarounds (cont.) n Can’t select individual certificates n Either store different certificates in different attribute types or in different entries –Different attribute types is problematical, PKIs expect the standard attribute userCertificate –Different entries: 3 choices »Child entries »Sibling entries »Application specific subtrees

13. 15 May 2001© 2001 University of Salford13 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=Username3 CN=I/C Sales Child Entries CN=Username1

14. 15 May 2001© 2001 University of Salford14 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 Entries

15. 15 May 2001© 2001 University of Salford15 O=My Org OU=Sales OU=Bids OU=Some Unit CN=Fred Jones CN=John Smith OU=Unix Accounts CN=Username1 OU=International Commerce OU=S/MIME Encryption CN=John Smith + SN=1235 CN=Username2 C=DE CN=Jane Smith + SN=44567 Application Subtrees

16. 15 May 2001© 2001 University of Salford16 Future Solutions n Matched Values Internet Draft defines an extension for returning single certificates – – n LDAP Schema Internet Draft defines certificate and CRL matching rules – –

17. 15 May 2001© 2001 University of Salford17 Distributed Directory Problems n Distributed directories need n Ways of finding directory servers –Bootstrap the user to one or more directory servers –Knowledge References to link directory servers together –Certificate extensions to point to directory servers n Referrals and/or chaining to pass requests between servers –Referrals are in LDAPv3 (but not LDAPv2) –LDAP chaining is supported by some servers n Distributed authentication when passing requests between servers

18. 15 May 2001© 2001 University of Salford18 Current Workarounds n Finding servers –Use the DNS SRV records (as in Win 2000) –Pre-configure clients with addresses of servers (as in Netscape and Entrust) –Add proprietary knowledge references to servers –Use an X.500 back end service –But no magic bullet here - still a difficult problem n Distributed Authentication –Configure client username/passwords into every LDAP server, or use no authentication –Use proxy servers that have their own un/pw for remote servers, and map local names into this

19. 15 May 2001© 2001 University of Salford19 Future Solutions to Finding Servers n Use PKIX defined certificate extensions – –Authority Information Access points to superior CA – –Subject Information Access points to cross certified CAs n Standard knowledge references are being defined –subordinate refs –subordinate refs –other refs –other refs n Location mechanisms based on the DNS are being defined – – n Use CIP based referral server

20. 15 May 2001© 2001 University of Salford20 n X.500 supports 3 mechanisms –signed operations –chained requests –use of Compare operation for UN/PWs n LDAP currently supports none –no support for signed operations –no support for chaining –LDAP servers could be built to support Compare n 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 server Future Solutions to Distributed Authentication

21. 15 May 2001© 2001 University of Salford21 LDAP client Local LDAP Server Remote LDAP Server User Binds to local server Local server SASL Binds to remote server and specifies user’s name for authorisation The Proxying Feature of SASL

22. 15 May 2001© 2001 University of Salford22 SASL Proxying n Is being added to OpenLDAP n BUT a number of problems with it –if first server is compromised, then unauthorised access to second server is achieved –separate SASL Binds are needed between the two LDAP servers for each client request. To solve this a new control carrying the user’s authorisation identity will need to be added to each LDAP request