From owner-svn-src-all@FreeBSD.ORG Wed Mar 11 04:27:28 2015 Return-Path: Delivered-To: svn-src-all@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 B2589DA4; Wed, 11 Mar 2015 04:27:28 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E302C9B8; Wed, 11 Mar 2015 04:27:27 +0000 (UTC) X-AuditID: 12074425-f79846d0000054e1-49-54ffc427562d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 51.94.21729.724CFF45; Wed, 11 Mar 2015 00:27:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2B4RIaY003477; Wed, 11 Mar 2015 00:27:19 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2B4RF3I025928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 00:27:17 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2B4RFtH010324; Wed, 11 Mar 2015 00:27:15 -0400 (EDT) Date: Wed, 11 Mar 2015 00:27:15 -0400 (EDT) From: Benjamin Kaduk To: Slawa Olhovchenkov Subject: Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh In-Reply-To: <20150308133821.GF48476@zxy.spb.ru> Message-ID: References: <20150305123349.GP48476@zxy.spb.ru> <20150305123548.GO17947@FreeBSD.org> <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> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1lU/8j/E4PoeC4tjD4+yW0x4HW3x p30Ki8WfTQtZLZq+LGByYPWY8Wk+i8fOWXfZPX6eFgpgjuKySUnNySxLLdK3S+DKOHtzP1vB fNOKqddfszQwPtXsYuTkkBAwkbjQep0ZwhaTuHBvPRuILSSwmEliwRGxLkYuIHsjo8TsjgYm COcQk8Tmc59YIJwGRonzr1YxgrSwCGhLPOl9yw5iswmoSMx8sxFslIiAusTar7fZQBqYBV4w SjQdngfWICwQIPFgeR8TiM0pYCCxsucdK4jNK+AgMePqc3aIDT+ZJbb09oMViQroSKzeP4UF okhQ4uTMJ2A2s4CWxPLp21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6F Xm5miV5qSukmRlBIs7uo7mCccEjpEKMAB6MSD6/DjP8hQqyJZcWVuYcYJTmYlER5Nx4ECvEl 5adUZiQWZ8QXleakFh9ilOBgVhLhlTkMlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2a WpBaBJOV4eBQkuD9cAioUbAoNT21Ii0zpwQhzcTBCTKcB2j4WpAa3uKCxNzizHSI/ClGRSlx 3t8gCQGQREZpHlwvLOW8YhQHekWYNwLkNh5guoLrfgU0mAloMIs12OCSRISUVANjhLnO6wln LskEuZVFza452be84H3jAkab+8//rY17L7P1Uc8Nxw/LCiPU/jfYf5ia8PiM7u2Pc7PYX3la LU5p3R6cKrVtQmgC19+b58qeLDry7u9+U/a42PWFH73tLQvPvJCpO7L4AsMmyUVXWxLEmOID Vky69yfN65SdUc32pxM0VS1fWy0JVGIpzkg01GIuKk4EAI6lQ1wUAwAA Cc: Benjamin Kaduk , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 04:27:28 -0000 On Sun, 8 Mar 2015, Slawa Olhovchenkov wrote: > On Thu, Mar 05, 2015 at 08:14:59PM -0500, Benjamin Kaduk wrote: > > > On Thu, 5 Mar 2015, Slawa Olhovchenkov wrote: > > > > > On Thu, Mar 05, 2015 at 10:11:43AM -0500, Benjamin Kaduk wrote: > > > > > > > On Thu, Mar 5, 2015 at 9:40 AM, Slawa Olhovchenkov wrote: > > > > > > > > Speaking as an upstream maintainer: don't use kerberized telnet. > > > > > > I am use this for test kerberos setup (check all setup correctly). > > > > I use ssh to test kerberos setups (I think sshd has better error message, > > for one). > > I don't see any error message from ssh (about kerberos), ssh just ask > password if any problem. What a problem? Silent. I said sshd, not ssh. ssh's output is not great; ssh -v just tells you that it's moving on to the next mechanims (password), which you could guess because it's asking for a password. But the kerberos client generally doesn't get a very informative error message anyway, since that could give too much information to an attacker -- the really useful parts will always be on the server side. > For debug ssh+kerberos I need stop sshd and run sshd with -D and -d. You can easily start a new sshd on a high port and leave the old one running. > And in this case debug messages very stranges for me. They will be less strange if you use it a lot :) > Also, telnet use less dependes and less restrictions. This is good for > step-to-step debug. I'm not sure what dependencies are a concern given that ssh is in the base system. What does youre step-to-step debug procedure look like? Mine is mostly just "use kinit to check that I can get a TGT", and then "use ssh to check that I can get a working service ticket". There could be an intermediate "use kgetcred to check that I can get a service ticket at all", but I usually skip it since I have lots of practice with ssh. Are there other steps I am missing? > > The problem with using telnet to test the kerberos setup is that if your > > kerberos setup works with telnet, you have the DES enctypes (weak > > cryptography) enabled. This means that the whole setup, even things > > other > > What you talk about DES? I don't see nothing about AES/DES/etc in krb5.conf. It would be allow_weak_crypto most likely, not an explicit list. See https://svnweb.freebsd.org/base/head/crypto/heimdal/appl/telnet/libtelnet/kerberos5.c?revision=233294&view=markup#l247 for where the client forces DES to be used. I also didn't mention the weak CFB cipher mode used, earlier. > > than telnet, are suffering from the vulnerabilities of weak crypto. > > Kerberos distributions have disabled DES by default for many years, now -- > > Apple has even completely removed the code for them from recent releases > > of OS X! Please see RFC 6649. > > I don't enable DES. And I have working kerberized telnet. What you > talk about? Supposedly there are patches to enable 3DES (but still CFB). Perhaps you could show the 'klist -v' output to remove some confusion > > > > I use kerberized ssh all the time; please tell me more about how it is > > > > broken (a new thread would be best). > > > > > > kerberized ssh broken in SSO mode: you can't do ssh login to > > > > I have a very different idea of what "SSO mode" means: I run kinit on my > > local machine and then use kerberos to authenticate to remote > > services. I > > SSO (for me) is from Windows world: you login in desktop and don't > need to enter password anymore. "desktop" is important -- it is a local machine. It's not giving your password to the remote server. > > 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. > And for untrusted binary -- why don't use kerberos with OTP? It helps a little bit, but frankly, all the existing kerberos/OTP solutions are not all that good. > > > kerberized host (from outside world), input kerberos password and use > > > kerberos ticket. > > > > "input kerberos password and use kerberos ticket" doesn't make sense -- > > you are not using your kerberos ticket; you are using your password. > > PAM > > I am use kerberos ticket for passwordless login to internal hosts > (after using password for login to gateway host). > > > 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) > > > This is issuse between PAM and ssh thread emulation. > > > > It does seem likely that this sort of thing would be an issue with PAM, > > yes. I am not particularly motivated to look into it, though. > > > I do recall some issue where sshd in capsicum mode was not allowed to read > > the keytab in order to verify the supplied Kerberos credentials, which > > required using UsePrivilegeSeparation=yes instead of the default value > > (sandbox). Perhaps that would affect the password mode of operation as > > well. > > Currently, sshd for PAM (and kerberos PAM) fork child. Got ticket in > this child. And try to save ticket in parent (unsuccessful, of > course). As result -- I don't have valid ticket after ssh login. So this is just an inconvenience, then, not a fatal flaw? (If you're willing to type your password at sshd, you can type it again at kinit later.) Anyway, this mode works in linux, so fixing it must just be a small matter of programming. I have too much on my plate to take it on, though. -Ben