daemon@ATHENA.MIT.EDU (Hugh C. Lauer)
Thu Dec 21 09:51:10 1989
From: lauer@BTC.KODAK.COM (Hugh C. Lauer)
To: kerberos@ATHENA.MIT.EDU
Cc: lauer@BTC.KODAK.COM
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
From: sytek!salzman@HPLABS.HP.COM (Michael M. Salzman)
To: kerberos@ATHENA.MIT.EDU
Date: Thu, 21 Dec 89 09:20:00 PST
From: salzman (Michael M. Salzman)
Message-Id: <8912211720.AA18059@sytek.hls.hac.com>
To: hplabs!lauer@BTC.KODAK.COM, kerberos@ATHENA.MIT.EDU
Subject: Re: Athentication vulnerabilities
The issues raised by Hugh Lauer and by others, concerning the vulnerabilities
of the authentication protocols and of the key administration regimes, are
indeed valid. Early on in the discussion of Kerberos, this issue
was obliquely addressed by Jerry Salter, who expressed the view that
Kerberos is an authentication not an identification system.
All of these schemes do not positively identify a user, and do not
insure that passwords are not shared. They merely control access
by "users" to controlled services and resources.
Identification of users requires additional steps, prior to the issue
of a ticket (in Kerberos argot). For example, our company long ago,
(and since forgotten), developed a system which required a key, a personal
ID Number, and a calculator like device to compute encrypted responses.
The keys were stored in an encrypted form (using another algorithm) in both
the calculator and the identifying computer. Users would then be presented
with a challenge, a seven digit number based on their key, they would enter
the number into the calculator, after identifying themselves via the Personal
ID Number (to their calculator). The calculator would then issue a response,
which could be decrypted by the computer using the known key. If the answer
matched the expected answer, the user was identified.
This system therefore relies on three elements: A physical device containing
a Key, and a personal ID number. The Key is entered by an administrator into
the calculator, and is not known to the user. The Personal ID Number is
entered by the user, and is not known to the administrator, and should not
be written down anywhere (common mistake). The device must therefore be
posessed by the user who knows the PIN in order to work. If the device or
the PIN are stolen they cannot be used.
Such a system would not solve the problems raised by Lauer and others since
it relies on a central adminstration scheme. However, a similar scheme can be
extended to a hierarchical domain system which would allow remote users to be
identified. Of course, such a scheme also raises questions about the meaning
of access privileges. If I do not know about the remote users, how can I
assign them privileges to use a resource. Do I assign it to them specifically
or to a group to which they belong? How do the groups get defined?
Mike Salzman
Hughes Lan Systems, Inc.
daemon@ATHENA.MIT.EDU (Bede B. McCall)
Thu Dec 21 14:10:24 1989
From: bede@LINUS.MITRE.ORG (Bede B. McCall)
To: lauer@BTC.KODAK.COM
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Hugh C. Lauer's message of Thu, 21 Dec 89 09:45:11 EST
<8912211445.AA10770@hotspur>
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
daemon@ATHENA.MIT.EDU (Steve Miller 26-Dec-1989 1246)
Tue Dec 26 12:53:00 1989
From: miller@ERLANG.ENET.DEC.COM (Steve Miller 26-Dec-1989 1246)
To: "kerberos@athena.mit.edu"@DECWRL.DEC.COM
From: LYRE::"MAILER-DAEMON" "Mail Delivery Subsystem" 24-DEC-1989 17:13:34.27
To: spm
CC:
Subj: Returned mail: Cannot send message for 3 days
----- Transcript of session follows -----
421 decwrl.dec.com.tcp... Deferred: Host is unreachable
----- Unsent message follows -----
Received: by lyre.nac.dec.com (5.57/Ultrix2.4-C)
id AA00681; Thu, 21 Dec 89 16:17:59 EST
Date: Thu, 21 Dec 89 16:17:59 EST
From: spm (Steven Miller)
To: decwrl::kerberos@athena.mit.edu
Subject: Re: Authentication vulnerabilities
Cc: spm
Recent messages from Hugh Lauer and Michael Salzman discussed the
administrative vulnerabilities of various authentication systems.
In any of these systems, be it Kerberos, X.509, or others, there is
a trust in the administrative components (such as the Kerberos realm
administrator). All that the protocols can hope to achieve is to explicity
identify which set of components are involved in a particular authentication
operation. This then gives the principals the opportunity to enforce any
policy they choose with respect to those administrative units. For example,
not granting write access to certain Kerberos realms based on not trusting
the carefulness of that realm's administration.
Kerberos V4 provides a limited form of such information, for a 1-hop
realm traversal, and V5 will provide the entire path of administrative
units (realms) involved in the operation. So an apprehensive principal
can setup their authorization to take the administrative trust into account.
The task of determining trust in an administrative unit is way beyond the
scope of computer communications. There may be applicable precedents in other
organizations such as banking or the military to deal with these
administrative issues.
Steve
p.s. Tools such as smart cards with PINs are better, but still imperfect
since they may be intentionally shared or shared under duress -- e.g.
people have been mugged and forced to obtain money from their cash machines.