[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Token card support in PAM.



  I've just implemented PAM support for CRYPTOCard tokens, using a
library we've been developing.  Some comments and questions follow..

  The PAM code isn't ready for prime-time yet, but it does work, and
is even fairly straightforward.

  I'd like to see generic "token card" support in PAM, with plug-ins
for various manufacturers.  This isn't intended to make their life
easier, but to up the ante by having an existing standard that we
support and they don't. ;-)

  Is it desirable to have something like "pam_tokencard" read a
configuration file, and call "pam_cryptocard" or "pam_othercard" as
desired?  This would allow administrators to configure one login
method for everybody, and still have multiple token card types.

  How does this interact with Sun?

  The API we're using for our library should be general enough to
support other token cards, or challenge/response sequences.  The
interface looks like:

int crypto_init(char *directory)
	Initialize, with data files in the specified directory
	return an "instance" number to be used later.

int crypto_challenge(char *user, char *challenge, int mode, int instance, int *session)
	Request the next challenge for a particular user and instance.
	return a "session" number, to match a response with later.

int crypto_response(char *response, int instance, int session)
	Validate the users response for a given session

void crypto_exit(int instance)
	exit and clean up.


  The background is that we want to have multiple programs/daemons
using token card authentication, each with multiple outstanding
authentication sessions. (logins, RADIUS servers, TACACS+ servers,
administrators bashing the database, etc.)

  The library uses shared memory which contains state information, to
keep track of simultaneous requests for one user, etc.  It uses
advisory locks on a shared file to serialize authentication access.

  This may not be the best of methods, but saved state is necessary to
prevent many attacks.  Locking allows an administrator to update a
live database, which is useful for commercial applications.  I could
change this to use semaphores, but I stole code for advisory
locks, and stuck it in with minimal work.

  What we will probably end up doing is giving away the PAM code and
our shared library, and have the administrative tools and tokens
available for $$.  We'd like to have the PAM code come standard with
PAM, as it gets us a wider distribution.  If people can figure out how
to use/abuse the token card support without having access to tokens,
that's fine by us.

  Do people have comments which will help us make the token card
support friendlier?  Any ideas or suggestions on the interface and
implementation?

  Alan DeKok.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []