DB2 UDB security, Part 3: Security plug-ins using the GSS-API security mechanisms (SPKM / LIPKEY)

Use the new GSS-API security mechanisms to customize the IBM® DB2® Universal Database™ (DB2 UDB) security plug-ins to achieve authentication based on public key technology.

Share:

Sandeep Patil (rsandeep@in.ibm.com), Staff Software Engineer, IBM

Sandeep Patil photoSandeep Patil has a B.E. degree in Computer Science and Engineering from the University of Pune, India. He has worked for IBM for the past 5 years, focusing on distributed technology including DCE, SARPC, and security products such as the IBM Network Authentication Services (IBM Kerberos). He was involved in development and porting of IBM NAS1.4 on Windows. He is currently developing new features and implementing security-related RFC for the IBM Network Authentication Services, along with its product support. You can contact the him at rsandeep@in.ibm.com.



08 December 2005

Introduction

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
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_sign() and gss_seal() operations (now called gss_getMIC() and 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:

  1. Obtains the server's certificate,
  2. Verifies that it was signed by a trusted Certification Authority (CA),
  3. Generates a random session symmetric key,
  4. Encrypts the session key with the server's public key, and
  5. 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:

  1. 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).
  2. 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.
  3. 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.
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.
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: db2secClientAuthPluginInit(), db2secClientAuthPluginTerm(), db2secServerAuthPluginInit(), 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_init_sec_context(), gss_accept_sec_context(), 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 DB2 UDB.

  1. Get a copy of a GSS-API offering that supports SPKM or LIPKEY mechanisms (or both) and set up the required PKI environment.
  2. 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) to gss_acquire_cred(). Note that if you specify GSS_C_NO_OID_SET as 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.
  3. 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.
  4. 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.
  5. 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.


Conclusion

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.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=100208
ArticleTitle=DB2 UDB security, Part 3: Security plug-ins using the GSS-API security mechanisms (SPKM / LIPKEY)
publish-date=12082005