NIST LOAs and Kerberos

[John Devitofranceschi]

I am trying to figure out how the stipulations for the management of tokens and credentials at LOA3 (Chapter 7.3.1.3 in NIST Special Publication 800-63-1 (http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf) map to a Kerberos KDC.

They talk about the encryption key for the shared secret file being "held in a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and decrypted only as immediately required for an authentication operation."

The second stipulation states that "shared secrets are protected as a key within the boundary of a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and is not exported in plaintext from the module."

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?


jd

[Ken Hornstein]

>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

[John Devitofranceschi]

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?

jd

[Nico Williams]

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
--

[John Devitofranceschi]

Sent from my iPhone

So, basically, even with LOA4 compliant user authentication methods and PKinit, the most we can currently hope for are Kerberos tickets that are acceptable for use at Level 2 (7.3.1.2).

Maybe.

jd

[Nico Williams]

Not only that, but also I think it's possible to interpret this spec
in ways that rule out Kerberos completely. For example, you can't
re-use temporary shared secrets, which could be interpreted as
requiring that no tickets be cached, or maybe it should be interpreted
as requiring new sub-session keys every time. And in higher LoAs you
have to protect even temporary shared secrets with a security module,
which means that you'd have to protect ccaches with security modules.
Also, long-term service keys would have to be protected by security
modules.

Nico
--