Network Security Architecture

The network security architecture works with standard industry interfaces, such as PAM, GSS-API, SASL, and RSA Security Inc. PKCS#11 Cryptographic Token Interface (Cryptoki). Through the use of standardized protocols and interfaces, developers can write both consumers and providers that need no modification as security technologies evolve.

An application, library, or kernel module that uses security services is called a consumer. An application that provides security services to consumers is referred to as a provider and also as a plug-in. The software that implements a cryptographic operation is called a mechanism. A mechanism is not just an algorithm but includes the manner in which the algorithm is to be applied. For example, one mechanism might apply the DES algorithm to authentication. A different mechanism might apply DES to data protection with block-by-block encryption.

The network security architecture eliminates the need for developers of consumers to write, maintain, and optimize cryptographic algorithms. Optimized cryptographic mechanisms are provided as part of the architecture.

The Solaris OS provides the following public Solaris interfaces for security:

• PAM – Pluggable authentication modules. PAM modules are mainly used for the initial authentication of a user to a system. The user can enter the system by GUI, command line, or some other means. In addition to authentication services, PAM provides services for managing accounts, sessions, and passwords. Applications such as login, rlogin, and telnet are typical consumers of PAM services. The PAM SPI is supplied services by security providers such as Kerberos v5 and Smartcard. See Chapter 3, Writing PAM Applications and Services.

• GSS-API – Generic security service application program interface. The GSS-API provides secure communication between peer applications. The GSS-API provides authentication, integrity, and confidentiality protection services as well. The Solaris implementation of the GSS-API works with Kerberos v5, SPNEGO, and Diffie-Hellman encryption. The GSS-API is primarily used to design or implement secure application protocols. GSS-API can provide services to other kinds of protocols, such as SASL. Through SASL, GSS-API provides services to LDAP.

  GSS-API is typically used by two peer applications that are communicating over a network after the initial establishment of credentials has occurred. GSS-API is used by login applications, NFS, and ftp, among other applications.

  See Chapter 4, Writing Applications That Use GSS-API for an introduction to GSS-API. Chapter 5, GSS-API Client Example and Chapter 6, GSS-API Server Example provides the source code descriptions of two typical GSS-API applications. Appendix A, Sample C-Based GSS-API Programs presents the code listings for the GSS-API examples. Appendix B, GSS-API Reference provides reference material for GSS-API. Appendix C, Specifying an OID demonstrates how to specify a mechanism other than the default mechanism.

• SASL – Simple authentication and security layer. SASL is used largely by protocols, for authentication, privacy, and data integrity. SASL is intended for higher-level network-based applications that use dynamic negotiation of security mechanisms to protect sessions. LDAP is one of the better-known consumers of SASL. SASL is similar to GSS-API. SASL is on a somewhat higher level than GSS-API. SASL consumes GSS-API services. See Chapter 7, Writing Applications That Use SASL.

• Cryptographic framework – The cryptographic framework is the backbone of cryptographic services in the Solaris OS. The framework provides standard PKCS #11 interfaces to accommodate consumers and providers of cryptographic services. The framework has two parts: the user cryptographic framework for user-level applications and the kernel cryptographic framework for kernel-level modules. Consumers that are connected to the framework need no special knowledge of the installed cryptographic mechanisms. Providers plug into the framework with no special code necessary for the different types of consumers.

  The consumers of the cryptographic framework include security protocols, certain mechanisms, and applications that need to perform cryptography. The providers to the framework are cryptographic mechanisms as well as other mechanisms in hardware and software plug-ins. See Chapter 8, Introduction to the Oracle Solaris Cryptographic Framework for an overview of the cryptographic framework. See Chapter 9, Writing User-Level Cryptographic Applications and Providers to learn how to write user-level applications that consume services from the framework.

  The library for the cryptographic framework is an implementation of the RSA PKCS#11 v2.11 specification. Both consumers and providers communicate with the user-level cryptographic framework through standard PKCS #11 calls.

• Smart Card – Developers of IFD handlers for smart card terminals can provide services to consumers through the terminal interface to the smartcard framework. Information on these interfaces is provided in Chapter 10, Using the Smart Card Framework.

• Java API – Java security technology includes a large set of APIs, tools, and implementations of commonly used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. Java security technology provides the developer with a comprehensive security framework for writing applications, and also provides the user or administrator with a set of tools to securely manage applications. See http://java.sun.com/javase/technologies/security/.