Subject: RE: Biometrics for AS request

From: "Artyom Borodkin" <[email-masked]>
Date: Tue, 13 Jan 2004 16:06:01 +0300

Hello,

I would like share with you some other thoughts about that Biometric
extension.

The original Kerberos protocol relies on a `shared secret` to authenticate
the principal. PK_INIT extension gives us an equivalently strong approach by
using of Certification Authorities.

But biometrics can't gives a `shared secret`. And the use of Diffie-Hellman
algorithm leaves the vulnerable to a middleperson attack.

I think that it is the most important issue and it could remain the general
constraint of the remote Biometrics authentication.

Maybe the host authentication could be used in a sense to fix this problem.

I would be pleased to hear your comments. Do I have a right vision? And is
there some way how to avoid these issues?

Thank you,
Artyom Borodkin

> -----Original Message-----
> From: Artyom Borodkin [mailto:[email-masked]]
> Sent: Monday, January 12, 2004 2:39 AM
> To: [email-masked]
> Subject: Biometrics for AS request
> 
> 
> Hello,
> 
> The purpose is to use fingerprint instead of both a user name and a
> password.
> 
> We can't create a unique identity from a fingerprint and it is not
> possible as our mathematicians say, so we can not use a "shared secret".
> 
> The goal is to obtain the TGT in reply to KRB_AS_REQ request using a
> biometrics to confirm the person identity.
> 
> It could be done in two steps. The former is a key exchange the latter
> is a biometric person search and conformation. After the person is
> identified the key is used to encrypt TGT.
> 
> I would like to pay your attention to few aspects:
> 
> 1) The algorithm of key exchange should be customable, as far as all
> cryptographic algorithms should be for export and licensing purpose.
> 
> 2) The biometric identification process could demands more than one
> request-reply exchange.
> 
> As far as PK_INIT already use DH key exchange it could be reasonable to
> combine these extensions.
> 
> Conceptually I see it as follows:
> 
> Initially we negotiate about the encryption key and then we confirm the
> person identity associated with the request by Password, Certificate,
> Biometrics or some other ways.
> 
> Thank you,
> Artyom Borodkin

---

From: Derek Atkins <[email-masked]>
Date: Tue, 13 Jan 2004 10:32:58 -0500

Remote Biometric Authentication doesn't work.  You need a completely
trusted path between the sensor and the verifier.  If I can get
"behind" the sensor then I can replay your biometric data.  Then I've
just gained access as you.

Basically, Biometrics are like passwords and should be treated as
such.  They do not change (indeed, they CANNOT be changed) and they
_are_ replayable (electronically).  This is why I say you need a
trusted path from the sensor to the verifier.

I've got a number of ideas for how to improve this situation, but this
is not the appropriate forum to discuss remote biometrics.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 13 Jan 2004 11:03:40 -0500

> algorithm leaves the vulnerable to a middleperson attack.

How about sending the biometric data encrypted using a public key 
belonging to the KDC?  Unlike PKINIT, it wouldn't need a certificate 
per user, but the KDC's public key would need to be made known in some 
secure fashion.

> Maybe the host authentication could be used in a sense to fix this 

Perhaps, at least if it's combined with some sort of perfect forward 
secrecy technique.  One problem to watch out for is, if the host key is 
later compromised, we don't want to have then revealed to an 
eavesdropper on the net all the information necessary to forever 
impersonate all the users who have logged in on that host.  But even 
with PFS, if the host key has been compromised, any future logins are 
still vulnerable to an attacker spoofing the KDC.  (Yes, in many UNIX 
systems with remote login access, a compromised host key means it's all 
over anyways, at least until the user can get a secure password change 
done.)

>> The purpose is to use fingerprint instead of both a user name and a

I think I'd be a bit more comfortable with a fingerprint *and* a 
password.  I don't have any experience with biometric authentication to 
back that up, but I've read a few web articles about how easy some of 
the biometric systems were to fool.  (Not that I have any data about 
your system specifically, but ideally the solution ought to be 
applicable to a number of systems.)

That wouldn't offer any more convenience than just using a password, 
but it may offer increased security.

Ken