Subject: [Ietf-krb-wg] Use of Biometric data for Pre-authentication in Kerberos v5

From: "Raymond Brown" <[email-masked]>
Date: Thu, 03 Sep 2009 16:41:02 +0100

Hi,

I'm an MSc student currently doing a paper on using Biometric (fingerprint) data for pre-authentication in Kerberos v5. The proposal is for the client to be identified to the KDC using verified biometric output as pre-authentication data. I propose an extension to the existing protocol, which will obviously take into consideration recommendations in the current draft ' A Generalized Framework for Kerberos Pre-Authentication', such as FAST. I propose adding the biometric authentication factor to the existing need for a password and would also propose an alternative option of replacing the password with a biometric input.

Can anyone advise me if you are aware of any existing work being done on this subject matter that could possibly assist me or anyone interested who can provide useful guidance.

Your response will be much appreciated.

Ray Brown
MSc Computer Forensics and Security
University of Bedfordshire
email: [email-masked]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 3 Sep 2009 14:55:31 -0400

Hi Raymond,

In my limited experience with fingerprint capabilities on some OEM platforms, the fingerprint match result (often called the "profile") is often used by the OEMs to unlock some BIOS-level credentials (which is the actual credential to then unlock other security-devices on the machine). Not so clean, but when dealing with BIOS nothing is ever clean :)

It would be a great project to see if a fingerprint result could be delivered through a pre-authentication protocol (that conforms to the FAST framework) to the KDC (augmented with fingerprint processing capabilities).  I don't know if you could wedge this feature into PKINIT or OTP. Perhaps a new pre-auth protocol could be devised.

cheers,

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Raymond Brown
> Sent: Thursday, September 03, 2009 11:41 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Ietf-krb-wg] Use of Biometric data for Pre-authentication in
> Kerberos v5
> 
> Hi,
> 
> I'm an MSc student currently doing a paper on using Biometric
> (fingerprint) data for pre-authentication in Kerberos v5. The proposal
> is for the client to be identified to the KDC using verified biometric
> output as pre-authentication data. I propose an extension to the
> existing protocol, which will obviously take into consideration
> recommendations in the current draft ' A Generalized Framework for
> Kerberos Pre-Authentication', such as FAST. I propose adding the
> biometric authentication factor to the existing need for a password and
> would also propose an alternative option of replacing the password with
> a biometric input.
> 
> Can anyone advise me if you are aware of any existing work being done on
> this subject matter that could possibly assist me or anyone interested
> who can provide useful guidance.
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 3 Sep 2009 14:10:25 -0700

As noted, a new pre-auth mech based on FAST would probably be the way  
to go.  (Possibly delivering the profile via TLS would be as good or  
better.)  I don't see PKINIT as relevant, and a fingerprint isn't "one  
time".

A concern I have (which is probably outside the scope of your  
research) is that a fingerprint profile plus a PIN has the  
*appearance* of a 2-factor authentication system.  However a practical  
deployment of such a system may not provide the reality because it  
depends critically on hardware outside the protocol chain.  For  
example a USB fingerprint reader's (or PIN reader's) interface might  
be easily sniffed and the relevant data replayed.  Since your  
fingerprint doesn't change this could be worse than having a password  
stolen.  My concern is that your resulting system not be advertised in  
terms that suggest security that isn't actually provided.

On Sep 3, 2009, at 8:41 AM, Raymond Brown wrote:

> (fingerprint) data for pre-authentication in Kerberos v5. The  
> proposal is for the client to be identified to the KDC using  
> verified biometric output as pre-authentication data. I propose an  
> extension to the existing protocol, which will obviously take into  
> consideration recommendations in the current draft ' A Generalized  
> Framework for Kerberos Pre-Authentication', such as FAST. I propose  
> adding the biometric authentication factor to the existing need for  
> a password and would also propose an alternative option of replacing  
> the password with a biometric input.
>
> Can anyone advise me if you are aware of any existing work being  
> done on this subject matter that could possibly assist me or anyone  
> interested who can provide useful guidance.
>

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Russ Allbery <[email-masked]>
Date: Thu, 03 Sep 2009 20:14:00 -0700

"Henry B. Hotz" <[email-masked]> writes:

> A concern I have (which is probably outside the scope of your research)
> is that a fingerprint profile plus a PIN has the *appearance* of a
> 2-factor authentication system.  However a practical deployment of such
> a system may not provide the reality because it depends critically on
> hardware outside the protocol chain.  For example a USB fingerprint
> reader's (or PIN reader's) interface might be easily sniffed and the
> relevant data replayed.  Since your fingerprint doesn't change this
> could be worse than having a password stolen.  My concern is that your
> resulting system not be advertised in terms that suggest security that
> isn't actually provided.

