Assessing the Business and Technical Aspects of Public Key Infrastructure Deployment
Articles and Tips: article
Senior Research Engineer
Novell Developer Information
01 Oct 1998
Thanks to Bob Jueneman and Toger Schell for their assistance with this AppNote.
Organizations looking for cost-efficient and easy-to-manage security solutions will be interested in this AppNote on the PKI and other cryptography services in NetWare 5.
- Introduction
- Cryptography Perils and Pitfalls
- NetWare 5 Security Architecture
- A Closer Look at Novell's PKIS
- Looking to the Future
Introduction
As increasing numbers of networks move from the traditional client-server LAN to the client- network paradigm of distributed services, new scaleability and manageability issues will inevitably present themselves. One critical issue that must be dealt with as networks expand--and especially as they embrace the "open" environment of the Internet--is the need for cryptographic services.
Cryptography is routinely used to perform user authentication at login time, where it shows increased (but not always certain) ability to identify end-users or the machines they work with. Cryptography is also a fundamental part of creating and maintaining secure information to adequately identify users in electronic business environments. Many user activities that are necessary for external collaboration require cryptographic protocols such as SSL (Secure Socket Layer), S/MIME (Secure Multipurpose Internet Mail Extensions), and IPSec (IP Security).
In addition to the network management issues arising from the use of cryptography in an open network environment, there are significant business issues that have direct implications on a company's operational costs and return on investment. To help both network managers and business people understand these implications as they affect manageability of the entire network, this AppNote covers some of the underlying problems of using cryptography in business, as well as Novell's solutions to those problems.
Specifically, this AppNote covers:
The perils and pitfalls of using cryptography
The NetWare 5 security architecture and how it relates to cryptographic services
Novell's Public Key Infrastructure Services (PKIS)
Novell's internal and external Certificate Authority (CA) capabilities
This AppNote assumes familiarity with basic security concepts such as authentication, certificates, and digital signatures. For more information on these topics, visit the Novell Directory Services (NDS) security Web page at:
http://www.novell.com/products/nds/security.html
Cryptography Perils and Pitfalls
In any organization connected to the Internet, it is important to give immediate attention to any specification or request that requires cryptography. A lack of understanding about the limitations of cryptography can have adverse consequences from both business and technical standpoints, as will become more apparent as we go along.
Business people may be surprised to learn that cryptography does not necessarily guarantee either proper or adequate levels of authentication. Network managers may be dismayed to discover that many of the underlying problems introduced by cryptography are not resolved by a public key infrastructure (PKI), and that a PKI actually raises its own issues regarding cryptographic key management. Improper management of cryptographic keys can not only halt business activity on the network, it could leave organizations susceptible to data loss or without access to vital information. Even the most secure electronic transactions pose a significant threat to business if they are not reversible.
To further complicate the problem, many of the tools commonly used to work over the Internet, such as browsers, web servers, and the Lightweight Directory Access Protocol (LDAP), mandate the use of cryptography. Yet the sobering reality at present is that imposed methods for protecting the "secret" used in the cryptography are very weak. In fact, one of the leaders in the security community has described cryptography as "the opiate of the naive." It might make people feel better about their information security, but without a complete infrastructure it is not particularly effective.
To help business and network managers understand these issues and others that come into play with cryptography, this section presents an overview of how cryptography has developed and where its strengths and weaknesses lie.
Cryptography vs. Security
In the early days of PC networks, when the typical computer was powered by an Intel 8086 processor running at 4.88 MHz, cryptographic mechanisms were largely homegrown—but they worked. Public and private key pairs were typically generated in a proprietary fashion, and digital certificates were minted as needed. Some of the longest key lengths that could be tolerated were 256 bits to 312 bits, which was considered extremely good cryptography. While some development houses had started to think about certificate hierarchies, few were ready to tackle the more complex issues such as cross-certification between certificate authorities.
As for the typical computer user, none were interested in notions such as authentication, authorization, and single sign-on. The ink in the U.S. government's security standards documents was barely dry, and the concept of a trusted computing base (TCB) had yet to be introduced. Security infrastructures, directory services, and auditing were just a gleam in some programmer's eye. Security was simply cryptography, and that's all anyone had to deal with.
Today, of course, computer security has come a long way. Processor power and network capabilities have increased dramatically, as has the need to intercommunicate between companies. Electronic commerce and virtual private networks are becoming a reality, while governments and other organizations requiring high security (especially for value-laden transactions over the Internet) are implementing "trusted" Class B3 and C2 evaluated systems. In Germany, the use of E4 rated systems (Class B3 equivalent) is mandated by law for creating electronic certificates, and user machines to use these certificates must be at least E2 rated (Class C2 equivalent).
Through all these advances, cryptography itself has evolved, especially in the area of public key cryptography.
One-Way Algorithms
The cryptography we use today for PKI is based on asymmetric encryption algorithms that require two keys: a public key known to everyone, and a private or secret key known only to the recipient of the message. These encryption algorithms are based on mathematical computations that are fairly easy to perform in one direction, but extremely difficult to reverse. A good analogy is making an omelette. You can easily crack some eggs, cook them, and serve the resulting omelette to a friend. Your friend can enjoy the omelette withing having to know what the original eggs looked like. But if your friend wants the original eggs back, you have a real problem.
This is much like the process of public key cryptography. If you want to send a message to your friend, you use one part of the key pair (your friend's public key) to encrypt it. As long as the friend has access to the other part of the key pair (his private key), he can successfully decrypt and read your original message. However, it is a very difficult problem for you to deduce what your friend's private key is, given just the public key.
The success of public key cryptography hinges on the mathematical difficulty of factoring very large numbers. It is a simple process to multiply two numbers together, even if they are fairly large. However, if you give someone the product of two large prime numbers and ask them to figure out what two numbers you used to arrive at that result, they would have a very difficult problem on their hands. With the computing power currently available, the biggest numbers that can be factored are somewhere around a hundred digits long. Assuming that a digit is about 3.3 bits, that means a skilled mathematician could conceivably factor a 300-bit number. As long as keys are longer than that, we are probably secure with cryptography based on commonly-used public key algorithms such as RSA and others.
Of course, no cryptographic system is 100 percent safe. A lot rests on your ability to keep the private key secure. And as computers become more powerful, keys will have to get longer to keep the level of factoring difficulty ahead of the curve. If you were to chart the success of factoring vs. number length over the last 400 years or so, you would see a straight line. It is likely to continue in a linear fashion, because cryptographic algorithms are improving at roughly the same pace as advances in computing power and decryption technology.
On this basis, you can extrapolate how long a given key length will remain sufficiently strong to safeguard your confidential information. The rule of thumb for cryptography says that instead of trying to make encryption algorithms that are 100 percent crackproof, you merely need to make them more costly to crack than the worth of the information you are protecting. If it will take thousands or millions of PCs running in parallel to factor the primes, even the most determined hacker is going to think twice before making the attempt.
Certificates and Certificate Authorities
Not all algorithms used in "public key" cryptography are one-way. Under the covers, algorithms are used that can be run in either direction, as in symmetric key cryptography. Other times, public key cryptography can be used in a reverse direction. For example, suppose you wanted to prove to another person that you know something. You can take some text, such as "Mary had a little lamb," and perform the RSA decryption operation on that text using your private key. You then send the garbled text to the other person. Although the recipient can't read your message, he should be able to look up your public key in some type of directory (an online listing of public keys or a printed version), and then perform the reverse encryption operation on the text using your public key. If everything works okay, something recognizable pops out, such as "Mary had a little lamb" or a specified checksum.
From this exercise, the recipient of your message can have confidence in two things: first, that the text of your message has not been changed since you "signed" it; and secondly, that you did in fact sign it"or at least that someone who had access to the private key associated with your public key signed the message.
For an additional layer of confidence, we must rely on a three-way binding. To do this, we invoke the services of a third party that we both trust. The third party takes the public key that you want to represent as yours, and associates that public key with some piece of information. Typically this might be your name, but it doesn't have to be. It could be some other attribute such as "this person is cleared to enter the building between 8 and 5." In a business context, it could be an X.500 name type such as:
.CN=Rich Lee.OU=Developer Services Division.O=Novell.C=US
Now the third party takes this identifier, signs it along with their public key, and calls the result a certificate. The certificate is then bound with the third party's own signature to safeguard the information against any further tampering.
In essence, this is what a certification authority (CA) does. It signs two pieces of information—the identify (with any additional attributes) and the public key—and binds them together with its own signature. You now have a three-way binding that can be trusted, at least as much as the technology and the integrity of the CA can be trusted. However, we still haven't fully solved the problem of how to prove the public key signature was okay.
Certificate Tree
The answer to this CA identity problem lies both in the form of the certificates and in the structure of the "certificate tree" or chain. The only way to ensure the validity of one CA is to involve another, more trustworthy CA. Thus you can climb the certificate tree and validate the CA's public key at some higher level. But eventually you reach the logical "top" of the tree, which by some inverted logic we call the root.
At some point in this process, we turn over the responsibility for key integrity to someone else. For instance, we might just give out a raw public key and let anyone who wants to send it to others worry about protecting it. This might not be a good idea, since if the public key is changed or if it is replaced by something else, you will no longer be able to substantiate that the public key is yours. You also won't be able to use the master public key for your application to validate this certificate tree, since normally the problem of key integrity is solved with a self-signed certificate, so the subject and the issue are the same thing. Typically, the relying party has to install that public key with its self-signed certificate in their browser or some other application.
Since this certificate is going to be the basis of trust for all subsequent dealings, you hope its binding was done in a "trusted" manner. The only way to know if it is the right key is to print out the "fingerprint" of the certificate. If it matches the publicly published fingerprint, you know you have the original key.
At present, most applications tend to have a self-signed certificate which they install in browsers or S/MIME packages. At recent count, there were nearly 50 different self-signed certificates being distributed by browser manufacturers (Netscape, Microsoft, and others). This is cause for concern, as it is difficult enough to know the competency of one or two CAs, let alone 50.
Go ahead and try it for yourself. Start up your browser, click on the security icon, and see how many certificate authorities are listed. An example is shown in Figure 1.
Figure 1: List of certificate signers from the Netscape Communicator Web browser.
Since there are probably many more entities listed than you could possibly be familiar with, how do you know which you can trust? Ideally, you should pick one or two CAs that you know something about. If your system is in the United States and you know what the US law is, you might pick one or two US-based CAs. If you are in Australia, you might pick Australian Post. If you are in Canada, you might pick Bell Canada. At any rate, you should select the most reliable CA you can find, preferably one whose laws and administration you know something about.
The Importance of Trust
Not all those who are minting certificates necessarily understand the security issues outlined above. It is imperative for certificates to be minted only by a high-quality process using strong cryptography within a TCB. If you don't have the underpinnings necessary for the computer to establish trust, it is possible for someone else to mint a certificate that is indistinguishable from yours, even though you may have thought yours was created in a sufficiently secure environment.
Most approaches to network security involve locking doors, providing physical controls, and other administrative measures to make sure outsiders can't access your data. Such controls are important, but they only protect against some of the more unlikely threats. For example, if someone were going to break in and steal data from your server's hard disk, they would have to haul off a megabyte or two to get anything worthwhile. Yet when people start using public key cryptography to exchange keys over the Internet, they ignore a much larger risk. Many simply encrypt their material and send it out over the wire, even though they do not know for certain who the receiver at the other end is. While it is true that transmissions over the wire can be cryptographically sound, all an intruder has to do is inject a Trojan Horse program to leak 64 to 128 bits of information—your private key. From a would-be attacker's standpoint, it is just too easy.
For all the cryptographic packages currently available, there is no simple application-level solution to the problems discussed above. Most people have no control over the quality of the cryptographic implementation they use. And even the best cryptography toolkits are not secure when they are loaded on a computer running DOS, Windows or any other desktop operating system. You cannot just assume you know about all the kinds of viruses, Trojan Horses, and other problems that might be in the operating system at the time you generate a private key.
For example, suppose you have a PC running Windows, and in the middle of generating your private key, a context swap occurs. All of the data currently in memory is written to the hard disk, including your partially generated key. You can bring the data back later on and finish the process, but what is left behind on the hard disk? And what if that new patch you downloaded the other day had been hacked to include a Trojan Horse that is designed to search your hard disk for leftover secrets?
Hopefully this discussion has shown that security and infrastructure issues must be dealt with from the very foundation of the system. They simply can't be added on afterwards. This is why in NetWare 5, Novell has incorporated into operating system itself a Public Key Infrastructure Service (PKIS) that has been carefully engineered to meet the kinds of criteria that security- conscious customers will need. The remainder of this AppNote describes the NetWare 5 security architecture, focusing particularly on the components of the PKIS.
NetWare 5 Security Architecture
In the past year, Novell has shown itself particularly adept in the deployment of a public key infrastructure, especially as it relates to cryptographic management. This service is built on a coherent architecture and provides a uniform set of security principles to Novell's customers. In turn, businesses can determine their own policies for how their users can handle their PKI needs.
A Coherent Architecture
An architecture should not be a mere collection of software pieces that have been thrown together haphazardly. In order to reliably provide the types of services noted above, there has to be a coherent security architecture in which the pieces fit together usefully for the customer. Novell's new security architecture for NetWare 5 is based upon the relationships that exist between the different pieces, with all the parts working together smoothly in a cost-effective way to ensure one of the principle value propositions for all Novell products: low cost of ownership.
Figure 2 is a graphical representation of the NetWare 5 security architecture and how its components fit together. Each component is discussed briefly after the figure, starting at the bottom and working up.
Figure 2: The NetWare 5 security architecture.
System Platform
Since Novell's PKIS uses NDS, these services will of necessity follow wherever NDS goes. Currently the main platform for NDS is NetWare 5. However, as NDS evolves to the Windows NT and Unix platforms, the PKI services will be available there too. Thus, the platform is a way in which Novell can carry the PKI forward so that Novell and our customers do not have to start all over again in different environments.
Security Infrastructure
On top of the system platform is the security infrastructure. This infrastructure provides the basic building blocks that must exist within the operating system if anything beneficial is going to happen. Authentication, authorization, administration, cryptography, directory, and audit services all fall into this layer.
Authentication. Authentication has always been an important part of Novell's security infrastructure. The importance of authentication to the overall ability of the network has been noted throughout the industry, and its role in NetWare has been elucidated in many AppNotes. (See the November/ December 1997 special issue on security for more information.)
Authorization. On the basis of authentication, NetWare also provides for authorization, which is the permission a user or process receives to do certain things. Authorization is an important part of determining who should have access to what objects, whether they are the containers in an NDS tree or the file systems on NetWare servers.
Administration. Unlike other industry contenders, NetWare provides centralized administration for its PKI. NetWare uses the administration infrastructure not only to administer the PKI, but as an enabling technology for the deployment of cryptography.
Cryptography. Public keys are created by cryptography. Therefore you cannot have a public key infrastructure without cryptography. NetWare 5 provides a coherent set of solutions via the cryptography infrastructure.
Directory. The directory service, NDS, is the foundation on which the public key infrastructure and other components are built.
Audit. Of course, a security infrastructure needs to include audit services. It is vital for businesses to be able to monitor what actions people have taken. Whereas in the past audit services have been included as an inseparable part of NDS, advanced audit services are being identified separately in NetWare 5 so that other entities besides NDS can use these services.
Security Services
On top of the infrastructure plumbing, NetWare 5 offers a set of security services. These are the exposed services that are available to developers and end-users from the infrastructure.
NICI. The Novell International Cryptographic Infrastructure (NICI) serves as the basis for many of NetWare 5's security services. Through NICI, cryptographic services will be made available for both server and client use through a standardized Software Developer Kit (SDK). Developing applications to the NICI Application Programming Interface (API) relieves developers from having to include cryptographic code in their products. It also allows multi-national corporations to use the same NICI-based application worldwide because NICI will control the encryption policy and usage.
SAS. Secure Authentication Services (SAS) are the authentication services that are exposed to developers and users, as opposed to those found in the plumbing layer. Later in the AppNote, you will see why developers and users can get significant benefit from the way in which Novell exposes these services.
CCS. Controlled Cryptographic Services (CCS) is an interface application developers can use to incorporate cryptography into their applications without having to do the actual cryptography or learn international laws and cryptographic regulations.
PKIS. Novell's PKI Service (PKIS) is the focus of this discussion. It uses NDS, the directory service which NetWare provides. Novell's PKIS will be discussed in more detail later in this AppNote.
SSO. We also have a secure single sign-on (SSO) service, which Novell has traditionally called "background authentication." It is a very powerful and useful single sign-on capability.
AAS. The Advanced Audit Services (AAS) will provide an interface for developers to use Novell's trusted audit system.
Trusted Computing Base Boundary
In order for these security services to be effective, they have to be protected by a security perimeter. In Figure 2 this is shown as the Trusted Computing Base (TCB) boundary. The components that are inside this boundary cannot be tampered with without affecting the overall security of the system. Thus in NetWare there are mechanisms to protect and control them.
SDKs
However, if the security services remain inside the TCB perimeter, they are of no use to anyone. To make them useful, Novell provides a security SDK for application developers. This reinforces Novell's commitment to developers and provides the tools external developers will need to build products that take advantage of security and PKI services.
Applications
Of course, it is mainly applications that are going to use these security services. For example, the next release of Novell's GroupWise collaboration application will be tightly integrated with NDS. Address books and other applications will leverage the basic infrastructure. Since these services are based on NDS, you get the ability for the authentication that comes with NDS. This means that in some future product release, additional capabilities for single sign-on with GroupWise can expand and strengthen the existing single sign-on capability.
Other applications, such as the next release of Novell's BorderManager, will have secure authentication services that include SSL. In order for SSL to work, you have to have a PKI. It is exactly the same PKI services discussed here that BorderManager uses to provide the PKI services for the server. This is a good example of how having these services together in a seamless way gives you an architecture that makes sense.
Again, administration is highlighted as an application, since we use NWAdmin in NetWare 5 as the basis for administering the PKI itself. In the future, administration services will be expanded for the Java environment in ConsoleOne, as well as for third-party applications which can leverage the PKI.
Benefits of Novell's Security Architecture
It is true that many of the components of the NetWare 5 security architecture are available from lots of different places. It is also true that other vendors offer similar components under the guise of a security architecture. However, as mentioned earlier, it is important that an architecture be coherent and that it provide a workable, cost-effective solution to real business problems.
To continue in our vein of establishing a business case for Novell's security solutions, here are some of the differences between Novell's security architecture and some of the "market-tectures" being proposed by other vendors.
A Real PKI Service. Assuming you have reached the point where you want to provide a PKI service, how would you go about doing that? Well, you could start by purchasing a prepackaged PKI someplace and installing it on your computer. Since PKI is a way to produce a certificate from some kind of certificate store, you've got to have a place to store your certificates. So you buy another kind of product: a box to hold your certificates, perhaps both private keys and public certificates. Now you've got your certificate management right there in that box.
Of course, now you've got to have a way to actually create certificates and get them signed. By the way, you also need a cryptography toolkit to perform cryptography in the certificate creation. You also need a Certificate Authority. So it's back to the store to buy three more pieces to your PKI puzzle.
Now, as a network administrator, you want to provide users with a single sign-on (SSO) capability. To do so, you need a certificate for your server, so you pay a certificate provider the going rate of $400 to create such a certificate for you. But you also want LDAP and SSL. Unfortunately, you can't use the server certificate you just paid for, because there is no infrastructure to do that. You can't get to your certificates from the client LDAP. You can't even access other services because you've got your own little proprietary certificate management protocol. So you spring for another server certificate to use for LDAP . . . it's only another $400.
Next, you find that you need a web server. But again, you can't simply take your LDAP certificate and use it for your web server. So you end up paying another $400 to your favorite certificate provider to get the web server you wanted.
While the above scenario may seem a bit farcical, it does point out some of the disadvantages of working in a non-coherent security environment.
Where you get your certificates is not Novell's business; we're not a certificate authority. However, whatever certificate provider you select—whether internal or external—should work with our PKIS. Once you have the certificate, you should be able to store it in the Directory, where it will be manageable and accessible for other services as well.
At the same time, if you want to have cryptography to process public keys, Novell provides the cryptographic services that allow you to handle that. This is why we place so much emphasis on the architecture which is integral to Novell's PKIS and abilities for electronic commerce.
Application Level PKI. Another significant supporting piece of the architecture is the administration component. In the initial release of NetWare 5, NWAdmin can be used for a certificate authority, for key generation, for certificate generation, for certificate signing, and for certificate management. In the future, these functions will be handled by ConsoleOne, which is also supported by PKIS.
Authentication services are used by PKIS for login, and also as the control for access to the certificates. The cryptographic services are used by the PKIS for the usual kind of cryptography applied by a public key infrastructure, including everything from key generation to actual encryption and decryption where you want to use a certificate.
Novell's PKIS also provides for key wrapping and for server storage of the private key—an integral part of public key technology that is often overlooked. You always have a secret to protect: in a PKI it's the private key; in authentication, it's the user's password. The Novell security infrastructure provides the ability to protect private keys via the Novell International Cryptography Infrastructure (NICI) that underlies our entire security architecture.
A Closer Look at Novell's PKIS
The PKIS components, features, and related synergies are derived from its integration with NDS. Novell's PKIS allows the customer to receive value from the public key certificates. In NetWare 5, these certificates are an integral part of NDS, and the PKIS provide certificate management via the NetWare Administrator (NWAdmin) utility. The NWAdmin snap-in provides a management interface for public keys inside the certificates from within NDS. This allows for a single point of administration. No other commercial PKI system currently allows for centralized administration in a replicated environment.
The Novell PKIS is standards oriented. It is based on our existing support, primarily in the area of X.509 version 3, the dominant industry standard for electronic certificates. Novell provides customers with their own certificate authority ability, so you can either use external or internally signed certificates. Novell maintains the digitally-signed association between the user, a name, and some distinguished name, along with the public key, as a certificate. Novell also supplies another kind of a certificate in the form of a Public Key Cryptography Standards (PKCS) #10 certificate signing request.
Typically, in working across the Internet, users will want to create a certificate signed from another source, such as VeriSign or Netscape. With Novell's PKIS, you can do this by first making a certificate that has the name and the public key and is signed by you. Then you send this PKCS#10 request to the certificate authority and they send you your certificate.
This first offering of Novell's PKI services is focused on providing a basic PKI that is already integrated with the networking platform. Add-ons and derivative products are soon to follow, such as public key cryptography for establishing a virtual private network via IPSec. Similarly, collaborative users can expect to see additional facility in S/MIME-based software.
In addition to PKIS and the PKCS services, NetWare 5 also includes other services to support SSL, as well as an LDAP implementation using SSL to securely access it.
Features in Novell's PKIS 1.0
PKIS version 1.0, which ships for free with NetWare 5, features a certificate management capability, including certificate generation. You can generate both public and private keys on your NetWare server and then send them to the PKIS component to be signed and turned into a certificate. You can also send certificate signing requests to an external CA. If you need a CA that is already installed in common browsers' roots, you can generate the keys on the NICI server and then send the public key in a prototype certificate to an external CA (Verisign, GTE, or whoever) and have them sign it as well.
In addition, no matter where the CA certificate is generated and signed, it can be published in NDS for easy access, control, and distribution.
Certificate Renewal. Likewise, we have a certificate renewal capability to facilitate deletion or modification when the certificate's end of life comes up. You have the option to change some of the attributes or recreate the certificate with a new key. In the process, the security administrator can check particular attributes, override preconfigured information, or reject the entire certificate if it contains something unreasonable.
Although certificate revocation has been available for many years, the current process doesn't scale well to the increasing numbers of Novell and Internet users. Rough estimates say it takes 3 weeks to revoke a certificate on a global basis. It may be fine for small organizations to go out once a month and check all the certificates. However, it becomes unwieldy if you've got thousands of certificates that have been revoked over the last year. Several approaches have been proposed to simplify revocation, such as using certificate revocation list (CRL) distribution points, delta CRLs, even a "CD of the month club"-type scheme where you could get CRLs sent to you periodically.
However, the standards in the area of certificate revocation are still not finished, and there is a lot of flexibility in the emerging standards. Novell will eventually move in one of those directions, but until the standards are fully fleshed out, we have something that works now: NDS. If a certificate is not valid, you simply delete it from the Directory and it's gone. If you're not quite sure whether a certificate has been compromised, you can suspend it by denying access to the user. If it turns out it really wasn't compromised, you simply grant access again. If it was compromised, you can delete it entirely and audit records the detail.
Server Tree CA. There are other uses for certificates beyond providing server-level certificates, certificates for LDAP, and (in the future) end-user certificates. To accommodate this, we provide the Novell Root CA. (Actually, there may be an even higher level CA which could provide a liability- assuming sort of "master Root" at some future time.)
In Novell's certificate tree, coming off the NICI is a subordinate CA which we use for code signing. Although you can't see them, this is were we keep all the certificates necessary to sign and validate our cryptographic modules on the subordinate chain. Each security module in the NICI is signed by Novell to prevent tampering. All of these systems are generated on a TCSEC Class B3 rated platform—in Novell's case, a Wang Class B3 platform and operating system.
On the other side is another subordinate chain used in some areas of the world where cryptographic keys are required to be deposited in a key escrow agency. With this system, we must have some way of knowing whether or not the key escrow agency is bona fide. If so, either the subordinate system or the trusted root will sign the keys so that customers can be assured they are in fact sending their keys to a valid key escrow agency. This is an important part of key management in a PKI.
The Novell Root CA is separate from the NICI CA so that we don't use the same CA for generating the certificates as we use for either code signing or the key escrow function. Beneath the NICI CA is a licensed unique server CA. It is at this point, however, that NetWare 5 is packaged up into "red boxes" to be shipped out for resale. While Novell has several distribution methods for products, the red boxes are usually shipped to resellers who are responsible for getting the product into customers' hands. Because Novell has no reasonable way of knowing who actually buys which box, we have no liability-assuming way to substantiate that a certain customer received a certain red box.
This presents an opportunity for both Novell and for our customers. While we would love to include each customer's name in the certificate, that's not the way the sales process works. So what we do is fill in a pseudo-name that contains the license number. We then put the license number in the certificate chain. At the customer level, we have a pre-CA, which is the first time customer names can be put into the certificate. Since we don't know who any particular customer is, the customer fills in the names, and at the same time it is put into their NDS object. This allows the customer to use either Novell internal certificates or external certificates. We also provide, via the NICI and SAS tools, the APIs for developers to extend the structure for other uses.
For internal use, this structure works fine inside your company domain because you can publish this customer tree CA or any others (including the Novell Root CA) in your NDS Directory. You can then mandate what name is to be used to fill in the certificates. From the point of installation of the CA, you can use the server CA as the CA, use the master CA for your company or organization, and then you can issue additional certificates to your NetWare servers, to your Border Managers, and eventually to your GroupWise or S/MIME users, and so forth.
However, for external use of certificates, legacy considerations, and a few other issues, this structure doesn't quite work. From a due diligence standpoint, whoever is running a CA for customer-created certificates will want to know whether the organization representation filled in by the customer is accurate. When you have external users, you'll want to have an external CA. This is why Novell has included the ability to send a PKCS #10 certificate signing request to an external CA (such as Verisign or GTE) and have them sign the certificate requests.
Of course, some of our larger customers create multiple servers under special licenses and contract agreements. If a large customer buys a copy of this type of NetWare 5 on CD, they can then mail it around to all of their people, who in turn create their own server. This means we need a machine-unique CA.
There's one more little problem if you're going to use this externally. You would like to have your name filled in and signed by a public CA. But that means every customer will be knocking on the door of each browser vendor (Netscape, Microsoft, and everybody else) asking them to please include their self-signed certificates in the browser. While the industry is not there yet, there has to be some kind of bubble-up mechanism with trusted authorities—whether they are run by the state, federal government, industry associations, or banking associations, some sort of higher level CAs are going to emerge. At that time, Novell can sign the certificate and you can issue your own certificates from the Novell CA.
Existing CAs may not be terribly fond of this capability, since their revenue models are based on users buying certificates for every server and end-user in the entire organization, at anywhere from $10 to $40 apiece, sometimes renewable annually. There are good reasons for many customers to obtain an external CA, one that they trust. However, the Novell structure may be a better way to go for large organizations with tens of thousands of users where it may not be cost- effective to pay for external certificates.
Protecting Certificate Content
The X.509 version 3 standard provides for extended attributes. Novell has added some proprietary extensions which are defined in an online document entitled "Novell Certificate Extension Attributes--Novell Security Attributes Tutorial and Detailed Design" (available from Novell's developer site at (http://developer.novell.com/whitepapers/).
This approach is similar to the one both Netscape and Microsoft are taking for their code signing certificates. Unfortunately, these two vendors defined their own proprietary attributes. As a result, when you go to an external CA to get a code signing certificate, you must obtain separate certificates for Netscape and for Microsoft. You can't use the same certificate to sign both ActiveX and Java. It's unfortunate, but that's competition.
Novell's extensions are called Novell Security Attributes, and we have trademarked them. The content is not a trade secret; in fact, we would like people in the industry who use certificates to be able to see these attributes. We're simply trying to protect end-users from any misuse or misrepresentation of their certificate content. As long as a product vendor or CA agrees to honor our syntax and the semantic definitions that we will control, they can use the trademarked phrase.
Additionally, within NetWare, end-users will be able to validate those attributes back to the Novell Root, so they can know if they were built by valid software. In X.509 parlance, our attribute extensions will be non-critical, which means the application will not reject the certificate if it does not understand the syntax and semantics of a particular extension. (With critical attributes, it could stop the application.) Our attributes are more or less advisory. Their value lies in the fact that the attributes created by our software will chain back to the Novell Root so customers will be able to validate them.
Key Quality. The first of these extended attributes is a key quality attribute. Its purpose is to provide a basic high-water mark of key quality at the time the certificate key was generated. This tells users the certificate key cannot be any better than this.
Certificate Quality. This attribute provides the "high water mark" of the machine upon which the certificate is signed. This is determined by two other quality ratings:
Security Rating. This attribute includes information such as the TCSEC, ITSEC, or Common Criteria rating. In the first release we only support TCSEC ratings, such as C2 or B3. We also have the ability to include other levels, such as "designed to meet but hasn't been re-evaluated." In addition to the computer security platform, we have the FIPS 140-1 cryptographic module security rating which range from level 1 to level 4. If other countries define their own rating criteria, NetWare has the ability to accommodate those as well.
Cryptographic Quality. NetWare 5 has a cryptographic process quality that will be available in the future. It is a legally binding representation made by the CA to the customer that the CA will never use the private key used to sign the customer's public keys on any nonsecure platform (such as one having less than a particular computer security or FIPS rating).
Enterprise ID. This attribute is probably going to be one of the most interesting ones. Consider an enterprise such as General Motors (GM), a very large and complex corporation with a number of subsidiaries. In an extended enterprise model, they have thousands of parts suppliers and car dealers that they work with on a regular basis. Outside of that community are trusted trade press representatives and other people that they want to communicate with. The trick is to communicate these entities over the Internet. For example, suppose a vendor such as Botswanaland Motors wants to access the GM network to do just-in-time parts ordering. How does GM know this is really a friend trying to access their network? They can't just look at the certificate name, because that is going to say Botswanaland Motors. It is not going to say O=General Motors, because that would imply General Motors had some liability for Botswanaland. One corporation cannot be an Organizational Unit under another corporation, because by law corporations are separate entities. There's a legal "firewall" between corporations that says even though one corporation may own the other one, they are separate legal entities and no liability flows upward. In such a case, you cannot use standard naming conventions and have them work.
With our extended security attributes, Novell has a scheme that looks very promising to handle this sort of naming quandary. The attributes will allow even a certificate issued by some Botswanaland CA to identify it as a bona fide GM friend. This allows a legal structure that you can rely on from CAs that conform to policy. It is intended to provide a very flexible way of controlling access to virtual private networks and allow electronic commerce to work in a lights-out environment so that we don't have to have a human sitting there looking at all these names.
There's a fair amount of work still to be done, not only in terms of code that has to written, but with business practices and arrangements that have to be set up. Of course, if you work in a defense environment, you may be able to operate things yourself. Large organizations with several million users may be willing to be their own CA and control the relationships with other CAs. It is only in a global construct that it becomes more difficult.
Classes. Beyond these extension attributes, Novell is working to support other concepts such as "Class". Verisign has several certificate classes: Class 1, which is a plain e-mail based certificate; Class 2, where they do a credit check to make sure the individual is alive and is current on their bill payments; or Class 3, where they verify a company through Dunn and Bradstreet and may require notarized standards.
Novell has broadened this standard, on the drawing board at least, to a sparse list ranging from 0 to 255. Class 0 is the low end of the spectrum, where you might buy the certificate from some anonymous source such as a vending machine on the street corner. The other end of the spectrum, somewhere around 250, is a permanent ruling by the Supreme Court of the United States or an authoritative declaration by the President—a final, official act of a sovereign state that the parties involved are who they say they are. This is about the highest level of trust you can get. But just in case, we have left a few open in case some alien monarch arrives and preempts the established governmental order.
Support for Digital Signatures
Another area Novell is working on is support for digital signatures. Within several states—Utah, Washington, Florida, New York, Vermont, Hawaii, and soon Illinois—and in countries such as Germany, Bolivia, Colombia, and Italy, laws have been passed to officially recognize digital signatures as legally binding. So if you sign something using your digital signature, it may have legal consequences. The bad news is that if you don't take adequate care of your keys, someone could forge your digital signature and use it to charge all kinds of things for which you would be legally responsible.
Looking to the Future
Customers are constantly looking ahead to see what's next in future developments. Some are just testing the water with plans for confidential e-mail. Some are looking to implement greater levels of workflow. But virtually everyone is looking to the next step in viable electronic commerce technologies. Among the many issues surrounding standards and privacy are the mixed-in issues of security and trust, along with scaleability and manageability. We have noted some of the scaleability issues surrounding Certificate Revocation Lists, and there are others as well. But the underlying needs for scaleability and manageability are most likely to emerge as the most preeminent needs. No one is going to use technology which cannot accurately report in a timely manner whether an electronic transaction is bona fide or not.
Efforts by standards groups to reduce the bandwidth required for certificate validation and to improve timely access have resulted in the creation of registries. Registries are very much like directories in their structure. However, the proposed concept of registries allows for replication, much like a federated directory. While federated directories are not available in NDS today, it is clear that bandwidth issues fostered by pairwise and inter-group communications will inevitably consume more and more bandwidth (and time) than existing structures will allow.
Additionally, the need for multiple CAs per organization, particularly subordinate or hierarchical CAs, will come to bear in the future. The need for one CA at the top that is used rarely, with subordinate CAs for independent organizations, has already been discussed by major infrastructure organizations such as the European Union Directorates. This construct not only provides enhanced reliability and scaleability, but ultimately it helps narrow the playing field so that network users can really know who they're dealing with. This is an essential element in the "closed-user" groups the industry is relying on for inter-organizational e-commerce activities.
The need for cross certification of CAs is another interesting and complex problem that Novell is working on. Clearly, with a "higher" level Root ability as found in the Novell Certificate Chain, customer needs can stimulate how Novell extends the ability.
Another area for of demand by customers is for more third-party CA interface support. In NetWare 5, we are already issuing certificate signing requests to external CAs, but there are a lot of CAs out there and there's only so much test time. At the same time, we know that customers will want to import signing requests to NetWare for their own use.
The important thing to remember is that when it comes to network security, Novell has solutions today, and we're making significant progress on future solutions beyond the server certificates for SSL that are included with NetWare 5 today. Providing a scaleable and manageable interface that is applicable to even very large organizations while maintaining Novell's Global Security Architecture will enable customers to better discern (electronically) the levels of security commensurate with their requirement.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.