HW-AUTHENT flag question

[Thomas Hardjono]

> -----Original Message-----
> From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
> Nicolas Williams
> Sent: Tuesday, February 09, 2010 10:15 PM
> To: MIT Kerberos Dev List
> Subject: Re: HW-AUTHENT flag question
> 
> On Tue, Feb 09, 2010 at 07:05:32PM -0600, Will Fiveash wrote:
> > Someone sent me this question:
> >
> > ==================================================================
> > Microsoft makes a confusing statement in "[MSKILE]"
> > http://msdn.microsoft.com/en-us/library/cc233891%28PROT.13%29.aspx
> > or
> > http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-
> a657e5900cd3/%5BMS-KILE%5D.pdf :
> >
> >     The HW-AUTHENT flag
> >     ([RFC4120]<http://go.microsoft.com/fwlink/?LinkId=90458> section 2.1):
> >     This flag was originally intended to indicate that hardware-supported
> >     authentication was used during pre-authentication. This flag is no
> >     longer recommended in the Kerberos V5 protocol. KDCs MUST NOT issue a
> >     ticket with this flag set. KDCs SHOULD NOT preserve this flag if it is
> >     set by another KDC.
> >
> > Who said that it "is no longer recommended"? I did not hear anything
> > like this elsewhere and IMHO this the exact opposite of what makes
> > sense.
> > ==================================================================
> >
> > What is the current take on HW-AUTHENT flag?
> 
> RFC4120 says no such thing.  It does not say that this flag MUST NOT be
> used or propagated.
> 
> However, the hardware pre-auth content in RFC4120 was incomplete.  That
> is, no hardware token pre-auth existed as a standard.  There's work
> ongoing to add support for OTPs, and PKINIT itself arguably supports
> hardware tokens (smartcards) when you know that a private key was
> provisioned via some process that ensures that the private key resides
> in a hardware token and cannot be extracted from it without defeating
> physical tamper resistance (and/or side channels) of the token.
> 
> Sadly, RFC4556 says nothing about PKINIT and the HW-AUTHENT ticket flag.
> IMO if the KDB says that a client principal's private key is believed to
> have been provisioned via an acceptable hardware token and process, then
> the AS ought to set the HW-AUTHENT ticket flag in INITIAL tickets
> issued to such client principals, and the TGS ought to copy that flag
> from TGTs to tickets it issues.
> 
> Nico
> --
> _______________________________________________



May be this is a good opportunity for the Kerberos WG & dev communities
to start looking at ways to represent/report Levels of Assurance (LOA)
in Kerberos.

FYI. The NIST draft SP-800-63-1 (Electronic Authentication Guideline)
has an entire section on Kerberos and the LOA levels achieved using
different scenarios of Kerberos (e.g. Kerberos with H/W Token (smartcard)).

http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf

Perhaps there should be some effort towards defining the format
of the LOA labels to be carried within the authz field (?) in a service ticket.

Plus there is still the (difficult) question of how a KDC can actually
tell the different between a Client/User wielding a hardware-smartcard
versus one that uses a software-smartcard.

/thomas/