lauer@BTC.KODAK.COM (Hugh C. Lauer) (12/21/89)
Denis Russell's recent message raised some other concerns in my mind about vulnerabilities of authentication, especially in wide area networks of many realms. It seems that weaknesses in administrations are much more serious problems than weaknesses in either the Kerberos or X.509 protocols. Denis's project is addressing a large area -- all of academic computing in the UK. Mine is one or two orders of magnitude smaller -- the computing networks of a multi-national corporation -- and that appears to be already intractable. We have a lot of departments with a lot of users. The largest concentration is in Rochester, New York, but about half the users are located elsewhere. For reasons not worth elaborating here, it is not possible in our company to have an effective central administration, even of authentication servers. Individual departments will install and use them or not, as they choose and as their individual business needs dictate. Yet I and many of my colleagues need to move physically around the corporation, and wherever we go we need to be able to login into a local system with our own passwords and be recognized as who we really are. This is why we are interested in Kerberos in the first place -- because it is a working system for authentication, presumably over a wide area. We also need to be able to put together projects comprising people from a number of departments and give them common sets of rights and access privileges, so that they can work together, share files, etc. They need to be able to sign on to a system anywhere in their project (which may span the continent) and still have substantially the same rights they have in their local environments. My concern is that I am not sure that I can trust the administrations of all of the other realms. Maliciousness is NOT the issue; carelessness is. I.e., I am not completely confident that the administrator or users in the various realms really understand the responsibilities and consequences of protecting passwords, keys, etc. Are there any public passwords in a particular department? Does another department find it necessary to routinely share the Master database password, the same way that we here find it necessary to routinely share root passwords? If I add a user from a particular department to the access list for a project, do I inadvertantly open it up to everyone in that department? to people outside the department but still inside the company? to people outside the company? It seems that this problem grows rapidly with the number of realms and is independent of whether you use centralized databases, such as Kerberos, or certificates in a public key cryptosystem. It is already bad enough in 'monolithic' company with 40-50 separate departments. It has to be much worse for the 40-50 universities in the UK, each with several dozen highly autonomous departments or colleges. Given this, I think that the practical vulnerabilities of X.509 AND Kerberos are much more severe than the protocol vulnerabilities described by Burrows, Abadi, and Needham (the latter, I expect, will eventually get fixed). Am I missing something? /Hugh C. Lauer Kodak Boston Technology Center Bedford, Massachusetts
bede@LINUS.MITRE.ORG (Bede B. McCall) (12/22/89)
We have a similar, although "smaller" (in terms of raw numbers, at
least) problem. In our case, the problem is compounded by very loose
coupling -- both administratively and with respect to network
connectivity -- between two major sites and a gaggle of smaller sites
spread globally (from Germany to Japan). I've targeted only the major
sites for kerberos. Presumably, if and when a "global" sort of
authentication scheme becomes available on a reasonable basis (perhaps
X.509), we would use that for inter-site authentication. So we might
eventually end up with a ubiquitous two-level sort of authentication
scheme which might at least be easier to use than the one we have now.
I have few illusions about a globally acceptable scheme showing up
which would allow us to simplify this situation in the foreseeable
future (e.g. 5 or 6 years).
Our existing answer to inter-site authentication is the use of SecurID
(but this is **NOT** a product endorsement!) "smart" cards which,
although they fulfill our requirements, nonetheless require an
infrastructure similar to that of kerberos -- dedicated, secure
servers, centralized administration, and so on. Since the number of
people who need the cards is quite small (maybe numbering in
the very low hundreds), the cost is not an intolerable burden -- but
certainly not cheap.
What the security cards don't give us is protection against our own
users within the major sites (an obstreperous lot, they), hence the
perceived need for kerberos. Considering that the basic system is
available now, at zero startup/licensing cost (potential future
development costs notwithstanding for now), is at least provably
secure in its abstract form (the papers from the DEC group), and that
we have an existing framework (due to the dedicated security card
authentication servers) for installing it, the choice of kerberos was
rather obvious. Secure inter-realm authentication for these major
sites is something we can cope with, as have Athena and LCS.
This isn't to say that our solution for authentication is a terrific
model, although I'll bet it's a typical one. At times, in fact, one
is tempted to view it as a kludge which works only by virtue of an
extraordinarily patient user community. Despite predictions to the
contrary, I still haven't gotten used to using my card, and it, just
like my password on many systems, expires every so often, making the
situation even worse.
It would be very nice if I could cob together a one-shot, bulletproof
"login certificate" for each user as they first pass through our
personnel office and then forget about them until they pass out the
same door, perhaps many years later. I think most organizations might
even be willing to pay a smallish (does $10 sound about right?)
one-time fee for this, assuming the recurring costs were nil and the
certificate was universally accepted. (One of the things you have to
remember about recurring license fees is the fact that they always
have some "hidden" internal overhead added to them: add these costs up
and you can run up a really whacking great bill for something like the
superficially inexpensive RSA licensing, which is handled on a
per-user basis.)
-Bede McCall
MITRE Corp. Internet: bede@mitre.org
MS A114 UUCP: {decvax,philabs}!linus!bede
Burlington Rd.
Bedford, MA 01730 (617) 271-2839