Security Flavors

This section describes the development and nature of the RPCSEC_GSS API.

Security Prior to RPCSEC_GSS

One of the first security flavors supported by RPC was AUTH_SYS (also known as AUTH_UNIX). AUTH_SYS provided a UNIX-style credential, using user and group IDs, to identify the sender and recipient of a message. AUTH_SYS is easy to implement; however, it is also easy to circumvent, since it does not provide true authentication -- that is, there is no way for a server to verify that a client is in fact whom it claims to be. Therefore, it is relatively simple to forge a network request under AUTH_SYS.

A later security flavor, AUTH_DES, appeared not long after AUTH_SYS. AUTH_DES is based on a public key authentication -- it uses a Diffie-Hellman key exchange to produce a common key between a client's private key and a server's public key. The common key is then used to encrypt a DES session key, which a server decrypts to establish a session.

Although AUTH_DES represented a significant advance over AUTH_SYS, it has some limitations to widespread usage. The main objection for many people is that the key size is, by today's encryption standards, somewhat undersized.

Eventually, another RPC security flavor was introduced. AUTH_KERB, based on Kerberos V4, provides yet better security than either AUTH_DES or AUTH_SYS. However, it too can be exploited.

For more information on these security flavors, see the ONC+ Developer's Guide.

Integrity and Privacy: The GSS-API

To improve security, a new networking layer, the Generic Security Standard API, or GSS-API, has been added. The GSS-API framework offers two extra security services beyond authentication:

• Integrity. With the integrity service, the GSS-API uses the underlying mechanism to authenticate messages exchanged between programs. Cryptographic checksums establish:

  • The identity of the data originator to the recipient

  • The identity of the recipient to the originator (if mutual authentication is requested)

  • The authenticity of the transmitted data itself

• Privacy. The privacy service includes the integrity service. In addition, the transmitted data is also encrypted so as to protect it from any eavesdroppers.

  Due to U.S. export restrictions, the privacy service might not be available to all SEAM users.

Currently, the GSS-API is not exposed. Certain GSS-API features, however, are "visible" through RPCSEC_GSS functions -- they can be manipulated in an "opaque" fashion. The programmer need not be directly concerned with their values.

The RPCSEC_GSS API

The RPCSEC_GSS security flavor allows ONC RPC applications to take advantage of the features of GSS-API. RPCSEC_GSS sits "on top" of the GSS-API layer as follows:

Figure 8-1 GSS-API and RPCSEC_GSS Security Layers

Using the programming interface for RPCSEC_GSS, ONC RPC applications can specify:

mechanism

A security paradigm. Each kind of security mechanism offers a different kind of data protection, as well as one or more levels of data protection. In this case, any security mechanism supported by the GSS-API (Kerberos V5, RSA public key, and so forth).

security service

Either privacy or integrity (or neither). The default is integrity The service is mechanism-independent.

QOP

Quality of Protection. The QOP specifies the type of cryptographic algorithm to be used to implement privacy or integrity services. Each security mechanism can have one or more QOPs associated with it.

Applications can obtain lists of valid QOPs and mechanisms through functions provided by RPCSEC_GSS. (See "Miscellaneous Functions".) Developers should avoid hard-coding mechanisms and QOPs into their applications, so that the applications will not need to be modified to use new or different mechanisms and QOPs.

Historically, "security flavor" and "authentication flavor" have meant the same thing. With the introduction of RPCSEC_GSS, "flavor" now has a somewhat different sense. A flavor can now include a service (integrity or privacy) along with authentication, although currently RPCSEC_GSS is the only flavor that does.

Using RPCSEC_GSS, ONC RPC applications establish a security context with a peer, exchange data, and destroy the context, just as they do with other flavors. Once a context is established, the application can change the QOP and service for each data unit sent.

For more information on RPCSEC_GSS, including RPCSEC_GSS data types, see the rpcsec_gss(3N) man page.