Go to main content

Developer's Guide to Oracle® Solaris 11.3 Security

Exit Print View

Updated: April 2020

Introduction to GSS-API

GSS-API enables programmers to write applications generically with respect to security. Developers do not have to tailor the security implementations to any particular platform, security mechanism, type of protection, or transport protocol. With GSS-API, a programmer can avoid the details of protecting network data. A program that uses GSS-API is more portable with regards to network security. This portability is the hallmark of the Generic Security Service API.

GSS-API is a framework that provides security services to callers in a generic fashion. The GSS-API framework is supported by a range of underlying mechanisms and technologies, such as Kerberos v5 or public key technologies, as shown in GSS-API Layer.

Figure 2  GSS-API Layer

image:Diagram shows the GSS-API and protocol layers between the application and             the security mechanisms.

    Broadly speaking, GSS-API does two main things:

  1. GSS–API creates a security context in which data can be passed between applications. A context is a state of trust between two applications. Applications that share a context recognize each other and thus can permit data transfers while the context lasts.

  2. GSS–API applies one or more types of protection, known as security services, to the data to be transmitted. Security services are explained in Security Services in GSS-API.

    In addition, GSS-API performs the following functions:

  • Data conversion

  • Error checking

  • Delegation of user privileges

  • Information display

  • Identity comparison

GSS-API includes numerous support and convenience functions.

Application Portability With GSS-API

    GSS-API provides several types of portability for applications:

  • Mechanism independence. GSS-API provides a generic interface for security. By specifying a default security mechanism, an application does not need to know the mechanism to be applied nor any details about that mechanism.

  • Protocol independence. GSS–API is independent of any communications protocol or protocol suite. For example, GSS–API can be used with applications that use sockets, RCP, or TCP/IP.

    RPCSEC_GSS is an additional layer that smoothly integrates GSS-API with RPC. For more information, see Remote Procedure Calls With GSS-API.

  • Platform independence. GSS-API is independent of the type of operating system on which an application is running.

  • Quality of Protection independence. Quality of Protection (QOP) refers to the type of algorithm for encrypting data or generating cryptographic tags. GSS-API allows a programmer to ignore QOP by using a default that is provided by GSS-API. On the other hand, an application can specify the QOP if necessary.

Security Services in GSS-API

    GSS-API provides three types of security services:

  • Authentication – The basic security offered by GSS-API is authentication. Authentication is the verification of an identity. If a user is authenticated, the system assumes that person is the one who is entitled to operate under that user name.

  • Integrity – Integrity is the verification of the data's validity. Even if data comes from a valid user, the data itself could have become corrupted or compromised. Integrity ensures that a message is complete as intended, with nothing added and nothing missing. GSS-API provides for data to be accompanied by a cryptographic tag, known as an Message Integrity Code (MIC). The MIC proves that the data that you receive is the same as the data that the sender transmitted.

  • Confidentiality – Confidentiality ensures that a third party who intercepted the message would have a difficult time reading the contents. Neither authentication nor integrity modify the data. If the data is somehow intercepted, others can read that data. GSS-API therefore allows data to be encrypted, provided that underlying mechanisms are available that support encryption. This encryption of data is known as confidentiality.

Available Mechanisms in GSS-API

The current implementation of GSS-API works with the following mechanisms: Kerberos v5, Diffie-Hellman, and SPNEGO. For more information about the Kerberos implementation, see Managing Kerberos and Other Authentication Services in Oracle Solaris 11.3 for more information. Kerberos v5 should be installed and running on any system on which GSS-API-aware programs are running.

Remote Procedure Calls With GSS-API

Programmers who use the RPC (Remote Procedure Call) protocol for networking applications can use RPCSEC_GSS to provide security. RPCSEC_GSS is a separate layer that sits on top of GSS-API. RPCSEC_GSS provides all the functionality of GSS-API in a way that is tailored to RPC. In fact, RPCSC_GSS serves to hide many aspects of GSS-API from the programmer, making RPC security especially accessible and portable. For more information about RPCSEC_GSS, see Authentication Using RPCSEC_GSS in ONC+ RPC Developer’s Guide.

The following diagram illustrates how the RPCSEC_GSS layer sits between the application and GSS-API.

Figure 3  RPCSEC_GSS and GSS-API

image:Diagram shows the RPCSEC_GSS layer, which provides security for remote               procedure calls.

Limitations of GSS-API

    Although GSS-API makes protecting data simple, GSS-API avoids some tasks that would not be consistent with GSS-API's generic nature. Accordingly, GSS-API does not perform the following activities:

  • Provide security credentials for users or applications. Credentials must be provided by the underlying security mechanisms. GSS-API does allow applications to acquire credentials, either automatically or explicitly.

  • Transfer data between applications. The application has the responsibility for handling the transfer of all data between peers, whether the data is security-related or plain data.

  • Distinguish between different types of transmitted data. For example, GSS-API does not know whether a data packet is plain data or encrypted.

  • Indicate status due to asynchronous errors.

  • Protect by default information that has been sent between processes of a multiprocess program.

  • Allocate string buffers to be passed to GSS-API functions. See Strings and Similar Data in GSS-API.

  • Deallocate GSS-API data spaces. This memory must be explicitly deallocated with functions such as gss_release_buffer() and gss_delete_name().

Language Bindings for GSS-API

This document currently covers only the C language bindings, that is, functions and data types, for GSS-API. A Java-bindings version of GSS-API is now available. The Java GSS-API contains the Java bindings for the Generic Security Services Application Program Interface (GSS-API), as defined in RFC 2853.

Where to Get More Information on GSS-API