[7182] in Kerberos
Re: rkinit
daemon@ATHENA.MIT.EDU (Randall S. Winchester)
Wed May 1 11:45:13 1996
Date: Wed, 1 May 1996 11:30:31 -0400 (EDT)
From: "Randall S. Winchester" <rsw@eng.umd.edu>
To: Richard Basch <basch@lehman.com>
Cc: Roland Schemers <schemers@leland.Stanford.EDU>, kerberos@MIT.EDU
In-Reply-To: <199605011417.KAA04920@badger.lehman.com>
On Wed, 1 May 1996, Richard Basch wrote:
> On , 30-April-1996, "Roland Schemers" wrote to "kerberos@MIT.EDU" saying:
>
> > In article <199604302356.TAA03052@badger.lehman.com>,
> > Richard Basch <basch@lehman.com> wrote:
> > >Kerberos credential is not checked by AFS. In other words, you could
> > >forward your afs ticket (hopefully encrypted in the rlogin or some other
> > >session key) to the remote side, and then stuff that into the kernel,
> > >using the appropriate pioctl() on behalf of the user. It does alleviate
> > >the user having to retype their password merely to issue an rlogin
> > >command.
> >
> > That is exactly what my kftgt program does. It securely forwards your tgt
> > to a remote host. You can then use aklog to grab a token when you
> > login. I hacked up /bin/login to do the aklog thing automatically.
>
> I don't see how a forwarded TGT could work with Kerberos; the IP
> addresses will be wrong. The afs ticket also could have the wrong IP
> address, but the service (AFS fileserver) does not verify it. By
> default, Kerberos services will reject any request not coming from the
> IP address encrypted in the ticket -- AFS may be a Kerberos service, per
> se, but it re-implemented the Kerberos decoding and neglected the IP check.
> --
Actually I 'believe' it is the AFS "Kerberos server" that does not do the
checking. I took the code from Transarc`s inetd.c which does "token
passing" add added support for TGT passing also. I then changed my rcmd.c
to include my modified ta-rauth.c (from Transarc), and relinked rlogin,
rsh and rcp. I did similar things to telnet from the krb5b5 tree. I
actually did modify rlogin.c, telnet.c and such to be able to turn
forwarding on or off. The important stuff gets passed through RX's
encryption handleing mechanism. I just run those applications that I want
to have forwarding support for under a seperate inetd (inetd.afs).
My code mostly comes from the BSD4.4-Lite, tree with POSIX mods gleemed
from the krb5b* tree. I run this on Solaris, SunOS, HPUX, IRIX, DU,
NetBSD, and Ultrix. (Pretty much everything Transarc supports.)
My users now get both tokens and TGT's passed. Since we have a number of
Kerberized applications like printing and request (our problem tracking
system) this comes in very handy. It gives us at least some of what we
have been waiting for DCE and krb5 interoperability to provide.
Randall
