# Presentation: 513490

## DeployingDirectory-EnabledEnterprise-Wide Security

- Luc Clement
- Director of Products,
- Zoomit Corporation
- LClement@zoomit.com

**Deploying****Directory-Enabled****Enterprise-Wide Security**

- Internet Expo
- Business-to-business Enterprise Solutions
- San Jose Convention Center
- February 10,1998

## Zoomit has security objectives ...

- Directory-enabling everything - securely
- Lead in identity management - establishing and managing identities in cyberspace
- Solve the single login problem
- Create metasecurity** **to 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

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

## Redeeming the Evil Twin

- Directory

- Security

- Inclusiveness

## Public Key Infrastructure

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

## 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 (YET Another directory)

- No New Namespaces!

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

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

## LPKI versus OPKI

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

## The Authentication Framework

## Should we start again as angels?

- Era of authentication
- as we know it

**Glorious New**
**Public Key Era**

- Just throw everything out!

- Free YETA!

## Or build on who we are?

- Authentication
- as we know it

**New**
**Public Key**

- Realistically, authentication protocols will co-exist

## VIA builds on information assets

- Unified Metadirectory

- NT LAN

- Email
- Infrastructure

- Human
- Resources

- Information Capital

- Authentication Capital

- Kerberos
- Infrastructure

- Public Key
- Infrastructure

## ... and can extend authentication ...

- Unified Metadirectory

- Existing
- Authentication
- Framework

- Intranet
- Authentication

- Kerberos

- Public
- Key

## ... by being an enabling force

- Metadirectory
- Authentication

- Existing
- Authentication

- Automatic
- Deployment
- of Public
- Key

**Increasing**
**Certificate**
**Quality**

## Synergy - not protocol wars

**DHCP**

**DNS**

**Public**
**Key**

**Kerberos**

**Radius**

**HTTP**

- Metadirectory -- Inclusive Technology

## Keys, keys, keys...all you ever talk about is Keys!

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

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

## A strategy for transition

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

**Metadirectory**

**Workstation**

- Encryption
- Key
- Escrow

- Encryption
- and
- Signature
- Keys

- User’s
- Token

- Certificate
- Request

- VIA PKIX
- Certificate

- User’s
- Token

## Empowering The Enterprise

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

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

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

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

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

## Getting Benefit

## PKCS #11 API

- PKCS #11/
- CAPI
- Converter

- PKCS #11
- Hard or
- Soft  Token

- Zoomit
- Certificate,
- Key,
- S/MIME
- API

- CAPI

- Directory
- Enabled
- Storage
- Token

- VIA and Zoomit API applications

- Zoomit Crypto Adapter (ZCAD)

## Microsoft Applications

**CAPI**

- Directory
- Enabled
- Storage
- Token

- Zoomit Crypto Adapter (ZCAD)

## Netscape Applications

- Directory
- Enabled
- Storage
- Token

- Zoomit Crypto Adapter (ZCAD)

- PKCS #11
- Hard or
- Soft  Token

## A Metadirectory Benefit - Kerberos Authentication

## The login logjam torments us

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

***The promise of distributed computing is jammed by individual vendors’ exclusive directory infrastructures. ***

- Mary Moore
- Insomnia2

- Mary Tyler Moore
- Esoteric21

- marym
- insomnia2

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

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

## Single Logon with Metadirectory

- Unified
- Security
- Administration

- Metadirectory

- Proprietary
- Connected
- Directories

- User Single Logon

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