Public Key Infrastructure

   

---

Computer networks are no longer closed systems in which a user 's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network can consist of intranets , Internet sites, and extranets ”all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter an organization's digital information assets.

There are many potential opportunities for unauthorized access to information on networks. A person can attempt to monitor or alter information streams such as e-mail, electronic commerce transactions, and file transfers. Your organization might work with partners on projects of limited scope and duration having employees about whom you know nothing but who, nonetheless, must be given access to some of your information resources. If your users have a multitude of passwords to remember for accessing different secure systems, they might choose weak or common passwords to more easily remember them. This provides an intruder with not only a password that is easy to crack but also one that will provide access to multiple secure systems and stored data.

How can a system administrator be sure of the identity of a person accessing information, and given that identity, control which information that person has access to? Additionally, how can a system administrator easily and securely distribute and manage identification credentials across an organization? These are issues that can be addressed with a well-planned public key infrastructure. A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), and other registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce.

An organization might choose to deploy a PKI using Windows for a number of reasons:

• Strong security.

  You can have strong authentication with smart cards. You can also maintain the confidentiality and integrity of transmitted data on public networks by using IPSec, and you can protect the confidentiality of your stored data using EFS.

• Simplified administration.

  Your organization can issue certificates and, in conjunction with other technologies, eliminate the use of passwords. You can revoke certificates as necessary and publish certificate revocation lists (CRLs). There is the ability to use certificates to scale trust relationships across an enterprise. You can also take advantage of Certificate Services integration with Active Directory and policy. The capability to map certificates to user accounts is also available.

• Additional opportunities for PKI.

  You can exchange files and data securely over public networks, such as the Internet. You have the ability to implement secure e-mail using Secure Multipurpose Internet Mail Extensions (S/MIME) and secure Web connections using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). You can also implement security enhancements to wireless networking.

The following sections describe the features in the Windows Server 2003 family that can help your organization implement a public key infrastructure.

Certificates

A certificate is basically a digital statement issued by an authority that vouches for the identity of the certificate holder. A certificate binds a public key to the identity of the person, computer, or service that holds the corresponding private key. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity, and secure communication across networks such as the Internet.

The standard certificate format used by Windows certificate “based processes is X.509v3. An X.509 certificate includes information about the person to whom or the entity to which the certificate is issued, information about the certificate, and optional information about the certification authority issuing the certificate. Subject information can include the entity's name , the public key, and the public key algorithm. The entity receiving the certificate is the subject of the certificate. The issuer and signer of the certificate is a certification authority.

Users can manage certificates using the MMC snap-in for certificates, as shown in Figure 5-4. Users can also allow certificate autoenrollment to manage their certificates automatically.

Figure 5-4. You manage certificates using Microsoft Management Console.

Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, secure e-mail (S/MIME), IPSec, TLS, and code signing. Certificates are also issued from one CA to another in order to establish a certification hierarchy. Typically, certificates contain the following information:

• The subject's public key value

• The subject's identifier information, such as name and e-mail address

• The validity period (the length of time that the certificate is considered valid)

• Issuer identifier information

• The digital signature of the issuer, which attests to the validity of the binding between the subject's public key and the subject's identifier information

A certificate is valid only for the period of time specified within it; every certificate contains Valid From and Valid To dates, which set the boundaries of the validity period. Once a certificate's validity period has passed, the subject of the now- expired certificate must request a new certificate.

In instances in which it becomes necessary to undo the binding that is asserted in a certificate, the issuer can revoke the certificate. Each issuer maintains a certificate revocation list that can be used by programs when checking the validity of any given certificate.

One of the main benefits of certificates is that hosts no longer have to maintain a set of passwords for individual subjects who need to be authenticated as a prerequisite for access. Instead, the host merely establishes trust in a certificate issuer. When a host, such as a secure Web server, designates an issuer as a trusted root authority, the host implicitly trusts the policies that the issuer has used to establish the bindings of certificates it issues. In effect, the host trusts that the issuer has verified the identity of the certificate subject. A host designates an issuer as a trusted root authority by placing the issuer's self-signed certificate, which contains the issuer's public key, into the trusted root certification authority certificate store of the host computer. Intermediate or subordinate certification authorities are trusted only if they have a valid certification path from a trusted root certification authority.

Certificate Services

Certificate Services is the component in the Windows Server 2003 family that is used to create and manage CAs. A CA is responsible for establishing and vouching for the identity of certificate holders. A CA also revokes certificates if they should no longer be considered valid and publishes CRLs to be used by certificate verifiers.

The simplest PKI design has only one root CA. In practice, however, a majority of organizations deploying a PKI will use a number of CAs, organized into certification hierarchies. Administrators can manage Certificate Services by using the Certification Authority MMC snap-in.

Certificate Templates

Certificates are issued by the CA based on information provided in the certificate request and on settings contained in a certificate template. A certificate template is the set of rules and settings that are applied against incoming certificate requests . For each type of certificate that an enterprise CA can issue, a certificate template must be configured.

Certificate templates are customizable in Windows Server 2003, Enterprise Server, and Windows Server 2003, Datacenter Server, enterprise CAs, and they are stored in Active Directory for use by all CAs in the forest. This allows the administrator to choose one or more of the default templates installed with Certificate Services or to create templates that are customized for specific tasks or roles.

Certificate Autoenrollment

Autoenrollment enables the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. Such configuration requires no knowledge by the subject of any certificate operations ”unless the certificate template is configured to interact with the subject or the cryptographic service provider (CSP) requires interaction (such as with a smart card CSP). This greatly simplifies the experience of the client with certificates and minimizes administrative tasks. Administrators can configure autoenrollment through configuration of Certificate Templates and CA settings.

Web Enrollment Pages

Web enrollment pages are a separate component of Certificate Services. These Web pages are installed by default when you set up a CA and allow certificate requesters to submit certificate requests using a Web browser.

Additionally, the CA Web pages can be installed on servers running Windows that do not have a CA installed. In this case, the Web pages are used to direct certificate requests to a CA that, for whatever reason, you do not want requesters to directly access.

If you choose to create custom Web pages for your organization to access a CA, the Web pages provided with Windows Server 2003 can be used as samples. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services and CA Web pages.

Smart Card Support

Windows supports logon via certificates on smart cards, as well as the use of smart cards to store certificates and private keys. Smart cards can be used for Web authentication, secure e-mail, wireless networking, and other activities related to public key cryptography.

Public Key Policies

You can use Group Policy in Windows to distribute certificates to subjects automatically, establish common trusted certification authorities, and manage recovery policies for EFS.

---

Top