Skip Navigation Links | |
Exit Print View | |
![]() |
Developer's Guide to Oracle Solaris Security Oracle Solaris 10 8/11 Information Library |
1. Oracle Solaris Security for Developers (Overview)
2. Developing Privileged Applications
3. Writing PAM Applications and Services
4. Writing Applications That Use GSS-API
Application Portability With GSS-API
Available Mechanisms in GSS-API
Strings and Similar Data in GSS-API
Mechanisms and QOPs in GSS-API
Interprocess Tokens in GSS-API
Developing Applications That Use GSS-API
Working With Credentials in GSS-API
Acquiring Credentials in GSS-API
Working With Contexts in GSS-API
Initiating a Context in GSS-API
Accepting a Context in GSS-API
Using Other Context Services in GSS-API
Delegating a Credential in GSS-API
Performing Mutual Authentication Between Peers in GSS-API
Performing Anonymous Authentication in GSS-API
Using Channel Bindings in GSS-API
Exporting and Importing Contexts in GSS-API
Obtaining Context Information in GSS-API
Sending Protected Data in GSS-API
Tagging Messages With gss_get_mic()
Wrapping Messages With gss_wrap()
Handling Wrap Size Issues in GSS-API
Detecting Sequence Problems in GSS-API
Confirming Message Transmission in GSS-API
7. Writing Applications That Use SASL
8. Introduction to the Oracle Solaris Cryptographic Framework
9. Writing User-Level Cryptographic Applications and Providers
10. Using the Smart Card Framework
A. Sample C-Based GSS-API Programs
D. Source Code for SASL Example
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.
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.
GSS-API provides three types of security services:
Authentication – Authentication is the basic security offered by GSS-API. 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.
The current implementation of GSS-API works with the following mechanisms: Kerberos v5, Diffie-Hellman, and SPNEGO. For more information on the Kerberos implementation, see Chapter 21, Introduction to the Kerberos Service, in System Administration Guide: Security Services for more information. Kerberos v5 should be installed and running on any system on which GSS-API-aware programs are running.
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+ 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
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().
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.
These two documents provide further information about GSS-API:
Generic Security Service Application Program Interface document (ftp://ftp.isi.edu/in-notes/rfc2743.txt) provides a conceptual overview of GSS-API.
Generic Security Service API Version 2: C-Bindings document (ftp://ftp.isi.edu/in-notes/rfc2744.txt) discusses the specifics of the C-language-based GSS-API.