Multi-security mechanisms with multifactor authentications

The approach for designing and implementing a multi-security mechanism with multifactor authentication for AIX and UNIX systems

Authentication is a the key component of security-based solutions. In client-server models designed over UNIX® systems, distributed network security is of significant importance. In order to meet the stringent security requirements necessary in client-server models, either multi-layer authentication or multifactor authentication or combinations of both are being used by existing systems. This article discusses the risk associated with the use of the same security mechanism in multifactor authentication systems and proposes the use of GSS-API ( Generic Security Service available with most of the UNIX systems) as a suitable option for achieving the multi-security mechanism clubbed with multi-factor authentication for enhanced security for solutions designed over UNIX.


Sandeep Ramesh Patil (, Advisory Software Engineer, EMC

Photo of SandeepRamesh PatilSandeep Ramesh Patil is an Advisory Software Engineer for the IBM India System and Technology Lab. His professional experience has been on distributed technology and security products such as the IBM Network Authentication Services (IBM Kerberos). He is an IBM developerWorks Professional Author with most of his articles on information security. He also plays a active role in IP generation. Sandeep holds a BE degree in computer science and engineering from the University of Pune, India. You can contact him at .

10 March 2009

Also available in Chinese


Security is a key aspect of software engineering. Authentication, authorization, privacy, integrity, and non-reputation are the major security components of software or a software-based solution working over the network. Out of these, authentication is one of the most important components. As defined, authentication is proving who you are. There are various authentication methods in UNIX systems, like password-based authentication, authentication using smart cards, authentication based on biometric technology, and more being practiced. These authentications over the network are exercised using various security mechanisms. SSL/TLS (Secure Socket Layer / Transport Layer Security Version 1.0, RFC 2246) and Kerberos (The Kerberos Network Authentication Service (V5), RFC 1510) are a few of the many security mechanisms used for authentication over the network. AIX® has an integrated login support for Kerberos. Solutions and softwares targeted for industries like finance, banking, and insurance have very stringent security requirements. To meet these stronger security needs, either multi-layer authentication or multifactor authentication or combinations of both are used. Most of the solutions exercising multifactor as well as multi-layer authentication make use of the same underlying network security mechanism. This is a risk, especially when addressing stronger security requirements.

This article discusses the risks associated with systems using the same network security mechanism for multifactor or multi-layer authentication. It states the need to have solutions built using multi-security mechanisms with multifactor authentication. This article also introduces the Generic Security Service Application Programming Interface (GSS-API), available on AIX and other UNIX operating systems, and proposes it as a suitable option for achieving the multi-security mechanism clubbed with multifactor authentication.

Industry requirements for stronger authentication over wire

Communicating electronically has become essential for all industrial sectors, including healthcare, telecom, pharmacy, retail, finance, and more. Throughout the world, almost all of these industries have their own tailor-made software-based systems and solutions that network their clients and business partners together. Security plays a vital role for all these systems and is especially important to the finance sector.

Fancial institutions are exposed to a higher risk from security breaches than companies in other sectors, as the transactions carried out by financial organizations are mostly based on money and hence of greater value and interest. Thus, generally they are the target for prolonged and determined attacks. Therefore, financial institutions working in the domain of banking, insurance, asset management, and stock markets have to meet external stringent requirements to safeguard all the electronic data being processed by their applications. They have to design and implement software solutions and applications that meet these tight security requirements. In other words, the systems need to ensure a high level of security compliance. As stated by the FFIEC (Federal Financial Institutions Examination Council) in its financial institution letter (FIL-103-2005, October 12, 2005) titled Authentication in an Internet Banking Environment, "The risks of doing business with unauthorized or incorrectly identified persons in an Internet banking environment can result in financial loss and reputation damage through fraud, disclosure of consumer information, corruption of data, or unenforceable agreements." The letter clarifies the importance of authentication over the wire by highlighting that the "risk assessments should provide the basis for determining an effective authentication strategy according to the risks associated with the various products and services available to on-line customers" (for details see the Resources section). Thus, establishing robust identity management processes to achieve authentication and authorization is one of the key aspects to successfully compile a secure software solution.

Security needs for distributed solutions are not only confined to the finance sector, but are equally vital to other industrial domains like telecom, healthcare, pharmacy, and more, which also require highly secure solutions. Hence, to meet the ever-growing need for secure systems over UNIX, most of the offerings have opted for multifactor and multi-layered (step-up) authentication over single-factor authentication methodology, which may not provide sufficient protection.

In the proposed design for a two-factor authentication system , you can make use of Kerberos for the first-factor authentication and then make use of the Kerberos infrastructure (using the GSS-API interface) to securely achieve the second-factor authentication using the One-Time Password (OTP) token. In this way, you achieve a secure two-factor authentication wherein the Kerberos protocol plays a dual role.

Multifactor and multi-layer authentication

In multifactor authentication, the authenticity of an identity is verified and validated using more than one validation mechanism. Two-factor authentication (T-FA) is one of the well-known forms of multifactor authentication. Typically, a two-factor authentication implementation uses "something you know" (a password) as one of the two factors, and uses either "something you have" (a physical device) or "something you are" (a biometric such as a fingerprint) as the other factor. A common example of T-FA is a bank card (credit card, debit card); the card itself is the physical "something you have" item, and the personal identification number (PIN) is the "something you know" (password) that is associated with it.

Multifactor authentication is generally used by systems to create a higher degree of security in order to mitigate the risk from criminals. Hence, it is generally preferred for solutions targeted for financial and related industries. Often people tend to consider multi-layer authentication as a synonym to multifactor authentication. However, there is a clear line of differentiation between multifactor authentication and multi-layer authentication.

Multifactor authentication itself can be layered. In multi-layer authentication, the authentication levels denote whether additional authentication is necessary to access a protected object. This means that an additional authentication step is required in order to access resources that require more restrictive-access policies.

Multi-layer authentication can be considered similar to step-up authentication defined by IBM® Tivoli® Access Manager for e-business. In traditional multi-layered authentication, the system is layered into sub-components where access to certain sub-components require valid authentication to the base component plus additional authentication information confined to that particular sub-component, generally using the same validation mechanism. For example, in a banking system that implements multi-layer authentication, its users are required to enter a user name and password (something the user knows) to log into the system, which is the basic authentication for this system. The base authentication allows users to carry out basic tasks like viewing previous transactions. But, if the users wants to carry out certain transactions (like transferring money), then in addition to the basic authentication, the user is also required to enter a "transaction password" (which is again "something the user knows," unlike in multifactor authentication) to be eligible to carry out the transaction.

Multifactor authentication together with multi-layer authentication provides a more secure solution than traditional single password authentication.

The need for multi-security mechanisms with multifactor authentication

Despite its advantages, most of the solutions exercising multifactor as well as multi-layer authentication make use of the same underlying network security mechanisms. This is a problem, especially when addressing stronger security requirements. For example, most of the Web-based systems for banking domains implementing a basic two-factor authentication scheme either use SSL/TLS or HTTPS protocol (Secure HyperText Transfer Protocol, RFC 2660) as the underlying network security mechanism.

To successfully log into such systems, the end user is typically required to:

  1. Submit the correct password (where the authentication information required is something that one should know). This forms the first factor of the authentication.
  2. Submit the last four digits of the user's ATM card number (where the authentication information required is something that one has). This forms the second factor of the two-factor authentication, where it is assumed that only the user will have access to his ATM card.

In these cases, the two-factor authentication makes the system more secure as, in order to hack the system, the malicious user not only has to guess the user's password, but also needs to have access to the user's ATM card to know its numbers. This sounds secure. But the point to note is that in both the factors (of the two-factor authentication), the system makes use of the same underlying security mechanism (SSL/TLS/HTTPS) for network authentication. This brings up a few questions: What if a malicious user hacks the underlying security mechanism itself? What if a hacker discovers a vulnerability in the security mechanism that allows him to break through the authentication without the need to know the required user's authentication information? What if someone exploits some unknown limitations of the security mechanism to break through? And, since both the factors in the two-factor authentication make use of the same underlying security mechanisms for network authentication, the advantages of having dual authentication is totally negated. This is a risk and an area of concern for systems where there is a need for highly secure solutions.

To tackle this problem, here is one proposed approach. The systems implementing multifactor authentication should make sure that they use different underlying security mechanisms for different factors. This will drastically reduce the stated risk. So, for example, if a two-factor authentication with the first factor making use of Kerberos as its underlying network security mechanism while the second factor makes use of LIPKEY (A Low Infrastructure Public Key Mechanism using SPKM, RFC 2847) or NTLM (NT LAN Manager, a Microsoft® authentication protocol) as the underlying network security mechanism, then the stated risk is reduced as the chances for a malicious user to break two totally different security mechanism are reduced. This contributes towards strengthening the overall system security by declining the stated risk. The same holds true for systems implementing multi-layer authentication instead of multifactor authentication.

The option of Generic Security Service Application Program Interface

The Generic Security Service Application Program Interface, referred to as GSS-API, as defined in [RFC-2743] (see the Resources section), 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. 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. Typically in GSS-API, a secure connection between two communicating applications is represented by a data structure called a security context. The application that establishes the secure connection is called the context initiator. The application that accepts the secure connection is the context acceptor. The context establishment between the initiator and the acceptor is actually a handshake process, which involves authenticating both the parties. On successful establishment of GSS-API context, it can be concluded that the user identification of the communicating parties have been successfully verified.

The UNIX distributed filesystem, Network File System Version 4 (NFS v4), makes use of GSS-API for its on-wire security (see the Resources section). Almost all UNIX operating systems, including AIX, support and provide GSS-API. IBM Network Authentication Service for AIX Version 1.4 exports GSS-API, which can be used for secure solutions over AIX. GSS-API has been on the market for quite some time with most of its offerings supporting only the secret-key security mechanism, namely Kerberos. Because of this limitation, GSS-API has not been potentially used. But, NFS v4 mandates the use of newer mechanisms like SPKM (Simple Public Key Mechanism) and LIPKEY (Low Infrastructure Public Key Mechanism), and is expected to be available on UNIX systems using GSS-API. Hence, application programmers should become aware of the benefits of GSS-API and consider using it for the security aspects of their applications. Some implementations of GSS-API, like the Microsoft's SSPI (Security Support Provider Interface), already have support for multiple security mechanisms like NTLM, Kerberos, and SSL. Architects, who see the requirement to make their applications operate in multiple security infrastructure environments, would benefit by exploring the GSS-API framework as opposed to directly using the mechanism-specific APIs in their applications.

You can use the GSS-API framework with multifactor authentication to achieve a multi-security mechanism with multifactor authentication. This combination helps reduce the risks associated with systems exercising multifactor authentication solutions using the same underlying security mechanism. With GSS-API, these systems can be designed to make use of different underlying security mechanisms for different factors of the multifactor authentication. Using GSS-API, you can explicitly state the underlying security mechanism that the application wants to exercise for authentication by simply specifying the correct mechanism-specific object identifier (OID) during the GSS-API handshake process. So, for example, in a system implementing two-factor authentication, the developer can pass a specific security mechanism OID (for example, Kerberos) to GSS-API for the first-factor authentication and on success can then reinitiate the GSS-API authentication handshake with a different security mechanism OID (for example, LIPKEY) for the second factor authentication. Since the Kerberos mechanism (which is based on pure symmetric key technology) is distinctly different from the LIPKEY mechanism (which is based on both symmetric as well as asymmetric key technology), it will be that much harder for the malicious user to break through both the mechanisms to hack the system. Hence, such a system will mitigate the risk associated with the use of single-security mechanisms in both the factors in a two-factor authentication.

Figure 1 shows that IT architects designing highly secure systems over UNIX using two-factor authentication can make use of the GSS-API framework to explicitly have two different security mechanisms for dual-factor authentication. In order to break through such a system, the malicious user needs to explicitly hack two distinctly different security mechanisms, as opposed to a single security mechanism, thus ensuring a higher degree of security.

Figure 1. Flow of processes to achieve multi-security with multifactor authentication using GSS-API
Flow of processes to achieve multi security mechanism with multi-factor authentication using GSS-API

For more information on GSS-API programming, please refer to IBM Network Authentication Service Version 1.4 for AIX Application Development Reference, shipped with the product. IBM Network Authentication Service Version 1.4 for AIX is available with the AIX Expansion Pack CD or can be downloaded from IBM AIX Web Download Pack Programs (see Resources).


This article discussed the importance of security in general and authentication in particular. It also highlighted the fact that despite being more secure, multifactor authentication is exposed to security risks if implemented with a single underlying security mechanism. It states the need to have a multi-security mechanism combined with multifactor authentication for enhanced security. Finally, it recommends the use of GSS-API (available with most UNIX operating systems like AIX) to help achieve readiness to incorporate newer security mechanisms.



Get products and technologies


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 AIX and Unix on developerWorks

Zone=AIX and UNIX
ArticleTitle= Multi-security mechanisms with multifactor authentications