[37] in Kerberos-V5-bugs
Revenge of Alice in Wonderland
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Fri Oct 19 17:02:59 1990
Date: Fri, 19 Oct 90 16:46:18 EDT
From: Bill Sommerfeld <sommerfeld@apollo.com>
To: krb5-testers@ATHENA.MIT.EDU, krb-protocol@ATHENA.MIT.EDU
"It helps a little if you review Alice in Wonderland immediately before
examining the export regulations."
- Jerry Saltzer, in late '88 or early '89
I and a few others at apollo are currently looking at what changes are
necessary to kerberos version 5 in order to make it exportable in
binary form. No protocol changes are needed in order to accomplish
what we need, but what we ship may well only include a subset of the
whole Kerberos protocol; changing a few messages to be in plaintext
and sealed with a crypto checksum rather than to be encrypted would
make things much easier to deal with.
One of the restrictions we're dealing with is that there must not be a
way for the user to send arbitrary encrypted messages.
At first, this looks like it shouldn't be too much of a problem (just
hide the encryption system and lose KRB_PRIV support) but once you
start thinking about the problem, it begins to look a whole lot like
covert channel analysis [the fact that government regulations are the
reason for the opportunity is one obvious similarity, but there are
deeper connections..].
The following "features" of the protocol expose some degree of
difficulty here, in decreasing order of difficulty.
- authorization data in general (because it's an arbitrary byte
string embedded in the ticket).
[The fact that authorization data is no longer protected when going
from client to KDC may not be relevant; the client and KDC may be on a
secure LAN in Bulgaria while the server is in Albania at the far end
of a tin-cans-and-string link which has been compromised by the NSA.]
Given that the plaintext authorization data is now exposed in the
ticket request, this means that it should be OK to not encrypt the
authorization data in the ticket, but instead include a cryptographic
checksum of it.
- authenticator checksums
This is a variable-length tagged byte string which appears in the
authenticator. I think the best solution here may be to push the
actual computation of the checksum, at least on the "send" side, under
the API. An alternative is to change the protocol so that
authenticators *aren't* encrypted, but merely protected by a
cryptographic checksum.
- host addresses.
These are again variable-length data.
I think this can be dealt with by hiding the ability to request
arbitrary addresses under the API.
----
There are a couple of lower-bandwidth, more extreme "covert channels"
floating around, which are probably impossible to protect against.
For instance, one realm could encode a message in the names of
principals registered in that realm, and then transmit the message via
interrealm ticket requests to another realm.
If you have a replicated KDC database, you can encode the message in
the keys of a number of principals (using an alphabet of some small
number of passwords), let the secure database replication scheme take
over, then extract the message on the other end by a number of
AS_REQ/AS_REP messages.
Information can be encoded in the authenticator and ticket timestamps
(this is pretty low-bandwidth, though).
Comments?
- Bill
