Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!mit-eddie!bloom-beacon!athena.mit.edu!steiner From: steiner@athena.mit.edu (Jennifer Steiner) Newsgroups: comp.unix.wizards Subject: Re: Who dat? Summary: use an authentication server Keywords: Kerberos Message-ID: <6104@bloom-beacon.MIT.EDU> Date: 10 Jul 88 16:19:42 GMT References: <199@stca77.stc.oz> <2310@rtech.rtech.com> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: steiner@athena.mit.edu (Jennifer Steiner) Organization: Massachusetts Institute of Technology Lines: 43 In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >On a single machine, we have a suid server process. A random client >program wishes to connect and have the server perform some services. The >server wants to know who the client is before doing anything. They might >be communicating with sockets, fifos, msgs, or shared memory. > >How can the server find out who the client is, in a spoof-proof and >secure way? Project Athena has an authentication service (called Kerberos) which we use to deal with this problem. Here's a simplified description of how it works: There's a trusted, secure authentication server which knows the keys (like passwords) of all its clients - both users and network servers have keys. When a program running on behalf of a user wants to authenticate the user's identity to some server, it goes to Kerberos (the authentication server) and requests a "ticket" for the server. Kerberos creates and returns the ticket to the user. The ticket is encrypted in the server's key and contains the identity of the user. When the user's program contacts the network server, typically the first thing it sends is this ticket. The server decrypts it to find out the identity of the user. Since only the server and Kerberos know the server's key, and the ticket is encrypted in the server's key, the server knows that the ticket was issued by Kerberos and believes what it says about who the user is. Issues that I won't go into in detail here, but that Kerberos does deal with, include: authenticating the user to Kerberos in the first place; authenticating the server back to the client; allowing the client to re-use a ticket for a given server without allowing impostors to use "re-use" it too; distributing a temporary encryption key to the client and server so that they may encrypt their communication; expiration of tickets; etc. If you're interested in the gory details, you can get documents via anonymous ftp from "athena-dist.mit.edu" (18.71.0.38). Jennifer Steiner P.S. Kerberos is in beta test now. We don't yet know when or how we'll make it generally available, but we'll post a message when we do.