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 the
following figure.

Figure 4-1 GSS-API Layer

Broadly speaking, GSS-API does two main things:

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.

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.

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.

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 on RPCSEC_GSS, see Authentication Using RPCSEC_GSS in ONC+ Developer’s Guide.

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

Figure 4-2 RPCSEC_GSS and GSS-API

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.

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.