Renewal or Replacement of the MFCF/CSCF Two-factor Authentication System (SecurID)


As of June 1st 2005, we are running low on SecurID tokens and the maintenance contract will be soon up for renewal. Now is a good opportunity to review how we are using the service, what it takes to make it current, how we can change it for the better, and how we can expand it.

Current State

Currently, two-factor authentication is used when staff wish to obtain super-user access on xhiered Solaris hosts. Access is obtained via the ssuw command. The ssuw program looks in a file named securid_users for the userid of the user invoking the command. If the userid is present, the ssuw program, using an API provided by RSA, forwards the userid and given passcode to a SecurID ACE server (via a proprietary protocol). Access to a privileged shell is granted when the ACE server gives the OK.

The ssuw command is only available on a limited number of Unix architectures, not including Linux, and two-factor authentication is not currently made available for other critical devices, such as console servers, network switches, and firewalls.

As of June 1st 2005, there are only 2 SecureID tokens left for MFCF/CSCF staff use, and one of the two ACE servers is out of service permanently. The ACE server software currently in use is no longer supported by RSA.

Future Directions

In order to continue the use of two-factor authentication in MFCF/CSCF, work needs to be done to either upgrade what we have, or replace it. This is also an oportunity to consider other vendors that offer similar technologies. In either case, we should look at using existing technologies to build this authentication mechanism, rather than re-developing and maintaining a custom application such as ssuw.

Most, if not all vendors of two-factor authentication systems support RADIUS. RADIUS can be thought of as the lowest-common denominator of authentication protocols, since the majority of operating systems and managed network devices support it.

Today, most Unix-based operating systems support Pluggable-Authentication-Modules (PAM). Since the su command, on both Linux and Solaris, support PAM and the freeradius project has a PAM module available, then we could configure the su command to use a RADIUS server via PAM to authenticate. Another thing to consider is using sudo instead of su. The sudoers file might give some excellent functionality.

Another advantage that RADIUS has is that we can expand the two-factor authentication service to any device/software that supports RADIUS.

LDAP can figure into here too. Instead of having a securid_users file on every host (or "xhier region"), we may be able to put the required info into an LDAP database. sudo looks like it has the ability to have sudoers info stored in an LDAP database.

Other things that need to be explored

  • migration to a new vendor
  • Expansion of service to Windows and OS X
  • can PAM modules be stacked in such away to allow su (or sudo) to provide suw functionalty (via the pam_pwdfile module) and ssuw functionality via RADIUS
  • Integration with LDAP and/or Active Directory

Links to relevant software and technology


Pieces of the puzzle

-- JasonTestart - 13 Jun 2005

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2006-03-21 - JasonTestart
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback