[6649] in Kerberos
Re: how to use kinit.c code w/o putting TGT in a file?
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Feb 15 00:54:09 1996
To: scott@talarian.com (Scott Weitzenkamp)
Cc: kerberos@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 15 Feb 1996 00:24:41 -0500
In-Reply-To: scott@talarian.com's message of Wed, 14 Feb 1996 22:28:44 GMT
>>>>> "Scott" == Scott Weitzenkamp <scott@talarian.com> writes:
Scott> In article <tsl20o3xiad.fsf@tertius.mit.edu>, Sam Hartman
Scott> <hartmans@MIT.EDU> wrote:
Scott> We have KDC and a Kerberized server program behind a
Scott> firewall providing lots of data access to a WWW server
Scott> sitting outside the firewall. The WWW security FAQ refers
Scott> to this WWW server configuration as the "sacrificial lamb".
Scott> I'm pretty new to Kerberos and WWW so I don't claim to
Scott> understand all the subtle nuances of running the WWW server
Scott> inside vs outside the firewall. I'm just providing the
Scott> network programming services and making sure it is secure
Scott> with Kerberos.
Scott> My main question is how to configure a Kerberized client
Scott> program sitting outside the firewall on the WWW server
Scott> machine. The client program will be initiated by a user
Scott> action from the WWW server (via a cgi-bin script, I am
Scott> told). Thus the client program has to be able to run
Scott> unattended.
Well, this is not always true; you could always ask the user
of the CGI script to provide the password, but if you are making data
available to the public (it sounds like you are), this is generally
not an acceptable option. So, you should use a keytab file. There
are several advantages to the keytab file: it can be changed without
recompiling the client, etc. Then, you need to get a credentials
cache; you can do this by calling krb5_get_in_tkt_with_keytab directly
or calling kinit -k. (This should be repeated at least once every
ticket lifetime.)
Scott> Do I use a keytab file and have the client program read
Scott> that? If so, then if someone steals my keytab file they
Scott> can impersonate the client. Chances are if they steal the
Scott> keytab file they can steal the client program executable
Scott> too (they will probably have the same stealibility)
Scott> That's why I thought it would be more secure to store a
Scott> password in the client program. If a bad guy steals the
Scott> client program they can run the program and cause trouble,
Scott> but at least they don't have a keytab file to cause further
Scott> mischief with.
Never design a protocol that trusts a client program to be
well behaved; all access checking and request sanity checking should
take place in the server. Also, it's fairly given the parity of DES
keys to extract them from an executable without trouble--a password
would be even easier.
Scott> If there is a better way, I'm all ears. If there is a book
Scott> or manual somewhere that points out this better way, my
Scott> wallet is open! :-) If there was a good book on using the
Scott> krb5_* and gss_* API functions, I would buy it in a second!
Scott> -- Thanks in advance... Scott Weitzenkamp, Talarian
Scott> Corporation, Mountain View, CA scott@talarian.com (415)
Scott> 965-8050 "Welcome to the late show, starring NULL and void"
Scott> -- Men At Work
