DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Nonrepudiation

At the moment, there is only one well-used mechanism to implement non-repudiation, and this uses the public and private key encryption methods we saw in the section on authorization. In this case, the person uses their private key to encrypt every message. This is then proof that the message could only have come from that person and acts like a signature on that message. The receiver then decrypts the message using the person’s public key.

Because the person sending the message can also ask for authentication of the server, the person can also treat any message from the server as though it was signed. For example:

A person wishes to place an order with a company. The person first sends a message asking for the service to place the order. The message is signed with the person’s private key. The person is authenticated by the server and the server then sends back a message encrypted with its private key to indicate it is willing to accept the order. The person authenticates the server by accessing the Directory to decrypt the server’s message using its public key. If the message decrypts OK, the server is the right one; if not, then the server is, for example, an impostor.

Both the person and the server have established each other’s identity. From then on each message can be treated in the same way—the order can be signed by the person placing it with the private key and any confirmation of receipt can also be signed by the server. Both parties therefore have then employed the means of preventing repudiation.

Audit

Audit mechanisms tend to be specific to each middleware vendor, if they are provided at all. Many middleware vendors, for example, use an audit log to provide a means of logging all security-related activity, producing an audit trail of security events recording information such as date, time, user, object, and event. The log itself must also be protected from tampering.

Third-Party Security Products (Which Microsoft Uses)

Microsoft not only provides its own security products, but also uses third-party products. Before I examine Microsoft’s own security services, therefore, I will describe the links it has to third-party products, how it provides those links, and what these products support—which mechanisms in the list above. The main third-party products that Microsoft includes within its security framework are:

  SSL (Secure Sockets Layer)-from Netscape
  Products from Cryptographic Service Providers (CSPs)
  Kerberos

SSL-SSL was introduced by Netscape and it has submitted the current version to an IETF (Internet Engineering Task Force) working group as an Internet Draft standard. SSL provides security services that are a combination of public key encryption, symmetric key encryption, and data integrity checking. It also includes authentication of the server and, optionally, the client’s using both a user id/password approach and using the new public/private key encryption services.

Internet Explorer and Internet Information Server support SSL, which Microsoft has called Secure Channel services. Developers must use the Win32 APIs part of the ActiveX developer’s kit to add secure channel support using this product.

Although Microsoft does support SSL, they also provide their own version of SSL called PCT (Private Communication Technology), which is supported in Explorer. PCT is based on SSL but separates the authentication mechanisms from the encryption mechanisms so that it is easier to export the technology.

CSPs-The main CSP with which Microsoft is working is RSA Data Security, but it does have links with others, notably BBN, Cylink, Atalla, Trusted Information Systems, Nortel Secure Networks, HP, and Spyrus. As we saw in the description of the encryption mechanisms, many of the mechanisms available can be freely licensed and thus supplied by a number of third-party companies. The products covered by this umbrella approach include those which support mechanisms such as DES, RC4, and so on and provide public and secret key encryption. They are thus able to cover Digital Certification, Confidentiality checking, and nonrepudiation.

Microsoft provides an API called the CryptoAPI, which connects applications to third-party security encryption services. CryptoAPI is designed to insulate applications from common cryptographic functions. The API is being built into the products of the CSPs; in other words, each service provider is adding a CryptoAPI interface to their product.

Although considered to be part of the Windows NT operating system, the API will also be available on Windows 95 and scaled-down versions of Windows for handheld machines. CryptoAPI can be called from Java, Visual Basic, and C++ as a Win32 API, and version 1.0 was part of the Software Developer’s toolkit. The CryptoAPI version 2 ships with both Windows NT 4 and Internet Explorer 3 with planned support for the Macintosh.

Kerberos-Kerberos is an authentication service that uses user/passwords and tokens. It was developed at the Massachusetts Institute of Technology in a project called Athena during the 1980s. As a government-funded project, much of the work is in the public domain for U.S. organizations and has been adopted by a number of suppliers.

Every user, computer, server, and so on (known as principals) in the network is given a secret key with which it can prove its identity. Human users can use passwords, which are then converted to the secret key. The user’s secret key is never passed over the network and is deleted from the host once it has served its purpose. Authenticated users receive conversation keys to communicate with the server.

When the user logs in, Kerberos accesses a Registry database to check the user’s password and get the user’s secret key. These security services also provide the user’s process with specially encrypted data structures called tickets. Tickets can be cached and used a number of times, although each ticket has a limited life span to prevent unauthorized users from getting access to tickets via the network.

Clients present the tickets to other principals as proof that they are authentic. When the user starts an actual application, the client process inherits the user’s identity and its tickets and privileges. In highly secure environments, the client can also be made to provide proof on every call. Each application server also has a secret key and can acquire tickets from the Security services. It is therefore possible to add mutual authentication checking to an application.

Microsoft is intending to incorporate support for Kerberos authentication in Windows NT version 5.0 for the local environment. Certificates from Certificate server (of which more later) will be passed to Kerberos domains and used as validation in Kerberos tokens. The mapping will be held in the new Active Directory.

Table 16.2 Microsoft-supported third-party mechanisms
Function/Mechanism SSL CSPs Kerberos
Authentication
User/password YES NO YES
Digital certificate YES YES NO
Smart card NO NO NO
Authorization
ACLs NO NO NO
Digital certs NO NO NO
Confidentiality
Public key YES YES NO
Secret key YES—RC4, DES YES NO
Integrity checking YES—MD5, SHA-1 YES NO
Nonrepudiation YES YES NO
Audit NO NO NO


Previous Table of Contents Next