Deploying Directory-Enabled Enterprise-Wide Security

1. DeployingDirectory-EnabledEnterprise-Wide Security Luc Clement Director of Products, Zoomit Corporation LClement@zoomit.com Internet Expo Business-to-business Enterprise Solutions San Jose Convention Center February 10,1998

2. Zoomit has security objectives ... • Directory-enabling everything - securely • Lead in identity management - establishing and managing identities in cyberspace • Solve the single login problem • Create metasecurityto integrate useful security protocols, especially X.509, Kerberos, and Radius • Lead in Cryptologistics - the way to successfully deploy and deliver keys and certificates • Interoperate with everyone

3. … but is a real Intranet company • Zoomit uses the Internet Services Model, in which network services are based on open standards • Zoomit VIA is comfortable in environments where Internet security services are offered by other vendors • We will make every effort so our tools, clients and servers will work with X.509 PKI’s and Kerberos servers from any vendor - including MIT/Cygnus, Microsoft, Verisign, Entrust, Netscape, and others.

4. Redeeming the Evil Twin Inclusiveness Directory Security

5. Public Key Infrastructure

6. Public Key What is it about public key? • The concept is awesome… • Has a pristine mystical quality • Must not be sullied by compromise with mortality • Perfect authentication for angels

7. Management of PKI • Must be directory enabled and managed • Not just sticking certificates in the directory • Rethink of the whole process given the universal infrastructure • PKI not fully rooted in directory is a ruse. • Beware the evil twin’s YETA (YETAnother directory) No New Namespaces!

8. A Need to Use Natural Business Processes • Use existing authentication machinery to grant certificates - transparently • Monitor the use of the certificates to deepen their quality • Add other certificates only when someone gets a real benefit from it • Make public key a natural extension of existing authentication systems

9. Why has PKI been so hard to deploy? • With public key, we have to manage certificates (and private key material), whereas before we didn’t. • With public key, people have to go through metaphorical “fingerprinting”, whereas before they didn’t. • Most companies have no processes for certification • In most cases, there is no instantaneous, tangible reward for the apparent hardship involved with public key deployment

10. Lightweight PKI Based on Metadirectory Automatic and transparent Grows organically, bottom up or top down Simple Overweight PKI Based on a YETA,or worse… A big intrusion and cumbersome Grows bureaucratically Really really complicated LPKI versus OPKI

11. The Authentication Framework

12. Should we start again as angels? Era of authentication as we know it Glorious New Public Key Era Just throw everything out! Free YETA!

13. Or build on who we are? Realistically, authentication protocols will co-exist New Public Key Authentication as we know it

14. VIA builds on information assets Human Resources Public Key Infrastructure Email Infrastructure NT LAN Kerberos Infrastructure Unified Metadirectory Information Capital Authentication Capital

15. … and can extend authentication ... Unified Metadirectory Intranet Authentication Kerberos Existing Authentication Framework Public Key

16. Public Key Applications and Benefits … by being an enabling force Metadirectory Authentication Automatic Deployment of Public Key Existing Authentication Increasing Certificate Quality

17. Synergy - not protocol wars HTTP Radius Kerberos Public Key DNS DHCP Metadirectory -- Inclusive Technology

18. Keys, keys, keys…all you ever talk about is Keys!

19. Public Key - Identifying Yourself • In Public Key, every network participant holds a private key • This private key is central to proving who you are, what you are allowed to do, and what you claim to be true • The storage of this private key is crucial to the deployment of public key infrastructure. Any limitations placed on this storage end up being limitations on all the technology which depends on public key

20. The Directory-enabled Token • A soft token stored in the directory in encrypted form and transmitted to the user under a second session-based layer of encryption • Implements the storage functions of PKCS #11 • When decrypted on the workstation, loads the local client-based crypto engine (CAPI or PKCS #11) • Allows users to access their crypto materials from any workstation • Operates under centralized management

21. A strategy for transition

