[858] in Kerberos
daemon@ATHENA.MIT.EDU (Michael M. Salzman)
Thu Dec 21 13:04:11 1989
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.
