smart card authentication with Linux?

Ben Scott dragonhawk at gmail.com
Wed Nov 16 23:36:02 EST 2005


On 11/14/05, Paul Lussier <p.lussier at comcast.net> wrote:
>> You want an authentication mechanism which does not require
>> central coordination, but allows rejection of compromised keys.
>> How are the auth clients going to determine when a key is
>> compromised, then?
>
> Generate them based on a sequence number similar to S/Key.

  For the record, that doesn't really do anything about compromised
keys.  OTPs protect you against password sniffing.  If the OTP list is
compromised, you're still hosed.

  Now... if you centrally controlled the OTP list, and only issued
OTPs "on demand", that might improve the overall situation.  You're
shifting the authentication problem from field-computer/field-person
to field-person/central-person, and reducing the exposure of the keys.
 Since key compromise becomes less likely, you should reduce how often
you need to update your CKL.  A drawback is that the OTP controller
becomes a point of failure.

>>   Is there a reason the auth clients can't automatically download a
>> signed CKL from the 'net?
>
> Yes, many of the systems we need to access are not allowed to make
> connections to the internet.

  Fair enough.

  It occurs to me that having some way to automatically distribute a
CKL would still increase overall security.  (It's important not to
increase security so much in one aspect that security in other aspects
suffers.)  A mechanism which would allow a tightly controlled data
transfer from <your org> to <bastion host> to <end system> should be
possible.  Perhaps that would be acceptable.

-- Ben "I'm glad I don't have to solve this problem" Scott



More information about the gnhlug-discuss mailing list