PGP Grows Up

Unfortunately, neither PGP nor S/MIME are quite ready for general enterprise use. Until OpenPGP and S/MIME version 3 are finalized as IETF standards, both should be considered proprietary technologies. PGP and S/MIME place an undue amount of responsibility on individual users to manage certificates and trusts. While PGP does add some automation (like automatically searching for a recipient's certificate via LDAP when encrypting a message), certificate management should be as transparent as possible. Likewise, both lack effective measures for certificate revocation and validity checking, which are critical for use in enterprise environments. On the other hand, Network Associates delivers a well-integrated PGP solution--on both the client and server si des--even though it means abandoning the X.509 PKI. At this point, PGP's effective administrative controls provide serious value for enterprise users, but secure messaging is still in its adolescence. Is It Enterprise-Ready? We're as tired of asking that question as you are. But it's important to do so. In a system as complex as a public key-driven secure-messaging solution, the real scalability issue is management. Consider that placing strong cryptography in the hands of your users is like handing out a loaded gun--it can provide a powerful form of protection, but users must be educated about how to use it safely. To that end, PGP attempts to address the needs of the enterprise by implementing trust policies. Using the admin tool wizard, the administrator generates customized PGP versions that are distributed to individual clients for installation; these contain all necessary applications and frozen security policies. Administrators can insert various certificates (called keys in PGP) into clients' default installations and build corporate trust models using meta-introducer and trusted introducer certificates or certificates from various partner companies. PGP for E-Mail and Files adds a powerful feature called ADK (additional decryption key). Previously called the Corporate Message Recovery Key, ADK is a policy that the administrator activates to force PGP clients to encrypt not only the recipient's public key, but also every message in a predesignated recovery key (see "Too Much of a Good Thing?" on page 62). As an application-layer security protocol, PGP lives entirely on the client. However, Network Associates does include two additional services for managing an enterprise PGP installation: the Certificate Server, essentially an LDAP-accessible certificate repository used as an enterprisewide clearinghouse of users' certificates; and the PMA (Policy Management Agent), a filtering SMTP relay that enforces security policies at the transport layer and screens mess ages for the presence of signatures, valid ADKs, disallowed certificates and more. We tested PGP's Certificate Server on a Sun Microsystems Ultra 2 running Solaris 2.5.1 and the PMA for SMTP on a Sun SPARCstation 10 running Solaris 2.6. Both products are configured through flat-text configuration files that should look familiar to Unix administrators. Certificate Server policies are relatively straightforward. We specified read-only access to everyone, and restricted administrative access (the power to delete certificates, for example) to machines within the subnet that present a valid administrative key signature. Keys are specified using 64-bit key IDs. Likewise, PGP's PMA was a cinch to configure: It simply listened to the server's SMTP port and redirected messages to a standard SMTP server on another Solaris host in our lab. Desktop clients direct their outgoing SMTP mail to the policy agent, and messages are parsed in real time and rejected with an SMTP 550 error message when a policy violation is detected. The PMA can be configured to allow, disallow or require encryption or signatures; to allow or disallow conventionally (nonpublic key) encrypted messages; and to require ADKs in all messages. Our testing turned up two caveats for anyone using the PMA. First, some clients do not display SMTP error messages to the user (Outlook97 simply indicated a failed message transfer without mentioning a policy violation--and prompted us to change the address of the outgoing SMTP server). Second, we discovered that when a message is both signed and encrypted, the signature is wrapped in a layer of encryption, making it invisible. If the policy agent requires signatures, encrypted messages will fail the signature policy check even though they are signed. According to Network Associates, this is intentional because message signatures should be secret when messages are encrypted. Although the security advantages of protecting the signature are real, there is a trade-off in terms of management. S/MIME clients do the opposite, leaving signatures on the outside, allowing the enforcement of both signature and encryption policies. Despite these issues, we successfully protected policies that encrypted and signed messages (though not at the same time), as well as policies that required additional valid decryption keys. We also could block any messages using nothing more than conventional encryption.

For the Side Bar on Who's Secure By Nancy Cox Too Much Of A Good Thing? By Dan Backman Support for PGP varies greatly among the Big Three ve ndors By Nancy Cox Other Features The 1998 BOTI Awards: Best of the Web