[157] in Kerberos
Re: Ooops. SMS cannot store keys th
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:35:31 1987
From miller%erlang.DEC@decwrl.DEC.COM Fri Jan 30 06:39:41 1987
Date: 29-Jan-1987 1032
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
miller%erlang.DEC@decwrl.DEC.COM
Subject: Re: Ooops. SMS cannot store keys that get loaded into Kerberos
I agree with Jeff's assessment of the situation, but would address it
more generically.
The Kerberos servers must be secure to protect against the three fundamental
types of threats:
1) Unauthorized disclosure;
2) Unauthorized modifications;
3 Denial of service.
In the first case, the unauthorized disclosure risk to Kerberos is its
master key, which in turn allows disclosure of principal keys and
unauthorized modification. The second case, unauthorized modification,
could be, as the previous memo suggested, accomplished if someone had
access to the Kerberos database (directly or through SMS) and could copy
principal A's key to principal B, or otherwise modify a key. This does
not require knowledge of any secret keys, only write access to the
database. The simplest case of denial of service is pulling the plug
on the Kerberos servers, causing all ticket requests to fail.
Jeff's suggestion is to cryptographically bind an integrity check (xor
the principal name) to the enciphered key. This may help protect against
the specific attack described, but really only shifts the point of attack
to where this integrity check is applied. It further assumes that Kerberos
itself has not been compromised.
Even if an integrity check were sufficient, a simple XOR is not. Kerberos
has to be able to detect if a principal's key has been modified. Consider
the following: My key, value "01234567" is stored XORd with my name, "spm"
(which is usually shorter than an 8-byte key). Then it is encrypted in the
master key, resulting in value X, and stored in the SMS/Kerberos database.
An intruder copies his encrypted key, Y, onto my entry. When I ask for a
ticket, Kerberos then decrypts Y, xors the result with "spm", and ends up
with "34567890". But the problem is that Kerberos cant tell whether
"34567890" is ok or bad, because there was no redundancy. So in order to
check properly for integrity, you need at least implicit redundancy in the
ciphertext "key". One way to do this is to encrypt my private key,
"01234567", concatenated with my name "spm", under the master key into the
saved "key". Then when you decrypt it, you get the real key and my name
"spm", which is redundant with the database name. If someone had substituted
a different encrypted value, when it was decrypted it would not yield "spm".
Furthermore, modifications, including splicing attacks, can be detected if
the encryption/decryption is performed using the PCBC DES mode which
propagates errors indefinitely. As an optimization on this, since names can
be long, compute a CRC on the name, and use that instead.
However, despite all this, the bottom line is that wherever the master
Kerberos key is in use must be strongly protected against all threats.
But you do find a particular threat to be easy and common,
it may be worthwhile to address it, as long as it is understood that only
that one hole has been plugged.
Steve.