Yes, I would second this.  Biometric factors are the most useful when they
can be obtained in an environment that makes it difficult to replay
someone else's biometric data (either electronically or physically).
There's a huge difference in effective security between sending a set of
fingerprint metrics via a network protocol to a server and pressing one's
finger to a reader pad in the physical presence of a security guard.

You may be able to reproduce some of the security of the latter with
sufficient ingenuity in the hardware of the fingerprint reader, although
it would be hard to get all of it.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 4 Sep 2009 09:29:36 -0400

> interested who can provide useful guidance.

The idea has come up before, though I don't know how much actual work  
has been done in the area.

It appears at least one proposal has been published, though I haven't  
found an online copy available without payment and have no idea how  
good it is, though the abstract says it's designed to prevent spoofing  
and biometric data leakage: http://sciencelinks.jp/j-east/article/200610/000020061006A0308020.php 
  .

Some previous discussion on this list:
https://lists.anl.gov/pipermail/ietf-krb-wg/2004-January/thread.html  
(listed under several threads)
https://lists.anl.gov/pipermail/ietf-krb-wg/2008-August/007060.html  
(and two followups)

You might also want to look up "Fuzzy Extractors: How to Generate  
Strong Keys from Biometrics and Other Noisy Data" by Dodis et al.  If  
it's the paper I remember skimming some time ago, it may not be ideal  
for Kerberos in its current form, but it's an interesting bit of work.

Good luck with your paper.

Ken

---

From: Kadirvel Chockalingam Vanniarajan <[email-masked]>
Date: Fri, 4 Sep 2009 23:57:36 +0800

Is this threat listed below unique to Biometric+PIN scenario? I understand that it is a credential which cannot necessarily be revoked. But is that the factor that makes it tricky? Even in a SC case also, won't a similar threat exist (with the client storing the certificate from SC for later replay)? If it doesn't, how is it handled securely?

---

From: Shivaram Mysore <[email-masked]>
Date: Fri, 4 Sep 2009 09:56:13 -0700 (PDT)

The way biometrics are used (for example PIV or FIPS201 card) is finger print is matched on the Smart Card on the end user system.  This requires use of FIPS certified Card reader and in secure installations Common Criteria or secure systems.  Without these qualifying conditions, the threat models cannot be controlled and the system becomes too complicated to build or maintain.

Due to privacy reasons, the finger print is also provisioned on the card and not stored on the server.  The use of fingerprint unlocks the smart card wherein the private key can now be used for say, signing a authentication challenge.

/Shivaram

--
Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants:
http://www.TrustStix.com/ 

________________________________
From: Kadirvel Chockalingam Vanniarajan <[email-masked]>
To: Russ Allbery <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Friday, September 4, 2009 8:57:36 AM
Subject: Re: [Ietf-krb-wg] Use of Biometric data for Pre-authentication in Kerberos v5

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 4 Sep 2009 11:29:15 -0700

On Sep 4, 2009, at 8:57 AM, Kadirvel Chockalingam Vanniarajan wrote:

> Is this threat listed below unique to Biometric+PIN scenario? I  
> understand that it is a credential which cannot necessarily be  
> revoked. But is that the factor that makes it tricky? Even in a SC  
> case also, won't a similar threat exist (with the client storing the  
> certificate from SC for later replay)? If it doesn't, how is it  
> handled securely?

For a typical SC implementation the *public* cert on the card is of  
limited relevance to security.  What's important is that the  
corresponding private key is generated on the card and cannot be read  
off.

The crypto processor on the card is an active participant in the  
PKINIT exchange.  Computations using that private key are performed on  
the card and not on the host computer.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 04 Sep 2009 11:47:33 -0700

>> revoked. But is that the factor that makes it tricky? Even in a SC case
>> also, won't a similar threat exist (with the client storing the
>> certificate from SC for later replay)? If it doesn't, how is it handled
>> securely?

> The crypto processor on the card is an active participant in the PKINIT
> exchange.  Computations using that private key are performed on the card
> and not on the host computer.

So you could reasonably use the same mechanism for adding a fingerprint or
other biometrics to the security process by requiring the fingerprint to
unlock the key in the smart card so that it will do the authentication
computation.  (That's the sort of thing I was thinking about.)  However,
in that case from the perspective of Kerberos you're just doing PKINIT,
and the fingerprint is replacing or supplementing the PIN rather than the
X.509 signature.

As soon as the fingerprint data itself is what you're transmitting over
the network, you have to have a way of preventing replay of the
fingerprint data by an attacker, which gets much harder.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 4 Sep 2009 15:41:58 -0700

On Sep 4, 2009, at 11:47 AM, Russ Allbery wrote:

>>> case
>>> handled
>> PKINIT

I guess that use scenario explains why people were bringing up PKINIT  
in the first place.

Of course if that's how the fingerprint is being used, then there's no  
need to modify any Kerberos protocols at all.  All the work is in the  
card/fingerprint readers and device drivers.