[7580] in Kerberos
Re: Question about the security of forwarded TGTs
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Jul 3 00:47:06 1996
To: kerberos@MIT.EDU
Date: 2 Jul 1996 18:54:51 -0400
From: kenh@cmf.nrl.navy.mil (Ken Hornstein)
In article <tslhgrqed3c.fsf@tertius.mit.edu>,
Sam Hartman <hartmans@MIT.EDU> wrote:
> If you aren't doing something like telnetd or klogind, you
>might consider using proxyable tickets instead of forwardable
>tickets. This way, you only give away the tickets that the remote
>service uses. Be aware that proxyable tickets aren't really used by
>much (although they are a useful service sometimes), so you may have
>some debugging. Just a thought.
I _did_ consider that, but the main tickets I'm interested in getting are
AFS tickets, and since that's v4, I didn't quite know if I could use
proxyable tickets with that. This is for a batch job system, and it's
possible that during the batch job the user could want tickets for
services other than what he had originally.
Also, don't take this the wrong way, but since there really isn't much
documentation on Kerberos programming (other than the API reference manual,
which I've found is a bit incomplete), most of what I've figured out has
been from looking at other code. There are two good examples of forwarding
TGTs (telnet and rlogin), but I don't know of any examples that do proxy
tickets. So for me at least, they aren't an option :-)
> As a general rule, transmitting tickets unencrypted over the
>network is perfectly reasonable. It is the session key associated
>with the ticket that needs to be protected. It looks like
>krb5_mk_ncred, the function used to prepare the credentials to be
>transmitted over the network encrypts enough of the credentials that
>they are safe. It uses either the subkey present in the authcontext
>if a subkey was established by mrkb5_mk_req, or it uses the session
>key from the ticket for the remote server.
Okay, I see. So as long as I've authenticated to the server, then it will
use the session key that it got for talking with that principal, right?
(Assuming that I use krb5_fwd_tgt(), which I am).
> One issue you should consider in any forwarded application is
>mutual authentication. Kerberos provides you with a mechanism to know
>what remote principal you are talking to using the mutual
>authentication options. However, as a user-interface issue it is
>important to make sure that you are actually talking to the principal
>that the user intended to talk to before forwarding credentials.
>Remember that services like DNS are not particularly secure.
That's a good point; thanks for the tip!
--Ken
