DB2 UDB provides a framework for writing customized security plug-ins that administrators can use for DB2 UDB authentication. This framework, introduced with DB2 UDB V8.2, also supports plug-in authentication based on Generic Security Service Application Programming Interface (GSS-API).
Many DB2 UDB administrators make use of GSS-API plug-ins for Kerberos-based authentication. With NFS V4 (Network File System Version 4, [IETF RFC-3530]) development on a roll, and its RFC mandating the use of newer GSS-API mechanisms like SPKM (Simple Public Key Mechanism, [IETF RFC-2025]) and LIPKEY (A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]), DB2 UDB will soon have GSS-API offerings that support these new security mechanisms.
Part 2 of the DB2 UDB Security series introduced and explained the DB2 UDB security plug-in architecture for authentication. This article takes you further with information about the new GSS-API security mechanisms. It then describes how you can achieve authentication based on public key technology, using the new GSS-API security mechanisms with the customizable DB2 UDB security plug-ins.
DB2 UDB security plug-in for authentication
Authentication is the process of validating user-supplied credentials using a security mechanism, as discussed in Part 1 of the DB2 security series. In DB2 UDB, user and group authentication is managed in a facility external to DB2 UDB, such as the operating system, a domain controller, or a Kerberos security system, in the form of a plug-in.
A security plug-in is a dynamically loadable library that DB2 UDB loads to provide the following functionality:
- Group retrieval plug-in: retrieves group membership information for a given user
- Client authentication plug-in: manages authentication on a DB2 client.
- Server authentication plug-in: manages authentication on a DB2 server.
DB2 UDB supports two mechanisms for plug-in authentication:
- Authentication using a user ID and password, which is known as user ID/password authentication.
- Authentication using GSS-API, formally known as Generic Security Service Application Program Interface, Version 2 [IETF RFC2743] and Generic Security Service API Version 2: C-Bindings [IETF RFC2744].
In DB2 Version 8.2, the default behavior is to use a user ID/password plug-in that implements an authentication mechanism at the operating system level. The following diagram gives a high-level view of the DB2 UDB security plug-in infrastructure:
Figure 1. High-level view of DB2 UDB security plug-in infrastructure
With the DB2 UDB security plug-in architecture, you can customize its authentication behavior by either developing your own plug-ins, or buying plug-ins from a third party. To enable you to customize DB2 UDB authentication behavior, DB2 UDB has exposed APIs that you can use to modify existing plug-ins or build new security plug-ins. This article will concentrate on authentication using GSS-API, and show you how to make use of newer GSS-API security mechanisms like SPKM (Simple Public Key Mechanism, [IETF RFC-2025]) and LIPKEY (A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]) for DB2 UDB authentication.
GSS-API and its upcoming support for SPKM/LIPKEY security mechanism
The Generic Security Service Application Program Interface, referred to as GSS-API, as defined in [IETF RFC-2743], "provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments." (See (RFC) 2743 in the Resource section.) It is a set of programming interfaces that abstracts identity authentication, message origin authentication and integrity, and message confidentiality. Thus, a secure application developed using GSS-API can work over different security mechanisms without changes to the application.
As of today, the only security mechanism supported by most of the GSS-API offerings is the popular symmetric key-based mechanism called Kerberos [IETF RFC-1964]. But with the development of NFS V4 [IETF RFC-3530] gaining momentum, programmers will soon hear vendors coming up with support for additional security mechanisms like SPKM and LIPKEY in their GSS-API offerings. The prime reason for this increased support is that the NFS V4 [IETF RFC-3530] has mandated the use of SPKM and LIPKEY security mechanisms for its security module. Thus the above requirement will force vendors to extend their GSS-API framework to support SPKM and LIPKEY in addition to Kerberos, which will continue be the default GSS-API mechanism. The major difference between Kerberos and SPKM-3/LIPKEY is that the former is a purely symmetric key-based security mechanism, while the latter is a blend of symmetric key-based security mechanisms and public key technology. The overview of the SPKM and LIPKEY mechanisms given below will provide an insight to what it offers to applications.
SPKM (Simple Public Key Mechanism, IETF RFC-2025)
SPKM is a GSS-API mechanism which is based on a public key rather than a
symmetric key infrastructure. SPKM provides authentication, key
establishment, data integrity, and data confidentiality in an online
distributed application environment using a public key infrastructure. It
allows both unilateral and mutual authentication to be accomplished
without the use of secure timestamps. The SPKM uses Algorithm Identifiers
to specify various algorithms to be used by the communicating peers. It
allows the option of a digital signature, based on a truly asymmetric
algorithm, in the GSS-API functions relating to signing and encrypting
messages such as
gss_seal() operations (now called
gss_wrap() in [GSSv2]), rather than an
integrity checksum based on a MAC computed with a symmetric algorithm
(such as DES). SPKM data formats and procedures are designed to be as
similar to those of the Kerberos mechanism as is practical. This is done
for ease of implementation in those environments where Kerberos has
already been implemented. So for applications that need to have a GSS-API
mechanism which is based on a public-key infrastructure, SPKM is the
answer. For more information, refer to IETF RFC 2025 (see Resources).
LIPKEY (A Low Infrastructure Public Key Mechanism using SPKM, IETF RFC-2847):
GSS-API mechanisms like Kerberos V5 [IETF RFC-1964] and SPKM [IETF RFC-2025] require a great deal of infrastructure. As mentioned in IETF RFC 2847, LIPKEY is a low infrastructure based GSS-API security mechanism which maps to a typical TLS (Transport Layer Security) deployment scenario. It consists of a client with no public key certificate, accessing a server with a public key certificate.
In this mechanism, the client:
- Obtains the server's certificate,
- Verifies that it was signed by a trusted Certification Authority (CA),
- Generates a random session symmetric key,
- Encrypts the session key with the server's public key, and
- Sends the encrypted session key to the server.
At this point, the client and server have a secure channel. The client can then provide a user name and password to the server to authenticate the client. The LIPKEY mechanism can be used when the initiator (client) does not have a certificate and instead uses a user ID and password for authentication. For more information, refer to IETF RFC 2847 (see Resources).
DB2 UDB Authentication using newer supported GSS-API mechanism
DB2 UDB V8.2 supports the GSS-API authentication mechanism. In fact, the IBM-supplied sample Kerberos security plug-in for DB2 UDB is based on GSS-API. In other words, IBM's Kerberos support is provided as a GSS-API security plug-in, which you can use for both server and client authentication. Further, GSS-API security plug-ins for DB2 UDB bring more value as you will soon have GSS-API libraries supporting both the traditional symmetric key security mechanism (namely Kerberos), and the upcoming asymmetric key security mechanism like SPKM and LIPKEY, thanks to the NFS V4 implementation.
To enable DB2 UDB to use SPKM/LIPKEY mechanisms for authentication:
- Write customized GSS-API security plug-ins that will support SPKM/LIPKEY security mechanisms. Naturally, this will require a GSS-API offering which supports SPKM/LIPKEY mechanisms. For customizing authentication, DB2 UDB provides a framework by exposing certain APIs for developers so that they can write their own authentication plug-ins. When you develop a security plug-in, you will need to implement the standard authentication functions that DB2 UDB invokes. Writing a GSS-API plug-in to support SPKM/LIPKEY is very similar to writing a Kerberos security plug-in, with slight differences as indicated later. For better understanding of how to write a GSS-API security plug-in, you should read and understand the IBM-supplied Kerberos security plug-in for DB2 UDB, which is based on GSS-API (see Resources).
- For SPKM-based authentication, you will typically need:
- On the DB2 UDB server: an X.509 certificate, a PKI (Public Key Infrastructure) environment, and a SPKM-enabled server-side GSS-API security plug-in.
- On the DB2 UDB client: an X.509 certificate, a PKI environment, and a SPKM-enabled client-side GSS-API security plug-in.
- For LIPKEY-based authentication, you will typically need:
- On the DB2 UDB server: an X.509 certificate, a PKI environment, and a LIPKEY-enabled server-side GSS-API security plug-in. The DB2 sever will also need to have access to the user ID/password database for client-side authentication. Typically, a GSS-API offering that supports the LIPKEY mechanism will provide detailed information about the user ID/password database.
- On the DB2 UDB client: a LIPKEY-enabled client-side GSS-API security plug-in. Notice that the client is not required to have any X.509 certificate, but may need to have a PKI environment in order to validate the server's X.509 certificate. This typically will be documented in detail by the GSS-API offering that supports LIPKEY mechanism.
The following figures depict a high-level view of how DB2 UDB authentication works when you use a GSS-API plug-in enabled for SPKM or LIPKEY.
Figure 2. High-level view of DB2 UDB authentication using the SPKM security mechanism.
Figure 3. High-level view of DB2 UDB authentication using the LIPKEY security mechanism.
As you can see in the above figures, the authentication is achieved by exchange of GSS-API tokens, which is very typical with the GSS-API security model. The key points to notice here are:
- With the SPKM security mechanism, the DB2 UDB client and the DB2 UDB server are authenticated on the basis of the X.509 certificate they possess.
- With the LIPKEY mechanism, the X.509 certificate is used only for server authentication, while the client authentication is achieved by using the user ID and password entered by the client (thus qualifying it as a low infrastructure public key mechanism). Additionally, LIPKEY mechanism is designed such that the data exchange of the user ID, the password, and the authentication result all takes place over a secured network channel between the client and the server.
Developing a GSS-API plug-in to support SPKM or LIPKEY is similar to developing a Kerberos security plug-in for DB2 UDB, except for few changes which we will list in this section. The following discussion assumes that you are familiar with DB2 UDB security plug-in programming, and with the Kerberos security plug-in shipped with DB2 UDB. For more information, refer to the DB2 UDB documentation (see Resources).
When you develop a DB2 UDB security plug-in, you will need to implement the
standard authentication functions that DB2 will invoke:
db2secServerAuthPluginTerm(), and so on. For a
GSS-API authentication plug-in, you will also need to implement the
GSS-API functions mentioned in the DB2 UDB documentation:
gss_acquire_cred(), and so on. You can find an
example implementation in IBMkrb5.c, a sample Kerberos security plug-in
shipped with DB2 UDB. The following guidelines showcase the key
considerations for developing SPKM or LIPKEY-enabled GSS-API plug-ins for
- Get a copy of a GSS-API offering that supports SPKM or LIPKEY mechanisms (or both) and set up the required PKI environment.
- While implementing the
db2secServerAuthPluginInit()function for the plug-in:
- Make sure you explicitly acquire credentials for the desired
security mechanism. To do this, pass the appropriate mechanism
OID (as defined in the header file of your GSS-API offering)
gss_acquire_cred(). Note that if you specify
GSS_C_NO_OID_SETas the desired mechanism OID,
gss_acquire_cred()will fetch credentials for the default security mechanism, which usually will be Kerberos.
- For LIPKEY and SPKM mechanisms, be sure to populate the server
principal name (for which the credentials will be acquired)
with the subject name of the X.509 certificate associated with
the DB2 server. Generally, the DB2 instance name is assumed to
be the name of the server. In such cases, you should make sure
that the subject name (or at least the common name component
of the subject name) in the X.509 certificate associated with
the DB2 server matches with the DB2 instance name. If this is
not the case, the
gss_acquire_cred()function will fail to fetch the server credentials.
- Make sure you explicitly acquire credentials for the desired security mechanism. To do this, pass the appropriate mechanism OID (as defined in the header file of your GSS-API offering) to
- In your
db2secGenerateInitialCred()function implementation, make sure that you explicitly acquire credentials for the desired security mechanism. To do this, pass the appropriate mechanism OID (as defined in the header file of your GSS-API offering) to
gss_acquire_cred(). For the LIPKEY mechanism in particular, during the execution of
db2secGenerateInitialCred(), the client will be prompted for a user ID and password, which will be used for client side authentication.
- In your implementation of the
db2secProcessServerPrincipalName()function, you will convert a text service principal name into the GSS-API internal format for use with the other APIs. To do this, use the
gss_import_name()function. The text service principal name should typically match the subject name (or at least the common name component of the subject name) in the X.509 certificate associated with the DB2 server, or with the server principal name for which the credentials are acquired at the server end.
- You will need to wrap or override the
gss_init_sec_context()function to make sure that you pass the correct desired mechanism OID, in order to initiate a security context for the desired mechanism. The GSS-API default behavior will be to initiate the context for Kerberos security mechanism.
Implementing the remaining DB2 UDB API functions will be similar to programming GSS-API security plug-ins as described in the DB2 UDB documentation, and as implemented in the sample Kerberos security plug-in shipped with DB2 UDB.
With additional security mechanisms like SPKM and LIPKEY being supported by GSS-API, DB2 UDB administrators/programmers should consider implementing newer GSS-API security plug-ins enabled with these mechanisms. With the support for these forthcoming GSS-API mechanisms (SPKM3 and LIPKEY), the use of GSS-API plug-ins will avail DB2 UDB administrators to have DB2 UDB authentication based on either the public key technology or the traditional symmetric-key mechanism without much code change.
- "Quick Beginnings for DB2 Servers Version 8.2": DB2 UDB Documentation describing DB2 UDB server installations.
- "DB2 Online Information Center": The most recent DB2 online (and searchable) documentation. Learn about:
- "DB2 UDB security, Part 1: Understand how user and group accounts interact with DB2 UDB"(developerWorks, Aug 2005) provides broad understanding of DB2 UDB Security Model.
- For details on the Generic Security Services Application Program Interface, see IETF Request for Comments (RFC) 2743, "Generic Security Services Application Program Interface Version 2, Update 1."
- For details on the Simple Public-Key GSS-API Mechanism (SPKM), see IETF Request for Comments (RFC) 2025, "The Simple Public-Key GSS-API Mechanism (SPKM)."
- For details on LIPKEY, A Low Infrastructure Public Key Mechanism Using SPKM, see IETF Request for Comments (RFC) 2847, "LIPKEY -- A Low Infrastructure Public Key Mechanism Using SPKM."
- For details on NFS V4, see IETF Request for Comments (RFC) 3530, "Network File System (NFS) version 4 Protocol."
- Stay current with developerWorks technical events and Webcasts.
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.
- Participate in developerWorks blogs and get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.