|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T U
Length: 772207 (0xbc86f)
Types: TextFile
Notes: Uncompressed file
└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
└─⟦07e3da56a⟧ »./papers/Kerberos/kerberos.mail.Z«
└─⟦this⟧
[0001] root@TELECOM.MIT.EDU Kerberos 08/07/87 18:09 (1 line)
Subject: Reason for this meeting
This is a transcript of the "kerberos" mailing list.
--[0001]--
\f
[0002] daemon@TELECOM.MIT.EDU Kerberos 08/07/87 18:58 (4 lines)
Subject: test
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos-mtg@achilles.LOCAL
does this work ...
--[0002]--
\f
[0003] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (220 lines)
Subject: Kerberos Support for Remote Services
From mtc@ATHENA.MIT.EDU Tue Jun 3 17:14:23 1986
To: geer, bcn, spm
Cc: charlie, saltzer, noah, jis
Subject: Kerberos Support for Remote Services, Project Description (long)
Date: Tue, 03 Jun 86 17:12:41 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
Introduction
I have been asked to put Kerberos support into the remote services
rlogin, rsh, and rcp. The task has evolved as I have proceeded;
therefore, the purpose of this project is to document what I'm
doing with this project, to identify and resolve conflicts with what
other people think should be done, and to give a status report on
the project.
Comments on this report are encouraged.
A feature of my approach is that it requires a new port number for
the Kerberos-authenticated services. These port numbers should
be assigned by SRI-NIC so that they can become "well-known"; if
we do not do this, it may break rlogin to foreign hosts (ie, if
the host thinks the port means something other than Kerberos).
The Problem
In the Athena environment we lose control over the administration of
individual workstations. This fact allows a workstation user to
capitalize on a hole in the rlogin (etc) "host trusting" mechanism,
possibly to destructive ends, assuming that the user has the root
password for the workstation, which is likely.
For example, I (mtc) have the machines I use regularly set up to
trust each other. "menelaus" is a VAX750 and "goanna" is my uVax II
workstation. If goanna goes down, it creates an opportunity for an
evil hacker to use any workstation to masquerade as mtc logged in on
goanna: all he has to do is name the workstation "goanna" and create
an account for "mtc", then rlogin to menelaus. Menelaus cannot tell
that the hacker is not me, and because of the way I have trusting set
up, allows the hacker full access to my menelaus resources. The only
alternative to this security hole that exists now is removal of
"trusting" from my ~/.rhosts file; this causes the nuisance of having
to type my password each time I begin an rlogin session.
The Solution
Kerberos can be used to prevent this kind of illicit access. To
start an authenticated rlogin session, a user creates a set of encrypted
tickets (via vxlogin) that absolutely identify him to a remote host.
With this kind of security, it is possible to trust a session, since
Kerberos can detect tampering, re-use, etc, of the tickets.
Goals of the Project
The services to be modified to use Kerberos authentication are rlogin,
rsh, and rcp. The changes must be made in such a way as to not break
the existing function for use without Kerberos. For example, for the
rlogin service:
1) An external user (eg, on a client without Kerberos) must still
be able to rlogin to a Kerberos host, provided that that host
is set up to allow the access.
2) A user of a Kerberos host must be able to rlogin to a host
that does not support Kerberos.
A change to the format of the ~/.rhosts and /etc/hosts.equiv files
have been proposed to allow some new flexibility in tailoring the
Kerberos environment; these changes are described later.
Since these services make use of a few common routines for setting up
the connection, changes should be made to those routines which can be
used by all targeted services. The changes will be the minimum required
to support authentication, to avoid breaking any other existing functions.
Changes to Permission Control Files
Steve Miller suggested some changes to the format of the files ~/.rhosts
and /etc/hosts.equiv for better tailoring to the Kerberos environment.
These files allow users to rlogin without typing their password for
each session. Currently, the files can contain two types of specification:
host trust all users from the specified host
host username trust username from the specified host
The proposed extensions use a special cookie, "*krb*", to indicate that
the control applies to Kerberos logins:
*krb* allow Kerberos-authenticated logins from any
user on any host.
host *krb* allow Kerberos-authenticated logins from any
user on the specified host.
host user *krb* allow Kerberos-authenticated logins from the
specified user on the specified host.
At the moment, an authenticated rlogin now works without these extensions;
it is governed by the same restrictions as a non-kerberos login. The main
difference between the authenticated and non-authenticated login is that
we have closed the hole of doubt as to the clients true identity. However,
a remote user can still gain access without authentication by using the
standard version of rlogin.
What the proposed extensions provide is flexibility in restricting access.
For example, a workstation in building E40 might be willing to trust any
workstation or host in E40 with or without Kerberos authentication, but
require others to authenticate their sessions. The /etc/hosts.equiv file
spec is:
*krb*
menelaus
goanna
(other hosts and workstations)
Changes to rlogin protocol
Continue to support the normal rlogin protocol:
lusername<0>
rusername<0>
terminal_info<0>
Add alternate protocol for Kerberos support:
KTEXT object # count in text form, a space, and count chars
# of the Kerberos text string.
rusername<0>
terminal_info<0>
Note that the Kerberos protocol does not explicitly supply the
lusername; this is taken from the authenticated data enclosed in the
KTEXT structure.
Changes to rcmd.c
Added a new argument, a pointer to a KTEXT object, which controls
the type of protocol used by remote services. If the pointer is NULL,
use the normal protocol; if it points to a KTEXT object, use the
Kerberos protocol via SendKerberosTicket().
New routine SendKerberosTicket() sends a KTEXT structure across the
connection from the client to the server.
New routine GetKerberosData() snarfs the KTEXT sent by SendKerberosTicket()
and uses rd_ap_req to extract the AUTH_DAT from the KTEXT object.
The remote username (ie client's local username) is translated by
antoln and returned.
ruserok() (and its subordinate routines) will be changed to extend
the function of /etc/hosts.equiv and ~/.rhosts, as described earlier.
Changes to rlogin.c
Find the port number for a Kerberos login session (from /etc/services).
If not found, punt the Kerberos login session and try normal rlogin.
Otherwise, create a KTEXT object and fill it in (via mk_ap_req).
Attempt connection to the remote host using the Kerberos port, by
means of rcmd() with a pointer to the KTEXT object. If the connection
fails, punt the Kerberos login session, release the KTEXT object, and
try the normal login.
If the Kerberos login failed, find the port number for a normal
login session. Attempt the connection via rcmd(), using NULL for
the KTEXT object.
Changes to rlogind.c
Look at the command name. If its "rlogind", spawn "login -r fromhost"
as before. If its "klogind", spawn "login -k fromhost" to get
login to expect the Kerberos protocol.
Changes to login.c
Check for the presence of "-k". Allow only one of: "-r -h or -k"
(instead of the first two only). If "-r" is found, call doremotelogin()
as before. If "-k" is found, call doKerberosLogin() instead, to use
the modified rlogin protocol.
Add new routine doKerberosLogin(). It snarfs a KTEXT object off of
the connection stream via GetKerberosData() (see rcmd.c). Then gets
the lusername (ie, rusername sent by rlogin) and terminal characteristics.
ruserok() is called as before (for the time being, until the Kerberos
extensions to /etc/hosts.equiv are implemented), but using the lusername
enclosed in the KTEXT, which is known to be authentic.
Changes to rsh.c
Will be changed analogous to the changes to rlogin.c.
Changes to rshd.c
Will be changed analogous to the changes to rlogind.c and login.c.
Changes to rcp.c
Will be changed analogous to the changes to rlogin.c.
Current Status
rlogin now works with Kerberos authentication, and does not break
existing function. It is complete except for the changes to ruserok.
Work remaining: modify rsh, rshd and rcp to use the new version
of rcmd() etc.
--[0003]--
\f
[0004] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (68 lines)
Subject: Re: Kerberos Support for Remote Serv
From Saltzer@ATHENA.MIT.EDU Mon Jun 9 00:52:57 1986
Date: Mon, 9 Jun 86 00:47:25 EDT
Subject: re: Kerberos Support for Remote Services, Project Description (long)
To: Mark Colan <mtc@ATHENA.MIT.EDU>
Cc: geer@ATHENA.MIT.EDU, bcn@ATHENA.MIT.EDU, spm@ATHENA.MIT.EDU,
charlie@ATHENA.MIT.EDU, noah@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
In-Reply-To: Mark Colan <mtc@ATHENA.MIT.EDU>'s message of Tue, 03 Jun 86 17:12:41 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Mark,
That plan looks fairly good. Here are some minor questions. (Your
writeup assumes rather substantial recall of a lot of Kerberos
details; since I didn't memorize them, some of the answers to these
questions may seem obvious to you.)
1.
> To start
> an authenticated rlogin session, a user creates a set of encrypted
> tickets (via vxlogin) that absolutely identify him to a remote host.
What is "vxlogin"?
2.
>Changes to rlogin.c
>
> Find the port number for a Kerberos login session (from /etc/services)
> If not found, punt the Kerberos login session and try normal rlogin.
> Otherwise, create a KTEXT object and fill it in (via mk_ap_req).
The management of Kerberos service keys isn't clear here. Does every
server that might allow Kerberos-mediated rlogin have a different
key? Or is there a standard Kerberos-mediated rlogin key that every
server must know? Assuming the former, just what does the
prospective client ask for by way of a ticket? How does the proper
UNIX user id get into the ticket? Do you assume that the Kerberos
name of the user is identical to the UNIX user id to be used at the
rlogin server?
3. Are the same service keys used for rsh, rcp, and rlogin?
4.
> Add new routine doKerberosLogin(). It snarfs a KTEXT object off of
> the connection stream via GetKerberosData() (see rcmd.c). Then gets
> the lusername (ie, rusername sent by rlogin) and terminal
> characteristics.
Where does the rlogin service store the private key it uses for
deciphering Kerberos tickets?
5.
> A feature of my approach is that it requires a new port number for
> the Kerberos-authenticated services.
This feature strikes me as being more of a bug. Have you established
for certain that you can't just extend the present protocol in a way
that produces a well-defined error response if you try to use the
Kerberos extensions in talking to a server that doesn't know about
Kerberos? I would expect that you could define a couple of new
operation types within the protocol that request a Kerberos login and
that supply the Kerberos ticket.
Jerry
--[0004]--
\f
[0005] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (36 lines)
Subject: Re: Kerberos support for remote Serv
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Mon Jun 9 08:10:02 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: re: Kerberos Support for Remote Services, Project Description (long)
To: Saltzer@ATHENA.MIT.EDU
Cc: mtc@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU, spm@ATHENA.MIT.EDU,
charlie@ATHENA.MIT.EDU, noah@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
In-Reply-To: <8606090447.AA16708@HERACLES>
I will respond to the non-aplication specific questions. Vxlogin is
the program used to get one's initial tickets. It is the piece of
kerberos that will be merged into the login program.
Each server that allows kerberos mediated rlogin has a separate key
(conceptually). In practice, you could use the same keys, but the
tradeoff is that compromising the security of one system would then
give you the key for the other if only one key is used.
The server gets it's key from the file /etc/srvtab (which is protected
using Unix's file protection mechanism.
A ticket for a client is only good to rlogin to a single host. If a
client needs to rlogin to a different host he has to get a new ticket.
This is (or will be) transparent to both the user and the application
since the kerberos library routine to create an authenticator will get
the new ticket from kerberos using its ticket granting ticket.
The unix user ID of a user does not appear in the ticket. Instead,
the routine antoln (authentication name to local name) is called by
the server to convert the name obtained from the ticket into a local
username. At the moment, the routine just returns the initial part of
the authentication name, but the routine is used so that an arbitrary
mapping can take place once it is finally implemented.
~ Cliff
-------
--[0005]--
\f
[0006] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (108 lines)
Subject: Re: Kerberos Support for Remote Serv
From mtc@ATHENA.MIT.EDU Mon Jun 9 16:25:49 1986
To: saltzer
Cc: geer@athena.mit.edu, bcn@athena.mit.edu, spm@athena.mit.edu,
charlie@athena.mit.edu, noah@athena.mit.edu, jis@athena.mit.edu
Subject: re: Kerberos Support for Remote Services, Project Description (long)
Date: Mon, 09 Jun 86 16:24:04 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
Jerry,
Thanks for your comments and questions. Here are some answers:
> What is "vxlogin"?
As bcn stated, it is (at present) a utility which creates the tickets.
The user types his Kerberos name and password, and tickets are created
if they match. Eventually vxlogin is planned to be merged into login(?).
> The management of Kerberos service keys isn't clear here. Does every
> server that might allow Kerberos-mediated rlogin have a different
> key? Or is there a standard Kerberos-mediated rlogin key that every
> server must know? Assuming the former, just what does the
> prospective client ask for by way of a ticket? How does the proper
> UNIX user id get into the ticket? Do you assume that the Kerberos
> name of the user is identical to the UNIX user id to be used at the
> rlogin server?
I its the former: every server has a different key. Upon calling vxlogin,
the client gets ALL tickets s/he is entitled to. I do not need to assume
that the Kerberos name is the same as the Un*x id on server, because of
the following:
a. A kerberos name is placed in the ticket by vxlogin. This name may or
may not be the same as the client's local username; a translation is
performed by the server (via antoln) which takes the kerberos name
and translates it to the client's username. I understand that at
present they ARE in fact the same, but by using antoln to do the
"conversion", the code will continue to work if at some point in the
future they are different.
b. The remote username, specified by the client via a switch on the
rlogin command, is not involved with Kerberos. The login will be
attempted if Kerberos says that the request has been authenticated;
generally, changing one's username over an rlogin involves typing
a password anyway.
> 3. Are the same service keys used for rsh, rcp, and rlogin?
There are separate service keys for each type of service. rcp and rsh are
actually the same "service", in that the same server (rshd) is used to
service both clients; therefore, they both use the same service key.
rlogin is a different type of service and thus has a different service key.
You've probably noticed that the current scheme calls for the creation of
a large number of service keys: one for each type of service available on
each host. It is not clear to me that having separate keys for each service,
for the purpose of additional flexibility in controlling access, is worth
the cost of multiplying the number of keys that are required; this feature
appears to be a remnant of the days when Kerberos was also in the
authorization business.
> Where does the rlogin service store the private key it uses for
> deciphering Kerberos tickets?
In /etc/srvtab, under Un*x file protection (see bcn's note).
> This feature strikes me as being more of a bug. Have you established
> for certain that you can't just extend the present protocol in a way
> that produces a well-defined error response if you try to use the
> Kerberos extensions in talking to a server that doesn't know about
> Kerberos? I would expect that you could define a couple of new
> operation types within the protocol that request a Kerberos login and
> that supply the Kerberos ticket.
I generally refer to a "feature" as a known, unavoidable side effect.
Frequently a feature is undesirable, as is the case here. I could have
underscored this by labelling it a "misfeature". A "bug", by contrast,
is when a program fails to work as designed.
There are three cases worth considering here:
1. Both client and server speak Kerberos. If I could assume this to be
the case, it would be very easy to extend the protocol.
2. The server knows Kerberos, the client does not. My original version
assumed that this would be one of the cases. It distinguished between
a Kerberos-speaking client and one that did not by means of a special
cookie sent before the username in the protocol; receipt of this cookie
changed the server's expectation of what followed. Because of the
requirements of solving #3 below, I removed this ugly hackery.
3. The client knows kerberos, the server does not. The term "protocol"
glorifies the communication between the client and server: it is simply
a one-way message consisting of three or four NULL-terminated text strings
from the client to the server. It does NOT provide any well-defined error
indication. If rlogind does not like the information sent by the client,
it simply prompts the user for a "login: ". While I could look for
a string of characters like "login: ", I feel this is not well defined;
local versions of login may vary.
Steve had suggested the use of the new port. It has the advantage of
absolutely identifying servers which speak Kerberos (after it is made
"well-known" via registry). After thinking about it, I doubt a better
solution exists, but I'm listening.
mtc
--[0006]--
\f
[0007] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (41 lines)
Subject: Kerberos Servers
From spm@ATHENA.MIT.EDU Fri Jun 13 15:58:31 1986
To: saltzer, ostlund, kelley, jis, bcn
Cc: spm
Subject: Kerberos servers
Date: Fri, 13 Jun 86 15:57:02 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
Some of us have been discussing alternate means of providing
a highly available Kerberos service, and I believe that this issue
needs to be pondered for a while.
The most direct approach is to put a kerberos server in each cluster,
thus insulating each cluster from gateway and backbone problems.
The drawback with this solution is that it requires a lot of servers
(and $$), each of which ought to be more secure physically than we
currently can provide, and each of which needs to be updated and
managed.
In terms of the workload on Kerberos, I estimate that with 2000 workstations,
except for brief periods of bursty load (26-100 empties into the adjoining
terminal room), three or four uvax2 class servers will provide sufficient
service. Each should be able to handle 3-5 requests/second, with a typical
request asking for 3 tickets. Once routine logging for debugging is turned
off, the limiting factor is software encryption time.
We will have much more than 4 clusters.
I would propose, as a long term alternative, that instead of spending
the equipment money on a Kerberos server per cluster, we install only
3 or 4 Kerberos servers, judiciously located, and that the extra equipment
budget go towards providing a more redundant network, e.g. two
gateways per cluster. This would provide higher availability for all
services, not just Kerberos.
Of course, just providing the gateways is not adequate if the backbone is
not highly reliable, but I suspect sooner or later the backbone will for
many reasons have to become highly reliable.
In the interim, Pete and John are considering the one per cluster approach,
since it is in the realm of what they can do, and do quickly.
--[0007]--
\f
[0008] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (38 lines)
Subject: Re: Kerberos Support for Remote Serv
From Saltzer@ATHENA.MIT.EDU Sat Jun 14 10:42:47 1986
Date: Sat, 14 Jun 86 10:40:10 EDT
Subject: re: Kerberos Support for Remote Services, Project Description (long)
To: Mark Colan <mtc@ATHENA.MIT.EDU>
Cc: geer@athena.mit.edu, bcn@athena.mit.edu, spm@athena.mit.edu,
charlie@athena.mit.edu, noah@athena.mit.edu, jis@athena.mit.edu
In-Reply-To: Mark Colan <mtc@ATHENA.MIT.EDU>'s message of Mon, 09 Jun 86 16:24:04 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> > What is "vxlogin"?
>
> As bcn stated, it is (at present) a utility which creates the tickets.
Where did the IBM people go? Who let a name like that into Athena?
Are all logins to a VAX? Come on, guys, change its name. (Drop the
"v").
> a. A kerberos name is placed in the ticket by vxlogin. This name may or
> may not be the same as the client's local username; a translation is
> performed by the server (via antoln) which takes the kerberos name
This approach sounds good, but it just pushes the problem back to
whoever has to implement antoln. (Which would be better named
an_to_ln.) Are there any good ideas on how that function should be
implemented in the long run?
> You've probably noticed that the current scheme calls for the creation of
> a large number of service keys: one for each type of service available on
> each host.
It certainly seems to me that rsh, rcp, and rlogin should be handled
as one service and thus use one service key.
Jerry
--[0008]--
\f
[0009] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:12 (110 lines)
Subject: Kerberos and rlogin services
From mtc@ATHENA.MIT.EDU Sat Jun 14 12:36:52 1986
To: saltzer
Cc: kerberos, geer, jis, charlie, noah
Subject: Kerberos and rlogin services
Date: Sat, 14 Jun 86 12:34:52 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
[Reminder: for those of you not already on the new "kerberos" mailing list,
add yourself via madm if you want to participate in these discussions.]
Jerry,
This is a reply to your two notes of Saturday June 14. I have avoided
addressing issues not directly related to the my part of the project
in favor of letting Cliff or Steve comment on them.
> ...for simplicity, the switches [whether to use normal or Kerberos-
> authenticated protocols] probably should consist of placing
> either or both of two demon startups in /etc/inetd.conf.)
That is exactly the case now.
> ...it might be appropriate to make it possible to tie it in to
> opening of an X window, and call it "xlogin" rather than "rlogin".
I've been calling it "klogin" etc. Programs which start with "k" are
just links to their "r*" counterparts; for the daemons (servers), the
name of the program is used to determine the expected protocol. Switching
to "x*" names is okay with me, except that implies some interaction with
the window system. Maybe that's appropriate; we COULD extend rlogin to
pop up a new window for the session if we know we are on an X display.
> a single command named "rlogin" with the current user interface
> might under the covers first try to invoke the xlogin protocol,
> and if rebuffed (by the new, cleanly specified xlogin protocol)
> then attempt to use the rlogin protocol on the old rlogin port.
That's the way it is now, except for the new protocol.
> It certainly seems to me that rsh, rcp, and rlogin should be handled
> as one service and thus use one service key.
I agree. What to call it to distinguish it from other Kerberos clients?
"xlogin" does not seem to be a good name for a service that includes rsh
and rcp.
> ...the idea that Kerberos should be controlled using a mechanism
> like the rlogin /etc/hosts.equiv and ~/.rhosts files is going
> the wrong direction...The notion that Kerberos might be trusted
> but only if the login comes from certain hosts or users is flawed.
I agree that the use of these two files is a mess, non-intuitive, etc,
and that the proposed extensions to the file make it much messier.
Thus, you are proposing to eliminate this kind of administrative
control from Kerberos-authenticated services altogether. That implies
that Kerberos authentication, together with the protection obtained from
the Un*x password and file system, is sufficient control for remote access.
> the old protocol is so badly designed that it can't be extended;
> yet the proposed new protocol is just as bad as the old one...
> Create a new protocol on a new port that is Kerberos-only, that
> has a nice clean protocol specification, and that is tailored to our
> real requirements...a single new protocol (the one I call xlogin)
> should actually suffice to do all of these things.
I have approached the project with the philosophy of changing as little as
possible to get the work done, to avoid side effects of the changes; the
"new" protocol is a simple extension to the old one. A new protocol sounds
like a good idea, and I'm willing to design and implement one.
The major problems with the old protocol are the following:
1. It is not (readily) extensible (in some situations)
2. It provides no feedback (normal/error indication)
3. The only way to determine whether we have the entire message
is context-specific - have enough Null-teminated strings been
received?
Off the top of my head, I can think of a very simple, clean protocol that
addresses these points, while providing the necessary exchanged of
information. I'd appreciate comments from those of you who have more
experience with protocol design. A (very) rough sketch follows:
1. Send first a function code, two or four bytes, which requests an
action and implies the form of the parameters that follow, and
a length attribute to state how many bytes of message follow.
The length is necessary because some messages, like the Kerberos
ticket, will not be Null-terminated strings.
Some initial functions:
a. Kerberos-authenticated rlogin request (followed by ticket and
other information)
b. Kerberos-authenticated rsh/rcp request (followed by ticket and
other information). These are the same function because rcp
uses the rshd server.
c. Acknowledgement, followed by a status code (okay, error code, etc).
2. The server side always sends back an acknowledgement. The client
acknowledges the acknowledgment, signalling the server to actually
do its work.
Note that this protocol provides all of the services we are discussing,
in the same way as the rcmd() routine now provides them.
mtc
--[0009]--
\f
[0010] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:14 (21 lines)
Subject: revised ext_srvtab
From ostlund@ATHENA.MIT.EDU Tue Jun 17 17:08:53 1986
From: ostlund@ATHENA.MIT.EDU
Date: Tue, 17 Jun 86 17:07:33 EDT
To: kerberos
Subject: revised ext_srvtab
I've fixed menelaus:~ostlund/src/ext_srvtab to ask for the Kerberos
master key and then use this to decrypt services' passwords before
writing them to the srvtab file. Usage is:
ext_srvtab host ...
You will be asked for the Kerberos master password. If you enter the
correct password, a file "host-new-srvtab" file will be generated
for each named host.
John
--[0010]--
\f
[0011] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:14 (43 lines)
Subject: rlogin, klogin, etc
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Jun 18 16:16:27 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: rlogin, klogin, etc
To: kerberos@ATHENA.MIT.EDU
Maybe it is time to make a clean break from the existing Unix programs
and thus avoid complicating this too far. I would not be against
creating our own klogin to replace rlogin. klogin would not need to
deal with host.equiv file, etc. I would, however, like to see a
.khosts file which allows users to specify what user, when
authenticated by kerberos, can use their account. This is an
authorization problem, and not an authentication one.
If we do take this route, the new protocol should contain version
number as Steve suggested. I would also suggest that things be
changed to pas the entire environment across, instead of just the
terminal type.
As to the key issue, I see no problem with grouping all the services
which run as root on a machine together, and using a single key for
them all. Of course, all the clients of these servers will have to
know which key they need. This isn't really a problem, as long as you
do it from the start. rsh, rexec, rcp, and rlogin should clearly use
the same key.
I think that individual hosts should have different keys, though.
Since the name of the server will contain the hostname (by
convention), using a key based on the cluster the server is in would
require the client to be able to figure out which cluster a server is
in. One could use the same text for the key in each case, but this
doesn't buy anything.
I will change antoln to an_to_ln as per Jerry's suggestion. I will
also rename vxlogin. The question is, to what, if we use the name
klogin for the new rlogin, then we can't use it for this. Vxlogin (or
it's new name) isn't in the long term plan, though, since it's
function will be performed by the normal login program.
~ Cliff
-------
--[0011]--
\f
[0012] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:14 (14 lines)
Subject: the kerberos alias
From ostlund@ATHENA.MIT.EDU Thu Jun 19 13:17:56 1986
From: ostlund@ATHENA.MIT.EDU
Date: Thu, 19 Jun 86 13:06:40 EDT
To: kerberos
Subject: the kerberos alias
... is finally on the air. (Extraction of the alias file got hung
up for the last couple of days. I "brute forced" an extraction at
about noon today.)
John
--[0012]--
\f
[0013] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (18 lines)
Subject: Kerberos flavored passwd
From ostlund@ATHENA.MIT.EDU Thu Jun 26 16:06:38 1986
From: ostlund@ATHENA.MIT.EDU
Date: Thu, 26 Jun 86 16:05:06 EDT
To: kerberos
Subject: Kerberos flavored passwd
The version of passwd I was putting together to seed the Kerberos
database was less secure than Cliff feels is necessary. After
a couple of rounds of discussion, I agree with him, and have decided
to "do it right". In terms of timing, this means I probably won't
have it done until next Tuesday or Wednesday. Sorry about the
delay. In the (presumably brief) meantime, we can change passwords
by hand for people who want to use Kerberos immediately.
John
--[0013]--
\f
[0014] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (24 lines)
Subject: db_edit
From ostlund@ATHENA.MIT.EDU Fri Jun 27 16:52:15 1986
From: ostlund@ATHENA.MIT.EDU
Date: Fri, 27 Jun 86 16:50:41 EDT
To: kerberos
Subject: db_edit
I've modified db_edit slightly so that it can generate random passwords
for principals on demand. To get a random password, type "RANDOM"
(twice, unfortunately) in response to the request for new password.
You'll be asked to verify that you want a random password: if you
don't respond 'y' or 'Y', you'll get "RANDOM" as the literal password.
Random passwords are of little use for people, but are of use for
services.
John
--[0014]--
\f
[0015] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (67 lines)
Subject: initial version of kerberos-authenti
From mtc@ATHENA.MIT.EDU Mon Jun 30 16:49:26 1986
To: kerberos
Subject: initial version of kerberos-authenticated rlogin etc
Date: Mon, 30 Jun 86 16:47:04 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
This memo describes the use of the initial version of the remote
services (rlogin, rcp, rsh) that use Kerberos authentication.
This software is still in slightly rough shape and is will be
undergoing some development for the next week or so, depending
on the types of bugs found.
At the moment, these programs use a very slightly modified "protocol"
from the original utilities. A new protocol may be developed if
Athena mgt decides that this is appropriate use of resources.
INSTALLING THE SOFTWARE
The following files are located in goanna:krb/bin. They can be
installed in any directory on the host machine, but a symbolic
link /krb must point to their home.
rshd,kshd remote shell daemon; same file, different links
rlogind,klogind login daemon; same file, different links
rlogin,rcp,rsh the user programs to access remote services
login called by rlogind
Note that rlogin, rcp, and rsh must be owned by root and set uid, as in:
su
chown root rlogin rcp rsh
chmod 4555 rlogin rcp rsh
CONFIGURATION FILES
Two files require new entries to use these programs.
/etc/inetd.conf: Add these two lines at the end of the file:
kshell stream tcp nowait root /krb/kshd kshd
klogin stream tcp nowait root /krb/klogind klogind
After updating /etc/inetd.conf, you must cycle inetd to get it
to read the changes:
su
ps -aux | grep inetd
kill -9 <pid> where <pid> came from the ps, above.
inetd
/etc/services: Add these lines somewhere in the file:
#
# Kerberos-authenticated services
#
klogin 543/tcp
kshell 544/tcp cmd # no passwords used
In addition, the usual Kerberos configuration files, /etc/srvtab and
/etc/k_in_tkts must be properly set up; see bcn for more information
on the required changes. Also, new entries are required in the
Kerberos database to enable a particular user to use services.
Please report problems and bugs to mtc.
mtc
--[0015]--
\f
[0016] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (26 lines)
Subject: krb_err_txt.c
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Thu Jul 3 14:15:11 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: krb_err_txt.c
To: spm@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I am going to update this. You went and created it, and apparently
told other people that they could use is (such as MTC) without ever
even mentioning to me that it existed. What you didn't realize when
you created it was that not all routines returned the same thing. For
example, and error code of 2 in rd_ap_requested meant that the ticket
was expired, but in mk_ap_request, it meant you couldn't find the
ticket. I think it probably is a good idea to have the same code mean
the same thing for all routines, and I have since started to make this
the case.
The problem is that you were telling people to use this array of error
messages for all routines (or at least they thought you were) when it
wasn't the case. Anyway, people should use the error codes defined in
krb.h for comparisons in their own code. The array should only be
used to display the messages.
~ Cliff
-------
--[0016]--
\f
[0017] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (10 lines)
Subject: Thursday at MIT
From miller%erlang.DEC@decwrl.DEC.COM Thu Jul 10 11:49:40 1986
Date: 09-Jul-1986 0956
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Thursday at MIT
I will be at Athena Thursday, July 10, as long as "styx" is up and running
ok.
--[0017]--
\f
[0018] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (24 lines)
Subject: RT encryption library
From spm@ATHENA.MIT.EDU Thu Jul 10 19:10:24 1986
To: kerberos
Subject: RT encryption library
Date: Thu, 10 Jul 86 19:08:27 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
I finally got the encryption library for the RT to give the right answers!
However, I have to integrate many (conditional) changes back into the main
sources, and I have to insert the alignment checks at the front end of the
encryption routines to conditionally bcopy data instead of using assignment.
For now, there is a copy of the routines and library in
styx:/projects/auth/src/lib/des/ibmws that checks out ok on the
"verify" program. Also, a backup copy of the changed stuff is
in menelaus:~spm/backup. (The active copy of the modified stuff is on
my VS2).
I will be on vacation for the next two weeks, and will be back at Athena
one day the following week, July 28+.
--[0018]--
\f
[0019] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (167 lines)
Subject: Kerberos slave data base
From miller%erlang.DEC@decwrl.DEC.COM Fri Jul 11 12:28:41 1986
Date: 11-Jul-1986 1059
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @SYSOGIN:KERB)
Subject: Kerberos slave data base
Purpose:
--------
This note presents plans for slave copies of the Kerberos database.
Recall that multiple replicas of the Kerberos authentication database
and server may run concurrently in order to provide greater availability
and a degree of load sharing. In order to avoid the difficult problems
of distributed databases, only one copy, the master copy, may be directly
updated. All the other replicas, called slaves, are entirely dependent
on the master copy, and are only updated from the master copy. For
Kerberos type applications with relatively low frequency of update,
and modest requirements for timeliness, it is sufficient to update the
slave copies on the order of once or twice a day.
Master Copy:
-------------
The master copy of the Kerberos authentication database is layered on
top of the RTI Ingres relational database. Alternative technologies
with similar characteristics -- indexed access by multiple keys,
concurrency control, good performance independent of size, ability to
support many ad-hoc queries -- could be easily substituted if RTI Ingres
is not available. A small library
of embedded query language (equel) database access routines provides the
standard interface between the Kerberos database and various Kerberos
utilities. A few new utilities,
such as one to change the master key of the stored database, may need
either additional library routines, or specific equel programming.
The master copy is read/write, and once sufficient slave copies are
operational, should only be used for database related activities, not
routine Kerberos requests for tickets.
Slave Copies:
-------------
Slave copies of the database are designed to be read-only, and do not
use the RTI Ingres database, but rather only the standard Unix file
system. They are intended to support routine Kerberos ticket requests
as efficiently as possible. Slave copies only contain a subset of the
fields for each record, but should contain all records from the master
db.
A slave copy is produced periodically at the master site as follows:
1) A routine steps through the entire master copy, where for
each record it:
a) computes a hash function of the name and instance,
b) writes a Unix file entry consisting of a subset of
the fields of the master records, and the computed hash.
c) note that step (b) requires a Unix file, since RTI
Ingres does not support nested operations.
2) The Unix file containing all the slave records is sorted according
to the hash values.
3) Two new files are produced from the sorted file, an index file,
and a data file. (Details below). The data file contains the hash
sorted entries in order, without the hash values. The index
file contains an array of offset values, each value representing
the byte offset in the data file where all records with that
hash value begin.
4) Steps (2) and (3) could be combined, if desired.
The slave files are then copied to the slave Kerberos servers. This
copy should be checked for integrity by using Kerberos protocols to
compute a checksum of the file at the master site, and securely transmitting
the checksum to the slaves. The slave sites then recompute the checksum
of the received file, and compare it to the checksum securely received
from the Kerberos protocol. If they match, the file integrity is ok,
and the slave should reinitialize its database, as atomically as
possible, using the new file.
The slave server uses the slave file as follows:
1) On startup, it opens both the index and data files, checks their
size, allocates memory for the entire files, and reads both entire
files into memory. In other words, we are using the virtual memory
system as a cache. This should work well as long as the
size of the files does not greatly exceed the available physical
memory. Most or all lookups can be done entirely in memory.
Let the system do the dirty work, but keep an eye on the
paging/swapping counts. A rough calculation is
10,000 records x 50 bytes/record = .5mb, which should be fine
even on a base system with only 2mb total memory. But keep
monitoring, just in case the cacheing strategy needs to be changed.
2) For each request, compute the hash value of the name and instance
using the same hash function as before. Then determine the search
limits of offset[hashvalue] to offset[hashvalue+1] by looking up
the index file values. Within this range of offsets, search
the data file, comparing the actual name and instance to the
request. Either a match will be found, or the upper limit to the
search reached. The hash value is chosen to produce a mean
of only 10-15 entries per bucket, which should all fit in a
single page.
3) The slave database functions noted in (1) and (2) are packaged as a
Kerberos database library supporting a subset of the semantics of the
master library. Either the routine names could be identical, with two
differently named libraries, and "ld" specifying the appropriate
one, or slightly different versions of the routine names could be
used.
Details:
--------
hash function -
For a population of ~10,000-20,000 records, use ~ 1000 buckets such that
most buckets are 10- 20 records and fit within one page.
(I have some good functions, cheap to
compute, that I tested on the entire athena_reg database of >10000, and
produce a good mean and standard deviation of bucket counts. I have to
find the code to give you the particulars.)
index file --
If N is the number of buckets in the hash function, numbered 0 - N-1, then
the file need just be structured as:
unsigned long offset[N+1]; /* array of offsets*/
where
offset[i] = byte offset from beginning of data file to beginning of
records with hash value 'i'
and
offset[N] = size of data file, in bytes, used to terminate searches
on the last bucket.
data file --
The data file is a sequence of records, sorted by the computed hash.
Each record contains only those fields needed by routine Kerberos
ticket request operations. Any other needs should go to the master.
Name and instance are compressed so they only take up as much space
as needed, not the entire space (currently 40 char) allowed in the
master database. The fields are as follows, in order beginning with
the lowest address. By convention, all database multi-byte fields are
defined in vax byte order.
Field: type:
name ascii null term string
instance ""
key_version unsigned char
kdc_key_version unsigned char
max_life unsigned char
key_low unsigned long
key_high unsigned long
exp_date unsigned long
attributes unsigned ?? /* check definition*/
(Note: when searching, read name, instance, compare, then skip
fixed distance to next name,instance if needed. Compare new address to
limit.)
Both the data file and the index file could be prefixed with a timestamp
and address of creation, as long as these were taken into account in
computing the offsets. This may help in managing slave file versions.
--[0019]--
\f
[0020] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (13 lines)
Subject: Kerberos release
From bcn@ATHENA.MIT.EDU Mon Jul 14 20:32:30 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Mon, 14 Jul 86 20:30:18 EDT
To: treese
Subject: Kerberos release
Cc: kerberos
Is on castor in /projects/auth/release/860714.
Read the README file for more info.
~ Cliff
--[0020]--
\f
[0021] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:15 (15 lines)
Subject: Re: Kerberos release
From treese@ATHENA.MIT.EDU Tue Jul 15 17:09:14 1986
From: Win Treese <treese@ATHENA.MIT.EDU>
Date: Tue, 15 Jul 86 17:06:49 EDT
To: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Mon, 14 Jul 86 20:30:18 EDT
Subject: Re: Kerberos release
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
Thanks; I picked it up.
Win
--[0021]--
\f
[0022] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (72 lines)
Subject: integration with old protocols
From Saltzer@ATHENA.MIT.EDU Tue Jul 22 20:35:32 1986
Date: Tue, 22 Jul 86 20:32:35 EDT
To: kerberos
Subject: integration with old protocols
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Yet another proposal (in this case the example is POP) for
integration of kerberos by assigning a new well-known TCP port for a
protocol variant leads me to want to explore possible alternatives.
Here is a proposal that might eliminate the need to make any changes
at all in old protocols that we want to authenticate with Kerberos.
The idea is to assign one new well-known TCP port, exclusively for
the purpose of compatible authentication in preexisting protocols.
Any server that ran one or more of the old protocols would also run a
listener on this port, known as the Ksetup server (better name
proposals are welcome.)
The scenario, say for POP, would go as follows:
1. The POP client, modified to use Kerberos, would track down a POP
ticket and authenticator and send them together with the service
name for POP in a single UDP datagram, to the Ksetup server's port.
(Using a standard time-out/retry procedure for reliability.) The
authenticator part of the packet would include in one field,
encrypted, the identity of this client, in exactly the form the
POP protocol expects to receive it.
2. The Ksetup server would look in /etc/servtab for the appropriate
key, examine the ticket and authenticator, and if all looks OK,
create an entry in a new table, /etc/Kconnections. This entry would
contain all the interesting information in the original ticket--client
identification, expiration date, temporary key, etc., plus the
IP address of the client that sent it. It would return a
datagram reporting success or failure in this endeavor.
3. The POP client, upon receipt of a success response, would then
proceed to invoke the POP protocol according to the present
specification.
4. The POP server, upon receiving a request for connection, would
collect the requester's claimed identity (in the form provided
as part of the standard protocol) and the IP address
of the requester (may be tricky--is that information easily
available?) and call to a Kerberos library routine named
is_this_one_OK(). That routine returns 0 for failure and the
value of the temporary key for success.
5. The routine is_this_one_OK() operates by comparing the
information supplied by the POP server with the information in
/etc/Kconnections. If the IP address and identity both match,
it returns the temporary key.
6. The POP server can now accept the connection, and if wanted
it might even encipher the data with the temporary key before
sending it back to the POP client.
I think the same pattern would work for rlogin, rsh, rexec, lpr, POP,
and even NFS and RVD. Protocols such as tftp, which do not attempt
to identify their clients, require a different strategy, though
authentication based only on IP address would probably suffice. New
protocols such as notify would have the option of including the
initial exchange as part of their definition rather than by relying
on the Ksetup server.
Any comments?
Jerry
--[0022]--
\f
[0023] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (17 lines)
Subject: integration with old protocols
From mike@ATHENA.MIT.EDU Wed Jul 23 15:28:12 1986
Date: Wed, 23 Jul 86 15:25:29 EDT
From: Michael R. Gretzinger <mike@ATHENA.MIT.EDU>
Sender: mike@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Tue, 22 Jul 86 20:32:35 EDT
Subject: integration with old protocols
Sounds good to me. It certainly makes server modifications to support
Kerberos easy.
--mike
--[0023]--
\f
[0024] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (29 lines)
Subject: Re: Integration with old protocols
From bcn@ATHENA.MIT.EDU Fri Jul 25 09:42:43 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Fri, 25 Jul 86 09:40:37 EDT
To: Saltzer
Subject: Re: Integration with old protocols
Cc: kerberos
Your proposal for integrating Kerberos with existing protocols looks
pretty good. It is sort of the "next step" towards a library that would
provide automatically authenticated TCP and UDP functionality.
I see some problems with using the "Ksetup" (Yeah, we need a new name)
approach. As defined, it would be easier for an active attacker to
impersonate someone else. But then again, even the current rlogin, rsh,
rcp integration allow such an attack since authentication is only
applied at the beginning of the connection. The details of the Ksetup
server and the library routines to access authentication information
using it are not completely specified, and it may be possible to come up
with an approach that is no less secure.
I am willing to work with someone designing the server, and defining a
new procedure for the Kerberos library to come retrieve information from
the server. I have other priorities, though (ticket granting tickets,
and getting Kerberos to run on the RT), so someone else will have to do
the actual coding.
~ Cliff
--[0024]--
\f
[0025] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (48 lines)
Subject: Re: RVD authorization and Kerberos i
From bcn@ATHENA.MIT.EDU Fri Jul 25 10:36:37 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Fri, 25 Jul 86 10:33:48 EDT
To: Saltzer
Subject: Re: RVD authorization and Kerberos integration plan
Cc: kerberos, rvd-info
This is in response to your proposal on the RVD authorization and
Kerberos integration plan. Assuming the existence an access control
list server (ACLS), your proposal looks good.
I have problems with one point, though, which is more an issue in the
design of the ACLS. I do not see the authorization as being a name of a
Kerberos principal. This seem to muddy an already unclear concept. A
Kerberos principal should be someone at either end of a connection, such
as a user, or a service. It is more an authentication concept that an
authorization concept since each prinicpal has it's own key (although it
could be the same as the key for another principal). There are cases
where one user may have several instances. In this case, the user gets
to choose which principal he wants to be come when he "logs in".
I propose instead that the ACLS provide its own ticket to a user such
that the user can pass the ticket on to the service. This ticket is
distinct from a Kerberos ticket, and may contain different/additional
information that can be used by the end service. The authenticity of
this ticket can be checked using Kerberos. This can be accomplished as
follows:
The beginning of an ACLS ticket is a Kerberos authenticatior for
the end service issued to the ACLS. Note that this ticket is
encrypted in the services key, so the user who the ticket is
returned to can't read it.
The second part of the ACLS ticket contains the authorization
information to be provided to the end service.
There are two ways the authenticity of the second part of the ACLS
ticket can be checked. The Kerberos authenticator contains a checksum
of the authorization data or the authorization data is encrypted in the
session key from the ticket. Both these approches can be accomplished
without change to Kerberos. The tradeoff is speed in creating the ACLS
ticket, versus difficulty in modifying the authorization data. If you
encrypt the authorization data, you also get the additional side effect
(for better or worse) that only the end service can determine the
contents of the ACLS ticket.
~ Cliff
--[0025]--
\f
[0026] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (34 lines)
Subject: Re: RVD authorization and Kerberos i
From wesommer@ATHENA.MIT.EDU Fri Jul 25 11:24:36 1986
To: bcn@athena.mit.edu
Cc: saltzer@athena.mit.edu
Cc: kerberos@athena.mit.edu, rvd-info@athena.mit.edu
Subject: Re: RVD authorization and Kerberos integration plan
In-Reply-To: Your message of Fri, 25 Jul 86 10:33:48 EDT.
<8607251433.AA07502@MENELAUS>
Date: Fri, 25 Jul 86 11:21:25 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
If you encrypt the authorization data, you also get the additional
side effect (for better or worse) that only the end service can
determine the contents of the ACLS ticket.
Why not do as you do with Kerberos, which is to enclose the plaintext
part of the ticket in unencrypted form in the reply, along with the
encrypted form; the whole thing could be wrapped up and encrypted in
the user's key.
I think that it might also be reasonable to provide some form of local
ACL library for some applications, to cut down the burden on the
central ACLS and to reduce the amount of network latency
involved. Presumably, the ACL, which would be a list of pairs
of the form "name of principal", "access allowed" (with some wildcarding of
the "name of principal"), could be stored in a protected file on the
server, and manipulated using utilities on the server or using an
extension to the protocol. This is the approach which is being taken
by Stan Zanarotti in his "discuss" system (a networked notes- or
Multics forum-like conferencing system).
- Bill
--[0026]--
\f
[0027] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (81 lines)
Subject: Access Control Lists and RVD
From bcn@ATHENA.MIT.EDU Mon Jul 28 13:37:21 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Mon, 28 Jul 86 13:21:41 EDT
To: kerberos, rvd-info
Subject: Access Control Lists and RVD
On Friday, Jerry and I worked out some more of the details of an Access
Control List Server (ACLS), and how it could be used by RVD.
The ACLS will be contacted by the user and authenticated via Kerberos.
The user tells that ACLS the name of the service he wishes to use and
the name of the list he claims to be in.
The ACLS will determine whether the user is in that list. If not, it
will return an error.
If so, it will generate an ACLS ticket that consists of the following:
A Kerberos authenticator authenticating the ACLS to the service.
This consists of:
A Kerberos ticket issued to the ACLS for the service and
additional information encrypted in the session key from the
ticket.
Authorization data including the name of the authorized principal,
his network address, and the name of the access control list of
which the principal is a member. This data is also encrypted in
the session key from the ticket.
The user will use the ACLS authenticator in place of the Kerberos
authenticator. This is possible because the ACLS ticket begins with a
Kerberos ticket. When the service receives an authenticator it decrypts
it, and sees that the authenticated principal is "ACLS" "machinename".
This tells it that it is from an ACLS, and that there is more to the
authenticator. It then reads the name of the list from the remainder of
the authenticator, and it generates a list name to be compared with its
internal database of who is authorized to spinup what disks.
It is important to note that local authorization data is still
maintained. This data is a list of a fixed number of principals
authorized to use a service/disk. What we have done through the ACLS,
is to allow that list to contain groups. i.e. anyone on a particular
ACL.
At first we decided that a list name would appear as "ACLS" "listname".
This would, if desired, allow one to create a principal with the same
name as a list, and thus one could bypass the ACLS if desired by the
people maintaining Kerberos. Since our discussion, I found one problem
with such names in that, if one did allow bypassing, the person with the
password for an ACLS principal could pretend to be an ACLS, and thus
falsely certify his membership in any ACL. This is easy to fix,
although it makes things a bit less clean, by having the apparent
principal for lists be "ACL" "listname". Thus, the service end not only
fills in the instance from the last part of the ACLS authenticator, but
it also changes "ACLS" into "ACL". Thus, we can still allow bypassing
the ACLS if desired, but we do not have to resort to remembering the
instance names of all certified ACLSs.
One unresolved issue (we just didn't think of it while discussing this)
has to do with final authentication of the user to the service. Can an
ACL authenticator be reused? If so, do we require a user to
authenticate himself to an end service in addition to presenting the
ACLS authenticator? If the answer to the above are Yes, and No, then
the only thing that stops an attacker from stealing the ACL
authenticator off the net and reusing it is the presence of a network
address inside. But, this can be easily gotten around. Requiring the
user to additionally authenticate himself to the end service will solve
this problem but may complicate the protocol. If we only allow an ACL
authenticator to be used once, then we must require that it is returned
to the user encrypted in the session key from the ticket the user used
to authenticate himself to the ACLS. This also requires many additional
calls to the ACLS, and, thus, is undesirable.
The above is a rough design for an ACLS server. Comments are welcome,
as are offers to help finish/refine the design, and to implement it.
~ Cliff
--[0027]--
\f
[0028] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:16 (37 lines)
Subject: More on an ACLS
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Mon Jul 28 22:46:00 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: More on an ACLS
To: kerberos@ATHENA.MIT.EDU
Over dinner, srz, spook, and myself discussed the proposal for the
ACLS. A few additions to the pervious message emerged.
The ACLS will maintain privileges along with each authorization in
it's database. Right now, we think 8 bits is enough, but I will
entertain arguments for more. At the service end, each entry for a
group, or direct user will have a mask which will indicate which of
these bits may be used. For users authenticated directly, only the
mask will be used. For those authenticated/authorized through the
ACLS, the logical AND of the mask and the privelege bits will be used.
Interpretation of the bits is up to the individual service, but some
kind of convention will be appropriate.
It is desirable to be able to delegate part of the namespace of groups
to particular individuals. Thus, if I have a unique service, or
services that I provide, and if for some reason it is appropriate for
me to be able to create new ACLs, I can be granted a prefix, under
which I can create other lists. An example of this would be the
person responible for creating and assigning RVDs. For each RVD he
create, he will want to create an ACL with the same name. This is
distinct from allowing someone modify access to an existing ACL.
To avoid the issue of dividing names into components, or choosing a
separator for different parts of an ACL name, I propose granting such
access based on prefixes. Thus, when I assign part of the namesapce
to RVD, I can choose "rvd_" as the prefix. If some other application
want's to use something else as the prefix, this is fine too.
~ Cliff
-------
--[0028]--
\f
[0029] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (11 lines)
Subject: Friday
From miller%erlang.DEC@decwrl.DEC.COM Wed Jul 30 11:22:01 1986
Date: 30-Jul-1986 1000
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Friday
August 1, I will be at Athena. If you know of any reason why things will
be broken (menelaus, lyre, styx, RVD, etc.) please let me know before
hand. thanks.
--[0029]--
\f
[0030] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (39 lines)
Subject: Re: integration with old protocols
From spm@ATHENA.MIT.EDU Sun Aug 3 13:42:25 1986
To: saltzer@athena.mit.edu
Cc: kerberos@athena.mit.edu
Cc: spm@menelaus.mit.edu
Subject: Re: integration with old protocols
In-Reply-To: Your message of Tue, 22 Jul 86 20:32:35 EDT.
<8607230032.AA16734@HERACLES>
Date: Sun, 03 Aug 86 13:40:00 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
I read your recent proposal, and believe it will work given a couple
of additions:
1) The "cached" authentication that the Ksetup server stores may
only be used once, within a very brief time of creation.
Otherwise, you have lost replay protection.
2) If "is_this_one_ok()" fails, it still has to distinguish
whether it failed because the Kerberos authentication is invalid,
or because the client does not speak Kerberos. This is a sticky
problem, since we might wish to allow non-Kerberos clients to
operate, but dont want to allow someone who should be using
Kerberos to break security by just disabling the Kerberos portion.
Perhaps a crude address filter could be used for this?
I see four implications:
1) Many extra port assignments are not needed.
2) Run time cost increases by two messages.
3) Security is a bit weaker, since the opportunity to crytographically
bind some of the application protocol into the authenticator is
lost.
4) A new privileged entity is created, Ksetup, and more sensitive
data is stored on the server.
There is already sufficient information in the protocol messages to
support this.
Overall, I think it is a good approach to try.
--[0030]--
\f
[0031] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (9 lines)
Subject: At Athena
From miller%erlang.DEC@decwrl.DEC.COM Wed Aug 6 19:17:55 1986
Date: 06-Aug-1986 1728
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: At Athena
I will be at Athena on Friday, Aug 8.
--[0031]--
\f
[0032] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (14 lines)
Subject: caucus
From geer@ATHENA.MIT.EDU Sat Aug 9 00:26:36 1986
From: Dan Geer <geer@ATHENA.MIT.EDU>
Date: Sat, 9 Aug 86 00:23:10 EDT
To: bcn, fhsu, jis, mike, ostlund, treese
Subject: caucus
Cc: kerberos
relative to privileged access to specialized servers,
KERBEROS, E40-PO, HESIOD, and the like - views, please,
on whether they belong in the regular propagation process.
--dan
--[0032]--
\f
[0033] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (17 lines)
Subject: Major problem in workstation configu
From bcn@ATHENA.MIT.EDU Sat Aug 9 13:12:19 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Sat, 9 Aug 86 13:08:17 EDT
To: athena, kerberos
Subject: Major problem in workstation configuration
It seems that someone a long time ago decided give mt8 the same
major and minor device number as ra1a. This is fine if your
workstation has floppies as ra1 and ra2, but if your workstation
has a second hard disk this can cause major problems as running
tar (or dump) will write over your hard disk. This is not good.
In case anyone is wondering, the reason kerberos is down is
because of this. It should be running again on Monday.
~ Cliff
--[0033]--
\f
[0034] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (49 lines)
Subject: SUN RPC & XDR
From wesommer@athena.MIT.EDU Sat Aug 9 15:24:54 1986
To: hackers@athena.MIT.EDU, kerberos@athena.MIT.EDU
Subject: SUN RPC & XDR
Date: Sat, 09 Aug 86 15:22:07 -0500
From: Bill Sommerfeld <wesommer@athena.MIT.EDU>
I just found the posting of the SUN Remote Procedure Call library on
mod.sources. Sources (which have been slighly hacked to get them to
work) are in /@/priam/mit/w/e/wesommer/rpc. I've already psroff'ed
the documents; if you want a copy, I'll lend you the one I printed for
copying...
The system is set up to allow RPC over both TCP and UDP, and provides
a dynamic port-mapper daemon to map "program numbers" to UDP ports.
RCP calls are uniquely identified by a (program number, version
number, procedure number) tuple. SUN will "register" program numbers
from 0x00000000 to 0x1fffffff; they allocate 0x20000000 to 0x3fffffff
to "customer specific applications", and 0x40000000 to 0x5fffffff for
dynamically allocated program numbers.
SUN RPC attempts to solve the data representation and transport
problem; it does not attempt to solve the rendezvous problem (clients
have to know which machine their server is on, and which program
number, version number, and procedure numbers it is listening for).
Data representation is done through what they call XDR ("eXternal Data
Representation"); each type provides an "xdr" operation, which walks
the data structure, calling the xdr operations of its components.
Depending on the state of the XDR "stream" passed in, this either
builds a data structure from a stream of bytes, sends it over RPC,
flattens it into a stream of bytes, or destroys the data structure.
There are hooks for arbitrary authentication; I think I have
implemented the proper ones for Kerberos, (look at the routines in
rpc/rpclib/*krb*) although since kerberos.mit.edu is down right now, I
can't test this.
Since the authenticator is decyphered by the server-side library
before the service is identifed, a catch-all "rpc" or "sunrpc"
principal for each host involved will be needed to get this to work.
There may be a way around this if we're not afraid to do some sort of
"modularity violation" in the Kerberos-specific code.
- Bill
--[0034]--
\f
[0035] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:17 (16 lines)
Subject: Kerberos is running again
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Sat Aug 9 16:36:30 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Kerberos is running again
To: kerberos@ATHENA.MIT.EDU
Well, I have kerberos running again. I stated with the database as it
exists on menelaus, so it is quite a bit out of date. There are still
a number of machines that are not registered, and most of the users
that were registered aren't anymore. I tried installing the passwd
program, but couldn't get it to run. If we can get it to run,
people will be able to register themselves.
~ Cliff
-------
--[0035]--
\f
[0036] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (33 lines)
Subject: Sun RPC may now be kerberos authenti
From wesommer@ATHENA.MIT.EDU Sat Aug 9 23:08:28 1986
To: hackers, kerberos
Subject: Sun RPC may now be kerberos authenticated...
Date: Sat, 09 Aug 86 23:04:58 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
From looking at the Sun RPC documents, I got the general impression
that plugging a new type of authenticator into the library is
relatively simple. I was right.
If you look in /@/priam/mit/w/e/wesommer/rpc/rpclib/, at
auth_krb.c, auth_krb.h, and svc_auth_krb.c, you can see what I had to
do.
Mutual authentication is not implemented yet (although it should be
simple), and the error codes returned leave a little bit to be desired
(Kerberos has a somewhat wider variety, and information gets lost when
they get translated to the RPC codes). It also doesn't know how to
deal with service principals other than "rcmd.<machine_name>@Athena".
I have a test program which uses this, as a "whoami" service (the
service takes a "void" parameter, and ships back three strings: the
three parts of your kerberos principal name). I have "priam"
hardcoded into the programs (for simplicity); if the "test" program
(the daemon) is running on priam (I left it running), and you've done
a kinit and have a ticket for rcmd.priam@Athena, you're in business;
run "client", and it will tell you who you have authenticated as.
These playtoys are in rpc/westoys.
- Bill
--[0036]--
\f
[0037] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (15 lines)
Subject: Re: caucus
From ostlund@ATHENA.MIT.EDU Mon Aug 11 11:56:49 1986
From: ostlund@ATHENA.MIT.EDU
Date: Mon, 11 Aug 86 11:53:28 EDT
To: bcn@ATHENA.MIT.EDU, fhsu@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU,
jis@ATHENA.MIT.EDU, mike@ATHENA.MIT.EDU, ostlund@ATHENA.MIT.EDU,
treese@ATHENA.MIT.EDU
Subject: Re: caucus
Cc: kerberos@ATHENA.MIT.EDU
KERBEROS should certainly not be in the standard propagation scheme.
This requires KERBEROS's rtingres user to trust hector: bad idea.
John
--[0037]--
\f
[0038] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (35 lines)
Subject: notes from today's discussion of ker
From geer@ATHENA.MIT.EDU Mon Aug 11 15:28:44 1986
From: Dan Geer <geer@ATHENA.MIT.EDU>
Date: Mon, 11 Aug 86 15:20:20 EDT
To: bcn, geer, ostlund, treese
Subject: notes from today's discussion of kerberos deployment
Cc: kerberos
1. Propagage /krb/passwd to all time share machines today. This
implements John's dual /etc/passwd change and Kerberos register/change
routine as of code freeze date.
2. Next week, pending testing by friendlies who already have /krb in
their search path before /bin and /usr/ucb, move passwd to
/usr/athena. This will allow /bin/passwd to remain as it now is (which
is useful in single user mode especially) and yet puts the new passwd
in front of all users, based on Athena standard search paths.
Staff machines on Monday; rest of Athena on Friday pending favorable
results.
3. A new release of Kerberos with the ticket-granting ticket and other
associated changes out today or tomorrow; this is waiting on bug fixes
to mtc's (/krb/)rsh code.
4. Bugs remain in using the new passwd on workstations, and will be
addressed ASAP.
5. Kerberos dependent servers (klogind & kshd) to be propagated to
all Athena machines today. I'll take responsibility to notify relevant
parties. Other key files are /etc/services entries and the /etc/srvtab
(unique) machine key.
6. The old /etc/k_in_tkts file is no longer needed.
--dan
--[0038]--
\f
[0039] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (29 lines)
Subject: How am I supposed to cleanly get at
From wesommer@ATHENA.MIT.EDU Mon Aug 11 21:13:25 1986
To: bcn
Cc: kerberos
Subject: How am I supposed to cleanly get at the session key?
Date: Mon, 11 Aug 86 21:09:53 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To plug a lighter-weight authentication into the Sun RPC library
(using a method similar to that proposed in the Sun USENIX paper on
secure RPC, with Kerberos authenticators used for the initial exchange
of session keys), I need to get at a few things "internal" to
mk_ap_req:
- The timestamp used inside the ticket (since there does not
seem to be any library routine for mutual authentication; the server
will ship back the timestamp-1 sealed in the session key and a 32-bit
identifier). "Timestamp+1" is not used, since that could be used as a
verifier on another procedure call.
- The session key contained in the authenticator.. There
doesn't seem to be any way to get that other than to use "retrieve"
again. This will be used to encrypt successive timestamps attached to
each RPC request.
- Bill
--[0039]--
\f
[0040] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (15 lines)
Subject: Re: How am I supposed to cleanly get
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Mon Aug 11 21:51:02 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: How am I supposed to cleanly get at the session key?
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608120110.AA04013@HEIMDALL>
When you do a rd_ap_req, what you get back is a structure of type
AUTH_DAT. One of the fields of this structure contains the session
key.
~ Cliff
-------
--[0040]--
\f
[0041] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (15 lines)
Subject: Re: How am I supposed to cleanly get
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Mon Aug 11 21:51:09 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: How am I supposed to cleanly get at the session key?
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608120110.AA04013@HEIMDALL>
You are right that you need to use retrieve to get the session key on
the user side. I should probably make that fill in a structure
instead. It might be a little cleaner that way. I will look into the
timestamp issue.
~ Cliff
-------
--[0041]--
\f
[0042] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (15 lines)
Subject: Re: How am I supposed to cleanly get
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Tue Aug 12 10:59:19 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: How am I supposed to cleanly get at the session key?
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608120110.AA04013@HEIMDALL>
The new kerberos library now takes a structre of type credentials for
retrieve and returns the credentials in that structure. I don't think
that anyone but bill is calling retrieve directly, but if you are, you
will have to change your code.
~ Cliff
-------
--[0042]--
\f
[0043] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:18 (23 lines)
Subject: Re: How am I supposed to cleanly get
From wesommer@ATHENA.MIT.EDU Tue Aug 12 11:38:38 1986
To: bcn%deep-thought@eddie.mit.edu
Cc: kerberos@athena.mit.edu
Subject: Re: How am I supposed to cleanly get at the session key?
In-Reply-To: Your message of Tue 12 Aug 86 10:51:26-EDT.
<12230228458.17.BCN@DEEP-THOUGHT.MIT.EDU>
Date: Tue, 12 Aug 86 11:35:26 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
While you're breaking "retrieve", I'd like to make a little bit of a
plea for a more sane name for the routine; it's a rather generic name
to use for something in a library routine. I've had to debug things
where there were name collisions before; it's not fun. The worst case
was debugging "lpc"; it had a routine called "select" in it; when it
was first linked with the nameserver library, this broke the
nameserver (which called the "select" system call to allow a timed-out
read) It took me a few hours of single-stepping to figure out that
this was indeed the case. Perhaps krb_retrieve would be a better
name?
- Bill
--[0043]--
\f
[0044] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (53 lines)
Subject: kerberos related testing
From geer@ATHENA.MIT.EDU Tue Aug 12 12:05:26 1986
To: alix, kelley
Cc: kerberos, planning_managers, lerman
Subject: kerberos related testing
Date: Tue, 12 Aug 86 12:02:02 -0500
From: geer@ATHENA.MIT.EDU
We want to propagate some Kerberos and Kerberos related files as
follows. I have discussed this with Pete, but also want to put it in
this form for your reference. The object is to put some parts of
Kerberos out for testing now in the hope of releasing them to
general use for September 1.
We propagaged /krb/passwd to all time share machines Monday. This
implements John's dual /etc/passwd change and Kerberos register/change
routine as of code freeze date. It has no effect on anyone not already
using Kerberos.
Next Monday, pending testing by existing friendly testers who already
have /krb in their search path before /bin and /usr/ucb, we'll move
/krb/passwd to /usr/athena in E40 staff machines. This will allow
/bin/passwd to remain as it now is (which is useful in single user mode
especially) and yet puts the new passwd in front of all staff users,
based on Athena standard search paths. This has almost no effect on
those not yet using Kerberos, the only exception is that this passwd
installs their password in the Kerberos database in addition to the usual
Athena_reg database.
Pending staff use and acceptable behavior, we would propagate this to
general use with the September 1 time-share release. (Our real desire is
to do this Monday 25 August). This is important; 9/1 is the best,
or perhaps only, time to start loading the Kerberos database. Loading
it is, itself, a prerequisite to a smooth integration of Kerberos wise
services later in the year.
Bugs remain in using this new passwd on workstations, and will be
addressed ASAP. Today, Tuesday 12 August, we will put out the last
release of Kerberos before September. (This release provides the
ticket-granting ticket functionality.) The old /etc/k_in_tkts file is
no longer needed. If further bugs appear, we will address them as
part of our handling of other bugs found before the September 1 date,
which is to say fast fix and inclusion in a new bug-fix release.
Kerberos dependent servers (klogind & kshd) will be released to all
Athena machines today. (Other key files are /etc/services entries,
/etc/inetd.conf entries, and the /etc/srvtab unique machine key.)
These free-standing servers will not affect those not using Kerberos,
but will allow Kerberos testers/users to use authenticated rlogin and
rsh to the entire Athena environment.
--dan
--[0044]--
\f
[0045] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (12 lines)
Subject: Re: How am I supposed to cleanly get
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Tue Aug 12 12:14:16 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: How am I supposed to cleanly get at the session key?
To: wesommer@ATHENA.MIT.EDU
Cc: bcn%deep-thought@EDDIE.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608121535.AA05085@HEIMDALL>
Retrieve has been renamed get_credentials.
~ Cliff
-------
--[0045]--
\f
[0046] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (43 lines)
Subject: Kerberos release
From bcn@ATHENA.MIT.EDU Tue Aug 12 21:59:07 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Tue, 12 Aug 86 21:51:55 EDT
To: treese
Subject: Kerberos release
Cc: geer, kerberos
The makefiles foer the new release are complete. The release can
be found on castor in /projects/auth/release/860812. A copy of the
README file follows:
This is the latest release of the kerberos software. Run make clean,
make all, make install and the software will be installed in ./dist.
These are the files that should be installed in /krb on the
workstations. They can go wherever you want as long as the link /krb
points to them.
login, kshd and rlogind should be installed on all timesharing systems
in the directory pointed to by /krb. For the time being, John and I
will get this installed. Also, on all timesharing system, a site
specific /etc/srvtab must exist. John and I are also worrying about
this problem.
In the last release, the file /etc/k_in_tkts was needed. This file is
not needed this time around, and can be deleted. Its continued
existence does not hurt anything though.
libkrb.a and libdes.a should appear in /usr/athena/lib, and the
include files should appear somewhere that <> will work for them.
Timesharing machines should have the two lines in inetd.conf.app
included in their inetd.conf file. Once again, you should worry about
this for the fall release, but for now, John and I will worry about
it. Also, /etc/services must have the lines appearing in
services.app.
Finally, please make links similar to those in /usr/hosts for all
athena machines in /krb. Also, please add a link for eddie since it
is also using kerberos for authentication.
~ Cliff
--[0046]--
\f
[0047] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (26 lines)
Subject: Re: caucus (propagation to servers)
From treese@ATHENA.MIT.EDU Wed Aug 13 13:10:18 1986
From: Win Treese <treese@ATHENA.MIT.EDU>
Date: Wed, 13 Aug 86 13:07:08 EDT
To: Dan Geer <geer@ATHENA.MIT.EDU>
Cc: bcn@ATHENA.MIT.EDU, fhsu@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU,
mike@ATHENA.MIT.EDU, ostlund@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Dan Geer's message of Sat, 9 Aug 86 00:23:10 EDT
Subject: Re: caucus (propagation to servers)
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
I think we need to distinguish two classes of servers:
1. Highly secure ones (such as kerberos)
2. Standard services (such as post office, name service (Hesiod), etc.)
In the secure case, we have to leave them out in order to protect them.
kerberos, for example, should not trust hector for the passwd file propagation.
Other servers, such as the post office, can safely trust hector and
receive a passwd file, though we probably need a careful definition of
which accounts get propagated to them. This class includes RVD servers,
as well.
Win
--[0047]--
\f
[0048] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (20 lines)
Subject: Re: Kerberos release
From treese@ATHENA.MIT.EDU Wed Aug 13 15:51:31 1986
From: Win Treese <treese@ATHENA.MIT.EDU>
Date: Wed, 13 Aug 86 15:48:17 EDT
To: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Cc: geer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Tue, 12 Aug 86 21:51:55 EDT
Subject: Re: Kerberos release
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
As far as /etc/services and /etc/inetd.conf go, I plan to add the
Kerberos entries to the master sources. It won't hurt to have them
there is they're not being used.
As I understand it, all I need to do now is install the system on
the RVD. Correct?
Win
--[0048]--
\f
[0049] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (14 lines)
Subject: Re: Kerberos release
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Aug 13 16:35:57 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: Kerberos release
To: treese@ATHENA.MIT.EDU
Cc: geer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608131948.AA01160@CIROCCO>
That is correct. You need to install it on the RVD (with the right
modes) and set up the host links. That should be it.
~ Cliff
-------
--[0049]--
\f
[0050] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (15 lines)
Subject: kerberos backup system
From ostlund@ATHENA.MIT.EDU Thu Aug 14 16:40:37 1986
From: ostlund@ATHENA.MIT.EDU
Date: Thu, 14 Aug 86 16:37:37 EDT
To: kerberos
Subject: kerberos backup system
Chris Reed has completed a program that backs up the kerberos database
onto a separate disk from the live copy. It's installed on both
kerberos and menelaus. Ask Chris (panda) if you're interested in
details.
John
--[0050]--
\f
[0051] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:19 (28 lines)
Subject: today's rcmd changes - summary
From mtc@ATHENA.MIT.EDU Thu Aug 14 18:37:07 1986
To: bcn, geer
Cc: kerberos
Subject: today's rcmd changes - summary
Date: Thu, 14 Aug 86 18:32:46 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
I have made some changes to rcmd commands; here's a list.
1. fixed a bug which existed in both rsh and rcp, but manifested itself
only when a hostname with subdomains specified was used. The name
came out wrong.
2. fixed a minor bug in login.c; a routine I added has one case where
it failed to return a proper value.
3. changed login.c to add more information when someone logs in as root
via Kerberos (ie, /.khosts has an entry for the user, and the user
does an rlogin hostname -l root). When this happens, the syslog
now also contains the name, instance, and realm used for authentication.
There are no more bugs that have been reported, and all features I have
been asked to implement are complete. Please advise me of problems in
the Kerberos rlogin, rsh, and rcp commands.
mtc
--[0051]--
\f
[0052] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (35 lines)
Subject: Re: rcp not finding hosts
From mtc@ATHENA.MIT.EDU Fri Aug 15 14:18:51 1986
To: srz@athena.mit.edu
Cc: kerberos
Subject: Re: rcp not finding hosts
In-Reply-To: Your message of Thu, 14 Aug 86 23:09:15 EDT.
<8608150309.AA14759@CHARON>
Date: Fri, 15 Aug 86 14:15:23 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
> Well, the specific instance was fixed, but playing with it showed up
> a spurious error message:
> login (don't run kinit):
> charon% /krb/rcp trillian.mit.edu:/mit/s/r/srz/.login trill.login
> erberos key length invalid.
> and then it copies the file over, using the .rhosts file.
> I think this should either be a better error message, or just
> eliminated.
Thanx for pointing out the bug. It has been fixed; get the
latest rcp binary from menelaus:~auth/src/services/rcmd/rcp.
The problem was that in the case of remote to local, the error return
from mk_ap_req was not checked. Since it failed, there was no ticket,
but we used the Kerberos port anyway. That caused the "can't happen"
message you saw. Now that the error return from mk_ap_req is properly
handled, we give up on Kerberos in this situation and use the normal
shell port instead. I did NOT actually remove the error message; it
remains to indicate the "can't happen" situation.
mtc
--[0052]--
\f
[0053] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (52 lines)
Subject: Re: caucus (propagation to servers)
From Saltzer@ATHENA.MIT.EDU Sat Aug 16 11:05:27 1986
Date: Sat, 16 Aug 86 11:01:49 EDT
To: Win Treese <treese@ATHENA.MIT.EDU>
Subject: Re: caucus (propagation to servers)
Cc: Dan Geer <geer@ATHENA.MIT.EDU>, bcn@ATHENA.MIT.EDU, fhsu@ATHENA.MIT.EDU,
jis@ATHENA.MIT.EDU, mike@ATHENA.MIT.EDU, ostlund@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
In-Reply-To: Win Treese <treese@ATHENA.MIT.EDU>'s message of Wed, 13 Aug 86 13:07:08 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
It seems to me that propagating password files (and creating user
directories) several times a day is primarily a requirement that came
from general-purpose time-sharing service. After a little more
software is in place, propagation shouldn't be needed for any servers
to which general users don't log in.
The missing link is the proposed ACLS server. If we put an ACLS
service in place, the other servers can be set up to allow direct login
only by root. All other login would be Kerberos-mediated, just as on
a workstation, and restricted to those who can present an ACLS
proof-of-membership ticket in one of a small number of lists, such as
"operations" and "print-server-operators". The membership of those
lists would be managed by the ACLS server; the set of lists would
change rarely, so there would be no need for daily propagation to
run-of-the-mill servers.
This approach leaves two special cases.
1. There is one entry in the /etc/passwd file on each server:
root. Occasionally that root password must be changed. Probably a
Kerberos-mediated rcp of a new /etc/passwd is the simplest way. This
event isn't accompanied by creating a new directory, so doesn't
require such a heavy-duty mechanism as propagation. A script running
on Hector that krcp's all of these one-line server password files
sounds about right.
2. Kerberos itself should be set up in the same way, but allow
login only by root and by users delivering Kerberos-supplied tickets
that it has itself authenticated, rather than list-membership-tickets
from the ACLS. In addition, probably the Kerberos servers shouldn't
allow anyone to rcp a new /etc/passwd; their root passwords must be
changed by hand.
While waiting for an ACLS to appear, traditional propagation of
/etc/passwd files to non-Kerberos servers is probably the simplest
way to proceed, though.
Jerry
--[0053]--
\f
[0054] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (25 lines)
Subject: re: SUN RPC & XDR
From Saltzer@ATHENA.MIT.EDU Sat Aug 16 11:05:58 1986
Date: Sat, 16 Aug 86 11:02:09 EDT
Subject: re: SUN RPC & XDR
To: spm, bcn
Cc: Bill Sommerfeld <wesommer@athena.MIT.EDU>, kerberos
In-Reply-To: Bill Sommerfeld <wesommer@athena.MIT.EDU>'s message of Sat, 09 Aug 86 15:22:07 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> Since the authenticator is decyphered by the server-side library
> before the service is identifed, a catch-all "rpc" or "sunrpc"
> principal for each host involved will be needed to get this to work.
> There may be a way around this if we're not afraid to do some sort of
> "modularity violation" in the Kerberos-specific code.
Steve and Cliff,
Have you any thoughts on the right way to deal with this problem? It
comes up any time one tries to integrate Kerberos directly with the
transport level protocol rather than the service level protocol.
Jerry
--[0054]--
\f
[0055] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (67 lines)
Subject: New release
From bcn@ATHENA.MIT.EDU Tue Aug 19 21:57:25 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Tue, 19 Aug 86 19:53:53 EDT
To: geer
Subject: New release
Cc: asp, kerberos
There is a new version of kerberos available for friendly testers and
others who want it. It can be found in ~auth/src/kerberos.tar on
menelaus. As before, to use it, untar this file where you want the
new kerberos directory to go. The tar file will create the directory
for you. If you already have a local kerberos directory, delete it,
or move it before untaring the new release. Once untared, set the
symbolic link "/krb" to point to the new directory.
If you are on a workstation and don't want the .a or .h files, feel
free to delete them. It will give you back considerable space.
WARNING: if you run the old version of kinit you must use the old
verions of rlogin, rcp, etc, and vice versa. Using different versions
of these commands will result in a segmentation fault because of
(infinite recursion).
The new release provides the following:
krb.conf This file specifies your local realm on the first line
and the kerbeors servers for various realms on the
following lines. Warning: If not hosts are specified
for the default realm, kinit will time out real fast
as it "retries each of them" multiple times.
kinit no longer prints a message except for failures, or if you
specify the "-c" (confirmation) flag. It also allows you
specify a realm with the "-r" flag. This only works if
you have hosts listed in /etc/krb.conf for that realm.
kinit will also now try multiple kerberos servers if
more than one has been specified in /krb.conf.
kdestroy has a "-q" (quiet) and a "-f" (force) option. The
quiet option suppresses printing ^Gs wheras the force
option keeps it from printing anything. Also, thanks
to wesommer, kdestroy no zeroes the ticket file before
unlinking it.
klogind Assorted bug fixes.
kshd
rlogin
rcp
rsh
-----
realms Are now supported. You should not hardcode realm
names when using kerberos. You can, instead, use the
routine krb_getrlm(s,1) to write the current realm
(from krb.conf) into the string pointed to by s. The
length of this string should be REALM_SZ.
prot v4 The initial exchange of tickets now uses protocol
version 4. This limits the number of tickets
requested to 1. The change will alow the kerberos
server to be more resistant to errors since the lentgh
of its response is now bounded. The increment in
ther version number effects other exchanges as well.
Version three will be phased out and no longer
supported sometome around the 27th.
--[0055]--
\f
[0056] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (13 lines)
Subject: New version
From bcn@ATHENA.MIT.EDU Tue Aug 19 21:58:58 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Tue, 19 Aug 86 19:55:42 EDT
To: geer
Subject: New version
Cc: kerberos
Add to my previous message before forwarding it that krb.conf should
be put in /etc. Thanks.
~ Cliff
--[0056]--
\f
[0057] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (16 lines)
Subject: Re: New release
From wesommer@ATHENA.MIT.EDU Tue Aug 19 22:07:33 1986
To: bcn@athena.mit.edu
Cc: geer@athena.mit.edu
Cc: asp@athena.mit.edu, kerberos@athena.mit.edu
Subject: Re: New release
In-Reply-To: Your message of Tue, 19 Aug 86 19:53:53 EDT.
<8608192353.AA05841@MENELAUS>
Date: Tue, 19 Aug 86 21:02:53 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I assume you meant "/@/menelaus/projects/auth/kerberos.tar";
~auth/src/kerberos.tar doesn't exist..
- Bill
--[0057]--
\f
[0058] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (13 lines)
Subject: Re: New release
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Aug 20 09:24:40 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: New release
To: wesommer@ATHENA.MIT.EDU
Cc: geer@ATHENA.MIT.EDU, asp@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <8608200102.AA03825@PRIAM>
Right. /@/menelaus/projects/auth/kerberos.tar. Sorry.
~ Cliff
-------
--[0058]--
\f
[0059] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:20 (56 lines)
Subject: Kerberos authenticated RFS is workin
From wesommer@ATHENA.MIT.EDU Wed Aug 20 10:10:03 1986
To: rfs-info, kerberos
Subject: Kerberos authenticated RFS is working.
Date: Wed, 20 Aug 86 10:06:31 -0500
From: wesommer@ATHENA.MIT.EDU
I set aside last night towards making RFS and Kerberos work together.
After much hacking, quite a bit of kludging, and other work-arounds, I
managed to get it working. The code is not yet ready for "release" (it
isn't all that robust, it requires the latest Kerberos release to
work properly, and I want to keep watching the log files so I know
when it breaks...).
I managed to get it working without any kernel modifications; this
made my life a lot easier. This is possible because, although the
kernel makes the actual connection, it has no idea of the
authentication used. RFS connections (which are TCP connections) are
relatively long-lived (typically as long as a login session); when the
connection is made to the server, the server does a "call-back" to a
"mount daemon" running on the client; the mount daemon provides the
authenticators. There is a noticeable "pregnant pause" of a few
seconds while the appropriate tickets are requested, and the
authenticators encoded, shipped, and decoded.
The mount daemon does the actual calls to mk_ap_req, after consulting
the /etc/utmp file to see who's logged in. This causes a bit of a
problem, as there is no documented way to specify more than one ticket
file for an application to look at; I got around this by writing my
own tkt_string routine which returned what I thought the filename
should be for each user. I haven't gotten this reconciled with
Toehold's insistance on putting the tickets in /tmp/tkt_ttyv0 rather
than /tmp/tkt<uid>.
The other major problem was translating domain names (e.g.
PRIAM.MIT.EDU) into service fullnames (rcmd.priam@ATHENA.MIT.EDU); I
wound up breaking up the domain name around the left-most period,
lowercasifying the first part, and making the second part the realm,
unless it happened to be MIT.EDU, in which case I translated it into
ATHENA.MIT.EDU.
The new server is, surprisingly enough, somewhat smaller than the old
one while executing (with perhaps 80KB of data space as opposed to
160KB in the old version); this is because it no longer builds a
permission map out of everyone's .rhosts files on startup.
- Bill
--[0059]--
\f
[0060] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (10 lines)
Subject: Friday'
From spm@ATHENA.MIT.EDU Thu Aug 21 20:51:25 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Thu, 21 Aug 86 20:48:05 EDT
To: champine, fhsu, kerberos
Subject: Friday'
Aug 22 I will be at Athena.
--[0060]--
\f
[0061] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (68 lines)
Subject: interesting bug
From henry@ATHENA.MIT.EDU Fri Aug 22 16:54:17 1986
To: kerberos
Subject: interesting bug
Dish-Of-The-Day: Frozen Ammonia Pops
Fruit-Of-The-Day: kumquat
Home-Address: P. O. Box 1303 Kendall Square Station; Cambridge, MA 02142
Work-Address: MIT/Project Athena; E40-371; Cambridge, MA 02139
Work-Phone: (617) 253-0177
Date: Fri, 22 Aug 86 16:50:57 -0500
From: Henry Mensch <henry@ATHENA.MIT.EDU>
I've enclosed portions of two terminal sessions from two different
hosts below. Something seems scwewy!
Script started on Fri Aug 22 16:34:52 1986
42 charon /mit/h/e/henry --> date
Fri Aug 22 16:35:21 EDT 1986
43 charon /mit/h/e/henry --> /krb/kinit
MIT Project Athena, (charon)
Kerberos login: henry
Password:
44 charon /mit/h/e/henry --> man tcsh | /krb/rsh theseus "lpr -Pln03-bldge40-3"
erberos rsh or rcp failed: Ticket expired (rd_ap_req)
Kerberos rcmd failed. Tell your guru. Trying normal rsh.
45 charon /mit/h/e/henry --> date
Fri Aug 22 16:36:17 EDT 1986
46 charon /mit/h/e/henry --> /krb/kdestroy
Tickets destroyed
47 charon /mit/h/e/henry --> exit
48 charon /mit/h/e/henry -->
script done on Fri Aug 22 16:36:27 1986
(**** now I realize that charon often runs things differently
(**** so I went back to theseus and tried the same sorts of
(**** things. This is what happened:
Script started on Fri Aug 22 16:38:41 1986
42 theseus /tmp/henry --> date
Fri Aug 22 16:38:51 EDT 1986
43 theseus /tmp/henry --> kinit
MIT Project Athena, (theseus)
Kerberos login: henry
Password:
44 theseus /tmp/henry --> ls /tmp
total 58
0 #26502 1 henry
11 11-124 0 line
7 11-124d 1 list_of_keys
0 Scribe002742 20 messages
1 cur_line 1 post011503
2 first_week 9 terminal_room_filing_cabinets
4 foo 1 tkt12408
45 theseus /tmp/henry --> rsh charon "man tcsh" | lpr -Pln03-bldge40-3
erberos rsh or rcp failed: Ticket expired (rd_ap_req)
You have new mail.
46 theseus /tmp/henry --> ^charon^odyss
rsh odyss "man tcsh" | lpr -Pln03-bldge40-3
erberos rsh or rcp failed: Ticket expired (rd_ap_req)
47 theseus /tmp/henry --> date
Fri Aug 22 16:40:33 EDT 1986
48 theseus /tmp/henry --> exit
49 theseus /tmp/henry -->
script done on Fri Aug 22 16:40:46 1986
--[0061]--
\f
[0062] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (17 lines)
Subject: Kerberos/styx
From spm@ATHENA.MIT.EDU Fri Aug 22 18:05:38 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Fri, 22 Aug 86 18:02:13 EDT
To: bcn
Subject: Kerberos/styx
Cc: kerberos
I got the kinit to work, with some effort.
Had a problem with byte swapping in pkt_clen(); my macro was not
working right. So I replaced it with a "swab", and had to add another
temp.
So there is a new version of pkt_clen() on menel.
See if "hindmost" can get the other stuff to build, then we can continue
debugging it.
--[0062]--
\f
[0063] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (11 lines)
Subject: hacking at the gates of hell
From mtc@ATHENA.MIT.EDU Wed Aug 27 13:13:29 1986
To: kerberos
Cc: wdc, dm
Subject: hacking at the gates of hell
Date: Wed, 27 Aug 86 13:21:16 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
Bill Cattey proposed the development of a program to break thru the
Kerberos protection. He wants to call it "Dante".
--[0063]--
\f
[0064] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (9 lines)
Subject: Friday
From miller%erlang.DEC@decwrl.DEC.COM Thu Aug 28 14:45:07 1986
Date: 28-Aug-1986 1434
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB), dec@athena.mit.edu
Subject: Friday
I will be at Athena late morning on Friday, Aug 29.
--[0064]--
\f
[0065] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (15 lines)
Subject: Inter realm communications
From bcn@ATHENA.MIT.EDU Tue Sep 2 18:48:05 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Tue, 2 Sep 86 18:47:28 EDT
To: kerberos
Subject: Inter realm communications
I think I have the inter-realm code running in the server. It should
only take a little bit more work to get the client code to make use
of this functionality. Unfortunately, there is a problem with
rlogin, etc. It can't seem to pars a REALM entry in a .klogin file
that contains a period (such as LCS.MIT.EDU).
~ Cliff
--[0065]--
\f
[0066] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (22 lines)
Subject: realm
From spm@ATHENA.MIT.EDU Tue Sep 2 20:47:32 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Tue, 2 Sep 86 20:44:29 EDT
To: kerberos
Subject: realm
I'm pleased that Cliff has the realm stuff working in the server.
I think it would be worthwhile to extend the .klogin notion, and make it
a bit more generic. Kerberos would provide a routine, "check_auth_type_1()"
that would specify a file name, and the name, instance, and realm of the
request. The routine would read and parse the named file, and either just
return True/False, or some arbitrary string tacked onto the end of the
entry.
This is only rally having kerberos provide the parsing, doing it once,
preferably correct, and re-using it in a general fashion for any other
application that so desires. Of course, there is no requirement to use this
routine or authorization scheme.
--[0066]--
\f
[0067] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:21 (23 lines)
Subject: unimplemented features
From spm@ATHENA.MIT.EDU Tue Sep 2 21:03:56 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Tue, 2 Sep 86 21:00:51 EDT
To: kerberos
Subject: unimplemented features
Last I checked, there were two unimplemented features relating to
the protocol. The first is guaranteed replay detection. This requires
stable storage at the servers, and can be a significant performance hit.
When implemented, its use should be optional, reserved for applications
where detecting all replays is very important, e.g. cash machines.
Without the stable store, certain types of replays cannot be detected.
The second feature is the mutual authentication option. Again, this is
critical when you dont want to surrender the family jewels until you are
sure that the bank is the bank. It involves implementing a protocl message,
and modifying the interface and code to support it.
I would suggest adding these two features after the current functionality has
survived some considerable large scale use.
--[0067]--
\f
[0068] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (40 lines)
Subject: Re: Bug in rlogin, etc
From mtc@ATHENA.MIT.EDU Wed Sep 3 12:24:40 1986
To: bcn
Cc: kerberos
Subject: Re: Bug in rlogin, etc
In-Reply-To: Your message of Tue, 2 Sep 86 18:42:13 EDT.
<8609022242.AA03464@TARTAROS>
Date: Wed, 03 Sep 86 12:22:49 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
An immediate fix for your problem is to put the realm in quotes.
For example:
realm="ATHENA.MIT.EDU"
will give you the desired result.
The .klogin parsing is working as designed; similar to the C language,
a token can consist of any alphanum or '_'. Therefore,
ATHENA.MIT.EDU
is received as five tokens.
Cliff, I can easily change the rules for what constitutes a token. If
you want me to do that, tell me which of the following alternatives you
prefer. Making the change for any of these alternatives is trivial.
1. Leave as is, require quotes for tokens containing punctuation
and whitespace.
2. Allow '.' in a (non-quoted) realm token, as well as alphanums and '_'.
3. Allow '.' '_' and alphanum, and the following punctuation: (you specify)
4. Allow ANY ASCII (except comma and whitespace) to be part of a token.
mtc
--[0068]--
\f
[0069] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (19 lines)
Subject: Re: Bug in rlogin, etc
From mtc@ATHENA.MIT.EDU Wed Sep 3 13:31:53 1986
To: wesommer
Cc: kerberos
Subject: Re: Bug in rlogin, etc
Date: Wed, 03 Sep 86 13:30:55 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
from wesommer:
> How about option 4A: Allow any @i(printable) ascii other than comma
> and whitespace to be part of a token??
Okay. Actually, we're going with 4B: any printable ascii other than
comma AND EQUAL SIGN. A "printable ascii" will be >040 and <0177.
The equal sign is part of the "keyword=value" syntax.
mtc
--[0069]--
\f
[0070] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (19 lines)
Subject: Inter-realm interactctiosn work
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Sep 3 14:37:04 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Inter-realm interactctiosn work
To: kerberos@ATHENA.MIT.EDU
I just got the rest of the kerberos library to work correctly with the
inter-realm authentication. Mark claims to have fixed the problem
with the .klogin files. This leaves only one more thing to be done
for inter-realm authentication to be used. The client code for
rlogin, rcp, etc, has to be able to figure out what realm a machine is
in so that it can be passed to mk_ap_req. I will leave this to mtc
since it involves the rcmd code itself. The potential problem comes
up when trying to figure out what realm a machine in the .MIT.EDU
domain resides in. With LCS.MIT.EDU machines, it is easy.
~ Cliff
-------
--[0070]--
\f
[0071] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (25 lines)
Subject: Re: realm
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Sep 3 14:37:15 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: Re: realm
To: spm@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8609030044.AA24377@MENELAUS>
I think it would be worthwhile to extend the .klogin notion, and make it
a bit more generic. Kerberos would provide a routine, "check_auth_type_1()"
that would specify a file name, and the name, instance, and realm of the
request. The routine would read and parse the named file, and either just
return True/False, or some arbitrary string tacked onto the end of the
entry.
Isn't this what we defined an-to_ln to do? Of course, this routine
would read a single file for the entire systems instead of individual
files in a users drectory. Also, the file reading functionality is
not yet implemented. Anyway, I am not going to concern myself with
this issue until I am out in WA. I have too much to do in the next 2
days as it is.
~ Cliff
-------
--[0071]--
\f
[0072] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (22 lines)
Subject: RT kerberos library
From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU Wed Sep 3 17:21:10 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: RT kerberos library
To: kerberos@ATHENA.MIT.EDU
I managed to get a get_ad_tkt call to run successfully. This means
that mk_ap_req on the RT does in fact work. At first I got the
message "time is out of bounds" and thought it might be byte ordering,
but checking the time on STYX, it was indeed 17 hours off. rlogin,
rcp, and rsh do not work on the RT with kerberos. Brian is working on
those programs now. Also, the version of krb.h in /usr/include on
STYX is ancient, and on the RVD.
When Steve is in on Friday, we can try merging the few remaining
changes on the RT version back into the primary sources on menelaus.
For now, it looks like the RT kerberos library does work, and I plan
to spend tomorrow and Friday working on Hesiod.
~ Cliff
-------
--[0072]--
\f
[0073] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (25 lines)
Subject: Kerberos on the RT
From spm@ATHENA.MIT.EDU Fri Sep 5 16:59:49 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Fri, 5 Sep 86 16:59:00 EDT
To: kerberos
Subject: Kerberos on the RT
Cc: Lerman, Saltzer, dec
Since I had previously gotten the DES library and the "kinit" working on the
RT, and "hindmost" reports that he has had initial success with the
rcmd stuff on the RT, I believe that the RT is now ready for full scale
Kerberos testing and development (e.g. RVD). This, of course, does
not mean that it is bug free, but rather that we should start using it
and wait for bug reports.
Consequently, I will discontinue my weekly visits to Athena, and switch
to an occasional or on request mode. I can be reached at 1-486-7545,
or at mail address miller%erlang.dec@decwrl.com .
Steve.
P.S. Please do keep me informed of significant issues, either with the
protocols, operation of the system, or types of use.
--[0073]--
\f
[0074] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:22 (25 lines)
Subject: Re: realm
From spm@ATHENA.MIT.EDU Fri Sep 5 18:01:54 1986
To: bcn%deep-thought@eddie.mit.edu
Cc: spm@athena.mit.edu
Cc: kerberos@athena.mit.edu
Cc: spm@menelaus.mit.edu
Subject: Re: realm
In-Reply-To: Your message of Wed 3 Sep 86 14:21:42-EDT.
<12236033903.14.BCN@DEEP-THOUGHT.MIT.EDU>
Date: Fri, 05 Sep 86 18:02:21 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
It (check_auth_type()) is similar, but not identical to the an_to_ln(),
but semantically quite different. an_to_ln() maps from an athena Kerberos
name to a system specific name, but does not imply any authorization.
For example, it could be used to map Kerberos names into Kanji characters
in Japan! As Cliff mentioned, it could be managed by the system or some
central authority.
The check_auth_type_1() would operate on a name (Kerberos or local, by
convention), and return an authorization. This needs to be managed by
whoever is allowed to control a given service. E.g. I manipulate the
files authorizing access to my account.
--[0074]--
\f
[0075] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (11 lines)
Subject: marv
From spm@ATHENA.MIT.EDU Fri Sep 5 18:03:32 1986
From: Steve Miller <spm@ATHENA.MIT.EDU>
Date: Fri, 5 Sep 86 18:04:08 EDT
To: kerberos
Subject: marv
Who is marv@src.dev.com on the kerberos mailing list?
I am getting mail bounced back addressed to him.
--[0075]--
\f
[0076] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (20 lines)
Subject: Integrated interrealm into rcmd
From srz@athena.MIT.EDU Sun Sep 7 15:16:13 1986
From: srz@athena.MIT.EDU
Date: Sun, 7 Sep 86 15:16:29 EDT
To: mtc@athena.MIT.EDU
Subject: Integrated interrealm into rcmd
Cc: kerberos@athena.MIT.EDU
I have fixed up LCS's version of rlogin, rcp, etc. to handle
inter-realm authentication. This allows users authenticated in the
LCS realm to present tickets and login to the ATHENA realm. For this to go
the other way, the ATHENA rcmd stuff will have to be updated.
I have left sources for rlogin & rcmd in my homedir in menelaus.
In rcmd.c, I have replaced PrincipalHostname with ExpandHost, which
takes a user-specified host ("MENELAUS"), and converts it into a
principal host ("menelaus") and a kerberos realm ("ATHENA.MIT.EDU").
rlogin, rcp, etc, just need to be changed to pass the results of this
call to mk_ap_req.
--[0076]--
\f
[0077] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (15 lines)
Subject: Re: Kerberos on the RT
From geer@ATHENA.MIT.EDU Mon Sep 8 14:19:24 1986
To: spm@lyre
Cc: kerberos@lyre
Cc: lerman@lyre, saltzer@lyre, dec@lyre
Subject: Re: Kerberos on the RT
In-Reply-To: Your message of Fri, 5 Sep 86 16:59:00 EDT.
<8609052059.AA02736@LYRE>
Date: Mon, 08 Sep 86 14:17:33 -0500
From: geer@ATHENA.MIT.EDU
thank, steve, for everything. we'll keep you informed.
--dan
--[0077]--
\f
[0078] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (50 lines)
Subject: Security breakin at Stanford.
From miller%erlang.DEC@decwrl.DEC.COM Tue Sep 9 00:09:28 1986
Date: 08-Sep-1986 1707
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @[MILLER]KERB)
Subject: Security breakin at Stanford.
From: ERLANG::RONSICKI "DTN 226-7551, LKG1-2/A19" 8-SEP-1986 15:07
To: FALCONE,DICKENS,WEITHMAN,MILLER,GLASER
Subj: Massive security problem at Stanford
To: everyone
From: reid (Brian Reid)
Date: 4 Sep 1986 2209-PDT (Thursday)
Cc:
Subject: computer security
This week there was a massive computer breakin at Stanford.
Virtually every Unix computer on the campus has been penetrated.
The intruders are clearly experts: they made changes to various system
programs, recompiled them, installed the recompiled versions, and reset
the "last-write" date of the changed programs.
Even as I send this message, one of the burglars is logged in to a
certain Vax over a dialup, editing the source for "login". The police
have been unable (legally or technically, I am not certain) to trace
the phone calls, and the system managers involved have chosen to
monitor the people's activities rather than terminate the accounts that
they are using.
The breakin pattern is to break into one machine, gain root permission
there, and then fan out from that machine using ".rhosts" and
"/etc/hosts.equiv" to take over accounts on other machines. The
burglars seem to have tremendous patience: Stanford folks stopped
counting at 50 machines penetrated.
It is just a matter of time until they expand from attacking Stanford
hosts to attacking hosts nearby on the network, i.e. DEC.
There are so many ways to break into Unix systems that it's somewhat of
a pointless exercise to try to keep all the holes plugged,
but if the system managers of DEC Palo Alto machines will contact me I
will explain how the breakins happened. I just checked saturn, decwrl,
magic, clark, and eros, and all of them have this security leak.
This would be a good time to check every machine to make sure that none
of the .rhosts files on them reference host names outside DEC.
Brian
--[0078]--
\f
[0079] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (16 lines)
Subject: is this kerberos?
From geer@ATHENA.MIT.EDU Wed Sep 10 08:28:45 1986
From: Dan Geer <geer@ATHENA.MIT.EDU>
Date: Wed, 10 Sep 86 08:27:20 EDT
To: kerberos
Subject: is this kerberos?
when starting my various windows and rsh xterms, i often find
client: All ports in use
and some windows will fail to appear. is this kerberos server
congestion in some way?
--dan
--[0079]--
\f
[0080] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (11 lines)
Subject: kinit password length
From spm@ATHENA.MIT.EDU Wed Sep 10 21:23:39 1986
To: kerberos
Subject: kinit password length
Date: Wed, 10 Sep 86 21:21:47 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
(menelaus /usr/local/kinit ) still breaks with a long password.
Breaks meaning doesnt work right, rejecting the password.
--[0080]--
\f
[0081] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (12 lines)
Subject: Re: kinit password length
From srz@athena.MIT.EDU Wed Sep 10 22:25:23 1986
From: srz@athena.MIT.EDU
Date: Wed, 10 Sep 86 22:24:09 EDT
To: spm@ATHENA.MIT.EDU
Subject: Re: kinit password length
Cc: kerberos@athena.MIT.EDU
On what principal is this losing on? It seems to work ok on the
LCS realm. Was this set with passwd? passwd loses on new passwords that
are too long.
--[0081]--
\f
[0082] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:23 (19 lines)
Subject: Re: kinit password length
From spm@ATHENA.MIT.EDU Thu Sep 11 20:57:22 1986
To: srz@athena.mit.edu
Cc: kerberos@athena.mit.edu
Subject: Re: kinit password length
In-Reply-To: Your message of Wed, 10 Sep 86 22:24:09 EDT.
<8609110224.AA12188@CHARON>
Date: Thu, 11 Sep 86 20:55:39 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
I changed my password with the new Athena/Kerberos passwd command, then
kinit didnt work with the new 10char passwd.
Steve.
--[0082]--
\f
[0083] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (13 lines)
Subject: Re: kinit password length
From srz@athena.MIT.EDU Thu Sep 11 22:24:44 1986
From: srz@athena.MIT.EDU
Date: Thu, 11 Sep 86 22:23:18 EDT
To: spm@ATHENA.MIT.EDU
Subject: Re: kinit password length
Cc: kerberos@athena.MIT.EDU
The problem is with passwd, unless somebody has fixed it. Cliff was having
the same problem when he used passwd to set his LCS password.
-stan
--[0083]--
\f
[0084] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (19 lines)
Subject: Re: kinit password length
From ostlund@ATHENA.MIT.EDU Thu Sep 11 23:11:32 1986
From: ostlund@ATHENA.MIT.EDU
Date: Thu, 11 Sep 86 23:08:25 EDT
To: spm@ATHENA.MIT.EDU, srz@athena.MIT.EDU
Subject: Re: kinit password length
Cc: kerberos@athena.MIT.EDU
The present (installed on Athena 750's) /bin/passwd only accepts 8 character
passwords. The revised edition (tested, soon to be released to the
Athena staff cluster) accepts 40 character passwords, of which the first
eight are handed to UNIX crypt(3) and stuffed into athenareg as the
encrypted UNIX password. (This version also will work on VS2's and
RT's.) For the moment, passwords longer than 8 characters won't
work.
John
--[0084]--
\f
[0085] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (30 lines)
Subject: Re: is this kerberos?
From ostlund@ATHENA.MIT.EDU Fri Sep 12 15:34:46 1986
From: ostlund@ATHENA.MIT.EDU
Date: Fri, 12 Sep 86 13:39:38 EDT
To: kerberos
Subject: Re: is this kerberos?
From geer@ATHENA.MIT.EDU Wed Sep 10 08:28:15 1986
To: kerberos@ATHENA.MIT.EDU
Subject: is this kerberos?
when starting my various windows and rsh xterms, i often find
client: All ports in use
and some windows will fail to appear. is this kerberos server
congestion in some way?
--dan
-------------
The answer, I think, is yes. Now that userreg is finally done, I'm
planning to dive pretty much exclusively into Kerberos for a while.
I hope I can answer this and other questions within the next week
or so.
John
--[0085]--
\f
[0086] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (21 lines)
Subject: New control arguments for rlogin,rsh
From jis@BITSY.MIT.EDU Sat Sep 13 21:27:24 1986
Date: Sat, 13 Sep 86 21:26:43 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: kerberos@athena.mit.edu
Subject: New control arguments for rlogin,rsh and rcp
I have checked new versions of rcp.c, rlogin.c and rsh.c into
~auth/src/services/rcmd on menelaus. These updated programs
support the "-k" control argument to specify a different realm
then the one your machine is in. Ie. with them you can do the
following:
rlogin borax.lcs.mit.edu -k LCS.MIT.EDU
which will "do the right thing" about negotiating with the various
kerberi. Note: If you install these programs be sure to install the
current "kinit" from ~auth on menelaus as well or else they will
not operate at all!
-Jeff
--[0086]--
\f
[0087] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (23 lines)
Subject: New control arguments for rlogin,rsh
From wesommer@ATHENA.MIT.EDU Sat Sep 13 22:45:11 1986
Date: Sat, 13 Sep 86 21:26:43 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: kerberos@athena.mit.edu
Subject: New control arguments for rlogin,rsh and rcp
Sender: wesommer@ATHENA.MIT.EDU
I have checked new versions of rcp.c, rlogin.c and rsh.c into
~auth/src/services/rcmd on menelaus. These updated programs
support the "-k" control argument to specify a different realm
then the one your machine is in. Ie. with them you can do the
following:
rlogin borax.lcs.mit.edu -k LCS.MIT.EDU
which will "do the right thing" about negotiating with the various
kerberi. Note: If you install these programs be sure to install the
current "kinit" from ~auth on menelaus as well or else they will
not operate at all!
-Jeff
--[0087]--
\f
[0088] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (52 lines)
Subject: knetd (formerly Ksetup)
From jtkohl@ATHENA.MIT.EDU Tue Sep 16 10:52:26 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Tue, 16 Sep 86 10:45:30 EDT
To: kerberos
Subject: knetd (formerly Ksetup)
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
Dan Geer has asked me to work on the proposed Ksetup daemon (which I
would like to rename knetd, for reasons below) and circulate a brief
design spec for it.
The design Jerry proposed has an extra overhead of two messages per
connection, since the client would talk to a kerberos server and then to
the desired server.
I propose eliminating the extra message pair by the following scheme:
knetd, similar in fashion to inetd, will act as a "multiplexor" to the
various kerberos authenticated services.
It will listen to one well-known port for tcp and udp connections. When
a client wishes to connect to an authenticated server, it connects first
to the knetd. The first message is the name (in suitable form) of the
service the client wishes to use.
The knetd correlates this name with a table (of the form maintained by
/etc/inetd) and forks off the appropriate server, with appropriate
arguments such that it realizes it is connected to a kerberos-speaking
client. The server takes whatever authentication and/or authorization
steps it deems necessary. (There are already routines in use by the
login and rcmd protocols which do the grunge work of verifying the
authenticity of a client, so development of the is_this_one_ok()
authorization routine would not be necessary). This has the added
benefit that the existing kerberos servers need not be changed
drastically to accomodate this scenario (they might need a few minor
changes regarding releasing the socket back to the knetd). We would
already need to modify the server's code to allow kerberos
authentication under the Ksetup scenario, so we are not losing ease of
conversion by using knetd. We can also avoid allocating more well-known
ports for new services (if desired) by having them connect through knetd.
This table can be maintained simultaneously with /etc/srvtab and
/etc/inetd.conf.
To cover the problem of people who should use kerberos who are trying to
avoid it by using the old existing protocols, an address filter (similar
to the one used by the userinfod) can be devised to insure they are not
circumventing authentication.
Comments?
--[0088]--
\f
[0089] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:24 (294 lines)
Subject: perhaps of interest ...
From henry@ATHENA.MIT.EDU Wed Sep 17 12:11:57 1986
To: kerberos
Subject: perhaps of interest ...
Date: Wed, 17 Sep 86 10:08:35 -0500
From: Henry Mensch <henry@ATHENA.MIT.EDU>
some time ago <spm> forwarded a message from Brian Reid at Stanford
describing some large-scale breakins to Unix hosts on that campus.
More on details on this are to be found in the message below.
-- henry / <henry@athena.mit.edu>
------- Forwarded Message
Return-Path: NEUMANN@CSL.SRI.COM
Received: by THESEUS (5.45/4.7)
id AA01476; Wed, 17 Sep 86 05:50:15 EDT
Received: by ATHENA (5.45/4.7)
id AA04363; Wed, 17 Sep 86 05:49:56 EDT
Message-Id: <8609170949.AA04363@ATHENA>
Date: Tue 16 Sep 86 15:40:35-PDT
From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@CSL.SRI.COM>
Subject: RISKS-3.56
Sender: NEUMANN@CSL.SRI.COM
To: RISKS-LIST@CSL.SRI.COM
RISKS-LIST: RISKS-FORUM Digest, Tuesday, 16 September 1986 Volume 3 : Issue 56
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Massive UNIX breakins at Stanford (Brian Reid)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
(Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM)
(Back issues Vol i Issue j available in CSL.SRI.COM:<RISKS>RISKS-i.j.
Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.)
- ----------------------------------------------------------------------
From: reid@decwrl.DEC.COM (Brian Reid)
Date: 16 Sep 1986 1519-PDT (Tuesday)
To: Peter G. Neumann <Neumann@csl.sri.com> [FOR RISKS]
Subject: Massive UNIX breakins at Stanford
Lessons learned from a recent rash of Unix computer breakins
Introduction
A number of Unix computers in the San Francisco area have
recently been plagued with breakins by reasonably talented
intruders. An analysis of the breakins (verified by a telephone
conversation with the intruders!) show that the networking
philosophy offered by Berkeley Unix, combined with the human
nature of systems programmers, creates an environment in which
breakins are more likely, and in which the consequences of
breakins are more dire than they need to be.
People who study the physical security of buildings and military
bases believe that human frailty is much more likely than
technology to be at fault when physical breakins occur. It is
often easier to make friends with the guard, or to notice that he
likes to watch the Benny Hill show on TV and then wait for that
show to come on, than to try to climb fences or outwit burglar
alarms.
Summary of Berkeley Unix networking mechanism:
The user-level networking features are built around the
principles of "remote execution" and "trusted host". For example,
if you want to copy a file from computer A to computer B, you
type the command
rcp A:file B:file
If you want to copy the file /tmp/xyz from the computer that you
are now using over to computer C where it will be called
/usr/spool/breakin, you type the command
rcp /tmp/xyz C:/usr/spool/breakin
The decision of whether or not to permit these copy commands is
based on "permission" files that are stored on computers A, B,
and C. The first command to copy from A to B will only work if
you have an account on both of those computers, and the
permission file stored in your directory on both of those
computers authorizes this kind of remote access.
Each "permission file" contains a list of computer names and user
login names. If the line "score.stanford.edu reid" is in the
permission file on computer "B", it means that user "reid" on
computer "score.stanford.edu" is permitted to perform remote
operations such as rcp, in or out, with the same access
privileges that user "reid" has on computer B.
How the breakins happened.
One of the Stanford campus computers, used primarily as a mail
gateway between Unix and IBM computers on campus, had a guest
account with user id "guest" and password "guest". The intruder
somehow got his hands on this account and guessed the password.
There are a number of well-known security holes in early releases
of Berkeley Unix, many of which are fixed in later releases.
Because this computer is used as a mail gateway, there was no
particular incentive to keep it constantly up to date with the
latest and greatest system release, so it was running an older version
of the system. The intruder instantly cracked "root" on that
computer, using the age-old trojan horse trick. (He had noticed
that the guest account happened to have write permission into a
certain scratch directory, and he had noticed that under certain
circumstances, privileged jobs could be tricked into executing
versions of programs out of that scratch directory instead of out
of the normal system directories).
Once the intruder cracked "root" on this computer, he was able to
assume the login identity of everybody who had an account on that
computer. In particular, he was able to pretend to be user "x" or
user "y", and in that guise ask for a remote login on other
computers. Sooner or later he found a [user,remote-computer] pair
for which there was a permission file on the other end granting
access, and now he was logged on to another computer. Using the
same kind of trojan horse tricks, he was able to break into root
on the new computer, and repeat the process iteratively.
In most cases the intruder left trojan-horse traps behind on
every computer that he broke into, and in most cases he created
login accounts for himself on the computers that he broke into.
Because no records were kept, it is difficult to tell exactly how
many machines were penetrated, but the number could be as high as
30 to 60 on the Stanford campus alone. An intruder using a
similar modus operandi has been reported at other installations.
How "human nature" contributed to the problem
The three technological entry points that made this intrusion
possible were:
* The large number of permission files, with entirely
too many permissions stored in them, found all over the campus
computers (and, for that matter, all over the ARPAnet).
* The presence of system directories in which users have write
permission.
* Very sloppy and undisciplined use of search paths in privileged
programs and superuser shell scripts.
Permissions: Berkeley networking mechanism encourages carelessness.
The Berkeley networking mechanism is very very convenient. I use
it all the time. You want to move a file from one place to
another? just type "rcp" and it's there. Very fast and very
efficient, and quite transparent. But sometimes I need to move a
file to a machine that I don't normally use. I'll log on to that
machine, quickly create a temporary permission file that lets me
copy a file to that machine, then break back to my source machine
and type the copy command. However, until I'm quite certain that
I am done moving files, I don't want to delete my permission file
from the remote end or edit that entry out of it. Most of us use
display editors, and oftentimes these file copies are made to
remote machines on which the display editors don't always work
quite the way we want them to, so there is a large nuisance
factor in running the text editor on the remote end. Therefore
the effort in removing one entry from a permission file--by
running the text editor and editing it out--is high enough that
people don't do it as often as they should. And they don't want
to *delete* the permission file, because it contains other
entries that are still valid. So, more often than not, the
permission files on rarely-used remote computers end up with
extraneous permissions in them that were installed for a
one-time-only operation. Since the Berkeley networking commands
have no means of prompting for a password or asking for the name
of a temporary permission file, everybody just edits things into
the permanent permission file. And then, of course, they forget
to take it out when they are done.
Write permission in system directories permits trojan horse attacks.
All software development is always behind schedule, and
programmers are forever looking for ways to do things faster. One
convenient trick for reducing the pain of releasing new versions
of some program is to have a directory such as /usr/local/bin or
/usr/stanford/bin or /usr/new in which new or locally-written
versions of programs are kept, and asking users to put that
directory on their search paths. The systems programmers then
give themselves write access to that directory, so that they can
intall a new version just by typing "make install" rather than
taking some longer path involving root permissions. Furthermore,
it somehow seems more secure to be able to install new software
without typing the root password. Therefore it is a
nearly-universal practice on computers used by programmers to
have program directories in which the development programmers
have write permission. However, if a user has write permission in
a system directory, and if an intruder breaks into that user's
account, then the intruder can trivially break into root by using
that write permission to install a trojan horse.
Search paths: people usually let convenience dominate caution.
Search paths are almost universally misused. For example, many
people write shell scripts that do not specify an explicit search
path, which makes them vulnerable to inheriting the wrong path.
Many people modify the root search path so that it will be
convenient for systems programmers to use interactively as the
superuser, forgetting that the same search path will be used by
system maintenance scripts run automatically during the night.
It is so difficult to debug failures that are caused by incorrect
search paths in automatically-run scripts that a common "repair"
technique is to put every conceivable directory into the search
path of automatically-run scripts. Essentially every Unix
computer I have ever explored has grievous security leaks caused
by underspecified or overlong search paths for privileged users.
Summary conclusion: Wizards cause leaks
The people who are most likely to be the cause of leaks are
the wizards. When something goes wrong on a remote machine, often
a call goes in to a wizard for help. The wizard is usually busy
or in a hurry, and he often is sloppier than he should be with
operations on the remote machine. The people who are most likely
to have permission files left behind on stray remote machines are
the wizards who once offered help on that machine. But, alas,
these same wizards are the people who are most likely to have
write access to system directories on their home machines,
because it seems to be in the nature of wizards to want to
collect as many permissions as possible for their accounts. Maybe
that's how they establish what level of wizard that they are. The
net result is that there is an abnormally high probability that
when an errant permission file is abused by an intruder, that it
will lead to the account of somebody who has an unusually large
collection of permissions on his own machine, thereby making it
easier to break into root on that machine.
Conclusions.
My conclusions from all this are these:
* Nobody, no matter how important, should have write permission
into any directory on the system search path. Ever.
* Somebody should carefully re-think the user interface of the
Berkeley networking mechanisms, to find ways to permit people to
type passwords as they are needed, rather than requiring them to
edit new permissions into their permissions files.
* The "permission file" security access mechanism seems
fundamentally vulnerable. It would be quite reasonable
for a system manager to forbid the use of them, or to
drastically limit the use of them. Mechanized checking is
easy.
* Programmer convenience is the antithesis of security, because
it is going to become intruder convenience if the programmer's
account is ever compromised. This is especially true in
setting up the search path for the superuser.
Lament
I mentioned in the introduction that we had talked to the
intruders on the telephone. To me the most maddening thing about
this intrusion was not that it happened, but that we were unable
to convince any authorities that it was a serious problem, and
could not get the telephone calls traced. At one point an
intruder spent 2 hours talking on the telephone with a Stanford
system manager, bragging about how he had done it, but there was
no way that the call could be traced to locate him. A few days
later, I sat there and watched the intruder log on to one
Stanford comptuer, and I watched every keystroke that he typed on
his keyboard, and I watched him break in to new directories, but
there was nothing that I could do to catch him because he was
coming in over the telephone. Naturally as soon as he started to
do anything untoward I blasted the account that he was using and
logged him off, but sooner or later new intruders will come
along, knowing that they will not be caught because what they are
doing is not considered serious. It isn't necessarily serious,
but it could be. I don't want to throw such people in jail,
and I don't want to let them get away either. I just want to
catch them and shout at them and tell them that they are being
antisocial.
Brian Reid
DEC Western Research and Stanford University
- ------------------------------
End of RISKS-FORUM Digest
************************
- -------
------- End of Forwarded Message
--[0089]--
\f
[0090] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (18 lines)
Subject: Re: knetd
From jis@BITSY.MIT.EDU Wed Sep 17 16:43:22 1986
Date: Wed, 17 Sep 86 16:41:57 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: kerberos@athena.mit.edu
Subject: Re: knetd
I agree with John's approach. It makes sense to have a knetd daemon
which gobbles down an ascii service name and authenication strings
and passes this information on (via a standard calling convention) to
a spawned service process. The spawned processes could then use
rd_ap_req() on the authenicant (as they do today) to determine whether
or not the authenication is valid (though it is still up to the server
to decide AUTHORIZATION issues, ie. whether or not it will in fact grant
the service).
-Jeff
--[0090]--
\f
[0091] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (17 lines)
Subject: Re: knetd
From srz@athena.MIT.EDU Wed Sep 17 17:27:03 1986
From: srz@athena.MIT.EDU
Date: Wed, 17 Sep 86 17:25:20 EDT
To: jis@BITSY.MIT.EDU
Subject: Re: knetd
Cc: kerberos@athena.MIT.EDU
Why not have knetd do the rd_ap_req, and just send the authentication
information to the subprocess via argv? This would keep the individual
programs from calling Kerberos, or even require them to run as root
(although some of the services need it for other reasons).
I don't see the use of using knetd if all it does is demultiplexing
different kerberos protocols. That's what inetd for.
-stan
--[0091]--
\f
[0092] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (45 lines)
Subject: Re: knetd
From Saltzer@ATHENA.MIT.EDU Wed Sep 17 23:50:08 1986
Date: Wed, 17 Sep 86 23:31:46 EDT
To: kerberos@athena.MIT.EDU
Subject: Re: knetd
In-Reply-To: <srz@athena.MIT.EDU>'s message of Wed, 17 Sep 86 17:25:20 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Before getting in too deep on knetd, let's review the fundamental
goals of the original ksetup proposal. There were two, both related
to integrating preexisting services with Kerberos as painlessly as
possible:
1. To stop in its tracks the approach of adding a new well-known
port for every old protocol that we adapt to Kerberos.
2. To allow the old protocol to operate without change in its
specification and with a minimum change in its implementation.
The knetd proposal meets goal number 1 beautifully: we add one new
well-known port for knetd and never again raise the issue of defining
more well-known ports.
Goal 2 is not so obviously met by the present knetd proposal. In the
case of UDP protocols, I don't see any way to preserve an old
protocol unchanged and at the same time avoid the extra two packets
for setup.
The suggestion by Stan that knetd should complete the authentication
on the spot and report the authenticated identity of its invoker to
the called subprocess as an extra argument sounds like it advances
the goal of minimizing the impact on old implementations.
And having a separate knetd.conf and inetd.conf is a nice
compatibility win, because a site can decide, for example, to stop
accepting non-kerberos-authenticated rlogins simply by removing
rlogin from inetd.conf. (Assuming that the client strategy for
kerberos-mediated rlogin is to attempt a knetd connection, and if it
is rejected simply invoke the old rlogin command, which will try the
inetd connection.)
Jerry
--[0092]--
\f
[0093] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (22 lines)
Subject: Re: knetd
From jtkohl@ATHENA.MIT.EDU Thu Sep 18 12:52:45 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Thu, 18 Sep 86 12:50:33 EDT
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@athena.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Wed, 17 Sep 86 23:31:46 EDT
Subject: Re: knetd
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
Do we want the server to be able to see the kerberos authentication
ticket for its own purposes? If not, it makes sense for the knetd to do
the decoding. If so, I don't see an easy way to achieve it.
I don't like the idea of maintaining a table on disk of what connections
are currently "OK", mainly because it opens another possible window of
opportunity for breaching kerberos security.
John
--[0093]--
\f
[0094] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (24 lines)
Subject: Re: knetd
From Saltzer@ATHENA.MIT.EDU Thu Sep 18 15:21:44 1986
Date: Thu, 18 Sep 86 15:18:20 EDT
To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Subject: Re: knetd
Cc: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>, kerberos@athena.MIT.EDU
In-Reply-To: John T Kohl <jtkohl@ATHENA.MIT.EDU>'s message of Thu, 18 Sep 86 12:50:33 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Isn't the original ticket in /tmp? If so, and if the server is smart
enough to know that there is more information of interest, it can
include a copy of the kerberos library routines, which know where to
look for the original ticket. I would guess that most old protocols
would be satisfied to be called with a parameter giving the
(authenticated) name of their client.
Jerry
--[0094]--
\f
[0095] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (36 lines)
Subject: Re: knetd
From wesommer@ATHENA.MIT.EDU Thu Sep 18 15:36:51 1986
To: saltzer@athena.mit.edu
Cc: kerberos@athena.mit.edu
Subject: Re: knetd
In-Reply-To: Your message of Thu, 18 Sep 86 15:18:20 EDT.
<8609181918.AA24932@HERACLES>
Date: Thu, 18 Sep 86 15:34:39 -0500
From: wesommer@ATHENA.MIT.EDU
The original *ticket* is in /tmp/tkt_[foo] on the client side of the
connection, and thus is inaccessible from the server side (unless, of
course, the client is running some sort of file server and the ticket
file is readable to the server.... something which shouldn't happen).
The ticket is rather sensitive information; it permits anyone who
possesses it to impersonate the principal who owns it for one
particular instance of a service. Therefore, it does not leave the
workstation.
The *authenticator* (built with mk_ap_req from the ticket file) passed
over is usually kept only in the address space of the server process.
It is only valid from one internet address, for one user, for about
five minutes (+/- clock skew).
Passing the authenticated name to the server process should be done
carefully; there should not be any way for randoms executing processes
on the server (which, under many circumstances, will be a timesharing
machine to some extent) to spoof the server process by calling it with
a forged principal name; in particular, the process recieving the name
should probably verify that it was invoked by a root process (if the
daemon happens to be set-uid), and that it happens to be connected on
an internet domain socket to the host where the user was coming from.
- Bill
--[0095]--
\f
[0096] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:25 (32 lines)
Subject: Re: knetd
From Saltzer@ATHENA.MIT.EDU Thu Sep 18 16:58:06 1986
Date: Thu, 18 Sep 86 16:54:11 EDT
Subject: Re: knetd
To: wesommer@ATHENA.MIT.EDU
Cc: saltzer@athena.mit.edu, kerberos@athena.mit.edu
In-Reply-To: wesommer@ATHENA.MIT.EDU's message of Thu, 18 Sep 86 15:34:39 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
oops. obviously.
Back to the original proposal:
1. knetd swallows the authenticator and places in /etc/ a
root-writeable-anyone-readable table that lists (user identity,
service, ip address, expiration time) 4-tuples that have been
authenticated.
2. knetd invokes the appropriate server. The server runs what it
thinks is the standard protocol with the client.
3. When the client declares its claimed identity via the standard
protocol, the server asks is_this_one_ok by calling a subroutine that
looks to see if the claimed identity is actually in the table.
I think that may help remove the need for server to make sure they
are invoked by root processes. (Instead, they probably need check to
make sure that the table is still writeable only by root!)
Jerry
--[0096]--
\f
[0097] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:26 (27 lines)
Subject: Re: knetd
From jtkohl@ATHENA.MIT.EDU Thu Sep 18 17:06:26 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Thu, 18 Sep 86 17:04:18 EDT
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@athena.mit.edu
In-Reply-To: Jerome H. Saltzer's message of Thu, 18 Sep 86 16:54:11 EDT
Subject: Re: knetd
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
Maybe I'm just paranoid, but I don't trust the security of such a table.
It is just asking for impersonation.
Consider someone who breaks root on a server machine. He can then
impersonate whomever he chooses by writing to the table appropriately.
If there is no such table, he cannot authenticate himself to kerberos
and impersonate someone without other breaches.
John
--[0097]--
\f
[0098] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:26 (22 lines)
Subject: Re: knetd
From wesommer@ATHENA.MIT.EDU Thu Sep 18 17:21:40 1986
To: saltzer@athena.mit.edu
Cc: kerberos
Subject: Re: knetd
In-Reply-To: Your message of Thu, 18 Sep 86 16:54:11 EDT.
<8609182054.AA26039@HERACLES>
Date: Thu, 18 Sep 86 17:19:27 -0500
From: wesommer@ATHENA.MIT.EDU
I would have the table say:
user identity, service identity, ip addr, expiration time, checksum
(the checksum is the 32 bit protected number in the authenticator,
which is useful for some protocols). There would have to be some way
to have entries deleted from the table, both at expiration time and
before that (currently, the authenticators are transient, and
disappear when the connections break).
- Bill
--[0098]--
\f
[0099] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:26 (19 lines)
Subject: Re: knetd
From Saltzer@ATHENA.MIT.EDU Thu Sep 18 23:57:57 1986
Date: Thu, 18 Sep 86 23:37:35 EDT
Subject: Re: knetd
To: wesommer@ATHENA.MIT.EDU
Cc: saltzer@athena.mit.edu, kerberos@ATHENA.MIT.EDU
In-Reply-To: wesommer@ATHENA.MIT.EDU's message of Thu, 18 Sep 86 17:19:27 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Bill's suggestion is only one step short of putting the entire
received authenticator in the table, so that a Kerberos library
routine buried in the server process can extract anything needed,
with security, so long as it does it before the authenticator
expires.
Jerry
--[0099]--
\f
[0100] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (19 lines)
Subject: knetd and the proposed table
From jtkohl@ATHENA.MIT.EDU Sat Sep 20 18:07:15 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Sat, 20 Sep 86 18:05:51 EDT
To: kerberos
Subject: knetd and the proposed table
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
I dislike the idea of putting authentication information into a disk
file, because it raises the probability of successful impersonation.
I will not object to using this scheme if I am convinced (by you guys)
that it is sufficiently secure not to worry about.
Any arguments on the security of such a setup?
John
--[0100]--
\f
[0101] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (34 lines)
Subject: Re: knetd
From jis@BITSY.MIT.EDU Sun Sep 21 19:37:28 1986
Date: Sun, 21 Sep 86 19:36:40 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: kerberos@athena.mit.edu
Subject: Re: knetd
I think it is pointless to build a table for known
authenicated connections consider:
Since we first started talking about this proposal, we have
haired it up quite considerably, what that table would have to look
like, and how it would have to be read (ie. you cannot trust the
table, so you have to make sure it is still root-only writable). Well
it is pretty obvious if you go with this approach that you will have
to provide a subroutine call that does all this work for you... BUT WE
ALREADY HAVE ONE it is called RD_AP_REQ. If you have to edit a server
program at all (ie. to add the subroutine call that fetches the
authenication from a table) then you might as well add the call to
RD_AP_REQ.
There is also another piece of information that rd_ap_req
gives you that hasn't been mentioned yet, that is the session key that
is associated with a ticket, and is provided by the authenicator. You
obviously don't want to leave this key in a readable place!
What is the objection to using rd_ap_req? It is really the
only subroutine that has to be used by a service (there is an issue of
security having to do with non-trusted services all having to be able
to read /etc/srvtab, but that can be corrected by spliting /etc/srvtab
up into several separate files....).
-Jeff
--[0101]--
\f
[0102] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (27 lines)
Subject: re: knetd
From spm@ATHENA.MIT.EDU Mon Sep 22 21:36:43 1986
To: kerberos
Subject: re: knetd
Date: Mon, 22 Sep 86 21:30:16 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
After being away for a week, I read all the notes re knetd.
I agree with Jerry's goals of minimizing new well known ports and
the disruption to existing protocols.
Knetd could clearly address the new ports issue simply, while not
requiring any extra tables (other than the knetd) on the server.
From there, I am in closest agreement with Jeff, that is, embed
the existing rd_ap_req() in the Kerberos versions of the protocols.
As far as relative security is concerned:
a) If you have root access to a server, all bets are off regardless
of whether or not Kerberos is involved, extra tables are involved,
etc.
b) A two-stage approach, where you first authenticate to knetd,
then invoke "is_this_one_ok()" is somewhat less secure, in that
you have opened a time window for impersonation of the client.
Steve.
--[0102]--
\f
[0103] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (83 lines)
Subject: simpler approach to RVD-kerberos in
From Saltzer@ATHENA.MIT.EDU Sat Sep 27 12:11:25 1986
Date: Sat, 27 Sep 86 12:09:38 EDT
To: kerberos, rvd-info, yba
Subject: simpler approach to RVD-kerberos integration
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
John Ostlund, Jim Van Sciver, and I have been going over a strategy
to simplify the integration of RVD with Kerberos, and I think we now
have a complete and consistent simpler proposal.
The idea is to focus on the goal for initial integration: The first
goal isn't to increase RVD security, it is to simplify administration
and use by replacing a password-per-spinup interface with one based
on a password at login time. This proposal effectively does that
simplification but only for what will be the most common and
hard-to-administer case, the student locker.
At the same time, we need to finesse the temporary lack of an Access
Control List Service. With this proposal, when that service is
available, a second round of minor changes to RVD will lead to both
better function and better security.
The idea is to make just one change right now: activate the "owner"
field associated with each pack at the server. A new RVD packet
type, "authenticated-spinup", is defined; it looks just like ordinary
spinup but it contains an authenticated Kerberos ticket instead of a
password. The server uses the standard Kerberos library routines to
examine the ticket and extract the Athena user name. If this user
name matches the name found in the "owner" field, the spinup request
is honored. If not, it isn't.
In addition, no change is made to the server's action on receiving an
old-fashioned spinup packet. It extracts the password field of the
packet and compares it with the appropriate password field of the
pack data, which we continue to maintain.
The client spinup command now behaves as follows: Try to obtain a
Kerberos ticket for RVD service. If it is obtainable, ask the client
driver to send an "authenticated-spinup". If that succeeds, carry
on. If it doesn't (or a Kerberos ticket wasn't obtainable) the
command tries an ordinary spinup sequence, prompting for a password
if necessary, just as is done now. [Tuneup: If, on an
authenticated-spinup request that fails the owner test, the server
goes ahead and checks for a null password in the pack data, and allows
the spinup, it could save the client the extra round of interaction
currently used to discover the need for a password.]
Administration of student lockers would be done by creating packs
with the name of the owner as the owner, and with random strings as
passwords. I would be inclined not to even admit the existence of
the random strings, so as not to encourage the procedure of
exchanging files by exchanging passwords; the ability to allow
someone else spinup access is better postponed till we have an ACLS
and can do it appropriately.
System library packs would continue to operate as now, with some
operations or system engineering id being owner, a null password for
read access, and a password known to both operations and system
engineering for update access. Managing those passwords is two
orders of magnitude less hassle than trying to do it for all
students. The same is less true for class library packs, but I think
hand administration will still work there, at least until we can
field an ACLS.
Two more loose ends: Operations and administration would still be
accomplished with passwords, as at present; but now is the time to
separate those two functions. And finally, the change to encrypt the
passwords found in the RVD data base should now be made. Steve
Miller's high-performance DES one-way-encipherment will be used
rather than the more majestically paced Unix algorithm.
When the ACLS server becomes available, a second round of changes
would be made: the server would accept ACLS membership certification
tickets as well as Kerberos tickets; all password fields would be
replaced by list or user names, and operations and administrative
operations would be done by supplying tickets.
Comments?
Jerry
--[0103]--
\f
[0104] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (38 lines)
Subject: Re: simpler approach to RVD-kerberos
From rlk@ATHENA.MIT.EDU Sat Sep 27 14:13:31 1986
Date: Sat, 27 Sep 86 14:12:00 EDT
From: Robert L. Krawitz <rlk@ATHENA.MIT.EDU>
Sender: rlk@ATHENA.MIT.EDU
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, rvd-info@ATHENA.MIT.EDU, yba@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sat, 27 Sep 86 12:09:38 EDT
Subject: Re: simpler approach to RVD-kerberos integration
Date: Sat, 27 Sep 86 12:09:38 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Administration of student lockers would be done by creating packs
with the name of the owner as the owner, and with random strings as
passwords. I would be inclined not to even admit the existence of
the random strings, so as not to encourage the procedure of
exchanging files by exchanging passwords; the ability to allow
someone else spinup access is better postponed till we have an ACLS
and can do it appropriately.
Hiding that sort of information is useless. For something as vital as
sharing information, people will learn how sooner or later. How are
people going to share files under these circumstances? By the obvious
expedient of giving out their password.
Comments?
Why not allow people to specify a different password for r/o spinup,
and use the same sort of procedure? Then people at least don't have
to give out their login password just to give other people the [bogus]
sort of access that r/o spinup allows?
[I won't except by this reference rehash the old arguments about rvd
lockers. As usual, the entire flame can be found in
/@/priam/mit/r/l/rlk/Rmail/rvdwars.]
Robert^Z
--[0104]--
\f
[0105] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:28 (34 lines)
Subject: Re: simpler approach to RVD-kerberos
From Saltzer@ATHENA.MIT.EDU Sat Sep 27 19:04:58 1986
Date: Sat, 27 Sep 86 19:02:55 EDT
To: Robert L. Krawitz <rlk@ATHENA.MIT.EDU>
Subject: Re: simpler approach to RVD-kerberos integration
Cc: rlk@ATHENA.MIT.EDU, Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>,
kerberos@ATHENA.MIT.EDU, rvd-info@ATHENA.MIT.EDU, yba@ATHENA.MIT.EDU
In-Reply-To: Robert L. Krawitz <rlk@ATHENA.MIT.EDU>'s message of Sat, 27 Sep 86 14:12:00 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> How are
> people going to share files under these circumstances? By the obvious
> expedient of giving out their password.
I agree, that is probably what will happen. To forestall it, see below.
> Why not allow people to specify a different password for r/o spinup,
> and use the same sort of procedure? Then people at least don't have
> to give out their login password just to give other people the [bogus]
> sort of access that r/o spinup allows?
That is allowed by the existing machinery in the RVD server; the only
hitch is providing an administrative mechanism to do the change to
the database. The missing piece is an interface to the database
stored on Hector to make the change permanent. We can add that as
soon as someone gets time to code it, without touching the server.
What I would rather do is quickly design and code a simple Access
Control List server and interface so people can set their own ACL's.
We need it anyway, for all services including NFS export control.
Jerry
--[0105]--
\f
[0106] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (60 lines)
Subject: Re: simpler approach to RVD-kerberos
From jis@BITSY.MIT.EDU Sun Sep 28 10:57:57 1986
Date: Sun, 28 Sep 86 10:57:07 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: rlk@ATHENA.MIT.EDU, Robert L. Krawitz <rlk@ATHENA.MIT.EDU>,
kerberos@ATHENA.MIT.EDU, rvd-info@ATHENA.MIT.EDU, yba@ATHENA.MIT.EDU
Subject: Re: simpler approach to RVD-kerberos +
I agree with RLK. If we don't provide a way for users to
exchange information, short of exchanging their login passwords, they
WILL exchange their login passwords.
This wouldn't be so bad except that I feel it establishes a
bad precedent that would be hard to change later, once ACL service is
available. How hard would it be to code in the password setting code
on the database server on hector (setup so that anyone with kerberos
authentication as the owner can diddle the passwords)?
On another topic: Operations and Maintenance of RVDs.
I have been chomping over in my mind a proposal for quite some
time. I haven't said anything yet because I feel it is "unclean" and
fuzzes the boundary between AUTHENTICATION and AUTHORIZATION... a
boundary that I was an ardent supporter of!
Begin suggest-a-kludge mode (until an ACL service lives):
Currently each service machine resides within a kerberos
realm, and each service can find out its realm with a kerberos library
call.
Each kerberos principal has a name that consists of two
components. a "name" and an "instance". For humans registered in the
database the "name" is their login name and their "instance" is NULL.
Some few of us also have a different "principal" (with its own
password). This principal has our login names as our "name" and the
string "root" as our instance. Certain services know to grant certain
(listed) people "super-user" access as long as their "root" instances
are used to authenticate their requests. We only get tickets for
services with our "root" instances if we intend to do super-userish
sort of things. In this way our normally logged in terminal is not a
gateway to the world for some intruder.
Note: everything in the above paragraphs is already implemented.
I propose generalizing this mechanism of "root" instance
trusting so that all who come calling with a "root" instance are
trusted as the super-user. We then only allow certain individuals to
have "root" instances. Therefore in place of the RVD operations
password any "root" instance from a realm equal to the realm of the
server is permitted to do RVD system control operations, and the
"name" field of the authentication is logged in the RVD log. When an
individual no longer needs root access (ie. he no longer works for
Athena) his root instance can be decommisioned without effecting his
normal NULL instance.
End suggest-a-kludge mode;
-Jeff
--[0106]--
\f
[0107] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (18 lines)
Subject: How are things going
From BCN@WARD.CS.WASHINGTON.EDU Sun Sep 28 18:44:58 1986
Date: Sun 28 Sep 86 15:42:55-PDT
From: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Subject: How are things going
To: kerberos@ATHENA.MIT.EDU, hesiod@ATHENA.MIT.EDU
How are things going with kerberos and hesiod. Has there been any
progress with hesiod? And have there been any problems with kerberos?
What is the next step for each of these projects. I see that there
has been a lot of concern on the Arpanet over the existing Unix scheme
of authentication, but haven't had a chance to read all the messages
yet. It may be the right time to make kerberos available beyond MIT
(and Washington).
~ Cliff
-------
--[0107]--
\f
[0108] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (23 lines)
Subject: Re: simpler approach to RVD-kerberos
From jvs@ATHENA.MIT.EDU Mon Sep 29 11:16:20 1986
From: jvs@ATHENA.MIT.EDU
Date: Mon, 29 Sep 86 11:14:35 EDT
To: Saltzer, jis
Subject: Re: simpler approach to RVD-kerberos +
Cc: bitsy.mit:Krawitz@edu, bitsy.mit:Robert@edu, kerberos, rlk, rvd-info, yba
John Ostlund and I had discussed using the instance to specify an RVD server
capability; e.g. rather than passing an instance of "root" have the RVD
server recognize instances of "rvd_admin" or "rvd_oper" and then allow
the authenticated user to perform administration or operations functions.
This is a relatively clean way to use Kerberos authentication to provide
some authorization. The problems with this solution:
1. it is a temporary fix that would have to be backed out
when a real ACLS became available.
2. it does not solve the larger problem of pack access lists.
In general, I think our efforts would be best spent in creating an ACLS rather
than trying to work around its absense.
-Jim VS
--[0108]--
\f
[0109] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (28 lines)
Subject: Re: Operations and Maintenance of RV
From miller%erlang.DEC@decwrl.DEC.COM Tue Sep 30 00:44:04 1986
Date: 29-Sep-1986 1650
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu, rvd-info@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
Subject: Re: Operations and Maintenance of RVDs kludge
I have trouble with the kludge suggested by Jeff. It not only mixes
authentication and authorization, but naming as well. It could set
a dangerous precedent on use of names for privileges.
I believe that in such cases, the name can be used by convention as
a HINT. In other words, all privileged access requests might require
instance "rvd-admin", but would still be subject to some type of
authorization system. But even the use as a HINT is questionable, and
should only be done if it simplifies management.
Another temporary alternative for RVD administration is to clone to routines
Mark setup for the rcmd stuff, and use the same routines with a separate
file listing the authorized Kerberos names who are valid rvd administrators.
I had previously suggested making this form of local authorization more
generic than just rcmd.
Steve.
--[0109]--
\f
[0110] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (23 lines)
Subject: Re: Operations and Maintenance of RV
From Saltzer@ATHENA.MIT.EDU Tue Sep 30 11:47:48 1986
Date: Tue, 30 Sep 86 10:24:44 EDT
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Subject: Re: Operations and Maintenance of RVDs kludge
Cc: rvd-info@athena.mit.edu, kerberos@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 29-Sep-1986 1650
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
> Another temporary alternative for RVD administration is to clone to
> routines Mark setup for the rcmd stuff, and use the same routines
> with a separate file listing the authorized Kerberos names who are
> valid rvd administrators. I had previously suggested making this
> form of local authorization more generic than just rcmd.
I have a different problem with that proposal: it is implementing a
service-specific access control list. I would rather put the effort
int a rudimentary access control list service.
Jerry
--[0110]--
\f
[0111] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (25 lines)
Subject: knetd available for testing
From jtkohl@ATHENA.MIT.EDU Wed Oct 8 16:01:24 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Wed, 8 Oct 86 15:59:02 EDT
To: kerberos
Subject: knetd available for testing
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
The new knetd package is available for testing. There is a tar
distribution file available from charon by anonymous ftp in
~ftp/pub/knetd.distrib, or from priam:~jtkohl/knetd.distrib (for those
with access to priam).
The tar file contains a README file which should get you set up to test
knetd.
Knetd is a simple TCP port multiplexor whose intent is to reduce the
number of well-known ports kerberos integration requires.
Please report any problems you have to jtkohl@ATHENA.MIT.EDU
John
--[0111]--
\f
[0112] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:29 (146 lines)
Subject: a different proposal for authorizati
From Saltzer@ATHENA.MIT.EDU Sat Oct 11 23:18:28 1986
Date: Sat, 11 Oct 86 23:15:36 EDT
To: kerberos, watchmakers, developers
Subject: a different proposal for authorization, etc.
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Jeff and I have been chewing over several alternate possibilities for
design of an authorization service. Each has a
Japanese-tea-party-like scenario of interaction among a client,
Kerberos, authorization service, name service, and the service the
client was interested in (if it hasn't lost interest after all that).
The result of those discussions is a new proposal, radically
different from the previous one I made (recently well summarized by
Steve Miller) on how to organize this architecture.
There are three issues that are beginning to dominate my thinking on
this topic:
1. Availability: It is appropriate to minimize the number of
distinct, other network services that must be available at the
instant that one decides to invoke some service, especially if the
other network service isn't really needed for the specific case at
hand. (E.g., you are importing a public file system that allows
anyone read access. Access lists are irrelevant, so no request
should be made of an access list server, which may be on the other
side of a gateway that is reloading right now.)
2. Intricacy: some of the scenarios are very baroque; others seem
more intuitively organized and modular. Simplicity should win.
Also, simpler cases should have simpler scenarios.
3. Who's in charge: access authorization is a poorly organized area,
with lots of different ways to do it. In the absence of widespread
agreement that there is one best way, the server designer should get
to decide how to do it, rather than having to fit into someone else's
imposed model. Another aspect of this consideration is that private
services should get to (have to) store their own authorization
information, rather than burdening a public storehouse with such
stuff.
The new proposal, and a more-or-less complete scenario for
integrating name service, Kerberos, and authorization, is as follows
(there are a lot of services flying around in this discussion--the
one the client really wants to invoke is called the "desired
service"):
1. Assume for starters that each client (and service) knows the
internet address of a name service and the name of Kerberos. As part
of its initialization, the client invokes the name service to
determine the internet address of Kerberos. It also performs an
initial transaction with Kerberos to obtain a ticket-granting ticket.
Each service that cares about authorization has done the same
thing as part of its initialization.
2. The client learns the name of a desired service. It may learn in
one of any number of ways. Here are a few examples:
- A prospective user reads the name on a bulletin board.
- User copies a program from a public place; the program has the
name buried in it.
- The name is embedded in a system-provided library program.
- The name is embedded in a class-provided library program.
- The user knows a watchmaker.
3. The person exporting the desired service has previously done one
thing: registering the name of that service with the name service.
If this step hasn't happened, it doesn't prevent use of the desired
service, but it does mean that the client has to invoke it by
discovering and using a host name and port number, rather than by
name.
4. The client invokes the name service to learn the host name and
port of the desired service. The client can cache this information
at its own risk, to allow future invocations of the desired service
without using the name service again. The name service provides a
time-to-live value for the information that gives the client a hint
about how long it is safe to cache it. [There is an open question of
whether for this record type the name service should also resolve the
host name into a host internet address, to avoid another inquiry of
the name service. Since a different authoritative name server is
likely to be the real source of the name-to-IP address information,
there may be no advantage to doing it under the covers.]
5. The client invokes the Kerberos ticket-granting service,
requesting a ticket for the desired service name. If Kerberos has
never heard of the desired service, that doesn't cause the scenario
to abort; it may simply be that the desired service doesn't require
authentication.
6. [Assuming that the initial response from the name service was the
name of the server's host] The client invokes the name service
again, to transform the host name of the desired service into an
internet address.
7. The client invokes the desired service, presenting its Kerberos
ticket (if by now it has one) certifying the client's identity. It
is the responsibilty of the desired service to decide whether or not
it wishes to deal with this client.
8. The desired service may invoke a list membership service, which
operates via a network connection in a process running on the same
host. This list membership service looks up the client's identity in
a list that was mentioned in the request, and reports whether or not
it finds that name. A list may contain names of other lists; the
list membership service will perform a recursive descent through
these lists trying to verify membership of the client in one of them.
9. A named list can either be stored in a file containing lists on
this host, or it can be managed by a list membership service running
on a different host. The access list service is organized like the
BIND name service: a local process manages some authoritative data;
it may refer to remote list membership servers which manage other
authoritative data. The ability to use remote servers allows the
possibility of shared, centrally managed lists. The ability to use
local lists allows the possibility of lists whose contents are
unknown to any central authority. The architecture allows that these
two possibilities can be mixed and matched in any way desired by the
implementer or manager of the host that offers the service.
Because the desired service is probably depending on the
authenticity of the certifications of the list membership service,
each connection with a remote list membership service must be
initiated via Kerberos and the responses from the service need to be
integrity-assured. One way could be for the remote list membership
service to return a copy of the original request, with a yes or no
bit added, enciphered in the session key that the invoker obtained
at initial connection with the list membership service.
This description leaves a fair amount to be designed as to how the
list membership service might work internally. Because of the family
resemblance, an initial model might be that it is organized much like
the BSD BIND package, perhaps to the extent of implementing it by
starting with the code of that package. It seems fairly likely that
the same list membership service can serve both for access control
lists and also for mailing lists--especially since it would provide
neatly both for completely private as well as publicly shared mailing
lists.
It should be apparent that this proposal needs some comment and
discussion . . .
Jerry
--[0112]--
\f
[0113] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (70 lines)
Subject: Re: a different proposal for authori
From miller%erlang.DEC@decwrl.DEC.COM Tue Oct 14 12:31:20 1986
Date: 14-Oct-1986 1151
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
watchmakers@athena.mit.edu, developers@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
Subject: Re: a different proposal for authorization, etc.
Many moons ago, while discussing these issues, we noted that a key
design decision was whether it was the service's responsibility to
request authorization information, or whether the client had to
provide a "sealed capability" that verified its authorization privileges.
The current proposal by Jerry is of the former type, where the service
has the entire responsibility, given an authenticated user id, to
determine the authorization in whatever fashion it deems best.
I believe that this is a reasonably clean solution with only one
drawback. That is, if a single server (process) handles multiple
clients, the server must either block other clients while performing
a potentially lengthy network transaction to check authorization, or
alternatively, must be prepared to simulate separate threads for
each client. Thus, while waiting for authorization information to
be returned for client A, client B's requests could be serviced.
The problem is that if the server blocks, performance (throughput)
suffers considerably. Or in order to simulate threads, new and
more complex programming of the server is required.
The Kerberos versions of the "rcmd"s currently work in a similar manner;
all authorization policy and mechanism is done by the service, locally.
If server performance is a potential bottleneck, this approach also
adds workload to the server for the extra messages to check authorization.
With these provisos in mind, I find this proposal comparable to the previous,
with different tradeoffs.
Minor comments:
Servers registering in name service--
For servers with well known ports, this works well, with few
transactions. For servers that are not at well known ports, but
whose port changes each time instantiated, update traffic at
the name service should be kept in mind, as well as the authorization
for changing the name service entry. Alternately, a two-stage
binding could be used, where the name service maps to a host,
and something on the host maps to a specific port.
List membership service--
This could be a generic interface via network protocols ( and library),
rather than requiring it to be local. The only difference would
be performance, and security/integrity on the network media. The
library could detect whether the two ends were on the same host or not,
and apply encryption or integrity checks accordingly. As mentioned
in the proposal, this service would be authoritative for
certain lists, and would communicate with other list membership
services where needed.
If the list membership service recursively translates lists, it
must provide cycle detection at input/update.
Caches should time-out relatively quickly, since they provide
real value, rather than just a performance improvement. And
you cannot guarantee any means of invalidation in a network
environment with a variety of types of failures.
{end}
--[0113]--
\f
[0114] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (35 lines)
Subject: Re: a different proposal for authori
From Saltzer@ATHENA.MIT.EDU Tue Oct 14 14:52:06 1986
Date: Tue, 14 Oct 86 14:49:31 EDT
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Cc: kerberos, watchmakers, developers
Subject: Re: a different proposal for authorization, etc.
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 14-Oct-1986 1151
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Steve,
Thanks for the quick response. You have pinpointed the one issue
that worries me most about this approach, namely that any server that
uses the common authorization system must wait for a network
transaction; some servers may not be organized in a way that makes
that easy.
If we implement the list membership service via a network path to a
server running on the same machine, then desired services that are
organized with a single thread perhaps could accept a restriction:
their membership lists must be all handled locally by the first list
membership server asked. Since the first such server is actually on
the same machine the response is guaranteed to be quick. To enforce
such a restriction, the interface to and the protocol with to the
list membership server could both have a parameter that says "Don't
refer this request forward."
To reduce time further, it might be more appropriate to implement the
local list membership service as a library subroutine that works
directly with files stored in /site/authorizations/ and that invokes
a real network protocol only when those lists seem to refer to
outside, common lists.
Jerry
--[0114]--
\f
[0115] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (15 lines)
Subject: Re: a different proposal for authori
From jg@ATHENA.MIT.EDU Tue Oct 14 18:45:24 1986
From: jg@ATHENA.MIT.EDU
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: miller%erlang.DEC@decwrl.dec.com, kerberos, watchmaker, developers
Subject: Re: a different proposal for authorization, etc.
In-Reply-To: Your message of Tue, 14 Oct 86 14:49:31 -0400.
<8610141849.AA04472@HERACLES>
Date: Tue, 14 Oct 86 18:41:50 EDT
I note that the X server is one of the type that Steve describes, and yes, it
would be very painful to recode to not block on doing the authorization...
In addition, when you run a program to your display, you would really like it
to be able to start quickly....
Jim
--[0115]--
\f
[0116] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (47 lines)
Subject: Re: a different proposal for authori
From Saltzer@ATHENA.MIT.EDU Tue Oct 14 23:51:48 1986
Date: Tue, 14 Oct 86 23:48:18 EDT
To: <jg@ATHENA.MIT.EDU>
Subject: Re: a different proposal for authorization, etc.
Cc: miller%erlang.DEC@decwrl.dec.com, kerberos@ATHENA.MIT.EDU,
watchmakers@ATHENA.MIT.EDU, developers@ATHENA.MIT.EDU
In-Reply-To: <jg@ATHENA.MIT.EDU>'s message of Tue, 14 Oct 86 18:41:50 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> I note that the X server is one of the type that Steve describes, and
> yes, it would be very painful to recode to not block on doing the
> authorization... In addition, when you run a program to your
> display, you would really like it to be able to start quickly....
Good point. However this one may be salvageable within a general
framework of having the server responsible for authorization
decisions. The X server is a good example of a service that almost
certainly can get along without the need for shared membership lists.
Suppose that the xhost mechanism is replaced with a simple check by
the x server of a locally-stored list of (Kerberos-authenticated)
users who are permitted to open windows. That would probably require
opening a file--perhaps only at X startup time--but no block awaiting
some network service to respond.
Another way to attack it is to observe that the one thing that needs
to go as fast as possible is figuring out that the window is being
opened by the workstation user from another host. If that case goes
fast perhaps the less frequent but more general case of a stranger
opening a window can be slower.
Here is a question for the Kerberos/rlogin crowd. If I am
Kerberos-authenticated at my workstation, and I rlogin or rsh to
another machine successfully, what (if anything) can my process at
the other machine do to short-cut the full-bore Kerberos ticket
acquisition mechanism when opening commerce with my workstation?
Superficially, the X client code at the other host is going to have
to go to Kerberos to get an X server ticket enciphered in my own
private key so that my workstation will accept it; but my workstation
could have provided that ticket as well. Any ideas on how to get
this out-and-back authentication to go cheaply? (Without
accidentally permitting anyone else logged in on the same
time-sharing system to open a window, too.)
Jerry
--[0116]--
\f
[0117] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (79 lines)
Subject: Re: a different proposal for authori
From jis@BITSY.MIT.EDU Wed Oct 15 00:19:53 1986
Date: Wed, 15 Oct 86 00:18:43 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: Saltzer@ATHENA.MIT.EDU
Cc: jg@athena.mit.edu, miller%erlang.DEC@decwrl.dec.com,
kerberos@ATHENA.MIT.EDU, watchmakers@ATHENA.MIT.EDU,
developers@ATHENA.MIT.EDU
Subject: Re: a different proposal for authorization, etc.
Ah. what a can of worms. One thing I have done often is login
to host A, and then rlogin to host B. Now on host B I want to invoke a
kerberos authenicated service, but I have to get tickets. To get
these tickets I have to give host B my password. Now my rlogin
connection between A and B is NOT enciphered, so my password is going
over the net in the clear, something that kerberos is supposed to
avoid.
What is clearly needed here is for rlogin (kerberos
authenicated version) to transmit a ticket granting ticket for me from
host A to host B using the make_private_message function to hide the
ticket. Now tickets are IP address specific so I cannot merely send my
ticket granting ticket from host A to host B, for that will not work.
I therefore propose that kerberos authenicated rlogin be
changed to perform the following transaction:
Currently the rlogin program (client) makes an authenicator
(with mk_ap_req) for you and sends it with some other information
(terminal type and whatnot) as the first bytes in a rlogin connection.
The server then reads this authenicator and validates it (using
rd_ap_req)
This should be changed so that the rlogin client determines
the IP address you are about to communicate with (it does this anyhow,
how else could it make a connection!). It then using your krbtgt
(ticket granting ticket) it asks the kerberos server for an additional
krbtgt valid from host B. Then it sets up a connection to host B
sending first your authenticator (created with mk_ap_req) and then the
new krbtgt encased in a private message (with mk_private_message)
followed by your terminal type info. The rlogind program (server on
host B), would read this information and then store the krbtgt in
/tmp/tkt_... (ie. where kerberos login stores it now). In this way
your login session on host B will have a krbtgt and be able to go on
from there as if you had logged in directly, and no private
information is sent unenciphered on the network.
Note: You are completely safe, for even if host B is not who you think
he is (ie. someone faked out the name service) your krbtgt will not be
exposed, If B is bogus he won't be able to decode your authenicator
and therefore not get the session key contained therein, which is the
key that mk_private_message used to encipher the transaction that
contains your krbtgt.
Also Note: The kerberos server would have to be modified to support
the "I want a krbtgt for host B" given a krbtgt for host A (of course
this transaction will have to be initiated from host A). Presumably a
library function could be added to the kerberos library to support
this "promotion" of a krbtgt.
Now what does this have to do with X? Well if this mechanism
was in place, then if you rlogin'd to a time sharing system from a
workstation, the time sharing system would have a krbtgt for you and
could get a service ticket for the X server on your workstation and
thus make authenticators.
NOTE: today we DO NOT have service keys on the workstations. If we
wanted the X server on your workstation to accept kerberos
authentication we would have to register an X server instance FOR EACH
WORKSTATION in the kerberos database, and more troublesome, maintain
those keys on the workstations. It is this fact that will probably nix
have the X server use kerberos authenication at all!!!
Enough for one message...
-Jeff
--[0117]--
\f
[0118] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (68 lines)
Subject: authentication forwarding; X servers
From miller%erlang.DEC@decwrl.DEC.COM Thu Oct 16 03:39:14 1986
Date: 15-Oct-1986 1518
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: authentication forwarding; X servers
The recent messages from both Jerry and Jeff point out that Kerberos
was not initially designed to support such "authentication forwarding".
I believe Jeff's suggestions can provide a reasonable workaround,
analogous to poor-man's-routing. Note that the address is sealed in
the ticket to provide an inexpensive means of detecting certain replay
attempts when using one-way authentication. Unless we go to a 3-way
handshake for mutual authentication, and eliminate the one-way
authentication, it should stay there.
To address Jerry's question using the X client example, Jeff's suggestion
could be further extended such that a client on host A can request tickets
that would be valid from host B. Then the client safely transports the
tickets from host A to host B, and uses them on host B as if they were
originally obtained there.
I would suggest a couple of minor changes-
a) Only the session key needs to be secret, since the
ticket is only valid in conjunction with the session
key to create an authenticator. (could even change
a future version of Kerberos to not encrypt the tickets
returned from the Kerberos server, but merely the
session keys and a checksum of the tickets.)
b) modify the ticket-granting ticket to allow requesting
more than one ticket at a time, only restricted by
the minimum length limits of a UDP datagram. This makes
the network and server transactions more efficient when you
know you need more than one ticket at a time.
The original auth_request allowed this, but has since been
limited to only 1 ticket request at a time.
c) guarantee that a new krbtgt ticket created from an existing
krbtgt ticket expires no later than the original.
The X problem, where the X server comes and goes with different owners
on a workstation, is not readily solved using the Kerberos server.
It would require frequent changes to the Kerberos database, and to the
"owner" of an entry in the database. The current batch update of the
database, as well as its administrative restrictions, make this unreasonable.
Make your own ticket--
----------------------
However, if you view the role of the Kerberos server as securely distributing
a session key between a client and server, other possibilities arise.
The secrets that Kerberos maintains are the master keys.
A user logging into a workstation is in a perfect position to securely
distribute a session key to the server, i.e. the X server on the workstation,
and the client, i.e. themself! For example, the user could use their own
password as the temporary X server master key, and construct their own ticket
for the X service automatically at login time! Local X client applications
would use the ticket thus constructed. If you wanted to rlogin to another
system then run an X application to the original host, do as suggested
by Jeff, but making your own ticket.
I havent thought through all the details for the X server problem, but
I think this type of approach is feasible.
Comments?
--[0118]--
\f
[0119] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (31 lines)
Subject: re: authentication forwarding; X ser
From Saltzer@ATHENA.MIT.EDU Thu Oct 16 12:28:38 1986
Date: Thu, 16 Oct 86 12:26:07 EDT
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Subject: re: authentication forwarding; X servers
Cc: kerberos@athena.mit.edu (Distribution list @KERB)
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 15-Oct-1986 1518
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
> A user logging into a workstation is in a perfect position to
> securely distribute a session key to the server, i.e. the X server on
> the workstation, and the client, i.e. themself! For example, the
> user could use their own password as the temporary X server master
> key, and construct their own ticket for the X service automatically
> at login time!
This is clearly the right direction to go for X authentication. I
don't like the idea of using the user's own password, which otherwise
doesn't need to remain around on the workstation. But for
self-authentication any randomly-generated key will do just fine.
The obvious one to use is the session key obtained in the initial
Kerberos encounter.
The main problem underlying this direction is mechanical: the current
mechanism for rsh and rlogin isn't equipped to pass environment
information, such as display location and, with this proposal,
authenticators.
Jerry
--[0119]--
\f
[0120] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (60 lines)
Subject: Re: a different proposal for authori
From BCN@WARD.CS.WASHINGTON.EDU Mon Oct 20 23:28:27 1986
Date: Mon 20 Oct 86 20:26:36-PDT
From: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Subject: Re: a different proposal for authorization, etc.
To: jis@BITSY.MIT.EDU
Cc: Saltzer@ATHENA.MIT.EDU, jg@ATHENA.MIT.EDU,
miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU,
watchmakers@ATHENA.MIT.EDU, developers@ATHENA.MIT.EDU
In-Reply-To: <8610150418.AA09755@BITSY.MIT.EDU>
Alot of the discussions that have been going on on this list recently
with respect to kerberos mirror many of issues that have been
discussed before. I will first discuss authentication forwadring.
Having rlogin generate a new set of tickets for the destination host
is clearly the way to go. There are a few problems though. First,
one does not want to do this automatically (or at least without
providing an override). As a security-concious user, you are not
going to desire the forwarding of your credentials to a new system
that you know is not secure. Perhaps this would be acceptable if you
made the life of those credentials sufficiently short, but once
credentials expire in the middle of the rlogin session, the simple
path no longer exists for renewing them and you are back where you
started.
Another possible solution, although not as clean, would require some
kind of call back mechanism from the remote system that would allow
the desired tickets (or perhaps a shortlived tgt) to be obtained as
necessary. Once the user has logged out of the remote system, further
requests would be disallowed. Although a bit more secure, this
doesn't solve the problem completely. The problem is one of deciding
just how far you want to trust an untrustworthy agent.
Steve suggested restricting the lifetime of new tickets to the
remaining life of the ticket granting ticket. If I recall correctly,
this is allready the case.
Now onto the next topic, X. At the moment, service keys do not reside
on the public workstations. I expect that this is the way things will
remain since their security can't be assured. The first approach one
might consider taking to solve this problem is to use the key for the
client who is currently logged in. This is bad since we want to get
rid of this key as quickly as possible after it has been entered.
In discussions with mike and tony (regarding the noticication server)
I presented a possible scheme where an intial unauthenticated request
triggers a reply that is the initial message of a mutual
authentication exchange. Unfortunately, this only works for requests
from a timesharing (or server host) to a workstation, and not between
workstations. It is also fairly complex. I have a few other ideas on
this topic, but they, too, are overly complex, and I won't go into
them here.
Most of the relavant issue have been mentioned with respect to an
access control list server. The main tradeoff is between conceptual
simplicity in the approach where the end service calles the ACLS, and
taking the load off the end service when the ACLS is called by the
client.
-------
--[0120]--
\f
[0121] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:30 (35 lines)
Subject: Re: a different proposal for authori
From jis@E40-311B-2.MIT.EDU Tue Oct 21 10:57:55 1986
Date: Tue, 21 Oct 86 10:55:37 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Cc: Saltzer@ATHENA.MIT.EDU, jg@ATHENA.MIT.EDU, jis@BITSY.MIT.EDU,
miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU,
watchmakers@ATHENA.MIT.EDU, developers@ATHENA.MIT.EDU
Subject: Re: a different proposal for authorization, etc.
Ah, but the trick is you don't need a permanent service key on
a workstation. Consider: User logs into workstation. A RANDOM service
key is generated for the "X" service and stored into /etc/srvtab. Now
when the user does an rlogin to a timesharing system (assuming that
rlogin hands over tickets), rlogin calls a subroutine (yet to be
written) that constructs an "X" ticket for use on the timesharing
system by fetching the service key out of /etc/srvtab. The timesharing
machine can then use this ticket for creating authenicators that the X
server on the workstation can check using normal kerberos subroutines
(rd_ap_req).
The beauty of this approach is that it is secure, and requires
NO interaction with the kerberos server. Although the kerberos
PROTOCOL is used, the server is not because there is no need to use a
central registry to hang onto the service key.
In fact we may want to generalize this one step further by
creating a service name of "ME" (well we can pick a better name, but
I'll use this for an example) which could be used by all services that
run on the workstation. Specifically all services that want to know
"Is this incoming connection being made on behalf of the user which is
using ME."
-Jeff
--[0121]--
\f
[0122] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (13 lines)
Subject: Visit
From miller%erlang.DEC@decwrl.DEC.COM Wed Oct 22 01:26:35 1986
Date: 21-Oct-1986 1512
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB), dec@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
Subject: Visit
I expect to drop by tomorrow, Wed, late morning to say hello and see
what is exciting.
Steve.
--[0122]--
\f
[0123] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (13 lines)
Subject: Authentication forwarding
From miller%erlang.DEC@decwrl.DEC.COM Wed Oct 22 04:22:57 1986
Date: 21-Oct-1986 1601
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
miller%erlang.DEC@decwrl.DEC.COM
Subject: Authentication forwarding
Another possibility is to do the forwarding as previously discussed
(jis), but as a separable command, e.g. "Kerb_forward hostname".
This leaves all the muck out of rlogin, yet you could alias (or script)
"rlogin" et all to be "Kerb_forward \!*; rlogin \!*".
--[0123]--
\f
[0124] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (21 lines)
Subject: Re: Authentication forwarding
From srz@athena.MIT.EDU Wed Oct 22 10:48:56 1986
From: srz@athena.MIT.EDU
Date: Wed, 22 Oct 86 10:47:11 EDT
To: kerberos@athena.MIT.EDU
Subject: Re: Authentication forwarding
But how can a separate command forward tickets between two hosts in
a secure way? There needs to be a session key kept between the two
parties, which is something that rlogin would have to do. I like the
idea of being able to manually forward tickets, though; I would then
be tempted in writing a "ksu", which is like "su", except it requires
kerberos tickets, not passwords. Keeping login passwords off the network
doesn't help if people have to type in root passwords...
-stan
--[0124]--
\f
[0125] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (46 lines)
Subject: Re: Authentication forwarding
From spook@ATHENA.MIT.EDU Wed Oct 22 13:09:20 1986
To: kerberos
Subject: Re: Authentication forwarding
In-Reply-To: srz's message of Wed, 22 Oct 86 10:47:11 EDT.
Date: Wed, 22 Oct 86 11:57:21 -0500
From: Ken Raeburn <spook@ATHENA.MIT.EDU>
But how can a separate command forward tickets between two hosts in
a secure way? There needs to be a session key kept between the two
parties, which is something that rlogin would have to do. I like the
idea of being able to manually forward tickets, though; I would then
be tempted in writing a "ksu", which is like "su", except it requires
kerberos tickets, not passwords. Keeping login passwords off the network
doesn't help if people have to type in root passwords...
While it could be done for trusted timesharing machines, workstations
(or not-necessarily-trusted timesharing systems) on the receiving end
do not present a reasonable way to do this before logging in. If the
initial rlogin protocol set up the session key (randomly generated?),
this key could be used later to transfer the TGT (or a limited set of
tickets) after logging in, could it not?
The session key would not in itself provide a way to get the TGT from
the host without the user requesting that it be sent, but if the user
decided he wanted to use the TGT from the remote host, he could then
send it over, via a separate program. That would still allow someone
to send a phony TGT, but if the program that did the receiving were to
check that a valid rcmd ticket could be requested for that user, given
the supposed TGT that it was given, this could be excluded.
Since the program receiving the TGTs from the network and rlogind
would be running independently, some location in the filesystem would
probably have to be predetermined as the location of that user's
tickets; some sort of double server accepting TGT-transfer connections
from the network and accepting pathnames from local processes (through
a socket accessible only through setuid programs?) would be possible,
but a little messy.
[An even messier possibility -- add to the klogin protocol an escape
sequence that says "here comes a TGT!", and a sequence on the user
side....]
_kr
--[0125]--
\f
[0126] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (16 lines)
Subject: Re: Authentication forwarding
From Raeburn.PDO@MIT-MULTICS.ARPA Wed Oct 22 13:58:04 1986
Date: Wed, 22 Oct 86 13:44 EDT
From: Ken Raeburn <Raeburn@MIT-MULTICS.ARPA>
Subject: Re: Authentication forwarding
To: kerberos@ATHENA.MIT.EDU
Cc: Ken Raeburn <spook@ATHENA.MIT.EDU>
In-Reply-To: Message of 22 Oct 86 12:57 EDT from "Ken Raeburn"
Wait, never mind that message. I realized after a little more thought
that that's not the right way to do things, even if it were to work..
Sigh.
-Ken
--[0126]--
\f
[0127] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (45 lines)
Subject: Time synchronization
From miller%erlang.DEC@decwrl.DEC.COM Thu Oct 23 11:10:33 1986
Date: 23-Oct-1986 0948
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Time synchronization
I tracked down a problem that Jim VanSciver was having with Kerberos,
and it turned out to be a time synchronization problem. The Kerberos
server itself was running over 3 minutes slow, while his workstation was
running fast. The net result was that the Kerberos server rejected
ticket-granting-ticket requests.
The current maximum time skew allowed by the protocol is 5 minutes.
Stretching this does not solve the problem, but only increases the number
of days clocks can drift before the problem bites you. It also increases
vulnerability to replays.
Therefore I would suggest the following:
a) The time on Kerberos servers is manually set by the Kerberos
administrator every couple of days (or more frequently.) The
Athena timeservice should not be automatically used for this,
since it could be spoofed, may not be accurate, and the time
exchange is not authenticated.
b) Workstations and time sharing systems should synchronize to
"real" time, using either the Athena time service or other
means, on a daily basis using some mechanism such as crontab.
c) A system/network manager should monitor the Timeserver time
to check for significant discrepancies. If the Kerberos time
and the timeserver time get too far out of synch, Kerberos
effectively will reject all requests from systems that synched
to the timeserver.
A more ambitious approach would be to make the timeserver a trusted, Athena
administered service using a Kerberos protocol to provide integrity
for certain requests. Then by adding a reliable source of the time, such
as a WWV receiver, things could stay correctly in synch. Of course, to boot
the "system" you still need a good external reference of time to setup the
Kerberos time before it talks to the timeserver.
So if wierd, intermittent Kerberos errors occur, check the time
synchronization.
Steve.
--[0127]--
\f
[0128] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (23 lines)
Subject: re: Time synchronization
From Saltzer@ATHENA.MIT.EDU Thu Oct 23 17:50:34 1986
Date: Thu, 23 Oct 86 17:47:32 EDT
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Subject: re: Time synchronization
Cc: kerberos@athena.mit.edu (Distribution list @KERB)
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 23-Oct-1986 0948
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
A quick strategy that would help improve the situation would be to
have crontab on the Kerberos server run a program once a day to
invoke the network standard time server, compare it with the Kerberos
clock, and if they are different by more than 15 seconds, send a mail
message to the Kerberos administrator. The Kerberos administrator
would be the only one who would actually modify the Kerberos clock.
With this approach, the only bad effect of a spoofed, inaccurate, or
unauthenticated timeservice response is a message to the
administrator.
Jerry
--[0128]--
\f
[0129] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (24 lines)
Subject: Kerberos edits
From miller%erlang.DEC@decwrl.DEC.COM Sat Oct 25 01:57:59 1986
Date: 24-Oct-1986 1056
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Kerberos edits
I just made two edits to the kerberos sources on menel.
The first is a bug fix to ~auth/src/lib/krb/decomp_ticket.c .
It no longer swaps the session key under any circumstances.
This fixes a problem Jim VanSciver had on the RT.
The second is a change to one register assignment in
~auth/src/lib/des/vax/des.c . This results in a savings of almost
10% in execution time on the microvax2. I recompiled the verify program
to confirm it is still yielding the correct results.
These changes should go in the next release, and the bug fix should be made
available to anyone developing kerberos server code on the RT asap.
Steve.
--[0129]--
\f
[0130] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:31 (32 lines)
Subject: Re: Authentication forwarding
From miller%erlang.DEC@decwrl.DEC.COM Sat Oct 25 07:54:28 1986
Date: 24-Oct-1986 1059
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu,
"srz@athena.mit.edu"%DEWCWRL.DEC@decwrl.DEC.COM
(Distribution list @KERB)
Subject: Re: Authentication forwarding
It could work similar to the manner in which rcmd works. That is, starting
at host A, you request a ticket from Kerberos to talk to the forwarding
service on host B. The forwarding server is akin to the rcmd stuff. Then
you make a standard authenticated request (mk_ap_req) to the forwarding
service on host B. Thus A and B now share a session key. Then, from A,
you ask Kerberos for another ticket-granting-ticket, but as if you were
from host B (or this could be done earlier). Kerberos replies with that
ticket, but to the requesting host A. Then host A, using the session key
just setup with the forwarding service, securely (mk_private_msg or
mk_safe_msg) transfers that new ticket to host B. Host B installs the
ticket in a ticket file, as if it had originated there.
The forwarding service could even just be an extension to the "rcmd"
suite. All it does it receive and store forwarded tickets.
As was pointed out, this is ok if Host B is a trusted time-sharing
service. Otherwise, it is as if you walked away from your workstation in
the middle of a session without destroying your tickets. Any other
user of that workstation, given root access, could use your tickets for
up to about a day, when they expire.
Steve.
--[0130]--
\f
[0131] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (31 lines)
Subject: Re: Authentication forwarding
From miller%erlang.DEC@decwrl.DEC.COM Sat Oct 25 08:20:20 1986
Date: 23-Oct-1986 1004
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu, srz@athena.mit.edu (Distribution list @KERB),
miller%erlang.DEC@decwrl.DEC.COM
Subject: Re: Authentication forwarding
It could work similar to the manner in which rcmd works. That is, starting
at host A, you request a ticket from Kerberos to talk to the forwarding
service on host B. The forwarding server is akin to the rcmd stuff. Then
you make a standard authenticated request (mk_ap_req) to the forwarding
service on host B. Thus A and B now share a session key. Then, from A,
you ask Kerberos for another ticket-granting-ticket, but as if you were
from host B (or this could be done earlier). Kerberos replies with that
ticket, but to the requesting host A. Then host A, using the session key
just setup with the forwarding service, securely (mk_private_msg or
mk_safe_msg) transfers that new ticket to host B. Host B installs the
ticket in a ticket file, as if it had originated there.
The forwarding service could even just be an extension to the "rcmd"
suite. All it does it receive and store forwarded tickets.
As was pointed out, this is ok if Host B is a trusted time-sharing
service. Otherwise, it is as if you walked away from your workstation in
the middle of a session without destroying your tickets. Any other
user of that workstation, given root access, could use your tickets for
up to about a day, when they expire.
Steve.
--[0131]--
\f
[0132] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (16 lines)
Subject: Code for January release
From treese@ATHENA.MIT.EDU Fri Oct 31 15:19:26 1986
From: treese@ATHENA.MIT.EDU
Date: Fri, 31 Oct 86 15:17:22 EST
To: kerberos
Subject: Code for January release
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
I need to nail down any changes to the Kerberos code that I have for
release in January.
In other words, are we changing anything from what is now distributed?
- Win
--[0132]--
\f
[0133] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (20 lines)
Subject: Re: Code for January release
From srz@athena.MIT.EDU Fri Oct 31 16:27:03 1986
From: srz@athena.MIT.EDU
Date: Fri, 31 Oct 86 16:25:16 EST
To: treese@ATHENA.MIT.EDU
Subject: Re: Code for January release
Cc: kerberos@athena.MIT.EDU
I recall that the kerberos code that reached the workstations was not
the latest code that Cliff had. Most of this had to do with different
realms. I think 'kinit' and 'rlogin' might have changed since August.
Also, toehold needs to be recompiled with the latest kerberos library.
(And tested, of course)
-stan
--[0133]--
\f
[0134] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (15 lines)
Subject: Re: Code for January release
From Saltzer@ATHENA.MIT.EDU Fri Oct 31 20:19:49 1986
Date: Fri, 31 Oct 86 20:18:17 EST
To: kerberos@athena.MIT.EDU
Subject: Re: Code for January release
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
It seems to me that Jim VanSciver fixed several byte-order dependent
bugs in his integration of Kerberos with RVD on the RT. Best make
sure those changes get picked up.
Jerry
--[0134]--
\f
[0135] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (39 lines)
Subject: Re: Host unknown
From Saltzer@ATHENA.MIT.EDU Sat Nov 1 20:40:08 1986
Date: Sat, 1 Nov 86 18:27:04 EST
To: kerberos, jis, spm%erlang.dec@decwrl.dec.com
Subject: Re: Host unknown
In-Reply-To: johnsson@decwrl.DEC.COM (Richard Johnsson)'s message of 1 Nov 1986 0010-PST (Saturday)
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
My last message to the kerberos mailing list got a bounceback--the
copy for Steve Miller at DEC came back with the message "host unknown".
I thought it was a problem inside decwrl, so I forwarded it to their
postmaster, who replied. . .
> Actually your problem is "decwrl.arpa". Our name is "decwrl.dec.com"
> and has been for the last year or so. Decwrl.arpa was recently
> deleted as a nickname and mail still using the old, obsolete name is
> getting bounced. Apparently kerberos@athena.MIT.EDU has set up
> forwarding to the old address.
I checked our local domain name server (strawberry) and it answered
with three (!) different addresses for decwrl.arpa, a time to live of
about one day, and a note that the primary name is decwrl.dec.com.
Then I checked the nic domain name server, and it answered,
presumably authoritatively, that the name decwrl.arpa is not known.
1. Jeff: how does strawberry know things that sri-nic doesn't? Does
it have a pirate (out of date) copy of the .arpa authoritative data
base? If so, it looks like being out of date leads to an obscure
kind of bug--our outgoing SMTP can get their address but their
incoming SMTP claims it isn't the place we are trying to talk to.
2. Steve: could you please fix your forwarding address to use the
new domain name?
Jerry
--[0135]--
\f
[0136] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (75 lines)
Subject: Interrealm misfeatures and alternate
From wesommer@ATHENA.MIT.EDU Mon Nov 3 03:46:33 1986
To: kerberos
Subject: Interrealm misfeatures and alternate an_to_ln
Date: Mon, 03 Nov 86 03:44:27 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I have just spent the last three hours examining some interrealm
misfeatures of Kerberos. Currently, Kerberos is quite inconvenient to
use in many protocols if both systems are not in the same realm.
One obstacle I ran across (but did not attempt to fix) is that ticket
files do not contain the realm of the principal they are for (it is
assumed that it is the same as the local realm of the machine). As a
result, when constructing an authenticator, mk_ap_req does a
get_credentials for the appropriate service; assuming that succeeds,
it proceeds to build the authenticator. When building the request ID
(including the user's identity encrypted in the session key), it uses
the name and instance retrieved from the ticket file, but always uses
the local realm, rather than the realm encoded in the ticket (which is
not stored in the clear in the ticket file). This makes "kinit -r"
(for an alternate realm) worthless unless you are empowered to do
surgery on /etc/krb.conf as well. (I am sure that others have noticed
this bug before).
The following syslog trace of a server which shall remain nameless
demonstrates the problem: [Oliver is in the ATHENA realm, and I have
"kinit"ed for the TELECOM realm]
Nov 3 02:15:58 paris xxx[15029]: connection accepted from OLIVER.SIPB.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: ticket->length: 56
Nov 3 02:15:59 paris xxx[15029]: Ticket Contents.
Nov 3 02:15:59 paris xxx[15029]: Aname: wesommer.TELECOM.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: Service: rcmd.paris
Nov 3 02:15:59 paris xxx[15029]: About to decrypt req_id
Nov 3 02:15:59 paris xxx[15029]: Done.
Nov 3 02:15:59 paris xxx[15029]: Pname: wesommer wesommer
Nov 3 02:15:59 paris xxx[15029]: Realm: TELECOM.MIT.EDU ATHENA.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: rd_ap_req(rcmd.paris) failed, code 36
"So close, and yet so far..."; the ticket is OK except for the bogus
realm (ATHENA.MIT.EDU) put in by the client code.
On a more optimistic note, I just implemented an "improved" an_to_ln()
routine (this is the routine which translates Kerberos names into
local names). In addition to translating {<name>, "", <local-realm>}
into the local name <name>, it also attempts to translate foreign
realms or non-null instances by looking them up in a DBM keyed
database (in /etc/aname.{dir,pag}).
To make this useable, I also wrote a simple user-interface program
(krb_alias) which allows one to examine and modify the database:
krb_alias with no arguments dumps the whole database; krb_alias with
one argument (a kerberos name of form <name>.<instance>@<realm>)
prints the local name or "unknown" if no local name can be found), and
krb_alias with two arguments (kerberos name and local name)
establishes a mapping, or deletes the mapping from the kerberos name
if the local name is "-delete". Naturally, /etc/aname.* is set up to
be mode 644, owner root, so krb_alias must be setuid root. I made a
few policy decisions:
- root can map any Kerberos name into any local name or delete any mapping
- <user> can map any Kerberos name of the form <user>.*@* into
<user>, or delete any mapping from <user>.*@*
I think that the second one could be relaxed a little bit, but I'm not
sure exactly how far (it's really a policy decision which I'm not
prepared to make at 3AM).
Sources for these modules may be found in
/@/paris/mit/w/e/wesommer/remote_krb/irlm/{lib,prog}; a binary for
krb_alias is installed in /krb on paris. Comments anyone?
- Bill
--[0136]--
\f
[0137] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (32 lines)
Subject: Re: Interrealm misfeatures; alternat
From miller%erlang.DEC@decwrl.DEC.COM Mon Nov 3 11:05:42 1986
Date: 03-Nov-1986 1042
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: Interrealm misfeatures; alternate an_to_ln
Bill's analysis of the realm problem looks right. The local ticket
file should keep track of the principal's realm, and this should
be used in mk_ap_req(). This should be a straightforward fix.
(Who is maintaining Kerberos currently?). Also, I would suggest doing
a quick "grep" of the Kerberos library looking for various uses of
the realm where it may similarly be hard-wired or ignored. The main
thing to keep in mind about the realm is that the Kerberos server
labels the tickets with the realm. All the rest is bookkeeping.
Regarding "an_to_ln()", Bill's intention is good. The original mapping
was just a simple default to get things going, and isolate the
Kerberos name space from system-specific name spaces. Before adopting
this new "an_to_ln()" on a larger scale, there should be some
discussion with the people doing the name service and service management
service. In terms of the details of Bill's suggestion, two comments:
1) The search order has to be specified, e.g. can the default
{name,"",realm} ---> <name> be overriden by the auxiliary file?
2) a local user <name> could be allowed to control all Kerberos
names that map into <name>, since <name> represents the
local resources and privileges. This allows a more general
proxy mechanism, though perhaps complicating management.
In the long run, are these mappings handled through SMS?
Steve
--[0137]--
\f
[0138] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:32 (19 lines)
Subject: Re: Interrealm misfeatures; alternat
From wesommer@ATHENA.MIT.EDU Mon Nov 3 12:41:52 1986
To: miller%erlang.dec@decwrl.dec.com
Cc: kerberos@athena.mit.edu
Subject: Re: Interrealm misfeatures; alternate an_to_ln
In-Reply-To: Your message of 03-Nov-1986 1042.
<8611031559.AA24599@decwrl.dec.com>
Date: Mon, 03 Nov 86 12:39:37 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
1) The search order has to be specified, e.g. can the default
{name,"",realm} ---> <name> be overriden by the auxiliary file?
Currently, this is not done; however, I could, of course, swap two
blocks of code. As this was a midnight->3AM hack, I didn't feel like
implementing or changing policy. One can map other realms to the
local name, just not the local realm.
- Bill
--[0138]--
\f
[0139] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (22 lines)
Subject: Re: Interrealm misfeatures and alte
From srz@athena.MIT.EDU Mon Nov 3 14:47:47 1986
From: srz@athena.MIT.EDU
Date: Mon, 3 Nov 86 14:45:18 EST
To: wesommer@ATHENA.MIT.EDU
Subject: Re: Interrealm misfeatures and alternate an_to_ln
Cc: kerberos@athena.MIT.EDU
Actually, the ticket file does contain the realm of the principal they
are in, except kerberos doesn't rely on it to determine the local
domain. As kerberos is currently set up, there is only one krbtgt
entry in which the instance (the realm that the ticket is good for)
is the same as the realm in which the ticket was gotten. That is the
'local' realm.
For example, if I am in the LCS realm, and do a 'kinit', I get a ticket
of the form: 'srz', '', 'krbtgt', 'LCS.MIT.EDU', 'LCS.MIT.EDU'. When
I log on over to athena, I get an additional ticket: 'srz', '', 'krbtgt',
'ATHENA.MIT.EDU', 'LCS.MIT.EDU'. If rd_ad_tkt were changed so that it
determined the local realm from the tickets, as opposed to using
krb.conf, then a single 'kinit -r' would change your realm for the entire
session. The ticket file would stay the same.
--[0139]--
\f
[0140] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (9 lines)
Subject: Re: realms
From miller%erlang.DEC@decwrl.DEC.COM Tue Nov 4 09:41:05 1986
Date: 04-Nov-1986 0932
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: realms
--[0140]--
\f
[0141] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (30 lines)
Subject: source code control transfer
From ostlund@ATHENA.MIT.EDU Tue Nov 4 11:01:07 1986
From: ostlund@ATHENA.MIT.EDU
Date: Tue, 4 Nov 86 11:00:18 EST
To: kerberos
Subject: source code control transfer
This week, Win and I will put together a release of the kerberos
code from menelaus that will land on paris and thereafter be
considered the master source. Further development (now mainly
being done by Dave Jedlinsky [opus], Chris Reed [panda], and
Brian Murphy [hindmost]) will use the code from paris as the
starting point, and will need to check code in and out through
Win.
A consequence of this shift from menelaus to paris will be that
the latest and greatest kerberos code now living on menelaus will
become part of the January release. If anyone knows of Kerberos
work NOT now on menelaus (e.g., on styx) that should go into Win's
master sources, please let us know THIS WEEK. Thanks.
I will continue to be the coordinator for the work Dave, Chris,
and Brian are doing, will continue to be the password-changer,
backup-checker, and general babysitter for the Kerberos machine,
and will, of course, be including support for Kerberos in the
SMS design.
John
--[0141]--
\f
[0142] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (24 lines)
Subject: Re: realms
From miller%erlang.DEC@decwrl.DEC.COM Tue Nov 4 13:50:45 1986
Date: 04-Nov-1986 1036
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: realms
SSorry, the last one got away when I was trying to kill it.
Anyhow, the point with realms should be to not lock out any reasonable
types of use. For example, I should be able to do a normal login into
the Athena realm, get appropriate Athena tickets, and then also do a
kinit into a DEC realm. This should be possible even if Athena and
DEC dont know about each other. As long as "rlogin", et. al, understand
how to figure out what realm is needed, they can obtain and use the
right tickets.
So I think you should be able to support tickets for multiple realms
concurently. The current ticket file, and its utilities may need to
be enhanced to do this.
Steve.
--[0142]--
\f
[0143] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (21 lines)
Subject: Bug with kerberos rlogin
From treese@ATHENA.MIT.EDU Sat Nov 8 23:40:11 1986
From: treese@ATHENA.MIT.EDU
Date: Sat, 8 Nov 86 23:39:04 EST
To: kerberos
Cc: wdc
Subject: Bug with kerberos rlogin
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
Though I have not attempted to reproduce this at will, it appears that
when a kerberos rlogin fails because the tickets have expired (after a
marathon session at a workstation...), it prompts for a password. Even
if the password is carefully typed (i.e., I'm sure I got it right), the
rlogin fails and prompts for "login:".
Has anyone else noticed this? (I cc'ed Bill Cattey since I have often
heard him complain about tickets expiring).
- Win
--[0143]--
\f
[0144] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (33 lines)
Subject: Re: Bug with kerberos rlogin
From ostlund@ATHENA.MIT.EDU Mon Nov 17 17:32:06 1986
From: ostlund@ATHENA.MIT.EDU
Date: Mon, 17 Nov 86 17:30:41 EST
To: treese
Subject: Re: Bug with kerberos rlogin
Cc: kerberos, wdc
From treese@ATHENA.MIT.EDU Sat Nov 8 23:39:31 1986
To: kerberos@ATHENA.MIT.EDU
Subject: Bug with kerberos rlogin
Though I have not attempted to reproduce this at will, it appears that
when a kerberos rlogin fails because the tickets have expired (after a
marathon session at a workstation...), it prompts for a password. Even
if the password is carefully typed (i.e., I'm sure I got it right), the
rlogin fails and prompts for "login:".
Has anyone else noticed this? (I cc'ed Bill Cattey since I have often
heard him complain about tickets expiring).
- Win
---------------
Sorry, this escaped from my input queue somehow. Yes, this is a known
bug. Worse than what you've reported is that the TERMCAP environment
variable ends up set to "network" even after you successfully log in.
At present, you have to know to bail out, get fresh tickets, and try
again.
John
--[0144]--
\f
[0145] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:33 (19 lines)
Subject: sources moving to paris (eventually)
From ostlund@ATHENA.MIT.EDU Wed Nov 19 12:37:07 1986
From: ostlund@ATHENA.MIT.EDU
Date: Wed, 19 Nov 86 12:36:27 EST
To: kerberos
Subject: sources moving to paris (eventually)
As I announced a few weeks ago, the master sources for Kerberos are
moving from menelaus to paris. Due to disk space shortage on paris,
this move is happening by way of castor. The master sources for
Kerberos are now in castor:/projects/auth/release/861106. DON'T
make changes to the sources on menelaus, or your changes may get
lost in the shuffle. Thanks. (Before the sources actually get
put on paris, we will probably [a] convince the Makefiles to work,
[b] integrate the RT Kerberos code now on styx, [c] integrate
knetd, and [d] fix miscellaneous bugs. This will all get done on
castor.)
John
--[0145]--
\f
[0146] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (95 lines)
Subject: [Mike Kazar: Re: A few questions]
From wesommer@ATHENA.MIT.EDU Mon Nov 24 09:43:14 1986
To: watchmakers, kerberos
Subject: [Mike Kazar: Re: A few questions]
Date: Mon, 24 Nov 86 09:41:53 EST
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I asked Mike Kazar of CMU to describe the authentication scheme used by the
Vice fileserver; since the security of this was under discussion earlier
I figured that it would be appropriate to forward this to the list.
By the way, I made the Kerberos paper available to him via anonymous FTP,
since he showed some interest in it.
------- Forwarded Message
Return-Path: @po5.andrew.cmu.edu:kazar#@andrew.cmu.edu
Received: by PRIAM.MIT.EDU (5.45/4.7) id AA06596; Mon, 24 Nov 86 09:03:44 EST
Received: by ATHENA (5.45/4.7)
id AA10844; Mon, 24 Nov 86 09:03:27 EST
Received: by po5.andrew.cmu.edu (4.12/3.15) id <AA00369>; Mon, 24 Nov 86 08:59:51 est
Received: FROM mooncrest VIA queuemail
ID </cmu/common/mailqs/q006/QF.mooncrest.1fc85d25.1f8>;
Mon, 24 Nov 86 08:59:03 est
Message-Id: <MS.V3.18.kazar.80020c0c.mooncrest.ibm032.1181.1@andrew.cmu.edu>
Date: Mon, 24 Nov 86 08:58:58 est
From: kazar#@andrew.cmu.edu (Mike Kazar)
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Subject: Re: A few questions.
The next release of venus will not use .cx or .hx files at all for the reason
you just hit. Unfortunately, bec requires the based editor 1 library as part
of it, and that is not a trivial thing to ship. How about I just send you
the object file version of bec, and you run it on your .cx and .hx files.
What machine type do you want it for? When I hear from you, I'll put the
appropriate machine type bec's on cmu's H vax, and you can ftp it over.
Anyway, all further vice updates will include the sources in regular text
file format.
As for our authentication scheme, it is essentially the one described under
Needham and Schroder's standard paper on the encryption. In particular, the
only thing shipped over the network in the clear is what we call a "secret
token", which is really a session key generated by the authentication server,
and encrypted with the file server's password. This session key, by virtue
of being encrypted with the file server's password, is useless for
eavesdroppers. Once it has been received by the file server, the secret
token is decrypted, yielding both the session key to use with this session,
and a time, set by the authentication server, that the token should be
considered obsolete. Our system currently runs with that time being 25
hours, after which the user of a vice console must re-authenticate using
login or the "log" program. After that time, the connection drops to an
unauthenticated level, and you are so warned by our console program.
Hopefully in the next release, venus will actually warn you before the token
expires.
That's the scheme, however, we're running a modified version thereof for
performance reasons. First of all, we have no DES hardware, so we use XOR
instead of DES. This is, of course, infinitely more susecptible to a known
cleartext attack. Secondly, at cmu we do not encrypt the packets used for
regular vice traffic at all.
We plan to remedy most of these problems in the next release. In particular,
while the cost of running DES in software is high, authentication happens
rarely enough that we can actually use it for conversations with the
authentication server without too much trouble, I believe. So, one item that
should get fixed shortly is that the secret token will really be encrypted
with DES.
The problem with the day-to-day traffic, however, is worse. We plan to offer
both headers-only encryption and whole-packet encryption modes, at a user's
option, but frankly, remote procedure call headers are so susceptible to
known clear-text attack that we may as well not bother doing any encryption
at all unless we use something better than XOR for the algorithm.
In short, while the framework is present for doing our full algorithm in a
secure manner, our use of XOR instead of DES means that it is possible, by
spying on the network, to inject a call into an RPC stream. This will screw
up the connection as far as the real user is concerned, but the injected call
will get handled.
What encrypted algorithm do you plan to use? How do you plan to get it to
run fast enough?
Yes, I would be very interested in seeing the Kerberos paper. I don't see
any real problems with you guys putting your own authentication system in
venus; it shouldn't take much work to figure out how to fit it in.
Mike
------- End of Forwarded Message
--[0146]--
\f
[0147] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (24 lines)
Subject: Kerberos sources
From treese@ATHENA.MIT.EDU Mon Nov 24 19:06:36 1986
From: treese@ATHENA.MIT.EDU
Date: Mon, 24 Nov 86 19:05:34 EST
To: kerberos, watchmakers, developers
Subject: Kerberos sources
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
(I don't think this got to everyone, so I am sending it again.)
The Kerberos master sources now live on paris (currently in /source/kerberos).
Any changes made for release should be made there, and I should be notified
that they are taking place (i.e., same rules as for the rest of the
master sources).
Thanks,
Win
--[0147]--
\f
[0148] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (16 lines)
Subject: Kerberos-authenticated RVD server
From treese@ATHENA.MIT.EDU Sun Nov 30 00:34:36 1986
From: treese@ATHENA.MIT.EDU
Date: Sun, 30 Nov 86 00:33:13 EST
To: rvd-info, kerberos
Subject: Kerberos-authenticated RVD server
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
...is now up and running on priam. This version requires some additions
to the rvddb file. I expect to have it running on pollux and agamemnon
by sometime tomorrow. Old versions of the client code can talk to it;
the new client code will be in the coming release.
- Win
--[0148]--
\f
[0149] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (16 lines)
Subject: Re: Kerberos-authenticated RVD serve
From henry@ATHENA.MIT.EDU Sun Nov 30 00:39:12 1986
To: treese@athena.mit.edu
Cc: rvd-info@athena.mit.edu, kerberos@athena.mit.edu
Subject: Re: Kerberos-authenticated RVD server
In-Reply-To: Your message of Sun, 30 Nov 86 00:33:13 EST.
<8611300533.AA00326@CIROCCO>
Date: Sun, 30 Nov 86 00:39:05 -0500
From: Henry Mensch <henry@ATHENA.MIT.EDU>
>> the new client code will be in the coming release.
in WHICH new release?
-- Henry
--[0149]--
\f
[0150] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (18 lines)
Subject: Re: Kerberos-authenticated RVD serve
From treese@ATHENA.MIT.EDU Sun Nov 30 01:50:08 1986
From: treese@ATHENA.MIT.EDU
Date: Sun, 30 Nov 86 01:48:45 EST
To: Henry Mensch <henry@ATHENA.MIT.EDU>
Cc: rvd-info@athena.mit.edu, kerberos@athena.mit.edu
In-Reply-To: Henry Mensch's message of Sun, 30 Nov 86 00:39:05 -0500
Subject: Re: Kerberos-authenticated RVD server
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
>> in WHICH new release?
The release scheduled to go to the world on January 1, and the staff
on December 1. As far as I am concerned right now, this is the only
release that exists.
- Win
--[0150]--
\f
[0151] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (17 lines)
Subject: Source code control
From treese@ATHENA.MIT.EDU Mon Dec 1 03:38:46 1986
From: treese@ATHENA.MIT.EDU
Date: Mon, 1 Dec 86 03:37:26 EST
To: kerberos
Subject: Source code control
Us-Snail: E40-342B, 1 Amherst St, Cambridge, MA 02139
I am freezing the kerberos sources on paris until they can be cleaned up
(i.e., reasonable makefiles, everything checked in under RCS, etc.)
If changes must be made, please see me first.
Thanks,
Win
--[0151]--
\f
[0152] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:34 (12 lines)
Subject: Visit
From miller%erlang.DEC@decwrl.DEC.COM Fri Dec 12 16:31:09 1986
Date: 12-Dec-1986 1612
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
miller%erlang.DEC@decwrl.DEC.COM
Subject: Visit
I thought I would come visit either Tues, Dec 16, or Friday, Dec 19.
Any preferences?
--[0152]--
\f
[0153] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (13 lines)
Subject: Visit Friday
From miller%erlang.DEC@decwrl.DEC.COM Mon Dec 15 10:44:31 1986
Date: 15-Dec-1986 1035
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB), dec@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
Subject: Visit Friday
Looks like Friday is better due to the Human Interface/Toolkit meeting
Tuesday, so I'll be in Friday morning and can spend most of the day.
Steve.
--[0153]--
\f
[0154] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (33 lines)
Subject: Cleanup of DES library.
From wesommer@ATHENA.MIT.EDU Tue Jan 13 18:17:53 1987
Date: Tue, 13 Jan 87 18:17:57 EST
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Sender: wesommer@ATHENA.MIT.EDU
To: kerberos
Subject: Cleanup of DES library.
Cc: jis, shew, treese, mckie
I have just finished a major cleanup of the DES library configuration.
The two directories lib/des/vax and lib/des/ibmws have been merged
into a single directory lib/des/bsd; architecture dependancies in the
code which are #ifdef'ed on various tags now depend on the inclusion
of the file des_conf.h, which contains two sets of declarations (one
for the VAX, one for the RT), #ifdef'ed on "vax" and "ibm032".
I had to make a number of fixes to support the new IBM compiler (which
lints and compiles in one pass), and I have not yet cleaned up all of
the things which it warns about (such as unreferenced variables, etc).
The library has been successfully regression-tested using the test
suite, and kinit and other Kerberos client programs are known to work
with it on both VAX and RT. Also, all source files are known to be
checked in and cleaned up by Release Engineering standards. (Win,
sorry for filling your mailbox with notifications of forced breaking
of RCS locks..).
The sources have not yet been moved back over & installed on Paris
(since PAZ.MIT.EDU just crashed for unknown reasons); this will be
done as soon as PAZ is back up.
- Bill
--[0154]--
\f
[0155] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (39 lines)
Subject: Ooops. SMS cannot store keys that ge
From jis@BITSY.MIT.EDU Wed Jan 28 00:49:20 1987
Date: Wed, 28 Jan 87 00:48:14 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@athena.mit.edu
Cc: Kerberos@Athena.mit.edu
Subject: Ooops. SMS cannot store keys that get loaded into kerberos.
The following problem came up during a conversation between
Melissa and myself.
The current design of the kerberos database enciphers the
private keys of users and services with the kerberos "master" key.
This protects the keys from disclosure, but does not "seal" them
against modification.
Specifically it is still possible to copy one user's key
information onto another, and thus make the second user's key the same
as the first.
If SMS loads all information into kerberos, then all one would
have to do to forge the id of some user (assuming breaking into SMS
first), is to make that user's private key data equal to the data for
the forger's private key, and wait for the next SMS => kerberos
download.
I can see two ways to prevent this:
1) Not store private key information in SMS, Kerberos would be
responsible for long term storage of the keys.
2) Change the master key encipherment so that first the first eight
characters (64 bits) of the principal name is Xor'd into the private
key and then enciphered with the master key. This would ensure that
two users with the same key (password) don't have identical values
stored in the database for their keys, and the attack above is
thwarted.
-Jeff
--[0155]--
\f
[0156] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (31 lines)
Subject: /source/kerberos/client/crp.c (or ho
From jis@BITSY.MIT.EDU Thu Jan 29 18:50:02 1987
Date: Thu, 29 Jan 87 18:49:24 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: treese@athena.mit.edu, wesommer@athena.mit.edu, geer@athena.mit.edu
Cc: kerberos@athena.mit.edu
Subject: /source/kerberos/client/crp.c (or how to change a root instance)
This program allows an individual to change the password associated
with their root instance. It works through the same backend that
the "admin" program uses (and which will eventually be merged with
the passwd backend program).
You can also optionally give a "-name" or "-inst" control argument so
you can use it to change the password of an arbitrary name and instance
(as long as you know the old password).
It isn't installed anywhere (though the Makefile has been modified and
a binary built on paris). Win, can you take care of distributing it?
(Also note, I don't care you want to change its name...."crp" may
not be the best name).
Also note: The coding standards employed are not completely up to my
normal "standards" so I will want to checkin a cleaned up version at
some point, but the code is correct as is (ie. I want to cleanup the
comments and do some of the error reporting differently). I tested
it against both legitimate and illegit uses...
-Jeff
--[0156]--
\f
[0157] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (62 lines)
Subject: Re: Ooops. SMS cannot store keys th
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.
--[0157]--
\f
[0158] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (59 lines)
Subject: Thoughts on the protection of the ma
From jis@BITSY.MIT.EDU Fri Jan 30 18:06:51 1987
Date: Fri, 30 Jan 87 18:05:54 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@athena.mit.edu
Subject: Thoughts on the protection of the master key AND database.
The more I think about this issue, the more I think that the
number of systems playing with the kerberos database should be kept to
a minimum. Probably only kerberos itself.
The kerberos database master key (and associated password)
have an interesting property. That is, it has residual value even if
it is changed. Consider the following form of attack:
Grab a copy of the database somehow (poach a backup tape, or
intercept the database being FTP'd in the clear, or have read-only or
write access to the SMS database, whatever...) Now this copy is
useless because all of the secret information is enciphered with the
master key. However bide your time.... At some point the master key is
changed, once changed people are likely to not have any inhibition
from giving out the OLD key (after all it has been changed...). Now
you have a copy of the OLD database AND the old master key. You can
now decrypt your data and obtain the secret key for any principal
which has not changed their key since the time you grabbed the
database. You will probably get a significant number of both user
private keys AND service keys.
This of course is based on the psychology of password
maintenance. Specifically taking advantage that most people consider
an OLD password as no longer confidential.
This leads me to believe that instead of hairing up the master
key encipherment process on private keys, that instead efforts be made
to protect the database from disclosure regardless of the fact that
secret information is enciphered in the master key.
This leads to two changes in direction.
1) SMS should not have a copy of key data from kerberos. This isn't
really necessary anyhow, as all data in SMS can be linked to the
appropriate record in kerberos by the principal (name,instance) fields
which SMS would still have a copy of.
2) Slave kerberos database propagation, which currently sends the
database in the clear, be changed to use a kerberos authenticated
connection to send the data AND use the session key provided by
kerberos to either encipher ALL the data going across the connection,
or at the very least the private key fields.
Because SMS will not have a copy of ALL the information stored
on kerberos, kerberos will need to be a backed up service (ie. the
database should be periodically backed up [which it is today...once a
day to tape]) and the backup media should be protected (ie. stored in
a locked room).
-Jeff
--[0158]--
\f
[0159] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (22 lines)
Subject: re: /source/kerberos/client/crp.c (o
From Saltzer@ATHENA.MIT.EDU Sun Feb 1 19:42:33 1987
Date: Sun, 1 Feb 87 19:40:16 EST
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Subject: re: /source/kerberos/client/crp.c (or how to change a root instance)
Cc: treese@athena.mit.edu, wesommer@athena.mit.edu, geer@athena.mit.edu,
kerberos@athena.mit.edu
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Thu, 29 Jan 87 18:49:24 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> This program allows an individual to change the password associated
> with their root instance. It works through the same backend that
> the "admin" program uses (and which will eventually be merged with
> the passwd backend program).
Why not name this program chpass, make its default instance the null
instance, and make it the normal way of changing all passwords? (Or
name it "passwd" if the additional semantics of -name and -inst don't
create a documentation incompatibility mess.
Jerry
--[0159]--
\f
[0160] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:35 (64 lines)
Subject: re: Thoughts on the protection of th
From Saltzer@ATHENA.MIT.EDU Sun Feb 1 19:42:43 1987
Date: Sun, 1 Feb 87 19:40:12 EST
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Subject: re: Thoughts on the protection of the master key AND database.
Cc: kerberos@athena.mit.edu
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Fri, 30 Jan 87 18:05:54 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> The kerberos database master key (and associated password)
> have an interesting property. That is, it has residual value even if
> it is changed.
Jeff's concern for attack using old, less-well protected keys is a
good one. That concern raises several further interesting points.
1. The double-edged sword. When the master key is changed, previous
backup copies become worthless. (Well, not completely; if you
remember the old master key you could reload the old backups, and
rechange the key. But the point of changing the key is to stop being
dependent on it.) So the key change procedure providing both
security and integrity probably goes like this:
- change the master key
- make a couple of new backup tapes and reload one of them to make
sure it is really valid.
- destroy all copies of the old master key and degauss all old
backup tapes.
- load (by hand, I think) the slave servers with the new master
key but tell them not to use it yet.
- send the slave servers the new data base and tell them cut over
to the new master key when they switch to the new data base.
2. Degaussing old backup tapes can help minimize the risk that Jeff
suggests, namely that people may be less protective of old master
keys than new ones.
3. Whether SMS or private backup tapes are used as the backup
mechanism, it might still be wise to encipher/seal keys in a block
containing the associated principal identifer, in order to inhibit
any kind of substitution attack. The one objection is decryption
time, which is serial with each authentication. If we had some
supported decryption hardware for use in the Kerberos servers I think
it would be worth doing this step. While awaiting arrival of such
hardware the idea probably has to be commented out.
4. I agree that SMS does not need to feed Kerberos. I claim further
that the principal identifier field is the ONLY item that needs to be
duplicated between the two data bases, and it provides an adequate
link between the information on record in the two places. There are
two more advantages of keeping SMS clear of Kerberos:
- Kerberos is then forced to be self-sufficient in management
tools, which helps insure its modular exportability.
- it is possible to have Kerberos-authenticable identities that are
not known to SMS. That could be useful in any case where the
administrative boundaries surrounding SMS and Kerberos don't
exactly coincide. (For example, one Kerberos realm might cover
Athena, Administrative Computing, and Telecommunications, while
SMS might maintain information only about Athena.)
Jerry
--[0160]--
\f
[0161] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (22 lines)
Subject: /source/kerberos/client/crp.c (or ho
From jis@BITSY.MIT.EDU Sun Feb 1 20:11:58 1987
Date: Sun, 1 Feb 87 20:11:07 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: treese@athena.mit.edu, wesommer@athena.mit.edu, geer@athena.mit.edu,
kerberos@athena.mit.edu
In-Reply-To: Jerome H. Saltzer's message of Sun, 1 Feb 87 19:40:16 EST <8702020040.AA18912@HERACLES>
Subject: /source/kerberos/client/crp.c (or how to change a root instance)
There is a catch. /bin/passwd also changes your password in the password
file on the local machine and instructs kerberos to update the athenareg
database as well. "crp" (or chpass, that is just as good a name) makes no
attempt to fool around with either a password file or athenareg (though
it turns out you can use '-inst ""' and it will change your login password,
for those times when login uses kerberos authentication).
Clearly in the long run this will be THE password changing program (or
a variant of it). However for now we need /bin/passwd's current behavior
for compatability.
-Jeff
--[0161]--
\f
[0162] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (26 lines)
Subject: On the backup of kerberos.
From jis@BITSY.MIT.EDU Sun Feb 1 20:18:44 1987
Date: Sun, 1 Feb 87 20:17:56 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@athena.mit.edu
In-Reply-To: Jerome H. Saltzer's message of Sun, 1 Feb 87 19:40:12 EST <8702020040.AA18909@HERACLES>
Subject: On the backup of kerberos.
The current scheme uses three backup tapes that are rotated through.
A tape gets written each night with three snapshots of the kerberos
database, one from each of the previous three nights.
This scheme has the advantage that only three tapes ever have confidential
data on them to worry about. The disadvantage is that we only save information
for the previous five days (the oldest data being from the oldest file
on the oldest tape). This also makes it unnecessary to deguass any
tapes just because the kerberos master key was changed.
As it turns out we have already had one tape fail, and that tape is
now waiting for me to take it to W91 for deguassing.
-Jeff
--[0162]--
\f
[0163] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (74 lines)
Subject: Protecting Kerberos
From miller%erlang.DEC@decwrl.DEC.COM Thu Feb 12 08:28:43 1987
Date: 11-Feb-1987 1752
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Protecting Kerberos
From: RHEA::DECWRL::MAILER-DAEMON "Mail Delivery Subsystem" 9-FEB-1987 07:47
To: <erlang::miller (Steve Miller)>
Subj: Returned mail: Cannot send message for 3 days
----- NOTICE -----
Due to a hardware failure, DECWRL has been disconnected from
the Internet for several days. We hope to be reconnected some-
time Monday, Feb 9, 1987. Please give us a chance to recover
and then retry your message.
----- Transcript of session follows -----
I agree with the recent notes by Jeff and Jerry re protecting the
OLD master key and backup copies of the database. Kerberos must be
protected!
The only other solution to losing an old master key would be to
invalidate all the principal keys every time the master key changed.
Then a new key could be established by a protocol that passed the old
password STRING to the password server, before its one-way encryption into
the key form. If that was ok, a new key could be created. Meanwhile,
the old key, compromised by the disclosure of the old Master key, would
not be valid for routine authentication. Since the Kerberos database
already contains a master key version field for each entry, enough hooks
currently exist to do this. This may be too drastic a step for the
Athena environment, but the alternative is to potentially compromise
all the keys.
I would also suggest that the slave copies of the database dont even
use the master key at all. Instead of encrypting the database (or at least
key fields) with a session key in order to transmit it between the master
and the slave, the master can just convert it to be encrypted under
the session key, or some other temporary key. Thus the slave database
has its key fields encrypted by some key OTHER than the master key, and
it changes every time a new slave database version is loaded. This
provides much more protection for the master key, since it now
exists on the master database only.
In other words, where E(foo)bar means Encrypt 'foo' with key 'bar'
Let PrinKey == my principal key
master: EncPrinKey = E(PrinKey)Kmaster /* master encrypts my prin key*/
master: store(EncPrinKey) /* master stores encrypted key*/
master: SlaveKey = E(D(EncPrinKey)Kmaster)Kslave /* master decrypts and
re-encrypts my prin key
using Kslave */
master: ProtSlaveKey = E(SlaveKey)Ksession /* master encrypts SlaveKey for
secure transmission */
master --> slave: ProtSlaveKey /* master transmits sealed key*/
slave: SlaveKey= D(ProtSlaveKey)Ksession /* slave decrypts received key*/
slave: store(SlaveKey) /* slave stores SlaveKey */
slave: PrinKey = D(SlaveKey)Kslave /* slave decrypts to yield PrinKey
upon Kerberos requests */
Ksession is used to protect the transfer, using the private_msg() or
equivalent.
Kslave is another 'session' key used as the temporary 'master' for the
slave.
Despite the best reasonable efforts, sooner or later major Kerberos
security problems, such as disclosing an old master key, will occur. I would
strongly suggest that Jerry, Jeff and others walk through some likely
scenarios and recovery procedures.
Steve.
--[0163]--
\f
[0164] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (46 lines)
Subject: re: Protecting Kerberos
From Saltzer@ATHENA.MIT.EDU Thu Feb 12 10:21:57 1987
Date: Thu, 12 Feb 87 10:19:17 EST
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Subject: re: Protecting Kerberos
Cc: kerberos@athena.mit.edu (Distribution list @KERB)
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 11-Feb-1987 1752
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Steve,
I like the idea that the slaves have their database enciphered with a
temporary Slave Key rather than the real master, to reduce the number
of exposure points for the master. But I don't think your specific
proposal is as effective as it sounds. The problem is that your
scenario sends the new Slave Key enciphered with KSession. Where did
Ksession come from? Presumably it is a result of an authenticated
handshake between the slave and the master. And how did that
handshake get authenticated? Presumably by virtue of a private key
known only to the slave and to some Kerberos, probably the master.
So now the slave's private key becomes an effective "master key",
albeit two steps removed, with the usual problems of future
disclosure. The one advantage your scenario provides is make it
necessary that an attacker who has discovered that private key be
present at the right time so as to watch the initial handshake (so as
to discover Ksession) and also to snatch a copy of
E(SlaveKey)Ksession as it goes by. Assuming everyone is careful to
destroy Ksession as soon as SlaveKey is safely acquired by the slave,
the attack work factor is certainly somewhat higher than if the slave
database is simply enciphered with the Master key.
There is also an availability problem: following a power failure, for
example, the slave Kerberos can't begin work again until it has been
reloaded from the Master Kerberos, unless it took the precaution of
preserving both its old data base and the SlaveKey that is
enciphering it. But preserving the SlaveKey in the persistent
storage of the slave machine is exactly the action that (I assume)
you are trying to avoid, so as to minimize its risk of disclosure.
I agree that we need to work out the best approach to handling the
case where a first-class compromise of the master key occurs.
Jerry
--[0164]--
\f
[0165] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (43 lines)
Subject: More re Protecting kerberos
From miller%erlang.DEC@decwrl.DEC.COM Tue Feb 17 20:18:36 1987
Date: 17-Feb-1987 0939
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: More re Protecting kerberos
(The gateway from the DEC engineering net to the Arpanet , 'decwrl',
has been flaky lately, so mail is being delayed and bounced around. spm)
----------------
Jerry,
You are right, my last suggestion only shifts the attack from the
master key to the interchange key between the slave database and
the master Kerberos database. Though it does make it a little harder.
The only way it might work, and still address the availability problem
is if you could afford, operationally, to create new interchange keys
between the slave db and master db every time an update was made,
manually distribute them out of band (Jeff on roller skates!), feed
them to the slaves, then immediately destroy them as soon as the
update protocol had fired up. On powerfail, Jeff on Skates would have
to redo the procedure, but unless all slaves power-failed at once,
Kerberos would still be available. But it would still leave a slave
key resident at the slave, subject to attack, even though no one
had ever directly seen it.
I conclude that it is not worth the effort for Athena for a minor
improvement in security. The only solution is real physical security
of the master keys, backup tapes, maybe even real crypto boxes, key guns, etc.
Perhaps some time before we all retire, Public key can be made fast
enough to allow a 3-way public-key based handshake without the
direct intervention of a 3rd party (Kerberos server) with critical
secrets. Note that Kerberos not only authenticates, but enforces an
expiration date on principals, which would not be possible in a
2-party Public Key exchange. (Assume that the public half is published.)
Introducing the 3rd party introduces that critical secret -- in one case
a Kerberos DES master key, in another an RSA (or similar) public half of
the key-pair.
--[0165]--
\f
[0166] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (32 lines)
Subject: On the security of kerberos (need fo
From jis@BITSY.MIT.EDU Wed Feb 18 15:58:19 1987
Date: Wed, 18 Feb 87 15:56:30 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@athena.mit.edu
Subject: On the security of kerberos (need for physical security)
All this talk of how to deliver the keys isn't really addressing the
likeliest form of attack, namely:
1) Obtain physical access to a kerberos slave machine.
2) Deposit a trap door program that allows a remote root login at
a later time.
3) Arrange it to look like the system crashed in some "normal" maner.
4) Wait for the system to be restarted.
5) Now while the machine is running, utilize trap door, make a copy of the
database and use the "gcore" program to grab a core image of the
running kerberos server and extract the master key (or the equivalent
of the master key for the database copy you must made).
6) Done. And let Athena beware!
Providing physical security is the key here (no pun intended). Encryption
hardware would help (if the hardware allows the key to be written, but
not read out, and it clears the key memory on bus reset).
-Jeff
--[0166]--
\f
[0167] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:36 (17 lines)
Subject: rcp protocol screwup
From Saltzer@ATHENA.MIT.EDU Tue Mar 3 18:41:36 1987
Date: Tue, 3 Mar 87 18:39:10 EST
To: bugs, kerberos
Subject: rcp protocol screwup
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Running on Paris, I just tried to rcp a file from my RT, and
got the following message. . .
rcp: protocol screwup: mtime.sec not delimited
the file did not transfer.
Jerry
--[0167]--
\f
[0168] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (14 lines)
Subject: tftp
From treese@ATHENA.MIT.EDU Sat Mar 7 19:19:33 1987
From: treese@ATHENA.MIT.EDU
To: bugs@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
Subject: tftp
...doesn't work. Among other things, the name "menelaus" is hard-coded into
the call to mk_ap_req().
This needs to be fixed...
- Win
--[0168]--
\f
[0169] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (16 lines)
Subject: re: tftp
From Saltzer@ATHENA.MIT.EDU Sat Mar 7 22:44:03 1987
Date: Sat, 7 Mar 87 22:41:36 EST
To: <treese@ATHENA.MIT.EDU>
Cc: kerberos
Subject: re: tftp
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Sat, 7 Mar 87 19:17:39 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Can anyone direct me to the sources for the Kerberized version of
PC/tftp? Presumably there is also a login/get-ticket command.
Jerry
--[0169]--
\f
[0170] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (16 lines)
Subject: Re: tftp
From treese@ATHENA.MIT.EDU Sat Mar 7 23:13:56 1987
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
Subject: Re: tftp
In-Reply-To: Your message of Sat, 07 Mar 87 22:41:36 -0500.
Date: Sat, 07 Mar 87 23:11:58 EST
From: Win Treese <treese@ATHENA.MIT.EDU>
paris:/src/athena.lib/kerberos/services/tftp.
(not obvious, I know)
- Win
--[0170]--
\f
[0171] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (21 lines)
Subject: Re: tftp
From wesommer@ATHENA.MIT.EDU Sat Mar 7 23:45:37 1987
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Sender: wesommer@ATHENA.MIT.EDU
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sat, 7 Mar 87 22:41:36 EST
<8703080341.AA09987@HERACLES>
Subject: Re: tftp
One thing I should warn you: you may have to do a bit of hacking on
the DES library; it used to work on PC's, but as I rearranged the
sources to get the same source tree to work on both VAX and RT, I may
have inadvertantly broken the PC DES library. (Sorry, but Athena got
out of the business of supporting IBM PC's - and I remember diking out
a few grossnesses used to support the PC cross-compiler in a makefile
cleanup). I didn't go out of my way to break the IBM PC stuff, but I
didn't waste time testing it either..
- Bill
--[0171]--
\f
[0172] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (19 lines)
Subject: Re: tftp
From treese@ATHENA.MIT.EDU Sun Mar 8 16:54:44 1987
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>, treese@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
Subject: Re: tftp
In-Reply-To: Your message of Sun, 08 Mar 87 14:23:38 -0500.
Date: Sun, 08 Mar 87 16:52:41 EST
From: Win Treese <treese@ATHENA.MIT.EDU>
Jerry,
The copy in /u1/auth on paris was not touched by Bill (as far as I know).
However, I don't think that his work really touched the tftp sources, just
the makefile support for the PC subdirectories.
- Win
--[0172]--
\f
[0173] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (15 lines)
Subject: Re: tftp
From wesommer@ATHENA.MIT.EDU Sun Mar 8 17:00:14 1987
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Sender: wesommer@ATHENA.MIT.EDU
To: Win Treese <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Win Treese's message of Sun, 08 Mar 87 16:52:41 EST
<8703082152.AA10705@CIROCCO.MIT.EDU>
Subject: Re: tftp
That's correct. I didn't touch tftp at all, except to change a few
routine calls to use "newer" names.
- Bill
--[0173]--
\f
[0174] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:37 (29 lines)
Subject: PC sources
From miller%erlang.DEC@decwrl.DEC.COM Mon Mar 9 10:25:29 1987
Date: 09-Mar-1987 1001
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
miller%erlang.DEC@decwrl.DEC.COM
Subject: PC sources
The last I worked on it, there was one set of DES library sources, with
sufficient conditional compilations defined such that it would work for
either the VAX, PC, or RT. The DES library is independent of the
rest of the Kerberos protocol library stuff, which I recall was NOT
updated to follow the revisions in the Kerberos protocol spec.
I also have some backup copies floating around if the need arises.
To check out the DES library on the PC (or elsewhere) there is a
test program called "verify" in with the sources. It runs some standard
tests of the algorithm, from the FIPS spec, and displays the computed
output as well as the expected output, which you then can inspect by eye
to determine if the library is obviously wrong.
All the PC stuff was built for the LCS cross-compiler and loader, not any
of the native PC utilities.
(P.s. the "not updated" above refers to the PC only. Should have used
the editor to compose this!).
( P.p.s. not updated also refers only to the Kerberos library, not the
DES library.)
--[0174]--
\f
[0175] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (31 lines)
Subject: DES library for IBM PC
From Saltzer@ATHENA.MIT.EDU Sun Mar 15 00:36:13 1987
Date: Sun, 15 Mar 87 00:33:25 EST
To: kerberos
Subject: DES library for IBM PC
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
I'm trying to revive Kerberos on the IBM PC; right now I'm trying to
build the DES library. Can anyone offer help on the following
details:
1. A couple of programs in libdes.a call on the 4.2 C-library
functions bzero() and bcmp(). Those two functions aren't part of the
standard CC86 C-library. Cliff and Steve: did one of you write
versions of those functions for the PC? I didn't find them anywhere.
Or did those calls get added to the sources after the last time
libdes was checked out on the PC?
2. For the PC/8086, should the compile-time parameter BIG be defined
or not? From the three places it is used I couldn't figure out just
what BIG does--something about enabling a table-driven permutation
transformation, I think.
3. Do I recall correctly that the PC/8086 has its bytes in the same
order as the RT?
Thanks.
Jerry
--[0175]--
\f
[0176] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (32 lines)
Subject: Re: DES library for IBM PC
From BCN@WARD.CS.WASHINGTON.EDU Sun Mar 15 01:24:16 1987
Date: Sat 14 Mar 87 22:22:45-PST
From: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Subject: Re: DES library for IBM PC
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8703150533.AA06986@HERACLES>
I wrote a few routines for the PC, and they can be found in
/mit/b/c/bcn/kdst/lib/krb/pc.c. I expect there is still a copy in the
master sources, but it may have been removed since I left. Tis file
contains 3 four line procedures.
Since steve did the DES stuff, I am not sure what BIG is for, but if I
recall correctly then, by setting BIG, a more time efficient approach
is taken, but at the cost of space. Unfortunately, on the XT we were
very limited in the maximimum program size.
I am not sure about the byte/bit ordering question, but I think that
there was some difference between the XT and the RT. I may be wrong
though.
~ Cliff
-------
--[0176]--
\f
[0177] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (30 lines)
Subject: Re: DES library for IBM PC
From Saltzer@ATHENA.MIT.EDU Mon Mar 16 09:54:17 1987
Date: Mon, 16 Mar 87 09:51:10 EST
To: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Subject: Re: DES library for IBM PC
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>'s message of Sat 14 Mar 87 22:22:45-PST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
> I wrote a few routines for the PC, and they can be found in
> /mit/b/c/bcn/kdst/lib/krb/pc.c. I expect there is still a copy in the
> master sources, but it may have been removed since I left. Tis file
> contains 3 four line procedures.
They were there, and they supplied the two missing routines as well
as a third one that I hadn't missed yet.
> Since steve did the DES stuff, I am not sure what BIG is for, but if I
> recall correctly then, by setting BIG, a more time efficient approach
> is taken, but at the cost of space. Unfortunately, on the XT we were
> very limited in the maximimum program size.
The DES library now compiles, runs, and verifies on the PC again. BIG
is switched on, but I may need to switch it off when I try to load
the library with anything useful.
Thanks for your help.
Jerry
--[0177]--
\f
[0178] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (31 lines)
Subject: help: pc sources missing
From Saltzer@ATHENA.MIT.EDU Thu Mar 19 11:05:33 1987
To: spm, bcn
Cc: kerberos
Subject: help: pc sources missing
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Steve and Cliff,
At this point I have the DES and Kerberos libraries working well
enough on the PC that I can get ticket-granting tickets with pclogin.
So now I need an application to try out.
After considerable searching, it appears that the sources for the
Kerberos version of PC/tftp are nowhere online at Athena. By chance
do either of you have a copy squirreled away somewhere?
The particular programs needed have names like "tftp_srv.c",
"tftp_use.c" and "tftp_util.c". Since PC/tftp is organized as a
library that may be used by various commands, the sources for the
Kerberos version may have been placed in the library section of the
pcip source hierarchy. It looks like the whole pcip source hierarchy
was deleted somewhere along the line.
Another possibility is a dusty backup tape, either a standard one, or
a special one hiding in someone's desk. Any idea what the date
should look like on such a backup tape or where there might be one?
Jerry
--[0178]--
\f
[0179] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (22 lines)
Subject: re: help: pc sources missing
From Saltzer@ATHENA.MIT.EDU Thu Mar 19 16:48:29 1987
Subject: re: help: pc sources missing
Cc: kerberos
To: spm, bcn
In-Reply-To: Jerome H. Saltzer <Saltzer>'s message of Thu, 19 Mar 87 11:03:27 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Here is a little more on the missing pc/tftp sources. . .
1. From references in an old makefile, it looks like the directory
containing the sources I am looking for was probably under
/projects/auth/ibm/.
2. The oldest backup tape that Berni could find (from last December,
actually so it isn't very old) doesn't have that directory, or
anything else that would help.
Jerry
--[0179]--
\f
[0180] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (17 lines)
Subject: Mystery subdirectories
From treese@ATHENA.MIT.EDU Fri Mar 20 22:09:55 1987
From: treese@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Subject: Mystery subdirectories
What are the "ss" and "et" subdirectories of /src/athena.lib/kerberos/client?
They are not in the makefile. Are they still needed?
- Win
--[0180]--
\f
[0181] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (16 lines)
Subject: Re: Mystery subdirectories
From wesommer@ATHENA.MIT.EDU Fri Mar 20 22:17:05 1987
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Sender: wesommer@ATHENA.MIT.EDU
To: Win <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Fri, 20 Mar 87 22:07:32 EST
<8703210307.AA28535@CIROCCO.MIT.EDU>
Subject: Re: Mystery subdirectories
Those look like Ken Raeburn's "subsystem" and "error table" libraries
from discuss; Jeff took them for the "admin" program.
- Bill
--[0181]--
\f
[0182] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:38 (18 lines)
Subject: Re: Mystery subdirectories
From jis@BITSY.MIT.EDU Sun Mar 22 00:37:18 1987
Date: Sun, 22 Mar 87 00:36:36 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
Subject: Re: Mystery subdirectories
Oops. They are my fault. That is part of the "admin" program that
Annette uses. I moved the sources over to paris (feeling that paris
should have a copy of all sources that represent a program in use). I
didn't however finish putting all the Makefiles in order (or in the
case of ss and et, making make files that work on paris).
I will eventually get around to it... if it needs priority, I can give
it priority.
-Jeff
--[0182]--
\f
[0183] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (23 lines)
Subject: #ifndef BIG fails
From Saltzer@ATHENA.MIT.EDU Mon Mar 23 19:17:15 1987
To: kerberos
Subject: #ifndef BIG fails
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
OK, guys, when was the last time that the DES library passed its
verify test when compiled with BIG not defined?
When defined, BIG causes compilation of a program that is quite a bit
faster, but in payment is also quite a bit larger. I need the small
library on the PC. With BIG defined the des library passes its
verify test both on the VAX and the PC. With BIG undefined, it fails
both places. (With different wrong answers.)
Steve: can you reconstruct any changes that might have led to this
problem? Or identify a set of sources that passes verify with BIG
undefined, so that we can diff?
Jerry
--[0183]--
\f
[0184] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (18 lines)
Subject: re: Fix for des library
From Saltzer@ATHENA.MIT.EDU Wed Mar 25 01:02:40 1987
To: spm%lyre.DEC@decwrl.DEC.COM (Steve Miller), kerberos
Subject: re: Fix for des library
In-Reply-To: spm%lyre.DEC@decwrl.DEC.COM (Steve Miller)'s message of Tuesday, 24 Mar 1987 11:09:36-PST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> I played with it on my Ultrix system, and found that disabling BIG
> caused the wrong values to be computed. I finally tracked this down
> to a missing initialization (R2=0) in the des_make_p.c file. With this
> fixed, it works ok for the Ultrix Vax with BIG disabled.
I just tried Steve's fix on the PC and it verifies there, too. So
this bug is now history.
Jerry
--[0184]--
\f
[0185] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (22 lines)
Subject: re: Fix for des library
From Saltzer@ATHENA.MIT.EDU Wed Mar 25 12:48:32 1987
To: spm%lyre.DEC@decwrl.DEC.COM (Steve Miller), kerberos
Subject: re: Fix for des library
In-Reply-To: spm%lyre.DEC@decwrl.DEC.COM (Steve Miller)'s message of Tuesday, 24 Mar 1987 11:09:36-PST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> I played with it on my Ultrix system, and found that disabling BIG
> caused the wrong values to be computed. I finally tracked this down
> to a missing initialization (R2=0) in the des_make_p.c file. With this
> fixed, it works ok for the Ultrix Vax with BIG disabled.
I just tried Steve's fix on the PC and it verifies there, too. So
this bug is now history.
Jerry
--[0185]--
\f
[0186] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (93 lines)
Subject: "solving" the xhost problem
From swick@ATHENA.MIT.EDU Fri Mar 27 13:50:37 1987
Resent-From: swick@ATHENA.MIT.EDU
Resent-Message-Id: <8703271847.AA10595@HERACLES.MIT.EDU>
To: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, saltzer@ATHENA.MIT.EDU,
jis@ATHENA.MIT.EDU
Cc: lbm@ATHENA.MIT.EDU
Subject: "solving" the xhost problem
Date: Fri, 27 Mar 87 12:18:04 EST
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>
Resent-To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
----- Begin Forwarded Message -----
After long consideration, it is my conclusion that a real solution to replacing
xhost with a more convenient authorization mechanism will require two additions
to Kerberos. After a lengthy description of the proposed additions, I also
propose a simple short-term solution.
The problem is two-fold; the current authorization based only upon host name
is insufficient in general and should be augmented to authorize by user.
The second part of the problem is, as Jeff points out, a thorny issue in
Kerberos about when a users credentials should be copied to another host.
I propose that the first extension to Kerberos be a request to obtain
temporary credentials (a ticket-granting ticket) valid for a different node
that the one from which the request originates. This should require the user
to re-enter his Kerberos principal key; i.e. the temporary credentials on
the requesting host should never be considered sufficient for obtaining new
ones. As a bone to users less concerned with security, klogin should consult
a table (in the user's home directory?) of nodes for which to obtain
credentials during login.
This solves the problem of having to send passwords in cleartext over the
network in order to kinit on a remote host. I have no definite proposal on
how to get the ticket-granting ticket over to the other node, but the new
rlogin/rlogind work should provide some clues. I do believe that once the tgt
is obtained on the local host, it is acceptable to automatically transfer it
to the destination node when needed. Parenthetically, I believe logout should
always cause a kdestroy.
The second addition to Kerberos is needed to provide a service key for
transient services (i.e. the user's X server). If the service is transient,
it cannot store it's own key in a permanent manner. This is a re-statement
of "workstations cannot have secrets". This proposal requires the addition
of a minimal amount of state to Kerberos, but I believe it will have more
utility than just the 'X0.E40-327-1' service.
Specifically, I propose adding a request, "get service key" to Kerberos. Upon
receipt of this request, Kerberos would create a random service key, store it
in its database and send it back to the requestor. "Get service key" must
require that the service be pre-registered with Kerberos, with an attribute
allowing the generated service key to be stored (by Kerberos; i.e. Kerberos
will need to know that this is a transient service). The transient service
then accepts tickets sealed in this service key for as long as it wants
and can unilaterally invalidate the key (by exiting or requesting a new one,
for example) without having to notify the Kerberos server. "Get service key"
could also require that the service instance include the node name and
that the request originate from the same node. This attaches extra semantics
to the instance, but reduces denial of service interference.
A transient service as defined above inherently cannot be assured the same
level of security as provided to a service that can store it's own secrets.
In particular, it does not protect the transient service against spoofs of the
Kerberos server itself or against wiretapping during transmission of the new
service key.
I believe the above mechanisms are necessary to provide the by-user
authentication desired in X and similar services that cannot keep secrets.
The easy short-term improvement requires only one line to be added to
the user's .cshrc file:
alias xlogin 'xhost \!:1; xterm -n "\!:-1" -e rlogin \!*'
The `xlogin' command has identical syntax to the `rlogin' command but also
causes the remote session to be displayed in an alternate window (a useful
freebie, I believe) and allows any X clients on the remote system to access
the local display.
It may be argued that rlogin itself should be redefined as above and I
believe that would be acceptable.
This does not handle `rsh'd clients, but I suspect that most uses of rsh
are within scripts (like .login) where an explicit xhost is acceptable.
Comments are, of course, invited.
-Ralph
--[0186]--
\f
[0187] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (19 lines)
Subject: "solving" the xhost problem
From jtkohl@ATHENA.MIT.EDU Fri Mar 27 14:50:14 1987
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: swick@ATHENA.MIT.EDU
Cc: kerberos, treese, geer, lbm, jis, saltzer
In-Reply-To: Ralph R. Swick's message of Fri, 27 Mar 87 12:18:04 EST <8703271718.AA13787@ORPHEUS.MIT.EDU>
Subject: "solving" the xhost problem
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
>to the destination node when needed. Parenthetically, I believe logout should
>always cause a kdestroy.
The kerberized login (in use on workstations) does indeed destroy
tickets at logout time, PROVIDED that the user has not put them
somewhere other than what login believes KRBTKFILE should be.
John
--[0187]--
\f
[0188] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (57 lines)
Subject: re: "solving" the xhost problem
From Saltzer@ATHENA.MIT.EDU Fri Mar 27 16:13:10 1987
Subject: re: "solving" the xhost problem
To: Ralph R. Swick <swick@ATHENA.MIT.EDU>
Cc: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, kerberos, jis@ATHENA.MIT.EDU,
lbm@ATHENA.MIT.EDU
In-Reply-To: Ralph R. Swick <swick@ATHENA.MIT.EDU>'s message of Fri, 27 Mar 87 12:18:04 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Ralph,
I don't think that adding state to Kerberos is the right solution,
but I have an alternative to propose.
To add state is a major change in Kerberos design ground rules, and it
fouls up quite a number of assumptions. For example, the way
Kerberos is currently designed, a Kerberos client goes through a list
of Kerberos slaves that nominally have identical authoritative
information, and uses the first one to respond. If Kerberos begins
to manage state dynamically we have to add some mechanism to get the
word to all the slaves when a user adds a temporary session key at
one of them. For another, if the Kerberos server crashes and reboots,
all authentications EXCEPT these self-authentications still work.
I propose a quite different method. This method would work for X,
and possibly for the other services you were thinking of.
The method is to have the workstation open up a Kerberos service
port, and run a mini-Kerberos service whose only function is to
give out tickets and session keys to clients who present credentials
that originated at this workstation.
I think that the realm mechanism offers enough semantics to pull this
off with no change in any of the current Kerberos machinery. That
is, workstation E40-399-21.ATHENA.MIT.EDU runs a realm with that same
name. The distant host receives the workstation identity, a
ticket-granting ticket, and the session key for the tgt from the
workstation via the undiscussed rlogin/environment-variable
mechanism, and it invokes make-app-request specifying as the realm
the name of the workstation. There is one new subroutine, that adds
the imported ticket to the local ticket collection.
The result is a request back to the workstation, supplying a tgt that
the workstation itself fabricated and can recognize. The workstation
mini-Kerberos responds with an X ticket and a new session key, all
properly sealed up with the tgt session key.
One minor problem this approach has is that without massive tinkering
of the rlogin environment-variable passing mechanism, the tgt session
key would be transmitted to the distant host in cleartext. Fixing
that is only a matter of effort (it and the ticket itself could be
enciphered in the rlogin session key) , which effort may not be
worth it for protecting X windows.
Jerry
--[0188]--
\f
[0189] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:39 (43 lines)
Subject: re: "solving" the xhost problem
From Saltzer@ATHENA.MIT.EDU Fri Mar 27 17:57:34 1987
Subject: re: "solving" the xhost problem
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: Ralph R. Swick <swick@ATHENA.MIT.EDU>, geer@ATHENA.MIT.EDU,
treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU,
lbm@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>'s message of
Fri, 27 Mar 87 16:10:45 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Jeff offered his own version of my suggestion; his is one step
simpler. Rather than fabricating a ticket-granting ticket for a
mini-realm, the workstation running the X server could simply
fabricate a ticket that its X server would honor. It could construct
one that appears to be from the default realm. Doing so would
simplify life for the time-sharing host at the other end which
currently isn't equipped to keep track of tickets that come from a
variety of realms.
Ralph points out that there is another, more difficult, application
that is also of interest: the granting of permission to a completely
different user to open a window on your workstation. If we assume
that the foreign user starts by requesting attachment via Zephyr,
which has authenticated the user's identity, and that the workstation
can trust Zephyr because it has a ticket for communication with
Zephyr, then the same mechanism could be used there: the workstation
fabricates an X ticket it will honor, and sends that ticket to the
foreign user, who sends it back to the X port. This approach
requires a hand-hold inside Zephyr, to get a ticket-containing
message back to a user who has used Zephyr to contact your
workstation.
Jerry
--[0189]--
\f
[0190] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (20 lines)
Subject: Re: "solving" the xhost problem
From lbm@ATHENA.MIT.EDU Fri Mar 27 18:19:15 1987
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: Ralph R. Swick <swick@ATHENA.MIT.EDU>, geer@ATHENA.MIT.EDU,
treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU,
lbm@ATHENA.MIT.EDU, lbm
Subject: Re: "solving" the xhost problem
In-Reply-To: Your message of Fri, 27 Mar 87 17:55:04 -0500.
<8703272255.AA11864@HERACLES.MIT.EDU>
Date: Fri, 27 Mar 87 18:17:39 EST
From: Linda B. Merims <lbm@ATHENA.MIT.EDU>
Yesterday I discovered that kerberos does not authenticate operations
between workstations (I was trying to rcp my files between two
workstations while logged in on both). Win explained that it is
because we don't run kerberos daemons in workstations because
they are unsecure. So, it was back to .rhost files. Can this
mechanism solve that problem, too?
--[0190]--
\f
[0191] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (15 lines)
Subject: Kerberos error messages
From treese@ATHENA.MIT.EDU Thu Apr 9 22:36:04 1987
From: treese@ATHENA.MIT.EDU
To: kerberos
Subject: Kerberos error messages
Ken Raeburn has suggested that all Kerberos error messages print "Kerberos"
in them somewhere to make problems easier to diagnose for those who don't
know the details.
Is this worth doing? Any volunteers?
- Win
--[0191]--
\f
[0192] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (16 lines)
Subject: Re: Kerberos error messages.
From jis@BITSY.MIT.EDU Fri Apr 10 11:02:53 1987
Date: Fri, 10 Apr 87 11:01:46 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Subject: Re: Kerberos error messages.
Sounds reasonable. I will do it with my next pass over the code (which
will be shortly, to remove dependancy on RTI Ingres). Note: The error code
numbers will remain the same, just the associated messages will change.
To get the new messages, an application would need to be relinked when
the updated libkrb.a is available.
-Jeff
--[0192]--
\f
[0193] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (57 lines)
Subject: New error message names.
From jis@BITSY.MIT.EDU Fri Apr 10 11:11:05 1987
Date: Fri, 10 Apr 87 11:10:18 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Subject: New error message names.
Ok, here is an exerpt of the new error message file. Basically all
I did was replace the parenthasized subroutine references (of the
form "(get_credentials)") with the string "(kerberos)."
This ok?
char *krb_err_txt[256] = {
"OK", /* 000 */
"Principal expired (kerberos)", /* 001 */
"Service expired (kerberos)", /* 002 */
"Authentication expired (kerberos)", /* 003 */
"Unknown protocol version number (kerberos)", /* 004 */
"Principal: Incorrect master key version (kerberos)", /* 005 */
"Service: Incorrect master key version (kerberos)", /* 006 */
"Bad byte order (kerberos)", /* 007 */
"Principal unknown (kerberos)", /* 008 */
"Principal not unique (kerberos)", /* 009 */
"Principal has null key (kerberos)", /* 010 */
"Permission Denied (kerberos)", /* 020 */
"Can't read ticket file (kerberos)", /* 021 */
"Can't find ticket (kerberos)", /* 022 */
"Ticket granting ticket expired (kerberos)", /* 026 */
"Can't decode authenticator (kerberos)", /* 031 */
"Ticket expired (kerberos)", /* 032 */
"Ticket issue date too far in the future (kerberos)", /* 033 */
"Repeat request (kerberos)", /* 034 */
"Ticket for wrong server (kerberos)", /* 035 */
"Request inconsistent (kerberos)", /* 036 */
"Time is out of bounds (kerberos)", /* 037 */
"Incorrect network address (kerberos)", /* 038 */
"Protocol version mismatch (kerberos)", /* 039 */
"Illegal message type (kerberos)", /* 040 */
"Message integrity error (kerberos)", /* 041 */
"Message duplicate or out of order (kerberos)", /* 042 */
"Unauthorized request (kerberos)", /* 043 */
"Current password is NULL (kerberos)", /* 051 */
"Current password incorrect (kerberos)", /* 052 */
"Protocol error (kerberos)", /* 053 */
"Error returned by KDC (kerberos)", /* 054 */
"Null ticket returned by KDC (kerberos)", /* 055 */
"Retry count exceeded (kerberos)", /* 056 */
"Can't send request (kerberos)", /* 057 */
"Warning: Not ALL tickets returned (kerberos)", /* 061 */
"Password incorrect", /* 062 */
"Protocol error (kerberos)", /* 063 */
"Generic error (kerberos)", /* 070 */
"Don't have ticket granting ticket (kerberos)", /* 071 */
-Jeff
--[0193]--
\f
[0194] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (13 lines)
Subject: Re: New error message names.
From Raeburn.PDO@MIT-MULTICS.ARPA Fri Apr 10 11:18:26 1987
Date: Fri, 10 Apr 87 12:11 EDT
From: Ken Raeburn <Raeburn@MIT-MULTICS.ARPA>
Subject: Re: New error message names.
To: "Jeffrey I. Schiller" <jis@BITSY.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Message of 10 Apr 87 12:10 EDT from "Jeffrey I. Schiller"
For readability, wouldn't such messages as "Kerberos principal expired",
"Kerberos principal not unique", etc., make much more sense, at least
for those for which it can easily be done?
--[0194]--
\f
[0195] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (17 lines)
Subject: Kerberos document available
From Saltzer@ATHENA.MIT.EDU Fri Apr 10 16:10:07 1987
To: athena, kerberos
Subject: Kerberos document available
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
A new draft of Athena Technical Plan section E.2.1 describing the
Kerberos Authentication System is now available for review and
comment. It is substantially revised and expanded from the previous
version of August 25, 1986.
Kate Lonnie will have copies in room E40-391 on Monday.
Jerry
--[0195]--
\f
[0196] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (17 lines)
Subject: Kerberos document available
From bcn@june.cs.washington.edu Fri Apr 10 17:50:43 1987
Date: Fri, 10 Apr 87 14:26:54 PST
From: bcn@june.cs.washington.edu (Clifford Neuman)
Return-Path: <bcn>
To: Saltzer@ATHENA.MIT.EDU
Cc: athena@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Fri, 10 Apr 87 16:02:38 EST
Subject: Kerberos document available
Can you have a copy of the new kerberos spec sent to me. My address is
PO Box 45775
Seattle, WA 98145-0775
Thanks, Cliff.
--[0196]--
\f
[0197] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (78 lines)
Subject: FYI
From treese@ATHENA.MIT.EDU Wed Apr 22 03:20:54 1987
To: kerberos@ATHENA.MIT.EDU
Subject: FYI
Date: Wed, 22 Apr 87 02:18:41 EST
From: Win Treese <treese@ATHENA.MIT.EDU>
An RFC that may be of interest. As usual, it's in /u3/rfc on paris.
- Win
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA04936; Tue, 21 Apr 87 23:01:59 EST
Received: by ATHENA (5.45/4.7)
id AA08978; Tue, 21 Apr 87 23:00:32 EST
Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Tue 21 Apr 87 18:33:15-PDT
Posted-Date: Tue, 21 Apr 87 18:32:51 PDT
Message-Id: <8704220132.AA02615@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA02615; Tue, 21 Apr 87 18:32:52 PDT
To: ;@Request-for-Comments-List
Cc: Westine@venera.isi.edu
Subject: RFC 1004 Now Available
Date: Tue, 21 Apr 87 18:32:51 PDT
From: Ann Westine <westine@venera.isi.edu>
A new Request for Comments is now available from the Network
Information Center in the online library at SRI-NIC.ARPA.
RFC 1004:
Title: A Distributed-Protocol Authentication Scheme
Author: D. L. Mills
Mailbox: Mills@UDEL.EDU
Pages: 8
Characters: 21,402
pathname: RFC:RFC1004.TXT
The purpose of this RFC is to focus discussion on authentication
problems in the Internet and possible methods of solution. The
proposed solutions this document are not intended as standards
for the Internet at this time. Rather, it is hoped that a general
consensus will emerge as to the appropriate solution to
authentication problems, leading eventually to the adoption of
standards. This document suggests mediated access-control and
authentication procedures suitable for those cases when an
association is to be set up between users belonging to
different trust environments. Distribution of this memo is
unlimited.
Public access files may be copied from the <RFC> directory at
SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST.
The normal method for distribution of RFCs is for interested
parties to copy the documents from the NIC online library using
FTP. Requests for special distribution should be addressed to
either the author of the RFC in question or to NIC@SRI-NIC.ARPA.
Unless specifically noted otherwise on the RFC itself, all RFCs
are for unlimited distribution.
Submissions for Requests for Comments should be sent to
POSTEL@ISI.EDU.
Requests to be added to or deleted from this distribution list should
be sent to NIC@SRI-NIC.ARPA.
--jon.
------- End of Forwarded Message
--[0197]--
\f
[0198] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:40 (39 lines)
Subject: missing kerberos feature needed for
From Saltzer@ATHENA.MIT.EDU Mon Apr 27 15:02:09 1987
To: jis@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
Subject: missing kerberos feature needed for mailing lists
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
ARPANET RFC 989 ("Privacy Enhancement for Internet Electronic Mail")
identifies a key-distribution feature that we don't currently have in
Kerberos: The ability to ask Kerberos for a bunch of tickets all of
which have the same session key inside.
The use would be in the case where one is sending a message to a
mailing list of, say, 20 other users. You would ask Kerberos for a
mail ticket for each of the 20 people (probably Kerberos would seal
mail tickets using the recipient's private key) but specify that it
should materialize a single temporary session key and seal that one
key inside every ticket.
Then you encipher the message contents once, under the session key,
and for each recipient, include that recipient's ticket in the header
of that recipient's copy.
Using the facilities that Kerberos now provides, each ticket has a
different session key inside it. If used for mail, distinct session
keys would require that the entire message text be reenciphered once
for each recipient.
This comment applies either to the case where the originator of the
message does the mailing list explosion, or where the originator
sends the message to a trusted list-exploder, in which case the
list-exploder is the one that needs the extended Kerberos function.
Comments? How soon do we need to start thinking about
privacy-enhanced mail? I suspect soon, in the M.I.T. non-Athena
context.
Jerry
--[0198]--
\f
[0199] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (67 lines)
Subject: missing kerberos feature needed for
From jis@BITSY.MIT.EDU Mon Apr 27 15:28:43 1987
Date: Mon, 27 Apr 87 15:27:29 AST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Mon, 27 Apr 87 14:58:13 EDT <8704271858.AA13937@HERACLES.MIT.EDU>
Subject: missing kerberos feature needed for mailing lists
Date: Mon, 27 Apr 87 14:58:13 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
ARPANET RFC 989 ("Privacy Enhancement for Internet Electronic Mail")
identifies a key-distribution feature that we don't currently have in
Kerberos: The ability to ask Kerberos for a bunch of tickets all of
which have the same session key inside.
The use would be in the case where one is sending a message to a
mailing list of, say, 20 other users. You would ask Kerberos for a
mail ticket for each of the 20 people (probably Kerberos would seal
mail tickets using the recipient's private key) but specify that it
should materialize a single temporary session key and seal that one
key inside every ticket.
Then you encipher the message contents once, under the session key,
and for each recipient, include that recipient's ticket in the header
of that recipient's copy.
Using the facilities that Kerberos now provides, each ticket has a
different session key inside it. If used for mail, distinct session
keys would require that the entire message text be reenciphered once
for each recipient.
This comment applies either to the case where the originator of the
message does the mailing list explosion, or where the originator
sends the message to a trusted list-exploder, in which case the
list-exploder is the one that needs the extended Kerberos function.
Comments? How soon do we need to start thinking about
privacy-enhanced mail? I suspect soon, in the M.I.T. non-Athena
context.
Jerry
Actually I looked into this RFC when it first came out. My idea would
be to choose a common session key with which to encipher the message,
then encipher this session key in the per ticket session key for
each user ie:
To: User1, User2
Ticket-For-User1: T {K }
User1 m K
T
User1
Ticket-For-User2: T {K }
User2 m K
T
User2
Message: {{Message Text per RFC } } (Encoded per RFC)
K
m
-Jeff
--[0199]--
\f
[0200] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (21 lines)
Subject: quad_cksum failures.
From jis@BITSY.MIT.EDU Wed Jul 8 00:47:16 1987
Date: Wed, 8 Jul 87 00:46:30 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: Geer@ATHENA.MIT.EDU, Treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
Subject: quad_cksum failures.
Well turns out that quad_cksum was converted to compile on the
RT, but byte-order issues were never thought about. Therefore it
yields different results on the RT then it does on the VAX. The
password changing utilities are the first set of programs that put
this routine to use.
I have looked over the code and it shouldn't be too hard to
fix so that it works on the RT (though the RT version would suffer a
small performance degradation as byte swapping would have to occur at
several places in the algorithm).
-Jeff
--[0200]--
\f
[0201] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (15 lines)
Subject: Re: quad_cksum failures.
From jbloom@ATHENA.MIT.EDU Wed Jul 8 12:35:11 1987
From: jbloom@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU, jis@BITSY.MIT.EDU
Subject: Re: quad_cksum failures.
Cc: Geer@ATHENA.MIT.EDU, Treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
I don't remember off the top of my head what the byte ordering rules
used in the rest of kerberos are, but the fix in this case should
follow the same idea. If network byte order is always used, the
checksum should be in network byte order. If the source machine
determines the order, then that order should be used in this case.
Jim
--[0201]--
\f
[0202] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (32 lines)
Subject: Re: quad_cksum failures.
From jis@BITSY.MIT.EDU Wed Jul 8 13:39:56 1987
Date: Wed, 8 Jul 87 13:38:42 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: jbloom@ATHENA.MIT.EDU
Cc: Saltzer@ATHENA.MIT.EDU, Geer@ATHENA.MIT.EDU, Treese@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
In-Reply-To: jbloom@ATHENA.MIT.EDU's message of Wed, 8 Jul 87 12:35:45 EDT <8707081635.AA14812@PARIS.MIT.EDU>
Subject: Re: quad_cksum failures.
Well there are two issues with the network byte order:
1) How the result is expressed.
2) How it is computed.
(1) should be obvious. However issue two comes up because the
algorithm looks at the byte stream as if it were a collection of 16
bits integers.
As a practical matter I am planning to fix this by having the
RT code emulate the VAX code (ie. VAX byte order). This is because
there is already production code running on many vaxes in our
environment. I might do this and rename the function at the same time
to be "broken_quad_cksum" and have quad_cksum behave properly in a
later release.
-Jeff
--[0202]--
\f
[0203] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (20 lines)
Subject: quad_cksum failures.
From tytso@ATHENA.MIT.EDU Wed Jul 8 14:01:42 1987
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: jbloom@ATHENA.MIT.EDU
Cc: Saltzer@ATHENA.MIT.EDU, jis@BITSY.MIT.EDU, Geer@ATHENA.MIT.EDU,
Treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <jbloom@ATHENA.MIT.EDU>'s message of Wed, 8 Jul 87 12:35:45 EDT <8707081635.AA14812@PARIS.MIT.EDU>
Subject: quad_cksum failures.
Reply-To: tytso@athena.mit.edu
Address: EC Bemis 509, 3 Ames Street, Cambridge, MA 02139
Phone: (617) 225-6569
Well, "rlogin E40-302-13" didn't work yesterday (didn't give me tickets)
but it works now. I thought mods to the kerberos database took effect
immediately, but I guess not, now that there's a slave kerberos machine
(kerberos1, which I thought wasn't running yet, but oh well). Have fun
with xtrek!
- Ted
--[0203]--
\f
[0204] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (16 lines)
Subject: quad_cksum failures.
From tytso@ATHENA.MIT.EDU Wed Jul 8 14:06:12 1987
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: jbloom@ATHENA.MIT.EDU
Cc: Saltzer@ATHENA.MIT.EDU, jis@BITSY.MIT.EDU, Geer@ATHENA.MIT.EDU,
Treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <jbloom@ATHENA.MIT.EDU>'s message of Wed, 8 Jul 87 12:35:45 EDT <8707081635.AA14812@PARIS.MIT.EDU>
Subject: quad_cksum failures.
Reply-To: tytso@athena.mit.edu
Address: EC Bemis 509, 3 Ames Street, Cambridge, MA 02139
Phone: (617) 225-6569
I accidentally replied to the wrong message, sorry!
- Ted
--[0204]--
\f
[0205] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (22 lines)
Subject: Availability of Kerberos
From jis@BITSY.MIT.EDU Thu Jul 9 13:19:53 1987
Date: Thu, 9 Jul 87 13:19:00 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: jbloom@ATHENA.MIT.EDU, Saltzer@ATHENA.MIT.EDU, Geer@ATHENA.MIT.EDU,
Treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Wed, 8 Jul 87 14:04:06 EDT <8707081804.AA03310@HERACLES.MIT.EDU>
Subject: Availability of Kerberos
I would not pick up kerberos this instant. I am in the middle of adding
support for non-Ingres based databases (ie. on top of ndbm files). This
support includes the low level record manipulation functions (mostly
done at this point, thanx to Stan Zanarotti at LCS), and utility programs
to dump and load the database (in progress now).
This work should be in a reasonable state in about a weeks time (which
is when I am targetting cutting Athena over to it). Stay tuned for
more information.
-Jeff
--[0205]--
\f
[0206] jon@ATHENA.MIT.EDU Kerberos 08/09/87 21:41 (73 lines)
Subject: Re: handling of tdc?
From jis@BITSY.MIT.EDU Thu Jul 9 14:15:11 1987
Date: Thu, 9 Jul 87 14:13:50 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: dyer@ATHENA.MIT.EDU
Cc: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, Saltzer@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
In-Reply-To: ---'s message of Wed, 08 Jul 87 15:28:20 EDT <8707081928.AA23441@MENELAUS.MIT.EDU>
Subject: Re: handling of tdc?
We have a problem here, and it is going to get bigger over
time.
Specifically our environment is not really oriented toward
dealing with machines in other domains (or subdomains). Hesiod is only
one example, kerberos is another. The kerberos situation is:
There is an implicit notion in the kerberos software that
one's domain is equal to one's realm (with a special hack that MIT.EDU
maps to ATHENA.MIT.EDU). This comes up in several places. One place is
in answering the question "What realm is that machine over there in?"
which is asked when you need to get tickets for a specific service.
The algorithm is:
Client "C" wants to use "rcmd" service at host "A.FOO.BAR.BAZ".
Strip domain name off of A.FOO.BAR.BAZ yielding FOO.BAR.BAZ as the realm
name and "A" as the service instance. Thus ask for tickets for:
SERVICE=rcmd INSTANCE=a REALM=FOO.BAR.BAZ as the service.
This will not be easy to change. First we need to invent a
mechanism (or use a nameservice like hesiod) to translate machine name
into realm name to use. Second we need to change our current notion of
instance name to be a fully qualified domain name, instead of just the
host name portion.
*
As for the first problem I recommend creating a simple UDP based server
that would run on each machine that would simply return the
machines realm name. Thus to talk to A.FOO.BAR.BAZ you would ask him!
Suppose he answers ATHENA.MIT.EDU, using this information and change
number two above we would get a request for:
SERVICE=rcmd INSTANCE=a.foo.bar.baz REALM=ATHENA.MIT.EDU as the service.
Solving problem number two above is harder. It involves a
massive flagday (the day we convert all the "a"s to "a.mit.edu"s) or
carrying two entries for each service (one with the old instance name
and one with the new) whose keys are the same (this would be a royal
pain in the you-know-what).
Now for the practical short term solution. Stop giving out
subdomain based names to living groups. Note: They are NOT
authoritative for their own domains today anyway (ie. we need to
update tables on campus when they add machines, they don't manage the
domain from the living group). It would therefore be no additional
work on our part to NOT have subdomains out there. We did it
originally because it was "cute" not because of any technical or
procedural reason.
This is a cop-out solution. We do need to solve the above
mentioned problems. However I do not think that the living groups are
the right places to debug it!
-Jeff
-----------------------------------------------------------------
(*) I am disinclined from making the kerberos software dependent on
the functioning of hesiod. A simple UDP based server would have the
property of always being available as long as the service machine itself
was. And if the service machine is unavailable, so what, you cannot
talk to it anyway.
--[0206]--
\f
[0209] daemon@TELECOM.MIT.EDU Kerberos 08/12/87 17:29 (9 lines)
Subject: list_tkts -l
To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Why isn't the -l option the default for list_tkts? I haven't yet
found a case when I was interested in knowing what tickets I have
when I wasn't also interested in knowing when then will expire.
Jerry
--[0209]--
\f
[0210] daemon@TELECOM.MIT.EDU Kerberos 08/22/87 22:41 (10 lines)
Subject: Locking ticket files
From: Robert S. French <rfrench@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
It would be extremely useful if the sections of the Kerberos library
that played with tickets file would LOCK it before doing so...two
applications updating the file simultaneously seems to be the primary
cause of garbled ticket files.
Rob
--[0210]--
\f
[0211] daemon@TELECOM.MIT.EDU Kerberos 08/23/87 11:27 (13 lines)
Subject: re: tftp manual page
To: <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, bcn@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU,
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Sun, 23 Aug 87 02:55:33 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> There does not seem to be a manual page for the MIT version of tftp with
> Kerberos. Anyone have any pointers?
I'm afraid that I have never seen one.
Cliff: did you prepare one?
Jerry
--[0211]--
\f
[0212] daemon@TELECOM.MIT.EDU Kerberos 08/31/87 17:07 (15 lines)
Subject: problems in kerberos
From: jbloom@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
I have found three problems with kerberos. First and most serious, when
retrieve() was renamed to get_credentials(), nobody changed the manual
page. This makes it very difficult for a programmer to use kerberos.
The next problem is that decomp_ticket.c has the string "ATHENA.MIT.EDU"
hardcoded in as the default realm. It should be the defined value
KRB_REALM. (This is in lib/krb)
Finally, libkrb has one routine multiply defined. Both conf.c and
get_krbhst.c define the routine get_krbhst().
Jim
--[0212]--
\f
[0213] daemon@TELECOM.MIT.EDU Kerberos 09/05/87 12:00 (53 lines)
Subject: re: managled hesiod info
To: <chariot@ATHENA.MIT.EDU>
Cc: bugs@ATHENA.MIT.EDU, rtbugs@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU,
In-Reply-To: <chariot@ATHENA.MIT.EDU>'s message of Sat, 05 Sep 87 06:35:48 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Hesiod is returning host names in upper case when asked for filsys
> entries. This causes attach on 5.0 RT's to fail with "NFS uidmap: krb
> error was Can't find ticket (get_credentials)<cr> NFS Kerberos
> authentication failed".
Let's be very careful about just how this one gets fixed; the wrong
fix will get us in deeper water very quickly.
The basic principles for dealing with upper and lower case from a
human engineering standpoint are:
1. People who store and pass along other people's data shouldn't
tamper with (coerce) it; they should store and pass along both upper
and lower case as they find it. Thus SMS stores and passes to Hesiod
and Hesiod returns to its client both upper and lower case
information. (Some customers require it, e.g., UNIX file names may
appear in returned Hesiod info).
2. People who USE data should coerce it to a standard form before
doing string comparisons. Thus Hesiod clients, after getting a
string of data from Hesiod, should coerce it before looking it up in
a local table (they should coerce the information found in the table,
too).
The UNIX file system (to its everlasting disgrace--Multics had proved
that it was a mistake by 1969 and the UNIX design team knew it)
explicitly violates this second principle. And there are too many
programs in the world that know about the violation and depend on it,
so it can't be changed now. The real challenge is to keep that
design mistake from spreading.
The specific bug report looks like a Kerberos library problem. Since
Kerberos uses the UNIX file system to store its tickets, it must be
very careful about the case-ness of the names it uses for the
purpose, so that it can find its own tickets later, if the user
happens to identify them using a different case. Since Kerberos uses
the service principal name to construct the ticket file name, for
consistency it should probably coerce that principal name to lower
case at both ticket creation time and at ticket lookup time.
Incidentally, does anyone know why just the 5.0 RT attach is failing?
Did case sensitivity in attach get somehow addressed in 5.4? Or is
there a case-sensitivity difference between the RT and VAX libraries?
Or perhaps the 5.4 VAX system is failing, too, but no examples have
turned up yet?
Jerry
--[0213]--
\f
[0214] daemon@TELECOM.MIT.EDU Kerberos 09/05/87 22:13 (21 lines)
Subject: Re: managled hesiod info
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: <chariot@ATHENA.MIT.EDU>, bugs@ATHENA.MIT.EDU, rtbugs@ATHENA.MIT.EDU,
In-Reply-To: Your message of Sat, 05 Sep 87 11:56:58 -0400.
From: Win Treese <treese@ATHENA.MIT.EDU>
There have been two problems with attach:
1) Hesiod returning domain-qualified names, which don't work with Kerberos, and
2) Hesiod returning all-uppercase names, which don't work with Kerberos as
service instances.
(1) was fixed in 5.k for k>0. (2) was fixed today, and is included in the
5.4A update. The fix for (2) was made in /etc/athena/nfsid (which attach
calls). It remains to be discussed what, if anything, should be done in
the Kerberos library (that is, whether or not Kerberos should be case-sensitive
for service and instance names). (Note: this may be explicit somewhere;
I haven't checked.)
- Win
--[0214]--
\f
[0215] daemon@TELECOM.MIT.EDU Kerberos 09/08/87 17:01 (40 lines)
Subject: case sensitivity
To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
I propose that Kerberos be modified to be non-case-sensitive in both
principal and instance identifiers. Does anyone know a good reason
for Kerberos to maintain case sensitivity? It doesn't appear to be a
requirement to operate with UNIX.
The issue comes up right now because we are being bitten by
applications that have obtained a ticket for an instance identifier
heracles, then look for it later using the identifier HERACLES, and
fail. Since we have a widely known convention that host names are
not case-sensitive, the failure is a surprising result. Some
applications have worked around this problem by including explicit
code that coerces instance names to lower case, because they know
that Kerberos administrators conventionally use lower case only.
Those applications will fail in an even more puzzling way the first
time some Kerberos administrator tries to create an instance name
using upper case.
The more general problem is that Kerberos currently admits the
possibility that three different users might have id's "smith",
"Smith", and "SMITH". From the point of view of trying to make an
authorization/authentication system as mistake-free as possible, this
design is a human-engineering disaster!
The specific change would probably be in just two places: searching
the kerberos data base and searching the ticket file. In both
places, the search would be changed to be insensitive to case both in
the data base (file) and in the supplied identifier. That way the
database can store names in any case (for human-engineered display)
and the application can supply names in any case (whatever is easiest
to come up with.)
1. Have I got the facts straight?
2. Comments?
Jerry
--[0215]--
\f
[0216] daemon@TELECOM.MIT.EDU Kerberos 09/23/87 18:27 (55 lines)
Subject: BURROWS SEMINAR
Resent-From: STATON@XX.LCS.MIT.EDU
From: Gail-Lenora Staton <STATON@XX.LCS.MIT.EDU>
To: saltzer@MULTICS.MIT.EDU
Cc: staton@XX.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU
Resent-To: kerberos@XX.LCS.MIT.EDU
From: Jerome H. Saltzer <Saltzer@XX.LCS.MIT.EDU>
----- Begin Forwarded Message -----
SEMINAR
DATE: Tuesday, September 29, 1987
TIME: 3:30 p.m. (Refreshments)
TIME: 3:45 p.m. (Lecture)
PLACE: 545 Tech Sq., Room NE43-512A
A LOGIC OF AUTHENTICATION
MIKE BURROWS
Cambridge University
Abstract
We have developed a logic which allows one to describe authentication protocols
and to prove their correctness. It is useful for the designers and implementors
of authentication protocols because:
- it can determine the exact end state of the protocol in terms of the
beliefs of the two authenticated parties;
- it shows up redundant information and redundant encryption in the
protocol;
- it highlights any undesirable assumptions that the protocol relies
upon in order to reach a desired end state;
- it uses concepts which can be understood (were developed!) by people
with little experience with formal techniques.
We have built a theorem checker for the logic, and analyzed various published
protocols, the results of which will be presented.
This work was done by Roger Needham and Mike Burrows at DEC SRC.
HOST: Karen R. Sollins
-------
--[0216]--
\f
[0217] daemon@TELECOM.MIT.EDU Kerberos 09/29/87 12:44 (66 lines)
Subject: [Gail-Lenora Staton <STATON@XX.LCS.MIT.EDU>: Burrows Seminar - NEW TIME]
Resent-From: SOLLINS@XX.LCS.MIT.EDU
From: Karen R. Sollins <SOLLINS@XX.LCS.MIT.EDU>
To: csr-people@COMET.LCS.MIT.EDU
Resent-To: kerberos@XX.LCS.MIT.EDU
From: Jerome H. Saltzer <Saltzer@XX.LCS.MIT.EDU>
1. Note change in time.
2. Mike Burrows stopped by to talk for a few minutes this morning.
He says that his talk will include an analysis of exactly what you
know for sure when each of several authentication protocols,
including Kerberos, is completed.
Jerry
----- Begin Forwarded Message -----
Date: Tue 29 Sep 87 10:08:08-EDT
From: Gail-Lenora Staton <STATON@XX.LCS.MIT.EDU>
Subject: Burrows Seminar - NEW TIME
To: tech-sq@XX.LCS.MIT.EDU
***TODAY **** TODAY **** TODAY **** TODAY **** TODAY **** TODAY***
SEMINAR
DATE: Tuesday, September 29, 1987
NOTE NEW TIME ====> TIME: 3:00 p.m. (Refreshments)
NOTE NEW TIME ====> TIME: 3:15 p.m. (Lecture)
PLACE: 545 Tech Sq., Room NE43-512A
A LOGIC OF AUTHENTICATION
MIKE BURROWS
Cambridge University
Abstract
We have developed a logic which allows one to describe authentication protocols
and to prove their correctness. It is useful for the designers and implementors
of authentication protocols because:
- it can determine the exact end state of the protocol in terms of the
beliefs of the two authenticated parties;
- it shows up redundant information and redundant encryption in the
protocol;
- it highlights any undesirable assumptions that the protocol relies
upon in order to reach a desired end state;
- it uses concepts which can be understood (were developed!) by people
with little experience with formal techniques.
We have built a theorem checker for the logic, and analyzed various published
protocols, the results of which will be presented.
This work was done by Roger Needham and Mike Burrows at DEC SRC.
HOST: Karen R. Sollins
-------
-------
--[0217]--
\f
[0218] daemon@TELECOM.MIT.EDU Kerberos 10/15/87 12:56 (22 lines)
Subject: passwd bugs
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
The command to change a Kerberos password, "passwd", accepts
a carriage return as valid input for the new password prompt.
After changing the password in this way, the user can't authenticate
to Kerberos anymore at all, neither using a <CR> in response to
the password prompt, nor the old password.
John Barba noticed this bug and will fix it. We propose that,
as in the "register" program, a password of less than 4 characters
not be accepted. Any objections?
There is another, known (at least to Carla) bug, which is: if
you type the command "passwd", even if you type in the correct
old password at the prompt, your password is deemed incorrect.
If you give the command "passwd -name your_name", however, all
goes as expected.
Is someone looking into this already?
Jennifer
--[0218]--
\f
[0219] daemon@TELECOM.MIT.EDU Kerberos 10/15/87 15:00 (25 lines)
Subject: Re: passwd bugs
To: <steiner@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, barba@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 15 Oct 87 12:56:11 -0400.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
"Fixed in next release".
The passwd program is currently built and installed from the *SMS* source tree.
It's in sms/clients/passwd/passwd.c, and requires
sms/rpc/{admin_call.c,admin_err.et,admin_server.h,admin_util,c} as
well. Note that this is a reimplemented version of Jeff's admin_util
routine; admin_util() maintains the same calling interface, but calls
admin_call() to do all the real work after collecting the passwords.
This was so that the user registration server could use the same code as passwd.
These should probably be merged back into the Kerberos library at some point.
The fix to the first bug (disallowing a key of the null string) should
be made in admin_util() rather than admin_call().
The second reported bug (requiring '-name foo', rather than defaulting
to the user's login name) was fixed shortly after the deadline for the release.
- Bill
--[0219]--
\f
[0220] daemon@TELECOM.MIT.EDU Kerberos 10/16/87 18:08 (9 lines)
Subject: Kerberos dev sources moved
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
The sources that we're doing development from (used to be in
paris:~steiner/kerberos) have been moved. The new location is:
paris:/u3/kerberos.new
Jennifer
--[0220]--
\f
[0221] daemon@TELECOM.MIT.EDU Kerberos 10/22/87 13:08 (22 lines)
Subject: file locking
From: raeburn@ATHENA.MIT.EDU
To: bugs@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In case this isn't already on the Kerberos buglist, file locking would
sorely help:
oliver% list_tkts -l
Ticket file for principal raeburn@ATHENA.MIT.EDU
Issued Expires Principal
Oct 22 12:56:36 Oct 22 20:56:36 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
Oct 22 12:56:41 Oct 22 20:56:41 rvdsrv.priam@ATHENA.MIT.EDU
Oct 22 12:57:52 Oct 22 20:57:52 rvdsrv.orpheus@ATHENA.MIT.EDU
Oct 22 12:58:02 Oct 22 20:58:02 rvdsrv.charon@ATHENA.MIT.EDU
Oct 22 12:58:29 Oct 22 20:58:29 rvdsrv.m4-035-w@ATHENA.MIT.EDU
Oct 22 12:58:46 Oct 22 20:58:46 rvdsrv.eurydice@ATHENA.MIT.EDU
Oct 22 12:58:51 Oct 22 20:58:51 rvdsrv.paris@ATHENA.MIT.EDU
Oct 22 12:59:03 Oct 22 20:59:03 rvdsrv.snorkelwacker@ATHENA.MIT.EDU
Oct 19 02:45:23 Oct 19 10:45:23 zephyr.zephyr@ATHENA.MIT.EDU
*|q:c?.4MHV+s9~!rvdsrv@zeus32:31 _i4Yb2x\/4 CL,xj%
oliver%
--[0221]--
\f
[0222] daemon@TELECOM.MIT.EDU Kerberos 10/22/87 13:47 (19 lines)
Subject: Re: file locking
From: steiner@ATHENA.MIT.EDU
To: <raeburn@ATHENA.MIT.EDU>
Cc: bugs@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 22 Oct 87 13:06:24 -0400.
The new Kerberos library has the following routines for
manipulating ticket files:
* tf_init opens the ticket file and locks it.
*
* tf_get_pname returns the principal's name.
*
* tf_get_pinst returns the principal's instance (may be null).
*
* tf_get_cred returns the next CREDENTIALS record.
*
* tf_close closes the ticket file and releases the lock.
Jennifer
--[0222]--
\f
[0223] daemon@TELECOM.MIT.EDU Kerberos 10/22/87 16:13 (14 lines)
Subject: Re: file locking
To: <steiner@ATHENA.MIT.EDU>
Cc: <raeburn@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 22 Oct 87 13:46:29 -0400.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Interface questions:
It seems to me to make more sense to have one function which returns
the (name, instance, realm) tuple.
Does tf_get_pinst() return "" or NULL for a null instance?
- Bill
--[0223]--
\f
[0224] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 13:53 (16 lines)
Subject: Kerberos function names
From: treese@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
Without considering the labor involved, it seems to me that it would be a
good idea to change the Kerberos library function names to something alon
the X pattern; that is, functions would have names like KUsefulFunction().
For example, mk_ap_request would become something like KMkApRequest() or
KMakeApRequest(). A scheme like this has less potential for name collisions
with other software, and makes it easier to find the Kerberos changes in
the code.
Comments?
- Win
--[0224]--
\f
[0225] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 14:26 (19 lines)
Subject: Kerberos function names
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: treese@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Fri, 23 Oct 87 13:50:03 EDT <8710231750.AA22720@PARIS.MIT.EDU>
I wouldn't mind a kerberos prefix (like the capital K) [of course I
would really go for kerberos_$mk_ap_request] , but I for one *hate*
using capital letters for "word" delimiters. Underscores look so
much better (my eyes/brain can parse the "words" foo_bar more easily
than FooBar ... it just "looks" like there's a space there).
The real problem is you have to get all the clients as well. I wonder
if it's worth that? (Though it will only get harder and harder to do
the longer we wait.)
-- Jon
--[0225]--
\f
[0226] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 14:42 (18 lines)
Subject: Re: Kerberos function names
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 23 Oct 87 14:23:40 -0400.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I second Jon's motion... In addition to being hard to read, the X
names are also incredibly hard to type. Usually, I wind up
capitalizing one more or one less letter than I have to. You have to
shift for underscores, too, but that's further off the keyboard, so
it's less likely that you'll make the mistake when typing. Of course,
LISP-style names using '-' instead of '_' are even easier to type.
A prefix of krb_ would be appropriate; kerberos_ is too long.
'$' is not strictly a legal character in C identifiers, by ANSI C
specs; PCC accepts it, but.
- Bill
--[0226]--
\f
[0227] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 14:47 (23 lines)
Subject: Re: Kerberos function names
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 23 Oct 87 14:23:40 -0400.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
[oops: this got sent too soon]
I second Jon's motion... In addition to being hard to read, the X
names are also incredibly hard to type. Usually, I wind up
capitalizing one more or one less letter than I have to. You have to
shift for underscores, too, but that's further off the keyboard, so
it's less likely that you'll make the mistake when typing. Of course,
LISP-style names using '-' instead of '_' are even easier to type.
A prefix of krb_ would be appropriate; kerberos_ is too long.
'$' is not strictly a legal character in C identifiers, by ANSI C
specs; PCC accepts it, but other utilities, like "indent", tend to
break it. It also brings back bad memories of 6.170 and 6.035
(although I think that the use of $ in CLU was ripped off from
Multics..)
- Bill
--[0227]--
\f
[0228] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 17:37 (11 lines)
Subject: Re: Kerberos function names
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: Jon Rochlis <jon@ATHENA.MIT.EDU>, treese@ATHENA.MIT.EDU,
In-Reply-To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>'s message of Fri, 23 Oct 87 14:46:16 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> (although I think that the use of $ in CLU was ripped off from
> Multics..)
It sure was, may they both soon rest in peace.
Jerry
--[0228]--
\f
[0229] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 18:00 (11 lines)
Subject: Re: Kerberos function names
From: raeburn@ATHENA.MIT.EDU
To: wesommer@ATHENA.MIT.EDU
Cc: jon@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Fri, 23 Oct 87 14:46:16 EDT <8710231846.AA05432@EPIMETHEUS.MIT.EDU>
Funny, just a couple of days or so ago I sent a similar suggestion
off (in private mail to steiner). "krb_foo" is probably the best
way to do it. (Although I too must confess to a preference for the
kerberos_$foo idea. Think my bit of Multics upbringing is showing
through?)
--[0229]--
\f
[0230] daemon@TELECOM.MIT.EDU Kerberos 10/23/87 18:14 (11 lines)
Subject: Re: Kerberos function names
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 23 Oct 87 14:23:40 EDT.
I generally agree with Jon on this one. Not being a great typist, I general
prefer things in lowercase and short. I'm not a big fan of capitals in
names in any case. I don't mind a prefix if it isn't too long. "krb_"
would be quite reasonable and should prevent conflicts in most cases.
Jim
--[0230]--
\f
[0231] daemon@TELECOM.MIT.EDU Kerberos 10/25/87 21:17 (11 lines)
Subject: Re: Kerberos function names
From: geer@ATHENA.MIT.EDU
To: <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 23 Oct 87 13:50:03 -0400.
i have no opinion about the function names in particular
(other than to second Bill on lisp-style), but i do think
that NOW is the time to make whatever change we are going
to make.
--dan
--[0231]--
\f
[0232] daemon@TELECOM.MIT.EDU Kerberos 10/27/87 15:21 (26 lines)
Subject: reporting of errors
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
One of the most frequent complaints I've heard about Kerberos
is that the way it deals with errors is ad hoc at best. I'd
like to solicit ideas for a consistent and handy way of dealing
with them.
As it now stands, sometimes returned errors are ignored by the
calling routines; some routines take it upon themselves to print
a message (sometimes to stderr, sometimes to stdout) and exit (or
not); sometimes perror() is used; the com_err library is used some places
and not others; if an error code manages to find its way back to the user,
it's usually the same error for any number of wildly different problems.
Sometimes when getting an error, the program will print its name,
sometimes the routine will print its name. In the list of error
texts (krb_err_text.c in the library), the routine name is a part
of the error string. Is this helpful?
Should there be a krb_errno a la Unix errno? Or is there a better
way to handle the problem than a global variable?
Any comments are appreciated.
Jennifer
--[0232]--
\f
[0233] daemon@TELECOM.MIT.EDU Kerberos 10/28/87 09:30 (17 lines)
Subject: Hostname-instance problems
From: treese@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
Problem:
rvddown aggie vssys
fails to work using Kerberos authentication. The problem is that "aggie"
is not a valid instance name. Some programs, such as rlogin, handle this
by calling gethostbyname() to get the canonical name, then strip off the
domain information and lower-case the string. Instead of having every client
do that, I propose that we make that part of mk_ap_req() as as standard
feature.
Comments?
- Win
--[0233]--
\f
[0234] daemon@TELECOM.MIT.EDU Kerberos 10/28/87 11:21 (22 lines)
Subject: re: Hostname-instance problems
To: <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Wed, 28 Oct 87 09:26:43 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Problem:
> rvddown aggie vssys
> fails to work using Kerberos authentication. The problem is that "aggie"
> is not a valid instance name. Some programs, such as rlogin, handle this
> by calling gethostbyname() to get the canonical name, then strip off the
> domain information and lower-case the string. Instead of having every
> client do that, I propose that we make that part of mk_ap_req() as as
> standard feature.
I see one problem: it somewhat permanently associates the concept of
"instance" with "canonicalized domain name". It seems to me that
there are other good sources for instance fields. Maybe a more
suitable way is to define a kerberos library routine named
krb_hostname_to_instance() which returns a string that you can hand
to make_ap_req().
Jerry
--[0234]--
\f
[0235] daemon@TELECOM.MIT.EDU Kerberos 10/28/87 14:20 (24 lines)
Subject: Hostname-instance problems
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Wed, 28 Oct 87 11:20:52 EST <8710281620.AA12417@HERACLES.MIT.EDU>
This also has to do with the relationship between Kerberos realms and
namespace domains. For example we had the frats (and the SIPB)
in their own domain, but using the Athena Kerberos realm. Since the
instance for service keys wasn't fully qualified, you had to be
careful about name assigment. (E.g. rlogin into binkley.sipb.mit.edu
by getting tickets for rcmd.binkley, but that implies that there isn't
a binkley.mit.edu).
This is a can of worms, and really should be solved, but is it too
much to deal with in the first release. See Jeff's message to the
kerberos list on July 9 of this year for more of the problem
(transaction [0206] in the kerberos discuss meeting on achilles).
I think a shipped Kerberos should probably use the fully qualified domain
names for service instances, and we should seriously consider doing
that ourselves (even with the flag day, or duplicate entries that that
would imply).
-- Jon
--[0235]--
\f
[0236] daemon@TELECOM.MIT.EDU Kerberos 10/28/87 14:30 (25 lines)
Subject: multi-homed hosts
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
While we're mentioning problems with Kerberos, I should point out that
Kerberos has lots of problems with multi-homed hosts. Basically if
you a request for a ticket on one interface, and send it to a service
through another interface you'll lose because the sealed IP address
won't match the IP address you claim to be coming from.
For example if you have a network (say 128.15) with a kerberos server
someplace on it and you have a multi-homed host on milnet (net 26) on
which you want to run to run some application to talk to something at
MIT. First you go off an talk to your kerberos server getting a
ticket with your 128.15 address sealed in it, but when you ship it to
MIT, you'll have your net 26 address in the packet header, and the
server's rd_ap_req will fail.
When talking to the service, binding the socket you intend to use the
same address that you used to get the ticket in the first place may be
the only "easy" was to fix the problem, without substainal changes to
the guts of kerberos.
-- Jon
--[0236]--
\f
[0237] daemon@TELECOM.MIT.EDU Kerberos 10/29/87 11:53 (9 lines)
Subject: kerberos library
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
I have noticed many functions in the kerberos library which are used
only by the kerberos server programs. Should we create a separate
library for these functions, and leave -lkrb for the client and server
applications?
John
--[0237]--
\f
[0238] daemon@TELECOM.MIT.EDU Kerberos 10/29/87 12:51 (22 lines)
Subject: discuss meeting for Kerberos development team under Jennifer Steiner
From: raeburn@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Announced in Athena_Meetings on Menelaus:
[0005] raeburn@ATHENA.MIT.EDU Athena_Meetings 10/29/87 12:43 (7 lines)
Subject: Kerberos_Development meeting
Meeting Name: Kerberos_Development
Host: MENELAUS.MIT.EDU
Pathname: /usr/spool/discuss/krb_dev
Participation: Public
This meeting will serve as information exchange and log for the
Kerberos development team. Suggestions and comments are welcome.
--[0005]--
If you have interest in reading this meeting but have not used
Discuss, you can get information on using Discuss from the Student
Information Processing Board (in room 11-205), or send me mail
directly. For those not involved in and without direct interest in
the development, it may be a bit boring....
--[0238]--
\f
[0239] daemon@TELECOM.MIT.EDU Kerberos 10/29/87 13:27 (13 lines)
Subject: re: kerberos library
To: kerberos@ATHENA.MIT.EDU
Cc: John T Kohl <jtkohl@ATHENA.MIT.EDU>
In-Reply-To: John T Kohl <jtkohl@ATHENA.MIT.EDU>'s message of Thu, 29 Oct 87 11:52:46 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I have noticed many functions in the kerberos library which are used
> only by the kerberos server programs. Should we create a separate
> library for these functions, and leave -lkrb for the client and server
> applications?
Definitely.
Jerry
--[0239]--
\f
[0240] daemon@TELECOM.MIT.EDU Kerberos 10/29/87 15:59 (44 lines)
Subject: Re: reporting of errors.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
\begin{flame}
'errno' is a crock which people keep copying it in the vain hope that
they are calling something reasonable.
Global variables shared between libraries and applications are
inherently _evil_, since they clutter up the namespace. In addition,
there are insufficient constraints on when errno can and cannot be
clobbered. Instead, use of Ken's com_err package (which is already in
use by SMS, as well as being in use inside discuss and a few other
places) seems to make a lot of sense.
In the presence of
\end{flame}
Exercise for the reader:
/*
* Explain why this program prints "open: Not a typewriter" when it is
* run with stdout redirected into a file. The "printf" works fine, by
* the way.
*
* Hints: errno, "man 4 tty".
*/
main()
{
int fd;
fd = open("/sadf/asdf/asdf/asd", 0, 0);
if (fd == -1) {
printf("Couldn't open the file\n");
perror("open");
}
exit(0);
}
- Bill
--[0240]--
\f
[0241] daemon@TELECOM.MIT.EDU Kerberos 10/29/87 17:22 (30 lines)
Subject: Re: Hostname-instance problem
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: kerberos@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
>I think a shipped Kerberos should probably use the fully qualified domain
>names for service instances, and we should seriously consider doing
>that ourselves (even with the flag day, or duplicate entries that that
>would imply).
Using fully qualified domain names as service instances doesn't solve
the entire problem; it only avoids name conflicts when the same
kerberos server serves machines with the same initial hostname (if
there were a BINKLEY.SIPB.MIT.EDU and BINKLEY.PIKA.MIT.EDU).
The problem we're running into it is answering the question: "I'm
trying to contact this host; what realm do I use to get kerberos
tickets for it?" Cliff was originally planning on having the name
service answer this question; associated with each machine is its
Kerberos realm. This never got implemented. So right now we're stuck
with the situation where either the domain name of a hostname is used
to determine the realm (as the LCS code does it), or explicitly giving
the realm on the command line with the '-k' option (as the Athena code
does it).
Jeff talked about having a UDP service that returns the kerberos realm
name for a machine; when contacting a machine, you contact this UDP
service first to determine which realm to use.
-stan
--[0241]--
\f
[0242] daemon@TELECOM.MIT.EDU Kerberos 10/30/87 10:26 (27 lines)
Subject: Re: reporting of errors.
From: steiner@ATHENA.MIT.EDU
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 29 Oct 87 15:58:48 -0500.
> Global variables shared between libraries and applications are
> inherently _evil_, since they clutter up the namespace. In addition,
> there are insufficient constraints on when errno can and cannot be
> clobbered. Instead, use of Ken's com_err package (which is already in
> use by SMS, as well as being in use inside discuss and a few other
> places) seems to make a lot of sense.
I agree com_err is nice. It integrates lists of error codes and texts,
such as Unix system errors and Kerberos library errors, and it provides
a uniform way of printing them.
But com_err by itself doesn't enforce any policy as far as I know (and
it probably shouldn't). The error code you pass to it can be "errno",
the return value of a function, your mother's middle initial, or whatever.
What I'm wondering about are things like, should library functions print
error messages, if so, in what cases; or should they only pass on any
errors they get, if so, how; is there any time when they should abort
a program, etc.?
Jennifer
--[0242]--
\f
[0243] daemon@TELECOM.MIT.EDU Kerberos 10/30/87 12:41 (22 lines)
Subject: Re: reporting of errors.
From: Robert S. French <rfrench@ATHENA.MIT.EDU>
To: <steiner@ATHENA.MIT.EDU>
Cc: wesommer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <steiner@ATHENA.MIT.EDU>'s message of Fri, 30 Oct 87 10:25:59 EST
From: <steiner@ATHENA.MIT.EDU>
Date: Fri, 30 Oct 87 10:25:59 EST
What I'm wondering about are things like, should library functions print
error messages, if so, in what cases; or should they only pass on any
errors they get, if so, how; is there any time when they should abort
a program, etc.?
Jennifer
I strongly believe that library routines should ONLY return error
codes. The error codes should be universal across all routines (ala
com_err style). Applications should be able to deal with error codes
in their manner. The library should never force an screen display and
especially should never cause a program abort.
Rob
--[0243]--
\f
[0244] daemon@TELECOM.MIT.EDU Kerberos 10/30/87 14:23 (22 lines)
Subject: Re: reporting of errors.
To: Robert S. French <rfrench@ATHENA.MIT.EDU>
Cc: rfrench@ATHENA.MIT.EDU, <steiner@ATHENA.MIT.EDU>, wesommer@ATHENA.MIT.EDU,
In-Reply-To: Robert S. French <rfrench@ATHENA.MIT.EDU>'s message of Fri, 30 Oct 87 12:40:25 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> What I'm wondering about are things like, should library functions print
> error messages, if so, in what cases; or should they only pass on any
> errors they get, if so, how; is there any time when they should abort
> a program, etc.?
One way to think about this issue is as follows: for a library
routine to decide to print a message and abort, it is effectively
saying "for the awful situation I just discovered, there is
absolutely nothing that any application in the universe could
possibly want to--or be able to--do next, so I might as well abort."
There are cases where that is an appropriate position to take, (Unix
kernel panics tend to operate that way) but they are rare. On
the whole, I would expect the Kerberos library not to have any such
cases.
Jerry
--[0244]--
\f
[0245] daemon@TELECOM.MIT.EDU Kerberos 10/30/87 19:17 (42 lines)
Subject: given realm, where is master kerberos server?
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
This is a problem I've run into when trying to set up
a new kerberos realm on another machine. (I've talked
to several people about this and most of the ideas here
are theirs, not mine. I'm just confused.)
If you want to do a write operation (like changing a
password), the Master kerberos server must be located,
unlike read-only (authentication) operations where Slave
servers will do.
Say you know what realm you want; how do you find out
which machine the master is running on? Right now, it's
assumed to be on a machine called "kerberos". Maybe this
is a good idea; that means that, given a realm; you can
always find the master kerberos server on a machine called
"kerberos".
But the way that the local realm is found, and the way a generic
(slave or master) kerberos server is found, is done differently
and maybe that model should also be used for the master. Namely,
/etc/krb_config is consulted, and if it's not there, the
#define KRB_HOST or KRB_REALM is taken as default. The master
could be designated in the krb_config file too, or default
to a #define'd KRB_MASTER.
This would certainly make testing easier on machines which
don't happen to think their name is "kerberos", but that's
not necessarily a good reason to do it.
Another related question is: could a nameserver (Hesiod)
be used in place of the /etc/krb_config file? It could
be argued that someone could impersonate the nameserver,
but it could also be argued that that wouldn't get them
very far.
Finally, does this relate to the Hostname-as-instance problem
at all? Enlightenment would be appreciated.
Jennifer
--[0245]--
\f
[0246] daemon@TELECOM.MIT.EDU Kerberos 11/01/87 23:13 (18 lines)
Subject: get_ad_tkt
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Reply-To: tytso@ATHENA.MIT.EDU
Right now, get_ad_tkt doesn't do any sanity checking on the
ticket that it gets back from kerberos after it decrypts it. Thus, if
the ticket gets somehow garbled in transit, get_ad_tkt will blithly
(using strcpy, not strncpy, which is *ANOTHER* problem), copy garbage
into s_name and s_inst and the put said garbage into the user's ticket
file.
It should probably check to make sure that the ticket that it
got back from kerberos matches what it asked for by checking the
returned service name/instance strings. After all, get_ad_tkt can't be
*sure* that it is talking to kerberos, so it should be as paranoid as
possible.
- Ted
--[0246]--
\f
[0247] daemon@TELECOM.MIT.EDU Kerberos 11/01/87 23:30 (21 lines)
Subject: re: get_ad_tkt
To: tytso@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU, tytso@ATHENA.MIT.EDU
In-Reply-To: tytso@ATHENA.MIT.EDU's message of Sun, 1 Nov 87 23:12:34 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> It should probably check to make sure that the ticket that it
> got back from kerberos matches what it asked for by checking the
> returned service name/instance strings. After all, get_ad_tkt can't be
> *sure* that it is talking to kerberos, so it should be as paranoid as
> possible.
It should check, but primarily for human engineering, rather than
paranoia. If the Kerberos is bogus, no service will accept the
ticket anyway, so the client's data is safe. (In some relaxed
protocols the client may include some data in the same packet with
the ticket, but presumably a protocol would do that only if it
weren't paranoid about that particular data.) But if something is
just accidentally screwed up, the earlier the problem is discovered,
the easier it is to diagnose and get started untangling the mess.
Jerry
--[0247]--
\f
[0248] daemon@TELECOM.MIT.EDU Kerberos 11/01/87 23:58 (19 lines)
Subject: Re: get_ad_tkt
From: raeburn@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU
Cc: tytso@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sun, 1 Nov 87 23:29:10 EST <8711020429.AA23405@HERACLES.MIT.EDU>
One thing Ted mentioned which you missed is that the program may not
be talking to Kerberos, or that the ticket it has is actually valid;
in the interest of security (through obscurity, alas) I will not
describe a fairly simple mechanism which has been demonstrated to
bypass Kerberos authentication as it is implemented in certain
programs. (Being on the development team now, I hope to plug a few of
these.)
There is little excuse for the Kerberos library to fail to make checks
against this sort of thing. The checks can do no harm, and may plug
hole we haven't even seen yet.
-- Ken
--[0248]--
\f
[0249] daemon@TELECOM.MIT.EDU Kerberos 11/05/87 15:00 (41 lines)
Subject: Too many zephyr kerberos tickets
From: mar@ATHENA.MIT.EDU
To: zephyr-comments@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
I just noticed that I have four identical zephyr.zephyr kerberos
tickets:
Ticket file for principal mar@ATHENA.MIT.EDU
Issued Expires Principal
Nov 5 11:01:10 Nov 5 19:01:10 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
Nov 5 11:01:13 Nov 5 19:01:13 rvdsrv.eurydice@ATHENA.MIT.EDU
Nov 5 11:01:51 Nov 5 19:01:51 rvdsrv.paris@ATHENA.MIT.EDU
Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
Nov 5 11:02:39 Nov 5 19:02:39 discuss.charon@ATHENA.MIT.EDU
Nov 5 11:02:48 Nov 5 19:02:48 rvdsrv.helen@ATHENA.MIT.EDU
Nov 5 11:02:50 Nov 5 19:02:50 discuss.menelaus@ATHENA.MIT.EDU
Nov 5 11:03:00 Nov 5 19:03:00 pop.e40-po@ATHENA.MIT.EDU
Nov 5 11:03:06 Nov 5 19:03:06 rvdsrv.menelaus@ATHENA.MIT.EDU
Nov 5 11:03:01 Nov 5 19:03:01 discuss.odysseus@ATHENA.MIT.EDU
Nov 5 11:03:25 Nov 5 19:03:25 rvdsrv.theseus@ATHENA.MIT.EDU
Nov 5 11:03:21 Nov 5 19:03:21 discuss.bloom-beacon@ATHENA.MIT.EDU
Nov 5 11:03:35 Nov 5 19:03:35 discuss.matisse@ATHENA.MIT.EDU
Nov 5 13:44:56 Nov 5 19:04:56 sms.sms@ATHENA.MIT.EDU
Nov 5 14:01:12 Nov 5 19:01:12 rvdsrv.euterpe@ATHENA.MIT.EDU
On trying to duplicate this, I discovered that I usually get two
identical ones, but I couldn't get four again. I start up zephyr with
this line in my .login:
(zwgc; zlogin; zinit; zcheckmail; znol | zwrite mar) > /dev/null &
My guess is that several programs are trying to get zephyr tickets at
the same time. They each see that there are no zephyr tickets in my
ticket file, and each one fetches a ticket and appends it to the file.
The number of duplicates is determined by how many programs try to get
a ticket before the first one succeeds.
This isn't really a problem, but an interesting race condition.
-Mark
--[0249]--
\f
[0250] daemon@TELECOM.MIT.EDU Kerberos 11/05/87 15:25 (58 lines)
Subject: Too many zephyr kerberos tickets
From: probe@ATHENA.MIT.EDU
To: mar@ATHENA.MIT.EDU
Cc: zephyr-comments@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <mar@ATHENA.MIT.EDU>'s message of Thu, 5 Nov 87 14:59:44 EST <8711051959.AA13308@TOTO.MIT.EDU>
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
> From: <mar@ATHENA.MIT.EDU>
> Date: Thu, 5 Nov 87 14:59:44 EST
> Play-Safe: it could save your life
> I just noticed that I have four identical zephyr.zephyr kerberos
> tickets:
> Ticket file for principal mar@ATHENA.MIT.EDU
> Issued Expires Principal
> Nov 5 11:01:10 Nov 5 19:01:10 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
> Nov 5 11:01:13 Nov 5 19:01:13 rvdsrv.eurydice@ATHENA.MIT.EDU
> Nov 5 11:01:51 Nov 5 19:01:51 rvdsrv.paris@ATHENA.MIT.EDU
> Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
> Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
> Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
> Nov 5 11:02:17 Nov 5 19:02:17 zephyr.zephyr@ATHENA.MIT.EDU
> Nov 5 11:02:39 Nov 5 19:02:39 discuss.charon@ATHENA.MIT.EDU
> Nov 5 11:02:48 Nov 5 19:02:48 rvdsrv.helen@ATHENA.MIT.EDU
> Nov 5 11:02:50 Nov 5 19:02:50 discuss.menelaus@ATHENA.MIT.EDU
> Nov 5 11:03:00 Nov 5 19:03:00 pop.e40-po@ATHENA.MIT.EDU
> Nov 5 11:03:06 Nov 5 19:03:06 rvdsrv.menelaus@ATHENA.MIT.EDU
> Nov 5 11:03:01 Nov 5 19:03:01 discuss.odysseus@ATHENA.MIT.EDU
> Nov 5 11:03:25 Nov 5 19:03:25 rvdsrv.theseus@ATHENA.MIT.EDU
> Nov 5 11:03:21 Nov 5 19:03:21 discuss.bloom-beacon@ATHENA.MIT.EDU
> Nov 5 11:03:35 Nov 5 19:03:35 discuss.matisse@ATHENA.MIT.EDU
> Nov 5 13:44:56 Nov 5 19:04:56 sms.sms@ATHENA.MIT.EDU
> Nov 5 14:01:12 Nov 5 19:01:12 rvdsrv.euterpe@ATHENA.MIT.EDU
> On trying to duplicate this, I discovered that I usually get two
> identical ones, but I couldn't get four again. I start up zephyr with
> this line in my .login:
> (zwgc; zlogin; zinit; zcheckmail; znol | zwrite mar) > /dev/null &
> My guess is that several programs are trying to get zephyr tickets at
> the same time. They each see that there are no zephyr tickets in my
> ticket file, and each one fetches a ticket and appends it to the file.
> The number of duplicates is determined by how many programs try to get
> a ticket before the first one succeeds.
> This isn't really a problem, but an interesting race condition.
> -Mark
I have noticed that many people get multiple zephyr tickets. As you
said, this is an interesting race condition, but contrary to what you
said, I believe it can be a problem -- I have also seen incorrect time
stamps associated with the tickets indicating that there is a
file-locking problem.
-Richard Basch
--[0250]--
\f
[0251] daemon@TELECOM.MIT.EDU Kerberos 11/06/87 13:49 (11 lines)
Subject: Mailing list addition request
From: Greg Hollingsworth <gregh@TRANTOR.UMD.EDU>
To: kerberos@ATHENA.MIT.EDU
Could you add kerberos@trantor.umd.edu to the kerberos mailing list.
Also, if there is an archive of previous discussions, could you send
me a pointer to it.
Thanks,
Greg Hollingsworth (gregh@trantor.umd.edu)
University of Maryland, Systems Staff
--[0251]--
\f
[0252] daemon@TELECOM.MIT.EDU Kerberos 11/13/87 16:02 (29 lines)
Subject: an_to_ln
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: kerberos@ATHENA.MIT.EDU
In paris:/mit/srz/rpc.mountd, I have a version of Bill Sommerfeld's
an_to_ln routine that uses /etc/aname.{pag,dir} to convert
authentication names into local user names. This was part of the
original Kerberos concept, but was never implemented by the time Cliff
left.
I also changed it so that it special cases name.root to map to name.
Although this is a site-specific customization (in other words, Jeff
Schiller couldn't live without it), an_to_ln was intended to have some
site customization in it.
With this feature, users can allow arbitrary principals to map to their
user name on the local machine. This comes in very handy for people
who live on the interrealm boundary. In the same directory, I have a
modified version of rpc.mountd that uses an_to_ln to do the mapping,
and Bill's krb_alias program that allows people to update this database.
I propose that this version of an_to_ln gets installed in the kerberos
library. Athena's version of rpc.mountd should be updated, although
Jeff hasn't found the time to install it yet. If it had used an_to_ln
in the first place, it could have avoided the "it doesn't check the
realm name" bug.
Comments?
-stan
--[0252]--
\f
[0253] daemon@TELECOM.MIT.EDU Kerberos 11/13/87 22:34 (25 lines)
Subject: Re: an_to_ln
From: raeburn@ATHENA.MIT.EDU
To: srz@MELANGE.LCS.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Stan Zanarotti's message of Fri, 13 Nov 87 16:00:59 EST <8711132100.AA06250@melange.LCS.MIT.EDU>
It sounds good, but the krb_alias program, as implemented (if I
remember it right), would permit denial of service of a sort.
Consider this scenario:
I log in to Charon.
I run "krb_alias" with the appropriate arguments to map
"jon@ATHENA.MIT.EDU" to "raeburn".
Jon can no longer log in to his own account on Charon.
(Guess who I was just discussing this with?)
You would probably have to present tickets for <aname> to be mapped,
as well as tickets for the target <lname> (or someone who can get mapped
to it) in order to establish the mapping. A simple implementation
could ask for the password of the <aname> while logged in as <lname>
(which assumes that authentication and authorization have already been
established).
--[0253]--
\f
[0254] daemon@TELECOM.MIT.EDU Kerberos 11/14/87 00:06 (31 lines)
Subject: Re: an_to_ln
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: raeburn@ATHENA.MIT.EDU, srz@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
Not really a denial of service.
Jon can then log into Ken's account, remove the alias, and then delete
all of Ken's files if he's feeling nasty.
Seriously, the way to deal with this so that it doesn't become a
denial of service is to provide a remote service equivalent to
krb_alias. It would require one authenticator for a delete, and two
for an add (basically saying "equivalence these two so that A now maps
to what B maps to"); some care would have to be taken so that replays
of old authenticators in the 'B' slot wouldn't work (B would have to
contain as its checksum the quad_cksum() of A's ticket, or something
like that).
To be complete, there should also be a remote "whoami" service; you
send over the authenticator, and the other end sends back an ascii
string equivalent to what you map into.
That way, the response to that kind of hacking would be:
Jon tries to log into his account; finds that it fails ("jon
has not given permission for jon@ATHENA.MIT.EDU to log in").
Jon runs "rkrb_alias" to find out what he maps into, deletes
the mapping, (falling back to the old one, of course), and starts
winning again.
- Bill
--[0254]--
\f
[0255] daemon@TELECOM.MIT.EDU Kerberos 11/14/87 01:04 (20 lines)
Subject: Re: an_to_ln
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: wesommer@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU, srz@ATHENA.MIT.EDU,
In-Reply-To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>'s message of Sat, 14 Nov 87 00:06:08 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Jon tries to log into his account; finds that it fails ("jon
> has not given permission for jon@ATHENA.MIT.EDU to log in").
> Jon runs "rkrb_alias" to find out what he maps into, deletes
> the mapping, (falling back to the old one, of course), and starts
> winning again.
The only problem with this scenario is that an ordinary mortal who
has been victim of this hack is very unlikely to figure out what has
happened. Even after he or she finds an authentication wizard to
explain mapping, it is unlikely the victim will carry away warm
feelings toward Kerberos.
Do we really need this kind of mapping?
Jerry
--[0255]--
\f
[0256] daemon@TELECOM.MIT.EDU Kerberos 11/14/87 01:43 (24 lines)
Subject: Re: an_to_ln
From: raeburn@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sat, 14 Nov 87 01:03:41 EST <8711140603.AA02985@HERACLES.MIT.EDU>
If the user (Jon) does figure out that he has been logged into my
account, it may not be possible for him to delete the mapping.
Consider a .cshrc which says "exec myhack", which only allows escape
to a shell with a magic password. It could also fake a failed login
attempt.
Actually, where Bill mentions that Jon would get "jon has not given
permission ....", I had been assuming that the mapping was automatic
and it would be logging him into my account -- I forgot for the moment
that the username requested on the opposite end is specified elsewhere
in that particular protocol, so that what I suggest for rlogin would
not work. For protocols that depend wholly on Kerberos for
authentication, however, this would not provide a way out.
It would be very difficult to deal with inter-realm activities that
require usernames without some sort of mapping from
Kerberos-authenticated entity to user. All that is needed is the
proper caution in permitting the mappings to be set up.
--[0256]--
\f
[0257] daemon@TELECOM.MIT.EDU Kerberos 11/14/87 11:05 (59 lines)
Subject: re: an_to_ln
To: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: srz@melange.LCS.MIT.EDU (Stan Zanarotti)'s message of Fri, 13 Nov 87 16:00:59 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
I think some of this discussion is barking up the wrong tree.
There are two mapping concepts here that are best kept orthogonal.
1. Mapping from an external identity to internal identity. This
mapping should be one-to-one, should almost never change, and should
be as obvious as possible.
2. Allowing several identities to map together, to accomplish some
kind of proxy login or access control goal. This mapping should be
done either by mapping external identities to external identities, or
by mapping internal identities to internal identities.
The mapping from authentication name (Kerberos principal identifier)
to local name (the ID you have on some time-sharing system) is
something that a non-standard world forces on us, but it isn't the
right place to introduce user-settable arbitrary rebindings. The
ideal external-to-internal mapping would be the identity mapping,
because any other mapping violates the principle of minimum surprise,
an especially important principle for protection mechanisms. That
is, protection mechanisms that have non-obvious properties are
protection mechanisms that well-intentioned users have a good chance
of setting up wrong, using incorrectly, or not auditing properly.
Unfortunately, there isn't much prospect of instantly changing UNIX
to use Kerberos principal identifiers in full, or of assuming that
every local system within a Kerberos realm will change its
identifiers for users to match everyone else's names for those same
users. So some mapping is required.
I think that one balances those two pressures by:
1. Using a mapping as close to identity as possible, wherever
possible. The algorithmic mapping we use at Athena for instance-less
names is a good example.
2. Where it can't be an identity, set it up once and for all and
leave it, so that once people learn a mapping for a particular system
they don't find it changing from day to day. This consideration
argues against any discussion about what tickets you need to present
to change the mapping. Wiring it into a table that only a system
administrator can get at is actually a good idea in this case.
Since the requirements for mapping are very site-dependent, it is
possible that the Kerberos master sources need to offer a few
optional versions of the an_to_ln() function, together with a good
explanation of the tradeoffs.
And any hint of function along the line of "I want to be able to
allow that user to log in to this system as me" ought to be handled
by an orthogonal mechanism, explicitly managed as a proxy system,
with appropriate logging and safeguards.
Jerry
--[0257]--
\f
[0258] daemon@TELECOM.MIT.EDU Kerberos 11/17/87 15:39 (70 lines)
Subject: re: an_to_ln
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
>There are two mapping concepts here that are best kept orthogonal.
>1. Mapping from an external identity to internal identity. This
>mapping should be one-to-one, should almost never change, and should
>be as obvious as possible.
>2. Allowing several identities to map together, to accomplish some
>kind of proxy login or access control goal. This mapping should be
>done either by mapping external identities to external identities, or
>by mapping internal identities to internal identities.
Let me see if I can figure this through, so that I can understand
exactly what you're proposing.
Situation #1:
One capability that I want to have is NFS, POP, and rlogin access from
my LCS account over to my Athena account. This is an access decision
that I make. If this had to be done by a system administrator, I
could whine at Jeff to get this done, but it would be better if I
could set this up myself from my Athena account.
Since this is a many-to-one mapping, it would have to be covered by
mapping #2. The external identity srz@LCS.MIT.EDU would have to be
mapped to the external identity srz@ATHENA.MIT.EDU. Presumably, when
the LCS client machine contacts Athena's kerberos server, it presents
tickets authenticating me as srz@LCS.MIT.EDU. The kerberos server
would give me back tickets authenticating me as srz@ATHENA.MIT.EDU.
I can present these tickets to charon, which will allow me to access
my files.
This scheme's advantage is that it takes care of the entire realm at
once. By updating one database (the one on the kerberos server(s)), I
can allow srz@LCS.MIT.EDU proxy for srz@ATHENA.MIT.EDU, for all
services. I do not have to set up separate access control lists for
the mail services, the NFS service, etc. The disadvantages are that
there is no granularity of access control (it's all or nothing), there
is still a denial of service attack, it involves changing the Kerberos
protocol (I'm getting back different tickets than I'm asking for) and
adding another database that the kerberos server has to maintain.
Situation #2:
Athena has the concept of "root" instances, which are Kerberos
instances that are more privileged than the normal (user, "")
instances. Services with access control lists (like rlogin), will
sometimes have root instances listed, but not the normal instances.
What Jeff wants is for POP and NFS access still work with root tickets
as well as normal tickets. That is, ("jis", "root") tickets would be
able to read the mailbox for "jis", just as well as ("jis", ""). This
too is a many-to-one mapping, and therefore has to be covered by
mapping #2. The external identity jis.root@ATHENA.MIT.EDU maps to
the external identity jis@ATHENA.MIT.EDU. If this mapping was always
done before the access control list check, then the root instances would be
useless; they would simply be washed away by this mapping.
So I'm not sure how we can accomplish both goals simulateneously if we
restrict ourselves to the two types of mappings above. And if we're
giving up on any of these goals, I would like to know now.
One final observation about goal #1: The current interrealm
mechanisms in Kerberos are woefully inadequate. If we start promoting
Kerberos as the solution to inter-realm access control, we've got to
come up with better inter-realm support. Currently I am one of the
few people suffering from this; Jeff gave up on the TELECOM realm.
-stan
--[0258]--
\f
[0259] daemon@TELECOM.MIT.EDU Kerberos 11/18/87 14:39 (51 lines)
Subject: re: an_to_ln
To: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
Cc: Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: srz@melange.LCS.MIT.EDU (Stan Zanarotti)'s message of Tue, 17 Nov 87 15:38:04 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> One capability that I want to have is NFS, POP, and rlogin access from
> my LCS account over to my Athena account. This is an access decision
> that I make. If this had to be done by a system administrator, I
> could whine at Jeff to get this done, but it would be better if I
> could set this up myself from my Athena account.
I think that is pure proxy; some services support user-designated
proxies and some don't. If you originally authenticate yourself as
srz@lcs I don't think that the Athena Kerberos server has any
business giving out tickets that say you are srz@athena; it should
give tickets for Athena services but the ticket should still identify
you as srz@lcs and the service should decide whether or not it wants
to allow usage by that principal, and also whether or not to map it
to the same thing that it would map srz@athena. Similarly, if your
LCS ticket comes through saying "stan@lcs" the service gets to decide
that it wants to map that name to "srz@athena" before proceeding.
> What Jeff wants is for POP and NFS access still work with root tickets
> as well as normal tickets. That is, ("jis", "root") tickets would be
> able to read the mailbox for "jis", just as well as ("jis", ""). This
> too is a many-to-one mapping, and therefore has to be covered by
> mapping #2. The external identity jis.root@ATHENA.MIT.EDU maps to
> the external identity jis@ATHENA.MIT.EDU. If this mapping was always
> done before the access control list check, then the root instances would be
> useless; they would simply be washed away by this mapping.
Shouldn't that class of "mapping" should be handled by an access
control list that implements wild cards? For the case indicated, the
access list might say "jis.*@athena.mit.edu"
> One final observation about goal #1: The current interrealm
> mechanisms in Kerberos are woefully inadequate. If we start promoting
> Kerberos as the solution to inter-realm access control, we've got to
> come up with better inter-realm support. Currently I am one of the
> few people suffering from this; Jeff gave up on the TELECOM realm.
I think everyone agrees that there are a lot of loose ends in this
area. The trick is to separate the fundamental issues out from the
current kit bag of shortcuts and implementation hacks. In
particular, when the present implementation runs into problems, the
question each time is whether it is because of a fundamental gap in
the Kerberos design or is it because some service (or Kerberos
itself) hasn't gotten around to implementing a nominally required
feature.
Jerry
--[0259]--
\f
[0260] daemon@TELECOM.MIT.EDU Kerberos 11/20/87 15:04 (56 lines)
Subject: Re: an_to_ln
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I think part of the reason we've been having this discussion is that
Kerberos is not really complete. Only the authentication head has
been completed. Authorization is a much harder problem, but one which
we have to deal with at the present time.
Theoretically, once Kerberos provides authentication, each service can
decide what access should be given to that principal. In practice, we
want to come up with common mechanisms or tools that services can use
to make authorization decisions. Currently, I believe that discuss,
rlogin and RVD have access control lists. POP, RFS, and NFS do not.
The people who 'kerberized' these applications did not want to put in
the time to add access control lists, and the administration
associated with them. If tools were around that made this easy, then
the authorization would be there.
> Similarly, if your LCS ticket comes through saying "stan@lcs" the
> service gets to decide that it wants to map that name to "srz@athena"
> before proceeding.
I find it easier to think about this as a simple access control
problem. Instead of asking the question: "What Athena principal does
this map to before I map external names to internal names?", I ask the
question: "Does stan@lcs have access to perform the requested
operation?". For networked file systems, the requested operation is
setting up the uid mapping. Presumably, there would be an ACL for
each uid on the server; if you present tickets for a principal on the
ACL, you would be allowed to map to that uid.
To prevent a denial of service attack such as Ken described, the
client program would have to request what uid to map to, instead of
having the server decide.
> In particular, when the present implementation runs into problems, the
> question each time is whether it is because of a fundamental gap in
> the Kerberos design or is it because some service (or Kerberos itself)
> hasn't gotten around to implementing a nominally required feature.
Since the access control question can be solved by having every
service do its own access checking, I would agree that it's not a
fundamental gap with the Kerberos design. Just a major inconvenience.
If you consider the actions of the kerberos library as part of its
design, then there is a design gap that should be fixed. If I
can get LCS tickets on an Athena machine, I should be able to use LCS
services with those tickets. Right now, the library uses
/etc/krb.conf to determine the current realm, which hardwires the
machine to a given realm. If the library were changed to remember the
realm in the ticket file, then inter-realm operations would be more
useful. That way, Jeff would not have to customize /etc/krb.conf
every time he logs into a workstation to use the TELECOM realm.
-stan
--[0260]--
\f
[0261] daemon@TELECOM.MIT.EDU Kerberos 11/23/87 15:13 (8 lines)
Subject: protocol version 3
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
What exactly is the difference between versions 3 and 4
of the Kerberos protocol? Is it reasonable to stop
supporting version 3 at this time?
Jennifer
--[0261]--
\f
[0262] daemon@TELECOM.MIT.EDU Kerberos 11/25/87 01:06 (19 lines)
Subject: protocol version 3
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: steiner@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <steiner@ATHENA.MIT.EDU>'s message of Mon, 23 Nov 87 15:12:03 EST <8711232012.AA18671@BACH>
From: <steiner@ATHENA.MIT.EDU>
Organization: Project Athena, MIT Cambridge MA
Date: Mon, 23 Nov 87 15:12:03 EST
What exactly is the difference between versions 3 and 4
of the Kerberos protocol? Is it reasonable to stop
supporting version 3 at this time?
Jennifer
Version 3 was the pre-realm version. Ie. there was just one realm "the"
realm. Now is probably a very good time to drop its support.
-Jeff
--[0262]--
\f
[0263] daemon@TELECOM.MIT.EDU Kerberos 11/29/87 16:42 (29 lines)
Subject: Kerberos login suggestions
From: treese@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
Situation:
1. I ksu on my workstation.
2. I rlogin to paris as root.
Problems:
1. A "finger" shows "root" logged in. When I notice root logged in
on paris, I always check to see who it is (a little paranoia).
2. My environment is the vanilla root one; there is no way for me
to customize it.
Since login in this situation knows that it is me, logging in with a root
instance, it seems that it could do the following:
1. Note the entry in utmp as something like "#treese" instead of
"root". The '#' indicates that this is really a root login,
similar to the '*' used on a login server. (this change may
actually be in klogind; I don't recall now who does that).
2. login could set two environment variables, KUSER and INSTANCE
that could be used in .login/.cshrc files to customize the
environment.
Comments?
- Win
--[0263]--
\f
[0264] daemon@TELECOM.MIT.EDU Kerberos 11/29/87 17:54 (16 lines)
Subject: re: Kerberos login suggestions
To: <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Sun, 29 Nov 87 16:39:54 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> 1. Note the entry in utmp as something like "#treese" instead of
> "root". The '#' indicates that this is really a root login,
> similar to the '*' used on a login server. (this change may
> actually be in klogind; I don't recall now who does that).
If utmp has room, how about noting the entry as "treese.root". Using
the full (external) Kerberos name.instance also extends in an obvious
way to cover some other cases that may come up.
Jerry
--[0264]--
\f
[0265] daemon@TELECOM.MIT.EDU Kerberos 11/29/87 17:54 (54 lines)
Subject: why knetd?
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
After reviewing the archives of this list, and thinking about the
upcoming distribution of kerberos, I think it's time to once again ask
the question "why knetd?" Is there a valid reason for its existence
and should we ship it or admit it was ill-conceived and punt while it's
still easy.
Bascially there seem to have been two factors which motivated the
development of knetd:
1) a desire for a "toolkit" layer dealing with the guts of
authentication/authorization so the applications don't have to.
2) conservation of well-known ports
Now, nobody would pretend that #1 has been accomplished. Instead, knetd
currently just accepts connections on the knetd port, reads a bit of
information including the "service" name, forks the appropriate server
(from knetd.conf). No useful authentication/authorization is done
either for client or server! Indeed most servers will need to do
their own authorization in any case.
So all we are left with is an de-multiplexer, which allows us to
succeed in #2, conservation of well-known ports. But I would argue
that two years later (or whatever), that has become a moot point.
Why do you want to control growth of well-known ports? Becuase it's
hard to add new ones? Adding new services is just not difficult. The
majority of people out there will have some Yellow Pages/Hesiod
mechanism for updating information contained in /etc/services, so it
does not requiring updating of thousands of files.
Because you have to register it with the NIC? Better reason, but
people these days hardly seem to care.
And what does using one port cost you? Mainting knetd.conf, knetd,
and *losing* information when using netwatch/netstat! (Is that knetd
connection a telnet, rcp, or pop connect?). The port name scheme for
TCP/IP works fine, and has plenty for room for hundred's of new port
assigments. Do we really need to have a kerberos scheme for naming
network ports?
Somehow I think knetd is a nice idea that just doesn't pan out. I
don't seen the need for the extra complexity of explaining another
daemon, another library, another config file, etc ...
Comments?
-- Jon
--[0265]--
\f
[0266] daemon@TELECOM.MIT.EDU Kerberos 11/29/87 22:37 (43 lines)
Subject: re: why knetd?
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jon Rochlis <jon@ATHENA.MIT.EDU>'s message of Sun, 29 Nov 87 17:37:31 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Bascially there seem to have been two factors which motivated the
> development of knetd:
> 1) a desire for a "toolkit" layer dealing with the guts of
> authentication/authorization so the applications don't have to.
> 2) conservation of well-known ports
Jon,
As I recall, number 1 was not directed at creation of a general
toolkit but rather at the creation of a crutch for preexisting
applications, to minimize the work required to mediate them with
Kerberos. By providing an interface with an inetd-type handoff, the
idea was that you could secure any inetd-implemented protocol without
having to go inside its implementation; just tack on a standard
prefix to the protocol that is stripped off by knetd before the
handoff.
I'd be interested in hearing how successful knetd was in achieving
that goal. If it worked well, maybe the thing to do is simplify it a
bit by using one well-known port per service. That way, knetd could
probably be merged with inetd, leaving a single demon driven from a
single configuration file. (I think that covers all the costs you
listed!)
On the subject of well-known ports, my intuition tells me there is
something not quite right about a requirement to have an entry in
Hesiod, the Yellow Pages, or /etc/services in order to offer a new
service. Somehow it seems it should be possible to offer services
without requirement of a central registry; if I know the name of the
server (which is centrally registered) and the name it knows the
service by, that ought to be sufficient. Central registration of
service names should be possible, but not required. The knetd design
was (perhaps too much) influenced by that consideration.
(Of course lack of central registration does, by definition, make the
life of netwatch harder.)
Jerry
--[0266]--
\f
[0267] daemon@TELECOM.MIT.EDU Kerberos 11/29/87 23:29 (37 lines)
Subject: Re: atalanta build
From: billb@ATHENA.MIT.EDU
To: <steiner@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Sun, 29 Nov 87 13:03:22 -0500.
Jennifer,
John and I tried to build the animal Sunday night. After many misadventures,
including the editing of makefiles to reflect the new source tree layout,
we discovered that a macro defined in include/prot.h has been ifdefed out
of existence for the RT. Said macro is pkt_time_ws:
#ifdef MUSTALIGN
/* pkt_time_ws has to be rewritten for RT */
#else
#define pkt_time_ws(packet) (unsigned long *) \
(packet->dat+5+strlen((char *)pkt_a_name(packet)) + \
strlen((char *)pkt_a_inst(packet)) + \
strlen((char *)pkt_a_realm(packet)))
#endif MUSTALIGN
Can't build the software until the macro is written for the RT.
(The build fails when trying to construct the programs in
the server directory; both kerberos and kerberos_slave need the macro.)
Anyone out there have time to fix this? ASAP?
Regards, etc.
Bill and John
--[0267]--
\f
[0268] daemon@TELECOM.MIT.EDU Kerberos 11/30/87 00:17 (38 lines)
Subject: Kerberos login suggestions
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: treese@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU
In-Reply-To: <treese@ATHENA.MIT.EDU>'s message of Sun, 29 Nov 87 16:39:54 EST <8711292139.AA06453@CIROCCO.MIT.EDU>
From: <treese@ATHENA.MIT.EDU>
Date: Sun, 29 Nov 87 16:39:54 EST
Situation:
1. I ksu on my workstation.
2. I rlogin to paris as root.
Problems:
1. A "finger" shows "root" logged in. When I notice root logged in
on paris, I always check to see who it is (a little paranoia).
2. My environment is the vanilla root one; there is no way for me
to customize it.
Since login in this situation knows that it is me, logging in with a root
instance, it seems that it could do the following:
1. Note the entry in utmp as something like "#treese" instead of
"root". The '#' indicates that this is really a root login,
similar to the '*' used on a login server. (this change may
actually be in klogind; I don't recall now who does that).
2. login could set two environment variables, KUSER and INSTANCE
that could be used in .login/.cshrc files to customize the
environment.
Comments?
Good idea. All the work is in "login". klogind merely tells
login that "root" is trying to login, "login" is the guy who looks at
the kerberos data to see who it really is.
-Jeff
--[0268]--
\f
[0269] daemon@TELECOM.MIT.EDU Kerberos 11/30/87 12:18 (55 lines)
Subject: Re: why knetd?
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: Rochlis <jon@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sun, 29 Nov 87 22:33:20 EST,
By providing an interface with an inetd-type handoff, the
idea was that you could secure any inetd-implemented protocol without
having to go inside its implementation; just tack on a standard
prefix to the protocol that is stripped off by knetd before the
handoff.
But that's not what knetd does! All knetd mediates is who gets forked
(ignoring internal services). The only difference between knetd and
inetd is that knetd uses a string passed as the first bytes in the
data stream to name the service and inetd uses the internet port of
the destination address to decide what to fork.
knetd does *not* currently do anything which resembles "securing any
inetd-implemented protocol with having to go inside of its
implementation." You still have to muck with the application, if only
to read off the ticket (the second thing in the data stream) and do
authorization.
I'd be interested in hearing how successful knetd was in achieving
that goal. If it worked well, maybe the thing to do is simplify it a
bit by using one well-known port per service. That way, knetd could
probably be merged with inetd, leaving a single demon driven from a
single configuration file. (I think that covers all the costs you
listed!)
It's a total failure in my opinion. The only vaguely useful things
are (Send Receive)KerberbosData which are only 15 lines long and should
be provided as part of libkrb. All they do is take a file descriptor,
service name, host name (really service instance of course), write (/read) the
service name on the file descriptor, do a mk_ap_req (/rd_ap_req) and
write (/read) the ticket on the file descriptor.
Somehow it seems it should be possible to offer services
without requirement of a central registry; if I know the name of the
server (which is centrally registered) and the name it knows the
service by, that ought to be sufficient.
That's what Sun did with portmapper. But it still argues against
multiplexing the use of a single port. My point is no matter how you
do it, you should be able to come up with a port to use to connect to
your kerberos service. It doesn't matter to me whether its through a
nameservice, /etc/services, portmapper or whatever. Knetd doesn't
have to be in between. There are enough naming mechanisms already and
adding one more piece of complexity with dubious functionality is not a good
idea.
I say knetd should be dropped while we still have the chance.
-- Jon
--[0269]--
\f
[0270] daemon@TELECOM.MIT.EDU Kerberos 11/30/87 17:55 (15 lines)
Subject: Re: Kerberos login suggestions
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: <treese@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Sun, 29 Nov 87 17:46:53 -0500.
From: Win Treese <treese@ATHENA.MIT.EDU>
> If utmp has room, how about noting the entry as "treese.root". Using
> the full (external) Kerberos name.instance also extends in an obvious
> way to cover some other cases that may come up.
Unfortunately, utmp has only 8 characters for the username...
- Win
--[0270]--
\f
[0271] daemon@TELECOM.MIT.EDU Kerberos 11/30/87 19:14 (12 lines)
Subject: Re: Kerberos login suggestions
To: Win Treese <treese@ATHENA.MIT.EDU>
Cc: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>, <treese@ATHENA.MIT.EDU>,
In-Reply-To: Win Treese <treese@ATHENA.MIT.EDU>'s message of Mon, 30 Nov 87 17:51:37 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Unfortunately, utmp has only 8 characters for the username...
I was afraid of that. In that case, how does the * work on dialin
passthrough? Does the last character of long usernames get
truncated?
Jerry
--[0271]--
\f
[0272] daemon@TELECOM.MIT.EDU Kerberos 12/01/87 11:16 (18 lines)
Subject: Re: kerberos login suggestions.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
>I was afraid of that. In that case, how does the * work on dialin
>passthrough? Does the last character of long usernames get
>truncated?
Yes. But a comment in <utmp.h> implies that the size of '8' is not
magic; however, I don't want to think about what would break if it
were changed.
Perhaps the fix _might_ be to stick the information into the "ut_host"
field (which is 16 characters long) instead.
I hate fixed-length-field databases.
- Bill
--[0272]--
\f
[0273] daemon@TELECOM.MIT.EDU Kerberos 12/01/87 14:25 (13 lines)
Subject: Re: kerberos login suggestions.
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Tue, 01 Dec 87 11:15:59 EST.
To change the size of the fields, you would have to look at every
program that uses <utmp.h>. Many of them probably use string routines
with a count of "8" instead of using a sizeof(). There may even be a
few programs that assume null termination floating around. Bill can
exercise a few of the bugs if they exist (8 char login).
Jim
--[0273]--
\f
[0274] daemon@TELECOM.MIT.EDU Kerberos 12/01/87 14:41 (12 lines)
Subject: Re: kerberos login suggestions.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
Cc: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>, Saltzer@ATHENA.MIT.EDU,
In-Reply-To: Jim Bloom's message of Tue, 01 Dec 87 13:30:18 EST,
Bill can exercise a few of the bugs if they exist (8 char login).
I already have (several times), although only in locally developed
code (John Romkey's rewrite of finger and one intermediate version of
the locally-hacked MDQS).
- Bill
--[0274]--
\f
[0275] daemon@TELECOM.MIT.EDU Kerberos 12/01/87 16:02 (9 lines)
Subject: kerberos login suggestions.
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: jb%cs.brown.edu@RELAY.CS.NET
Cc: wesommer@ATHENA.MIT.EDU, Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jim Bloom's message of Tue, 01 Dec 87 13:30:18 EST <8712011830.AA04155@archer.cs.brown.edu>
Lets also not forget some programs that we have in binary form only that
look at this file (like RTI Ingres for example).
-Jeff
--[0275]--
\f
[0276] daemon@TELECOM.MIT.EDU Kerberos 12/01/87 16:11 (13 lines)
Subject: Re: kerberos login suggestions.
To: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
Cc: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>, Saltzer@ATHENA.MIT.EDU,
In-Reply-To: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>'s message of Tue, 01 Dec 87 13:30:18 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> To change the size of the fields, you would have to look at every
> program that uses <utmp.h>. Many of them probably use string routines
> with a count of "8" instead of using a sizeof(). There may even be a
> few programs that assume null termination floating around.
Wouldn't touch this one with a ten foot pole.
Jerry
--[0276]--
\f
[0277] daemon@TELECOM.MIT.EDU Kerberos 12/07/87 14:06 (44 lines)
Subject: timestamps in Kerberos: a question
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Timestamps are used in the Kerberos protocol to help
detect replays of messages. The current status of
timestamps in Kerberos is: they are described in the
Technical Plan. They are partially implemented.
Partially implemented means that the timestamps are
inserted into messages from the user to Kerberos and
in Kerberos' reply back to the user. (I haven't looked
carefully at how they're used in the user->server exchange
yet.) Although the timestamps are sent back and forth
from user to Kerberos and back, no one ever looks at them.
My question is this: use of timestamps to preclude replays
is described inconsistently in the Technical Plan and I
wonder which way it should be.
1. On page 8, 4 paragraphs into the "4. The Kerberos Authentication
Model" section, it is stated that, in the part of the message
which Kerberos returns to the user, which is encrypted in the
user's private key, a "copy of the timestamp that was in the
original request" is inserted. In other words, a copy of the
timestamp which the client sent in the request, which the
client keeps a copy of.
2. On the other hand, on page 24, in the Protocol description of
the KKDS (section 7.1.2), it is stated that, in the reply from
Kerberos back to the user, one of the components of the "cipher"
(the part of the message encrypted in the user's private key,
as above) is
time_sec[kkds]
or the time of day according to the Kerberos server.
In the implementation, the second method is used. Could someone
shed some light; which one is correct, and what is the rationale
behind it?
Thanks,
Jennifer
--[0277]--
\f
[0278] daemon@TELECOM.MIT.EDU Kerberos 12/08/87 11:03 (11 lines)
Subject: timestamps in Kerberos: a question
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: steiner@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <steiner@ATHENA.MIT.EDU>'s message of Mon, 07 Dec 87 14:05:08 EST <8712071905.AA00929@BACH>
Time stamps as a mechanism to detect replay in the
user<=>kerberos interchange is unimportant (ie. nothing is gained for
an intruder to replay a request of reply). The truely interesting case
in in the user=>server interaction.
-Jeff
--[0278]--
\f
[0279] daemon@TELECOM.MIT.EDU Kerberos 12/08/87 13:00 (57 lines)
Subject: re: timestamps in Kerberos: a question
To: steiner@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU,
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Tue, 8 Dec 87 11:03:16 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Time stamps as a mechanism to detect replay in the
> user<=>kerberos interchange is unimportant (ie. nothing is gained for
> an intruder to replay a request of reply). The truely interesting case
> in in the user=>server interaction.
A standard technique in checking validity of received, encrypted,
material is that the encrypted data should always contain some item
whose value the recipient can predict; if the recipient doesn't find
that value, there is immediate warning that the receiver and sender
aren't key-synchronized. This is, of course, a probabilistic test
that improves in quality as the predictable data value grows in
bit-length. The time-stamp could serve that function, in which case
the return of the originator's time stamp would be more effective
than inserting the server's time stamp. (Looking for a range of
values isn't as good because it increases the chance that random data
will be accepted.)
In the case of the client-Kerberos interaction, there is another
predictable data value that can serve this function, the name of the
service for which this ticket is intended. If that service name is
at least as long as a timestamp, (and assuming that the client checks
the service name, which check it omits at its grave peril!) then it
can serve the validity-checking function, and the timestamp serves
only to catch certain denial-of-service attacks early in the
ticket-analysis process.
The detectable denial-of-service attack is for an interloper to
intercept the reply and hand the client instead a duplicate of a
reply to an earlier request for the same service but from months ago
when it had a different key. If there is a time-stamp in the
response, a careful client will immediately notice something amiss,
rather than being bewildered when the service rejects the ticket as
indecipherable.
Bottom line for the client-Kerberos interaction: The predictable data
in the enciphered part of the response consists of the service name
and instance, and the time stamp. (The session key and encrypted
ticket are advertised as unpredictable, the realm is filled in by
the server, possibly different from what the client expected, the
lifetime isn't controlled by the client, and even the version number
could be from a range if we are in the middle of a protocol
transition.) Since we don't control how long a service name is
(could be one byte with a null instance), it is probably a good idea
to also have the timestamp for the purpose of authenticating the
encryption key, in which case it ought to be a copy of the client's
timestamp.
Anyone else care to try an analysis? This stuff is tricky and there
are usually at least three different analyses, all of which sound
equally plausible at first. (And all of which may turn out to be
faulty.)
Jerry
--[0279]--
\f
[0280] daemon@TELECOM.MIT.EDU Kerberos 12/08/87 14:45 (35 lines)
Subject: Re: Kerberos timestamps
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER@DECWRL.DEC.COM
In reply to the three previous messages on this.
I agree with Jeff and Jerry.
Jennifer's message refers to two distinct timestamps used for two different
purposes. Both timestamps are completely implemented in the protocol messages.
The first, sent from a client to Kerberos and back, is really just a bookeeping
aid for the client. The Kerberos server COULD detect that the client's
timestamp is too far out of whack and reject it, but in the version of
the code I have (year and a half old) it doesn't.
The second, the time_sec[kkds] (section 7.1.2) on the auth_reply message
serves two purposes. First, it provides an authenticated timestamp of the
KDC as a reference. The (old) client code does indeed check this time against
the local time, and causes an error if it is too far off. The second
purpose it serves is to detect modification of the reply message. Based
on the way the crypto algorithms work, modifying only a single bit
anywhere in the encrypted part of the message preceeding the time_sec[kkds]
will cause approximately half of the bits in time_sec[kkds] to change.
This would most likely result in a time_sec[kkds] that is out of range
with respect to local time, so an error is caused. So this serves as
a mechanism to protect the client against forged/modified messages
returned from the Kerberos server.
Timestamps are used in a similar fashion in the exchange between a
client and server, sections 7.1.3, and are embedded in tickets. They can detect
certain replay attempts and modification attempts. They
are also used to enforce the expiration of tickets, based on the
timestamp plus lifetime.
Steve
--[0280]--
\f
[0281] daemon@TELECOM.MIT.EDU Kerberos 12/08/87 16:35 (44 lines)
Subject: Re: Kerberos timestamps
To: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: miller%erlang.DEC@decwrl.dec.com (Steve Miller)'s message of 8 Dec 87 14:46
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Steve,
Thanks for your comments. Two clarifications:
> The first, sent from a client to Kerberos and back, is really just a
> bookeeping aid for the client.
According to the protocol specification, the client's timestamp is
returned to the client in the clear, rather than in the
enciphered-in-the-client-key section of the response, so I don't see
that it has any security value. Its only use seems to be as a hint
in matching this response with the corresponding request.
> The Kerberos server COULD detect that
> the client's timestamp is too far out of whack and reject it, but in
> the version of the code I have (year and a half old) it doesn't.
> The second, the time_sec[kkds] (section 7.1.2) on the auth_reply message
> serves two purposes. First, it provides an authenticated timestamp of the
> KDC as a reference.
If the Kerberos server were to check the client timestamp to verify
that it is in range, and then return that timestamp in the
enciphered-in-the-client-key section of the response, wouldn't that
provide an equally good reference?
[Aside: An interesting addition to the protocol could be a field
returned from the Kerberos server to the client that gives the
difference between the client's timestamp and the Kerberos server's
clock. That would allow the client to know just what a server
timestamp would contain (and exactly when the tickets expire), and
also how far different the clocks are, so as to allow reporting
drift.]
Returning the client's original timestamp would also improve the
reliability of modification detection, because the client could then
look for exact match rather than for out-of-range value.
Jerry
--[0281]--
\f
[0282] daemon@TELECOM.MIT.EDU Kerberos 12/08/87 17:45 (21 lines)
Subject: More protocol discussion
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER@DECWRL.DEC.COM
Sorry. Fat fingered the editor, didn't think it would send it off.
The point of the redefined requirement is that the calling thread
needs the ability to specify particular routines that block it after the
request has been sent, and unblock it after the response has been received.
Normally, we expect that this is specified at stub generation time or
link time, for example to hook into the ADA run-time threads package.
The architecture does not distinguish between the user and kernel mode
parts of a call. For modeling purposes, assume there is just a single
thread that executes in user and/or kernel mode
until the message is physically on the wire, then blocks. Similarly,
it unblocks as soon as the response is received, and continues executing
to provide the reply arguments, et. al, to the user. The fact that a
real kernel queues requests and has its own internal threads is not
relevant to our architecture.
Steve
--[0282]--
\f
[0283] daemon@TELECOM.MIT.EDU Kerberos 12/09/87 14:23 (53 lines)
Subject: More re Kerberos
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
(Sorry about the misdirected message re threads et al. Ignore it.
This is the one that was intended-- it may be a duplicate.)
From: ERLANG::MILLER "Steve Miller" 8-DEC-1987 17:36
To: MILLER,MILLER
Subj: Kerberos
Jerry,
First set of your clarifications, agreed -- that is all that I meant.
>If the Kerberos server were to check the client timestamp to verify
>that it is in range, and then return that timestamp in the
>enciphered-in-the-client-key section of the response, wouldn't that
>provide an equally good reference?
>
Almost agreed. There is a subtle difference. The kkds time represents
events, and their sequence, at the Kerberos server(s), and is embedded in the
ticket and used for calculating expiration times. This both gives a more
uniform time reference, since the Kerberos server(s) are centrally managed,
and creates a better partial ordering of events at the server and on the
network. This is useful for debugging and auditing. For example, alternatively,
if the time embedded in the ticket was the workstation time, you could get
anomalous situations where the ticket was granted with a timestamp that
preceeds the time at the Kerberos server when the client or server was
defined (or modified, etc.,) in the Kerberos database.
>[Aside: An interesting addition to the protocol could be a field
>returned from the Kerberos server to the client that gives the
>difference between the client's timestamp and the Kerberos server's
>clock. That would allow the client to know just what a server
>timestamp would contain (and exactly when the tickets expire), and
>also how far different the clocks are, so as to allow reporting
>drift.]
Fine, as long as it is encrypted. Is it worth the price of encryption?
>Returning the client's original timestamp would also improve the
>reliability of modification detection, because the client could then
>look for exact match rather than for out-of-range value.
True, but not of practical concern. Even a single bit modification to
the ciphertext will change roughly half of the following bits, so
between the timestamp range and changes to the preceeding fields,
all modifications will almost certainly be detected. In the worst
case, checking the range will cause roughly 300/4,000,000,000 undetected
errors, while checking the specific value will be lower by the factor
of 300 (5minutes).
Steve (enjoying a little bit of a diversion).
--[0283]--
\f
[0284] daemon@TELECOM.MIT.EDU Kerberos 12/11/87 16:08 (43 lines)
Subject: [Steven L. Waldbusser: Vice Authentication]
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
You might be interested in the following paper. The whole paper can
be found in /mit/jon/Random/Text/vice.PS (spify poscript figures and
all). An abreviated lpt version of particular relevance to
athentication can be found in the RMAIL file /mit/jon/Mail/awg ...
-- Job
INTEGRATING SECURITY IN A LARGE DISTRIBUTED SYSTEM
M. Satyanarayanan
Department of Computer Science
Carnegie Mellon University
30 November 1987
ABSTRACT
Andrew is a distributed computing environment that is a synthesis of
the personal computing and timesharing paradigms. When mature, it is
expected to encompass over 5000 workstations spanning the Carnegie
Mellon University campus. This paper examines the security issues that
arise in such an environment and describes the mechanisms that have
been developed to address them. These mechanisms include the logical
and physical separation of servers and clients, support for secure
communication at the remote procedure call level, a distributed
authentication service, a file-protection scheme that combines access
lists with Unix mode bits, and the use of encryption as a basic
building block. The paper also discusses the assumptions underlying
security in Andrew and analyses the vulnerability of the system. Usage
experience reveals that resource control, particularly of workstation
CPU cycles, is more important than originally anticipated and that the
mechanisms available to address this issue are rudimentary.
--[0284]--
\f
[0285] daemon@TELECOM.MIT.EDU Kerberos 12/16/87 15:22 (29 lines)
Subject: [John D. Kubiatowicz: Re: Problems with /etc/knetd ]
From: Jean Marie Diaz <ambar@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Reply-To: ambar@ATHENA.MIT.EDU
something to check for the beta release..
AMBAR
To: Tony Della Fera <tony@ATHENA.MIT.EDU>
Cc: vs-testers@ATHENA.MIT.EDU
Subject: Re: Problems with /etc/knetd
In-Reply-To: Your message of Wed, 16 Dec 87 12:51:37 -0500.
<8712161751.AA00482@NESKAYA.MIT.EDU>
Date: Wed, 16 Dec 87 14:53:24 EST
From: John D. Kubiatowicz <kubitron@ATHENA.MIT.EDU>
Do you have an /etc/krb.conf? How about /usr/etc/knetd.conf? Does
/etc/services have kerberos ports defined? Do you have an /etc/srvtab
(I'm assuming so, since you seem to have used knetd before)?
| The knetd has a particularly nasty habit of merely exiting without
| giving error messages. However, the above questions are pertinent. I
| don't have immediate access to a 6.0 vs machine, so I can't check it
| out.
Incidentally, if I remember the correctly, the 6.0 release IS missing
the link between /usr/etc/login.krb and /bin/login. Consequently,
attempts to login via kerberos aren't successful.
--[0285]--
\f
[0286] daemon@TELECOM.MIT.EDU Kerberos 12/17/87 14:58 (92 lines)
Subject: updating credits
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Kerberos documents, sources, and man pages are being
updated, and new documentation and papers on Kerberos are
being written. I'd like to make sure that we give credit
where it's due, but since I wasn't here for most of Kerberos's
history, I need help getting it right.
Below is a list of credits. Please let me know of any people
or categories I have left out or which should be changed.
Jennifer
-------
Designers
Steven Miller
Cliff Neuman
Jeff Schiller
Jerry Saltzer
Contributors of ideas
Jim Bloom
Bill Bryant
Dan Geer
Jon Rochlis
Win Treese
Stan Zanarotti
Main Implementers
Mark Colan
Steve Miller
Cliff Neuman
Jeff Schiller
Stan Zanarotti
Contributing Implementors
John Barba
Richard Basch
Chris Reed
Jennifer Steiner
People who contributed but I don't know how or to
what extent (help)
Jim Aspnes
Bob Baldwin
Rob French
John Kohl
John Kubiatowicz
Brian Murphy
John Ostlund
Ken Raeburn
Bill Sommerfeld
Ted T'so
Documentors
Bill Bryant
What about people who have written 'Kerberized' applications?
-------
Where credit is noted
Technical Plan
designers (authors)
everybody else (acknowledgements)
Kerberos introductory man page
everybody?
Individual man pages
implementors of topic
Individual source files
original implementor
anyone making major revisions
Other documentation, such as Kerberos administrators manual
documentor (author)
Papers (we're writing one now for Usenix)
everybody (acknowledgements)
Anything else?
--[0286]--
\f
[0287] daemon@TELECOM.MIT.EDU Kerberos 12/18/87 18:54 (12 lines)
Subject: misparsable/ambiguous error message
To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
nfsid: can't find ticket (get credentials) (for instance paris realm
Athena.MIT.EDU)
I know there isn't a comma after the phrase "for instance" but I
persist in misreading it anyway. A colon after the "for" would help
disambiguate it a little.
Jerry
--[0287]--
\f
[0288] daemon@TELECOM.MIT.EDU Kerberos 12/18/87 23:31 (26 lines)
Subject: misparsable/ambiguous error message
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Fri, 18 Dec 87 18:53:16 EST <8712182353.AA20989@HERACLES.MIT.EDU>
Date: Fri, 18 Dec 87 18:53:16 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
nfsid: can't find ticket (get credentials) (for instance paris realm
Athena.MIT.EDU)
I know there isn't a comma after the phrase "for instance" but I
persist in misreading it anyway. A colon after the "for" would help
disambiguate it a little.
Actually this whole message is bogus. The problem (correct me
if I am wrong, Jerry) was that your ticket granting ticket had
expired. I see no mention of that fact in the error message. In fact
the message itself conveys very little information (beside the obvious
"something spazzed" to anyone but a kerberos guru, who having studied
at the prescribed oracles knows what the message can fortell!).
-Jeff
--[0288]--
\f
[0289] daemon@TELECOM.MIT.EDU Kerberos 12/19/87 18:21 (33 lines)
Subject: Re: misparsable/ambiguous error message
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Cc: Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 18 Dec 87 23:31:17 -0500.
From: Win Treese <treese@ATHENA.MIT.EDU>
> Actually this whole message is bogus. The problem (correct me
> if I am wrong, Jerry) was that your ticket granting ticket had
> expired. I see no mention of that fact in the error message. In fact
> the message itself conveys very little information (beside the obvious
> "something spazzed" to anyone but a kerberos guru, who having studied
> at the prescribed oracles knows what the message can fortell!).
Jeff is right, there's a real error message problem here. There are actually
two problems:
1) nfsid isn't being very friendly. It's got serious problems with error
messages, and those I will take care of fixing. But,
2) the Kerberos library error messages aren't very helpful, either.
In the error message original sent by Jerry:
nfsid: can't find ticket (get credentials) (for instance paris realm
Athena.MIT.EDU)
The "can't find ticket (get_credentials)" is from the Kerberos library table
of error messages, and the rest is supplied by nfsid. The Kerberos error
in this case isn't always clear, either.
- Win
--[0289]--
\f
[0290] daemon@TELECOM.MIT.EDU Kerberos 12/20/87 02:12 (11 lines)
Subject: Re: misparsable/ambiguous error message
From: srz@ATHENA.MIT.EDU
To: treese@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
Just to add some more fuel to the flames, the version of nfsid I
copied over to LCS is losing on realm names. For instance, I
can do an nfsid to host 'paris.MIT.EDU', but not for 'paris.mit.edu'.
Another case where case-sensitivity is causing problems. This would
result in the same error message that Jerry got...
-stan
--[0290]--
\f
[0291] daemon@TELECOM.MIT.EDU Kerberos 12/20/87 12:44 (23 lines)
Subject: Re: misparsable/ambiguous error message
From: steiner@ATHENA.MIT.EDU
To: Win Treese <treese@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Sat, 19 Dec 87 18:19:14 -0500.
Win is right; several kinds of errors map to the "can't get
ticket (get_credentials)" error. Would the following breakdown
in error messages suffice?
problem with ticket file (perror)
could be it doesn't exit,
can't be read,
is locked by another application,
is in bad format (not perror in this case;
Kerberos bad-ticket-file-format error)
ticket-granting ticket expired -- run "kinit"
Rob French pointed this out.
There's no point in going to Kerberos and
asking for an application ticket when the
ticket-granting ticket is expired.
Jennifer
--[0291]--
\f
[0292] daemon@TELECOM.MIT.EDU Kerberos 12/20/87 14:48 (13 lines)
Subject: Re: misparsable/ambiguous error message
From: srz@ATHENA.MIT.EDU
To: steiner@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I think error messages should be as fine grained as possible. If the
ticket file is locked, and we can determine that, we should state
that in the message. Ticket granting ticket expired, unknown realm,
time out-of-sync with kerberos, non-existent ticket file, etc, should
all have different error messages; it makes tracking down errors
much easier. With the current software, the only way of tracking down
what "Can't get credentials" means is using dbx on the kerberos library.
-stan
--[0292]--
\f
[0293] daemon@TELECOM.MIT.EDU Kerberos 12/20/87 16:13 (14 lines)
Subject: Re: misparsable/ambiguous error message
To: <srz@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <srz@ATHENA.MIT.EDU>'s message of Sun, 20 Dec 87 14:48:06 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I think error messages should be as fine grained as possible.
I agree; Stan has the right handle on this problem. In an
environment where many different things can go wrong, it is far more
user-friendly to give a precise description of what happened. To a
first approximation, every different test that can fail ought to
result in a distinct error message.
Jerry
--[0293]--
\f
[0294] daemon@TELECOM.MIT.EDU Kerberos 12/20/87 16:13 (17 lines)
Subject: Re: misparsable/ambiguous error message
To: <srz@ATHENA.MIT.EDU>
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <srz@ATHENA.MIT.EDU>'s message of Sun, 20 Dec 87 02:12:14 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Just to add some more fuel to the flames, the version of nfsid I
> copied over to LCS is losing on realm names. For instance, I
> can do an nfsid to host 'paris.MIT.EDU', but not for 'paris.mit.edu'.
> Another case where case-sensitivity is causing problems. This would
> result in the same error message that Jerry got...
As I have indicated before, I would recommend fixing this particular
problem by making Kerberos case-insensitive. Then, an improved
error message ("realm does not match", or whatever) would become
genuinely helpful.
Jerry
--[0294]--
\f
[0295] daemon@TELECOM.MIT.EDU Kerberos 12/21/87 10:45 (32 lines)
Subject: timestamps revisited
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
According to Steve's mail about timestamps, there are
two timestamps sent back to the client from the authentication
server: one is a copy of the client's original timestamp, sent
in the clear; the other is the Kerberos timestamp, sent back to
the client encrypted in the client's private key.
In that case, the Technical Plan is misleading. It says
... Anyone could send such a message or intercept its
response; that response, however, is usable only to the client named in
the original request, because Kerberos seals the response by
enciphering it in the private key of that client. The response contains
three parts: the ticket (which itself is further sealed in the private
key of the service), a newly-minted key for use in this client-server
session, and a copy of the timestamp that was in the original request.
I've modified it to read:
... Anyone could send such a message or intercept its
response; that response, however, is usable only to the client named in
the original request, because Kerberos seals the response by
enciphering it in the private key of that client. The response contains
three parts: the ticket (which itself is further sealed in the private
key of the service), a newly-minted key for use in this client-server
session, and the time of day according to the Kerberos server. A copy
of the client's original timestamp is returned in the clear, as a
bookkeeping aid to the client.
Jennifer
--[0295]--
\f
[0296] daemon@TELECOM.MIT.EDU Kerberos 12/21/87 11:37 (53 lines)
Subject: Re: Timestamps revisited
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
If you want to make the documentation entirely accurate, but without
drowning the intent in the detail, you would have to make the further changes
I am suggesting, marked by >> and CAPITALIZED. Also note that "time of day"
is misleading, since the timestamp includes both the date and time.
Steve.
-----------
From: DECWRL::"steiner@ATHENA.MIT.EDU" "21-Dec-87 1044 EST" 21-DEC-1987 10:48
To: kerberos@ATHENA.MIT.EDU
Subj: timestamps revisited
According to Steve's mail about timestamps, there are
two timestamps sent back to the client from the authentication
server: one is a copy of the client's original timestamp, sent
in the clear; the other is the Kerberos timestamp, sent back to
the client encrypted in the client's private key.
In that case, the Technical Plan is misleading. It says
... Anyone could send such a message or intercept its
response; that response, however, is usable only to the client named in
the original request, because Kerberos seals the response by
enciphering it in the private key of that client. The response contains
three parts: the ticket (which itself is further sealed in the private
key of the service), a newly-minted key for use in this client-server
session, and a copy of the timestamp that was in the original request.
I've modified it to read:
... Anyone could send such a message or intercept its
response; that response, however, is usable only to the client named in
>> the original request, because Kerberos seals PART OF the response by
>> enciphering it in the private key of that client. The SEALED PART OF THE
response contains
three parts: the ticket (which itself is further sealed in the private
key of the service), a newly-minted key for use in this client-server
session, and the TIMESTAMP according to the Kerberos server. A copy
of the client's original timestamp is returned in the clear, as a
bookkeeping aid to the client.
Jennifer
========================================================================
Received: from ATHENA.MIT.EDU by decwrl.dec.com (5.54.4/4.7.34)
id AA01776; Mon, 21 Dec 87 07:46:39 PST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16754; Mon, 21 Dec 87 10:44:54 EST
Received: by BRAHMS.MIT.EDU (5.45/4.7) id AA00364; Mon, 21 Dec 87 10:44:48 EST
Message-Id: <8712211544.AA00364@BRAHMS.MIT.EDU>
Organization: Project Athena, MIT Cambridge MA
--[0296]--
\f
[0297] daemon@TELECOM.MIT.EDU Kerberos 01/16/88 15:29 (9 lines)
Subject: accounts on atalanta
From: barba@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Everybody in krbdev should now have an account on Atalanta.
Problems to me.
John Barba
--[0297]--
\f
[0298] daemon@TELECOM.MIT.EDU Kerberos 01/23/88 18:40 (63 lines)
Subject: RFC1004
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
RCC1004 - "A Distributed-Protocol Authentication Scheme" by Mills is
of releavance to the kerberos crowd. Read kerberos server for cookie
jar and it's just about the same thing (at least the main points are,
3-party authentication, client only talks to the authent server and
then to its associate) ...
-- Jon
----------------------
The purpose of this RFC is to focus discussion on authentication
problems in the Internet and possible methods of solution. The
proposed solutions this document are not intended as standards for
the Internet at this time. Rather, it is hoped that a general
consensus will emerge as to the appropriate solution to
authentication problems, leading eventually to the adoption of
standards. Distribution of this memo is unlimited.
1. Introduction and Overview
This document suggests mediated access-control and authentication
procedures suitable for those cases when an association is to be set
up between multiple users belonging to different trust environments,
but running distributed protocols like the existing Exterior Gateway
Protocol (EGP) [2], proposed Dissimilar Gateway Protocol (DGP) [3]
and similar protocols. The proposed prcedures are evolved from those
described by Needham and Shroeder [5], but specialized to the
distributed, multiple-user model typical of these protocols.
The trust model and threat environment are identical to that used by
Kent and others [1]. An association is defined as the end-to-end
network path between two users, where the users themselves are
secured, but the path between them is not. The network may drop,
duplicate or deliver messages with errors. In addition, it is
possible that a hostile user (host or gateway) might intercept,
modify and retransmit messages. An association is similar to the
traditional connection, but without the usual connection requirements
for error-free delivery. The users of the association are sometimes
called associates.
The proposed procedures require each association to be assigned a
random session key, which is provided by an authentication server
called the Cookie Jar. The procedures are designed to permit only
those associations sanctioned by the Cookie Jar while operating over
arbitrary network topologies, including non-secured networks and
broadcast-media networks, and in the presence of hostile attackers.
However, it is not the intent of these procedures to hide the data
(except for private keys) transmitted via these networks, but only to
authenticate messages to avoid spoofing and replay attacks.
The procedures are intended for distributed systems where each user i
runs a common protocol automaton using private state variables for
each of possibly several associations simultaneously, one for each
user j. An association is initiated by interrogating the Cookie Jar
for a one-time key K(i,j), which is used to encrypt the checksum
which authenticates messages exchanged between the users. The
initiator then communicates the key to its associate as part of a
connection establishment procedure such as described in [3].
--[0298]--
\f
[0299] daemon@TELECOM.MIT.EDU Kerberos 01/23/88 21:17 (61 lines)
Subject: [desaree@venera.isi.edu: RFC1040 now Available]
From: henry@GARP.MIT.EDU (Henry Mensch)
To: kerberos@ATHENA.MIT.EDU
This might be of interest here . . .
Original-Subject: RFC1040 now Available
Original-Date: Fri, 22 Jan 88 16:22:36 PST
Original-From: Desaree Scott <desaree@venera.isi.edu>
A new Request for Comments is now available from the Network Information
Center in the online library at SRI-NIC.ARPA.
RFC 1040:
Title: Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encipherment and Authentication
Procedures
Author: J. Linn
Mailbox: Linn@CCY.BBN.COM
Pages: 29
Characters: 76276
pathname: RFC:RFC1040.TXT
This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and
of internal working papers distributed for those meetings. This memo defines
message encipherment and authentication procedures, as the initial phase of an
effort to provide privacy enhancement services for electronic mail transfer in
the Internet. Detailed key management mechanisms to support these procedures
will be defined in a subsequent RFC. As a goal of this initial phase, it is
intended that the procedures defined here be compatible with a wide range of
key management approaches, including both conventional (symmetric) and
public-key (asymmetric) approaches for encryption of data encrypting keys.
Use of conventional cryptography for message text encryption and/or integrity
check computation is anticipated.
This RFC suggest a proposed protocol for the Internet community, and requests
discussion and suggestions for improvements. Distribution of this memo is
unlimited.
Public access files may be copied from the <RFC> directory at SRI-NIC.ARPA via
FTP with username ANONYMOUS and password GUEST.
The normal method for distribution of RFCs is for interested parties to copy
the documents from the NIC online library using FTP. Requests for special
distribution should be addressed to either the author of the RFC in question
or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC
itself, all RFCs are for unlimited distribution.
Submissions for Requests for Comments should be sent to POSTEL@ISI.EDU.
Requests to be added to or deleted from this distribution list should be sent
to NIC@SRI-NIC.ARPA.
--jon.
--[0299]--
\f
[0300] daemon@TELECOM.MIT.EDU Kerberos 01/26/88 18:12 (14 lines)
Subject: authentication papers
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
I've received three papers on authentication from Karen Sollins:
1. "Authentication: A Practical Study in Belief and Action"
by Mike Burrows, Martin Abadi, and Roger Needham (DEC SRC)
2. "Block Encryption" by David Wheeler (Cambridge University)
3. "Cascaded Authentication" by Karen Sollins (LCS)
Unfortunately, they're hardcopy, but I'll make some
xeroxes. If you'd like one, send me mail.
--[0300]--
\f
[0301] daemon@TELECOM.MIT.EDU Kerberos 01/26/88 22:48 (9 lines)
Subject: Re: authentication papers
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: <steiner@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jennifer Steiner's message of Tue, 26 Jan 88 18:11:46 EST,
Reply-To: tytso@ATHENA.MIT.EDU
Could you make a copy of the three papers for me? Thanks!
- Ted
--[0301]--
\f
[0302] daemon@TELECOM.MIT.EDU Kerberos 01/27/88 18:05 (17 lines)
Subject: Authentication on remote machines
From: treese@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
This is a followup to a suggestion from Jeff and Jerry for our remaining
timesharing systems. In the orignal suggestion, we need to prompt for
a password when a user runs rlogin, so the remote timesharing machine can
get Kerberos tickets for use on that machine.
I propose that rlogin prompt for the password, and use the session key
to encrypt it to send to the remote login daemon, which can then get
tickets for the user.
Comments?
- Win
--[0302]--
\f
[0303] daemon@TELECOM.MIT.EDU Kerberos 01/27/88 19:15 (12 lines)
Subject: Re: Authentication on remote machines
From: srz@ATHENA.MIT.EDU
To: treese@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
Why not do it right, and not require the password to be typed at
all? The local machine could request tickets, which could be sent
over encrypted to the remote machine. This would require a change
to kerberos, so that one machine can request tickets that would
be good for another machine. Of course, the lifetime couldn't
exceed the lifetime of the original tickets.
-stan
--[0303]--
\f
[0304] daemon@TELECOM.MIT.EDU Kerberos 01/28/88 19:49 (37 lines)
Subject: Authentication on remote machines
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: srz@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <srz@ATHENA.MIT.EDU>'s message of Wed, 27 Jan 88 19:14:35 EST <8801280014.AA01330@CHARON.MIT.EDU>
From: <srz@ATHENA.MIT.EDU>
Date: Wed, 27 Jan 88 19:14:35 EST
Why not do it right, and not require the password to be typed at
all? The local machine could request tickets, which could be sent
over encrypted to the remote machine. This would require a change
to kerberos, so that one machine can request tickets that would
be good for another machine. Of course, the lifetime couldn't
exceed the lifetime of the original tickets.
-stan
I like Win's suggestion. I do not like this one. The problem I
see is that it would allow someone who walked up to your workstation,
to propagate a TGT for you to some other machine.
Example: User "B" is logged in to server "S".
User "A" leaves his terminal unattended for a moment.
User "B" walks up to "A"'s workstation and uses "rlogin" to
get to "S". He then copies the tkt file created on "S" to another
location and sets it to be publicly readable. He then grabs it from his
session on "S" and now is in possession of a valid TGT for host "S" for
user "A".
Win's approach does not suffer from this problem.
-Jeff
P.S. This issue has come up and been debated before. ALL: Please check
the archives of the "kerberos" mailing list for the old discussion.
--[0304]--
\f
[0305] daemon@TELECOM.MIT.EDU Kerberos 01/28/88 20:07 (20 lines)
Subject: Authentication on remote machines
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: treese@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: treese@ATHENA.MIT.EDU's message of Wed, 27 Jan 88 18:02:54 EST <8801272302.AA26210@CIROCCO.MIT.EDU>
I may be answering the worng question here, since I wasn't present for
the discussion Win is following up, but anyway... Note that whatever
mechanism you come up with for your remaining timesharing systems will
get used in other circumstances also. Especially when Kerberos gets
outside MIT. As such, the host one is connecting to will not always
be trusted, and the user might not always want to give his password.
As such, it must be possible for a user to choose not to give his
password.
Ideally, one would not have to give the remote system his password.
Instead, rlogin could obtain a new ticket granting ticket for the user
that is good from the remote address, it could then send that along with
necessary session key, encrypted, to the remote system.
~ Cliff
--[0305]--
\f
[0306] daemon@TELECOM.MIT.EDU Kerberos 01/28/88 20:11 (9 lines)
Subject: Addendum to previous message
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Thu, 28 Jan 88 17:06:22 PST <8801290106.AA16493@june.cs.washington.edu>
Even if the mechanism does not involve sending ones password to the
remote system, the user should still have the option of not even
sending a ticket granting ticket.
~ Cliff
--[0306]--
\f
[0307] daemon@TELECOM.MIT.EDU Kerberos 01/28/88 20:24 (27 lines)
Subject: Yet another addendum
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Thu, 28 Jan 88 17:06:22 PST <8801290106.AA16493@june.cs.washington.edu>
The answer to Jeff's problem is to require that the response to a
request from kerberos for a ticket with a different internet address
come back encrypted in the users secret key instead of the session
key. As such, the user would be required to type in his password
again.
I think it is important to minimize the number of machines that see
the users password. Since the user is already logged into the local
machine, we can presume that at one point, it had the password. If we
use Wins suggestion, then once the password has been decrypted on the
remote system, it has seen the password. If, howver, the password is
used and discarded on the local machine, then, even if the remote
machine has been compromised, it at most gets a ticket granting ticket
good for a finite lifetime.
Another issue that should be considered is the case of a user taking
two rlogin hops. If we tell him that it is OK to type his password to
rlogin, then when he makes the second hop, he is typing to to the
rlogin on the remote machine, and it is not encrypted on the network
between his local host and the remote host (even though it is between
the first remote host and the second).
~ Cliff
--[0307]--
\f
[0308] daemon@TELECOM.MIT.EDU Kerberos 01/28/88 20:30 (17 lines)
Subject: Re: Yet another addendum
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: bcn@JUNE.CS.WASHINGTON.EDU
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Thu, 28 Jan 88 17:22:56 PST <8801290122.AA17383@june.cs.washington.edu>
Date: Thu, 28 Jan 88 17:22:56 PST
From: bcn@june.cs.washington.edu (Clifford Neuman)
The answer to Jeff's problem is to require that the response to a
request from kerberos for a ticket with a different internet address
come back encrypted in the users secret key instead of the session
key. As such, the user would be required to type in his password
again.
I'll buy off on this one...
-Jeff
--[0308]--
\f
[0309] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 08:42 (391 lines)
Subject: [SYSTEM%CRNLNS.BITNET@CUNYVM.CUNY.EDU: distribution of sensitive software like DES]
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
The following appears to be relevant to Kerberos distributions; the
modularity of our DES library does not appear to be as critical as it
used to be.
- Bill
------- Forwarded Message
Resent-From: <security@aim.rutgers.edu>
Date: Mon, 11 Jan 88 12:01 EST
From: SYSTEM%CRNLNS.BITNET@CUNYVM.CUNY.EDU
Subject: distribution of sensitive software like DES
To: SECURITY@aim.rutgers.edu
Resent-Date: Thu, 28 Jan 88 03:07 EST
Resent-To: security-list@aim.rutgers.edu
A recent discussion of DES software distribution on one
of the Bitnet mailing lists came to a definitive resolution.
Since this seems to be security related, I thought the
readers of this list might find it interesting.
Selden Ball
system@crnlns.bitnet
--------------------------------------------
Date: Fri, 8 Jan 88 21:43:42 -0500
From: Rayan Zachariassen <rayan@ai.utoronto>
Subject: Re: DES
To: "Selden E. Ball, Jr." <SYSTEM@CRNLNS>
After you read the following article (referred to earlier by Dennis Ferguson),
hopefully the DES discussion will disappear from this list.
Date: Mon, 26 Oct 87 17:18:36 PST
From: John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
Subject: Export control does *NOT* apply to publicly available software.
To: info-futures@bu-cs.bu.edu
I researched this topic pretty thoroughly last year, by going down to the
local Federal Building and wading through the rulebooks in Commerce Dept.
library. What prompted me to do it was that I had a PD DES, that I had
posted to comp.sources.unix, which a Canadian reader claimed was in
violation of export laws.
Rich $alz took the info I got and talked with the NSA (US National
Security Agency) and some Boston-area cryptographers. The upshot was
that NSA never came up with anything that contradicted the rules I
found, and Rich posted not only the DES code, for worldwide distribution,
but also the "crypt breaker's workbench" that decrypts the ancient Unix
"crypt" command.
Now, the way things wag with NSA is that if you ask them "Can I do this?"
the answer is almost always "No". What you have to say is "Show me the rules
that say I can't do this. I have some that say I can." The courts have
regularly ruled that the government cannot enforce a policy which is not
written down and equally applied to everyone (it's called "secret law").
So if what *is* written down supports you, they are stuck with it. They
can't secretly make new laws and tell you later that you broke them.
Since everyone else on this topic is shooting off their mouth without
having done any research (now we have *two* Canadians who are falsely telling
us what the US export law is -- thanks guys!), I figured I'd better post
my full references to make it credible. Save this message; if I ever leave
the net somebody had better have a copy to shout down the clowns again.
From: gnu@hoptoad.uucp (John Gilmore)
Subject: There are basically no export controls on public domain information.
Date: 3 Oct 86 23:57:06 GMT
I got into a hassle last month for posting a DES program to mod.sources
because someone claimed that I was breaking the export control law.
I spent the afternoon down at the Federal Building and discovered that
export policy is in better shape than I thought. Basically, you can
export any technical data to any destination if it "has been made
generally available to the public in any form". This export is under
a "general license" which is available to everyone without any paperwork.
So, you should expect to see the DES posting again (it was canceled)
and to see Crypt Breaker's Workbench on mod.sources soon.
Here are the regs for all you policy hounds:
Export Administration Regulations, Part 370.2, Definitions.
"General License. A license established by the US Department
of Commerce for which no application is required and for which
no document is granted or issued. It is available for use by
all persons, except those listed in and prohibited by the
provisions of Supplement No. 1 to Part 388, and permits export
within the provisions thereof as prescribed in the Export
Administration Regulations. These general licenses are not
applicable to exports under the licensing jurisdiction of agencies
other than the Department of Commerce."
Part 379.1, Definitions.
"... All software is technical data."
Part 379.2, Licenses to Export.
"Except as provided in Part 370.3(a), an export of technical
data must be made under either a US Department of Commerce
general license or a validated export license. General
licenses GTDA and GTDR apply to specific types of exports of
technical data..."
Part 379.3, General license GTDA: Technical Data Available to all
Destinations.
"A General License designated GTDA is hereby established
authorizing the export to all destinations of technical data
described in 379.3(a), (b), or (c) below:
(a) Data Generally Available
Data that have been made generally available to the public in
any form, including--
(1) Data released orally or visually at open conferences,
lectures, trade shows, or other media open to the public; and
(2) Publications that may be purchased without restrictions
at a nominal cost, or obtained without costs, or are readily
available at libraries open to the public.
The term "nominal cost" as used in 379.3(a)(2) above, is intended
to reflect realistically only the cost of preparing and distributing
the publication and not the intrinsic value of the technical data.
If the cost is such as to prevent the technical data from being
generally available to the public, General License GTDA would not
be applicable.
(b) Scientific or Educational Data ...
(c) Patent Applications ..."
------ (end of first message)
John here, talking to info-futures again. Chris Lewis (the first
Canadian "expert") tried to pick the above to pieces, so I provided
more explanation by private mail, now revealed to the info-futures
readership for the first time ever!
Date: Sun, 12 Oct 86 16:57:06 PDT
From: gnu (John Gilmore)
Subject: Re: Export control revisited
Chris Lewis is still somewhat concerned about export control. I will
try to explain the things he mentioned in his message of 8 October.
>> "General License. A license established by the US Department
>> of Commerce for which no application is required and for which
>> no document is granted or issued. It is available for use by
>> all persons, except those listed in and prohibited by the
>> provisions of Supplement No. 1 to Part 388, and permits export
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> what is this section about?
It lists people who have abused the general license in circumstances
where it does not apply (eg shipping Vaxen to Russia). The idea is that
you are innocent until proven guilty with regards to general licenses.
I looked in the supplement and it was a 3-page list of names and cities.
I was not on it. :-)
>> within the provisions thereof as prescribed in the Export
>> Administration Regulations. These general licenses are not
>> applicable to exports under the licensing jurisdiction of agencies
>> other than the Department of Commerce."
I also got myself a copy of the regulations on cryptographic material
export, but I didn't include it in my posting since it did not apply.
It's listed under Part 399.1, supplement #1 (the Commodity Control
List), "ECCN 1527A". It mentions that computers when combined with
cryptographic software are covered under this ECCN, and says "Technical
Note: No technical data or software controlled under this ECCN may be
exported or reexported under General License GTDR." HOWEVER, we are
exporting under General License GTDA, not GTDR, and this is a valid
distinction. There is nothing in this ECCN section that precludes
shipping cryptographic technical data (e.g. software) under general
license GTDA. It also says, "Exporters requesting a VALIDATED LICENSE
from the Department of Commerce must provide a statement from the
Department of State, Office of Munitions Control, verifying that the
equipment intended for export is under the licensing jurisdiction of
the Department of Commerce." (emphasis mine) However, we are not
requesting a validated license, we are using the general license, so
this requirement does not apply either.
In summary, I believe that the provisions of ECCN 1527A do not apply to
public domain software, and we are OK. (I don't know of any other ECCN
sections that apply either.)
>> "A General License designated GTDA is hereby established
>> authorizing the export to all destinations of technical data ...
>>
>> (1) Data released orally or visually at open conferences,
>> lectures, trade shows, or other media open to the public; and
>>
>> (2) Publications that may be purchased without restrictions
>> at a nominal cost, or obtained without costs, or are readily
>> available at libraries open to the public.
> 1) Has *this* DES program been formally published before?
> 2) Can it legally be? Journals are supposed to be reviewed prior
> to publication by one of the security agencies. We're a loophole.
> 3) From another tack: can you make a DES program PD?
(1) You elided the relevent section of the general license definition.
"(a) Data Generally Available: Data the have been made generally
available to the public IN ANY FORM, including... (1) and (2)...".
(emphasis mine.) If something has been placed into the public domain
and its location advertised to the Usenet community, or placed into
a publicly accessible bulletin board, or posted to the Usenet, I claim
that it has been made generally available to the public. (1) and (2)
are not the only ways something can be made available to the public;
they are just examples.
(2) You can't be expected to know how things work in the U.S., being
Canadian, but there is NO requirement that "journals are supposed to be
reviewed prior to publication". We have a free press here. They tried
to impose something like this and it didn't work. There is a
"voluntary" system whereby authors can submit manuscripts to the NSA
for review, but you are not even bound by the result -- they can only
make suggestions. Mostly this is so they can recommend that you delete
certain phrases that might give away what they are working on, and you
are supposed to feel patriotic enough to go along. Presumably they
could also try to go to court to stop you from publishing, but I don't
think that has happened to any paper that has been voluntarily
submitted under this program. (They did go to court against the
magazine that published the "how to build an atom bomb" article.)
You may be confused between mandatory review of journals and the
Defense Department's right to review articles by people who they fund.
If you are doing government-sponsored research, they can write the
contract such that they get to OK any release of information derived
from the sponsored research. But if I invent something on my own,
without gov't money, I can publish it.
(3) Public Domain-ness is a state of ownership. Since you can
certainly own a DES program (e.g. AMD owns the copyright of the 8068
DES chip; ATT owns crypt(1)), you can also renounce its ownership and
place it into the public domain.
>You didn't include anything from 370.3 (or is that a typo?) either.
It was not a typo. I don't have a copy of it here, but I don't think
it applies to us. It's part of the "General Policy on Exports" section.
>If this program were to be published in a technical magazine (presumably
>safest in a real journal, not necessarily BYTE), then I'd feel safe
>because they've already had approval. BYTE published one or two DES programs
>ages ago, but this was before the NBS standard was formalized. Presumably
>you could publish *that* program (6502 assembler), but not anything written
>since then. I haven't seen a DES program since (though, I don't read all
>that many journals...)
This objection is covered above -- there is no required government
review of publications here, and no government approval is required to
publish.
>I realize perfectly well that a court challenge on this would probably
>find in our favor - as in, is DES in software really DES? But, I want
>to ensure that we stay well clear of the shadow (if not the substance)
>of the law.
Actually, this is not relevant. The export control regs don't mention
DES at all. They say "cryptographic equipment...designed to ensure
secrecy of communications...or of stored information...and "software"...
performing the functions of such cryptographic equipment", and then
make a few exemptions for things like simple scrambled voice, video, or
fax.
>I can't help remembering the export restrictions on crypt (which, I believe
>are still in effect *even tho* Enigma has been declassified for years),
>AT&T's security package, Motorola and Intel's encryption boards etc.
>I remember seeing discussions in trade journals 2-4 years ago about DES
>export restrictions, code-breaking discussions, other more recent encryption
>methods, but I can't remember where.
None of the above stuff is "technical data generally available to the
public", so it cannot be exported under the GTDA general license. Note
that journal articles like the AT&T Tech Journal one on breaking crypt
are generally available to the public, and they are being exported
without trouble. Ditto for _Cryptologia_. It *DOES* take an export
license to export non-public technical data, e.g. the Unix crypt
command (licensed software), encryption boards (hardware, not
technical data), etc.
I must say that I felt the same way you do about this -- I had a general
feeling that exporting this stuff was illegal, even though I thought it
should be legal -- until I spent the time to research it. My opinion of
the people who wrote US export law has gone up significantly. They
really believe that if the US "public" can get it, it is exportable.
FYI, here is the definitive story on how the "export restrictions on
crypt" came about, from Dennis Ritchie himself. As you can see, no
government agency ever said it could not be exported; AT&T and DEC
simply decided that applying for an export license was too much trouble.
I've also included a message from Gordon Moffett who says that Amdahl
is now exporting Unix with the crypt command without trouble.
From: dmr@research.UUCP
Subject: export controls
Date: 18 Sep 84 05:15:46 GMT
Posted: Mon Sep 17 22:15:46 1984
As has been said, there is indeed a special "International Edition"
of System V that differs from the ordinary system in that it
lacks the crypt command, the encrypting features of ed and vi, and the
encrypt entry of crypt (3). The crypt entry, which is used for
passwords, is there, as is the underlying DES algorithm.
Here's how it happened.
About a year ago, I got mail from Armando Stettner saying basically,
"Do you know of any problems with exporting crypt? Our lawyers
[at DEC] are worried about it." I replied that such worries were
utterly unfounded for a variety of sensible reasons.
Now, as it has turned out, DEC was very justified in worrying about
export controls in general; they have recently been fined (I think) $500,000
for the Vaxen that almost got sent to Russia. I conjecture that
the earliest stages of this or a similar incident were already in progress
and they were trying to be extra careful when they learned about crypt.
At any rate, the DEC lawyers communicated their fears to AT&T,
and the AT&T lawyers, equally cautious, sought government advice.
The problem, you see, is that cryptographic materials are under export
control. There is a thing called the Munitions Control Board that worries
not only about machine guns going to Libya, but also about the crypt
command going to England. In practice, the enforcement is done by the
Commerce department.
AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was
that they decided it would be simplest all around just not to export
the crypt command. The gov't would almost certainly have granted
the license, but (probably wisely) AT&T decided it wasn't worth
the hassle.
In technical terms, the situation is ludicrous. The encrypt subroutine
is distinguished mainly by the excruciating care I took to make it
an exact transcription of the algorithm published in the Federal Register,
and by its slowness. NBS, the caretaker of DES standardization,
is explicit that software implementations cannot be certified, so in that
sense encrypt is not "real" DES. The underlying subroutine is still
there, only the simple command that uses it is missing. So there is
actually nothing to protect, and even if there were, it's not protected.
Nevertheless, in the present situation we officially don't need
an export license, whereas with the crypt command we would.
In political terms, AT&T probably could have done better. Conservative
and careful, they called a big meeting at which no one could possibly
have put forward anything but official positions about encryption
programs. Private checking with well-placed people in the appropriate
agencies might well have done the job. But who knows?
Dennis Ritchie
-----
In article <3140@amdahl.UUCP> Gordon Moffett writes:
Our Corporate legal advisor says that the restrictions against
exporting encryption stuff has been lifted. We used to have two
UTS's: one with the crypt(3) stuff for domestic customers, and one
without export. We no longer distiguish between the two -- we now ship
everything to non-USA customers just as to the USA sites.
I've already gotten one letter about this, asking me for further
confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk
to *your* companies' legal advisors, or to the Federal Government
directly. Second, I am sure we would hear about it from the Federalees
if our Corporation were making a mistake ....
--
Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam
[Back to Chris's comments: -- gnu]
>The definitive answer would be to see whether the current listing of
>restricted items includes DES, and in what forms. I don't think excerpts
>from a different set of legislation is sufficient to answer this question.
>Further, there *may* be a difference between "legislation" and "regulation"
>here. DES restriction might *not* be enshrined in legislation, but come
>out of some other department's regulatory powers. The second paragraph
>I've quoted still leaves that whole question open.
I have spent the time researching it, and I think it's OK to export.
If you still think differently, please give details of the regulations
or laws involved. I'm not interested in "maybes"; I have an answer
that came straight from the rule books, and won't be swayed from it
by anything less definitive.
------- End Forwarded Message
--[0309]--
\f
[0310] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 11:36 (21 lines)
Subject: Re: Yet another addendum
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: bcn@june.cs.washington.edu
Cc: treese@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Thu, 28 Jan 88 17:22:56 PST,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Thu, 28 Jan 88 17:22:56 PST
From: bcn@june.cs.washington.edu (Clifford Neuman)
The answer to Jeff's problem is to require that the response to a
request from kerberos for a ticket with a different internet address
come back encrypted in the users secret key instead of the session
key. As such, the user would be required to type in his password
again.
Instead of doing that, why not modify Kerberos so that you can ask for a
Ticket Granting Ticket for any arbitrary internet address? Or is that
what you're suggesting already? (Your mention of "instead of the
session key" leads me to assume that that's not what you intended.)
- Ted
--[0310]--
\f
[0311] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 13:37 (27 lines)
Subject: rlogin
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
As Cliff pointed out, if multi-hop rlogins occur, none of the solutions
that require typing in a password are secure, since rlogin sessions are
not encrypted for privacy.
I believe that once you have authenticated yourself the first time on your
local system, you should be able to navigate throughout the network, given
the appropriate authorizations, without having to type the password again
anywhere. (Assume that the tgt doesnt't expire.) If you make it a rule
that the password is NEVER entered again, you minimize the exposure on the
wire or in another system.
Whenever you walk away from your system, anyone else can capture it
and "be" you for whatever intent they wish. I am not convinced that this
is particularly different in terms of security for the different scenarios
suggested -- the original tgt is still available. (Unless you start tying
authorizations to the source address in addition to the kerberos name.)
Some of the alternatives may make it simpler to do more damage, so it might
be worth considering.
I would go with along with what Cliff and Stan suggested, but probably not
with having the user type in their password again. It loses big in the
multi-hop case, and buys little otherwise.
Steve.
--[0311]--
\f
[0312] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 15:57 (15 lines)
Subject: Re: [SYSTEM%CRNLNS.BITNET@CUNYVM.CUNY.EDU: distribution of sensitive software like DES]
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Fri, 29 Jan 88 08:40:42 -0500.
From: Win Treese <treese@ATHENA.MIT.EDU>
> The following appears to be relevant to Kerberos distributions; the
> modularity of our DES library does not appear to be as critical as it
> used to be.
> - Bill
This material has already been turned over to Bill Hogue for evaluation.
- Win
--[0312]--
\f
[0313] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 16:53 (30 lines)
Subject: rlogin
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: Theodore Ts'o's message of Fri, 29 Jan 88 11:32:39 EST <8801291632.AA22179@THOR.MIT.EDU>
If I recall correctly, there is a field in the ticket for privileges
(flags). I don't think this field has ever been used though. How
about using one of these bits in the ticket granting ticket to
indicate that one can use it to obtain a new ticket granting ticket
for a new address. When a request is received for a new ticket
granting ticket at a different IP address, the ticket granting server
uses the bit in the existing ticket granting ticket to decide whether
to return the response encrypted in the users key or the session key.
As to how to decide what type of ticket to initially issue a user, one
can base it on who the user is, recording the default in the same
manner one could choose a default ticket lifetime. Alternatively, the
default could be decided by the local machine. If it is a public
workstation, one might be more careful, than if it is the users
personal machine. As for the possibilty of someone changing the
software on a public workstation to get the other type of ticket, if
they do this, they might as well have it record the password.
Finally, there should be a way for the user to overide the default
when logging in, and as already mentioned, when rloggin in.
The final question is what type of ticket granting ticket should be
issued based on an existing ticket granting ticket. I propose the
same type (unless the user chooses to overide the default). I can see
arguments both ways though.
~ Cliff
--[0313]--
\f
[0314] daemon@TELECOM.MIT.EDU Kerberos 01/29/88 17:25 (9 lines)
Subject: Re: flags and rlogin
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Careful with the flags. At least one bit IS used to indicate byte ordering
(create_ticket.c, decomp_ticket.c).
This is becoming incredibly arcane...
Steve
--[0314]--
\f
[0315] daemon@TELECOM.MIT.EDU Kerberos 01/30/88 12:00 (32 lines)
Subject: re: Yet another addendum
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: bcn@june.cs.washington.edu (Clifford Neuman)'s message of Thu, 28 Jan 88 17:22:56 PST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> The answer to Jeff's problem is to require that the response to a
> request from kerberos for a ticket with a different internet address
> come back encrypted in the users secret key instead of the session
> key. As such, the user would be required to type in his password
> again.
That proposal smells almost right for the case when you WANT the user
to type a password as part of moving to a new environment. The only
problem I see is that if while logged in at A you rlogin to B, then
from B you rlogin to C, you still end up sending your password over
the net from A to B. The user could able avoid this exposure by
always doing rlogins directly from A, but it requires some
indoctrination to realize why it is worth the bother.
However, I find very appealing Steve's argument that, once
identified, you should be able to navigate without exposing your
password at all, even to the local workstation. I suspect it is
easier for a user to understand (and protect against) the exposure in
leaving a workstation unattended than the exposure in doing rlogin
from a to b to c.
I think this is a fairly tough call, trading off subtle objectives.
The discussion about flags leaves me cold. Noone will ever
understand how to set them to get the right result.
Jerry
--[0315]--
\f
[0316] daemon@TELECOM.MIT.EDU Kerberos 01/30/88 13:32 (21 lines)
Subject: Yet another addendum
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sat, 30 Jan 88 11:57:00 EST <8801301657.AA14743@HERACLES.MIT.EDU>
The way flags get set can be analagous to the way the ticket lifetime is
set. Users can select a default. Those that want to overide the
default can then use a special option to rlogin or login. Most people
would have no need to do this, however.
The above combined with the ability for the user to optionally select
the lifetime of the ticket to be sent to the remote host will allow
just the amount of trust that is needed to be placed in that host.
The exact same mechanism could be used for proxies where either the
local application knows exactly what services will be accessed by a
remote service, or where it is willing to entrust the remote system
with a short lived and not further propogatable ticket granting
ticket.
~ Cliff
--[0316]--
\f
[0317] daemon@TELECOM.MIT.EDU Kerberos 01/30/88 17:51 (48 lines)
Subject: Draft of Visa paper
To: kerberos@ATHENA.MIT.EDU
From: Win Treese <treese@ATHENA.MIT.EDU>
...is now available. LaTeX source and a PostScript file are in
/mit/treese/Doc/draft_vis.{tex,PS}. I also printed one out if anyone
wants to photocopy (you get double-sided that way).
Note that it is still a draft, and it shows. The edges are still a little
rough.
- Win
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07612; Sat, 30 Jan 88 15:31:50 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA25362; Sat, 30 Jan 88 15:31:27 EST
Received: by CIROCCO.MIT.EDU (5.45/4.7) id AA14401; Sat, 30 Jan 88 15:27:38 EST
Path: bloom-beacon!mit-eddie!ll-xn!ames!pasteur!ucbvax!rt234.usc.EDU!estrin
From: estrin@rt234.usc.EDU (Deborah L. Estrin)
Newsgroups: comp.protocols.tcp-ip
Subject: Visa paper draft Finally available
Message-Id: <8801271816.AA00480@rt234.usc.edu>
Date: 27 Jan 88 18:16:17 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 16
Apparently-To: treese
A DRAFT of the visa protocol paper mentioned long ago is now ready for
limited distribution.
Those of you who requested copies via usmail will receive
them shortly. Those who requested copies via email, are asked
to ftp it over to save the mail systems. If this is not possible
for you let me know and i will send email or usmail.
The draft isavailable by anonymous ftp on oberon.usc.edu in pub/draft_visa.tex
It is still a Draft so we recommend that you only look at it if
you are seriously interested in providing us with some feedback
with the understanding that it is not finished and is not intended for broad
distribution.
thank you, Deborah Estrin (and co-authors Jeff Mogul of Digital and
Gene Tsudik of USC)
------- End of Forwarded Message
--[0317]--
\f
[0318] daemon@TELECOM.MIT.EDU Kerberos 02/19/88 12:07 (312 lines)
Subject: DEC's lawyers on DES
To: kerberos@ATHENA.MIT.EDU, tony@ATHENA.MIT.EDU, champine@ATHENA.MIT.EDU,
From: Win Treese <treese@ATHENA.MIT.EDU>
Posted to the net; it seems to be relevant.
- Win
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA10621; Fri, 19 Feb 88 00:47:20 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14352; Fri, 19 Feb 88 00:46:18 EST
Received: by CIROCCO.MIT.EDU (5.45/4.7) id AA24282; Fri, 19 Feb 88 00:45:03 EST
Path: bloom-beacon!husc6!bbn!uwmcsd1!ig!agate!ucbvax!DECWRL.DEC.COM!kent
From: kent@DECWRL.DEC.COM
Newsgroups: comp.society.futures
Subject: Re: distribution of sensitive software like DES
Message-Id: <8802162241.AA16997@armagnac.DEC.COM>
Date: 16 Feb 88 22:41:07 GMT
References: <8801281211.AA13780@decwrl.dec.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 284
Apparently-To: treese
This is a memo prepared by Digital's lawyers in response to John
Gilmore's note of last October. Please note that I am only passing this
along, without comment -- I know little if anything about the law, and
am not in the least interested in engaging in debate about this issue,
nor am I willing to pass such debate back to the lawyers piecemeal.
chris
- --------Begin Forwarded Message
From: ehrgood@wnpv01.enet (TOM EHRGOOD, WNP, DTN 427-5698)
To: @cryptomemo.dis, ehrgood
Subject: Crypto Export Controls - Answer To Gilmore
_____________________________
| | | | | | | |
| d | i | g | i | t | a | l | I n t e r o f f i c e M e m o
|___|___|___|___|___|___|___|
TO: "TO" Distribution DATE: 16 February 1988
FROM: Tom Ehrgood
CC: "CC" Distribution DEPT: Corporate Law
TEL: (202) 383-5698
LOC: WNP
SUBJECT: Controls Over The Export Of Cryptographic Software
This memo answers points made in an October 27, 1987, memo by John
Gilmore, which we received on January 28th. Gilmore's memo, which I am
separately forwarding, argues that the posting of cryptographic software
to certain widely available bulletin boards places that software in the
"public domain," with the consequence that export licenses are not
required for the exports of that software. Gilmore's analysis has been
given wide distribution on various networks.
Gilmore is mistaken in his analysis and in his conclusion. Given the
high national security sensitivity of cryptography, generally, and DES
encryption, specifically, it is important to set the record straight.
The fundamental points that Gilmore gets wrong are:
o Exports of cryptographic software are governed by the State
Department's International Traffic in Arms Regulations ("ITAR"),
not by the Commerce Department's Export Administration
Regulations ("EAR"). Exports would be governed by Commerce's
EAR only if State waived jurisdiction.
o Although State Department regulations contain a "public domain"
exemption for technical data, cryptographic software does
not qualify as "technical data," and thus the "public domain"
exemption does not apply.
A legal analysis follows.
\f
DISCUSSION
I. State Department Control Over Cryptographic Software
----------------------------------------------------
A. Cryptographic software is a "defense article"
---------------------------------------------
Section 38 of the Arms Export Control Act authorizes the President to
control the export and import of "defense articles" and "defense
services." This statutory authority -- which includes the authority to
to "designate those items which shall be considered as defense articles
and defense services" -- was delegated to the Department of
State, which in turn has implemented the statutory authority through
promulgation of the International Traffic in Arms Regulations ("ITAR"),
22 C.F.R. Subch. M.
The term "defense article" is defined in section 120.7 of ITAR to mean
"any item designated in section 121.1," which contains the United States
Munitions List.
Category XIII of the Munitions List provides in paragraph (b) as
follows:
Speech scramblers, privacy devices, CRYPTOGRAPHIC DEVICES AND
SOFTWARE (ENCODING AND DECODING), and components specifically
designed or modified therefore, ancillary equipment, and protective
apparatus specifically designed or modified for such devices,
components, and equipment. (Emphasis added.)
Since "cryptographic . . . software" is thus included on the United
States Munitions List, it is a "defense article" subject to the State
Department's ITAR controls over exports of such articles.
At certain low thresholds, it may not be clear whether software
containing certain encryption functionality in a technical sense
constitutes "cryptographic software" within the meaning of Category
XIII(b), above. Section 120.5 of ITAR establishes a procedure under
which "[t]he Office of Munitions Control will provide, upon written
request, a determination on whether a particular article is included on
the United States Munitions List." Questionable cases may be resolved
by following this procedure.
Assuming that encryption software does constitute "cryptographic
software" within the meaning of Category XIII(b), State Department
export licenses are required, REGARDLESS OF WHETHER THE ENCRYPTION IS
BASED ON THE DES ALGORITHM. The relevance of DES vs. non-DES lies in
the ease with which licenses can be obtained, not in whether licenses
are required.
B. The State Department's "public domain" exemption does not
apply to exports of "defense articles."
---------------------------------------------------------
Part 123 of ITAR contains rules governing export licenses for the export
of "defense articles." The basic rule is stated in Section 123.1(a) as
follows:
Any person who intends to export a defense article must obtain a
license from the Office of Munitions Control prior to the export
unless the export qualifies for an exemption under the provisions
of this Subchapter.
Part 123 sets forth a number of exemptions in sections 123.16 through
123.22. None is these exemptions covers the posting of cryptographic
software on a bulletin board.
Section 126.5 exempts from the licensing requirement any exports of
unclassified defense articles or unclassified technical data to Canada
for end-use in Canada or return to the United States. This exemption
would be potentially applicable only if the ONLY exports that might take
place as a result of the bulletin board posting were exports to Canada.
(See section 120.10, which defines "export" to include "[s]ending or
taking defense articles outside the United States in any manner.") In
any event, care would have to be taken to ensure that applicable
documentation requirements are met to invoke properly the exemption.
Part 125 of ITAR contains rules governing exports of technical data.
Section 125.1(a) provides:
The export controls of this part apply to the export of technical
data . . . . Information which is in the "public domain" (see
section 120.18) is not subject to the controls of this chapter.
Section 120.18 defines "public domain" as follows:
"Public domain" means information which is published AND WHICH
IS GENERALLY ACCESSIBLE TO THE PUBLIC:
(a) Through sales at newstands and bookstores;
(b) Through subscriptions which are available without restriction
to any individual who desires to obtain or purchase the published
information;
(c) Through second class mailing privileges granted by the U.S.
Government; or,
(d) At liberaries open to the public.
(Emphasis added.) This definition is a much more restrictive one than
the analogous Commerce GTDA regulation analyzed by Gilmore: a bulletin
board posting of information would not fall within ITAR's public domain
unless that posting qualified under paragraphs (a)-(d) of section
120.18. A posting would not appear to so qualify. (This memo does not
take any position on whether bulletin board posting would place
Commerce-controlled technical data into Commerce's public domain;
specific information about the technical data and the bulletin board
would be necessary.)
Regardless of how the ITAR "public domain" applies to bulletin board
postings in general, the posting of cryptographic software cannot fall
within the "public domain" provision, because, per section 125.1(a)
above, the "public domain" provision applies to "technical data."
Cryptographic software -- a "defense article" (see Section I.A above) --
does not constitute "technical data" under ITAR. More on that below.
The term "technical data" is defined in section 120.21 as follows:
"Technical data" means for purposes of this subchapter:
(a) Classified information relating to defense articles and
defense services;
(b) Information covered by an invention secrecy order;
(c) Information which is directly related to the design,
engineering, development, production, processing, manufacture,
use, operation, overhaul, repair, maintenance, modification, or
reconstruction of defense articles. This includes, for example,
information in the form of blueprints, drawings, photographs,
plans, instructions, computer software and documentation. This
also includes information which advances that state of the art of
articles on the U.S. Munitions List. This does not include
information concerning general scientific, mathematical or
engineering principles.
"Technical data" per this definition thus consists either of
information "relating to defense articles" (par. (a)) or information
directly related to the doing of things to "defense articles" (par. (c)).
[Paragraph (c) is not relevant here.] Since cryptographic software is
itself a "defense article," it cannot simultaneously qualify as
"technical data." Moreover, different ITAR Parts govern exports of
"defense articles" (Part 123) and exports of "technical data" (Part
125).
Of course, not all encryption materials (DES or otherwise) necessarily
take the form of "cryptographic software" controlled under Category
XIII(b) of the Munitions List. Non-Category XIII(b) materials will
qualify as "technical data" within the meaning of the section 120.21 and
will thus be eligible for "public domain" treatment if the specific ITAR
conditions apply.
II. Commerce Department Controls Over Cryptographic Software
--------------------------------------------------------
Section 370.10 of Commerce's Export Administration Regulations state the
general rule that Commerce does not control exports of State
Department-controlled items. Specifically, subsection (a) provides:
(a) U.S. Munitions List. Regulations administered by the Office of
Munitions Control, U.S. Department of State, Washington, D.C. 20520,
govern the export of defense articles and defense services on the U.S.
Munitions List.
Thus, Gilmore's statement that the State Department's concerns about
exports of crypt commands are "enforced" by Commerce is wrong.
What has complicated the picture and confused Gilmore is that Commerce's
Commodity Control List -- Commerce's counterpart to the United States
Munitions List -- contains a category 1527A covering "cryptographic
equipment . . . and software controlling or performing the function of
such cryptographic equipment." Gilmore identified this regulatory control
provision, but he misinterpreted it.
Gilmore found the note in category 1527A, which states that
Exporters requesting a validated license from the Department of
Commerce must provide a statement from the Department of State,
Office of Munitions Control, verifying that the equipment
intended for export is under the licensing jurisdiction of the
Department of Commerce.
Gilmore mistakingly says, however, that "we are not requesting a
validated license, we are using the general license, so this requirement
does not apply . . . ." Gilmore missed the 1527A heading: "Validated
License Required: Country Groups QSTVWYZ." These designated country
groups comprise every country in the world except Canada. Consequently,
a validated license issued by Commerce is required in order to make any
export of 1527A-controlled cryptographic software. And because a
validated license is required, exporters seeking such a license must,
per the note quoted above, submit a State Department statement
"verifying" that Commerce has jurisidiction over that cryptographic
software. Such a statement would generally take the form of an ITAR
section 120.5 commodity jurisdication determination.
In sum, unless the State Department has issued a statement verifying
Commerce jurisdiction over the cryptographic software that Gilmore has
in mind, Commerce's controls do not apply. And without such a
statement, Gilmore's analysis of section 379.3 of EAR (General License
GTDA) is completely irrelevant.
III. Conclusions
-----------
Gilmore's conclusion that the posting of cryptographic software to a
bulletin board places it in the public domain and thus exempts it from
export licensing controls is flat-out wrong. U.S. law is clear: in
order to export "cryptographic software" within the meaning of
Category XIII(b) of the United States Munitions List to any country
other than Canada, a State Department export license is required.
If there is any reason to believe or suspect that a non-U.S. or
non-Canadian national will gain access to that bulletin board, an export
to a third country should be assumed and a license is required..
If there is any question whether specific encryption software
constitutes "cryptographic software" within the meaning of
Category XIII(b), clarification can be obtained under procedures
established pursuant to section 120.5 of ITAR.
A determination from State under 120.5 that it does not have
jurisdiction is the prerequisite to bringing the control question into
Commerce's export regulations.
IT IS IMPERATIVE THAT NO DIGITAL EMPLOYEE ACT IN RELIANCE ON GILMORE'S
ANALYSIS OR HIS CONCLUSIONS.
- --------End Forwarded Message
------- End of Forwarded Message
--[0318]--
\f
[0319] daemon@TELECOM.MIT.EDU Kerberos 02/19/88 13:14 (51 lines)
Subject: re: DEC's lawyers on DES
To: kerberos@ATHENA.MIT.EDU
Cc: tony@ATHENA.MIT.EDU, champine@ATHENA.MIT.EDU, wfhogue@ATHENA.MIT.EDU,
Cc: rivest@LCS.MIT.EDU
In-Reply-To: Win Treese <treese@ATHENA.MIT.EDU>'s message of Fri, 19 Feb 88 12:04:12 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Posted to the net; it seems to be relevant.
It certainly is. I was expecting that this is where the issue of DES
exportability would come out, and I'm happy to see that someone has
analyzed the issue with some clarity. We may see some more debate on
the net, but I suspect that the conclusion isn't going to change.
My interpretation of what it all means for Kerberos is as follows:
1. We should segregate and label the DES library from the rest of
Kerberos; it is clearly subject to export licensing.
2. We should create a non-cryptographic replacement for the DES
library (the present DES-NOOP might qualify, though its name is
misleadingly wrong; if we can convince ourselves that a single XOR
with an unchanging 56-bit key isn't a cryptographic transformation
then that might be more suitable.)
3. We can't place the real DES library with the rest of M.I.T.'s
copyrighted sources in a publicly accessible locker on Zeus; we
should keep it protected on Paris, probably with the same level of
access as for BSD sources.
4. When we ship Kerberos tapes that include the DES library, we need
to insure that
a. they are going to someone inside the U.S.
b. they contain a clear notice of export control.
5. It appears that it may be necessary for M.I.T. to request an ITAR
120.5 determination as to whether the authentication parts of
Kerberos require export license. Since they are not in themselves
cryptographic in any way--they just depend on cryptographic elements
for their operation to be secure--, the M.I.T. lawyers ought to study
this question and the regulations carefully with the goal of
convincing themselves that we don't have to ask. Unfortunately,
until this step is completed, we may need to regard all of Kerberos
as non-exportable.
Bill Hogue: could you please start on step 5?
I invite anyone interested to propose an alternate interpretation of
any of this stuff. My interpretation leads to a lot more hassle than
I like.
Jerry
--[0319]--
\f
[0320] daemon@TELECOM.MIT.EDU Kerberos 02/19/88 17:07 (54 lines)
Subject: Legal hassles.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
The only flaw that I can see is their comments about whether or not
publication on Usenet counts as being put in the public domain.
I would argue that it is; I don't think that this impacts the overall
decision though.
>Section 120.18 defines "public domain" as follows:
>
> "Public domain" means information which is published AND WHICH
> IS GENERALLY ACCESSIBLE TO THE PUBLIC:
> (a) Through sales at newstands and bookstores;
> (b) Through subscriptions which are available without restriction
> to any individual who desires to obtain or purchase the published
> information;
> (c) Through second class mailing privileges granted by the U.S.
> Government; or,
> (d) At liberaries open to the public.
>
>(Emphasis added.) This definition is a much more restrictive one than
>the analogous Commerce GTDA regulation analyzed by Gilmore: a bulletin
>board posting of information would not fall within ITAR's public domain
>unless that posting qualified under paragraphs (a)-(d) of section
>120.18. A posting would not appear to so qualify. (This memo does not
>take any position on whether bulletin board posting would place
>Commerce-controlled technical data into Commerce's public domain;
>specific information about the technical data and the bulletin board
>would be necessary.)
I think that category (b) holds here (note there is no limit to
subscription costs here).
There are several public-access timesharing systems which provide
USENET access; anyone who can afford a terminal and modem can
presumably subscribe to one of these for a fee.
Also, the USENIX association sells newsfeed access to the USENET
(through uunet.uu.net); anyone who wants to buy into this (and can
afford the phone bill.) presumably can. Uunet also has a stash of
software which has been anonymously FTP'ed from various sites on the
arpanet, so that non-arpa sites can pick up a lot of public domain
stuff as well.
- Bill
--[0320]--
\f
[0321] daemon@TELECOM.MIT.EDU Kerberos 02/22/88 00:02 (34 lines)
Subject: re: Legal hassles.
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>'s message of Fri, 19 Feb 88 17:06:38 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> The only flaw that I can see is their comments about whether or not
> publication on Usenet counts as being put in the public domain.
> > (b) Through subscriptions which are available without restriction
> > to any individual who desires to obtain or purchase the published
> > information;
> I think that category (b) holds here (note there is no limit to
> subscription costs here).
1. That interpretation is certainly the obvious one from the point
of view of anyone familiar with how access to Usenet postings works
in practice. But the question may rest on some obscure
interpretation of "published" which may apply only to paper copies or
things that libraries know how to store, or something. If someone
out there does offer paper copies of Usenet postings to anyone
willing to pay for them, then it would be clear that the papers
copies are public domain. Lacking that, a test case leading to an
argument before a judge might be required to settle the question.
2. It isn't really a flaw in their argument because they go on to
argue (fairly convincingly) that the clauses that exempt public
domain stuff from export licensing don't apply to munitions and
crypto.
(Where that leaves the people who have posted crypto things to Usenet
isn't clear. The only thing that is clear is that the law can't work
as intended; its main effect is to create hassles.)
Jerry
--[0321]--
\f
[0322] daemon@TELECOM.MIT.EDU Kerberos 02/22/88 21:34 (28 lines)
Subject: storage of keys in the database and byte order
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
I've discovered a nasty little gotcha in trying to set up a slave
Kerberos running on an RT. It turns out that when keys stored in the
database are stored encytped in the master key, which is all well and
good, however the initial vector passed into pcbc_encypt is the key
schedule (well, the first 64 bits of it anyway) *which is byte-order
dependent*. This means that the internal formats of
the database are different on different byte order architectures and
you cannot go back and forth.
All other uses of pcbc_encypt in the krb library use the key itself as
the initial vector.
Is there a reason for this difference?
Is now the time to change the database touching programs to use the
key as the initial vector? (I'm volunteering to do it.) I count the
following programs as needing two or three lines of changes (as well
as a conversion program for the existing databases) ... kerberos.c,
kerberos_slave.c, admin_server.c, kdb_init.c, kdb_edit.c,
ext_srvtab.c, kstash.c. Any others?
I think this is important.
-- Jon
--[0322]--
\f
[0323] daemon@TELECOM.MIT.EDU Kerberos 02/23/88 11:16 (16 lines)
Subject: re: storage of keys in the database and byte order
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jon Rochlis <jon@ATHENA.MIT.EDU>'s message of Mon, 22 Feb 88 21:33:19 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Is now the time to change the database touching programs to use the
> key as the initial vector? (I'm volunteering to do it.) I count the
> following programs as needing two or three lines of changes (as well
> as a conversion program for the existing databases) ... kerberos.c,
> kerberos_slave.c, admin_server.c, kdb_init.c, kdb_edit.c,
> ext_srvtab.c, kstash.c. Any others?
Is another approach to change those same programs to set up the key
schedule differently depending on the byte order?
Jerry
--[0323]--
\f
[0324] daemon@TELECOM.MIT.EDU Kerberos 02/23/88 11:24 (16 lines)
Subject: Re: Storage of keys in the database and byte order
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
If my memory serves me correctly, the reason I did that was to minimize
the exposure of the master key. It only needs to be exposed once, to
convert into the key schedule, then can be cleared. I don't recall from
the DES algorithm whether the key schedule is uniquely invertible to the
key, but even if it is, it is considerably more work than snatching the key.
I would suggest as an alternative that when the server is initialized use
the master key to ECB encrypt a constant (roughly half the bits 1s, not a zero
constant) once you have the schedule, then use the encrypted constant for
the IV. That way, the master key can be cleared, and can not be recovered
from the one-way encrypted IV.
Steve
--[0324]--
\f
[0325] daemon@TELECOM.MIT.EDU Kerberos 02/23/88 11:29 (15 lines)
Subject: More re storage of keys in the database...
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Re Jerry's comments, I would strongly recommend against mucking with the
byte order of the key schedule. I spent much more time fighting with byte
order to get the correct answers than I did on the basic algorithm or making
it go reasonably fast.
If someone is looking for a significant project, the DES library could be
rewritten, starting on a BigEndian machine (instead of a VAX) to make it
cleaner and more readable. Since the DES algorithm is written in BigEndian
order, it was a major hassle doing it on the VAX and then being able to
get it to also work on the BigEndian RT PC.
Steve
--[0325]--
\f
[0326] daemon@TELECOM.MIT.EDU Kerberos 02/23/88 11:39 (9 lines)
Subject: DES NOOP
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In the recent notes about exporting the DES library, there was mention
of the DES NOOP library. Unfortunately, when I left this many moons ago
I don't think it entirely worked, so someone will have to look at it
carefully.
Steve.
--[0326]--
\f
[0327] daemon@TELECOM.MIT.EDU Kerberos 02/23/88 21:42 (16 lines)
Subject: Re: Storage of keys in the database and byte order
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: Steve Miller's message of 23 Feb 88 11:17,
I don't recall from
the DES algorithm whether the key schedule is uniquely invertible to the
key, but even if it is, it is considerably more work than snatching the key.
But if you have the key schedule you don't need the key at all! (Jeff
thought of this right off the bat.) pcbc_encrypt doesn't even take the
key as an argument, it only takes the key schedule. So I don't think
the protecting the master key argument flies ...
-- Jon
--[0327]--
\f
[0328] daemon@TELECOM.MIT.EDU Kerberos 02/24/88 04:21 (14 lines)
Subject: key <-> key schedule.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
From examining the key schedule algorithm, it appears to be relatively
trivial to invert; each of the 16 iterations through the DES algorithm
through just uses a different 48 bit subset of the 56 bit key. To
recreate the key from the key schedule is just a matter of going
through the key schedule putting the bits back where they came from,
followed by recreating the parity bits (which are not used by the
encryption algorithm).
- Bill
--[0328]--
\f
[0329] daemon@TELECOM.MIT.EDU Kerberos 02/24/88 10:45 (14 lines)
Subject: Re: re: Storage of keys...
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Right, Jon and Jeff, though it is a bit more work. I can't remember any
other reason to use the key schedule instead of the key. In the long term,
if the use of DES ever migrates towards hardware, I think you are better off
assuming you can't read the key or key schedule, and using a one-way
encrypted constant. Then the key and key schedule arguments just become
handles that point to something within the confines of the DES hardware.
But for now I think the key is ok for the IV, provided you convert the
database!
Steve
--[0329]--
\f
[0330] daemon@TELECOM.MIT.EDU Kerberos 03/09/88 13:49 (44 lines)
Subject: ticket/authenticator terminology
To: kerberos@ATHENA.MIT.EDU, spm@ATHENA.MIT.EDU, bcn@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Bill Bryant just pointed out that there is a terminology problem in
the documents describing Kerberos, in which there are three kinds of
physical objects being discussed but only two labels for them; the
documentation and the code are inconsistent in the way they apply the
labels. This inquiry is to see if there are strong opinions one way
or another as to which way we should resolve the inconsistency.
The three physical objects are:
Thing #1. The thing that Kerberos sends to a client, almost
always called a "ticket".
Thing #2. The thing that a client adds to a ticket to
inhibit replay, called an "authenticator" in the Technical Plan,
not specifically labeled in the code and accompanying comments.
Thing #3. The thing that a client sends to a server, consisting
of a Thing #1 and a Thing #2. Thing #3 is variously called a
"ticket" (in the Technical Plan) and an "authenticator" (in the
code and some manual pages.)
On the one hand. . .
The Technical Plan pattern of using the term "ticket" to describe
both Thing #1 and Thing #3 supports the common usage "you have to
present a ticket to the server to prove your identity." Describing
the extra field created by the client as an "authenticator" is
consistent with usual terminology in the cryptographic/authentication
field. It is also consistent with first-cut, simplified descriptions
of Kerberos that omit mention of the replay-prevention machinery, in
which case there are only "tickets" to discuss.
On the other hand. . .
The pattern of labeling Thing #3 the "authenticator" seems to be
fairly deeply embedded in variable names, comments in the code, and
some manual pages.
I'm inclined to suggest for new documentation the usage in the
Technical Plan, and to change the manual pages to conform. Does
anyone else have an opinion?
Jerry
--[0330]--
\f
[0331] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 15:16 (18 lines)
Subject: Re: Terminology
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
I suppose that the only clean solution would be to come up with three
entirely new terms, and fix everything. But that might be prohibitive,
and cause excessive shock.
Off the top of my head, I can't think of quite the right metaphor to fit
these three pieces. "Ticket", in sense #1, is a bit of a misnomer, since
it is reusable, which real "tickets" for a plane or game, etc., are not.
"Ticket" in sense #3 is more accurate, but still misleading because "ticket"
suggests authorization as well.
So I would just as soon stay with Jerry's suggestion, with the possible
addition of a qualifier on the #1 type ticket, if someone thinks of a good
one, such as "raw ticket", "half ticket", etc.
Steve
--[0331]--
\f
[0332] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 17:14 (18 lines)
Subject: Re: Terminology
To: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: miller%erlang.DEC@decwrl.dec.com (Steve Miller)'s message of 14 Mar 88 14:14
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> So I would just as soon stay with Jerry's suggestion, with the possible
> addition of a qualifier on the #1 type ticket, if someone thinks of a good
> one, such as "raw ticket", "half ticket", etc.
When things get thick enough that it is important to make the
distinction, we could refer to thing #1 (the thing that comes back
from Kerberos) as an "unvalidated ticket", while the thing that goes
to the service is a "validated ticket". (To be completely consistent
one could also rename thing #2 from "authenticator" to "validator",
but I think that step isn't necessary. We simply can say that the
authenticator acts to validate the ticket.)
Jerry
--[0332]--
\f
[0333] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 17:55 (22 lines)
Subject: Terminology
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: Saltzer@ATHENA.MIT.EDU
Cc: miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Mon, 14 Mar 88 17:12:13 EST <8803142212.AA22021@HERACLES.MIT.EDU>
I like the term validator. How about the following:
Ticket: What the client gets back from kerberos. (Thing #1)
Validator: What the client sends to the client along with the
ticket. (Thing #2)
Authenticator: The ticket plus the validator.
I would strongly discourage anyone from changing the meaning or name
of "ticket". Ticket has always been used to describe what the client
got back from kerberos, and nothing else. The only term that has been
confused is authenticator which has been used to mean both the
validator, and the ticket plus the validator.
~ Cliff
--[0333]--
\f
[0334] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 18:03 (10 lines)
Subject: Terminology
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: Saltzer@ATHENA.MIT.EDU
Cc: miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Mon, 14 Mar 88 17:12:13 EST <8803142212.AA22021@HERACLES.MIT.EDU>
The other thing to consider is that in the Usenix paper, thing #2 was
refered to as an authenticator, and naming the combination of thing #2
and the ticket was was specifically avoided.
~ Cliff
--[0334]--
\f
[0335] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 18:45 (51 lines)
Subject: Re: Terminology
From: steiner@ATHENA.MIT.EDU
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Mon, 14 Mar 88 17:12:13 -0500.
Thing #1 (ticket without authenticator) is like a T pass or a
museum card. It says a certain person can use a certain service
for a certain period of time.
In practice, I can loan my museum card to my housemate, so in
order to make sure the museum card is being used by the right
person, the person's identity has to be verified. In real life,
that could be done using a photo ID or a signature. In Kerberos
it's done using Thing #2 (the authenticator).
Calling Thing #1 the ticket and Thing #2 the authenticator seems
okay, although as Steve says, usually real-life tickets can only
be used once.
The problem was that Thing #3 (authenticator + ticket) was also
called an "authenticator" in the code, which is bad.
I like Jerry's proposal of calling Thing #3 the same as what
you call Thing #1, when speaking loosely, but having a more
specific term when necessary. I also like the idea of having
the specific term being an adjective in front of "ticket". But
why "valid", why not "authenticated"?
(If you call Thing #3 a "validated ticket", then what's a
Thing #3 in which the identity in the authenticator and the
identity in the ticket don't match? An "invalid validated ticket"?
Besides, the ticket in and of itself is a perfectly valid thing;
it's its use that's either valid or invalid. A Thing #3 can only be
validated based on whether the authenticator and ticket match, like
getting a signed check validated in the grocery store.)
Either way, the problem of Thing #3 being referred to as an
"authenticator" in the code would still have to be fixed. Modified
nouns don't work very well in code (e.g., "authtkt" or "valtkt");
a new noun would be nicer. But there's no name for it in real life
either; what do you call combinations of airline ticket/passport,
or museum card/photo ID, or signed check/grocery ID? "Credentials"
might work, but unfortunately, it's used for something else in the
Kerberos code (the ticket/session key tuple, I think).
Jennifer
P.S. Why are we dealing with tickets at all? In the real
life analogies, the ticket carries authorization, and the
ID gives authentication. Whereas in Kerberos, all we're
accomplishing with ticket+authenticator is authentication. ??
--[0335]--
\f
[0336] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 20:40 (12 lines)
Subject: Re: Terminology
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: miller%erlang.DEC@DECWRL.DEC.COM
Cc: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In-Reply-To: Steve Miller's message of 14 Mar 88 14:14 <8803142014.AA04759@decwrl.dec.com>
Half kidding: I have thought that perhaps we should change our terminology thus:
Ticket becomes "T-Pass" and Authenticator becomes "Ticket." For a T-Pass is good
an arbitrary number of times, by one user, for a given time duration. A ticket
is useful only once.
-Jeff
--[0336]--
\f
[0337] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 21:17 (16 lines)
Subject: Re: Terminology
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Cc: miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU,
In-Reply-To: Jeffrey I. Schiller's message of Mon, 14 Mar 88 20:39:11 EST,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Mon, 14 Mar 88 20:39:11 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Ticket becomes "T-Pass" and Authenticator becomes "Ticket." For a
T-Pass is good an arbitrary number of times, by one user, for a given
time duration. A ticket is useful only once.
I couldn't resist.... how about "token"?
:-)
--[0337]--
\f
[0338] daemon@TELECOM.MIT.EDU Kerberos 03/14/88 21:21 (16 lines)
Subject: Re: Terminology
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Ticket becomes "T-Pass" and Authenticator becomes "Ticket." For a
T-Pass is good an arbitrary number of times, by one user, for a given
time duration. A ticket is useful only once.
I couldn't resist.... how about "token"?
:-)
Does that make a set of authenticated principals in a circle a "token
ring"?
:-) :-) :-)
--[0338]--
\f
[0339] daemon@TELECOM.MIT.EDU Kerberos 03/15/88 22:52 (33 lines)
Subject: Terminology
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: steiner@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: steiner@ATHENA.MIT.EDU's message of Mon, 14 Mar 88 18:43:40 EST <8803142344.AA06117@BACH>
I agree with Jennifer. It seems that the technical plan (dated 10
April 1987), uses authenticator to refer to just the piece of data
used to validate the ticket. Where both the ticket and the
authenticator is needed it says that both are sent. It does not name
the combination. This means that the only thing that doesn't
necessarily agree with this naming convention is a few references in
the code. Since many people have the Usenix paper, and quite a few
people have the technical plan, I think we should stick with that
terminology.
If my recollection of the history is correct, authenticator originally
refered to the combination. Since there was not originally a name for
the information used to authenticate the prinicpal other than that in
the ticket, people started refering to the additional information as
the authenticator. Relatively quickly, people started to explicitly
specify that they meant both the ticket and authenticator when they
meant the combination. This all happend before the first real cleanup
of the document, but after the initial code was written.
Since the time that people, other than Steve and myself, worked on the
code, ticket meant just that, authenticator was the additional
information, and the combination of the two was refered to as such,
and not named in itself.
If anything should be changed, the code should be made to agree with
the de facto usage of the terms. Language changes by use, not rule.
In this case, I think it was for the better.
~ Cliff
--[0339]--
\f
[0340] daemon@TELECOM.MIT.EDU Kerberos 03/16/88 10:43 (39 lines)
Subject: re: Terminology
To: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: bcn@june.cs.washington.edu (Clifford Neuman)'s message of Tue, 15 Mar 88 19:46:47 PST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I agree with Jennifer. It seems that the technical plan (dated 10
> April 1987), uses authenticator to refer to just the piece of data
> used to validate the ticket. Where both the ticket and the
> authenticator is needed it says that both are sent. It does not name
> the combination. This means that the only thing that doesn't
> necessarily agree with this naming convention is a few references in
> the code. Since many people have the Usenix paper, and quite a few
> people have the technical plan, I think we should stick with that
> terminology.
The more recent draft (December 22, 1987) of the Technical Plan
section follows this usage also. So far, I think everyone is in
agreement that naming the thing that Kerberos sends back the ticket,
and naming the thing that is added to a ticket the authenticator is
the right approach.
But this approach does leave one loose end beyond the code itself.
The man page for the kerberos library [Kerberos(3)] has to name the
structure that contains the ticket and the authenticator. The
pointer to that structure is of type KTEXT and instances are
currently named "authent" and "ticket" in synopses for {mk_ap_req,
rd_ap_req} and {retrieve}, respectively. And the text says things
like, "rd_ap_req takes an authenticator of type KTEXT, . . ." Under
the agreed-upon convention, both labels are inappropriate. And
unfortunately, these particular labels are visible to the application
programmer.
I suppose the thing to do is to rename the documentation variable,
e.g., to tkt_auth, and to revise the text to say things such as
"rd_ap_req takes a structure tkt_auth of type KTEXT that contains a
ticket and an authenticator. . ."
Jerry
--[0340]--
\f
[0341] daemon@TELECOM.MIT.EDU Kerberos 04/01/88 14:56 (105 lines)
Subject: [Karen R. Sollins: just for fun on April 1]
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: watchmakers@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU, sipb@ATHENA.MIT.EDU
------- Forwarded Message
Date: Fri, 1 Apr 1988 13:21 EST
From: "Karen R. Sollins" <sollins@XX.LCS.MIT.EDU>
To: csr-people@XX.LCS.MIT.EDU, sra@XX.LCS.MIT.EDU, raeburn@ATHENA.MIT.EDU,
msollins@BBN.COM, skent@BBN.COM,
mb%computer-lab.cambridge.ac.uk@NSS.CS.UCL.AC.UK
Subject: just for fun on April 1
>From reserch!dmr Fri Apr 1 09:22:22 PST 1988
Article 16 of news.announce.important:
Path: sun!reserch!dmr
>From: drm@reserch.uucp (Dennis Ritchie)
Newsgroups: news.announce.conferences,news.announce.important
Subject: First International Conference on Secure Information Systems
Message-ID: <6.0225x10toda23@reserch.uucp>
Date: 1 Apr 88 00:00:00 GMT
Expires: 1 May 88 00:00:00 GMT
Organization: AT&T Bell Labs, Unix Research
Lines: 77
Xref: sun news.announce.conferences:250 news.announce.important:16
FOR IMMEDIATE RELEASE % FOR IMMEDIATE RELEASE
The System Security Society of Southern Saskatchewan and the University
of North Saskatechwan, Hoople campus announce the First International
Conference on Secure Information Systems. This conference will feature
a star studded panel of security and system experts from across the
computing spectrum giving boring papers and comparing notes on
security problems and possible solutions for existing and future operating
systems and networking environments.
Papers that will be given at the conference include:
Richard Brandow, MacMag magazine: Computer Viruses as a form
of social terrorism
Dennis Ritchie, AT&T: Trojan Horses: Security Hole or Debugging Aid?
Richard M. Stallman, Free Software Foundation: Passwords are a
Communist Plot, or Give Me Access to Your Computer, Dammit!
Chuq Von Rospach, Fictional Reality: A Secure USENET, an Exercise
in Futility.
Greg Woods, NOAO: Benign Dictatorships in Anarchic Environments: A
Case Study
Peter Honeyman, University of Michigan: Security Features in
Honey-DanBer UUCP, or Why a Flat Name Space is Good.
John Mashey, MIPS Computers: RISC security risks on Usenet
Peter G. Neumann, SRI: The RISKS Of Risk Discussion, or
Why This Conference Should be Classified.
William Joy, Sun Microsystems: Unix is Your Friend.
Donn Parker, SRI: Breaking Security for Fun and Profit: A Survey
Lauren Weinstein, The Stargate Project: Stargate Encryption;
Turning Free Data into Revenue.
Mark Horton & Rick Adams, The UUNET project: Security Aspects
of Pay for Play on USENET.
C. Edward Brown, National Security Agency: How to get USENET
feeds when you don't exist, A Case Study.
Gordon Moffett, Amdahl Corp.: The USENET anarchist's cookbook;
An alternative to the backbone cabal
John Quarterman, University of Texas: The USENIX social agenda
and national security; A summary of Usenet discussions
from Star Wars to Tar Wars.
Landon C. Noll & Ron Karro, Amdahl Corp.: Public Key Encryption
in Smail3.1; How to send E-mail that the NSA can't read
A. I Gavrilov, KGB, North American Information Bureau: Exporting
American Military Information via Encoded USENET Signatures,
Theory and Practice.
The Conference will be held March 2 through 4, 1989 on the campus of the
University of North Saskatechwan in Hoople, Saskatechwan, Canada. Registration
is $195 until December 1, 1989, $295 afterward. For more information please
contact Professor Peter Schikele, Department of Computer Science, University
of North Saskatechwan, Hoople, Saskatechwan, Canada 1Q5 UI9.
Note: This conference is a rescheduling of the conference originally
scheduled for October, 1988 but cancelled after the United States Department
of Commerce decided that the material was too sensitive to allow
non-American citizens to read (including the material written by the
Canadians on the committee). Because of this, the conference has been moved
to Canada, which doesn't have a complete Freedom of Speech written into it's
constitution, but has better things to do than worry about ways of
circumventing civil rights. Americans having trouble getting their papers
cleared for distribution at the conference should contact Professor Shikele
about setting up a direct uucp link for the troff source.
------- End Forwarded Message
--[0341]--
\f
[0342] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 14:08 (35 lines)
Subject: converting a hostname into its realm
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
We have a need in the Kerberos system to determine the realm of a host
given its Internet domain name.
One convention established in a system in use at MIT is to take the
domain name (e.g. MIT.EDU, S1.GOV) as the domain name. For historical
reasons, this fails at MIT, so we need to translate the MIT.EDU into
ATHENA.MIT.EDU, the realm in use for many MIT hosts.
The easiest way to do this would be to have a translation table from
domain names to Kerberos realms for those hosts whose realm != domain.
An open question is whether the table should be compiled into the
library function or disk-resident in a configuration file. (The latter
is much more flexible, but may be prone to spoofing. comments?)
I propose the following function for the Kerberos library:
/*
* krb_getrealm. Given a fully-qualified domain-style primary host name,
* return the name of the Kerberos realm for the host.
*/
char *
krb_getrealm(host)
char *host;
{
take domain portion of hostname
compare with a table of translations, translating if necessary:
MIT.EDU -> ATHENA.MIT.EDU
*.CMU.EDU -> CMU.EDU
etc.
return the domain name or translated name
}
--[0342]--
\f
[0343] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 14:21 (22 lines)
Subject: converting a hostname into its realm
From: probe@ATHENA.MIT.EDU
To: jtkohl@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: John T Kohl's message of Mon, 4 Apr 88 14:05:58 EDT <8804041805.AA12219@ELRIC.MIT.EDU>
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
A domain such as .MIT.EDU could theoretically contain several Kerberos
realms. How do you provide for such a thing in the translation table
that you suggest?
For instance: ACHILLES.MIT.EDU might be in the realm TELECOM.MIT.EDU
whereas ODIE.MIT.EDU could be in the realm ATHENA.MIT.EDU.
I have not fully thought this out to the same extent that John has given
his idea, but how would a query to the remote machine sound? For
instance, if you open a connection to the remote machine on some
arbitrary port (ie krb_query tcp/ip), you would get information about
its Kerberos facilities. If this fails, you could then fall back onto a
table.
-Richard Basch
--[0343]--
\f
[0344] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 14:29 (31 lines)
Subject: Re: converting a hostname into its realm
From: davy@INTREPID.ECN.PURDUE.EDU (Dave Curry)
To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Mon, 04 Apr 88 14:05:58 EDT.
From: John T Kohl <jtkohl@athena.mit.edu>
Date: Mon, 4 Apr 88 14:05:58 EDT
Subject: converting a hostname into its realm
An open question is whether the table should be compiled into the
library function or disk-resident in a configuration file. (The latter
is much more flexible, but may be prone to spoofing. comments?)
One lesson we learned here at Purdue, and still get bitten by with
several old pieces of software: *never*, *ever* compile hostnames into
a piece of code unless you have a real need to do so (which is very
seldom).
Especially with a library routine, you'll be recompiling the world
every time something in your host configuration changes, or you add a
new realm (well, a new real whose name != domain name). That's pretty
gross, and you'll get sick of it fast. The voice of experience
talking here.
It should be reasonably easy to make the file un-prone to spoofing.
(No symbolic links, link count = 1, correct owner and mode, you could
even store a checksum in the binary and update it like "ps" updates
itself, if you had to.)
--Dave Curry
--[0344]--
\f
[0345] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 14:44 (23 lines)
Subject: Re: Converting a hostname into its realm
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Two comments -
First, I would not assume a one-to-one mapping from domain name to
Kerberos realm. We intentionally did NOT use domains as management units
to allow flexibility in configuring security management. So if you do
a mapping, it should be from a full host name to Kerberos realm. You might
want to try to optimize this by first trying a domain name based translation,
with backup provision of some sort for a host name based translation.
Second, in terms of security, it shouldn't make any differences. If the
realm name is wrong, it could result in a denial of service,
since you couldn't discover what Kerberos realm to talk to. In order to
prevent a service from being spoofed, the mutual authentication option of
Kerberos should be used -- but this is true whether within a single realm
or across realms. The only difference is that if the realm is looked up
transparently behind the users back, it is easier for them to believe they
are talking to the right realm and server when indeed they are talking to a
different realm and server.
Steve.
--[0345]--
\f
[0346] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 14:46 (19 lines)
Subject: Re: converting a hostname into its realm
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: davy@INTREPID.ECN.PURDUE.EDU
Cc: John T Kohl <jtkohl@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Dave Curry's message of Mon, 04 Apr 88 13:27:42 EST,
From: davy@intrepid.ecn.purdue.edu (Dave Curry)
Date: Mon, 04 Apr 88 13:27:42 EST
It should be reasonably easy to make the file un-prone to spoofing.
(No symbolic links, link count = 1, correct owner and mode, you could
even store a checksum in the binary and update it like "ps" updates
itself, if you had to.)
It's probably even easier that that. Currently the /etc/krb.conf file
is trusted; theoretically an attack there would be just as damaging as
an attack on a translation table in some other file.
John
--[0346]--
\f
[0347] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 16:25 (70 lines)
Subject: re: converting a hostname into its realm
To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: John T Kohl <jtkohl@ATHENA.MIT.EDU>'s message of Mon, 4 Apr 88 14:05:58 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> We have a need in the Kerberos system to determine the realm of a host
> given its Internet domain name.
>
> The easiest way to do this would be to have a translation table from
> domain names to Kerberos realms for those hosts whose realm != domain.
>
> An open question is whether the table should be compiled into the
> library function or disk-resident in a configuration file. (The latter
> is much more flexible, but may be prone to spoofing. comments?)
This is a job for a network inquiry, either of a name server or of
the target host itself. The trick is to avoid adding an extra level
of fragility to the system by introducing dependence on yet another
network path and yet another host. A second trick is to keep the
total number of network interchanges from doubling.
I believe that spoofing is not really a problem. By virtue of its
knowledge of the keys of its clients, Kerberos is self-protecting.
The worst thing that can happen when someone slips you a bogus realm
value is that you can't find a Kerberos that can give you a valid
ticket. Since there are lots of ways for me to prevent you from
finding your way to Kerberos or to the service itself, I don't think
that providing info via an unprotected remote inquiry (or by a stored
configuration file) represents a new exposure.
I would be inclined to go at it sequentially:
1. Assume that the target service is in your Kerberos realm and ask
your Kerberos for a ticket. (Your own realm is named in your own
krb.conf.) This will answer 95% of the questions without adding any
packets or delay. [The only thing that could go wrong is if your
realm isn't the right one, but it happens to have a different service
with the identical service name and instance. Since the instance for
a service includes the fully qualified host name, I don't think that
problem arises in practice.]
2. If your Kerberos responds "never heard of that service" then
begin looking harder. Ask the host server itself at a krb-realm
inquiry port. In order to do that, you first have to ask an IP name
server for that server's IP address. Thus in the unusual case of
cross-realm access there is a little extra network traffic.
Question: is there any reason to assume that all the services offered
by a given host are in the same realm? The present krb.conf provides
only a single realm value, but there is no reason why that value
couldn't be indexed by service. Note that the inquiry in part 2 can
include the service name, and therefore the answer can be
per-service.
An alternative to step (2) would be to ask the IP name service for a
record of type krb-realm for the target host. Since you have to be
able to get to that name service to find the IP address anyway, this
doesn't add any extra fragility, but I can't find any particular
advantage to doing it that way, apart from automatic caching of the
result in the name server cache. (I suspect that closely repeated
inquiries for the realm name of the same server are infrequent enough
that caching would have little effect on either performance or
robustness.) And it would be more awkward to provide different
answers for different services at the same host. [We could ask
Hesiod to provide service-dependent realm info, but that would
introduce a dependence on an additional set of servers, and also make
running a Hesiod service a prerequisite for using Kerberos. Both of
those properties are negatives.]
Jerry
--[0347]--
\f
[0348] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 17:08 (19 lines)
Subject: re: converting a hostname into its realm
From: srz@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
The problem with going at it sequentially is that you are assuming that
the service names are going to be unique for each realm. For instance,
if I am in the LCS.MIT.EDU realm, and I want to log onto
KERBEROS.MIT.EDU, I would be asking for the service "rcmd.kerberos".
If that service were registered in the LCS realm, I would
get tickets valid for KERBEROS.LCS.MIT.EDU, not KERBEROS.MIT.EDU.
Similar problems occur for generic service names, such as
"zephyr.zephyr".
I think the routine that John suggested should be defined, even though
the exact implementation may be site-specific. That way, different
sites can make tradeoffs between flexibility and the cost of network
traffic. If we assume that different services on the same server
may be in different realms, then perhaps the service name should
be another argument to this routine.
--[0348]--
\f
[0349] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 17:16 (45 lines)
Subject: Re: converting a hostname into its realm
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: Richard Basch <probe@ATHENA.MIT.EDU>
Cc: jtkohl@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Richard Basch's message of Mon, 4 Apr 88 14:19:43 EDT,
I have not fully thought this out to the same extent that John has given
his idea, but how would a query to the remote machine sound? For
instance, if you open a connection to the remote machine on some
arbitrary port (ie krb_query tcp/ip), you would get information about
its Kerberos facilities. If this fails, you could then fall back onto a
table.
This is extactly what Jeff proposed quite a while ago. It sounds very
attractive but I have been convinced that you have serious spoofing
problems with this scheme. Bascially you allow somebody to point you
at the wrong kerberos realm. Any realm you exchange ticket-granting
ticket keys with would be able to do you serious harm. Imagine:
Client in Kerberos realm A queries server in Kerberos realm C, what
realm are you in? But nasty in Kerberos realm B replies, "I'm in
realm B". Then client in A goes and gets tickets for the service but
in the wrong realm (B not C). This works however, if A's Kerberos and
B's Kerberos have exchanged a common key for inter-realm
authentication. Realm B can then look just like realm C ...
Basically if you use the simple query mechanism any realm you "trust"
to do inter-realm sytle authentication can spoof any other realm you
might want to deal with.
The simplest way to deal with this is to know the hostname to realm
mapping a priori. A good aproximatation to this is a table in the
*local* filesystem. I think Richard's point about achilles.mit.edu
and odie.mit.edu belonging to different realms and Rob's point made
last week about CMU have ten million sub-domains which probably want
to be mappped into the same kerberos realm, mean you have to have a
do something like this:
1) look up the whole hostname in the table. if you find a realm
use it.
2) otherwise look up the domain and use what you find
While the table approach is nice, it is very attractive to be able to
fall back on an algorithmic approach that will work the first time at
a new site ...
-- Jon
--[0349]--
\f
[0350] daemon@TELECOM.MIT.EDU Kerberos 04/04/88 18:56 (47 lines)
Subject: Re: converting a hostname into its realm
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jon Rochlis <jon@ATHENA.MIT.EDU>'s message of Mon, 4 Apr 88 17:13:37 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Basically if you use the simple query mechanism any realm you "trust"
> to do inter-realm sytle authentication can spoof any other realm you
> might want to deal with.
Jon's argument is a very good one, but there is a part of it that I
find slightly suspect. If I start things off by saying
rlogin nutmeg.lcs.mit.edu
without specifying which realm I want authentication in, presumably
it is acceptable to connect me with any service that has an
authenticable Kerberos identity of the form {rcmd, nutmeg, *}. If
there is more than one such identity out there, I'm not convinced
that getting a different one from the one I expected is an example of
"spoofing". If I wanted to be connected to the one that is
authenticated by kerberos.lcs.mit.edu, I should have said so. (Not
that we currently have any syntax for saying so.)
Kerberos provides a guarantee that you are talking to the service
that you named, nothing more. If you provide an ambiguous name, then
Kerberos can give only an ambiguous guarantee.
That does mean that we need a way to allow people to specify
unambiguously what service they want, including realm.
> The simplest way to deal with this is to know the hostname to realm
> mapping a priori. A good aproximatation to this is a table in the
> *local* filesystem.
One problem in the Athena environment is that this mapping would have
to be per-user, wouldn't it? I don't think we want to get into the
business of distributing system-wide tables of all the services that
our users may use in other realms--adding a realm becomes a big job.
But a per-user mapping is certainly a nuisance from a user-interface
point of view--each user of the new realm has to add it.
The real problem here appears to be that we want an authenticated
realm default translation but we don't have an authenticated name
service. So the local table is the only way to gain authenticity.
A Kerberos-mediated name server would work as well.
Jerry
--[0350]--
\f
[0351] daemon@TELECOM.MIT.EDU Kerberos 04/07/88 18:01 (107 lines)
Subject: [eachus@mitre-bedford.arpa: Re: Question--Exporting the DES Algorithm]
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Here's yet another opinion on DES exportability.
- Bill
------- Forwarded Message
Resent-From: <security@aim.rutgers.edu>
Date: Fri, 11 Mar 88 17:55:05 EST
From: eachus@mitre-bedford.arpa
Subject: Re: Question--Exporting the DES Algorithm
Sender: security@aim.rutgers.edu
To: iconsys!bryan@uunet.uu.net
Resent-Date: Wed, 6 Apr 88 23:01 EST
Resent-To: security-list@aim.rutgers.edu
The communications on exporting the DES algorithm which have
appeared on the net recently are ALL correct. Huh? What did you just
say? Read on.
If something not subject to ITAR regulations is in the public
domain, or "widely published" in the US, any citizen has a general
license to export that information. If fact you may go overseas and
speak publicly about what you know, and that will create information
subject to license requirements, qualify it for general license, and
export it. In other words, as an American citizen, your freedom of
speech does not end at the waters' edge. (The country where you give
the speech might not like what you say, but that is a different
issue.)
However, if you have information subject to ITAR regulations (no
matter how you got it), you (or your company) can be prosecuted if you
export it without State Department approval. See the "aid and
comfort" clause in the constitution. Since some crypto information is
clearly protected this way, most company lawyers "take the easy way
out" and advise the company not to export any crypto software, without
checking to see if it falls under the ITAR rules.
(Apply standard disclaimers to what follows at least twice.) Last
time I checked the "opinion" of State was that the DES algorithm was
not subject to ITAR rules, although certain implementations (usually
in the form of chips) were protected. Note that any government
employee must be vague here, either he knows all the (classified) uses
of crypto (and where is YOUR need to know) but can't tell you, or he
doesn't know and can't be more specific. Therefore the standard
procedure is to request an opinion before exporting crypto
implementations, and if you don't get something on the order of "your
application does not currently appear to fall under ITAR rules..." you
talked to the wrong person (or you really are trying to export a 300
MIP DES chip 8^> ).
If you do ACCIDENTLY export something subject to ITAR rules, you
probably won't go to jail. In any violation, your rights to free
speech must be shown to conflict with other constitutional powers, and
the balence must tilt strongly against you before the ITAR regulations
have any standing. If you intentionally violate the ITAR regs,
however you might not have any constitutional protection.
Let me give you a realistic example. You buy a Zowie 1000
portable computer and take it with you to England. Unbeknownst to
you, the Zowie 1000 is used in a test system for Stealth Bomber ECM
equiptment. You violated the ITAR regulations, but in the normal
course of events, you won't even know it, because the DoD is unlikely
to tell the Customs people which COTS (commercial off the shelf)
equipment is used on black projects. In any case your violation was
innocent and is probably protected.
Second case, an ATE specialist on the Stealth project buys a
Zowie 1000 for personal use because he uses it at work and likes it.
He takes it (and some of his software) to England on his vacation.
Dumb, and the security folk at the plant may have a long talk with
him, but if it was innocent probably no long term repercussions. The
third case of course, is he takes it with him and sells it to a
foriegn agent for $100,000 -- and twenty years hard labor. What did
you think the ITAR regulations were for anyway?
So now you know why all the weasel words. If you take my
(knowingly incoorect) advice (or someone elses) and innocently violate
the ITAR regs, I'm guilty and you are not... "So you're going to
Berlin on your vacation? Could you do me a favor? I have this
package for my sister, but the mail takes weeks. I'll give you ten
bucks for your trouble." You are only guilty if you think he's a spy
and do it anyway... Each case is different, and an awful lot depends
on intent.
It would be nice if someone who has requested and recieved (from
the government, not from a company lawyer) a recent opinion on the DES
algorithm, would post the opinion here. If no one out in net land has
a recent opinion, someone should go ahead and request one. The most
recent opinion I have seen was two companies back, and things can
change in either direction.
Robert I. Eachus
Disclaimer: Oh boy, do I need one here. If you have any intention of
exporting anything which might be subject to ITAR rules, have your
lawyer check with the State Department and get a written opinion. If
you decide to create a test case and take it to the Supreme Court,
I'll be glad to come cheer, but if you expect me to get up and say it
was all my idea, you didn't read carefully.
Second Disclaimer: I didn't ask MITRE, MITRE's lawyers, or anyone
elses lawyers for their opinion of this message, but if I did, I'm
sure that they would waffle at least as well as I did.
------- End Forwarded Message
--[0351]--
\f
[0352] daemon@TELECOM.MIT.EDU Kerberos 04/07/88 22:46 (19 lines)
Subject: "athena-dist.mit.edu" IP number
From: claris!clay@AMES.ARC.NASA.GOV (Clay Maeckel)
To: info-kerberos@ATHENA.MIT.EDU
I am interested in obtaining the documentation on Kerberos. I have FTP access
using Apple's VAX but they have not installed the name server and depend on
a very large /etc/hosts table. If I could get the actual IP number that would
greatly help, or if hardcopy is relatively cheap then I could get it that way.
Thanks for you help.
Clay Maeckel * UUCP: {ames,apple,portal,sun,voder}!claris!clay
(I know nothing!) * Arpanet: claris!clay@ames.arc.nasa.gov
Claris Corporation * AppleLink: Maeckel1 * CompuServe: 73057,255
and as an extra feature, US Mail:
Claris
440 Clyde Avenue
Mountain View, CA 94043
--[0352]--
\f
[0353] daemon@TELECOM.MIT.EDU Kerberos 04/07/88 22:56 (8 lines)
Subject: athena-dist.mit.edu IP address.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: Clay Maeckel <claris!clay@AMES.ARC.NASA.GOV>
Cc: kerberos@ATHENA.MIT.EDU
ATHENA-DIST.MIT.EDU is currently at 18.71.0.38; it is an add-name
for AENEAS.MIT.EDU.
- Bill
--[0353]--
\f
[0354] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 09:56 (28 lines)
Subject: Pls send Kerberos Documentation Hardcopy
To: info-kerberos@ATHENA.MIT.EDU
From: Steve Goldstein <goldstei@MITRE.ARPA>
>If you can't ftp, and would like a hardcopy, send your
request (and US/PTT mail address) to info-kerberos@athena.mit.edu.
Thanks, I can FTP to another host, but it's quite remote from my actual
location, and downloading PS to a Mac at 1200 Baud just won't hack it!
Please send whatever you can to
Steven N. Goldstein
c/o The MITRE Corporation
Suite 200A (West Wing)
600 Maryland Avenue, SW
Washington, DC 20024
(202) 755-0676
One of my duties is formulating network security policy for NASA Science
Internet, a new partner in the DARPA Internet. I want to do more than to
repeat the old saw that "responsibility for security resides [wholly] in the host".
If there's anything of a policy nature attached to releasing any info to me,
please check with Dave Clark, LCS.
Thanks again,
Steve Goldstein
--[0354]--
\f
[0355] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 10:54 (12 lines)
From: "Michael A. Shiels" <mshiels%watmath.waterloo.edu@RELAY.CS.NET>
To: info-kerberos@ATHENA.MIT.EDU
I am not in the Internet for FTP access so could I please have a snail-mail
copy. Thanx.
Michael A. Shiels
9-426 Hazel Street
Waterloo, ON
CANADA N2L 3P8
--[0355]--
\f
[0356] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 11:33 (16 lines)
Subject: Kerberos papers
From: Robert Stroud <Robert_Stroud%newcastle.ac.uk@NSS.CS.UCL.AC.UK>
To: info-kerberos@ATHENA.MIT.EDU
Please could you send me hard copies of the papers on Kerberos advertised
recently in RISKS. My snail-mail address is below. Unfortunately, I cannot
ftp over the ARPANET from the UK.
Thank you.
Dr Robert J Stroud,
Computing Laboratory,
University of Newcastle upon Tyne,
Claremont Road,
Newcastle upon Tyne,
ENGLAND
NE1 7RU
--[0356]--
\f
[0357] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 11:45 (16 lines)
Subject: Kerberos paper
From: rmarks@ksp.unisys.com (richard marks)
To: info-kerberos@ATHENA.MIT.EDU
Dear Ms Steiner:
Please send me a copy of the Kerberos paper.
Below is my home address as my group is moving in a few weeks
and US mail may get confused.
Thank you,
Richard Marks
931 Sulgrave Lane
Bryn Mawr, PA 19010
--[0357]--
\f
[0358] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 11:56 (19 lines)
Subject: Kerberos Documentation
To: info-kerberos@ATHENA.MIT.EDU
Cc: Lee@TSCA.ISTC.SRI.COM
From: lee@TSCA.ISTC.SRI.COM
I would like to receive a copy of your documentation on MIT Project
Athena's authentication service, Kerberos. I could not ftp to
athena-dist.mit.edu. My address is as follows:
Diane Lee
SRI International
MS EK358
333 Ravenswood Avenue
Menlo Park, CA 94025
Thanks
Diane
--[0358]--
\f
[0359] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 12:09 (15 lines)
Subject: Kerberos doc request
From: cam%columbia-pdn@ACC-SB-UNIX.ARPA (Chris Markle acc_gnsc)
To: info-kerberos@ATHENA.MIT.EDU
Sir or Madame,
Please send Kerberos doc to me at the following address:
Chris Markle
ACC
10220 Old Columbia Rd.
Columbia MD 21046
Thanks in advance for your attention to this request.
Chris Markle
--[0359]--
\f
[0360] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 12:38 (13 lines)
From: Quentin Fennessy <quentin%umb.edu@RELAY.CS.NET>
To: info-kerberos@ATHENA.MIT.EDU
Hi,
I would appreciate info on the Kerberos project.
My USMAIL address is :
Quentin Fennessy
43 Billings St.
West Roxbury, MA 02132
Thank you very much
--[0360]--
\f
[0361] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 12:56 (8 lines)
Subject: Kerberos inquiries
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Apologies that people on the "kerberos" mailing list have
been getting mail directed toward "info-kerberos". The
situation is being rectified.
Jennifer
--[0361]--
\f
[0362] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 13:23 (10 lines)
Subject: where is athena-dist?
From: sstovall@DAITC.ARPA (Steve Stovall)
To: info-kerberos@ATHENA.MIT.EDU
what is the address of athena-dist.mit.edu? its not in the master
host table.
steven stovall
sstovall@daitc.arpa
defense applied information technology center
(703) 998 3452
--[0362]--
\f
[0363] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 14:25 (12 lines)
Subject: inquiries
From: steiner@ATHENA.MIT.EDU
To: info-kerberos@ATHENA.MIT.EDU
To the people on the info-kerberos mail list:
Due to the recent postings to net news, we're
getting a lot of requests coming in to info-kerberos.
I just wanted to let you know, so that these people
don't get answers from 5 different Athenians, that
I am answering them.
Jennifer
--[0363]--
\f
[0364] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 15:30 (13 lines)
Subject: Information Request
From: Bob Schumaker <rts@ADEA-ATT.ARPA>
To: info-kerberos@ATHENA.MIT.EDU
I tried to ftp to athena.mit.edu and cannot get there (not was I able to find the
arpa address).
Could you send me the net address that I should ftp to?
Bob Schumaker (schumaker@adea-att.arpa)
The BDM Corporation
10116 36th Avenue Court SW
Suite 300
Tacoma, WA 98499
--[0364]--
\f
[0365] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 16:49 (11 lines)
Subject: Kerberos info
From: Brian Kaye <BDK%UNB.BITNET@MITVMA.MIT.EDU>
To: info-kerberos@ATHENA.MIT.EDU
Please send the documentaion on Project Athena's "KERBEROS" to
Brian Kaye
Computing Centre
University of New Brunswick
P.O. Box 4400
Fredericton, N.B.
Canada E3B 5A3
--[0365]--
\f
[0366] daemon@TELECOM.MIT.EDU Kerberos 04/08/88 18:04 (16 lines)
Subject: Documents
From: wyatt%cfa@HARVARD.HARVARD.EDU (Bill Wyatt)
To: info-kerberos@ATHENA.MIT.EDU
Unfortunately our LaserWriters can't quite hack the PostScript
files in the pub/kerberos/doc directory on athena-dist. Soooo...
Please send a copy to:
William F. Wyatt
Smithsonian Astrophysical Observatory, mail stop 20
60 Garden St.
Cambridge MA 02138
Thanks..
--[0366]--
\f
[0367] daemon@TELECOM.MIT.EDU Kerberos 04/19/88 16:34 (40 lines)
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU, sdsu!vinge@UCSD.EDU
(Please copy Vernor on any replies as he is not on
the mailing list.)
Jennifer
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA21587; Sat, 16 Apr 88 23:17:58 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA20583; Sat, 16 Apr 88 23:17:22 EST
Received: from sdsu by ucsd.edu (5.58/UCSD-1.0) via UUCP;
Sat, 16 Apr 88 21:18:15 PDT id AA06696 for steiner@ATHENA.MIT.EDU
Received: by sdsu.SDSU.EDU (5.51/SDSU-ROOT)
id AA28587 for delivery to ucsd!steiner@athena.mit.edu; Sat, 16 Apr 88 21:15:24 PDT
From: sdsu!vinge@ucsd.edu (Vernor Vinge)
Message-Id: <8804170415.AA28587@sdsu.SDSU.EDU>
To: steiner@ATHENA.MIT.EDU
Subject: kerberos question
Date: Sat, 16 Apr 88 21:15:19 PDT
Jennifer --
I just read "Kerberos: An Authentication Service for Open Network
Systems". Thanks for showing me how to get it.
I have a question (2.5 actually):
Why is it necessary to include the client's IP address in the tickets
and authenticators? Wouldn't the client's name suffice?
Why is it necessary to include the server's name in the ticket?
Thanks,
- -- Vernor
Vernor Vinge
Dept Math Sci
San Diego State University
San Diego, CA 92182
------- End of Forwarded Message
--[0367]--
\f
[0368] daemon@TELECOM.MIT.EDU Kerberos 04/19/88 18:53 (29 lines)
Subject: Re: kerberos question
From: jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes)
To: sdsu!vinge@UCSD.EDU
Cc: kerberos@ATHENA.MIT.EDU
From: sdsu!vinge@ucsd.edu (Vernor Vinge)
Why is it necessary to include the client's IP address in
the tickets and authenticators? Wouldn't the client's name
suffice?
I don't think there's a big problem just using the name, except
that it's probably easier to code using an IP address, since it's
a fixed length. The other problem is that you may not be able to
resolve the name correctly all the time. Probably it's just easier.
I'm not sure what the system does about gateways (those machines
that have more than one IP address), but it probably checks all
the addresses.
Why is it necessary to include the server's name in the
ticket?
To make sure you get the right server? You need to tell the
ticket-granting service which server you want, so I assume it's in
the initial request.
Who on the kerberos design-team is on this list?
/jordan
--[0368]--
\f
[0369] daemon@TELECOM.MIT.EDU Kerberos 04/19/88 20:41 (36 lines)
Subject: Re: client name vs. client IP address.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: jordan@UCBARPA.BERKELEY.EDU
Cc: sdsu!vinge@UCSD.EDU, kerberos@ATHENA.MIT.EDU
The IP address is sealed into the ticket in an attempt to increase
security by a small amount. Someone attempting an attack by replay
must be able to forge the `from' address of an IP packet, which is
(marginally) harder than just sending packets, and is more likely to
be noticed.
The hostname is not in there because doing a nameserver/host table
lookup will impose a pretty large network delay on the server end; in
the current setup, the server side never blocks for I/O (not counting
looking up the service key).
Also, the domain nameserver is eminently spoofable, since its requests
aren't authenticated...
With respect to multi-homed clients (clients with more than one net
address): this is a problem which hasn't really been resolved, as
there is only one address in the packet. If the client binds all its
outgoing sockets to its `primary' address, this ceases to be a
problem, but this requires special code in each client application
using kerberos.
I suspect that there will be some sort of protocol rearrangement in
the future which should include (a) having a list of addresses sealed
in the ticket and (b) tagging each address with some sort of address
family code (I'm pretty sure that DEC, IBM, and Apollo are all
interested in using kerberos over their own proprietary protocols, and
ISO is looming somewhere over the horizon...).
The _service_ name is included in the ticket as an extra check to
make sure that the ticket was decrypted correctly.
- Bill
--[0369]--
\f
[0370] daemon@TELECOM.MIT.EDU Kerberos 04/20/88 14:11 (24 lines)
Subject: Re: client name vs. client IP address.
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: jordan@ucbarpa.berkeley.edu, sdsu!vinge@ucsd.edu, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Tue, 19 Apr 88 20:32:31 EDT.
Those problem with multiply homed hosts are a real pain. When I
initially installed kerberos, I found that gethostid(2) was used
to determine the primary address. I didn't have the hostid set
and the call returned zero. The IPC worked fine, but the protocol
broke because different "addresses" were used. These problems
occured on a host with only one interface.
Using one address as primary on a multiply homed host and only
using that address may lead to problems. Communication might be
only one direction due to routing differences. At Brown, we have
a host on network 128.148 and 128.121. I have seen cases where
the route selected might go through some other machine, out to the
internet and return. Selection of the correct address by the
kernel would totally avoid the problem. For whatever reason,
the hostid might be set to the wrong interface.
Jim
--[0370]--
\f
[0371] daemon@TELECOM.MIT.EDU Kerberos 04/24/88 21:38 (132 lines)
Subject: Kerberos and host addresses
From: kazar+@andrew.cmu.edu
Resent-From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Resent-To: kerberos@ATHENA.MIT.EDU
To: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Mike,
Here's a copy of a recent discussion on the "kerberos" mail
list which may be of interest.
Jennifer
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA08666; Tue, 19 Apr 88 18:02:03 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09827; Tue, 19 Apr 88 17:49:26 EST
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
id AA11331; Tue, 19 Apr 88 15:48:44 PDT
Date: Tue, 19 Apr 88 15:48:44 PDT
From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes)
Message-Id: <8804192248.AA11331@ucbarpa.Berkeley.EDU>
To: sdsu!vinge@ucsd.edu
Subject: Re: kerberos question
Cc: kerberos@ATHENA.MIT.EDU
From: sdsu!vinge@ucsd.edu (Vernor Vinge)
Why is it necessary to include the client's IP address in
the tickets and authenticators? Wouldn't the client's name
suffice?
I don't think there's a big problem just using the name, except
that it's probably easier to code using an IP address, since it's
a fixed length. The other problem is that you may not be able to
resolve the name correctly all the time. Probably it's just easier.
I'm not sure what the system does about gateways (those machines
that have more than one IP address), but it probably checks all
the addresses.
Why is it necessary to include the server's name in the
ticket?
To make sure you get the right server? You need to tell the
ticket-granting service which server you want, so I assume it's in
the initial request.
Who on the kerberos design-team is on this list?
/jordan
----------
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA09143; Tue, 19 Apr 88 19:33:39 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11308; Tue, 19 Apr 88 19:32:57 EST
Received: by STEVE-DALLAS.MIT.EDU (5.45/4.7) id AA05954; Tue, 19 Apr 88 20:32:31 EDT
Date: Tue, 19 Apr 88 20:32:31 EDT
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Message-Id: <8804200032.AA05954@STEVE-DALLAS.MIT.EDU>
To: jordan@ucbarpa.berkeley.edu
Cc: sdsu!vinge@ucsd.edu, kerberos@ATHENA.MIT.EDU
Subject: Re: client name vs. client IP address.
The IP address is sealed into the ticket in an attempt to increase
security by a small amount. Someone attempting an attack by replay
must be able to forge the `from' address of an IP packet, which is
(marginally) harder than just sending packets, and is more likely to
be noticed.
The hostname is not in there because doing a nameserver/host table
lookup will impose a pretty large network delay on the server end; in
the current setup, the server side never blocks for I/O (not counting
looking up the service key).
Also, the domain nameserver is eminently spoofable, since its requests
aren't authenticated...
With respect to multi-homed clients (clients with more than one net
address): this is a problem which hasn't really been resolved, as
there is only one address in the packet. If the client binds all its
outgoing sockets to its `primary' address, this ceases to be a
problem, but this requires special code in each client application
using kerberos.
I suspect that there will be some sort of protocol rearrangement in
the future which should include (a) having a list of addresses sealed
in the ticket and (b) tagging each address with some sort of address
family code (I'm pretty sure that DEC, IBM, and Apollo are all
interested in using kerberos over their own proprietary protocols, and
ISO is looming somewhere over the horizon...).
The _service_ name is included in the ticket as an extra check to
make sure that the ticket was decrypted correctly.
- Bill
------------
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA13767; Wed, 20 Apr 88 13:16:43 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24456; Wed, 20 Apr 88 13:08:50 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac00397; 20 Apr 88 10:26 EDT
Received: from cs.brown.edu by RELAY.CS.NET id ab29151; 20 Apr 88 10:09 EDT
Received: by cs.brown.edu (5.51/1.00)
id AA28389; Wed, 20 Apr 88 09:29:58 EST
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
Message-Id: <8804201329.AA15527@archer.cs.brown.edu>
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: jordan@UCBARPA.BERKELEY.EDU, sdsu!vinge@UCSD.EDU, kerberos@ATHENA.MIT.EDU
Subject: Re: client name vs. client IP address.
In-Reply-To: Your message of Tue, 19 Apr 88 20:32:31 EDT.
<8804200032.AA05954@STEVE-DALLAS.MIT.EDU>
Date: Wed, 20 Apr 88 09:29:11 EDT
Those problem with multiply homed hosts are a real pain. When I
initially installed kerberos, I found that gethostid(2) was used
to determine the primary address. I didn't have the hostid set
and the call returned zero. The IPC worked fine, but the protocol
broke because different "addresses" were used. These problems
occured on a host with only one interface.
Using one address as primary on a multiply homed host and only
using that address may lead to problems. Communication might be
only one direction due to routing differences. At Brown, we have
a host on network 128.148 and 128.121. I have seen cases where
the route selected might go through some other machine, out to the
internet and return. Selection of the correct address by the
kernel would totally avoid the problem. For whatever reason,
the hostid might be set to the wrong interface.
Jim
------- End of Forwarded Message
--[0371]--
\f
[0372] daemon@TELECOM.MIT.EDU Kerberos 04/26/88 11:40 (25 lines)
Subject: More on Kerberos questions
From: spm%lyre.DEC@DECWRL.DEC.COM (Steven Miller)
To: jordan@ucbarpa.berkeley.edu, kazar+@andrew.cmu.edu
The net (Internet) address in the ticket is used, as Bill stated,
to inhibit replay attempts. The receiver checks
the address sealed in the Kerberos ticket against the address received from.
Using a host name is both much more expensive (to encrypt more data) and
not as strong a deterrent, since it is easier to forge.
Multiply-homed hosts are currently a problem if different addresses are
used when requesting tickets than when requesting authorizations.
This was an oversight in the design.
On the second question, the server's complete name must be included in the
ticket. Note that there are no rules prohibiting running multiple Kerberos
mediated servers with
the same crypto keys, or running multiple Kerberos-mediated servers in a
single process. So the server name is required to assure that the correct
service is represented, regardless of these "packaging" issues. The service
name will-- but is not necessary to -- ensure that the ticket was unmodified
and properly decrypted. Errors in other fields could detect such errors.
Steve
--[0372]--
\f
[0373] daemon@TELECOM.MIT.EDU Kerberos 04/26/88 19:40 (77 lines)
Subject: a possible attack on Kerberos.
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Cc: John Leo <leo@ATHENA.MIT.EDU>
One possible attack on Kerberos could involve being able to predict
the random number generator used by the KDC to create session keys.
In particular, the `rand()' random number generator is not very good;
the low order bit is not really random. `random()' is better, but not
available on non-BSD systems. System V includes a `rand48()' which is
supposedly better than `random()'; however, it isn't available on
Berkeley Unix..
It might make a lot of sense to do a portable implementation of the
algorithm described in the paper referred to in this posting and
include it in the distribution.
Of course, if you _really_ wanted to produce good random numbers for
session keys, you'd hook up a radioisitope and geiger counter to the
KDC...
- Bill
(this is truncated from the posting, so I don't overfill everyone's
mailbox..)
From bloom-beacon!athena.mit.edu!leo Tue Apr 26 19:26:34 EDT 1988
Article 1154 of sci.crypt:
Path: bloom-beacon!athena.mit.edu!leo
>From: leo@athena.mit.edu (Oblivious Transfer)
Newsgroups: sci.math,sci.crypt
Subject: pseudo-random number generation
Message-ID: <4898@bloom-beacon.MIT.EDU>
Date: 26 Apr 88 22:49:28 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: leo@athena.mit.edu (Oblivious Transfer)
Organization: Massachusetts Institute of Technology
Lines: 278
Xref: bloom-beacon sci.math:3624 sci.crypt:1154
For those interested, the following is the introduction to the
Blum-Micali paper on pseudorandom number generation. Although the paper
is rather difficult reading, the introduction is fairly easy to follow
and quite enjoyable. I have included the numbered references, but not
mentioned what they are; also notation has been made TeX-like for
precision. Hopefully there are not too many typos.
John Leo
leo@xx.lcs.mit.edu
leo@athena.mit.edu
******
Siam Journal of Computing, Volume 13, Number 4, November 1984
(pages 850-864)
How to Generate Cryptographically Strong Sequences of Pseudo-random Bits
Manuel Blum and Silvio Micali
ABSTRACT: We give a set of conditions that allow one to generate 50-50
unpredictable bits.
Based on those conditions, we present a general algorithmic scheme for
constructing polynomial-time deterministic algorithms that stretch a
short secret random input into a long sequence of unpredictable
pseudo-random bits.
We give an implementation of our scheme and exhibit a pseudo-random
bit generator for which any efficient strategy for predicting the next
output bit with better thant 50-50 chance is easily transformable into
an "equally efficient" algorithm for solving the discrete logarithm
problem. In particular, if the discrete logarithm problem cannot be
solved in probabilistic polynomial time, no probabilistic
polynomial-time algorithm can guess the next output bit better than by
flipping a coin: if "head" guess "0", if "tail" guess "1".
KEY WORDS. randomness, pseudo-random number generation,
unpredictability, random self-reducibility
--[0373]--
\f
[0374] daemon@TELECOM.MIT.EDU Kerberos 04/27/88 07:47 (14 lines)
Subject: a possible attack on Kerberos.
From: chariot@ATHENA.MIT.EDU
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU, leo@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Tue, 26 Apr 88 19:37:41 EDT <8804262337.AA09081@EPIMETHEUS.MIT.EDU>
Re. the Blum-Micali paper, etc. If anyone is interested in
this, I am currently taking 6.875J -- intro to cryptography and
cryptoanalysis. We recently did poly-random generators in all their
gory detail. I have a hard copy of this paper and many revent other
papers if anyone is interested. I can also *explain* it as well...
Warning: the paper is not easy to understand without a reasonable math
background...
- Mark Lillibridge
--[0374]--
\f
[0375] daemon@TELECOM.MIT.EDU Kerberos 04/27/88 21:12 (59 lines)
Subject: Powerhouse Patrons Behind ID Tokens
Resent-From: Bob Sidebotham <bob+@andrew.cmu.edu>
Resent-To: kerberos@ATHENA.MIT.EDU
X-Digest-From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@KL.SRI.COM>
X-Digest-To: RISKS-LIST@KL.SRI.COM
From: "Vin McLellan" <SIDNEY.G.VIN%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Apparently-To: kerberos@athena.mit.edu
A new venture in token-based ID authentication -- and a hint of a broad
new thrust in EDP security -- has emerged with the first product from the
Applied Information Technologies Research Center, a little-known R&D consortium
organized in 1984 by a number of universities and leading U.S. vendors of
information service products.
AITRC, in Columbus, Ohio, about to beta test a credit card-sized
calculator which impliments a challenge-response ID authentication. A software
module on a host CPU sends a 7-digit challenge to a remote terminal, the user
keys that number into his "calculator," presses a special authentication button
to process that number (and a token-specific seed) through a one-way crypto
algorithm -- then reads off the 7-digit response code on the calculator's LCD
screen. That number, transmitted to the host, verifies the token as one issued
to a specific user.
Tokens (also called "hand-held password generators") are said by IBM to
increase the certainty of end user authentication by at least a full order of
magnitude over mere passwords. Tokens impliment the second of the three ID
authentication options (something known, something held, something inherent to
the user) and have drawn rising interest as the relative frailty of classic
password systems becomes apparent and risks proliferate.
The two leading vendors, Security Dynamics in Cambridge, Ma., and Sytek of
Mountain View, Ca., are NSA-certified -- so their tokens can be integrated into
access control systems for secure DoD computers -- and SD last week obtained a
GSA scheduled contract which allows no-bid purchases by federal agencies. But
the AITRC development may mark tokens even more forcefully as the future
direction for the industry.
AITRC is jointly funded by CompuServ, Meade Data Central, Chemical
Abstracts, the Online Computer Library Center and John Wiley & Sons; as well as
Carnegie Mellon University, University of Pittsburgh, Wright State University,
Ohio State, the Ohio State University Research Foundation, BDM Corp., and
Batelle Institute. No lightweights there.
AITRC hopes to see licensed token/calculators marketed at $10 apiece
by the end of this year, according to AITRC president George Minot --
although the members of the AITRC consortium could potentially use and offer
them to their clients for even less, he said, since consortium members get
royalty-free access to the technology.
At $10 per unit, AITRC would revolutionize the pricing of tokens --
which currently range between four and ten times that for comparable
devices. Minot conceeded, however, that projected price is based on high
volume production (minimum100,000) overseas. The AITRC token is built upon
the 4-bit NEC calculator chip, works as a standard calculator, and is
powered by a 2-year lithium battery. According to Minot, the device is also
designed to be "initialized," or registered on the host, from any remote
terminal or push button telephone.
Vin McLellan, The Privacy Guild, Boston, Ma. (617) 426-2487
--[0375]--
\f
[0376] daemon@TELECOM.MIT.EDU Kerberos 04/28/88 16:37 (18 lines)
Subject: Re: Random Session Keys.
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
I talked very briefly to our crypto guru, and he mentioned that some of
the crypto-based pseudo-random key generators were very expensive
computationally, and one had to exercise care in the initial (secret) seed.
He suggested looking at a DES based solution as sketched out in the
ANSI X9.17-1985 Appendix C, which is seeded using a secret double length
DES key and secret IV. I will paper mail a copy of the page to Bill Sommerfield.
It would be a very worthwhile minor project to carefully look into this and
other similar alternatives, making sure the sequences are extremely long.
If something works out in terms of both randomness and computes, I would
strongly recommend adopting it.
Steve.
--[0376]--
\f
[0377] daemon@TELECOM.MIT.EDU Kerberos 05/04/88 06:49 (6 lines)
Subject: release date?
From: Jordan Hayes <jordan@ADS.COM>
To: kerberos@ATHENA.MIT.EDU
any word on when we can get a look at the code?
/jordan
--[0377]--
\f
[0378] daemon@TELECOM.MIT.EDU Kerberos 05/04/88 15:38 (15 lines)
Subject: Re: release date?
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Jordan,
I am waiting for documentation on installation and
operations to be completed. It is currently being
debugged and should not take much longer. I am
hoping it will be finished by end of this week, but
will release the code by next week at the latest in
any case.
Thanks for your patience,
Jennifer
--[0378]--
\f
[0379] daemon@TELECOM.MIT.EDU Kerberos 05/13/88 17:19 (10 lines)
Subject: beta test release delay
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
I'm still awaiting official word that we can release
Kerberos code for beta test (with or without DES).
I've been promised an answer by Monday.
Once again, sorry for the delay.
Jennifer
--[0379]--
\f
[0380] daemon@TELECOM.MIT.EDU Kerberos 05/16/88 13:30 (50 lines)
Subject: one more piece of paper
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Kerberos beta testers,
I'm afraid I have to ask for one more piece of
paper from you, which we require in order to
protect MIT from any problems should a copy
of our DES implementation make its way overseas.
Could you send a signed copy of the letter below
to me? Upon receipt I will either mail you a tape
or give you ftp instructions, whichever is appropriate.
Jennifer
(my address again:)
Project Athena
MIT E40-300
77 Massachusetts Avenue
Cambridge, MA 02139
USA
------------------------- cut here ------------------------------
To: Jennifer Steiner
Date:
Subject: Kerberos beta distribution
I understand that the Data Encryption Standard library
of MIT Project Athena's Kerberos beta test source code
distribution may be subject to restrictions imposed by
the Export and Commodities Control List, and that the beta
test release is not for redistribution.
Signed,
-------------------------
(signature)
-------------------------
(name, please print)
of
-------------------------
(Name of Institution)
--[0380]--
\f
[0381] daemon@TELECOM.MIT.EDU Kerberos 05/19/88 13:00 (187 lines)
Subject: Kerberos beta testers
From: steiner@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Below is a list of people who will be participating
in the Kerberos beta test, along with brief descriptions
of their test environments.
Jennifer
--------
Steve Bellovin <smb@research.att.com> of AT&T Bell Labs.
We have ~30 Suns running SunOS 3.4, plus several VAXen and a CCI 6/32
running 4.3bsd. Our machines are linked via assorted gateways to a
moderate number of other TCP/IP networks (using assorted technologies).
We'd really like to run Kerberos on our local nets plus those of one
affiliated department, since we provide computing services for them
(though they have their own workstations as well). Our applications
include the obvious standards ones (rsh, rlogin, and NFS (our VAXen
are starting to run Mt. Xinu NFS)), possibly others.
--------
Dave Curry <davy@intrepid.ecn.purdue.edu> of Purdue University.
26 timesharing machines (Vaxes and Goulds), 147 Sun workstations with
about 100-150 more on order to show up this summer. We have 7
different Schools of Engineering in our network; we might make each
one a different Kerberos realm (or not, depends on some of the
capabilities of Kerberos). We have about 12,000 users. We are
also connected to the Computer Center and the Computer Science
department here.
--------
Craig Finset <fin@uf.msc.umn.edu> of the Minnesota Supercomputer Center.
Our environment includes:
5 Sun 3/180 and 3/280 computers
10 Sun 3/50 and 3/60 diskless workstations
2 CRAY-2 supercomputers
They are connected via Ethernet and Hyperchannel.
We will initially bring it up on our development computer and some of
the workstations. As we gain experience and confidence in it, we will
expand it to our staff machine, then (ultimately) to our routers.
Finally, we hope to port it to the Crays (and, after you have released
the official version, to offer it to our customers).
Initial applications will be to authenticate NFS mounts, to eliminate
the /bin/su program, and to eliminate .rhosts files. Later
applications will be to convert from offering telnet-accessed local
accounts to direct network access to services.
--------
Jordan Hayes <jordan@ucbarpa.Berkeley.EDU> of Advanced Decision Systems.
Environment:
Vaxes, Suns, Pyramids, Intel HyperCube, BBN Butterfly, etc.
We are a government contractor centering on artificial
intelligence applications. We're interested in security,
on the network and in UNIX in particular.
--------
Greg Kenley <harvard!palladium!gkenley> of Epoch Systems.
Epoch Systems currently consists of a heterogeneous mix of
Vaxen, Suns, Macs and PCs and our own DataStation(tm). The
DataStation is an ultra high capacity NFS compatable file server
designed to support the current and next generation of technical
workstations. The common thread amongst all our systems is that
they connect via NFS, the Darpa protocols and Ethernet.
--------
Norm Kincl <norm%atom@hplabs.HP.COM> of HP labs.
We plan to bring Kerberos up on our HP-UX workstations and begin
experimenting with authentication in various services.
--------
Pierre-Louis Neumann <neumann%inria.inria.fr@uunet.uu.net> of Inria.
Inria is a governmental research institute in computer
science. We use 150 machines connected on an Ethernet:
100 Sun3 diskless workstations (with 20 Sun servers)
4 Vax 785 4.3BSD
2 NP1 Gould
1 Pyramid
10 Apollo on their Domain ring network
the others are French BULL SPS7 (System V.2 + sockets + NFS)
--------
Gary Rosenblum <rosenblg@acf3.nyu.edu> of New York University.
Our initial test environment will consist of two Vaxen
running Mt. Xinu's release of 4.3BSD, a Sun 3/180-S server,
my Sun 3/50 workstation (both running Sun OS 3.4), and a
Microvax running either 4.3BSD or Xinu's 4.3. Then we will
extend to more Vaxen and Sun workstations.
In the summer, a new dorm will open with space for 80 workstations. We
plan to stock it with IBM PCs, Mac IIs, and Sun workstations. Our plan
is to use Kerberos for authentication of the workstations. Eventually,
we hope to include the (approximately) 100 Sun workstations and servers
on other subnets, on our extended LAN.
--------
Robert Viduya <robert@pyr.gatech.edu> of the Georgia Institute
of Technology.
Our environment currently consists of a Pyramid 90x running an
essentially 4.2BSD kernel, a MicroVAX II running 4.3BSD acting as our
main network nameserver and two MicroVAX II's running Ultrix 2.2
acting as fileservers for a cluster of 24 VAXStation 2000's running
Ultrix 2.2. In addition, we have two AT&T 3B20's running SysV R2.1.1
with Wollongong TCP/IP and a few 3B2's running SysV R3.0, also with
the Wollongong TCP/IP package. We also have 60 Macintosh II's
with A/UX (to be installed), and 24 Macintosh II's running MacOS.
--------
Mike Zeleznik <zeleznik@cs.utah.edu> of the University of Utah.
Two groups within the University of Utah Computer Science Department
will be working with Kerberos.
1) Utah Retrieval System Architecture (URSA) group:
We are interested in integrating Kerberos with the URSA information
retrieval system. The URSA system is designed for very large (e.g. 50+
Gbyte) non-formated databases, supported by custom pattern search
hardware. The architecture is message-based, distributed, and
reconfigurable on the fly (the datacomm package relocates modules and
reestablishes connections), with a sophisticated window-based user
interface. It has run distributed across Apollo, Sun, and VAX systems,
on both BSD4.X and native Apollo Aegis (it was designed also for
portability). Currently, we are working very closely with Apollo.
We are also involved with the startup of the Univ. of Utah campus
computing network, currently underway, which could also offer some
interesting testing possibilities for Kerberos (e.g., multiple
administrative domains).
2) Computer Science Department systems programming group:
We have ported 4.3 with NFS to the HP 9000/300 series machines
(Bobcats), and are investigating using MIT's RVD protocol to provide
diskless support for these HP workstations. The current version of RVD
uses Kerberos.
In addition, in the CS dept's environment of well over 100 Unix hosts,
we want to investigate Kerberos as a replacement for our current
Berkeley .rhosts method of authentication, with its well known
weaknesses.
--------
In addition (people for whom I don't yet have an environment
description) are:
--------
Scott Bradner <sob@harvard.harvard.edu> of Harvard.
--------
Steve Miller of DEC <miller%erlang.DEC@decwrl.dec.com>, one
of the original creators of Kerberos.
--------
Steven M. Miller <smiller@umn-cs.cs.umn.edu> of the
Secure Computing Technology Center of Honeywell.
--------
--[0381]--
\f
[0382] daemon@TELECOM.MIT.EDU Kerberos 05/25/88 17:55 (22 lines)
Subject: erlogin
To: kerberos@ATHENA.MIT.EDU
Cc: don@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Beta testers,
Below is an addendum to the "Kerberos Installation Notes"
document.
Jennifer
----------
The directory SRCDIR/appl/erlogin contains some code
based on rlogin[d], modified by Don Davis of Project
Athena to do the following:
erlogin is a rewritten version of 4.3bsd rlogin(d). it causes the remote
login session to share the invoker's DISPLAY environment-variable/value,
and can readily be modified to pass other environment variables/values.
it offers kerberos authentication, but can talk to hosts that don't support
kerberos. it is intended to be backwards compatible with 4.2bsd rlogin.
--[0382]--
\f
[0383] daemon@TELECOM.MIT.EDU Kerberos 05/26/88 14:23 (34 lines)
Subject: beta testers addendum
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Scott Bradner <sob@harvisr.harvard.edu> of Harvard
The computing environment at William James:
5 Microvax IIs running Mt Xinu 4.3 with NFS
1 Sun 3/60 running SunOS 4.0
about 30 PCs on Ethernet, PCnet (gated to Ethernet with tcp/ip drivers)
or Appletalk (all Appletalked PCs to be moved to Ethernet within 2 months)
about 15 Macs on Appletalk
Appletalk connected with a fastpath box to the Ethernet
New uses for Kerberos:
We do printer serving on the Microvaxes for the PCs and Macs. Since
we must charge for the printer use the current method of printing
requires the user to "print" the file on the PC or Mac which transfers the
file to a subdirectory in the user's Microvax account. The user must then
login to the Microvax (establishing their id for billing) then send the
file to the printer. We wish to add Kerberos to a version of the printer
driver in the Mac and into the network drivers on the PC so that the user
is not required to do the second step. We also provide for electronic
mail to and from the PCs. (We ported Berkeley mail to the PC and have it use
a server on one of the Microvaxs.) The user must currently type in a
password in order to send or receive mail; Kerberos could be used to make
this easer. We have developed software to do remote incremental backups
of the PCs, this like the email requires that the user enter a password to
get things started, another logical place for Kerberos.
---------
--[0383]--
\f
[0384] daemon@TELECOM.MIT.EDU Kerberos 05/26/88 20:01 (25 lines)
Subject: Sun Licenses
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
It turns out we can only supply NFS Kerberos modifications
to holders of a Sun NFS Educational Institution Source
License.
Commercial license holders must obtain our changes directly
from Sun. I am in the process of getting a name of someone
to contact at Sun.
According to my records, the following sites have sent us
copies of the required (Educational Institution) license:
NYU
Univ. Utah
If you think you sent me such a license and aren't on that list,
please drop me a note.
I'll let you know as soon as I have a person to contact
at Sun, for those people who have a commercial-type source
license.
Jennifer
--[0384]--
\f
[0385] daemon@TELECOM.MIT.EDU Kerberos 05/31/88 16:07 (10 lines)
Subject: Sun NFS modifications
To: kerberos@ATHENA.MIT.EDU
Cc: warrens@sun.com
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Beta testers who have a Sun NFS Source License (as opposed
to a Sun NFS Educational Institute Source License) must get
MIT's Kerberos modifications to NFS directly from Sun. The
person to contact is Warren Smith (warrens@sun.com).
Jennifer
--[0385]--
\f
[0386] daemon@TELECOM.MIT.EDU Kerberos 06/05/88 16:26 (31 lines)
Subject: faster encrypted rlogin
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Jeff and I were talking a little last night, and this idea came up.
While the encrypted rlogin that is in the beta release (at least, I
think it was; I picked up one from our sources here that works ok)
tends to be quite slow (enough so as to be noticable even at 1200
baud), there is no real reason why the DES routines have to be run in
real time. Why not use a DES-generated random sequence of bytes to
XOR against the data? The XOR values can be generated using, say, the
session key as the seed, and can be computed before the data is
available against which it is to be XOR'ed. The random number
generation could even be done in a subprocess, if CPU time is still
the problem. (Another help would be getting a better compiler for the
VAX -- due to some oversight, the des.c code is maybe half as fast on
the vax as it could be.)
The "random" number generation could be done by taking a seed and
repeatedly putting it through encryption (with the known key) and
using one byte of the result each time. I myself don't know quite
enough about DES to know how good this is, or if we could get away
with using more bytes of the result...
This wouldn't work so well for batch-type data transfers (though it
might make a small difference), but should be useful for user login
sessions, where a lot of idle time is wasted waiting for the user...
Comments & opinions?
_kr
--[0386]--
\f
[0387] daemon@TELECOM.MIT.EDU Kerberos 06/05/88 17:52 (26 lines)
Subject: faster encrypted rlogin
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: raeburn@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ken Raeburn's message of Sun, 5 Jun 88 16:21:42 EDT <8806052021.AA27194@BINKLEY.MIT.EDU>
Reply-To: chariot@ATHENA.MIT.EDU
Well, the scheme you describe for generating random numbers is
quite close to one of the schemes used in cryptography to generate
poly-perfect random number generators. (A poly-perfect random number
generator is a generator who's output is indistishable from a truely
random sequence in polynomial time) The difference is that cryptography
replaces the DES function with a number theory function (RSA for example
although it is slower than some alternates) that we have reason to
believe is not invertable in polynomial time. It can be proved that if
the function used is indeed not invertable in polynomial time, then a
poly-perfect random number generator will result.
Unfortunely, since very little is known about DES mathamatically
at the moment, it is very hard to say if it is not invertable in
polynomial time. None the less, I think that this method is reasonably
secure compared to the original method. Anyone with the resources to
break this method is almost certain to be able to break the original
method as well. This is only my opinion of course, through....
- Mark Lillibridge
--[0387]--
\f
[0388] daemon@TELECOM.MIT.EDU Kerberos 06/06/88 15:16 (18 lines)
Subject: Re: faster encrypted rlogin
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Ken and Jeff's suggestion sounds like a variation on a Vernam cipher,
or one-time-pad. A true random bit stream used as the XOR is uncrackable,
if used only once, and is used for the highest security level communications.
So the question is to make sure you get a good pseudo-random stream from
the DES seed, and don't reuse it. The reuse is a problem with Kerberos,
since the Session key is valid for some considerable time -- actually
can be multiple sessions.
You could use the DES output feedback (OFB) mode to produce the bit stream,
or even better, according to our crypto guru, just use a counter that
doesn't wrap, e.g. >=32 bits, and encrypt the counter.
Let me know how it works out.
Steve.
--[0388]--
\f
[0389] daemon@TELECOM.MIT.EDU Kerberos 06/06/88 18:29 (18 lines)
Subject: Re: faster encrypted rlogin
From: Mike Kazar <kazar+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8806052021.AA27194@BINKLEY.MIT.EDU>
Your message doesn't specify what data you are encrypting with your DES/XOR
scheme, so I'm not sure how important the attack I'll describe here is.
However, you should note that XOR-based encryption schemes, while not
vulnerable to decipherment, are quite vulnerable to tampering in an environment
where the cleartext is known.
So, for instance, if I have a ticket authenticating me as "bogon", and it is
encrypted via your scheme (using DES/XOR with these quasi-random numbers), then
if I can find the ticket in the cleartext (which should be easy, given the
sources), I can change the ticket to authenticate me as "kazar" instead of
"bogon" by XORing the ticket with ("kazar" XOR "bogon").
Of course, as I said, above, if you're encrypting data that you don't mind
being tampered with invisibly, then this objection doesn't matter.
--[0389]--
\f
[0390] daemon@TELECOM.MIT.EDU Kerberos 06/06/88 19:57 (48 lines)
Subject: Re: faster encrypted rlogin
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar's message of Mon, 6 Jun 88 18:21:21 -0400 (EDT),
Date: Mon, 6 Jun 88 18:21:21 -0400 (EDT)
From: Mike Kazar <kazar+@andrew.cmu.edu>
So, for instance, if I have a ticket authenticating me as "bogon", and it is
encrypted via your scheme (using DES/XOR with these quasi-random
numbers), then if I can find the ticket in the cleartext (which
should be easy, given the sources), I can change the ticket to
authenticate me as "kazar" instead of "bogon" by XORing the ticket
with ("kazar" XOR "bogon").
I don't think this attack would work quite as described, but there is
some possible risk here. Remember, we aren't using XOR for the
authentication encryption, just for later data. The
authenticator/ticket itself would be DES-encrypted such that only the
intended receiver could decrypt it. An XOR on this data would produce
meaningless garbage.
However, a known sequence of data could be tampered with through the
attack you describe, but only that portion for which the cleartext
(and position in the data stream) is known, but this isn't difficult.
Hmm...perhaps a randomly-generated (and constantly changing)
translation table, with offsets transmitted? It wouldn't need to be
too sophisticated, just something that couldn't be reversed (and used
in the forward direction) with a known cleartext. Perhaps using two
numbers to generate the table; for example:
Use #1 for the character \000 translates to.
Use #2 as an offset into a table of the first N numbers relatively
prime to 256, and use it as an offset to get the consecutive
numbers in the translate table. (I.e., \001 maps to (#1 + #2) mod
256, \002 maps to (#1 + 2 * #2) mod 256, etc.)
There are simpler mathematical methods for getting the results in both
directions here, but I think this provides a means by which we'd be
safe sending data without fear of eavesdropping or tampering, since in
order to substitute a (known) second value, the second random byte
would have to be known.
Would we be safe in taking two bytes of the encryption output for the
random number sequence, or should it require two passes? Doing the
latter would slow it down, but we can see how it compares against
realtime encryption....
--[0390]--
\f
[0391] daemon@TELECOM.MIT.EDU Kerberos 06/07/88 14:41 (33 lines)
Subject: Re: Integrity
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
The Kerberos tickets are integrity protected, so attempts at modifying
them will be detected via causing invalid values for some/all of the
fields. In this case, the integrity protection is provided by using a
modified cipher-block-chaining modes of DES with the characteristic that
modifying a single bit of ciphertext will cause about 50% of all the
subsequent cleartext bits in the message to change. Then by placing
fields with constraints on their values, such as a timestamp or a constant,
at the end of the message, modification attempts will cause invalid field
values.
If you want to provide integrity protection for rlogin, you will have to
use some integrity mechanism, for example the one used for tickets. But
it is harder to integrate that with a character by character operation,
and it is not obvious how it interacts with the DES generated random
bit stream used for the XOR. DES has an integrity checksum mode, whose
exact name I forgot at the moment, but that requires a separate pass crypto
pass over the data, which is why we picked the technique described above for
the tickets -- no extra crypto.
A basic principle of providing integrity checks is to provide a redundant
copy of the data, usually in the form of a checksum, etc., and include that
in the data stream to be encrypted. Then it is virtually impossible to
modify both the data and its redundant copy in a consistent fashion, as long
as the checksum technique is well chosen. On decryption, the receiver
decrypts, then recomputes the checksum over the cleartext and compares
the computed value to the received value.
This is an interesting problem. Have fun.
Steve
--[0391]--
\f
[0392] daemon@TELECOM.MIT.EDU Kerberos 06/13/88 14:10 (62 lines)
Subject: Re: ksu (really ticket lifetimes)
From: Jon Rochlis <jon@BITSY.MIT.EDU>
To: <qjb@ATHENA.MIT.EDU>
Cc: steiner@ATHENA.MIT.EDU, watchmakers@ATHENA.MIT.EDU,
In-Reply-To: Emanuel 'Jay' Berkenbilt's message of Mon, 13 Jun 88 11:20:50 EDT,
From: <qjb@ATHENA.MIT.EDU>
Date: Mon, 13 Jun 88 11:20:50 EDT
Why do kerberos tickets obtained "automatically" while ksu'ed only last for
ten minutes? This is rather inconvenient... Is there some deep security
reason? Is there any way to vary this?
This really belongs on "kerberos", not "watchmakers". The ten minute
lifetime is a feature. You can get longer-lasting tickets by using
"kinit -i" (or with the new kerberos stuff "kinit qjb.root") or by
making your own version of ksu (which you should only be using on a
workstation BTW, not on a server unless you are on the console or
otherwise have a secure path over which to type your root instance
password).
ksu specifically asks for ten-minute tickets so if you spaz and forget
about those tickets no harm will probably be done since they expire so
quickly. If you forget to do a kdestroy (exiting the ksu shell won't
do that for you!) this is a big win. The same rational is employed in
using a separate root instance as well. Your null instance tickets
are less important than your root instance tickets (not because of the
name "root" but rather because your root instance appears in access
control lists that lets you unix login as root for a given server).
Perhaps a user should be able to vary the life of his tickets. It is not
uncommon for a user to say something like, "I have a program that writes to
my nfs locker, and it is going to run for ten hours. I want to put up
the screensaver and go away. Can I do that?"
Writing to the nfs locker is a different issue. At the current time
mappings from uid,client to uid,nfs-server don't go away until the
locker is detached (or the server crashes). It is only when
establishing the mapping (at attach/mount time) that you need
non-expired kerberos tickets.
However, you can easily imagine other services who require valid
tickets as you suggest. I guess the real issue is the user interface.
At the moment how long your tickets last if a function of what program
did the get_in_tkt call and what it filled in for a "lifetime".
Perhaps what you're looking for is a -lifetime argument for kinit (or
login!).
In anycase, kerberos ticket lifetimes range between 0 and 255 and are
in units of five minutes, so the longest a ticket can last is 255 * 5
= 21.25 hours ... There have been some bugs found recently in
lifetime processing so we want to look carefully at this whole area (the
so-called "supertickets" on big-endian machines) and reports that
request initial tickets with a lifetime if -1 (i.e. 255) works
[tickets have a max lifetime in the database of eight hours, and any
new ticket is supposed to have a lifetime of the min of database
lifetime and the TGT used].
Some thought should also be given to the user-interface side of
notifying a user that tickets have expired.
-- Jon
--[0392]--
\f
[0393] daemon@TELECOM.MIT.EDU Kerberos 06/14/88 00:13 (19 lines)
Subject: "Postdated" tickets?
From: Zalman Stern <zs01+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
Is it possible to ask Kerberos for a ticket that is valid between two times in
the future? That is, good from say 10 hours from now until 20 hours from now?
If not, are there any inherent security problems in doing this?
I think it should be possible to exchange the times the ticket is valid for
over an authenticated connection so snoops wouldn't even know when the ticket
can be used. This might increase security slightly.
The reason I ask is because I have an idea for an at(1) like batch queue
program that could use postdated tickets to implement an authenticated file
service connection.
Sincerely,
Zalman Stern
Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890
--[0393]--
\f
[0394] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 11:38 (9 lines)
Subject: Re: NFS security
From: Jim Evins <evins@NRL-RADAR.ARPA>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: Sun-Spots's message of Sun, 19 Jun 88 21:07:19 CDT
Could you please send me more information about the Kerberos
authentication system, mentioned by treese@athena.mit.edu in the
Sun-spots mail digest. Thanks.
-Jim Evins <evins@nrl-radar.arpa>
--[0394]--
\f
[0395] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 14:15 (9 lines)
Subject: Kerberos system
From: dean@WRATH.CS.CORNELL.EDU (Dean Krafft)
To: kerberos@ATHENA.MIT.EDU
I'm interested in information about the Kerberos authentication system.
How should I proceed?
Dean Krafft
Computer Science Dept.
Cornell University
dean@gvax.cs.cornell.edu
--[0395]--
\f
[0396] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 14:26 (9 lines)
Subject: (ip_addr,uid) -> uid
From: bks@OKEEFFE.BERKELEY.EDU (Brian K. Shiratsuki)
To: kerberos@ATHENA.MIT.EDU
would you please send information on the kerberors authentication
system.
TNX,
brian
--[0396]--
\f
[0397] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 15:37 (11 lines)
Subject: anyone beta testing?
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Beta testers, are you out there? Send news. Have
you been able to build/install/use Kerberos?
Jennifer
P.S. Sorry for the inquiries about Kerberos that have
been appearing on this mail list. Someone seems
to have given out a pointer to the wrong mail list.
--[0397]--
\f
[0398] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 18:00 (45 lines)
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22592; Tue, 21 Jun 88 17:43:08 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08261; Tue, 21 Jun 88 17:42:34 EDT
Received: from tachyon by atom ; Tue, 21 Jun 88 14:42:19 pdt
To: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Subject: Re: anyone beta testing?
X-Mailer: mh6.5
In-Reply-To: Your message of Tue, 21 Jun 88 15:31:26 -0400.
<8806211931.AA10004@BACH.MIT.EDU>
Date: Tue, 21 Jun 88 14:42:14 PDT
Message-Id: <253.582932534@atom>
From: Your Name Here <ranous@atom.hpl.hp.com>
I'm working for Norm Kincl here at HP, and I'm porting kerberos to HP-UX.
I only started last week, and have been mainly getting used to HP equipment,
so I haven't had a lot of time to work on it.
I've just finished making the dependencies on the source last week. The
HP-UX cc doesn't support the -M option, so I had to port the 4.3 cpp and
convince cc to use it. Also, I had to wait for the op system to get
upgraded to a new version that supports file names longer than 14
characters. You might want to consider making the long names shorter so
others trying to port to SYS V machines won't have to go to the trouble.
Also it seems that programs compiled and run out of make need to exit(0)
explictly with the SYS V make, or it kills the make. I had to add that to
those programs that make the include files in the make depend step in the
des library.
I've started compiling real code now, and have run into a few problems, but
I haven't had a real change to check things out yet. I'm at Usenix for the
week, so I'll won't find much more out until next week. I'll let you know
about any more problems.
Alex Ranous
ranous@hplabs.hp.com
------- End of Forwarded Message
--[0398]--
\f
[0399] daemon@TELECOM.MIT.EDU Kerberos 06/21/88 19:34 (13 lines)
Subject: NFS security (kerberos)
From: benjaram@SUN.COM (Raj Benjaram)
To: kerberos@ATHENA.MIT.EDU
I would be very interested to recieve any details you can provide on the
Kerberos authentication system. Thank You.
-Raj Benjaram (sun!rbenjaram)
-Catalyst Technical Support
-Sun Microsystems
-415-336-4564
--[0399]--
\f
[0400] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 10:00 (162 lines)
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
(Please mail to kerberos.mit.edu not just me, for the
benefit of other beta testers. -Jennifer)
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22864; Tue, 21 Jun 88 18:24:04 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08844; Tue, 21 Jun 88 18:23:43 EDT
Received: by uc.msc.umn.edu (5.54/1.14)
id AA19916; Tue, 21 Jun 88 17:21:27 CDT
Date: Tue, 21 Jun 88 17:21:27 CDT
From: "Stuart Levy" <slevy@uc.msc.umn.edu>
Message-Id: <8806212221.AA19916@uc.msc.umn.edu>
To: steiner@ATHENA.MIT.EDU
Subject: Re: anyone beta testing?
I haven't installed a server nor applications yet but did compile most things.
Some changes were needed to accommodate SUNs.
include/osconf.h
Couldn't find any documentation on how to add configuration information
for new kinds of machines, so inserted #ifdef sun here.
include/conf-bsd-m68k.h
The #ifdef sun in osconf.h includes this.
(This is a new file, so I did diff -c /dev/null.)
bsd/Makefile: Sun 3.3 (at least) <sys/param.h> doesn't define MAXHOSTNAMELEN
so I put this in the Makefile. I'm not sure where this kind of hack
really belongs; maybe in <osconf.h>? In that case kcmd.c would need
to include it.
bsd/rlogin.c
There's an #ifdef sun related to handling the window size structure
but it doesn't work; the distributed rlogin.c explicitly declares
"struct winsize" which conflicts with the declaration of the same
structure in Sun's <sys/ioctl.h>.
bsd/rshd.c
bsd/rlogind.c
appl/sample_server.c
Minor changes to accommodate the difference between 4.2 and 4.3
syslog(3).
Before we can actually use this on a pre-4.0 SUN, I need to integrate the
Kerberos login.c into the 4.2 environment (different ttys format, no
getttyent(), etc.). This shouldn't be too big a deal but I haven't gotten
to it yet.
Here are diffs for the changes made so far.
*** /tmp/,RCSt1a02544 Tue Jun 21 16:52:52 1988
- --- osconf.h Mon Jun 6 19:51:55 1988
***************
*** 18,22 ****
- --- 18,26 ----
#else
#ifdef ibm032
#include "conf-bsd-ibm032.h"
+ #else
+ #ifdef sun
+ #include "conf-bsd-m68k.h"
+ #endif /* sun */
#endif /* ibm032 */
#endif /* not vax */
*** /dev/null Tue Jun 21 17:00:18 1988
- --- conf-bsd-m68k.h Mon Jun 6 19:55:32 1988
***************
*** 0 ****
- --- 1,19 ----
+ /*
+ * $Source: /mit/kerberos/src/include/RCS/conf-bsdvax.h,v $
+ * $Author: steiner $
+ * $Header: conf-bsdvax.h,v 1.3 88/02/25 14:44:06 steiner Exp $
+ *
+ * Copyright 1988 by the Massachusetts Institute of Technology.
+ *
+ * For copying and distribution information, please see the file
+ * <mit-copyright.h>.
+ *
+ * Machine-type definitions: 68000 with BSD Unix, e.g. SUN
+ */
+
+ #include <mit-copyright.h>
+
+ #define BITS32
+ #define BIG
+ #define MSBFIRST
+ #define BSDUNIX
*** /tmp/,RCSt1a02520 Tue Jun 21 16:52:05 1988
- --- rlogin.c Mon Jun 6 22:02:12 1988
***************
*** 83,92 ****
#endif
#ifdef sun
struct ttysize winsize;
- - struct winsize {
- - unsigned short ws_row, ws_col;
- - unsigned short ws_xpixel, ws_ypixel;
- - };
#else sun
struct winsize winsize;
#endif sun
- --- 83,88 ----
*** /tmp/,RCSt1a02525 Tue Jun 21 16:52:07 1988
- --- rlogind.c Mon Jun 6 22:09:32 1988
***************
*** 48,53 ****
- --- 48,57 ----
#include <syslog.h>
#include <strings.h>
+ #ifndef LOG_AUTH
+ # define LOG_AUTH 0
+ #endif LOG_AUTH
+
#ifdef KERBEROS
#include <sys/param.h>
#include <utmp.h>
*** /tmp/,RCSt1a02530 Tue Jun 21 16:52:09 1988
- --- rshd.c Mon Jun 6 22:06:08 1988
***************
*** 78,84 ****
- --- 78,88 ----
#ifdef KERBEROS
ksh = (strcmp(*argv,"kshd")==0);
#endif KERBEROS
+ #if defined(LOG_ODELAY) && defined(LOG_DAEMON)
openlog("rsh", LOG_PID | LOG_ODELAY, LOG_DAEMON);
+ #else /* probably 4.2BSD */
+ openlog("rsh", LOG_PID);
+ #endif /* 4.2BSD */
fromlen = sizeof (from);
if (getpeername(0, &from, &fromlen) < 0) {
fprintf(stderr, "%s: ", argv[0]);
*** /tmp/,RCSt1a02560 Tue Jun 21 16:53:31 1988
- --- sample_server.c Mon Jun 6 21:37:08 1988
***************
*** 49,55 ****
- --- 49,59 ----
/* open a log connection */
+ #ifdef LOG_DAEMON
openlog("sample_server", 0, LOG_DAEMON);
+ #else !LOG_DAEMON
+ openlog("sample_server", 0);
+ #endif !LOG_DAEMON
/*
* To verify authenticity, we need to know the address of the
------- End of Forwarded Message
--[0400]--
\f
[0401] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 12:15 (9 lines)
Subject: wrong address
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
> (Please mail to kerberos.mit.edu not just me, for the
> benefit of other beta testers. -Jennifer)
I mean, "kerberos@athena.mit.edu".
Jennifer
--[0401]--
\f
[0402] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 18:39 (8 lines)
Subject: kerberos
From: mcgrew@TOPAZ.RUTGERS.EDU (Charles)
To: kerberos@ATHENA.MIT.EDU
Please send me info about kerberos..
Thanks,
Charles
--[0402]--
\f
[0403] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 18:41 (24 lines)
Subject: information request
From: "Alan Bleier, Brigham and Women's Dept. of Radiology"
To: kerberos@ATHENA.MIT.EDU
X-Vms-To: MAILER%"kerberos@athena.mit.edu",BLEIER
In a recent posting I read in Sun-Spots, Win Treese mentioned that more
information is available from you about the Kerberos authentication system.
I plan and manage the research network in the Radiology Department at
Brigham and Women's Hospital, and we are naturally concerned about security
for research data and patient information. As you can see, we do not have
a direct connection via ethernet to the internet, but we may have a bridge
from our network to Harvard's ethernet soon.
Please send me any references, writeups, citations, etc. to the above address
on HUSC3, or to
Alan Bleier, PhD
Brigham and Women's Hospital
Department of Radiology
75 Francis St.
Boston, MA 02130
phone: 732-7986
Thanks! (oops -- the zip code should be 02115)
--[0403]--
\f
[0404] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 19:31 (12 lines)
From: mcvax!minster.york.ac.uk!forsyth@UUNET.UU.NET
To: kerberos <athena.mit.edu!kerberos@ukc.ac.uk>
Please tell me about yourself (kerberos).
I've recently read some amusing articles in USENIX proceedings and a Sun
glossy, written by someone at Sun who claims to be talking about ``security''.
I don't think this can be true, though, since he then says I have to put
my root password decrypted in a secret file (and/or have people queue up
at all our discless workstations to allow setuid files to work).
I know that you publish your root passwords, but also have the wit to make
this not matter. Anyhow, I'd like to know more.
--[0404]--
\f
[0405] daemon@TELECOM.MIT.EDU Kerberos 06/22/88 21:19 (40 lines)
Subject: information
From: John Iarocci <iarocci@ENEEVAX.UMD.EDU>
To: kerberos@ATHENA.MIT.EDU
We've been looking around for an authentication system to replace Yellow Pages.
There are some serious problems with YP and there are some nice features. We
are junking the `hosts' yellow page map and running BIND. Some of the other
maps can be distributed via rdist. This leaves us with access to machines.
We are interested in security both in the account sense and the remote mount
sense. One of the features of Yellow Pages that we would rather like to keep
is the concept of `netgroups'. By using this mechanism, I can have a password
file that looks like this:
root:OaWYiXw/YZLCU:0:10:Eneevax,J-0313,4546849,4548798:/:/bin/csh
daemon:*:1:1:The devil himself,,,,:/:
bin:dWAkTAiH9ZE2s:3:10:System File Owner,,,,:/bin:/bin/csh
news:LD5fc4QzrJ3Ug:7:12:The News System,,,,:/usr/spool/news:/bin/csh
adm:q6J3eGswXEhH2:8:10:Accounts Administrator,,,,:/usr/adm:/bin/csh
mdqs:*:11:10:The Mdqs System,,,,:/usr/lib/mdqs:/bin/csh
guest:*:51:17:The Guest Account--can't log in,,,,:/usr/tmp:/bin/csh
+@Staff::0:0:::
+@EE_Department::0:0:::
+@All::80:10::/usr/local/restrict:/bin/sh
This lets the groups `Staff' and `EE_Department' on the machine in question,
and restricts the group `All' (albeit, in a nonsecure manner).
Please forward any information concerning your kerberos system.
Thank you,
John Iarocci
iarocci@eneevax.umd.edu
College of Engineering
University of Maryland
College Park Campus
College Park, MD 20742
(301) 454 - 1526 (6849)
--[0405]--
\f
[0406] daemon@TELECOM.MIT.EDU Kerberos 06/23/88 16:02 (13 lines)
Subject: Re: NFS security
From: awhite%fang@XENURUS.GOULD.COM (Arden White)
To: kerberos@ATHENA.MIT.EDU
Please send me more info on Kerberos authentication system.
Thanks,
Arden
------------------------------------------------------------
Arden White o Gould CSD o Urbana, IL
(217) 384-8705
awhite@Gould.com uiucdcs!ccvaxa!awhite
------------------------------------------------------------
--[0406]--
\f
[0407] daemon@TELECOM.MIT.EDU Kerberos 06/24/88 11:07 (20 lines)
Subject: kerberos
From: prlb2!jjq@UUNET.UU.NET (Jean-Jac. Quisquater)
To: kerberos@ATHENA.MIT.EDU
I'm interested into more information about the Kerberos
authentication system.
Many thanks,
Best regards,
Jean-Jacques Quisquater,
SMAIL:
Philips Research Laboratory Brussels
Avenue Van Becelaere, 2; Box 8; B-1170 Brussels, Belgium.
TELEFAX: 32-2-674.22.99
UUCP:
World: ...{philabs,uunet,munnari,mcvax}!prlb2!jjq
INTERNET:
na.quisquater@score.stanford.edu
--[0407]--
\f
[0408] daemon@TELECOM.MIT.EDU Kerberos 06/24/88 14:01 (25 lines)
Subject: ticket file access
From: mar@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
I have run into an unfortunate interaction with the new ticket file
access checks and system daemons that use kerberos.
If someone kills a daemon that was started by /etc/rc and starts it by
hand, that daemon inherits their KRBTKFILE environment variable. But
that points to a file owned by the user, not root, and the daemon will
run as root and be unable to store tickets there. This causes errors
like: "Can't access tkt file: /tmp/tkt_ttyp1" from the daemon.
The only workaround I know of right now is to explicitly unset or
change the KRBTKFILE environment variable before invoking the daemon.
Do we want to have to continue this workaround, or add code to every
system daemon to handle this case, or change the kerberos library?
This is further complicated by the fact that there are no C library
routines for setenv() or unsetenv(). This means that more than a
couple of lines of code need to be added to a program to fix this. I
would propose that either the library be changed back to allow root to
write to people's ticket files, or a routine be added to the kerberos
library that will change the ticket file location (i.e. do a
setenv(KRBTKFILE, [location])).
-Mark
--[0408]--
\f
[0409] daemon@TELECOM.MIT.EDU Kerberos 06/24/88 14:20 (24 lines)
Subject: Re: ticket file access
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: <mar@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mark A. Rosenstein's message of Fri, 24 Jun 88 13:54:17 EDT,
From: <mar@ATHENA.MIT.EDU>
Date: Fri, 24 Jun 88 13:54:17 EDT
This is further complicated by the fact that there are no C library
routines for setenv() or unsetenv().
Actually, the C libraries that Athena is running now (in version 6.0)
do have these routines. However, this isn't sufficiently portable,
and it's sorta kludgy.
I
would propose that either the library be changed back to allow root to
write to people's ticket files, or a routine be added to the kerberos
library that will change the ticket file location (i.e. do a
setenv(KRBTKFILE, [location])).
The first is probably okay as long as it doesn't include depositing
new ticket-granting tickets there. Regardless of this, I would like
to see the second done as well.
--[0409]--
\f
[0410] daemon@TELECOM.MIT.EDU Kerberos 06/24/88 14:32 (17 lines)
Subject: Re: ticket file access
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mark Rosenstein's message, [0408]
All that is required to change the library's idea of where the tickets
should live is to define a function tkt_string(). An example from the
Zephyr server:
static char tkt_file[] = ZEPHYR_TKFILE;
/* Hack to replace the kerberos library's idea of the ticket file with
our idea */
char *
tkt_string()
{
return(tkt_file);
}
--[0410]--
\f
[0411] daemon@TELECOM.MIT.EDU Kerberos 06/25/88 01:34 (12 lines)
Subject: Authentication Schemes
From: malik@GONDOR.CS.PSU.EDU (Sohail Malik)
To: kerberos@ATHENA.MIT.EDU
If I am interested in a thorough knowledge of the way the Kerberos
authentication system works, which documents should I read to get
right up to date?
Thanks for any help you can provide,
-Sohail
malik@gondor.psu.edu
miy@psuvm.bitnet
--[0411]--
\f
[0412] daemon@TELECOM.MIT.EDU Kerberos 06/27/88 08:53 (9 lines)
Subject: info on kerberos authentication wanted
From: Karl Kleine -- FZI Karlsruhe <kleine%ira.uka.de@RELAY.CS.NET>
To: kerberos@ATHENA.MIT.EDU
we would like to get detailled information on kerberos (per email,
mit reports, info on software availability, incl. university site licence).
Karl Kleine, Forschungszentrum Informatik an der Universitaet Karlsruhe (FZI),
Haid-und-Neu-Str. 10-14, D-7500 Karlsruhe, West Germany
kleine@uka.uucp, {...}!unido!uka!kleine, kleine@germany.csnet, +49-721-690639
--[0412]--
\f
[0413] daemon@TELECOM.MIT.EDU Kerberos 06/27/88 16:07 (28 lines)
Subject: woe the (poor) commercial site
From: Jordan Hayes <jordan@ADS.COM>
To: kerberos@ATHENA.MIT.EDU
From: warrens@Sun.COM (Warren A. Smith)
Date: Mon, 27 Jun 88 11:41:46 PDT
To: jordan@ads.com
Subject: Re: Kerberos modifications to NFS
Cc: kc%sunned@Sun.COM
The changes for Kerberos involve source level changes. We
don't support object changes for Kerberos at this time.
To get a commercial NFS source license (which gets you a
reference port of NFS to the Berkeley 4.3 kernel) contact K.C.
Chan (kcchan@sun.com) at 415/336-2184. This license costs
$25,000 and is a full implementation of 4.3BSD with NFS, Yellow
Pages, RPC/XDR, REX, Lock Manager, Status Monitor. K.C. can
tell you about university licensing.
Well, I don't have $25,000 for a source license, but I still want to
run this code. Do I have any other options? Why can't we get
objects? Anyone wanna slip me some .o's? (i assume this doesn't break
any license agreements, but correct me if i'm wrong) ... seems to me
that .o's aren't an unreasonable request ...
Also, anybody using Kerberos on a 4.0 machine?
/jordan
--[0413]--
\f
[0414] daemon@TELECOM.MIT.EDU Kerberos 06/27/88 18:39 (11 lines)
Subject: authentication ...
From: suneast!db@SUN.COM (David Brownell)
To: kerberos@ATHENA.MIT.EDU
Can you direct me to a few places that Kerberos is published? I'd like to
read about it.
Also in general more Athena stuff: do you have a collection of papers? Or should
I go to some library on campus?
- Dave Brownell
Sun ECD Networking
--[0414]--
\f
[0415] daemon@TELECOM.MIT.EDU Kerberos 06/28/88 04:59 (26 lines)
Subject: the Kerberos authentication system
From: Jonas Dahl`n <jonas%holtec.se@RELAY.CS.NET>
To: kerberos@ATHENA.MIT.EDU
Read about Kerberos in SUN-SPOTS.
>More information about the Kerberos authentication system can be obtained
>by mailing to kerberos@athena.mit.edu.
Please send more info.
Yours,
jonas
--
Jonas Dahlen ! E-mail:
Holistic Technology AB (Holtec) ! jonas@holtec.se
Gr|na gatan 59 ! ..!mcvax!enea!chalmers!holtec!jonas
S-414 54 Gothenburg !
Sweden ! tel: +46 31 420370
! telfax:+46 31 247456
! telex: 20182 Telegot S, Holtec
-----------------------------------------------------------------------------
My opinions are my own, and do not reflect official policy, either explicit
or implied, of the Holistic Technology AB.
--[0415]--
\f
[0416] daemon@TELECOM.MIT.EDU Kerberos 06/28/88 14:21 (5 lines)
From: FEN@XX.LCS.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
May I have the top level architectural description?
Tnx.
--[0416]--
\f
[0417] daemon@TELECOM.MIT.EDU Kerberos 06/30/88 01:11 (15 lines)
Subject: Authentication system information requested
From: ihnp4!drutx!drusp!fidder@EDDIE.MIT.EDU
To: drutx!ihnp4!kerberos@ATHENA.MIT.EDU
Hi,
If you have a standard burb you send out on information on you
authentication system (being used by the NFS id mapping service) I would
be interested in see a copy.
Thanks,
Ted Fidder
ihnp4!drutx!fidder
--[0417]--
\f
[0418] daemon@TELECOM.MIT.EDU Kerberos 06/30/88 23:50 (37 lines)
Subject: <unspecified>
From: G.Eustace%massey.ac.nz@RELAY.CS.NET
To: kerberos@ATHENA.MIT.EDU
X-Vms-To: IN%"kerberos@ATHENA.MIT.EDU"
Reply-to: CSnet or ACSnet:G.Eustace@massey.ac.nz
or: INTERnet:G.Eustace%massey.ac.nz@relay.cs.net
or: JANET/Greybook: G.Eustace@NZ.AC.MASSEY
=======================================================================
Subject: Problems with NFS environments.
We are currently trying to set up a network with about 500 pcs, and
some 5 servers. I am having difficulty trying to work out how to cope
with the problems of user authentication, allocation of user ids etc.
The problem is that we anticipate a user community of approx. 1200
people to be using the 500 workstations, so each more station will have
multiple users and each user can use multiple stations.
These are some more concerns:
1. The NFS export lists are on the basis of host, not user, which
presents security difficulties.
2. What sort of user names does one use, we would like to have J.Smith
etc, but unix then thinks you are are caps only teletype!
3. What is going to happen to interactive logins that have to search a
passwd file that has thousands of entries.
The comments I have seen regarding kerberos seem to suggest that some
of these problems have already been addressed.
Any help or info you can send would be much appreciated.
-----------------------------------------------------------------------
Glen Eustace, Software Mgr, Comp.Cntr, Massey Uni, Palmerston Nth, N.Z.
uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!glen DTE: 530163000005
Janet/Greybook: G.Eustace@nz.ac.massey Phone: +64 63 69099 x7440
CSnet/ACSnet/Internet: G.Eustace@massey.ac.nz New Zealand = GMT+12
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--[0418]--
\f
[0419] daemon@TELECOM.MIT.EDU Kerberos 07/01/88 14:38 (31 lines)
Subject: using Kerberos with AFS, some comments
From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
I've been looking at making the Andrew file system authentication system
"compatible" with the Kerberos authentication system. The most fundamental
level of compatibility we can aim for is compatibility at the ticket level: our
file system has to understand Kerberos-generated tickets, otherwise no other
level of compatibility even makes sense.
The only problem we have in using Kerberos-format tickets in our system is that
the lifetime field simply does not allow us to represent long expiration times.
We have been running the Andrew file system using tickets (of our own design)
that expire in 25 hours, and have been repeatedly criticized by our users on
the grounds that this value is too small. We've promised to address that
problem in our "next" system, which we hope to make Kerberos-based.
I believe that it is reasonable, in certain restricted applications, for ticket
lifetimes to be as long as two weeks, rather than the 21+ hours in the present
format. Note that we're *not* arguing for the default ticket timeout value to
be weeks, simply that for certain applications, long values make sense.
I would therefore suggest/request/whatever that the Kerberos ticket lifetime
field be increased from its current 8 bits (of 5 minute resolution) to 16 bits
(of unsigned 5 minute resolution), increasing the maximum ticket lifetime
representable to about 227 days.
I'll send more comments after the July 4 weekend, but I believe this to be our
only make-or-break problem.
Mike Kazar
(kazar+@andrew.cmu.edu)
--[0419]--
\f
[0420] daemon@TELECOM.MIT.EDU Kerberos 07/01/88 15:29 (27 lines)
Subject: short Kerberos ticket times
From: fin@UF.MSC.UMN.EDU (Craig Finseth)
To: kazar+@ANDREW.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar's message of Fri, 1 Jul 88 14:23:52 -0400 (EDT) <cWmxWsy00Uk-M250V2@andrew.cmu.edu>
We are wondering about the short times ourselves. In our environment,
it is not unusual to have a single "batch" job (i.e., detached shell
script) run for over two weeks. This job will have been
checkpoint/restarted several times during its lifetime. In some
cases, the job may be held for over a day before it is restarted.
Is it reasonable to ask that a researcher log in once each day so that
their job doesn't stop?
We checkpoint/restart jobs during system maintenance time (like 2 to 5
AM). For jobs that started before 8 AM the previous day, do we have
to tell our researchers "sorry, but you have to get up an log in in
order to make use of the early morning time?"
We haven't gotten far enough to actually encounter this problem in
real life: we are just "looking for trouble" that we may encounter
down the road.
Any ideas?
Craig A. Finseth fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc. (612) 624-3375
--[0420]--
\f
[0421] daemon@TELECOM.MIT.EDU Kerberos 07/04/88 17:20 (39 lines)
Subject: <unspecified>
From: G.Eustace%massey.ac.nz@RELAY.CS.NET
To: kerberos@ATHENA.MIT.EDU
X-Vms-To: IN%"kerberos@ATHENA.MIT.EDU"
Reply-to: CSnet or ACSnet:G.Eustace@massey.ac.nz
or: INTERnet:G.Eustace%massey.ac.nz@relay.cs.net
or: JANET/Greybook: G.Eustace@NZ.AC.MASSEY
=======================================================================
Subject: Problems with setting up and administrating NFS environments.
We are currently trying to set up a network with about 500 pcs, and
some 5 servers. I am having difficulty trying to work out how to cope
with the problems of user authentication, allocation of user ids etc.
The problem is that we anticipate a user community of approx. 1200
people to be using the 500 workstations, so each more station will have
multiple users and each user can use multiple stations.
These are some more concerns:
1. The NFS export lists are on the basis of host, not user, which
presents security difficulties.
2. What sort of user names does one use, we would like to be able to
have sensible names like J.Smith, W.Fitzgerald etc. but Unix doesn't
like '.'s or names >8 characters, and some versions aren't to keen
on capital letters.
3. What is going to happen to interactive logins that have to search a
passwd file that has thousands of entries.
The comments I have seen regarding kerberos seem to suggest that some
of these problems have already been addressed.
Any help or info you can send would be much appreciated.
-----------------------------------------------------------------------
Glen Eustace, Software Mgr, Comp.Cntr, Massey Uni, Palmerston Nth, N.Z.
uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!glen DTE: 530163000005
Janet/Greybook: G.Eustace@nz.ac.massey Phone: +64 63 69099 x7440
CSnet/ACSnet/Internet: G.Eustace@massey.ac.nz New Zealand = GMT+12
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--[0421]--
\f
[0422] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 11:12 (26 lines)
Subject: short Kerberos ticket times
From: fin@uf.msc.umn.edu (Craig Finseth)
To: kazar+@andrew.cmu.edu, kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar's message of Fri, 1 Jul 88 14:23:52 -0400 (EDT) <cWmxWsy00Uk-M250V2@andrew.cmu.edu>
We are wondering about the short times ourselves. In our environment,
it is not unusual to have a single "batch" job (i.e., detached shell
script) run for over two weeks. This job will have been
checkpoint/restarted several times during its lifetime. In some
cases, the job may be held for over a day before it is restarted.
Is it reasonable to ask that a researcher log in once each day so that
their job doesn't stop?
We checkpoint/restart jobs during system maintenance time (like 2 to 5
AM). For jobs that started before 8 AM the previous day, do we have
to tell our researchers "sorry, but you have to get up an log in in
order to make use of the early morning time?"
We haven't gotten far enough to actually encounter this problem in
real life: we are just "looking for trouble" that we may encounter
down the road.
Any ideas?
Craig A. Finseth fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc. (612) 624-3375
--[0422]--
\f
[0423] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 16:15 (16 lines)
Subject: file server mappings
From: chariot@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Reply-To: chariot@ATHENA.MIT.EDU
I currently implementing authentication for Vice using kerberos.
The question I have is should file server mappings (a mapping is what
tells the server that uid XXX on host YY is really user ZZZ) expire? In
the current athena set up if you log in and work for 8 hours, your
kerberos tickets will expire preventing you from reading your mail and
attaching new filesystems. However, you can still read and write to all
already attached filesystems, including your home directory. The
question is, should your ability to read and write to already existing
filesystems expire when your tickets do? Comments would be great. Note
that this is just a private opinion poll.
- Mark
--[0423]--
\f
[0424] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 18:01 (58 lines)
Subject: Re: Misc Kerberos questions
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
File Server Mappings-
This is a very deep question, way beyond Kerberos per se. It is really
a question of what is the access control model. Most systems (Unix, VMS, etc.)
check access when a file is first opened, but once the file is opened, changing
the protection on the file has no effect on existing clients. Some systems
may check access on EVERY ACCESS.
Kerberos should be consistent with whatever access control model is in use.
For example, if the VICE model is that access is checked on every file open,
then if your Kerberos ticket expires, subsequent open requests should treat
it as just as if the access controls on the file had changed -- the client
can no longer authenticate as a user granted access. But just as in the local
case without Kerberos, once the file has been opened, access may continue.
Now, of course, one can change the existing model to cutoff access to open
files. But then one should logically cutoff access to open files if the
protection on the file is changed while the file is open, such that the
existing client would be excluded from the current access mode.
Short Tickets-
----------------
In the Kerberos design maximum ticket lifetimes were intentionally kept short
to be consistent with the Athena workstation environment and common security
practices. The main concern is that in an open workstation environment like
Athena, the tickets may be exposed on the workstations after the user has
left, either due to forgetting to clean up, or system idiosyncracies. Also
recall that the workstations have no hardware protection for keys or tickets.
So the longer the lifetime, the more exposed the system is for misuse. And,
designed as part of a security system, this is precisely what we were trying
to prevent. There is a second tier of arguments centered around crypto-attacks,
where the general principle is to restrict the amount of data encrypted with
any single key; Kerberos uses the same session key between parties for the
entire lifetime of the ticket. The crypto threat is less important in the
university environment.
Also note that Kerberos does not support any notion of revocating tickets.
Once issued, they are valid until they expire, unless the recipient makes
a conscious decision to reject a particular ticket based on some knowledge
learned from an external channel.
So, while you could extend the maximum lifetime allowed in the ticket, to
do so would weaken the protection environment Kerberos offers, and weaken
the damage control enforced by ticket lifetimes.
I don't feel that it is unreasonable to ask a researcher to login once a
day in order to gain Kerberos' benefits. Alternatively, if the security
of the application is not crucial, don't use Kerberos for it. Nobody
claimed that security is free.
(p.s. the size of encrypted fields within the ticket must be minimized to
minimize the performance cost of encryption.)
Steve
--[0424]--
\f
[0425] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 21:26 (21 lines)
Subject: Re: file server mappings
From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
In-Reply-To: <8807052008.AA11009@VULCAN.MIT.EDU>
The current authentication system at use at CMU cuts off authenticated access
to AFS (aka Vice) on ticket expiration as soon as it discovers the ticket has
expired, i.e. when the cache manager next tries an RPC to the file server.
The file server checks the ticket status cached in its client status entry, on
every RPC, and returns a distinctive error code when the ticket expires. The
cache manager detects this, and switches to an unauthenticated RPC connection
for the remaining operations.
The other possibility would be to only check the expiration time when a ticket
has to be decoded. In general, our user's didn't like that system as much
because it was less predictable: they generally assumed the tickets never
expired, and were surprised when occasionally they did. And, of course, it
leaves you more vulnerable to security problems.
I'd vote for matching the current Vice semantics: stop the accesses as soon as
the tickets expire.
--[0425]--
\f
[0426] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 21:37 (21 lines)
Subject: Re: Misc Kerberos questions
From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In-Reply-To: <8807052151.AA17136@decwrl.dec.com>
The problem with short ticket lifetimes is that our researchers *do* find it
unreasonable to login (more than) once a day to keep their computation running.
And they've told us so. They like to start long batch jobs and walk away,
often for a weekend. Most of them do things like setup cron jobs to
re-authenticate themselves periodically so that they can store their data back
to the file servers.
When they make some mistake in setting up these re-authentication jobs, they do
not blame themselves for their lost efforts, they blame us. And to a certain
extent, they're right. They have physically secure machines and are not really
concerned with a cryptographic attack on their tickets. A ticket expiring in
O(72) hours is exactly the level of security they want.
While I realize that ticket lengths must be minimized to keep encryption costs
down, I think the expiration field was trimmed down just a bit too much in the
original design. An extra byte encrypted in a 60 byte or so ticket shouldn't
really be noticible.
--[0426]--
\f
[0427] daemon@TELECOM.MIT.EDU Kerberos 07/05/88 21:56 (17 lines)
Subject: Re: Misc Kerberos questions
From: "Stuart Levy" <slevy@UC.MSC.UMN.EDU>
To: MILLER%erlang.DEC@DECWRL.DEC.COM, kazar+@ANDREW.CMU.EDU,
Would there be some way to cause file accesses to freeze, rather than abort,
when a ticket for file access or some such thing expired? It would
still be annoying, but much less annoying than just losing a multi-hour
(or day, or week) job. Ticket lifetimes would be much less of an issue.
I'm not sure what the best way to do this would be. At a minimum, file servers
would have to distinguish expired mappings/tickets from ordinary access
control failure and return a different error code.
But then what? Should the client just go and suspend the process?
Sleep for a while and retry? Send a message to a daemon (which could try to
notify the user that the job had gone to sleep)?
Stuart Levy
--[0427]--
\f
[0428] daemon@TELECOM.MIT.EDU Kerberos 07/06/88 07:57 (24 lines)
Subject: Re: RPC for communicating with Kerberos
To: Mike Kazar <kazar+@andrew.cmu.edu>
Cc: kerberos@ATHENA.MIT.EDU, dachurch@ATHENA.MIT.EDU
In-Reply-To: Your message of Tue, 05 Jul 88 22:16:54 -0400.
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Actually the non-idempotent Kerberos operations are done via
a different protocol, which is missing, you're right. It's
being re-written.
The server is called the "admin server" and the clients which
interface with it are "kpasswd" and "kadmin", with the obvious
functionality. In addition, our "register" program talks to
the admin server in order to allocate a user name for a new
user and set the initial password.
Doug Church is designing the new admin server and should have
specs to post soon.
I would like to see some RPC system used for both the admin server and
the authentication server. I believe Bill Sommerfeld is looking at
using Apollo's RPC with Kerberos (Bill?) and it would be interesting
to compare theirs and CMU's.
Jennifer
--[0428]--
\f
[0429] daemon@TELECOM.MIT.EDU Kerberos 07/06/88 12:42 (19 lines)
Subject: NFS Authorization Server
From: "M. D. Parker x2130" <chip!mparker@NOSC.MIL>
To: kerberos@ATHENA.MIT.EDU
Greetings...
I'd be interested in obtaining more information about the Kerberos Authorization
system.
===============================================================================
M. D. Parker ARPANet: chip!mparker@nosc.mil
UNIX Systems Manager UUCP: ...{ucsd,nosc,hp-sdd,crash}!chip!mparker
Phone: (619) 457-2340
USPS: M/A-COM Government Systems, 3033 Science Park Road, San Diego, CA 92121
Disclaimer: Opinions expressed are my own and not necessarily that of
M/A-COM Government Systems Inc.
--[0429]--
\f
[0430] daemon@TELECOM.MIT.EDU Kerberos 07/06/88 13:33 (64 lines)
Subject: re: should mappings expire?
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU, athena-ws@ATHENA.MIT.EDU
Reply-To: chariot@ATHENA.MIT.EDU
> I don't feel that it is unreasonable to ask a researcher to login once a
> day in order to gain Kerberos' benefits. Alternatively, if the security
> of the application is not crucial, don't use Kerberos for it. Nobody
> claimed that security is free.
(from Steve)
Security if used for filesystem authentication, is not optional.
If Athena decides that all filesystem accesses must be authenticated
(this is the current policy), then the researcher must keep himself
authenticated in order to read or write any of his files. Very few
applications will work without some form of file storage. Hence,
security becomes mandatory to every application, not just some. The
choice of whether they want the security at the price of having to log
in once a day has been taken out of the hands of the users.
The way I see it (correct me here if I am wrong) is that
workstations of the Athena/Andrew type get used in two distinct ways.
One is as a public workstation being used by a user to read mail, write
a paper, or play a game. Total usage time is normally less than eight
hours, sometimes as much as 30 hours (we are talking about MIT/CMU
here...) but only with extreme rarity more than 30 hours. Very few
people are going to sit at a terminal with no food/drink for 30 hours
straight. For this usage, requiring the user to reauthenticate every n
hours, n>=8, is not too bad as he is physically present and can take any
needed corrective action.
It is still going to be a fairly big surprise to the user the
first time his tickets expire. This will be particularly bad if the
first time he discovers this is the day he is writting his final paper.
(i.e., spending 30 hours on the computer normally happens only just
before a major project of some sort is due) The Vice system solves this
problem for this group of people fairly well by simply upping the default
ticket lifetime to 25 hours, ensuring that very few students will
encounter expiration at all. The few that do probably fall into the
second class.
The second type is the private workstation in someone's office
or in an area of a lab all of whom's reasearchers trust each other. In
this situation, it is reasonable for someone to want to run a data
collection job while he's on vacation. 72 hours or more is perfectly
reasonable for a private workstation. (i.e., batch jobs over the
weekend) However, Vice does not currently provide (to my knowledge
anyways...) any real means of supporting researchers wishing to do this.
Ironically, the current athena setup does support this. Since in the
current athena setup tickets expire but not mappings, so long as no
services needing tickets need to be used (e.g., to read mail), batch
jobs on private workstations can run forever with no problems.
It would seem to me that the ability to create tickets with any
length and using 25-30 hours as the default ticket lifetime for normal
tickets would solve most of the problems abet at a loss of security.
What would be nice (hint, hint, kerberos developers) is a utility that
would allow you to throw away selective tickets from your ticket file.
This would allow me to kinit -lifetime 72, "attach" my home filesystem,
and then destroy all my tickets except my file server tickets. This
would greatly lower the security risk if I did lose my tickets. This is
basically what the current athena system lets you do now.
- Mark Lillibridge
--[0430]--
\f
[0431] daemon@TELECOM.MIT.EDU Kerberos 07/06/88 16:00 (33 lines)
Subject: Another realm...
From: Doug Alan <nessus@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
Henry told me that I should forward the following message here...
From: Doug Alan <nessus@athena.mit.edu>
To: athena-ws@athena
Date: Wed, 06 Jul 88 03:42:14 EDT
I set up an NFS server, FENCHURCH.MIT.EDU, which is in the kerberos
realm EECS.MIT.EDU. I want to get r/w access to my files on fenchurch
from an Athena workstation. Everything works fine if I change
/etc/krb.conf so that the workstation is in the EECS.MIT.EDU realm,
but I'd rather not have to do this. How do I tell fenchurch that
'nessus@ATHENA.MIT.EDU' is equivalent to 'nessus@EECS.MIT.EDU'? I set
up the '/usr/etc/credential' file as follows, but it doesn't work:
nessus:654:64:844:390:75:64
nessus@ATHENA.MIT.EDU:654:64:844:390:75:64
nobody:32767:9999:74
'nfsid fenchurch map' outputs the following error:
nfsid: Can't find ticket (get_credentials) (for instance
fenchurch realm ATHENA.MIT.EDU)
No UID maps installed
|>oug /\lan
P.S. How it should work, is that I should be able to be
simultaneously authenticated as multiple users in multiple realms, but
I've been told that something similar to what I tried to do above is
what I'll have to settle for, at the moment.
--[0431]--
\f
[0432] daemon@TELECOM.MIT.EDU Kerberos 07/06/88 16:49 (35 lines)
Subject: Re: RPC et al
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Re: Short Ticket Lifetime--
Possible workaround -
It might be possible to tweek the code in a few places that set or read the
the ticket lifetime to change the effective units from 5minutes to some
larger value. This would not involve any protocol change. It wouldn't
interoperate properly with "vanilla" installations.
Re: RPC --
Mike Kazar's first point -- re a duplicate response -- is well
taken. I don't know what the existing code does, but the request and response
both carry the requestor's timestamp, so should always be matched up
appropriately, discarding extraneous responses. Note that the responses are
not quite idempotent, since they will contain different session keys.
The second point is also on target, that is some of the management operations
are not idempotent, and need more than just a raw datagram transport. I don't
know what they currently run on -- I thought it was TCP, which will offer
the right behavior.
An RPC that provides *At-most-once* semantics is one way to address these
issues, but not the only way. You need duplicate suppression and retransmission
at the transport layer to get the right behavior -- TCP could do all this,
or certain request/response protocols, or certain RPC protocols. There are
a multitude of RPC protocols around, all of which do not provide the right
services. Again, the only real concern about switching the protocols to
be RPC based, given the right semantics, is interoperability, and perhaps
performance at the potential bottlenecks such as the Kerberos server.
Steve
--[0432]--
\f
[0433] daemon@TELECOM.MIT.EDU Kerberos 07/07/88 15:17 (20 lines)
Subject: Re: RPC et al
From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In-Reply-To: <8807062040.AA15522@decwrl.dec.com>
Steve Miller suggests:
It might be possible to tweek the code in a few places that set or read the
the ticket lifetime to change the effective units from 5minutes to some
larger value. This would not involve any protocol change. It wouldn't
interoperate properly with "vanilla" installations.
The biggest problem with this suggestion is that the ticket lifetime is
interpreted by the application server, and this server does not know how to
interpret the lifetime field.
For instance, if we build Andrew file system servers that interpret the
lifetime field in 4 hour units, instead of the standard 5 minute units, then a
standard MIT kerberos ticket will be interpreted "incorrectly" by an Andrew
file server here at CMU (if reached over NFSnet, say). In addition, folks at
MIT will have to modify Andrew file server releases to remove this lifetime
conversion factor on every release.
--[0433]--
\f
[0434] daemon@TELECOM.MIT.EDU Kerberos 07/07/88 18:07 (11 lines)
Subject: nfsid
From: qjb@ATHENA.MIT.EDU
To: nessus@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I don't know how much of your problem is caused by nfsid, but the current
version of nfsid will assume that the realm is ATHENA.MIT.EDU if the
host name ends with .MIT.EDU. It does this even after finding out what
realm it should be in! While working in the SMS_TEST realm, we had to build
a new nfsid to solve the problem, but I haven't tried using it for inter-
realm stuff.
.
--[0434]--
\f
[0435] daemon@TELECOM.MIT.EDU Kerberos 07/08/88 16:15 (28 lines)
Subject: Liftimes in tickets
From: Clifford Neuman <bcn%arctic.uit.uninett@TOR.NTA.NO>
To: <kerberos@ATHENA.MIT.EDU>
This message is based on very little knowledge of what has been discussed
on this issue so far. I am in Norway, and I do not have my
mail forwarded to me. If you reply, please cc this address directly
if you want me to see the message before I get home in two weeks.
Anyway, I think I agree with the CMU people. The choice of 1 byte
and 5 minute granularity was made for efficiency reasons. It was
an acceptable choice for the Athena environment, but if we expect
Kerberos to become a standard, then we have to make it useful when people
want liftimes that are longer than are allowed in the current implementation.
Now is the time to do it.
I would also suggest changing the granularity to
1 minute. 5 minutes was chosen because given 1 byte, that allowed
a reasonable range for uses that we expected in our environment. Without
the one byte restriction, 5 becomes a somewhat arbitrary choice. If
someone can suggest a choice that is intuitively more appropriate than
1 minute, choose that as the granularity.
By the way, at this course (ARCTIC '88) Kerberos has been mentioned
a couple of times, and a number of people seem to think that it
is likely get wider use and to become a standard in the same manner
X did.
~ Cliff
--[0435]--
\f
[0436] daemon@TELECOM.MIT.EDU Kerberos 07/09/88 14:46 (24 lines)
Subject: Re: nfsid
From: "Robert S. French" <rfrench@ATHENA.MIT.EDU>
To: <qjb@ATHENA.MIT.EDU>
Cc: nessus@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <qjb@ATHENA.MIT.EDU>'s message of Thu, 07 Jul 88 17:55:22 EDT
From: <qjb@ATHENA.MIT.EDU>
Date: Thu, 07 Jul 88 17:55:22 EDT
I don't know how much of your problem is caused by nfsid, but the current
version of nfsid will assume that the realm is ATHENA.MIT.EDU if the
host name ends with .MIT.EDU. It does this even after finding out what
realm it should be in! While working in the SMS_TEST realm, we had to build
a new nfsid to solve the problem, but I haven't tried using it for inter-
realm stuff.
.
This is proper behavior. The krb_getrealm call looks in
/etc/krb.realms to map domains to Kerberos realms. It knows what
realm YOU are in, but not what realm the host you're talking to is in.
The proper fix is for you to add lines to /etc/krb.realms to map the
hosts you're trying to talk to to the SMS_TEST realm explicitly.
Rob
--[0436]--
\f
[0437] daemon@TELECOM.MIT.EDU Kerberos 07/09/88 15:10 (14 lines)
Subject: Timestamps
From: Clifford Neuman <bcn%arctic.uit.uninett@TOR.NTA.NO>
To: steiner@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: <8807091149.AA08041@BACH.MIT.EDU>
I think that using an expiration timestamp instead of a liftime is
fine, but we should still have a starting time since that information
is used to make sure the ticket is valid. I also like the idea of
allowing postdated tickets as suggested, and whatever approach is
considered, this should be taken into account. If we are going to
make such changes now, then now is also the time to reconsider
the form of the timestamp. We should be using some standard time
format other than that found in Unix.
~ Cliff
--[0437]--
\f
[0438] daemon@TELECOM.MIT.EDU Kerberos 07/10/88 22:25 (7 lines)
Subject: nfsid
From: qjb@ATHENA.MIT.EDU
To: rfrench@ATHENA.MIT.EDU
Cc: nessus@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: "Robert S. French"'s message of Sat, 9 Jul 88 14:35:50 EDT <8807091835.AA00332@CAROLINGIA.MIT.EDU>
-- I have since discovered that by reading sources. My /etc/krb.realms file
has been appropriately modified.
--[0438]--
\f
[0439] daemon@TELECOM.MIT.EDU Kerberos 07/11/88 17:58 (18 lines)
Subject: Re: Liftimes in tickets
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To: Clifford Neuman <bcn%arctic.uit.uninett@TOR.NTA.NO>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of "08 Jul 88 12:55:00 GMT."
I agree that the liftimes need a longer timeout. I personally think
the granularity should be in seconds. I realize this is probably much
finer than needed, but it makes calculations easier. Most machines
have a clock which counts seconds (plus maybe finer times). Working
in minutes, more arithmetic is required every time the lifetime is
checked. The disadvantage of this is that the field would need to be
at least 3 bytes long to record a reasonable maximum timeout (2 bytes
maxs out at 18 hours).
What's the tradeoff of encrypting additional bytes versus having to
convert time units (a multiplication or division)?
Jim
--[0439]--
\f
[0440] daemon@TELECOM.MIT.EDU Kerberos 07/11/88 18:07 (8 lines)
Subject: Questions about names & instances
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
Is there a restricted set of legal characters in names and instances? If not
may I suggests something like upper/lower case letters, numbers, underscore,
and hyphen? Also is there a wild card instance, which matches any (or all)
instances?
Ted Anderson
--[0440]--
\f
[0441] daemon@TELECOM.MIT.EDU Kerberos 07/11/88 18:59 (18 lines)
Subject: Questions about names & instances
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ted Anderson's message of Mon, 11 Jul 88 15:50:42 -0400 (EDT) <4WqFkGy00VseE0eG8l@andrew.cmu.edu>
Reply-To: chariot@ATHENA.MIT.EDU
> Is there a restricted set of legal characters in names and instances? If not
> may I suggests something like upper/lower case letters, numbers, underscore,
> and hyphen? Also is there a wild card instance, which matches any (or all)
> instances?
> Ted Anderson
I would like to add "." to that list for instances only. It is
needed in some cases. I.e., service name = "vice", instance =
"wm.athena.mit.edu".
- Mark Lillibridge
--[0441]--
\f
[0442] daemon@TELECOM.MIT.EDU Kerberos 07/11/88 21:44 (29 lines)
Subject: interested in authentication for batch jobs
From: Jerry Scharf <jerry@PIONEER.ARC.NASA.GOV>
To: kerberos@ATHENA.MIT.EDU
Cc: bkaufman@PIONEER.ARC.NASA.GOV
Hi, I'm new to the group. If this has been discussed before, please point
me to the archives (and even tell me where they might be.)
I am interested in using Kerberos as the authenticator for some of our machines.
I have read some papers on the subject and think I understand most of the
ideas involved. I have some problems when I get to systems that are both batch
and interective in usage. The time limit of 22 hours (255 5 minute ticks) is
limiting in both the run time and the wait time before a job runs. In the
interactive use, the user is required to retype their password, which doesn't
seem to work for a batch job. There is also the problem that Kerberos doesn't
have the idea of an authenticated agent that I could see. The way I look at it,
the batch job itself is not authenticated, but instead is operating as an agent
of the authenticted user. This means that all the tickets of the user should
be passed to the batch job, along with the decrypting key of the user. This
looks unsafe to me at first glance.
Are there any cheap workarounds to these problems that don't compromise the
security? Are there any plans to extend Kerberos in some of these directions?
Can people point me to the liturature that will help me understand this, or
better yet send me copies of papers by email?
(Will Spaceman Spiff live through the next episode)?
Jerry Scharf
NASA Ames Research Center
--[0442]--
\f
[0443] daemon@TELECOM.MIT.EDU Kerberos 07/12/88 01:03 (27 lines)
Subject: Crossing Realms
From: Doug Alan <nessus@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
So, is there anyone who would like to tell me the details of what I
have to do to get inter-realm access to work? Let's say, for example,
that from an Athena workstation, WS.MIT.EDU, I want to write files on
the NFS server, SERVER.MIT.EDU, which is in the EECS.MIT.EDU domain.
Let's also say that there is a kerberos server for the EECS.MIT.EDU
domain called KERBEROS.EECS.MIT.EDU.
Before this will work, do KERBEROS.EECS.MIT.EDU and KERBEROS.MIT.EDU
have to have exchanged some kind of password between them so that they
will be able to identify each other? If so, is this done with the
usual service instance mechanism, with a password that goes in
/etc/srvtab? What is the name of this instance?
Then I have to add a line to /usr/etc/credentials on SERVER.MIT.EDU,
to grant access to nessus@ATHENA.MIT.EDU? What does this line look
like? "nessus@ATHENA.MIT.EDU:654"?
Then I have to add a line to /etc/krb.realms on WS.MIT.EDU? What does
this line look like? "server.mit.edu EECS.MIT.EDU"?
Is there anything else that I am missing?
|>oug /\lan
--[0443]--
\f
[0444] daemon@TELECOM.MIT.EDU Kerberos 07/12/88 14:29 (50 lines)
Subject: Re: Crossing Realms
From: Jon Rochlis <jon@BITSY.MIT.EDU>
To: Doug Alan <nessus@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Doug Alan's message of Tue, 12 Jul 88 00:57:52 EDT,
From: Doug Alan <nessus@ATHENA.MIT.EDU>
Date: Tue, 12 Jul 88 00:57:52 EDT
Sender: nessus@WONKO.MIT.EDU
Before this will work, do KERBEROS.EECS.MIT.EDU and KERBEROS.MIT.EDU
have to have exchanged some kind of password between them so that they
will be able to identify each other? If so, is this done with the
usual service instance mechanism, with a password that goes in
/etc/srvtab? What is the name of this instance?
Yes you need to share a secret with each realm you want to play ball
with. It is not srvtab based. Rather the ATHENA realm has a entry for
krbtgt.EECS.MIT.EDU@ATHENA.MIT.EDU which has the same key as the entry
in the EECS realm for krbtgt.ATHENA.MIT.EDU@EECS.MIT.EDU ... (Give me
or Jeff or Ron a call if you actually want to do this and we'll set it up).
Then I have to add a line to /usr/etc/credentials on SERVER.MIT.EDU,
to grant access to nessus@ATHENA.MIT.EDU? What does this line look
like? "nessus@ATHENA.MIT.EDU:654"?
That would be my guess (that's what Sommerfeld maintained when the
credentials stuff was done). If it doesn't work that way it should.
Then I have to add a line to /etc/krb.realms on WS.MIT.EDU? What does
this line look like? "server.mit.edu EECS.MIT.EDU"?
Yes, I think that is right.
Is there anything else that I am missing?
/etc/krb.conf on WS.MIT.EDU has to have a line like
"EECS.MIT.EDU kerberos.eecs.mit.edu" in order for the workstation to
be able to figure out how to talk to the EECS kerberos server.
The basic idea is that you get a TGT for EECS from the ATHENA server
(krbtgt.EECS.MIT.EDU@ATHENA.MIT.EDU), and present it to the EECS
kerberos server in order to get a ticket for
rvdsrv.server@EECS.MIT.EDU (which has your identity
nessus@ATHENA.MIT.EDU sealed inside). You are not "authenticated" by
the EECS realm at all, you are authenticated by the ATHENA realm and
that is why you need to be able to specify a realm in the credentials
file (or any other kind of access control list you might think of).
-- Jon
--[0444]--
\f
[0445] daemon@TELECOM.MIT.EDU Kerberos 07/12/88 15:44 (33 lines)
Subject: Re: Re: Lifetimes in tickets
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
From: DECWRL::"jb%cs.brown.edu@RELAY.CS.NET" "Jim Bloom 11-Jul-88 1553 EDT" 11-JUL-1988 18:09
To: Clifford Neuman <bcn%arctic.uit.uninett@TOR.NTA.NO>
Subj: Re: Liftimes in tickets
Cc: kerberos@ATHENA.MIT.EDU
I agree that the liftimes need a longer timeout. I personally think
the granularity should be in seconds. I realize this is probably much
finer than needed, but it makes calculations easier. Most machines
have a clock which counts seconds (plus maybe finer times). Working
in minutes, more arithmetic is required every time the lifetime is
checked. The disadvantage of this is that the field would need to be
at least 3 bytes long to record a reasonable maximum timeout (2 bytes
maxs out at 18 hours).
What's the tradeoff of encrypting additional bytes versus having to
convert time units (a multiplication or division)?
Jim
>> This is a bad tradeoff; encryption is much more expensive than arithmetic.
>> For example, the moderately optimised Athena DES code took 2.5 milliseconds
>> per 8 byte block, that is over 300 usec per byte on a Microvax II. And
>> each byte in the ticket is encrypted twice at the Kerberos server, and
>> once at the client and once at the server. By comparison, a single integer
>> multiply or divide on a Microvax II is at most a few tens of microseconds
>> (I don't have the exact figures handy), which is an order of magnitude
>> cheaper.
>>
>> Steve.
--[0445]--
\f
[0446] daemon@TELECOM.MIT.EDU Kerberos 07/14/88 10:43 (15 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Peter_King@NeXT.COM
The NeXT corporate internet consists of several Ethernets,
an Apollo ring net, several Appletalk nets, and a factory floor
network. These networks are located at two sites in Palo Alto,
California and the Fremont, California factory. T1 links connect
these three sites. Numerous gateways tie the whole thing together.
On these networks we have NeXT machines, SUN 3/50's
and 3/60's, and Apple Macintoshes. We will be using Kerberos
to authenticate access to a variety of network services, some of which
are remote file systems (including NFS), and name services.
--[0446]--
\f
[0447] daemon@TELECOM.MIT.EDU Kerberos 07/14/88 15:53 (17 lines)
Subject: information please
From: Russell Brand <wuthel!brand@LLL-CRG.LLNL.GOV>
To: kerberos@ATHENA.MIT.EDU
Reply-To: brand@postgres.berkeley.edu
Win Treese(treese@athena.mit.edu) suggested I send mail to this
address find out about the Kerberos system
is there an overview paper of it?
thanks
wuthel
(brand@lll-crg.llnl.gov)
--[0447]--
\f
[0448] daemon@TELECOM.MIT.EDU Kerberos 07/19/88 06:59 (24 lines)
Subject: Re: Questions about names & instances
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
> > Is there a restricted set of legal characters in names and instances?
> > If not may I suggests something like upper/lower case letters, numbers,
> > underscore, > > and hyphen? Also is there a wild card instance, which
> > matches any (or all) instances?
> > Ted Anderson
>
> I would like to add "." to that list for instances only. It is
> needed in some cases. I.e., service name = "vice", instance =
> "wm.athena.mit.edu".
>
> - Mark Lillibridge
You can find the specifications for naming in the part of the Athena
Technical Plan on Kerberos, pp 6-7. "." is not legal unless escaped
with a backslash. Personally, I think this should be modified; it
would be useful to be able to include "." in instances, as Mark points
out. Wild card names and instances would also be useful. For example,
when extracting a list of tickets for servers on a given host, we
essentially need a wildcard name, and the host as instance.
Jennifer
--[0448]--
\f
[0449] daemon@TELECOM.MIT.EDU Kerberos 07/19/88 12:15 (18 lines)
Subject: Re: Problems with rlogin?
To: kerberos@ATHENA.MIT.EDU
Cc: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
In-Reply-To: Ken Raeburn <raeburn@ATHENA.MIT.EDU>'s message of Mon, 18 Jul 88 12:05:58 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> rlogin:Kerberos rcmd failed: Principal unknown (kerberos).
> The problem here is that the machine is not properly registered with
> Kerberos for providing rlogin service. The unknown principal is
> "rcmd.m11-115-5", which Kerberos must know about in order for you to
> get tickets:
A second problem is that the error message doesn't report what
principal name it couldn't identify. A much better error message
would be:
rlogin:Kerberos rcmd failed: Principal "rcmd.m11-115-5" unknown (kerberos).
Jerry
--[0449]--
\f
[0450] daemon@TELECOM.MIT.EDU Kerberos 07/20/88 15:38 (29 lines)
Subject: re: RPC for communicating with Kerberos
To: Mike Kazar <kazar+@andrew.cmu.edu>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar <kazar+@andrew.cmu.edu>'s message of Tue, 5 Jul 88 22:16:54 -0400 (EDT)
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> From my reading of the Kerberos source code, administrative requests
> are sent from the client to the Kerberos server repeatedly until the
> client receives a response from the appropriate host (correct me if
> I'm wrong). There seem to be several problems with this protocol:
Mike,
I think that the Kerberos protocols are clean on this point. The
ticket acquisition and exchange protocols are all designed to be
completely idempotent (for security reasons as well as the for the
potential flakiness problems you mention) and the administrative
functions that can't be idempotent are implemented with tcp, rather
than doing retransmission themselves.
> Unfortunately, in our environment, with a 2-3% packet loss rate (Unix
> process to Unix process), and packets delays measured in seconds,
> these problems should result in a moderately flakey overall system.
I certainly sympathize with the performance problems you must have to
put up with, but I believe that the Kerberos protocols are designed
to cope with that level of confusion without anyone noticing.
Jerry
--[0450]--
\f
[0451] daemon@TELECOM.MIT.EDU Kerberos 07/20/88 15:38 (17 lines)
Subject: re: using Kerberos with AFS, some comments
To: Mike Kazar <kazar+@andrew.cmu.edu>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar <kazar+@andrew.cmu.edu>'s message of Fri, 1 Jul 88 14:23:52 -0400 (EDT)
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> The only problem we have in using Kerberos-format tickets in our
> system is that the lifetime field simply does not allow us to
> represent long expiration times.
I agree that inability to request long-lived tickets is a major
problem with the current protocol design and that the next Kerberos
release should fix it. Long-running computations are common in many
environments, and there has to be a way to allow them to be
authenticated.
Jerry
--[0451]--
\f
[0452] daemon@TELECOM.MIT.EDU Kerberos 07/20/88 16:15 (34 lines)
Subject: Re: Liftimes in tickets
To: kerberos@ATHENA.MIT.EDU
Cc: Clifford Neuman <bcn%arctic.uit.uninett@tor.nta.no>,
In-Reply-To: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>'s message of Mon, 11 Jul 88 15:53:11 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I agree that the liftimes need a longer timeout.
. . .
> What's the tradeoff of encrypting additional bytes versus having to
> convert time units (a multiplication or division)?
One way to expand the range of timeouts, yet avoid encrypting
additional bytes, is to notice that it isn't really important to
allow a timeout of every possible integer value.
If one allowed timeouts only of 1, 2, 4, 8, 16, etc. seconds, a
single byte could be used, interpreted as an exponent of 2. That
would allow timeouts ranging from 1 second to several gazillion
years, but without very good resolution at the larger end.
A practical version of this idea could be to reinterpret one byte in
a rudimentary floating point: take the last three bits of the byte,
shift them left the number of bits indicated by the first five bits,
and consider the result to be the integer number of seconds wanted
for the timeout. That would allow timeouts ranging from 1 second to
500 years, with good resolution. (One might limit the shift value
to 29, so that the result would always fit in a 32-bit word. That
would limit the upper end to about 100 years.)
Jerry
--[0452]--
\f
[0453] daemon@TELECOM.MIT.EDU Kerberos 07/20/88 19:30 (14 lines)
Subject: Re: RPC for communicating with Kerberos
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kazar+@ANDREW.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Wed, 20 Jul 88 15:26:14 EDT <8807201926.AA00933@HERACLES.MIT.EDU>
Actually I believe that Mike was referring to the "admin
server" protocol. This protocol is UDP based and not idempotent. At
MIT we therefore do not retransmit but instead take advantage of the
fact that the network rarely loses packets (most of the time).
Needless to say this is a crock. A good RPC mechanism is certainly
called for and there is discussion in that direction among the
Kerberos developers.
-Jeff
--[0453]--
\f
[0454] daemon@TELECOM.MIT.EDU Kerberos 07/23/88 00:04 (31 lines)
Subject: interrealm krbtgt's
From: qjb@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
Suppose I have the following /etc/krb.realms:
.MIT.EDU ATHENA.MIT.EDU
HOST2.MIT.EDU REALM2.MIT.EDU
My workstation is in realm ATHENA.MIT.EDU.
If I login or kinit qjb, I get a single ticket:
krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
Even though REALM2.MIT.EDU and ATHENA.MIT.EDU allow each have the
appropriate keys for inter-realm mutual authentication (if this is the
correct terminology), I cannot
nfsid HOST2
Now, if I change kerberos ticket files and kinit qjb@REALM2.MIT.EDU,
I get a single ticket:
krbtgt.REALM2.MIT.EDU@REALM2.MIT.EDU
Now if I type "nfsid soup", I get an error. The only way I can
successfully get both commands to work simultaenously is to hand-edit
my kerberos ticket file and add the latter ticket to the first file
(or the other way around). If I do this and then type "nfsid HOST2",
I get both the rvdsrv.HOST2.MIT.EDU@REALM2.MIT.EDU ticket and the
krbtgt.REALM2.MIT.EDU@ATHENA.MIT.EDU that had to exist for this to
work in the first place. Is there a way that I can get both of these
tickets without hand-editing my ticket file?
--[0454]--
\f
[0455] daemon@TELECOM.MIT.EDU Kerberos 07/23/88 15:49 (11 lines)
Subject: Re: interrealm krbtgt's
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: <qjb@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Emanuel 'Jay' Berkenbilt's message of Fri, 22 Jul 88 23:59:05 EDT,
Just what errors do you get when you try to use nfsid? Do you have an
entry for qjb@ATHENA.MIT.EDU in the credentials database on the file
server in REALM2? (I don't know if this even works, but knowing the
errors you get would help determine the source of the problem.) Do
you get additional tickets when you try it, despite the failure?
--[0455]--
\f
[0456] daemon@TELECOM.MIT.EDU Kerberos 07/25/88 10:01 (9 lines)
Subject: interrealm krbtgt's
From: qjb@ATHENA.MIT.EDU
To: raeburn@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ken Raeburn's message of Sat, 23 Jul 88 15:41:22 EDT <8807231941.AA07146@PRIAM.MIT.EDU>
Hmm. It works now and I haven't changed anything. All the correct
tickets appear "automatically" when I try to do nfsid HOST2. I wonder
what was wrong before? Oh well.
--[0456]--
\f
[0457] daemon@TELECOM.MIT.EDU Kerberos 07/26/88 13:04 (21 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Dan Kolkowitz (Stanford)
Stanford's total network based environment consists of more than one thousand
computers inter-connected on Stanford SUNeT network. Most of the computers
are Unix based workstations and minicomputers, the exceptions being DEC
System 20's running TOPS-20. The principal workstation vendors are Sun,
DEC, IBM, and HP.
We are looking to provide vendor independent secure services across
Stanford. The proposed model is similar enough to Kerberos' that we
hope to use substantial components from it. The major component of the
application would be authentication of a user requesting a resource. We
intend to first use this for secure login and to later extend it to
general network services. The version of secure login would be
implemented on all of the above mentioned architectures, including the
20's. In addition we hope to incorporate the secure protocols in our
ethernet terminal servers to provide secure login on any ethernet
access.
--[0457]--
\f
[0458] daemon@TELECOM.MIT.EDU Kerberos 07/26/88 22:31 (16 lines)
Subject: NFS security
From: mac@SUN.COM (Mac Townsend)
To: kerberos@ATHENA.MIT.EDU
Could you please send me information on the following:
============================================================================
MIT's Project Athena has implemented a user ID mapping scheme for NFS that
maps a pair {client IP address, uid} onto a uid on the server. The
mappings are established at mount time and are authenticated using
Athena's Kerberos authentication system. With such a server, an Amiga (or
any other NFS machine) can't access private files simply by changing the
uid in the request.
============================================================================
Thanks for the trouble,
Mac Townsend
--[0458]--
\f
[0459] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 10:39 (19 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Patrick Powell <papowell@julius.cs.umn.edu>
University of Minnesota
We are currently running a site with an ENCORE Multimax,
SEQUENT Symmetry (in Sept.), Sun 2s, Sun3s, Sun4s,
HP 300 workstations, VAXen (VMS, 4.3, and ULTRIX),
MicroVaxes, and a couple of hundred personal computers.
We have 3 major nets: the fibre net backbone, which connects the
Univerisity, the CS net, which interconnects the CS department,
and several subnets. In addition there are several other subnets
which we actively communicate with.
What we want to do is to implement a secure mail/news/lineprinter spooler
system that will allow us to use our current network AND have some
reasonable control over it.
--[0459]--
\f
[0460] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 13:07 (51 lines)
Subject: valid names
From: qjb@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
There has been a change from the old kerberos to the new about what
is considered a valid name:
---- old protocol
% kinit
MIT Project Athena, (dodo)
Kerberos login: 13.10
Principal unknown (kerberos)
% kinit -i
MIT Project Athena, (dodo)
Kerberos login: krbtgt
Kerberos instance: SMS_TEST.MIT.EDU
Password:
Password incorrect
%
--- new protocol
% kinit
MIT Project Athena, (soup)
Kerberos Initialization
Kerberos name: 13.10
kinit: bad Kerberos name format
Exit 1 kinit
%
% kinit -i
MIT Project Athena, (soup)
Kerberos Initialization
Kerberos name: krbtgt
Kerberos instance: ATHENA.MIT.EDU
kinit: bad Kerberos instance format
Exit 1 kinit -i
% kinit krbtgt.ATHENA.MIT.EDU
kinit: Bad Kerberos name format (kname_parse)
MIT Project Athena, (soup)
Kerberos Initialization
Kerberos name: ^C%
----
Is this really appropriate? Some operating systems have usernames
with .'s and @'s in them. (In MPE, a Hewlett Packard operating
system, ALL usernames have .'s in them.)
--[0460]--
\f
[0461] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 15:17 (191 lines)
Subject: New Kerberos ticket proposal
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
I'd like to suggest several changes to the Kerberos ticket format. The
original motivation for a format change was to increase the range of
specifiable ticket lifetimes, but once that can of worms is open, I'd like to
make some additional suggestions.
This is the current format, as I understand it, from the _Project Athena_
_Technical Plan, Section E.2.1, *Kerberos Authentication and Authorization*_
_*System*_, dated 21 Dec 1987:
ticket = {flags, namep, instancep, realmp, addressp, Ksession,
lifetime, time_seckkds, names, instances}Kskvno
where:
flags: 1 byte, unsigned: byte order of granter?
namep: >= 0 chars, null terminated string
instancep: >= 0 chars, null terminated string
realmp: >= 0 chars, null terminated string
addressp: 4 bytes, unsigned: IP address
Ksession: 8 bytes, unsigned
lifetime: 1 byte, unsigned: in 5 minute intervals
time_seckkds: 4 bytes, unsigned: time issued, sec since 0000 GMT 1/1/70
names: >= 0 chars, null terminated string
instances: >= 0 chars, null terminated string
Kskvno: the server's (kvno'th) key, which encrypts the ticket
Accompanying the ticket, but not actually part of it are two additional fields:
a two byte unsigned length and a one byte key version number (kvno).
First several questions.
The purpose of the kvno is not explained. The paper uses kvno as a subscript
on keys which are used for encrypting tickets. From this, and some later
discussion about changing master passwords, I gather it serves to distinguish
between tickets encrypted with an old password and those encrypted with the new
password. Is this right? Is this the only use envisioned for this field?
What is the flags field used for? I found one place in the Kerberos document
revision history that suggested it was used to specify the byte order of the
ticket granter. Is this still true? Are any of the other bits used for
anything?
The current definition appears to allow for a zero length principal name. Is
this intentional or useful?
What is the purpose of including the server's name/instance in the ticket?
These are potentially lengthy strings which could contribute significantly to
the encryption/decryption time and contain very minimal information. Surely a
server with the correct key would know its own name. The only thing I can
think of that that it would provide a final check against a ticket that had
been tampered with. It seems an expensive way of accomplishing this. Am I
missing something?
Here is an alternative ticket proposal:
ticket = {kvno, {flags, Ksession, namep, instancep, realmp, addressp,
starttime, endtime, label}Kskvno}
where these fields are different from the above:
kvno: 1 byte: identifies the encryption key to the server
Ksession: 8 byte sequence
namep: > 0 chars, null terminated string
starttime: 4 bytes: time ticket becomes valid
endtime: 4 bytes: time ticket expires
label: >= 2 chars: a string to verify correct decryption
Comments/Rationale:
I propose limiting principal names to upper and lower case letters, digits,
underscore, apostrophe, and hyphen. The length must be between 1 and 63
characters plus a trailing null. Instance and realm strings would be
restricted to the same character set with the addition of dot (mainly for
Internet domain names) and lengths of between 0 and 63 characters plus a null.
The motivation for the length limitation is to bound the size of the largest
ticket (the minimum length is 33 bytes, the maximum would be 217). This will
simplify allocation procedures and codify the maximum length, which many
implementation are likely to impose anyway.
The length limit of 63 characters is fairly arbitrary. The selection of a
length should ideally accommodate very nearly all the envisioned uses.
Certainly, the vast majority of user's names will fit in 63 characters. Indeed
31 would probably be enough, although the trend lately towards hyphenated names
may push this limit. Realms and in some cases instances have been named after
domain names so their length is a consideration. RFC-1035 specifies a limit of
63 characters on the individual components of a domain name, but the whole name
may be as long as 255 characters. This could cause trouble, but 63 characters
will probably be sufficient in practice. The limit on realms could be
increased to 255 but this seems excessive.
The character set restrictions are the same as those ``strongly recommended''
for domain names [RFC-1035] with the addition of underscore, and apostrophe.
These graphics allow the following representations for some of the more exotic
names that might be encountered: Du_Pont, D'Urfey, Dvora'k (which omits the
miniature, raised 'v' over the 'r'), de_Soto, Dore' (where the apostrophe
following a letter indicates an accent over the letter). Other possible
additions include ':' following a letter to stand for an umlaut, and backquote
following a letter to indicate accent grave. Internet domain names are case
insensitive, whereas, names, instances, and realms are case sensitive. A
standard needs to be established for selecting the name of a realm from the
various case representations of the corresponding domain name. Alternatively,
realms (and perhaps instances) could be made case insensitive.
I suggest using network byte order for constructing tickets and that the bits
of the flags field be reserved for future use and set to zero by current
implementations. The Internet standard for byte order is specified in RFC-791:
Internet Protocol, appendix B: Data Transmission Order, and is strictly
big-endian. At the byte level, which is the most important for machines with
byte addressing, the order is left to right for strings, and most significant
to least significant for multi-byte integers. Note that the session key is a 8
byte sequence, not a 64 bit integer.
In spite of the fact that this ordering may not be the most convenient for all
machines, utilizing a standard for communications has several advantages.
First, the Internet standard is already in wide use for inter-machine
communication so adhering to a well known standard will minimize confusion
about byte order. Second, from a conceptual point of view, it will be simpler
for implementors to uniformly convert into network order when assembling a
ticket and out of network order when disassembling them. This eliminates
checking the flags bit and having code that handles both cases. The cost of
conversion to and from network order is small enough that the savings realized
in cases where the natural ordering at the sender and receiver is the same is
not worth the added complexity.
I suggest that kvno be used by the server to identify the key needed to decrypt
a ticket. This will work for the case of a transition period where some
outstanding tickets are encrypted with an old password. In addition, it
smoothly handles the case of a server which maintains several passwords. An
example of where this would be useful is the case of Kerberos servers in a
multiple, independent realm environment. Each Kerberos ticket granting server
exchanges a password with the Kerberos in each cooperating realm. This
password is used to encrypt tickets that authenticate its users to the other
Kerberos. For safety reasons the password exchanged with another realm should
not be the same as the password used locally. Thus a ticket received by a
Kerberos server may be encrypted by either the local password or an external
password. In general, to provide security firewalls in a large multi-realm
environment there may be many external passwords known to a server, although
each Kerberos will only need to remember one for each server. Other reasons
why a server might encounter tickets encrypted with different passwords can be
imagined. The kvno field allows a simple method for discriminating between
such tickets.
The argument for including the kvno as an unencrypted part of the ticket is
that the ticket is effectively useless without the kvno. Thus, it is
conceptually simpler, to treat the ticket as a single entity where only the
encryption routines know which part is encrypted.
The use of both a start time and end time provides the most flexible means for
controlling ticket lifetimes. These times should be checked for reasonability
by making sure the starttime is in the past, the endtime is in the future, and
The difference between the two is strictly positive but less than some
reasonable upperbound. The upperbound should allow lifetimes of at least one
year. An alternative is to provide a start time with a duration, which could
be specified as a two byte unsigned number of minutes. This allows the
specification of lifetimes less than 45 days long. The advantage of the
start/end method is that the ticket format
does not impose precision or length limitations of the specification of
lifetimes. Thus the simplicity and flexibility more than compensate for the
small additional cost in ticket length.
From a cryptographic standpoint, putting the most random part of the ticket at
the beginning makes attempts to decrypt it more difficult because of the use of
cipher-block-chaining during encryption. This also means that interference
with a ticket is most likely to garble the end of the ticket. Since the order
of fields in the ticket is arbitrary it would be advantageous to put the
session key near the beginning and an easily recognized label at the end.
Leaving the flags at the very beginning allows the possibility of using it to
support a later incompatible format change.
This ticket proposal eliminates the name and instance of the server from the
ticket. This should provide a substantial reduction in the length, and
corresponding encryption and decryption times, of tickets. The absence of the
server's identity from the ticket could only cause confusion if a user supplies
some other ticket to a server. In almost every case this error would be
detected because the key used by the server to decrypt the ticket would be
wrong and result in total garbage. If a server's password has been
compromised, a user could forge tickets at will, and all would be lost anyway.
The only other alternative is that two servers coincidentally selected the same
password and their tickets are inadvertently switched by the user. In this
exceedingly unlikely case the user is still correctly authenticated to the
server and no security violation occurs. Thus, naming the server for which a
ticket is created is entirely unnecessary.
Using the server's name and instance as the ticket's label is also
questionable. To detect decryption errors I suggest, in addition to
reasonability checks on all the fields in the ticket, padding the end with a
constant string. Since the encryption algorithm requires its input to be a
multiple of 8 bytes, adding at least two characters and enough more to bring
the length to this boundary would allow this extra correctness check with a
minimum of overhead. Specifically, if the length of the part to be encrypted
is N; append the first 9-(N+1)%8 characters of the string "TicketEnd" to the
ticket before encryption. Checking for this terminal sequence after decryption
provides added confidence in the integrity of the ticket.
--[0461]--
\f
[0462] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 16:01 (19 lines)
Subject: Background on Ticket Proposal
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>
I suppose a bit of background on my proposal to change the Kerberos ticket
format would be in order. I have taken over the implementation of a
Kerberos-style authentication server for the Andrew File System. For various
reasons we can't use Kerberos as is, but we'd like to retain as much as
possible. Since all our client/server communication uses RPC we can't use the
Kerberos protocols directly, but ticket level compatibility is still useful.
Specifically, one senario involves having an Andrew File System cell at MIT use
tickets obtained from the Athena Kerberos (with an Athena log program). This
allows a single authentication database to serve both systems at MIT. The
proposal developed during the process of considering the design issues for the
new authentication server and figuring out the Kerberos design document.
I'd appreciate comments on the proposal. My intent is to try and reach
agreement on a compromise ticket format that everyone can use.
Ted Anderson
--[0462]--
\f
[0463] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 16:15 (14 lines)
Subject: Re: valid names
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
Cc: qjb@ATHENA.MIT.EDU
In-Reply-To: <8807281702.AA01361@SOUP.MIT.EDU>
I don't think there's any intrinsic reason to prevent '.' in a username. Some
ambiguity arises in trying to decide where the user name ends and the instance
begins. Maybe comma should be an alternate separator between the name and
instance. This is a far less likely character to find in either a user or
instance name.
However, allowing atsign in usernames is right out. Any system that allows '@'
in usernames and also supports network mail is going to be sorry.
Ted Anderson
--[0463]--
\f
[0464] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 16:29 (11 lines)
Subject: Background on Ticket Proposal
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU, kazar+@ANDREW.CMU.EDU
In-Reply-To: Ted Anderson's message of Thu, 28 Jul 88 15:49:45 -0400 (EDT) <8WvsJNy00VseMGl4cP@andrew.cmu.edu>
Reply-To: chariot@ATHENA.MIT.EDU
I'm interested in getting kerberos working with vice as well.
I'm one of people "managing" the mit vice cell. Can you send me your
current proposal?
- Mark Lillibridge
--[0464]--
\f
[0465] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 16:40 (15 lines)
Subject: valid names
From: qjb@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
I have been informed (and have verified) that quoting the period or @
with a backslash works:
kinit -i
test\.root
will work as will
kinit test\\.root
I guess I jumped too soon.
--[0465]--
\f
[0466] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 18:26 (17 lines)
Subject: my second question related to Kerberos
From: Jerry Scharf <jerry@PIONEER.ARC.NASA.GOV>
To: kerberos@ATHENA.MIT.EDU
As one of the people who started the whole issue of lifetimes of Kerberos
tickets, my question was adressed in the sense that there was a large
response that longer tickets were needed. I agree, but was asking also if
there are any ideas to reduce the risk of a lost ticket, thus making the
idea of a longer ticket not represent a weakening of the system security.
The other question I had was on the idea of batch jobs working as agents
for an authenticaed user. There has been work done on the ability to pass a
ticket on to an agent, and have that agent represent itself as the user. This
seems like a critical issue for batch job preocessing, and wanted to know
if Kerberos could/should be extended to allow this model of authentication.
Jerry Scharf
NASA Ames Research Center
--[0466]--
\f
[0467] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 18:53 (143 lines)
Subject: Re: New Kerberos ticket proposal
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
Re: Ted Anderson's questions and proposal-
I am quite pleased to see this interest in the evolution of Kerberos.
Steve
-------------------------------------------------------------------
...text deleted...
>First several questions.
>
>The purpose of the kvno is not explained. The paper uses kvno as a subscript
>on keys which are used for encrypting tickets. From this, and some later
>discussion about changing master passwords, I gather it serves to distinguish
>between tickets encrypted with an old password and those encrypted with the new
>password. Is this right? Is this the only use envisioned for this field?
Yes, it is for orderly transition when keys change. If a principal changes
its key, as it should do routinely, there will be tickets outstanding with
both the old and the new keys. The tickets with the old keys would
otherwise be valid until they expire, so if the server (receiver really)
isn't worried about having compromised its old key, it can honor either
the old or the new for some period of time, after which all tickets should
have the new key.
>What is the flags field used for? I found one place in the Kerberos document
>revision history that suggested it was used to specify the byte order of the
>ticket granter. Is this still true? Are any of the other bits used for
>anything?
It is used to define byte ordering of multi-octet integer fields that appear
in a few places in different protocol messages. I don't think any of
the other bits were used.
>The current definition appears to allow for a zero length principal name. Is
>this intentional or useful?
Probably an accident. Don't think it is particularly useful.
>What is the purpose of including the server's name/instance in the ticket?
>These are potentially lengthy strings which could contribute significantly to
>the encryption/decryption time and contain very minimal information. Surely a
>server with the correct key would know its own name. The only thing I can
>think of that that it would provide a final check against a ticket that had
>been tampered with. It seems an expensive way of accomplishing this. Am I
>missing something?
We went around on this a few times. It serves two purposes, each of which
could be served better. The first is that it disambiguates the ticket if
different instances of a principal or even entirely different principals use
the same key. Otherwise a ticket for one principal could be used for a
different one. Second, given the modified cbc crypto mode used, and its
position at the tail of the ticket, it guarantees that any modifications to
the ticket will be detected, resulting in invalid server name, instance.
... deleted text...
>Here is an alternative ticket proposal:
I don't have the time to go through the proposal in detail right now,
but will offer some generic suggestions.
>I propose limiting principal names to upper and lower case letters, digits,
>underscore, apostrophe, and hyphen. The length must be between 1 and 63
>characters plus a trailing null...
> ...(text deleted)
Conventions on the principal et al. names are a good idea. I don't have
any idea what the right conventions are.
>I suggest using network byte order for constructing tickets and that the bits
>of the flags field be reserved for future use and set to zero by current
>implementations...
> (text deleted)
While this is probably a good idea in theory, if it ain't broke, don't fix
it. At this point in time, what does it buy?
>I suggest that kvno be used by the server to identify the key needed to decrypt
>a ticket.
>... (text deleted)...
This is already the case, at least in the protocol design. I thought the
interfaces already support this.
>The use of both a start time and end time provides the most flexible means for
>controlling ticket lifetimes.
> ... text deleted...
There are two questions here: what is the maximum ticket lifetime, and
how is it encoded. First, the easy question about encoding -- use the
densest encoding possible to minimize the size of the encrypted data. So that
probably points to using a start time plus offset encoding. Second, the
hard question, is what should the architected maximum lifetime be? My views
on this were and still are that it needs to be reasonably bounded, otherwise
the whole authentication serves no purpose. I would also point out that the
people who have found the current lifetime too short have gone beyond the
original design goal and tied the authentication lifetime exactly to the
authorization lifetime, e.g. files service access. Not to belabor the point,
if there is pressure to extend the field, extend it, but not by too much.
>From a cryptographic standpoint, putting the most random part of the ticket at
>the beginning makes attempts to decrypt it more difficult because of the use of
>cipher-block-chaining during encryption.
>... text deleted...
First, we never worried about cryptanalysis, but we were concerned about
detecting active modification attacks. The layout of the ticket was not
arbitrary, but planned to put values at the end that would detect modification.
This interacted well with the modified cbc mode, in that if a single bit
was modified anywhere in the ticket, about 50% of the bits in the last block,
containing the server name and instance, would change. A similar effect can
be achieved by including a known constant at the end of the cleartext, but
it is not necesary because there are enough other fields that would almost
certainly cause problems if modified.
>This ticket proposal eliminates the name and instance of the server from the
>ticket. This should provide a substantial reduction in the length, and
>corresponding encryption and decryption times, of tickets.
> ... text deleted...
This is a good direction to pursue, but I would not eliminate it entirely,
rather use a condensed signature function of it instead. This signature
could even be used on the principal name, moving the actual name into the
cleartext part of the ticket. Of course, a signature will sacrifice some
security since multiple inputs will produce the same signature. Unfortunately,
the good signatures -- crypto MACs, require the same amount of
computation as encrypting the whole thing. The quad_cksum (signature)
in Kerberos is computationally inexpensive, though probably
not terribly secure. I had proposed an alternative protocol along these lines
when we were first starting to use Kerberos.
>Using the server's name and instance as the ticket's label is also
>questionable. To detect decryption errors I suggest, in addition to
>reasonability checks on all the fields in the ticket, padding the end with a
>constant string.
>... text deleted ...
If you look at the properties of DES in the CBC mode, a single bit error
anywhere will cause about 50% of all the subsequent bits to change. So
if the ticket ends with a value that has a small valid range, you will
have a very good integrity check. So for the purposes of Kerberos, I don't
think anything else is necessary.
Steve.
--[0467]--
\f
[0468] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 19:42 (14 lines)
Subject: P.s. re New Ticket proposal
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
The end of the existing ticket is already zero padded to a multiple of
eight bytes, so checking any padding for zero after decryption would buy
a small amount of additional integrity at no additional runtime cost or
change in the protocol. So if you believe that the size distribution of
the names, modulo 8, is reasonably evenly distributed, about 7/8 of the
time you will get some extra integrity for free. BTW, other than at
the beginning of the first block in a chain, zero is about as good an integrity
constant as any.
Steve
--[0468]--
\f
[0469] daemon@TELECOM.MIT.EDU Kerberos 07/28/88 20:09 (46 lines)
From: (Stephen Tihor) <TIHOR@CMCL1.NYU.EDU>
To: <KERBEROS@ATHENA.MIT.EDU>
In-Reply-To: <MWvreay00VseAGl3Mu@andrew.cmu.edu>
Any field which contains the names of (a) existing programs, or (b) users
must be in general unbounded and unrestricted. There are operating systems
which permit pretty arbitrary usernames contain all the alphanumeric, national
replacement characters, and selected separators (INCLUDING BLANKS).
Considering the possibilities of Kanji usernames in any of the possible
encodings it would be best to not restrict this field.
Historically people hacking together code for Unix tend to ignore such issues
(e.g. sendmail) but if Kerberos is a serious first draft of a protocol we
hope to see adopted generally then it is a bad idea to add restrictions
that rule out its use by other vendors.
Realms and instances if named with the internet domain rules should follow
those rules as to the maximum size. I suspect in practice most names will be
shorter than 35 characters but everyday I use a couple of boxes that can not
express an internet name over 12 characters because their designers expected
the world to be xyz.asb.hjk. Setting a defacto limit means some other, honest
person will try and follow the rules and lose when using your version of the
code. Granted that we can define what a realm is so that it follows our own
naming rules but if the use of the real domain name rules is not acceptable why
were these fields defined as domain names rather than say unix path names,
another well defined heirarchical namespace?
You write, "Internet domain names are case insensitive, whereas, names,
instances, and realms are case sensitive. A standard needs to be established
for selecting the name of a realm from the various case representations of the
corresponding domain name. Alternatively, realms (and perhaps instances) could
be made case insensitive." I agree. By the same arguement I made before
I believe we should try and follow those rules exactly or else make up our
own ab initio.
If you feel you need to put an upper bound on the size of the ticket you can
ask around for reasoable values but I expect you will end up with something
like 1000 bytes worst cases. If preallocation of buffers is necessary perhaps
specifying an options dialog whereby Kerberos can discuss the legal size of
fields at the moment when a piece of Kerberos using code needs to get a buffer
allocated would be appropriate. [I am unsure why you are that concered about
this issue.] I am much more concerned about the realtively short passwords
being used.
-------
--[0469]--
\f
[0470] daemon@TELECOM.MIT.EDU Kerberos 07/29/88 07:14 (15 lines)
Subject: Don't forget us
From: mcvax!inria.inria.fr!neumann@UUNET.UU.NET (Pierre Louis Neumann)
To: kerberos@ATHENA.MIT.EDU, steiner@ATHENA.MIT.EDU
Kindly send us the tape as soon as possible
Many thanks
Pierre-Louis NEUMANN
INRIA adresse electronique:
Domaine de Voluceau ^^^^^^^^^^^^^^^^^^^^^
ROCQUENCOURT neumann@inria.inria.fr
BP.105 neumann@inria.uucp
78153 Le Chesnay CEDEX ...uunet!mcvax!inria!neumann
FRANCE
--[0470]--
\f
[0471] daemon@TELECOM.MIT.EDU Kerberos 07/29/88 12:58 (53 lines)
Subject: Re: valid names
To: kerberos@ATHENA.MIT.EDU
Cc: Ted Anderson <ota+@andrew.cmu.edu>
In-Reply-To: Ted Anderson <ota+@andrew.cmu.edu>'s message of Thu, 28 Jul 88 16:01:00 -0400 (EDT)
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I don't think there's any intrinsic reason to prevent '.' in a
> username. Some ambiguity arises in trying to decide where the user
> name ends and the instance begins. Maybe comma should be an
> alternate separator between the name and instance. This is a far
> less likely character to find in either a user or instance name.
>
> However, allowing atsign in usernames is right out. Any system
> that allows '@' in usernames and also supports network mail is going
> to be sorry.
> Ted Anderson
I think that this discussion may be losing sight of some
fundamentals. There are non-UNIX systems out there that use
different mail conventions, and that may have at-signs, dots,
dollar-signs, and even blank spaces in their user names. Kerberos
ought to be applicable to those systems, too.
Kerberos itself should enforce restrictions on the range of
principal, instance, and realm identifiers only to the extent that
restrictions are required for proper, secure operation of an
authentication service. So far the only such requirement I have
heard articulated is of name length, in order to keep the cost of
encryption from getting out of hand. I would propose in addition
that a human-factors/security argument would suggest we constrain
identifiers to the 94 ASCII characters that have usual graphic
representations. Apart from those two sources of argument, no one
has mentioned anything about the authentication process, the Kerberos
protocol, or the Kerberos subroutine call interfaces that requires
that anything else (even space characters) should not be allowed in
Kerberos identifiers.
When Kerberos is applied to particular situations, such as the
authentication of UNIX logins, a mapping of Kerberos names to UNIX
login identifiers needs to be implemented, and to the extent that
people find it convenient to use one-to-one mapping, they may wish to
enforce some restriction from outside Kerberos that leads to not
registering certain names. In the case of UNIX one might impose
restrictions such as no more than 8 characters, that they must all be
lower case alphabetic or numeric, and they must begin with an
alphabetic.
Similarly, if one decides to use Kerberos to authenticate names used
for mail receipt, one might decide not to register names with
at-signs. But each of these examples are application restrictions,
not things that should be enforced by the Kerberos server itself.
Jerry Saltzer
--[0471]--
\f
[0472] daemon@TELECOM.MIT.EDU Kerberos 07/29/88 13:25 (31 lines)
Subject: Comments on beta test version
From: jb%cs.brown.edu@RELAY.CS.NET
To: kerberos@ATHENA.MIT.EDU
I have only gotten as far as reading the documentation and compiling the
code of the beta test release and have not started running it yet. Here
are some comments about what I have seen so far.
First, the manual pages make too much reference to the Athena environment.
If someone outside of MIT is told there system is running kerberos and
types man kerberos, the paragraph has the sentence "All Athena timesharing
machines and public workstations support Kerberos." What does this fact
have to do with anyone else using the software. Other comments like this
and about other software at Athena are also included. The manual pages
should be complete in themselves and not reference other software that
is not running on the machine.
Next, I used a compiler that effectively runs lint on the code as well.
I had more lines of lint style warning from the compiler than commands
executed by make. Rcs ids I won't argue about (this was only about
half of the errors though), but there were lots of unused variables.
Also included were many statics that were not initialized before use.
Finally, skimming the code for rsh and rlogin leads to some interesting
discoveries. First, the "-n" flag has different meanings between the
two programs. In rsh it means disconnect stdin from the terminal and
in rlogin it means allow escape character (I think). On a similar
note, how about manual pages which describe the new options in the
bsd applications. Half of the mods were made for various reasons
at Athena which are not related kerberos.
Jim
--[0472]--
\f
[0473] daemon@TELECOM.MIT.EDU Kerberos 07/29/88 19:55 (20 lines)
Subject: Re: valid names
From: jb%cs.brown.edu@RELAY.CS.NET
To: "Jerome H. Saltzer" <Saltzer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of "Fri, 29 Jul 88 12:49:23 EDT."
I think even limiting the character set to printable ascii is overly
restrictive. If at all possible, the protocol should be able to
handle any character set using 8-bit bytes. Anything more restrictive
than forbidding NULL might interfere with users tring to use international
character sets. (Anyone know how kanji works?) Most people don't
even consider the international character sets. It would look good
if we had thought about the issue and tried to be compatible with
the internation character sets.
At the application level, it is reasonable to be more restrictive.
If at all possible, the library routines should accept any null
teminated string of bytes for the principal, instance, and realm
identifiers. The server should be as general as possible too.
Jim
--[0473]--
\f
[0474] daemon@TELECOM.MIT.EDU Kerberos 07/29/88 20:59 (28 lines)
Subject: valid names
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
I beleive that in the current protocol, the only character that is not
allowed in components of names is NULL. The three components of a
name are treated separately and there is no problem if a name contains
an "@" or a ".". This is as it should be.
Note, however, that although the protocol allows anything other than
NULL this choice is (presently) restricted in the user interface. For
example, the character set that can be used in the .klogin files is
more restricted. Programs that read text files or take user input and
try separating the three fields of a name might get confused if they
accept input as a single token and the separators also appear in the
individual fields. This is a separate issue, and I do not feel that
the way to solve it is to restrict what is legal according to the
protocol.
As to the size of the fields. As far as the protocol goes, they
should be unlimited. This follows from application of the
zero-one-infinity argument. The lengths are currently restricted by
the implementations, but this is something that can be fixed, although
it would be a low priority task. A user that wants a long name should
be allowed to do so. As long as allowing long names only slows things
down when such names are actually used, there is no reason to disallow
them.
~ Cliff
--[0474]--
\f
[0475] daemon@TELECOM.MIT.EDU Kerberos 07/30/88 11:05 (30 lines)
Subject: more comments on kerberos installation
From: jbloom@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
It would be nice if there was some easy way to check the output from the
des test program verify. I find having to read a printed copy and the
program output more difficult than is needed. A couple ideas for making
this less error prone would be to include a copy of the correct output
so that diff might be run or to have verify have the results hardcoded
inside and test for correctness itself using bcmp. The second is more
work, but even easier for someone installing kerberos.
The operation guide is fairly complete about all of the steps needed to
install kerberos and run a first test of the system. One step was missed
here; There was no mention that an entry for kerberos was needed in
/etc/services.
Another problem in the operations guide with the sample entry in inetd.conf
for the sample (test) server. What is the field entry "switched"? This is
not most machines to which I have access. In fact, the only machines I can
find it on are the Athena machines. It is NOT described in the online
manual pages there either. This field should probably be dropped be from
the operations guide sample.
I'm not sure if I really like the idea of the installation being performed
to /usr/athena. I don't feel that everyone outside of Athena should have
to add something else to their path to access kerberos. Maybe the libraries
should go in /usr/local/lib which is searched by most loaders when looking
for libraries referenced as -llibname.
Jim Bloom
--[0475]--
\f
[0476] daemon@TELECOM.MIT.EDU Kerberos 08/01/88 12:39 (47 lines)
Subject: Limits in Standards
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: jb%cs.brown.edu@RELAY.CS.NET, bcn@june.cs.washington.edu (Clifford Neuman)
Cc: kerberos@ATHENA.MIT.EDU
While I am sympathetic to the desire to allow as much flexibility and
generality in the protocol as possible I think limits should be imposed by a
standard that has aspirations of usefulness. A standard is used by an
implementor to provide information about how other implementations will behave.
When an program is expected to communicate with other systems these guidelines
to those other system's behavior is critically important. A standard that is
too opened ended really just refuses to provide this information, it defers
decisions to another person or another time. The implementor is then forced to
guess, decide on his own, experimentally determine the operational parameters
of other implementations or take other measures to answer these questions for
himself. This is the process I am going through now since there is no standard
yet, but it would be nice to save future implementors the trouble.
Although there may be techniques for allowing truly unlimited name lengths,
these will span a spectrum of difficulty. I think it is safe to assume that
all implementations will impose some length limits, either explicitly or
implicitly. We owe it to the users of the system to specify, in advance, when
a name is too long. Otherwise, longish names will fail in unpredictable ways
when the limits are reached, perhaps in extremely subtle and intermittent ways.
A fixed upper bound can also be a well tested upper bound.
In our case, RPC needs a preallocated area in which to return tickets from
Kerberos. Above some limit, less than 1000 bytes, the underlying IP protocol
will be forced to fragment the packets which will be a source of delay,
complication and error. At still larger sizes an FTP like protocol will have
to be used, which will further complicate things. The limit I suggested of 63
characters has the property that tickets are smaller that 256 bytes, which
should be reasonably convenient for everyone.
A similar, but weaker, argument can be made for restricting the character set
of names. My main purpose in suggesting the restrictions was to allow
reasonability checks on the result of decrypting a ticket. A totally garbaged
ticket could still produce a legal user name, although there will be other ways
of detecting this. Allowing international character sets even precludes
checking for the eighth bit being on. Even if we allow this can we at least
require both user and instance name to have either all or none of their eighth
bits set? If the consensus is to allow any 8 bit byte except null then we
should explicitly say that we expect any sequence of bytes in names and remind
people not to do things like clear the eighth bit, canonicalize white space or
whatever. We should also suggests a standard escape convention for user level
applications to allow entry of unusual characters, such as backslash followed
by three octal digits.
Ted Anderson
--[0476]--
\f
[0477] daemon@TELECOM.MIT.EDU Kerberos 08/05/88 13:07 (49 lines)
Subject: completeness of DES_CRYPT(3)
To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
As everyone on this list probably knows, export of Kerberos outside
the U.S. leads, because it uses cryptographic techniques, into a
wonderful maze of government regulations, controls, confusion, and
related time-sinks. I'm looking at a particular narrow question in
the middle of that maze, and would like to get opinions from anyone
who has looked at the relevant parts of Kerberos.
The question is the following: if one were to receive a copy of the
Kerberos sources with the DES library sources and binaries omitted,
would it be possible to write a working library with the information
found in the man pages labeled DES_CRYPT(3), assuming the programmer
also had copies of the relevant FIPS specifications of DES and DES
usage?
A reasonable meaning for the term "working library" is that servers
and clients could interwork in any combination: e.g., a client loaded
with the standard distribution library could get tickets from a
server loaded with the newly-programmed library, and that those
tickets would be recognized by servers loaded with either the
standard distribution or the newly-programmed library. All clients
(including, e.g., password-changing commands) should interwork.
A weaker definition of "working library" (let's call this "working
without interworking") would be that the resulting library could be
used to put together a complete self-consistent set of clients and
servers that work together but that don't work across the net with
clients or servers from a realm that uses the standard distribution.
There are two obvious possible stumbling blocks:
1. The algorithm to be used by subroutine string-to-key is not
specified in DES_CRYPT(3), but a first look suggests that it may not
matter; as long as everyone within a single realm agrees on the
algorithm used by string-to-key within that realm, it doesn't matter
if different realms use different algorithms. (Can anyone think of a
counterexample?)
2. The function of pcbc_encrypt isn't specified in the FIPS
standards, but a first look at the man page suggests that it supplies
enough detail. (Again, alternate opinions are solicited.)
Are there any others?
Thanks for your help.
Jerry
--[0477]--
\f
[0478] daemon@TELECOM.MIT.EDU Kerberos 08/06/88 08:04 (77 lines)
Subject: bugs in ext_srvtab.c
From: jb%cs.brown.edu@RELAY.CS.NET
To: kerberos@ATHENA.MIT.EDU
Ext_srvtab has a couple minor problems. If it is called using a relative
beginning with a "." and without the "-n" flag, it complains that the
path used for executing the program is an invalid instance. The easiest
test case I found was "./ext_srvtab host". I traced this problem down to
poor handling of the argument list. A second problem is that the srvtab
created has bad permissions. When I ran the program, the srvtab was
readable by everyone on the machine. It should be readable by only root
for security reasons.
Below are fixes for both of these problems as well as removing an unused
variable.
Jim
*** ext_srvtab.c.orig Mon May 23 15:58:18 1988
--- ext_srvtab.c Sat Jul 30 10:22:45 1988
***************
*** 48,54 ****
char realm[REALM_SZ];
int fopen_errs = 0;
char *arg;
- Principal master_princ;
Principal princs[40];
int more, prompt;
register int n, i;
--- 48,53 ----
***************
*** 64,70 ****
exit (-1);
}
}
- argc++; argv--;
CheckArgs(argc, argv);
--- 63,68 ----
***************
*** 84,91 ****
fprintf(stderr, "%s: couldn't get local realm\n", progname);
exit(1);
}
! while (--argc) {
! arg = *++argv;
sprintf(fname, "%s-new-srvtab", arg);
if ((fout = fopen(fname, "w")) == NULL) {
fprintf(stderr, "Couldn't create file '%s'.\n", fname);
--- 82,90 ----
fprintf(stderr, "%s: couldn't get local realm\n", progname);
exit(1);
}
! (void) umask(077);
! while (argc--) {
! arg = *argv++;
sprintf(fname, "%s-new-srvtab", arg);
if ((fout = fopen(fname, "w")) == NULL) {
fprintf(stderr, "Couldn't create file '%s'.\n", fname);
***************
*** 129,135 ****
int c;
char *v[];
{
! for (; --c; ++v)
if (!k_isinst(*v)) {
fprintf(stderr, "%s: bad instance name: %s\n",
progname, *v);
--- 128,134 ----
int c;
char *v[];
{
! for (; c--; v++)
if (!k_isinst(*v)) {
fprintf(stderr, "%s: bad instance name: %s\n",
progname, *v);
--[0478]--
\f
[0479] daemon@TELECOM.MIT.EDU Kerberos 08/06/88 08:10 (57 lines)
Subject: bug in lib/des/read_password.c
From: jb%cs.brown.edu@RELAY.CS.NET
To: kerberos@ATHENA.MIT.EDU
When trying to read in passwords, if an EOF is provided at the beginning
of a line, read_password goes into an infinite loop asking for input, not
reading from the terminal and complaining about a bad password. I fixed
this by clearing the EOF flag whenever an error occurs reading a password.
This doesn't change the looping structure, i.e. it will continue to ask
for passwords, but it lets the user input something.
Jim
*** read_password.c.orig Mon May 23 16:00:37 1988
--- read_password.c Sat Jul 30 17:59:57 1988
***************
*** 115,122 ****
if (!strlen(s))
continue;
#else
! if (!gets(s))
continue;
#endif
if (verify) {
printf("\nVerifying, please re-enter %s",prompt);
--- 115,124 ----
if (!strlen(s))
continue;
#else
! if (!gets(s)) {
! clearerr(stdin);
continue;
+ }
#endif
if (verify) {
printf("\nVerifying, please re-enter %s",prompt);
***************
*** 126,133 ****
if (!strlen(key_string))
continue;
#else
! if (!gets(key_string))
continue;
#endif
if (strcmp(s,key_string)) {
printf("\n\07\07Mismatch - try again");
--- 128,137 ----
if (!strlen(key_string))
continue;
#else
! if (!gets(key_string)) {
! clearerr(stdin);
continue;
+ }
#endif
if (strcmp(s,key_string)) {
printf("\n\07\07Mismatch - try again");
--[0479]--
\f
[0480] daemon@TELECOM.MIT.EDU Kerberos 08/06/88 19:01 (25 lines)
Subject: Re: bugs in ext_srvtab.c
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: jb%cs.brown.edu@RELAY.CS.NET
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: jb%cs.brown.edu@RELAY.CS.NET's message of Sat, 06 Aug 88 07:55:42 -0400,
From: jb%cs.brown.edu@RELAY.CS.NET
Date: Sat, 06 Aug 88 07:55:42 -0400
A second problem is that the srvtab
created has bad permissions. When I ran the program, the srvtab was
readable by everyone on the machine. It should be readable by only root
for security reasons.
Just a minor point here. I have no problem with the umask change you
made, but remember that root may very well not be the person running
ext_srvtab. After all you only need read access to the dir and pag
files. While you probably don't want many user-accounts on your
kerberos master, you might have a few. (I might want an account so I
in could have read-access to the database, but not write. Limit the
damage I could do unless I explicity chose to log in as root. Unix
generally loses in making you spend too much time logged in as root in
anycase.)
-- Jon
--[0480]--
\f
[0481] daemon@TELECOM.MIT.EDU Kerberos 08/08/88 11:43 (91 lines)
Subject: Mike's wish list
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA21570; Thu, 4 Aug 88 10:27:37 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11479; Thu, 4 Aug 88 10:25:49 EDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00682> for steiner@athena.mit.edu; Thu, 4 Aug 88 10:25:07 EDT
Received: via switchmail; Thu, 4 Aug 88 10:25:00 -0400 (EDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.whitaker.andrew.cmu.edu.22f87369.7ca4c>;
Thu, 4 Aug 88 07:23:40 -0700 (PDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/kazar/.Outgoing/QF.whitaker.andrew.cmu.edu.22f87364.98a7d>;
Thu, 4 Aug 88 07:23:32 -0700 (PDT)
Received: from Version.6.20.N.CUILIB.3.44.SNAP.NOT.LINKED.whitaker.andrew.cmu.edu.rt.r3
via MS.5.5.whitaker.andrew.cmu.edu.rt_r3;
Thu, 4 Aug 88 07:23:31 -0700 (PDT)
Message-Id: <EWy7BXy00Uk-80TEpL@andrew.cmu.edu>
Date: Thu, 4 Aug 88 07:23:31 -0700 (PDT)
From: Mike Kazar <kazar+@andrew.cmu.edu>
X-Andrew-Message-Size: 4066+0
To: steiner@ATHENA.MIT.EDU
Subject: Fwd: Kerberos wish list
References: <MWxm8my00Uk-48PGIX@andrew.cmu.edu>
...
- ---------- Forwarded message begins here ----------
Well, the heart of our wish list is Ted Anderson's ticket proposal that he sent
to the kerberos mailing list about a week ago. I'm assuming you've seen that
note; if not, send mail to me or to Ted (ota+@andrew.cmu.edu) and we can send
you a copy of the message. The key ideas in that message are (and I'm
over-simplifying here, so you should really read the original note):
More flexibility in specifying when a ticket is valid. We'd like to be
able to specify that a ticket will be valid for a longer period than is
possible now, and we would also like to be able to specify that a ticket
doesn't become valid until a certain time. Ted's proposes using a start
time and an end time, both in Unix date format seconds, to get this
functionality.
I certainly wish that tickets had only one format: network byte order. The
time to convert these things to a different byte order is essentially
trivial, and of course having only one format simplifies things.
It looks like there really is no need for placing the server's name and
instance into a ticket. That would probably reduce the size of tickets
considerably.
Aside from the ticket format, there are several other problems with the
Kerberos distribution as it stands now.
The Kerberos administrative protocols are UDP-based and non-idempotent, yet the
Kerberos code simply retransmits requests without any attempt to prevent a
request from multiple executions. This affects virtually every network request
except for the "get tickets" request. We strongly suggest the use of an RPC
mechanism here, and we're working with IBM to try to make our RPC and
light-weight thread package available essentially in the public domain if you
folks want to use it. Using an RPC mechanism has a significant effect on the
protocols, but we believe, based on our experience, that RPC interfaces are
quite easy to understand and well worth using in those circumstances where they
make sense.
Another "system design" level problem with Kerberos is the lack of a mechanism
for storing tickets for others to read. In the Andrew file system, we
associate tickets with process trees, and any process within a tree can get the
tickets for that tree. Any process can establish itself as the root of a new
process tree, which starts out life with no tickets available (except for those
it had the sense to retrieve before establishing its own tree). Certainly the
current Kerberos scheme of storing tickets in a file on /tmp is unacceptably
insecure on timesharing machines.
Finally, we'd like to see a better replication scheme for the kerberos
database. When I create a new user, change a password, or whatever, I'd like
the operation to take effect as soon as the operation completes, at least
assuming that no network partitions have occurred (the problem gets *seriously*
difficult in the presence of network partitions). We'd like to write utilities
for administrators that do things like create new users, and in our
environment, this requires that Kerberos database operations complete before we
can proceed to create the new users' home dirs, as well as add them to the
appropriate user groups and other file system configuration tables.
Well, that's my first cut at a wish list.
Mike
------- End of Forwarded Message
--[0481]--
\f
[0482] daemon@TELECOM.MIT.EDU Kerberos 08/08/88 18:20 (16 lines)
Subject: Re: Completeness of DES_CRYPT(3)
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In principal, I don't see why not, especially since we intended to
keep the crypto as a separable component. But I haven't looked at the
documentation carefully for quite a while.
Both the string-to-key and pcbc_encrypt are straightforward. If needed,
I am sure that sufficient additional documentation for DES_CRYPT could be
done unambiguously. The string-to-key algorithm should be the same
across realms if the inter-realm authentication is used, and the keys
are defined (indirectly) using the string-to-key. E.g. the LCS Kerberos
appears as a member of the Athena realm, so if string-to-key is used to
setup their shared key, it had better be the same.
Steve
--[0482]--
\f
[0483] daemon@TELECOM.MIT.EDU Kerberos 08/09/88 10:04 (93 lines)
Subject: Mike's wish list
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
- ------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA21570; Thu, 4 Aug 88 10:27:37 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11479; Thu, 4 Aug 88 10:25:49 EDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00682> for steiner@athena.mit.edu; Thu, 4 Aug 88 10:25:07 EDT
Received: via switchmail; Thu, 4 Aug 88 10:25:00 -0400 (EDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.whitaker.andrew.cmu.edu.22f87369.7ca4c>;
Thu, 4 Aug 88 07:23:40 -0700 (PDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/kazar/.Outgoing/QF.whitaker.andrew.cmu.edu.22f87364.98a7d>;
Thu, 4 Aug 88 07:23:32 -0700 (PDT)
Received: from Version.6.20.N.CUILIB.3.44.SNAP.NOT.LINKED.whitaker.andrew.cmu.edu.rt.r3
via MS.5.5.whitaker.andrew.cmu.edu.rt_r3;
Thu, 4 Aug 88 07:23:31 -0700 (PDT)
Message-Id: <EWy7BXy00Uk-80TEpL@andrew.cmu.edu>
Date: Thu, 4 Aug 88 07:23:31 -0700 (PDT)
From: Mike Kazar <kazar+@andrew.cmu.edu>
X-Andrew-Message-Size: 4066+0
To: steiner@ATHENA.MIT.EDU
Subject: Fwd: Kerberos wish list
References: <MWxm8my00Uk-48PGIX@andrew.cmu.edu>
...
- - ---------- Forwarded message begins here ----------
Well, the heart of our wish list is Ted Anderson's ticket proposal that he sent
to the kerberos mailing list about a week ago. I'm assuming you've seen that
note; if not, send mail to me or to Ted (ota+@andrew.cmu.edu) and we can send
you a copy of the message. The key ideas in that message are (and I'm
over-simplifying here, so you should really read the original note):
More flexibility in specifying when a ticket is valid. We'd like to be
able to specify that a ticket will be valid for a longer period than is
possible now, and we would also like to be able to specify that a ticket
doesn't become valid until a certain time. Ted's proposes using a start
time and an end time, both in Unix date format seconds, to get this
functionality.
I certainly wish that tickets had only one format: network byte order. The
time to convert these things to a different byte order is essentially
trivial, and of course having only one format simplifies things.
It looks like there really is no need for placing the server's name and
instance into a ticket. That would probably reduce the size of tickets
considerably.
Aside from the ticket format, there are several other problems with the
Kerberos distribution as it stands now.
The Kerberos administrative protocols are UDP-based and non-idempotent, yet the
Kerberos code simply retransmits requests without any attempt to prevent a
request from multiple executions. This affects virtually every network request
except for the "get tickets" request. We strongly suggest the use of an RPC
mechanism here, and we're working with IBM to try to make our RPC and
light-weight thread package available essentially in the public domain if you
folks want to use it. Using an RPC mechanism has a significant effect on the
protocols, but we believe, based on our experience, that RPC interfaces are
quite easy to understand and well worth using in those circumstances where they
make sense.
Another "system design" level problem with Kerberos is the lack of a mechanism
for storing tickets for others to read. In the Andrew file system, we
associate tickets with process trees, and any process within a tree can get the
tickets for that tree. Any process can establish itself as the root of a new
process tree, which starts out life with no tickets available (except for those
it had the sense to retrieve before establishing its own tree). Certainly the
current Kerberos scheme of storing tickets in a file on /tmp is unacceptably
insecure on timesharing machines.
Finally, we'd like to see a better replication scheme for the kerberos
database. When I create a new user, change a password, or whatever, I'd like
the operation to take effect as soon as the operation completes, at least
assuming that no network partitions have occurred (the problem gets *seriously*
difficult in the presence of network partitions). We'd like to write utilities
for administrators that do things like create new users, and in our
environment, this requires that Kerberos database operations complete before we
can proceed to create the new users' home dirs, as well as add them to the
appropriate user groups and other file system configuration tables.
Well, that's my first cut at a wish list.
Mike
- ------- End of Forwarded Message
------- End of Forwarded Message
--[0483]--
\f
[0484] daemon@TELECOM.MIT.EDU Kerberos 08/11/88 08:31 (36 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
From: mts@emptys.cc.umich.edu (Michael T. Stolarchuk)
------------------------------------------------------------------
There has been some public announcement about the UofM-IBM
contract to develop the IFS (institutional file system).
The project is beginning with the AFS from CMU. We currently
plan to provide AFS facilites on our IBM 3090-600E, with
some more local intermediate servers. The AFS code will
be moved into an MVS environment, a CMS (VM/370) environment,
and of course AIX 370. We want to stay protocol compatable
with CMU so that we can use CMU's file systems too.
The project's goal is to provide an instituional wide
file system for all of the machines which want to be connected.
Services will be provided so that clients can connect to
the IFS, unaware of whether the operating system which is
providing the service is MVS.
Some University officials believe the UofM community will
need support for 30,000 workstations within a few years.
Currently the university has over 500 advanced function workstations,
and about 2000 public limited function workstations.
Because of the different vendors involved, and the different
environments, we will need some mechanism for distributed
authentication. We already have this problem with services
we would like to provide on the IBM mainframe -- printing and
backup services. Kerberos would help us begin integrating
these sevices into our distributed environment.
-------------------------------------------------------------------
--[0484]--
\f
[0485] daemon@TELECOM.MIT.EDU Kerberos 08/12/88 09:21 (24 lines)
Subject: Mis-Routed Messages
From: apollo!griffith_j@ATHENA.MIT.EDU
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: A message dated Thursday, August 11, 1988 6:15:34 pm (EDT)
Again - I received this message (griffith_j@apollo.com, griffith_j@apollo.uucp).
> Received: from RA.MIT.EDU by apollo.com; Thu, 11 Aug 88 17:45:29 EDT
> From: wesommer@ATHENA.MIT.EDU
> Received: by ra.mit.edu (5.51/4.7)
> id AA00951; Thu, 11 Aug 88 17:45:11 EDT
> Date: Thursday, August 11, 1988 5:45:11 pm (EDT)
> To: kerberos@ATHENA.MIT.EDU
> Subject: testing again.
>
>(Sorry about this, but mail from the real list doesn't seem to be getting
>through).
Looks to me like RA.MIT.EDU is going mental.....
-----
griff
--[0485]--
\f
[0486] daemon@TELECOM.MIT.EDU Kerberos 08/27/88 23:56 (30 lines)
Subject: picked up from eunet.general
From: henry@GARP.MIT.EDU (Henry Mensch)
To: kerberos@ATHENA.MIT.EDU
Reply-To: henry@GARP.MIT.EDU
> I am working on a software implementation of DES, and would like either
> another implementation or a set of test examples (plaintext block,
> key, ciphertext block in ECB mode) to verify the correctness of
> my version. So far in the small amount of literature I have looked at,
> I have found only 2 worked examples.
>
> When I am reasonably satisfied of the correctness of the code I will post
> it to eunet.sources (maybe to net.unix.sources, too).
>
> The code (if it is in fact correct) is quite fast: 2ms per cipher block
> on a VAX 11/785. I am working on a port to Sun. Some of the bit twiddling
> is byte-order dependent (UGH!).
>
> Peter Lamb prl@ethz.uucp, cernvax!ethz!prl
> Integrated Systems Lab. Phone: +41 1 256 5241
> Federal Inst. of Technology (ETH)
> Zurich, Switzerland
> --
> Peter Lamb
> uucp: seismo!mcvax!ethz!prl eunet: prl@ethz.uucp Tel: +411 256 5241
> Institute for Integrated Systems
> ETH-Zentrum, 8092 Zurich
--[0486]--
\f
[0487] daemon@TELECOM.MIT.EDU Kerberos 09/01/88 16:44 (24 lines)
Subject: random_key()
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>
I was using the Kerberos DES package to run some experiments and I discovered
that the random_key package doesn't behave very well. In particular my program
was calling random_key, calling key_sched, and encrypting one number. What I
descovered is that after 170 thousand keys, about one in five keys returned was
in the table of 170 thousand keys. In fact I was getting several duplicates
even after the first few thousand.
I looked at the code and discovered that it is calling srandom() every time you
ask for a random key. It uses the time of day and so forth to seed srandom(),
but then the key is constructed from the first two values returned by random().
I reimplemented it by adding an init_random_key() routine that calls srandom()
and have random_key() just call random() twice. In 64 000 calls to this new
random_key() I've found no duplicates.
I understand that although the period of random() is very long (something like
2^1000) its output isn't, in fact, all that random. Better random values are
can be obtained by using an encryption algorithm. Since this is all part of an
encryption package, and the call to random_key() doesn't need to be all that
fast, maybe this would be an even better approach.
Ted Anderson
--[0487]--
\f
[0488] daemon@TELECOM.MIT.EDU Kerberos 09/02/88 10:18 (18 lines)
Subject: Re: random_key()
To: Ted Anderson <ota+@andrew.cmu.edu>
Cc: Mike Kazar <kazar+@andrew.cmu.edu>,
In-Reply-To: Your message of Thu, 01 Sep 88 15:46:37 -0400.
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Ted,
Thanks for your message about problems with random_key.
Last I heard, Steve Miller was going to send Bill Sommerfeld
information about a cryptographic random number generator and
Bill was going to implement it. However, I don't know if or
when this will happen (Bill?) so it would be useful to have your
modifications in the interim. Could you post your diffs to
the mail list?
Thanks.
Jennifer
--[0488]--
\f
[0489] daemon@TELECOM.MIT.EDU Kerberos 09/02/88 15:55 (28 lines)
Subject: cbc_encrypt
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>
I've been reading up on encryption and ran accross a detailed definition of
cipher-block-chaining in "Cryptography: A New Dimension in Computer Data
Security", by Meyer and Matyas, John Wiley publisher, 1982; around page 70.
The basic idea of cipher block chaining is to provide feedback in the
encryption process that increases the effective block size of the cipher.
There are two basic ways to do this. One is uses ciphertext feedback and the
other uses plaintext-ciphertext feedback. Both accomplish hiding of patterns
in the clear text data. But only the latter accomplishes error propagation
during decryption. Since the insuring data integrity is a crucial aspect of
using DES to encrypt Kerberos tickets it is imperitive that we incorporate
plaintext feedback in our cipher-block-chaining. The Meyer&Matyas text was not
clear about which was the NBS approved method.
I looked at the code in the krb/src/lib/des/cbc_encrypt.c and found that it is
using only ciphertext feedback. A simple test program that inverted a single
bit of the first block of ciphertext produce the expected result upon
decryption. The first block of plaintext was totally garbaged, the second
block had the corresponding bit inverted and the subsequent blocks were
unaffected. I rewrote cbc_encrypt to use plaintext-ciphertext feedback (a very
simple mod) and it managed to garble all blocks of the plaintext. Is this a
known problem or did it just slip by?
If people are interested I can send a description of the fix to cbc_encrypt.
Ted Anderson
--[0489]--
\f
[0490] daemon@TELECOM.MIT.EDU Kerberos 09/02/88 16:00 (9 lines)
Subject: Re: random_key()
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>,
In-Reply-To: <8809021415.AA12823@BACH.MIT.EDU>
We're going to use an encryption based scheme for generating keys also. The
simplest fix to the existing random_keys is to move the code that calls
srandom(seed) into another function and call it just once. Then calling
random() twice and fixing up the key parity is all random_key needs to do.
--[0490]--
\f
[0491] daemon@TELECOM.MIT.EDU Kerberos 09/02/88 19:17 (8 lines)
Subject: Kerberos
From: Sam Drake <drake@IBM.COM>
To: kerberos%athena.mit.edu@RELAY.CS.NET
Hi, we're now subscribed to the Kerberos newsgroup, thank you, but
have not yet been given information about getting a copy of Kerberos
itself. Is there something that I need to do?
Thanks, ...Sam
--[0491]--
\f
[0492] daemon@TELECOM.MIT.EDU Kerberos 09/02/88 19:48 (14 lines)
Subject: cbc_encrypt
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU, kazar+@ANDREW.CMU.EDU
In-Reply-To: Ted Anderson's message of Fri, 2 Sep 88 15:47:46 -0400 (EDT) <kX7jfWy00VseI-iJZm@andrew.cmu.edu>
Barf. cbc_encrypt is DEFINED by the DES itself don't change
it. What you want to do is defined by the routine pcbc_encrypt() (I
don't remember exact what source module it is in). It is
pcbc_encrypt() that is used by the kerberos library for exactly the
reasons you mentioned. Last I checked it was not an "official" mode of
using DES, but it does what we want (it actually chains both ways,
using cipher text and plaintext).
-Jeff
--[0492]--
\f
[0493] daemon@TELECOM.MIT.EDU Kerberos 09/04/88 20:10 (26 lines)
Subject: rcp - a non-trivial problem
From: qjb@ATHENA.MIT.EDU
To: kerberos@ATHENA.MIT.EDU
One of the unresolved (to my knowledge) problems with Kerberos is
ticket forwarding. One of the manifestations of this is in rcp:
**=> m16-034-15:/mit/qjb <=**
% rcp priam:/mit/qjb/.cshrc paris:/mit/q/j/qjb/.cshrc
Kerberos rcp failed: No ticket file (tf_util).
trying normal rcp (/bin/rcp.ucb)
Permission denied.
Exit 1 rcp /mit/qjb/.cshrc paris:/mit/q/j/qjb/.cshrc
I haven't looked deeply into this, but I assume that rcpd on priam was
trying to go to paris.
Would it be possible for the "kerberized" rcp to grab the file from
the first host and copy it to the second when two hosts are involved,
is the a to b and then b to c routing there for a deeper reason that I
am not seeing right now?
Jay
P.S. I decided not to send this to bugs. If you think that it should
go to bugs, feel free to forward it...
--[0493]--
\f
[0494] daemon@TELECOM.MIT.EDU Kerberos 09/05/88 12:41 (30 lines)
Subject: re: rcp - a non-trivial problem
To: <qjb@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <qjb@ATHENA.MIT.EDU>'s message of Sun, 4 Sep 88 20:06:24 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> One of the unresolved (to my knowledge) problems with Kerberos is
> ticket forwarding. One of the manifestations of this is in rcp:
> . . .
> P.S. I decided not to send this to bugs. If you think that it should
> go to bugs, feel free to forward it...
Jay,
This problem is definitely not a bug, it is a limitation in the
current design, and will require some careful thinking to decide just
what design extension is the right one.
One reason why forwarding is not easy to work out is that your
ticket, in order to complicate the life of anyone who hopes to make a
killing by snatching a copy of the ticket from your workstation,
contains your network address inside. It isn't valid when used from
any other network address. A second reason is a strong feeling that
in forwarding situations, the ultimate target should receive
authenticated information that both the originater and the
intermediary are involved in the transaction, in case the target
cares. And, finally, any solution is likely to need to deal with
more than one level of forwarding.
Jerry
--[0494]--
\f
[0495] daemon@TELECOM.MIT.EDU Kerberos 09/05/88 13:43 (106 lines)
Subject: Re: rcp - a non-trivial problem
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: qjb@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <qjb@ATHENA.MIT.EDU>'s message of Sun, 4 Sep 88 20:06:24 EDT <8809050006.AA16400@M16-034-15.MIT.EDU>
Indeed you have stumbled onto a non-trivial problem. What
makes it non-trivial is that the solution is surrounded by complex
issues that effectively boil down to a tradeoff between security and
convenience (as is usually the case with "security" enforcing
software).
The issue here is how to get tickets on a host which is the
destination of an "rlogin" in a secure manner.
To start some facts:
The tickets in your ticket file are customized to work only
from the IP address they were issued to (it is stored in the ticket)
and are not transferable to another host.
The kerberos server will not (currently) issue tickets for an
IP address (host in other words) given a "ticket granting ticket" from
a different IP address.
The contents of your ticket file is confidential. If shipped
over the network in the clear your kerberos authenticity can be faked
(by those who intercept the network transfer).
Possible Solutions:
Solution 1:
After rlogin'ing in on the destination host. The user manually runs
"kinit" and gets tickets for the destination host.
Advantages:
It works. Already in place (ie. people can do this today, and do no
doubt).
Disadvantages:
Typed password is shipped over the network in the clear (and thus is
interceptable). Inconvenient.
Solution 2:
Modify kerberos server so that given a TGT (ticket granting ticket)
from one host, a TGT for another host can be fetched. Use this feature
to have the rlogin program fetch a TGT for the destination host and
ship it over (encrypted in the session key that "rlogin" and "rlogind"
have in common). Possibly do this only if an option appears on the
command line.
Advantages:
Convenient to use. "Does the right thing" from the (naive) user's point
of view.
Disadvantages:
Requires modification to the kerberos server. Is a marginal security
hole. Suppose for example I control host "B" and I walk up to your
terminal which is logged into host "A" (assuming you are elsewhere). I
can now rlogin to host "B" which deposits on host "B" a TGT for you
which is valid from host "B". Now I go and steal the ticket file
(because I control host "B" I can do this) and can now masquerade as
you for upto the ticket lifetime (which is measured in hours). Of
course after I have stolen the tickets I logout of "B" from your
terminal and clear the screen, you are none the wiser that your name
has been compromised.
Solution 3:
Modify rlogin and rlogind (actually klogind) so that as part of the
connection establishment protocol the "kinit" program is invoked on
the destination host to get you tickets. During the invocation of
"kinit" rlogin and rlogind are encrypting the connection so that the
password the user types is not sent in the clear. [There are actually
several ways to implement this that are slightly different then what I
describe above, but are semantically equivalent. The basic idea is
that the user is asked for a password which is securely transmitted to
the destination host for use in fetching tickets.]
Advantages:
Does not require modification to the kerberos server. Securely fetches
tickets on the destination machine (as opposed to solution 1 which
gets tickets in an insecure fashion). Requires that the user provide
his password explicitly so the security hole in solution 2 is not
present.
Disadvantages:
Slightly less convenient then solution 2 as the user has to type
his/her password. Generally unworkable from a shell script (ie. if you
wanted to write a shell script which invoked rlogin on some host and
then fed it commands to execute).
---
If I had my choice of solutions I would go for solution 3
above.
-Jeff
--[0495]--
\f
[0496] daemon@TELECOM.MIT.EDU Kerberos 09/05/88 15:48 (24 lines)
Subject: Re: rcp - a non-trivial problem
From: jb%cs.brown.edu@RELAY.CS.NET
To: "Jeffrey I. Schiller" <jis@BITSY.MIT.EDU>
Cc: qjb@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of "Mon, 05 Sep 88 13:38:56 EDT."
You only hit upon one problem that Jay(?) was having. His problem
was with rcp. Rcp never creates a login session on the remote machine.
By modifying rcp, Jay's problem can be fixed. Rcp currently handles
the third party transfers by doing an rsh to the src host and starting
up an rcp to the destination host. If rcp was modified to do the
transfer in two steps, it could work with "no" new authentication
problems. (The "no" is qualified because a new ticket will need to
be fetched.) The first transfer is to copy the src file to the
initiatiing machine. Next, copy the file to the destination machine.
There are some problems with this approach. First, there must be
enough disk space on the initiating machine to store the file temporarily.
The second problem is that there is twice as much network traffic
since the file is being transferred twice. The second problem
might be ignorable because I don't think third party transfers are
used much. (Was this the first time someone mentioned that a third
party rcp did not work under kerberos?)
Jim
--[0496]--
\f
[0497] daemon@TELECOM.MIT.EDU Kerberos 09/05/88 16:34 (67 lines)
Subject: Re: rcp - a non-trivial problem
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Cc: qjb@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Mon, 5 Sep 88 13:38:56 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> . . .
> Solution 2:
>
> Modify kerberos server so that given a TGT (ticket granting ticket)
> from one host, a TGT for another host can be fetched. Use this feature
> to have the rlogin program fetch a TGT for the destination host and
> ship it over (encrypted in the session key that "rlogin" and "rlogind"
> have in common). Possibly do this only if an option appears on the
> command line.
> . . .
> Disadvantages:
>
> . . .
> Is a marginal security hole. Suppose for example I control host
> "B" and I walk up to your terminal which is logged into host "A"
> (assuming you are elsewhere).
There is another plausible-sounding security attack if this solution
is used. Suppose I rlogin to another workstation or a time-sharing
system controlled by C, without realizing that C is not trustworthy.
Solution 2 obtains a fully valid ticket-granting ticket and stores it
on C's machine for the duration of my activity. Even if I destroy
that ticket on logout, there is plenty of time for C to have made a
copy of my TGT while I was logged in, which C can then continue to
use at leisure for all manner of services after I leave.
A similar scenario plagues the other solutions, too. One way to
reduce the exposure would be obtain only an ordinary ticket, rather
than a ticket-granting ticket, at the target machine.
On that basis, here is a solution 4 (only for the specific example of
rcp from C to D from A:
After obtaining the network address, but before opening a connection
to the rlogin server at C, use the TGT stored at A to obtain an rcmd
ticket for D, but specified to contain the network address of C.
(Kerberos change required to support this.) A opens an encrypted
connection to C and sends the rcmd ticket across the connection, then
asks C to perform the rcp to D. At logout, destroy the ticket.
Advantages:
The exposure at C is limited to the ability to do rcmd's to D under
A's identity for the duration of the ticket lifetime.
Disadvantages:
Not awfully general--originator at A has to know at outset what
ticket will be needed to accomplish the job at C. Every different
scenario is another case.
Two more comments:
1. None of these solutions generalize in an obvious way to multiple
levels.
2. For rcp/rcmd, it would seem appropriate to request (as default)
especially short-lived tickets, like ten minutes. The option of
using long-lived tickets should require asking for them explicitly so
the user has a chance to evaluate the exposure on long-running jobs.
Jerry
--[0497]--
\f
[0498] daemon@TELECOM.MIT.EDU Kerberos 09/07/88 14:50 (10 lines)
Subject: CBC vs PCBC
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
Mea Culpa! I should have read the help files more carefully. Thanks for the
clarifications.
On a related topic what does Kerberos assume for the value of the
Initialization Vector?
Ted Anderson
--[0498]--
\f
[0499] daemon@TELECOM.MIT.EDU Kerberos 09/07/88 15:26 (18 lines)
Subject: Re: CBC vs PCBC
From: Jon Rochlis <jon@BITSY.MIT.EDU>
To: Ted Anderson <ota+@ANDREW.CMU.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ted Anderson's message of Wed, 7 Sep 88 14:42:55 -0400 (EDT),
On a related topic what does Kerberos assume for the value of the
Initialization Vector?
Most calls to pcbc_encrypt seem to use the key itself as the
initialization vector. I caught some of the internal server-side
database routines using the key schedule for the ivec when I ran a
server on the RT. I stamped this out since the key schedule is
byte-order dependent and the key isn't.
-- Jon
--[0499]--
\f
[0500] daemon@TELECOM.MIT.EDU Kerberos 09/07/88 15:32 (15 lines)
Subject: CBC vs PCBC
From: rwu@ARRAN.BELLCORE.COM (Ronald W Underwood)
To: kerberos@ATHENA.MIT.EDU
I received the following by mistake:
>
>Mea Culpa! I should have read the help files more carefully. Thanks for the
>clarifications.
>
>On a related topic what does Kerberos assume for the value of the
>Initialization Vector?
> Ted Anderson
>
>
--[0500]--
\f
[0501] daemon@TELECOM.MIT.EDU Kerberos 09/07/88 19:45 (21 lines)
Subject: Re: CBC vs PCBC
From: "Stuart Levy" <slevy@UC.MSC.UMN.EDU>
To: jon@BITSY.MIT.EDU, ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU
Speaking of key byte order independence, that's something that seems to be
missing from the des_crypt(3) man page. The DES standard specifies keys and
data blocks in terms of 64-bit strings but doesn't talk about arranging them
on octet arrays as far as I can see. And des_crypt doesn't mention anything
about the format its routines use.
All the DES implementations I've seen -- including Kerberos' -- assign
DES bit 1 = 0x80 in the first byte, ..., DES bit 64 = 0x01 in the last byte
but it would be nice if that were written down. It would be pretty natural
to go the other way around and say DES bit <i> has significance 2 ** (i-1),
yielding bit 1 = 0x01 in the first byte, ... bit 64 = 0x80 in the last byte
on little-endian machines.
I'm surprised this hasn't caused more trouble.
Stuart Levy, Minnesota Supercomputer Center
slevy@uc.msc.umn.edu
--[0501]--
\f
[0502] daemon@TELECOM.MIT.EDU Kerberos 09/08/88 07:13 (19 lines)
Subject: Request for Information
From: usas@cup.portal.com
To: kerberos@ATHENA.MIT.EDU
Twice in the past couple of months I have attempted to request information
about the Kerberos authentication system developed at MIT. I understand
from a USENET posting that you have documentation and reports available.
So far, nothing has reached me.
Would you please acknowledge this message and send me the information you
have available for distribution?
Thank you very much.
---------------------------+-------------------------------------------------
Alan M. Usas | ARPA : usas@cup.portal.com
Tandem Computers | UUCP : {gateway}!sun!portal!cup.portal.com!usas
19333 Vallco Parkway 3-15 |
Cupertino, CA 95014-2599 | VOICE: 408-725-5037
===========================+=================================================
--[0502]--
\f
[0503] daemon@TELECOM.MIT.EDU Kerberos 09/12/88 15:48 (16 lines)
Subject: encryption question
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>
I noticed a comment in Birrell's Secure RPC paper that suggested that
exchanging cipher text blocks resulted in no error propagation. It wasn't
clear that they were using pcbc so I tried a test case. The result is that
using pcbc, switching two cipher text blocks fails to affect any subsequent
blocks of plaintext. Has a fix for this problem been decided upon? How about
xoring the block count in with the plaintext & cipher text?
Ted Anderson
I checked up on this a bit and it seems that they were using only an XOR
checksum. Perhaps a CRC checksum would have worked better for Birrell's
problem.
ota
--[0503]--
\f
[0504] daemon@TELECOM.MIT.EDU Kerberos 09/13/88 16:10 (12 lines)
Subject: encryption question
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
I am a little confused about the question from Ted Anderson. Is it about
the Kerberos DES-based pcbc encryption?
If the crypto algorithm is just an XOR, since XOR is commutative,
A XOR B = B XOR A
and you won't detect shuffled blocks. This is not the case with the
DES based pcbc_encrypt.
Steve
--[0504]--
\f
[0505] daemon@TELECOM.MIT.EDU Kerberos 09/13/88 16:30 (33 lines)
Subject: Re: random_key()
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
The problem of generating truly random and secret keys without a hardware
random number generator is difficult. Using a pseudo-random number
generator, the problem is reduced to providing a truly random seed that is
secret, i.e. can't be guessed. Most systems, such as the Unix or Ultrix
systems used for Kerberos, do not have much system "noise" to create a
good random seed. "Noise" can take the form of low order bits of the time
of day, system resource utilization, etc.
In the experiment reported by Ted Anderson, I believe that the system
noise used by the existing random_key routine was further minimized by
the nature of the experiment-- iterating random_key in a tight loop.
In the environment for which it was targeted, that is the Kerberos server,
there would be more variability than in such an experiment. This does not
suggest that the existing technique is good however. We did run some tests
of at least 10000 keys to verify that it was at least minimally adequate.
The reason we kept changing the seed was to prevent attacks where you would
get a key, then try to search the random number generator output until you
found the matching key, which could be done without exorbitant computation.
My documentation on random claims a period of 16*((2**31)-1).
Then, if a match was found, the attacker has a free lunch of subsequent
"random" keys.
A better solution, as Ted suggested, is to take the random number, or
even just a sequence number, and encrypt it under a secret key. While the
random_key code notes this in a comment, for reasons I don't recall it was
never implemented. Maybe we didn't want to require the presence of a
secret key to produce a random key.
Steve.
--[0505]--
\f
[0506] daemon@TELECOM.MIT.EDU Kerberos 09/14/88 10:14 (73 lines)
Subject: Re: encryption question
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
Cc: Mike Kazar <kazar+@ANDREW.CMU.EDU>
In-Reply-To: <8809132001.AA16517@decwrl.dec.com>
Let me try to be a little more clear.
There is a relatively obscure comment in the paper by Birrell called "Secure
Communication Using Remote Procedure Calls" where he mentions that the method
he suggests for detecting modifications to cipher text is inadaquate. He was
using standard CBC encryption with a message checksum at the end. He refers to
the Voydock and Kent article "Security Mechanisms in High-Level Network
Protocols" which I looked at. By implication the checksum he was using was a
simple XOR which was (probably then encrypted with CBC as) the last block of
the message. The weakness is that if an attacker swaps to adjacent cipher
blocks the checksum will not help detect the modification.
It was not entirely clear to me at first what method he was using so I figured
it would be a good idea to try it out with the Kerberos PCBC routine. As I
understand it Kerberos encrypts messages with PCBC which does a much better job
of ciphertext error propagation and so doesn't use a checksum at all. I wrote
a little program which just swapped the two first two bolcks of ciphertext
obtained from pcbc_encrypt of a simple message and then decrypted it. The
result was that the two exchanged blocks were garbled but no subsequent blocks
were affected.
Here is the program I used which also inverts a single bit in the ciphertext to
see what happens:
long msg[8]; /* this is a four block (64 bits each) message
*/
long out[8];
string_to_key ("abcdefgh", key);
code = key_sched (key, schedule);
for (i=0; i<8; i++) msg[i]=i;
print_msg ("Input message", msg, sizeof(msg));
pcbc_encrypt (msg, out, sizeof(msg), schedule, default_ivec, ENCRYPT);
print_msg ("Using Kerberos PCBC", out, sizeof(msg));
pcbc_encrypt (out, msg, sizeof(msg), schedule, default_ivec, DECRYPT);
print_msg ("Decrypted", msg, sizeof(msg));
/* invert the 32nd bit of the first ciphertext block */
out[0] ^= 1;
pcbc_encrypt (out, msg, sizeof(msg), schedule, default_ivec, DECRYPT);
print_msg ("Invert 32nd bit", msg, sizeof(msg));
out[0] ^= 1; /* set the bit back */
/* swap first two ciphertext blocks */
{ unsigned long temp;
temp = out[0];
out[0] = out[2];
out[2] = temp;
temp = out[1];
out[1] = out[3];
out[3] = temp;
}
pcbc_encrypt (out, msg, sizeof(msg), schedule, default_ivec, DECRYPT);
print_msg ("Exchanging first two ciphertext blocks", msg, sizeof(msg));
and here is the output:
Input message
00000000 00000001 00000002 00000003 00000004 00000005 00000006 00000007
Using Kerberos PCBC
fd09ff5a 90f9e7d0 bc58ef9f 400c9454 811a8b28 4138af1d a47698d4 c68a246d
Decrypted
00000000 00000001 00000002 00000003 00000004 00000005 00000006 00000007
Invert 32nd bit
6d4851de 177f7242 6d4851dd 177f7240 6d4851db 177f7246 6d4851d9 177f7244
Exchanging first two ciphertext blocks
fd09ff58 90f9e7d2 415110c7 d0f57387 00000004 00000005 00000006 00000007
Ted Anderson
--[0506]--
\f
[0507] daemon@TELECOM.MIT.EDU Kerberos 09/23/88 12:29 (8 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Keith Bostic, UC Berkeley:
We're interested in integrating Kerberos and Hesiod into the 4BSD
distribution. We'll be running it on CCI 6/32's, MIPs and VAXen,
approximately 15 machines.
--[0507]--
\f
[0508] daemon@TELECOM.MIT.EDU Kerberos 09/23/88 16:30 (44 lines)
Subject: DES Pseudorandom key generation
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
I have copied verbatim (except for possible typos!) Appendix C of
ANSI X9.17-1985, "Financial Institution Key Management (Wholesale)"
that describes a technique for producing pseudorandom DES keys and
IVs (initialization vectors). It requires a secret DES key pair, a
secret 64 bit-seed, the date and time, and multiple encryption operations,
making it fairly expensive in software. 'DEA' means the Data Encryption
Algorithm of DES.
The 'ede' operation using the key pair encrypts with the left key of the pair,
then decrypts with the right key of the pair, and finally encrypts with the
left key of the pair.
I don't know to what extent this is actually used currently, but presumably
it was designed for large $$ transactions.
Steve
----------------------------------------------------------
----------------------------------------------------------
C.1 Purpose
The purpose of this appendix is to present an example of a
pseudorandom key and IV generator.
C.2 Algorithm
Let ede*X(Y) represent the DEA multiple encryption of Y under
key *X. Let *K be a DEA key pair reserved only for the generation
of other keys, let V be a 64-bit seed value which is also kept
secret, and let + be the exclusive-or operator. Let DT be a
date/time vector which is updated on each key generation. I is
an intermediate value. A 64-bit vector R is generated as follows:
I = ede*K(DT)
R = ede*K(I + V)
and a new V is generated by V = ede*K(R + I).
To obtain a DEA key, every eighth bit is reset to odd parity.
To obtain an Initialization Vector (IV), R may be used directly.
--[0508]--
\f
[0509] daemon@TELECOM.MIT.EDU Kerberos 09/27/88 17:41 (26 lines)
Subject: new beta test site
To: kerberos@ATHENA.MIT.EDU
Cc: mar@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
From: David A Rasmussen <dave@csd4.milw.wisc.edu>
The University of Wisconsin - Milwaukee, Computing Services
Division, is a supplier of computing resources for researchers and
students on our campus. We currently maintain a Unisys 7000/40
supermini running 4.3 Tahoe source release, a Unisys 1100/81A
running Exec, a number of small 68010 based machines and VAXstations
to support our networking and printer traffic. We also provide
campus gateway services to supercomputer centers and the Internet
via an ISI 68010 box and some Proteon routers for other departments
who have their own machines including VAXen, workstations, and
assorted PC type machines.
We are currently looking into subnetting PC's with SLIP and
Ethernet, and Kerberos sounds like it may have applications in
the management of some of this. We are also expanding our user
management software to deal with mailing lists, project groups,
multiple machines, and such, and if and when SMS gets released,
hopefully we will have a basic understanding of Kerberos, which
it seems to depend upon. From reading the paper on SMS it
encompasses more than our equivalent package will as currently
planned.
--[0509]--
\f
[0510] daemon@TELECOM.MIT.EDU Kerberos 10/06/88 16:22 (8 lines)
Subject: NFS credentials
From: Doug Alan <nessus@ATHENA.MIT.EDU>
Reply-To: Doug Alan <nessus@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
With Athena's authenticated NFS system, what is the recommended method
of notifying the NFS server that its credentials file has changed?
|>oug /\lan
--[0510]--
\f
[0511] daemon@TELECOM.MIT.EDU Kerberos 10/06/88 16:59 (11 lines)
Subject: Re: NFS credentials
From: "Robert S. French" <rfrench@ATHENA.MIT.EDU>
To: Doug Alan <nessus@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Doug Alan's message of Thu, 06 Oct 88 16:16:42 EDT
rpc.mountd, which is the only program that uses the credentials file,
stats it every five minutes or so to see if it's been updated. If it
has, it rereads it...
Rob
--[0511]--
\f
[0512] daemon@TELECOM.MIT.EDU Kerberos 10/18/88 13:43 (61 lines)
Subject: Ticket Authentication
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
This is a follow up message to my earlier proposal for changes to the Kerberos
ticket format. That proposal is fairly long so I don't want to include it but
if anyone is interested in a copy, send me a note and I will forward you my
original message.
I've done some more reading on the problems of authentication and have concluded
that the current mechanism for detecting modifications of Kerberos tickets
should be augmented. The basic problem is that although plaintext-ciphertext
block chaining (pcbc_encrypt in the Kerberos distribution) is an improvement
over the DES Standard CBC mode of operation it still has several weaknesses.
These problems result in several simple modifications to the encrypted ticket
failing to propagate errors to the end of the ticket when it is decrypted.
Changes like swapping two ciphertext blocks or inserting blocks whose xor is
zero have this problem. While it isn't clear that these modifications will lead
to usable (for an intruder) changes to the decrypted ticket information, it is
hard to make a convincing case that no one will ever be able to exploit this
weakness.
Most authentication schemes rely on a cryptographic checksum appended to the
message which is then encrypted (if secrecy is desired) using CBC mode. While
using DES for the checksum seems excessively expensive for Kerberos, a simpler
hash function would still be useful. A very cheap solution is to append the
arithmetic sum of all the bytes in the ticket. A better function is suggested
in the X.509 draft standard for directory authentication. It uses
multiplication with a suitably chosen modulus to combine the blocks to be
checksummed. A modulus less than 2^16 and a block size of 8 bits should result
in a inexpensive algorithm for most machines that can do small multiplies nearly
as fast as adds.
The more fundamental issue in authentication is that the message being
authenticated must contain sufficient redundancy to make it unlikely that a
random message would be accepted. Adding a 16 bit checksum is really just
adding 16 bits of redundancy. However, the redundancy is distributed over the
whole message such that a modification to any bit is equally likely to produce
an incorrect checksum. In contrast, inserting two zero blocks into a ticket at
a point within the name has a probability of (255/256)^16 (or about 94%) of
going undetected, at least as far as format goes.
Since I earlier suggested removing the server name from the ticket using the
argument that it was redundant, it seems appropriate to give some attention to
the total redundancy in the ticket. Here is a list of fields and the
approximate (in some cases very approximate) redundancy of each.
flags: 8 bits. Assuming only one value is legal.
session key: 8 bits. The parity requirement on DES keys provides a bit per
byte.
name, instance, realm: 24 bits. The requirement that each end with a null
supplies about 8 bits each, the length limits and the requirement that the
name is at least one character long provides only a small additional amount.
host address: 32 bits. Assuming this is checked, and there is only one
correct host address.
starttime, endtime: 16 bits. I assumed 128K seconds as the maximum lifetime
and a bit for the fact that the interval must be positive.
This totals 88 bits plus the 16 bits of checksum. A very respectable amount.
I'm very interested in comments and suggestions on this suggestion as well as
the other aspects of the ticket proposal.
Ted Anderson
--[0512]--
\f
[0513] daemon@TELECOM.MIT.EDU Kerberos 10/18/88 17:47 (23 lines)
Subject: installing kerberos
From: David A Rasmussen <dave@CSD4.MILW.WISC.EDU>
To: kerberos@ATHENA.MIT.EDU
Forgive my stupid questions regarding making this beast, but I am hung up
on the lib/des directory where in make depend it builds a bunch of
include files like:
# Generated files
GFILES = \
./key_perm.h \
./p_table.h \
./s_table.h \
./odd.h \
./e.c \
./p.c \
./s.c \
./fp.c \
./ip.c
My make runs until it dies at p_table.h. make_ptable works fine if I execute
it myself. Just wondering if anyone had any makefile patches or anything
before I figure out that a slash or something else is missing somewhere. ;-?
--[0513]--
\f
[0514] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 01:02 (9 lines)
Subject: Re: installing kerberos
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: David A Rasmussen <dave@csd4.milw.wisc.edu>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: David A Rasmussen's message of Tue, 18 Oct 88 16:40:13 CDT,
Hmm ... des makes some files (I think these) during the make depend
phase of things. Did you do a "make depend"?
-- Jon
--[0514]--
\f
[0515] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 07:35 (47 lines)
Subject: An idea for forwarding access to remote machines
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: athena-ws@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I rlogin to multiple machines in my normal work -- the sipb RT server,
my E40 VS2000 (if I am not on it), charon, and occaisional other
machines. Typing my password over the net is obviously wrong (grabbing
passwords typed over the net is more than just a theoretical
possibility) and yet at times I need to authenticate myself from the
remote machine to my file server (and homedirectory) in order to
transfer files (examples: using macsyma or scheme on my VS2000, or
running andrew on the SIPB RT (with 32Meg of swapspace) when I am not
on the apropriate machine type.)
Fortunately, I am a watchmaker, and have root access to priam (my file
server.) Thus I can kinit with my root instance, rlogin to priam as
root, and use `nfsc' by hand to tell priam to create a mapping for me
from whatever remote machine I am using. I have found myself doing
this often enough that I now have an alias for it.
However, I am starting to think that this might be more generally
useful. Providing root access to the server is clearly excessive (that
is: WRONG) but perhaps providing an extension to the nfsid mapping
protocol to allow `proxy mappings', where I present tickets to request
that a mapping from another machine be created.
Note that this is not identically equivalent to the problem of
forwarding tickets to remote machines, as it is not transitive. The
authentication itself is still tied to the machine I am sitting in
front of; I am using this authentication to authorize other machines
to access my files.
One of the classic arguments against `ticket forwarding' is that if I
am away from my terminal for a moment, someone can forward my tickets
to another machine where they can use them to do me harm, without my
being able to revoke that access. If `proxy mappings' are in some way
tied to the authorizing host, then the `flush mappings for this host'
nfsid request can be extended to also `flush mappings authorized by
this host', thus limiting this form of damage somewhat.
Comments? Would this indeed be useful, and which flaws does this
design have that make it impractical?
Mark Eichin
<eichin@athena.mit.edu>
SIPB Member & Project Athena ``Watchmaker''
--[0515]--
\f
[0516] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 13:04 (9 lines)
Subject: An idea for forwarding access to remote machines
From: mar@ATHENA.MIT.EDU
To: eichin@ATHENA.MIT.EDU
Cc: athena-ws@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Mark W. Eichin's message of Fri, 21 Oct 88 07:27:55 EDT <8810211127.AA00466@OLIVER.MIT.EDU>
I would find proxy file mappings very useful. I do a lot of work in a
different kerberos realm, and it is very difficult for me to get nfs
mappings for the hosts in that realm.
-Mark
--[0516]--
\f
[0517] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 13:09 (15 lines)
Subject: Miscellaneous low level Kerberos questions
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
What does Kerberos do about byte order for machines that are neither purely
little or big endian? For instance the 286 just byte swaps the halfwords of a
long or something. How about if such a machine converts to one or the other of
the existing machine types on output? This seems much better than teaching all
existing implementations about yet another machine type.
I gather that the ticket flags field encodes the byte order but it isn't clear
from the documentation which bit of the flag it used for this. LSB?
Am I correct in assuming that the kvno of the key used to encrypt a ticket is
always passed around with the ticket? Can a ticket be interpreted with out one
(perhaps by trying all plausible keys)?
--[0517]--
\f
[0518] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 14:45 (28 lines)
Subject: re: An idea for forwarding access to remote machines
To: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
Cc: athena-ws@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Mark W. Eichin <eichin@ATHENA.MIT.EDU>'s message of Fri, 21 Oct 88 07:27:55 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> If `proxy mappings' are in some way tied to the authorizing host,
> then the `flush mappings for this host' nfsid request can be extended
> to also `flush mappings authorized by this host' . . .
Mark,
In order for that to work, you need to come up with a bright idea for
automatically deciding when to run nfsid flush and which servers to
send it to. Telling the user to do it by hand misses the interesting
case where someone else authorizes a proxy while I was distracted by
a bull session in the next aisle. (unless the intruder happens to
send proxy authorizations only to servers where you already have an
ordinary mapping.)
Possibly the server should refuse to accept authorization of proxy
mappings unless there is already an ordinary mapping for the
authorizing user. Then, your suggested extension to nfsid/flush
would have the effect that whatever mechanism that user relies on to
flush the ordinary mapping can also be relied on to flush the
proxies. (But you have to think through unmap, too.)
Jerry
--[0518]--
\f
[0519] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 15:36 (42 lines)
Subject: An idea for forwarding access to remote machines
From: probe@ATHENA.MIT.EDU
To: Saltzer@ATHENA.MIT.EDU
Cc: eichin@ATHENA.MIT.EDU, athena-ws@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Fri, 21 Oct 88 14:33:53 EDT <8810211833.AA04474@HERACLES.MIT.EDU>
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
> Date: Fri, 21 Oct 88 14:33:53 EDT
> From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Sender: Saltzer@ATHENA.MIT.EDU
> Repository: heracles
> Originating-Client: E40-391A-1
> > If `proxy mappings' are in some way tied to the authorizing host,
> > then the `flush mappings for this host' nfsid request can be extended
> > to also `flush mappings authorized by this host' . . .
> Mark,
> In order for that to work, you need to come up with a bright idea for
> automatically deciding when to run nfsid flush and which servers to
> send it to. Telling the user to do it by hand misses the interesting
> case where someone else authorizes a proxy while I was distracted by
> a bull session in the next aisle. (unless the intruder happens to
> send proxy authorizations only to servers where you already have an
> ordinary mapping.)
> Possibly the server should refuse to accept authorization of proxy
> mappings unless there is already an ordinary mapping for the
> authorizing user. Then, your suggested extension to nfsid/flush
> would have the effect that whatever mechanism that user relies on to
> flush the ordinary mapping can also be relied on to flush the
> proxies. (But you have to think through unmap, too.)
There is an option to nfsid that will flush all of a user's mappings to
a given host (nfsid -r host). Unfortunately, becuase the KUIDUPURGE
code is broken in the current release of rpc.mountd, this does not work
as expected (actually, the KUIDUPURGE code was missing). "Fixed in the
next release".
-Richard
--[0519]--
\f
[0520] daemon@TELECOM.MIT.EDU Kerberos 10/21/88 15:58 (21 lines)
Subject: yabts (yet another beta test site)
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
Robert Van Cleef (NASA Ames Research Center)
vancleef@prandtl.nas.nasa.gov
The NAS programming network consists of the following systems:
2 Cray 2's Running UNICOS 4.0
an Amdahl 5880 Running UTS 1.2.2
VAX 11/780's running BSD 4.2
25 IRIS 2500T workstations running SGI 3.5 Unix
15 IRIS 3100 workstations running SGI 3.5 Unix
15 IRIS 4D workstations running SGI 3.0 Unix
21 Sun 3 workstations running SunOS 3.5
All systems are connected through a combination of ethernet and
HYPERchannel using TCP/IP.
Our goal is to evaluate Kerberos for trusted links for systems
administration and support functions.
--[0520]--
\f
[0521] daemon@TELECOM.MIT.EDU Kerberos 10/24/88 14:42 (33 lines)
Subject: Re: Misc Kerberos questions
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
>From: DECWRL::"ota+@andrew.cmu.edu" "Ted Anderson 21-Oct-88 1302 EDT" 21-OCT-1988 13:46
>To: kerberos@athena.mit.edu
>Subj: Miscellaneous low level Kerberos questions
>
>What does Kerberos do about byte order for machines that are neither purely
>little or big endian? For instance the 286 just byte swaps the halfwords of a
>long or something. How about if such a machine converts to one or the other of
>the existing machine types on output? This seems much better than teaching all
>existing implementations about yet another machine type.
My recollection of the 286, from porting the Kerberos code to a PC-AT, is that
it is little endian. But if such a weird beast did exist, yes, it should mimic
either a little endian or big endian machine.
>I gather that the ticket flags field encodes the byte order but it isn't clear
>from the documentation which bit of the flag it used for this. LSB?
Yes, the LSB. The documentation should be fixed to make this clear.
>Am I correct in assuming that the kvno of the key used to encrypt a ticket is
>always passed around with the ticket? Can a ticket be interpreted with out one
>(perhaps by trying all plausible keys)?
Yes, it is passed in cleartext as a hint to tell the receiver
what key to use. In principle, the receiver could try multiple keys if it
wanted, but I don't remember if the existing interface directly supports that.
Trying multiple keys would be very expensive when the number of possibilities
is greater than one, such as when a server is in the process of changing
its key, yet doesn't want to invalidate outstanding tickets.
Steve.
--[0521]--
\f
[0522] daemon@TELECOM.MIT.EDU Kerberos 11/01/88 18:47 (9 lines)
Subject: configuring kerberos
From: Gary Veum <veum@AMELIA.NAS.NASA.GOV>
To: kerberos@ATHENA.MIT.EDU
From the Installation Notes (DRAFT), May 11, 1988, it doesn't really specify
where to set up the hardware specific dependencies. I am attempting to
build it on a Sun 4.0 system.
Thank you.
-Gary Veum
--[0522]--
\f
[0523] daemon@TELECOM.MIT.EDU Kerberos 11/01/88 19:00 (5 lines)
Subject: test
From: Robert E. Van Cleef <vancleef@PRANDTL.NAS.NASA.GOV>
To: kerberos@ATHENA.MIT.EDU
testing the kerberos alias on prandtl
Bob
--[0523]--
\f
[0524] daemon@TELECOM.MIT.EDU Kerberos 11/02/88 10:59 (104 lines)
Subject: Re: Ticket Authentication
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
(** This may be a duplicate, may mailer returned it to me claiming unsent. *)
This message is in response to Ted Anderson's mail of Oct 18, 1988.
I agree that the problem with the pcbc_encrypt should be fixed. However,
it is not a backwards compatible fix, and any tickets outstanding or
data stored encrypted with the old pcbc will be trashed.
There are a number of ways to fix it. You could add a DES MAC, quad_cksum,
CRC, or some other form of checksum computed over the cleartext message.
The checksum would then be encrypted as part of the message (ticket).
But any of the checksum or MAC type approaches both cost time for the
checksum computation, which is very significant in the case of a DES MAC,
and cost additional encryption overhead by lengthening the ticket.
I would therefore recommend fixing it by fixing the pcbc_encrypt routine
to properly detect swapped blocks. Basically, we got it wrong, but I don't
feel bad since the same wrong solution was published by others as well.
I talked to one of our crypto experts, and came up with a variation
that seems to work. The basic difference is that when encrypting block N,
instead of XORing the cleartext from block N-1 with the CLEARTEXT
for block N prior to encrypting block N, the cleartext from block N-1
is XORed with the CIPHERTEXT resulting from encrypting block N. I have
attached a schematic describing this at the end of this message. I hacked
up a version of this, and tried it out, and it did successfully detect
swapped ciphertext blocks and other modifications, propagating the errors
thru to the end of the decrypted cleartext.
In terms of the redundancy of the ticket, I believe that it is more than
adequate, given a fix to pcbc as outlined above. Ted's note underestimates
the effective redundancy in the ticket, since there are strong semantic
constraints on the values contained in the tickets above and beyond the fact
that the strings are null terminated, the key has parity, etc.
So I would not include a checksum. When encrypting arbitrary data with no
known semantic constraints a checksum/MAC should be used, but Kerberos
tickets are not in this category.
The server name in the ticket provides more than just redundancy. Without
it, if two different servers (or instances) happened to use the same master
key, and I got a ticket for one, it would also be valid at the other.
Since master keys are derived from strings typed in by people, it is likely
that multiple servers (or instances) would have the same key, especially
if an administrator is responsible for multiple servers.
Steve
\f
Legend:
let P0...Pn represent blocks of plaintext
let C0...Cn represent blocks of ciphertext
let XOR be the XOR operation
let E be the DES ECB Encrypt operation
let D be the DES ECB Decrypt operation
let IV be the initialization vector
let K be the DES session key.
---------------------------------------------------------------------------
New pcbc encrypt, also detects misordered ciphertext blocks and insertions
P0 >-+ P1
| | |
| | |
v | v
IV --> XOR | +----->XOR
| | | |
| | | |
v | | v
K ---> E | | K -->E
| | | |
| | | |
v | | v
0 --> XOR +---|----->XOR
| | |
| | |
v | v
C0 >----+ C1
==============================================================================
Decrypt
C0 >-+ C1
| | |
| | |
v | v
0 --> XOR | +----->XOR
| | | |
| | | |
v | | v
K ---> D | | K -->D
| | | |
| | | |
v | | |
IV -->XOR +---|----->XOR
| | |
| | |
v | v
P0 >----+ P1
--[0524]--
\f
[0525] daemon@TELECOM.MIT.EDU Kerberos 11/03/88 15:33 (10 lines)
Subject: Inter-Realm Access
From: Ted Anderson <ota+@andrew.cmu.edu>
To: kerberos@ATHENA.MIT.EDU
I've read the Kerberos document section on cross-realm authentication. It has a
distinctly tentative feel to it as if few installations actually use it. Are
there Kerberos users making extensive use of the cross-realm features and is
there a more detailed description of the protocols? I'm hoping for a list of
dos, don'ts, hints, caveats, and provisos that would be helpful to look at.
Thanks,
Ted Anderson
--[0525]--
\f
[0526] daemon@TELECOM.MIT.EDU Kerberos 11/03/88 17:22 (54 lines)
Subject: Re: Inter-Realm Access
From: sommerfeld@apollo.com
To: ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ted Anderson's message of Thursday, November 3, 1988 3:29:28 pm (EST)
The interrealm mechanism works; however, it seems to require more
support from the application than many application writers seem to
want to provide.
The biggest problem on the client side is the question of "what realm
is this server or service in"?
Currently, this is handled by the use of what some call a heuristic,
but I call a kludge: the domain of the host (everything after the
first `.') is used as its realm, with the exception that (for historic
reasons; you really _don't_ want to know why) the domain MIT.EDU maps
to the realm ATHENA.MIT.EDU. This is under the control of a
configuration file on the client side, accessed through the use of a
library routine. I've been kicking around the idea of replacing the
configuration file with some sort of a "secured" nameservice. (It
should be obvious why the nameservice has to be secure).
The equivalent problem on the service end is "what do I do now that
this remote user claims to be in a completely different realm?". This
is just an authorization decision like any other.
In answer to your question about major interrealm kerberos users, I
believe the biggest (in terms of number of tickets requested) is
"discuss", a networked conferencing system. It doesn't have a concept
of a "unix user"; all its authorization decisions are made by looking
for the kerberos principal name of its caller on an access control
list.
The protocol for interrealm access is basically this: if I am user X
in realm A, and want to talk to service Y in realm B, I first need a
ticket granting ticket for realm A (a ticket for krbtgt.A@A), which I
presumably picked up at login time. I can then get a ticket for B's
ticket granting service, granted by A (a ticket for krbtgt.B@A), and I
can then present that to B's KDC to get a ticket for Y@B. However,
all these details are hidden under the covers.. all the applications
programmer has to do is come up with the realm of the server as a
parameter to krb_mk_req.
The application's service doesn't have to do anything "special" to get
it to work; the system managers of the two realms merely have to come
up with a shared secret.
One common error is forgetting to check the realm or instance of the
decoded authenticator, thus allowing user "joe@B" to have all the
access of "joe@A"; from the point of view of interface design, I think
that this error would have been harder to make had kerberos names been
a specific datatype, as opposed three strings travelling together...
- Bill
--[0526]--
\f
[0527] daemon@TELECOM.MIT.EDU Kerberos 11/04/88 11:12 (21 lines)
Subject: Re: Ticket Authentication
From: Ted Anderson <ota+@ANDREW.CMU.EDU>
To: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller), kerberos@ATHENA.MIT.EDU
In-Reply-To: <8811021547.AA02650@decwrl.dec.com>
When I was looking at variations on block chaining I considered something like
this but it seems dangerous to put the clear text one XOR from the data that
goes out over the wire. A compromise of any piece of cleartext may allow an
attack to discover certain cipher text blocks which could then be used to reveal
clear text in a different message. This is a little fuzzy but it just seemed
like a bad idea.
The important concern about the redundency of tickets is that there are large,
easily located areas of the ticket that have very low redundency (ie the name
and instance). These would make relatively easy targets for insertion attacks.
The checksum I favor is a two byte variant on the quad cksum which should be
quite cheap to implement. It costs roughly a 16x16 bit multiply and a modulus
operation per byte. This seems to run an order of magnitude faster an a single
DES so it should be a performance problem. A checksum like this has the
advantage that it protects you against any current or future problems with cbc
or its variants.
Ted Anderson
--[0527]--
\f
[0528] daemon@TELECOM.MIT.EDU Kerberos 11/07/88 11:04 (27 lines)
Subject: Re: Ticket Authentication
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
As Ted pointed out, the new "pcbc" mode I suggested in a Nov 2 memo is no good -
the cleartext could be recovered by an exhaustive search of XORs. I retract
the suggestion-- the cure was worse than the disease. Our crypto guy also
realized this, but unfortunately not until after I had sent the note out.
So much for ad-hoc design.
It still may be possible to construct a modified pcbc mode with the desired
properties by using other operations on the plaintext. For example, instead
of XORing the plaintext, as in the original Kerberos pcbc, add a running sum
of all the plaintext blocks. (I don't know if this particular one works.)
Some such solutions will be data sensitive. I don't have time to play with
these.
So my revised recommendation is that for the next version of Kerberos other
possible pcbc modes are investigated. If a satisfactory one is found that
always propagates errors (doesn't resync), even if two ciphertext blocks are
switched, is not particularly data sensitive, and doesn't put a simple function
of the plaintext on the wire, use it. Otherwise, use vanilla cbc mode and
add a checksum to the end of the ticket, as Ted suggested. The checksum
should be inexpensive to compute compared to DES itself. I have been very
reluctant to add a checksum because even if the checksum calculation is free,
it adds to the length of the ticket, and therefore the DES encryption costs.
Steve.
--[0528]--
\f
[0529] daemon@TELECOM.MIT.EDU Kerberos 11/07/88 12:19 (16 lines)
Subject: Re: Ticket Authentication
To: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
Cc: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In-Reply-To: miller%erlang.DEC@decwrl.dec.com (Steve Miller)'s message of 7 Nov 88 10:30
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> As Ted pointed out, the new "pcbc" mode I suggested in a Nov 2 memo
> is no good - the cleartext could be recovered by an exhaustive search
> of XORs. I retract the suggestion-- the cure was worse than the
> disease. Our crypto guy also realized this, but unfortunately not
> until after I had sent the note out. So much for ad-hoc design.
Would someone be so good as to remind me just how serious is the
disease for which this particular modification, had it not been a
loser, would have been a cure?
Jerry
--[0529]--
\f
[0530] daemon@TELECOM.MIT.EDU Kerberos 11/08/88 13:26 (15 lines)
Subject: new project leader
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
John Kohl <jtkohl@athena.mit.edu> will be taking over
responsibility for leading the Kerberos development
project at Athena. John graduated from MIT last year
and is now a DEC employee working full-time at Athena.
During his undergraduate career at MIT, he worked on
various Athena projects, including Kerberos and the
Zephyr Notification System.
I'll still be working on Kerberos for a while, mostly
working on some documents that need to be written.
Jennifer
--[0530]--
\f