Novell's PKI Provides International Security Architecture
Articles and Tips: tip
Senior Research Engineer
Roger Schell
Security Development Manager
01 Aug 1998
Novell's networking platforms center around the concept of Client-Network rather than just Client-Server computing. In the Client-Network environment, customers want smart logins and the ability to gain services directly from the client. However, this means all of these services must work across heterogeneous and international boundaries.
Software and hardware solutions that worked for LANs with their relative privacy can hardly be expected to work in the open environments required for international networking. There is certainly the need for trusted workstations in an environment where user fingers and eyes interface with the bits and bytes. But if we are to have a secure network, end-users must be able to authenticate across the open distance, and this requires a security architecture in addition to a trusted workstation.
With both the architecture and the trusted workstation in place, users will be able to authenticate with a level of trust and with increasing levels of single sign-on (SSO) ability. However, increasing levels of SSO accessibility require an infrastructure, which must in turn support trusted technology. Even if you do not need the trusted workstation, you still need the infrastructure which supports it. This way, you can choose to work without trusted workstations or with lower levels of acceptability. Of course, you must live with the risks you introduce.
If the technology does not support trusted workstations, then you have mandated "no trust" as the infrastructure. No effort to support it with the same or a better level of assurance will work against attack to the network. The overall confidence in vendor offerings to customers is determined by the security architecture of the product and by the customer's knowledge of the relevant security issues.
Dealing With Cryptography Issues
In the broader picture, when you deal with the concepts of SSO in international terms, you must deal with the cryptography issues. For SSO, the cryptography restrictions, especially in authentication, are less stringent in most countries than they are for the cryptography itself. The accountable actions of the user are of more interest to their companies than to governmental regulations. In the Client-Network environment, there needs to be accountability, and that requires international standards in both accountability and cryptography. Nevertheless, it is unlikely that either of these standards will emerge in the foreseeable future. Because of this hesitancy to commit to a standard, there is some question as to how to have a Client-Network session which is strongly authenticated, reliable, and well audited.
Novell is shipping a Public Key Infrastructure (PKI) with NetWare 5. This PKI can provide an international security architecture that meets the end-user needs to authenticate across heterogenous international boundaries. The operating system can use a public key authentication mechanism to make calculated decisions based upon the grade of authentication (see "Network Security: The First Steps to an International Authentication Framework" in the February 1998 NetNotes). Where you travel internationally or who you communicate with should not depend on the technology as much as upon what you intend to do. Once authentication has occurred, the level of accountability should determine the appropriate level of confidence and integrity. It is on this issue that governmental regulation is focused.
Part of today's common framework of business interactions across the Internet is peer-to-peer Secure Socket Layer (SSL). SSL provides a way to secure the communication. Since there are times when a communication environment may be hostile, cryptography allows us to securely span the environment. However, in countries such as France, governmental regulatory constraints which limit both the strength and the security of cryptographic solutions can only be circumvented by some form of escrow, as prescribed by their law. The types of restrictions encountered weak cryptography or escrow support are not the only choices imposed. In Russia, for example, proprietary algorithms are the rule.
Dealing with Differences in International Cryptography
In the international environment there are ways of dealing with these variations. One way is known as the lowest common bound (LCB) or lowest common denominator. Cryptography is no stronger than the lowest requirement in every country. While this is an acceptable legal solution, it imposes software development requirements that most developers are not aware of.
Some countries are interested in the flow of data through their country. If you want to do electronic commerce over the Internet, the implications imposed by this type of regulation are staggering. The tendency is to impose a lowest common bound, which can result in a very weak or ineffectual solution. For instance, if you want to transact with Russia from France, the governmental regulations combine to prohibit the use of cryptography altogether. This is not a very satisfying answer to the problem.
Another technique is to use store-and-forward security gateways. Such gateways only offer transition by and through cryptographic regimes. For example, while a particular encryption scheme may be perfectly usable, the user of that encryption scheme is exposed in the regime in which it operates because the protocols must be known to the various governments. In electrical engineering terms, this is known as impedance matching. While it is certainly effective for transitory data regulations, it is unnecessary in many cases.
Another workaround to international encryption regulations is an attempt to accommodate by flexibility. To illustrate, suppose you are in France and you want to transact with someone in Russia. Since you recognize Russia's proprietary algorithms and France's laws, you use the Russian algorithm with key escrow in France. This meets the legal requirements of France. Such a technique is neither good or bad. It is French law, and it is the only way to have strong cryptography in France.
If you are trying to do flexible cryptography in today's environment, your efforts are best spent in the enhancement and extension of the existing protocols. Some researchers have noted that since SSL is unfriendly to key escrow, significant benefit could be provided by vendor extensions and enhancements to this standard.
What of the Future?
Going forward, customers will have to recognize that their needs up to this point have not been considered and addressed by standards such as SSL. To fulfill customers' security needs, vendors may have to respond with formal or de facto evaluations of their products, or by selling products only at graded levels. But since the consumer cannot create his own products, users have weak security choices.
In the final analysis, a security architecture can work as a whole, even with the various regimes of cryptography legislation taken into consideration. If you consider registries as a method and distributed services as a need for establishing the critically important technology, you also must recognize that they allow you to interact on a global basis. Simply, you need a registry for that domain. Other domains may or may not be as accepting. Clearly, governments will not go outside their domain to other services for registry. In the financial world or in workflow management areas, people will need to grade their security. Within this universe of discourse, their need for a PKI will provide impetus to create these registries.
* 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.