22. When Authenticated to the Metadirectory ... • A PKI security policy object is consulted by the client • The client automatically generates encryption and signature key pairs if they don’t already exist • The private encryption key is escrowed • The metadirectory issues a certificate for each key binding it to the user’s directory name • The certificate follows all PKIX recommendations and specifies a policy limited to directory binding • The certificate will interwork with certificates from other CAs. User’s Token User’s Token Encryption and Signature Keys Certificate Request VIA PKIX Certificate Encryption Key Escrow Metadirectory Workstation

23. Empowering The Enterprise

24. The PKIX Certificate • PKIX is the preferred profile for X.509 on the Internet • Specifies not only a policy OID, but a link to a Web page in which the policy is defined • Defines and limits the purposes for which a certificate can be used • All of these parameters are configured through a signed directory object belonging to the VIA Certificate Authority. • Can bind email addresses as well as DNs.

25. Special issues addressed in VIA • Renewal for short-term signature certificates • “Valid From” date remains fixed • “Valid To” date may be limited and extended as required by use • Shifting of location in the directory results in a natural expiry, not in a revocation • Binding of user credentials to a hierarchical directory name becomes possible without CRL babble

26. Special issues addressed in VIA • Optional binding of encryption key to a unique and permanent identifier rather than to a directory name • Once again reducing CRL babble • Ability to place access controls on individual certificates

27. The user security policy object • Specifies key type, key size • Specifies which crypto providers the user is allowed to employ • Specifies when keys must be rolled over • Specifies what kind of token should be used (hard or soft) • Specifies whether a soft token should be stored in the directory, on a file system, or both

28. Working with Others - Verisign, Entrust, Microsoft, Netscape • Don’t assume that you will only ever have one set of certificates • Different realms could use certificates produced by others. • Clients and servers will support the Entrust version of GSSAPI. • Zoomit VIA has been tested and functions as an Entrust certificate repository.

29. Getting Benefit

30. VIA and Zoomit API applications PKCS #11 API Zoomit Certificate, Key, S/MIME API PKCS #11/ CAPI Converter PKCS #11 Hard or Soft Token Directory Enabled Storage Token CAPI Zoomit Crypto Adapter (ZCAD)

31. Microsoft Applications Directory Enabled Storage Token CAPI Zoomit Crypto Adapter (ZCAD)

32. Netscape Applications PKCS #11 Hard or Soft Token Directory Enabled Storage Token Zoomit Crypto Adapter (ZCAD)

33. A Metadirectory Benefit - Kerberos Authentication

34. NDS Notes SAP NT The login logjam torments us Mary Moore Insomnia2 • Login is the first point where Mary encounters namespace chaos • This chaos encompasses both who we are and how we prove it • Mary is confused by the chaos, and that confusion costs bigtime Mary Tyler Moore Esoteric21 marym insomnia2 • The promise of distributed computing is jammed by individual vendors’ exclusive directory infrastructures.

35. The Metadirectory Token Names and Passwords Private Key NT Netware Notes Metadirectory Name and Password HR System The Metadirectory enabled password caching service • Zoomit single logon information is stored in the metadirectory • Secret information - optionally be stored in hard or workstation-based tokens • automatically updates a user's password cache • administrators can view and update all proprietary systems through a single common interface • no administrative burden at the desktop • logs you in to our desktops and our existing network operating systems automatically

36. Single Logon and Your Metadirectory Token • With Zoomit's single logon solution, metadirectory-based policy management allows the security administrator to select the type of token employed by each user, and determine whether soft tokens are stored on the desktop and/or in the directory - or group of users. • Security administrators can assess the risks associated with various roles and select the kind of token which is most appropriate. Because private keys and passwords are always stored in a token, it is easy for security personnel to evaluate the cryptographic methods being used to protect secret information.

37. Single Logon with Metadirectory Proprietary Connected Directories Metadirectory User Single Logon Unified Security Administration

38. VIA Intranet Security Infrastructure VIA Single Logon VIA Public Key Infrastructure VIA Kerberos Real-time Authentication Full-Spectrum Solution A full-spectrum solution creates a continuum between the existing authentication infrastructure and new Intranet Security Services