From owner-svn-src-head@FreeBSD.ORG Fri May 22 16:48:02 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43DB996; Fri, 22 May 2015 16:48:02 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA2AB1D85; Fri, 22 May 2015 16:48:01 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Yvq72-0000Ws-Tu; Fri, 22 May 2015 19:47:56 +0300 Date: Fri, 22 May 2015 19:47:56 +0300 From: Slawa Olhovchenkov To: Benjamin Kaduk Cc: Benjamin Kaduk , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Subject: Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh Message-ID: <20150522164756.GL1394@zxy.spb.ru> References: <48981079-C9B7-411D-87A3-5A8F04924314@FreeBSD.org> <20150305141334.GX48476@zxy.spb.ru> <63BD8258-D2C9-4C94-8A54-63AA104871D9@FreeBSD.org> <20150305144056.GY48476@zxy.spb.ru> <20150305151732.GA48476@zxy.spb.ru> <20150308133821.GF48476@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:48:02 -0000 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/@ from /etc/krb5.keytab. PAM don't do this? Or I something missing?