Date: Tue, 18 Sep 90 13:43:55 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: jfc@ATHENA.MIT.EDU, swick@ATHENA.MIT.EDU, krbdev@ATHENA.MIT.EDU
interesting...perhaps some collaboration is in order?
------- Forwarded Message
To: jtkohl@ATHENA.MIT.EDU
Cc: rws@expo.lcs.mit.edu
Subject: kerberos for X11R4 server authorization
Date: Tue, 18 Sep 90 11:28:06 -0400
From: Vick Khera <khera@cs.duke.edu>
Earlier this summer I contacted you for information about using
Kerberos for X server connection authorization. Since you indicated
that there was no known work in this area currently being done, I went
ahead and did the necessary work. Below is the release I plan on
announcing in comp.windows.x and comp.protocols.kerberos sometime
soon. Do you think there will be interest in this scheme? My
intention is to propose it as another standard alternative to
MIT-MAGIC-COOKIE-1 similar to XDM-AUTHORIZATION-1 for the next release
of X from MIT.
If there has been any other work done with this, please let me know.
Note that the tar file mentioned in the release is not yet on line,
but if you wish to take a look at it we can make arrangements.
MCNC has granted permission for me to freely distribute the modified and
new software.
v.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vick Khera Gradual Student Department of Computer Science
ARPA: khera@cs.duke.edu Duke University
UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528
---cut here---
Kerberos Security for The X Window System
Vivek Khera
Duke University Computer Science Dept.
Durham, NC 27706
e-mail: khera@cs.duke.edu
Support for Kerberos authenticated and authorized server connections
has been merged into the MIT X11R4 sample server. The support is
implemented in the form of a server extension to maintain an access
control list, and some necessary modifications to the server and
library. Additional support for starting the server must be provided,
and the current implementation uses xdm (with the needed modifications.)
The extension provides a mechanism for dynamically modifying the list
of users authorized to connect to the server. Only users listed may
connect to the server after providing the proper credentials which are
authenticated by Kerberos. The client must be linked with the new
version of the library routine XOpenDisplay() which passes the needed
information for Kerberos to make the determination of the authenticity
of the user. If Kerberos approves, then the access control list is
consulted and the connection is either allowed or disallowed. If
Kerberos disapproves, then the connection is not allowed. The
mechanics of the authorization scheme work similarly to
XDM-AUTHORIZATION-1.
The files and patches needed to implement the extension and the
Kerberos support are available for anonymous ftp in a file called
pub/x11r4-kerberos.tar.Z on the host cs.duke.edu (128.109.140.1). A
paper describing the system is also available by contacting the author
at the e-mail address above.
The server was implemented and tested on a VAXStation 2000 running 4.3
BSD Unix. The clients have also been tested on a Convex C2.
This work was done while the author was at the Microelectronics Center
of North Carolina in Research Triangle Park, NC. The author is
currently associated with Intelligent Data Sciences, Inc., of
Rockville, MD.
------- End Forwarded Message
To: Vick Khera < khera@cs.duke.edu>
Cc: jtkohl@ATHENA.MIT.EDU, swick@ATHENA.MIT.EDU, keith@expo.lcs.mit.edu
Subject: Re: kerberos for X11R4 server authorization
In-Reply-To: Your message of Tue, 18 Sep 90 11:28:06 EDT.
< 9009181528.AA06523@thneed.cs.duke.edu>
Date: Tue, 18 Sep 90 19:02:28 -0400
From: rws@expo.lcs.mit.edu (Bob Scheifler)
We (Project Athena and the X Consortium) currently have plans to include support
for Kerberos version 5 in X11R5. The precise interface (e.g. whether or not
we can get away with no protocol extension) is still being worked on. Certainly
we'd like to take a look at what you've done, although we don't want to be
bound by it. I think there will be interest in Kerberos support; what problems
might arise from our using a different implementation downstream, I don't know.