NIST LOAs and Kerberos

[Nico Williams]

On Fri, Mar 30, 2012 at 8:05 AM, John Devitofranceschi
<jdvf at optonline.net> wrote:
> On Mar 30, 2012, at 8:23, Ken Hornstein <kenh at cmf.nrl.navy.mil> wrote:
>
>>> Does this mean that in order to consider one's KDC infra LOA3 compliant
>>> one needs to hold the principal database in a compliant hardware
>>> security module? Or am I missing something here?
>>
>> You're in trouble even if you did that anyway.  Look at section 9.3.2.2.
>> By my reading of that, with the traditional use of Kerberos you can't
>> go above Level 1.
>>
>> --Ken
>
> Yes I read that. :(
>
> But if we use a smart card  (LOA4 compliant) to log in and obtain Kerberos credentials, is it at all possible for one to claim that the requirements specified in 9.3.2.4 are satisfied and then use Kerberos tickets as assertions at Level 4?

That's my reading, yes.

Earlier you asked:

> Does this mean that in order to consider one's KDC infra LOA3 compliant
> one needs to hold the principal database in a compliant hardware security
> module? Or am I missing something here?

The 7.3.1.3 requirement doesn't require that the whole KDB be in a
FIPS 140-2 security module.  It requires that the individual shared
keys not be extractable from the security module.

This means that you can't just have the master KDB key in a security
module either.  You have to re-write a lot of the KDC so that a number
of its functions are run in the security module.  That's not enough
either.  You have to ensure that that you can't tamper with the KDB
such as by renaming records while not having access to the master key
(the keys are encrypted, sure, but there's no integrity protection on
the binding of keys to names).

I believe there are other ways to address this requirement, but I see
no way in which any of us can address this without substantial effort.

Nico
--