From owner-freebsd-hackers Sun Aug 15 15:34: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 7C5111564A; Sun, 15 Aug 1999 15:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 710C21CD7BC; Sun, 15 Aug 1999 15:33:58 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Sun, 15 Aug 1999 15:33:58 -0700 (PDT) From: Kris Kennaway To: Dave Walton Cc: nsayer@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <19990815221506.26169.qmail@modgud.nordicrecords.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Dave Walton wrote: > > Again, the problem is that there is administrative overhead - a separate > > password database is required. > > Yes, there is /etc/tpasswd to deal with. I guess what I should have > said is that I'd love to see SRP integrated into FreeBSD (as PAM, > perhaps?). Properly done, the various system utilities would keep > passwd, master.passwd and tpasswd in sync, and SRP > authentication/encryption would be available to telnet, ftp, or > anything else. > > (Disclaimer: Authentication and PAM are way outside of anything I > know anything about, so I really have no idea what it would take to > make that work.) /etc/tpasswd is a way of storing the SRP information separately for systems which cannot handle it being in /etc/passwd directly. At least with my replacement libcrypt this isn't an issue as far as I know. > > Keep in mind, also, that as long as AUTHTYPE_SRP and > > AUTHTYPE_SRA are different numbers, both could be present. I > > would even conceed that SRP should be tried before SRA. But I'd > > sure as hell rather use SRA than nothing. > > Ok, Nick implements SRA for folks in heterogenous NIS > environments, and Kris implements SRP for those of us without > that restriction. How's that for a non-cryptographic compromise? :) I don't have a problem with that. The only issue which (to my knowledge) has never been addressed anywhere is the authentication protocol exchange between client and server and a formalized API (PAM doesn't do this: it communicates between a server and arbitrary backend, among other things, but doesn't specify the client/server interaction). Ideally, things like SRP, SRA, CHAP, PAP, etc, should be available as plugins to client/server apps, so we don't have to make separate patches to telnet/telnetd, ftp/ftpd, etc, for all of the authentication protocols-of-the-day. This would make a good RFC if one does not already exist. > Unfortunately, this whole discussion ignores one ugly problem: > client availability. I've never heard of SRA before, and the only non- > Unix SRP telnet client I'm aware of is a hacked version of TeraTerm > and only supports authentication, not encryption. Without good > clients on certain unnamed widespread OS's, most people will > continue to use plaintext due to a complete lack of choice. I think I've heard rumours of agreements by some of the superpowers (Microsoft, etc) to standardize on SRP. This presumably means a common protocol. I should look into this more - anyone have any real information? Kris > > Dave > > > ---------------------------------------------------------------------- > Dave Walton > Webmaster, Postmaster Nordic Entertainment Worldwide > walton@nordicdms.com http://www.nordicdms.com > ---------------------------------------------------------------------- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message