Section 30.2. Embedding and Simplifying Public Key Security


30.2. Embedding and Simplifying Public Key Security

The Lotus Domino PKI is not a free-standing product: it is integral to the Lotus Notes end-user and administrative experience. Every new user of the Notes desktop client is given, by his administrator, a public/private key pair in a keyfile called his ID file.[1] The user types in his password to decrypt and make use of the ID file. The Lotus Notes client uses a private key to authenticate to the Domino server, providing two-factor authentication (the

[1] Notes 6 provides a feature that allows the user to generate his own public/private keypair.

IBM LOTUS NOTES AND DOMINO

The IBM Lotus Notes and Domino architecture supports a suite of products that provide a client/server infrastructure for collaboration applications, as well as specific support for electronic messaging and calendaring and scheduling. Lotus Notes is a rich desktop client to the Domino server. It communicates with the Domino server through a proprietary, public key cryptographic protocol called Notes Remote Procedure Call (NRPC) . Notes client security features are generally accessed through the user security panel (Figure 30-1). A user's password (Figure 30-2) decrypts the file that contains her public/private keys.

The Lotus Domino server provides the foundation for custom collaboration applications, messaging, and web applications. Full enterprise deployment of this server can take advantage of administrative features such as clustering, partitioning, and automatic failover, for performance and scalability. A separate rich client, the Administrative client, provides the server administration features in a user interface experience tuned to the administrator's tasks and skills..

Each Domino application is associated with a design template that is instantiated in a Domino database. Access control lists are set and managed at the database level (see Figures 30-3 and 30-4). Domino Designer is application development software that provides the features that make up a Domino application, including forms, views, pages, framesets, integrated instant messaging, XML, Java, JavaScript, and LotusScript. These Domino applications can be accessed via either Notes or a web browser. Multiple instances of the same application are supported via multiple disjoint databases associated with that application design. This allows a site to use the same team room design for different groups and topics, for example. The Notes client supports full-featured offline functionality with Domino applications through local copies of the Domino application databases. Both Notes and Domino run on a variety of hardware platforms and operating systems. A full overview of Notes/Domino security features as of version 5 is available.[a] A timeline of all Notes/Domino security features from the first release in 1989 through the 2001 releases also lists some of the security features that were put into version 6.[b] From the scope of the features, the reader can see that in this chapter we touch on the usability aspects of only a few of them. Resource and schedule constraints generally concentrate explicit usability attention on the highest priority or most widely used security features of each release.


[a] Susan Bryant and Christie Williams (with Katherine Spanbauer), "Overview of Notes/Domino Security," Iris Today Archives [cited Oct. 2004]; http://www-10.lotus.com/ldd/today.nsf/lookup/security_overview.

[b] Katherine Spanbauer, "Milestones in Notes/Domion Security," Iris Today Archives [cited Nov. 2004]; http://www-10.lotus.com/ldd/today.nsf/Lookup/security_milestones.

password the user knows, and the private key the user has stored in his keyfile).[2] By and large, the user is unaware of this use of public key cryptography. He knows only that he needs access to a copy of his ID file to use Notes.

[2] The keyfile is stored on each user's local computer, making it inaccessible to attackers who have not penetrated the local computer. However, the keyfile is protected by the password and may potentially be compromised without a user's knowledge. In addition, copies of the keyfile may be stored elsewhere. Thus, Lotus Domino may be considered to have one and one-half factor authentication.

30.2.1. Signing and Decrypting Email

The same private key used in authentication can be used to sign and decrypt mail. A single email is explicitly signed or encrypted via a checkbox in the set of optionally manipulated delivery options of a mail message. Those features can also be enabled by default for all mail messages in user preference information.

Checking signatures on email from people in your organization is quite seamless. Notes has a native, proprietary format for signing and encrypting, because the feature was originally developed before S/MIME and X.509 certificate standards had the widespread use they have today. Notes supports those standards now as well, but the usability and integration of the earlier formats is superior, because it exploits other native features of Notes/Domino, such as the organization and syntax of enterprise names and usernames in the directory.

