Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Aug 1999 15:33:58 -0700 (PDT)
From:      Kris Kennaway <kris@hub.freebsd.org>
To:        Dave Walton <walton@nordicrecords.com>
Cc:        nsayer@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Re: Whither makefiles for src/crypto/telnet/* ?
Message-ID:  <Pine.BSF.4.10.9908151519330.45940-100000@hub.freebsd.org>
In-Reply-To: <19990815221506.26169.qmail@modgud.nordicrecords.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908151519330.45940-100000>