-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
On Wed, 6 Oct 2004, jmt wrote:
>
>
> -----Original Message-----
> From: Jesse I Pollard - CONTRACTOR
> To: MUSCLE <[EMAIL PROTECTED]>
> Date: Wed, 6 Oct 2004 11:02:54 -0400 (EDT)
> Subject: Re: [Muscle] Avoid asking for a username in smart card login
>
> > In many circumstances, it won't work.
> >
>
> Well... I don't claim this should be the standard solution; only that in
> the application I'm currently working on this would be *very* convenient.
>
> This is a "marketing issue" too. If the user must introduce a username and
> a password for the token (pin), it doesn't *feel* diffent.
>
> > 1. User has multiple accounts and will need some way to select which
> > one to use.
>
> If an user has multiple accounts there's a chance he has multiple smart
> cards too. Anyway, this won't be a problem in my environment.
Not a chance - unless the previous CAC card is expired.
> > 2. The certificate (at least in the DoD CAC case) has no username
> > other than the DN name, which doesn't match anybodys idea of a
> > login name.
> >
>
> Yes... this is the most delicate problem. I assume that you are aware
> about how Mario Strasser's module checks the name. In your opinion, what
> would be the best way to get the user name from the card?
You can't.
User names vary - on one system it might be based on the last name.
On another, the last name + first initial. And then what about
the case of multiple John Smith, or June Smith, Joe Smith, and Josephine
Smith?
Or it might be totally unrelated. I've seen user names like U77745
just because that was the policy at that site.
Even on the same system you may have multiple logins (I have two - used
for totally different purposes).
The only unique thing I've been told is an identification number
at the end of the CN string. It starts with a period, and is 10 digits
long. Maybe using that for a lookup of a list of valid login names would
be reasonable. Of course, the list of valid logins is NOT on the card.
And to get the identification number, you must have the user supply the
PIN.
> I think that if it was configurable everybody could be able to find the
> scheme that suits more to his application.
I think you'll find that there are too many alternatives to
be able to implement something generic.
Now for a SIMPLE case where something could be done:
First the Assumptions:
1. only one login name for a user
2. a network information server is available (LDAP, NIS, ...)
3. Unix or Unix like environment...
THEN:
I'd suggest trying to extract the id number from the CN field.. or
just use the entire CN field to lookup the login via the network
information structure.
Then use the login id associated with the CN/id number.
Uhhhmmm... one possibility is to put the users CN field in the
UNIX gcos/comment field of the logins password entry. Then you
wouldn't have to explicitly implement the network lookup function.
Though you do have to verify that a user cannot change the gcos/comment
field (some systems do allow it to be altered).
If you needed to extend it to multiple logins, then you have to
present a menu (at a minimum) to allow the user to select from.
note - this does nothing to validate users to remote
computation/batch/file servers.
I'm not sure PAM would be the way to do this though - I believe PAM
requires the login name first. so you would need to replace a
good bit of xdm data input to succede. Can be done - I'm relatively
familiar with xdm. The prompting can be completely replaced (did that
for a Kerberos xdm - needed to include the /etc/issue file, and
local kerberos options). So it CAN be done.
The best might be to look like a screen saver until a card was plugged in,
then ask for the PIN.
Replacing the verify.c function of xdm (along with some of the
caller) would allow you full access to the display, for any type
of prompts you need (including a menu of possible logins).
Hmmm. That might be an interesting project.
The actual screen savers can be farmed out like that used in the
xscreensaver application - start the application and pass the background
window id number as the parameter, the screen savers could run under a
screensaver non-root uid, as long as the the access to the display were
provided, then denied once the card is plugged in - maybe a restart of
the X server would do the trick, that would generate a new access key.
The implemented sequence for xdm would be:
1. start the base xdm daemon which forks a child daemon and waits
2. the child xdm generates authorization key, and starts the x server.
3. the child then looks to see if a card is plugged in - if it is plugged
in then:
a. prompts for PIN
b. unlocks card, queries for CN/id number matches
c. if multiple logins, present selection menu
d. Uses the single login, or the one selected by the user and
starts the user process (eventually, an exec system call).
4. If no card plugged in, then:
a. start screen saver process (a fork/exec?)
b. wait for a card to be plugged in.
c. when a card is plugged in, terminate the screen saver and X
server, then exit. This forces the base xdm daemon to start a
new child which would take over at step 2, then on step 3
starts the user activity. And prevents extranious connections
to the X server and any leftover data...
Non-recoverable errors during step three should all present some status
message window, terminate the X server, then exit. This prevents any
data contamination from the error to get into an actual login.
Step 4 is for fun, without a screensave though, you depend on the X
blanking to be used. Withoug step 4, step 3a would be to wait for a
card, then prompt. Step 4 allows a screensaver or help function to exist
that could display system scheduling messages - "all logins denied during
backups", "network is down", "for help call..." type of thing.
Note: all identification and authentication at this point depends
entirely on the secrecy of the PIN, and posession of the card.
> Thanks,
>
> Josep
>
> P.S.: I'm writing from an horrible MUA (webmail), sorry if it doesn't
> thread messages correctly.
>
> _______________________________________________
> Muscle mailing list
> [EMAIL PROTECTED]
> http://lists.drizzle.com/mailman/listinfo/muscle
>
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