Notes Certificate Authorities are arranged in a naming hierarchy that parallels the enterprise organization naming hierarchy. Each user receives in his ID file a public key certificate for his private key and the certificate of every authority in his hierarchy. Any signature from another user who shares a common hierarchical authority with the recipient is automatically checked when the message is read. The name of the signer, the time of the signature, and the name of the shared authority is displayed in a message bar at the bottom of the window. For example, the Notes name of Mary Ellen Zurko/Westford/IBM will have certificates for that name, /Westford/IBM, and /IBM in its ID file. That username can automatically validate signatures from anyone under the /IBM authority. Hierarchical names constrain the format of names, but simplify the explicitly available trust relationships. Within an enterprise, users never have to be asked confusing questions about trust and authorities. Hierarchical names also provide excellent security properties, limiting the amount of damage a misbehaving or compromised Certificate Authority can do.[3]

[3] Virgil D. Gligor, Shyh-Wei Luan, and Joseph N. Pato, "On Inter-Realm Authentication in Large Distributed Systems," IEEE Computer Society Symposium on Research in Security and Privacy (1992), 217.

30.2.2. Encrypting Email

Encrypting mail messages is more challenging, even within the circumscribed limits of an enterprise, because it requires access to information not always available locally on the client (trustworthy public key information for the recipient). When the user is on the network, and sending email to a colleague with a record in the directory configured as his directory server, encryption is as easy as signing. The directory server automatically finds the recipient's name and public key information. However, an enterprise may have many Domino directories; all need to be configured to be available to the sender's directory server. Sending encrypted mail offline has another set of issues that are addressed in the product, but can require preconfiguration or other extra interactions with the user.

While excellent integration within an enterprise or organization hides many confusing key management concepts, using encryption or signature checking across those boundaries exposes them, leading to many of the known difficulties with PKI. Users receiving signed email from beyond their enterprise hierarchy are asked if they trust the root authority of the sender, with a display of that authority's fingerprint (a sequence of letters and numbers encapsulating the public key). In theory, the user is supposed to verify the fingerprint's association with a trustworthy entity associated with the presumed organization of that authority. In practice, users are more likely to be confused or simply click OK to start trusting that certificate. Encrypting for a recipient in another organization is even more complex, involving acquiring the certificate from the potential recipient and placing it into a personal directory. Lotus Notes provides features that allow the user to do that so that he does not have to rely on administrative intervention. However, explicit use of such features takes some sophistication on the part of the user.

From the point of view of promoting both the active use and the understanding of security concepts, signing and encrypting are perhaps too embedded in Notes, as their integration has made them invisible in the most common use cases. Many Internet browser users feel a sense of security when they see the padlock icon indicating that the Secure Sockets Layer (SSL) is in use. The same users are unaware that an electronic pay stub delivered by Notes is encrypted and signed.

Although users might get an enhanced feeling of trust if they see a similar icon on signed or encrypted mail messages, display of this information needs to be traded off with the many other informative messages and icons displayed in Notes email (including message priority, whether an attachment is included, and whether the message is a calendar invitation). How to balance ease of use and simplicity with user awareness and trust is an ongoing design issue.

One of the major places where the public key infrastructure still intrudes is the need for the ID file to be present for Notes authentication, decryption, and signing. This has posed a challenge for kiosk use, where a desktop with the Notes client might be used by many employees of a single enterprise. It is an even bigger issue for browser-based access to Domino applications, including mail. The emphasis on local information that makes signing, signature checking, and decrypting both easy and extremely secure in the rich Notes client makes the same operations a challenge, and potentially less secure, in a browser-based environment.

Lotus Domino can operate in a browser environment using special server-side processes for signing and encrypting email. To use these processes, however, the user must be willing to place his ID files on the server, allow the files to be decrypted, and allow the processes to access the user's private keys.

The Lotus Notes PKI has provided excellent security and usability for six versions and 15 years. The benefits have been most noticeable in an enterprise setting that can take advantage of both the proprietary features and the organization's structure. This has enabled many simplifications not available to fully flexible, free-standing PKIs.



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net