This paper was presented at the 1997 CAUSE annual conference and is part of the conference proceedings, "The Information Profession and the Information Professional," published online by CAUSE. The paper content is the intellectual property of the author. Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and the source is acknowledged. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the author and CAUSE. For further information, contact CAUSE at 303-449-4430 or send e-mail to [email protected].

Securing IT Resources with Digital Certificates and LDAP

Kent Cearley and Lindsay Winsor
University of Colorado System Office
Boulder, Colorado

Electronic Information Security History

The age of information, commencing somewhere in the late 20th century, is also the age of information assets. Tangible assets are protected by lock and key or physical barrier but these material constraints aren't effective for electronic information assets. We were able to secure information assets fairly well when they could be corralled on mainframe computers. But with the advent of networking, the task of providing authorized access while preventing unauthorized access is exponentially more difficult.

Username and Password Security

A computer's equivalent of lock and key is the username and password. The platform, its databases, and its applications may all maintain records linking usernames to secret password information. This structure relies on a pivotal assumption: if you know your user name, and some secret that only you should know, then you must be who you say you are. There are three standard ways to establish identity: Username and password authentication uses only one factor: something you know. In controlled environments of discrete computers, this might have been auditor friendly. In the open era of the Internet it's a recipe for trouble.

Network Exposure

Networks developed without much thought to security. TCP/IP, the most prevalent communication protocol, was designed around precepts of robust communication rather than secure transactions. While the OSI network model designed a layer between the application and network that could manage security handshakes, TCP/IP left everything above the communication layer to the application. Consequently each application developed its own negotiation strategy. Rather than building a generic, reusable security mechanism, applications relied on proprietary or embedded techniques for shuffling account information across the network to the platform or application for validation.

As a result, on most Local Area Networks and Wide Area connections, usernames and passwords are transmitted in clear text. Ethernets and TCP/IP networks are analogous to telephone party lines. Eavesdropping, or "password sniffing", is easily executed, usually undetected, by a variety of freeware applications. Networks also permit any flaws in platform components to be exploited for access. Sometimes errors are triggered intentionally in routines designed to accept inbound email, telnet, or other "services" to gain unauthorized access to systems. Sometimes legitimate services can be used to exploit the course granularity of file level protections to obtain encrypted password files. Once captured, automated dictionary attacks typically decrypt about 50% of the passwords successfully. With a cracked password the front door is open. Something only you knew is now something a hacker knows and uses to fulfill the authentication requirements.

Tactical fixes to this widespread problem were developed: hubs that scrambled packets preventing eavesdropping, one-time and encrypted passwords, tokens, tickets, firewalls. Each of these new technologies mitigate risks, but the strategic problem is something bigger.

Internet Commerce Requires a Solution

For the Internet to thrive as a collaborative environment and commercial marketplace, a reliable method of establishing identity is required. Internet markets are beginning to take shape with 1.2 billion dollars in online commerce done in 1996, doubling 1995's revenue which in turn doubled 1994's take. Analysts identify customer and vendor authentication and secure transactions as the keys to procuring consumer trust and tapping into the exponential growth of Internet use. As the Web browser strives to become the shopping basket of online commerce, a great deal of commercial mindshare has been directed to this problem.

To be successful, secure Internet commerce must be scaleable and easily deployed (we're talking consumers). It cannot require monolithic account structures or complex multi-cell domains. It must be simple, something not based on a circle of friends but upon trust between strangers. Digital certificates, based on public key encryption, seem to be a perfect fit.

Public Key Basics

Encryption

It's said that encryption has two eras: before public key and after. Public key was a clever technique patented by Diffie-Helman in 1974 (the patent recently expired) and refined into an architecture by Rivest, Shamir and Adelman (RSA). It was designed to securely exchange information between complete strangers. Here's how it works:


 

  1. A user generates a key pair, one public, one private. These keys are related mathematically such that anything encrypted by one can be decrypted by the other. Which you decide to make public and which private is purely arbitrary.
  2. The public key is put out in some public place: a directory, a Web page, in your email signature, etc. The private key remains on your desktop in a password protected file.
  3. When someone wants to send you a secret message, they use your public key to encrypt a message with a public key algorithm.
  4. Once the message is encrypted it can be sent to you via email, a network protocol, or put in a public place.
  5. You retrieve the message and decrypt it with your private key after unlocking the key with the local password. Since the password never leaves your desktop, it can't be exposed on the network. This is an example of two factor security, something you know (the password to unlock your private key) and something you have (the private key on your machine or cryptocard).

Digital Signature

If you used your private key to encrypt a message, anyone could decrypt it using your public key. What good is that? Well, it proves you are the one that encrypted it and it hasn't been altered since you did so. This forms the basis of the digital signature. Digital signatures can be used to sign electronic documents, ensure their integrity (by encrypting a hash or checksum), certify application code and components, setup secure topologies on top of public networks, and encrypt data.

Symmetric Keys

Before public key, a single key was used to encrypt secret messages. This was called a symmetric key. Symmetric keys had to be in both parties hands before messages could be exchanged. The biggest problem was how to get the symmetric key to the other party securely. This was the problem public key solved so elegantly: a way to get a secret key to someone without falling into the recursion of them needing a secret key to have a secure enough channel to get a secret key ... etc. (This is why Escher is popular with people who've been in this business long.)

Session Encryption with Symmetric and Public/Private Keys

While the public/private keys could be used to encrypt sessions, in practice they require significantly more computational overhead than a symmetric key. Instead the public key of one party (say a web server) is used by another party (say a web browser) to encrypt a symmetrical key for the session. The encrypted symmetric key is sent back to the server, which uses its private key to decrypt it. Now, both intended parties have the symmetric key and no one else can get it. The public/private keys are just used in the initial handshake to establish a unique session key.

Certificate Basics

Certificates 101

By itself, public key technology doesn't provide authentication. Just because someone creates a public key and makes it available as the key for "Jane Doe" doesn't necessarily mean this is Jane Doe's key. How do you make sure that a given key is reliability associated with an individual identity? This is the function of a certificate. A certificate is a public key that has been digitally signed by a recognized authority attesting that the owner of the key is who they say they are. The process that does this for a living is called a Certificate Authority or CA. So here's the bootstrapping problem again. A CA signs a user's public key with its own private key (see digital signatures to recap how this works.) But how can you trust that the CA's public key really belongs to the CA? One way is by fiat. Microsoft and Netscape browsers both come with a number of CA's pre-accepted. Any certificate the browser encounters signed by these CAs is assumed to be valid. Of course, if you are operating your own CA, you're not likely to be on the "in" list. This adds a few more wrinkles. The client's browser needs to accept your CA first, before it can accept any certificates you might have signed for your organization. The process is relatively painless, dialog wizards walk a user through the process of dynamically accepting and installing a new CA, but it is definitely far from seamless.

A Place for Everything: LDAP

Public directories are essential in managing certificates. We need a place to make certified public keys available and to record when they are no longer valid. LDAP 3.0 is proving to be an effective repository for that information. LDAP (Lightweight Directory Access Protocol) has several characteristics that make it especially attractive. Certificates and LDAP take authentication out of the application and off the platform and put it on the network. LDAP can help do the same for authorization. Authorization information is presently maintained in many locations for each user. Email accounts, databases, file server accounts, calendaring systems, web applications, other applications all store access information. Tracking down that information when it needs to be updated can be difficult, error prone, and time consuming. Products have been designed to artificially glue all the known authorization files together under a single-signon veneer, but the real fix is to treat authorization as a network service available to all applications, databases, and servers. LDAPs' fluent access capabilities make it a prime candidate for providing this security service as well.

Public Key Infrastructure

Managing certificates is performed through an architecture called the Public Key Infrastructure, or PKI. PKI is made up of technology, standards, and policy. Policy is a species of documentation that plays an important structure role in the planning and implementation of a PKI. It defines what standards and technology will be used, and how the technology will be managed. As technology, and standards change, so the PKI and its organizing policy will need to change.

PKI Technology

The Certificate Authority process operates on certificate server software. It needs to communicate with one or more LDAP repositories. The certificates are used by certificate aware web servers and web browsers. They can also be used in certificate aware email and applications. Few applications, beyond the Web browser, are currently certificate aware. But notable exceptions are emerging: Oracle8 enables certificate based authentication to its broad client/server base and several products, including Peoplesoft, will be able to use certificates through the GSS-API with Tuxedo. Most of us operate in heterogeneous environments with servers and browsers from a variety of vendors. So understanding key PKI standards helps in mapping integration of components into a certificates support fabric.

PKI Standards

The figure below maps the major standards that glue together components of a PKI. Most of them deal with ways information about certificates is encoded and shuttled around. These links are important when you start considering plug-and-play services for your PKI and may help alert you to products that may have a proprietary hook in a key pinion of the architecture. There are other standards that define the make up of certificates themselves, negotiation of algorithms during various handshakes, etc. They do not appear in the diagram.

 rectrectrectrectrectrectrectrectrectrectrectrectrectrectrect

PKI Policy

PKI policy exists within the general security policy environment of an organization. Digital certificates need a well established environment of good general security policy and procedure before they can be effective. The start of a PKI project is an excellent time to review your organization's overall policy and procedure framework. Are your policies up to date, comprehensive, well communicated? Are your security staff knowledgeable about the security policies and in the habit of consulting and maintaining their procedure documentation? Have you informed users of their security responsibilities? A culture that understands the role of policy in security will have an easier time implementing a PKI and digital certificates.

Policy Defines the Level of Assurance Provided

Digital certificates can provide a variety of levels of assurance of the authenticity of the electronic identities of people, resources and communications, depending on the policies that guide their creation and use. A policy that requires minimal verification of a person's identity before a certificate can be issued provides a much lower level of assurance than one that requires independent verification of identity by a third party. A policy requiring the issuance of revocation lists daily provides more assurance than one that only requires weekly revocation. For some purposes, relatively low levels of assurance are sufficient and the costs associated with higher assurance can be avoided. High risk systems and data need a high level of authentication. Each policy needs to be tailored to the purpose for which the certificates will be used. An institution may issue certificates conforming to several different policies, some of which may be developed by other organizations

Procedures Implement Policies

While policies state what is to be done, procedures state how it will be done in a particular implementation. Each Certificate Authority needs a Certification Practices Statement (CPS) that may include different procedures to be followed to provide different levels of assurance for different purposes. The CPS defines the personnel and technical configurations and the processes that will be used to accomplish each of the requirements of a policy. It is useful to use exactly the same outline for a CPS as was used for the policy it implements to assure that every point of policy is addressed. However, when a single CPS relates to multiple policies, that may not be possible.

Policy Chains, Policy Webs

CAs can be stand alone or they can relate to other CAs through chains or webs. Stand-alone CAs "self sign" their own certificate and can operate under policies and procedures they establish for themselves. In these cases, the policy and procedure information can be combined into a single document.

If your CA's certificate is signed by another CA, it is part of a CA chain or hierarchy. The administrator of the CA that signs your certificate may want to review your practice statement to be assured that your procedures are adequate to protect your CA and to create necessary audit records. The signing CA administrator may also check that your CPS is adequate to implement a specific policy. At the other extreme, the signing CA administrator may review none of your documents, simply contracting with you to create your CA certificate with no policy or procedure review.

Two CAs who are members of separate hierarchies may issue certificates against essentially equivalent policies. If a single user needed to access multiple resources, some of which recognize one CA and some recognizing the other, it could be helpful to the user for the CAs to establish a trust relationship. The Policy Mapping Extension field defined in the X.509 v3 certificate standard is intended to hold trust information, but servers and browsers (let alone applications!) aren't able to use those fields yet. At present, each relying resource (server or browser) must be instructed to accept certificates from either CA. If applications develop the capability to use this field, CAs could be directly connected into a web of trust without having to instruct all resources about all CAs.

Policies and Procedures Inform Certificate Users

Relying parties, things like web servers or browsers that accept certificates for authentication, need to review policies to understand what level of assurance the certificate provides. Certificates issued under one policy may meet the needs of the relying party while those issued under another policy may not.

Subscribers, entities such as web servers or people that have been issued certificates, need to be informed about policies and procedures because they include requirements subscribers must meet such as how to protect their certificate unlocking password.

The specification for X.509 v3 certificates defines Certificate Policy Extensions to record and communicate policy and procedure information. However, since applications and web browsers currently have limited capability to using policy extensions, organizations that operate CAs also use other mechanisms to disseminate information about their policies and procedures. Subscribers can be informed by adding the URL for the applicable policy and/or CPS to the certificate request form or instructions. Relying parties can be shown the URL when the certificate is displayed.

What Needs to be Addressed in Policy and Procedure?

At this time, there is no standard for what must be addressed in a Certificate Policy or a CPS. Various PKI service providers have developed recommended frameworks for policies and procedures. The PKI Working Group of the IETF issued an Internet-Draft containing a proposed framework for Certificate Policies and Certification Practice Statements on July 3, 1997. Even if adopted, the framework would become an informational RFC, i.e., its use will be optional. So it is likely that various PKI vendors will support different approaches to policies and procedures. A vendor's approach should be one of the factors considered in selecting products.

In preparing to develop our own CPS, we reviewed all of the policy and procedure proposals we could find. We then developed our own format that addresses the topics that seem important to us in the sequence we think would make the most sense to our users. As we learn more about the technology, as we expand into new uses for certificates, as we seek cross certification with other CAs, we expect the policy to evolve significantly. Some of the policy topics that presented particular challenges to us are discussed below.

Legal responsibilities and limitations for CAs, subscribers, and relying parties;

We began early to address legal issues, but quickly found ourselves in need of professional advice. We have sent a query to University legal counsel seeking help in identifying warranties, limitations on warranties, disclaimers, loss limitations, and other policy statements that will inform users about the certificates we issue, and that will appropriately limit University liability in the event of a breach of certificate based security.

Certificate lifecycle issues:

Communication of certificate, policy, and procedure information;

Our policy and procedure information will be published on our web site. We will require certificate applicants to attest that they have read the CPS summary and will seek to make highlights of the CPS available to web browsers when they attempt to communicate with a certified server.

Technical security for the CA;

The certificate server and its CA software become a major point of risk in a PKI. Stringently limiting access to the CA through minimizing network connections, software firewalls, and carefully maintained access privileges is essential.

Procedural and staffing security for the CA;

Our policy addresses backup procedures and schedules, and recovery processes, all of which will be tested before we begin to issue certificates. We've defined separation of duties and determined how to implement them with part-time assignments to multiple staff.

Termination of the CA;

What should happen if our CA were to go out of business? What amount of notification should be given to subscribers and relying parties? How will the records archives be maintained? Our CPS is attempting to plan for this occurrence.

Policy and procedure maintenance;

Changing the policy or procedure could change the level of assurance provided by certificates issued under the policy and could affect the willingness of some resources to accept the certificates. A process for notifying concerned parties of proposed changes, for receiving and processing comments, and for approving and publishing final changes is specified in our CPS.

PKI Issues

There is at least one significant institutional political issue that addresses the role digital certificates will play in an institution's enterprise security architecture. There are several competing technologies, including PKI, that could be an enterprise solution by themselves. Will an institution choose a single technical solution or will it decide to integrate two or three technologies, using each where they provide the best answer? PKI and Kerberos are leading contenders in higher education. While Kerberos is more proven and widely implemented in higher education, it isn't a good solution for Internet commerce. Several institutions have statements of direction or actual implementations that recognize a role for both mechanisms or a commitment to study how they should each be used. Technology may also assist in supporting both. An enhancement to Kerberos, since release 5, introduced public keys as native components of its architecture. Microsoft's NT 5.0 also has the ability to map Kerberos tickets to digital certificates allowing users to seamlessly participate in overlapping security models.

Besides local politics, it will be important, even for academia, to pay attention to legislation that may affect a PKI's operational requirements. Federal legislation related to key-escrow is targeted to those managing PK directories and issuing certificates. State legislation on digital signatures targets the type of assertions PKI policies make about using identities to approve transactions for goods and services. Both may affect a University's strategy, particularly in their interfaces to commercial services and extranets.

We also face a market issue in that PKI is to some extent a captive of the browser wars. To date, the major contenders seem to be supporting most certificate standards. However, that doesn't ensure complete interoperability.

Other issues that are part and parcel of deploying digital certificates include:

This is a partial list! Threaded throughout this list are issues of technology, standards, policy, and politics that must all be resolved in some phase of the PKI implementation.

Product Maturity

PKI is past the early adopter stage, but is still cutting edge. Large scale implementations exist, like the Government of Canada's Public Key Infrastructure, but most of the large implementations have been done with proprietary PKI suites, like Entrust. A number of vendors are selling the pieces to construct this suite yourself. Netscape provides certificate servers for issuing your own Digital IDs for clients, servers, S/MIME, object signing, etc. and they provide some level of integration with LDAP. Microsoft has a public key framework built into NT 5.0 using certificates and LDAP directory services. A number of standards have been defined and unevenly adopted by products governing how IDs move between pieces of this architecture, but there are rough spots. Developing your own PKI at this point takes a degree of faith that, due to the commercial momentum, these pieces will play together.

The ability of applications and databases to work with network based authentication and authorization services is still in early stages of development. Netscape, Microsoft NT 5.0, Lotus and other vendors are using LDAP stored authorization information. Some transaction monitoring systems such as Tuxedo are in early stages of providing this capability. But more development is needed before many client/server and legacy applications will be able to take advantage of external security services.

First Steps

We have chosen a narrowly defined purpose for our first venture into certificate territory. We intend to issue certificates to web servers so that they can authenticate themselves to browsers and so communication between the server and browsers can be encrypted. Our primary reason for securing these communications is to protect student admission, registration, and payment data, but we expect it will serve other purposes as well.

We are using Netscape's certificate server and LDAP to create our PKI, although we expect to include servers and browsers from a variety of vendors, among them Netscape, Microsoft, and Stronghold. We will sign our own CA certificate which means that both servers and browsers will need to accept and install the CA certificate and the server certificate. This will require that we carefully develop user information materials to help browser users understand who is operating the CA and why it can be trusted.

We began developing our policy and Certification Practice Statement early in the project and found that helped us identify technical concerns as well. We are keeping our policy and our technology as simple as possible at this stage to increase our chances for success. Later, we may change both the technology and the policy as we undertake to meet new needs, as the technology and theory mature, and as we learn more about certificates, LDAP, and PKI.

Where is this leading?

As workflow and groupware emerge into the mainstream, we can take advantage of certificates that have been used to authenticate client sessions to provide also for non-reputable signatures. As we begin taking advantage of distributed processes, we can reuse the same mechanism for authenticating executable content. Middleware services like transaction processing, CORBA, and messaging provide standard security exits in the form of the GSS-API which now has commercial support for certificate based authentication. At the same time we are encouraged by the directions of Java's JDK which incorporates X.509 into the fabric of the standard Java distribution, Microsoft's CryptoAPI and use of X.509 and LDAP in NT 5.0. SET initiatives are finally taking off, DNSafe is poised to address critical issues around reliable use of Domain Names as part of network authentication. Finally, CryptoCards and readers are beginning to be incorporated into standard keyboards and PC peripherals. There is significant momentum that is rapidly completing, enhancing, and extending both the technology and the theory of PKI.

Luckily, you don't have to tackle all this at once. A PKI can, and probably should, be implemented incrementally. The "Geoffrey Moore Chasm" (Crossing the Chasm, HarperBusiness, 1991) advises that you navigate gaps from early adopter to market majority with bridging techniques particular to the stage of adoption the technology has reached. By working with components of PKI and adhering to standards for interoperability, you should be able to navigate these gaps strategically. PKI's promise as a universal fabric to authenticate users and LDAP's ability to centralize authentication and authorization information can be realized in practical steps that return immediate gains. Unification of standards around new technology, as is occurring with LDAP for directory services for example, requires the new technology to be adaptable enough to encompass and typically extend the more proprietary or limited technology it replaces. In the age of collaboration, it also must serve a global, rather than localized market, and it must be propelled by both mind and market share. All the indicators point to PKI as meeting these requirements and digital certificates becoming the passport for secure transactions across a broad spectrum of services.

Endnotes:

Policy References

X.509 Certificate and CRL Profile Internet-draft has a complete discussion of policy extension fields.  Note that this is a work in progress and may change at any time.

One vendor's view of policy and procedure requirements is contained in a white paper from Entrust Technologies titled "Certificate Policies and Certification Practices Statements" by Sharon Boeyen, dated February, 1997.

The Certificate Policy and Certification Practices Framework Internet-draft provides an explanation of subjects that might be addressed in policies and CPSs, as well as a possible structure for those documents.  Note that this is a work in progress and may change at any time.

A draft policy statement for the Government of Canada Public Key Infrastructure follows the framework proposed in the IETF Internet-draft.  It is very helpful to see the framework fleshed out.

The CPS for Verisign is a live, working practices statement.

Our CPS draft is in preliminary stages of development!  It still acknowledges what we don't know as much as specifying what we think we know.  We are trying to design a document that is as readable as possible.

Other institutions who are  addressing the interaction of PKI and Kerberos include MIT, University of California (Office of the President), and the University of Iowa.
 
Technical References

The main page for PKCS, or Public-Key Cryptography Standards developed by RSA Laboratory  information can be found at:

Individual PKCS Standards Referenced in: SSL 3.0 Protocols supported for Certificate Download in Netscape

LDAP

X.500 Standards (including X.501 and X.509 --- pay per view)

A Layman's Guide to a Subset of ASN.1, BER, and DER

Transport Layer Security. IETF draft for standardizing SSL 3.0.

MIME. RFCs for Multipurpose Internet Mail Extensions

Oracle8 Security. Oracle's new security capabilities and use of certificates for authentication.

Kerberos Integration

Crypto APIs X.509v3 Extensions:

    PKCS #6: Extended-Certificate Syntax Standard
    PKCS #9: Selected Attribute Types
    Netscape Certificate Extensions

[Comments] [Search] [Home]