svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

[Slawa Olhovchenkov]

On Wed, Mar 11, 2015 at 12:27:15AM -0400, Benjamin Kaduk wrote:

> > > should never type my password at something which is not a trusted local
> > > binary.
> >
> > As I know, you can't use kerberos outside controled perimeter (with
> > working NTP sync, revers DNS and etc). I.e. from random [network]
> > place you can't run kinit on local machine [notebook] and use kerberos
> > to ssh login.
> >
> > For may case this is requirement.
> 
> I use kinit on my local machine and use kerberos to ssh login from all
> sorts of weird environments.  The use of reverse DNS can be disabled;
> libkrb5 can store a time offset to correct for some classes of clock
> errors.
> 
> Maybe your KDC is firewalled off?  I know that trying to reason with
> sysadmins can frequently be a lost cause, but the kerberos protocol is
> explicitly designed to run over an untrusted network.

Ok, now I re-establish kerberoised setup -- antecedent will be lost --
and re-check assertion.

Currently I don't see reverse DNS dependency.
I see dependency on forward DNS -- kerberos library (?) can't handly
IPv4 address correctly -- interpretation as "domain's" and stripping
first octet. As result -- can't find krbtgt/.

This is problem, but this is different and minor problem.

Can you advise some way for refreshing tickets?
Or best way -- use initilay long expiration time?

For use with kerberoised NFSv4, too.

> > > is going off and getting a ticket, sure (and hopefully validating it
> > > against the host keytab to avoid the Zanarotti attack!), but it is
> > > starting with your password.  That is completely at odds with how Kerberos
> > > is intended to be used.
> >
> > Sorry, I don't understand you. Can explain?
> 
> The basic idea of the attack is that if I know the password that sshd is
> trying to validate, I can fake a response from the KDC which is encrypted
> in the (key derived from that password) and make that response look like a
> valid TGT.  In order to tell that the TGT it receives is actually from the
> KDC, and not the attacker, sshd has to use that TGT to get a service
> ticket it can validate (i.e., a service ticket for itself)

And what is wrong?
As I read requirement is validating KDC response with service identity
host/<hostname>@<realm> from /etc/krb5.keytab. PAM don't do this?
Or I something missing?