From: strick at The Yak <strick@yak.net>
Date: Sun, 5 Feb 95 17:06:28 PST
To: "Perry E. Metzger" <perry@imsi.com>
Subject: "encrypt tcp connections" hacks
Message-ID: <199502060105.RAA07673@nando.yak.net>
MIME-Version: 1.0
Content-Type: text/plain


Perry, could you enumerate them?  I take your opinions more
seriously than perhaps I should, so I want to understand
what you're saying.

I'm not doing this to re-invent the wheel.  I'm doing it because
I need it, and nothing else is working very well for me.

I'm doing it because I don't see anything that's easy-to-use in wide
use today.  I don't just want one or two encrypted applications -- like
the Kerberos telnet and rcp -- but something to transparently provide
privacy for all TCP sockets -- like SMTP sockets between (re)mailers,
NNTP, X11, FTP, MUDs, etc.

Let me name the ones I can think of.

  1.  	Matt Blaze just announced one.  As always, he has the best
	crypto.  But his world interface seems to be a hacked up
	script.c.  If I lift his crypto, and make it a standard
	module in Skronk, I can reuse 90% of his good work.

  2.	Kerberos4.  I use Kerberos4 between home and work all the time.
	However the only command I have that actually encrypts the
	session is the "rlogin" replacement.  (But I sure use it, even 
	if it's just DES.)

	Also Kerberos administration is a nightmare.  I'm a fairly
	knowledgeable crypto hacker and unix system administrator but
	honestly I don't understand what I did.  If it weren't for
	the Cygnus installation manuals giveing line-by-line
	instructions, I wouldn't have made it.  I've taken the 
	reference manuals to bed with me several times, but still
	haven't gotten a grasp of how to fully use it.

	And the reason big providers like The Well and Netcom won't
	run kerberos (or at least not the last time I asked) is that
	they would have to hire another person just to do the
	password management etc.  Skronk should be "just plug it in
	and it works".  There should be no reason why big providers
	can't offer it as an option.

  3.	Kerberos5.  I've been unable to build Kerberos5 on my 
	sun3.  Honestly.  To build it, I have to have ISODE, which seems 
	to be some enormous ISO thing that I haven't been able to build.

	Again, not too encouraging for your average unix sys admin.

  4.	The new telnet program with Telnet Options for authentication
	and encrytion.  Well it won't do encryption unless you
	can get the authentication done, and so you're back to 
	problems 2 and 3 above.  I couldn't get it to work in 
	an evening, and decided the world needed something better.
	Also even if it did work, it's only Telnet.  None of the other
	apps I named above can use it.

  5.	Standards for IPng.  Vapor, as far as I know.  Is there any
	usable code, that works in IP this generation?


I think it comes down to the fact that, of these, only Skronk and 
Blaze's software use a Diffee-Hellman -like Key Exchange so that
administration stuff doesn't have to be done by humans and footnet.

The real value I'm adding is not the crypto.  It's the packaging.
When I'm done it should be possible to skronk all your current 
clients and servers by just overriding the shared library libc.so,
running a skronk map UDP daemon, and customizing a configuration
file to tell the daemon what to say.


=================

As for the UDP service:

> UDP won't get through most firewalls.
> 
> Build in support for non-transparent firewalls (ie: telnet gatekeeper,
> c sys port).

UDP packets are for automatic configuration of skronk maps.  
Skronk maps could be announced other ways too -- including via
manual configuration, where you put skronk maps in your SKRONK_CONF
environment variable.

I may have to spend more effort on this than I wanted to.   I have
a SKRONK_CONF variable, and an option to say "dont ask the UDP 
skronk map daemon" about this port, just skronk it -- but right now 
it's only dependant on port number, not on the IP address too.
This can be fixed.

> UDP Port 333 - does this imply you need to be root to use it,
> at least as a server, or are only TCP ports typically root-limited
> for low-number ports?
>                 Bill

You need to be root to install it properly on your system, for the
skronked services to become bona fide system services.  Users should
not be able to hijack SMTP and TELNET connections to a site unless
they're root.

For people who run their own web server on a nonstandard port on a 
machine that someone else administers -- we're back to the manual
configuration method.  Maybe we can build a PGP service with 
signed certificates to collect nonstandard skronked services.  
But really I think these services will be marginal.



I had thought about using DNS TXT records.  But I decided against that
because a *lot* of people have autonomy over their workstation on
the net, but not over their DNS records.   Linux boxen in dorm rooms
come to mind.  Or anyone who puts a new machine on someone else's
ethernet, grabbing an IP address via ARP.


================= 

Thanks to everyone for your comments.

The discussion question is -- if we have so many hacks already -- 
howcome they're not in use.  I hope I found the reasons and addressed
them.  The firewalls issue bugs me a bit.  Would using a well-known
TCP port instead of the UDP port fix the problem?  I don't think 
so.  Firewalls will block my new TCP port as well.  Matt Ghio's
project to tunnel through the telnet port sounds good.  Of course,
that defeats the purpose of the firewall, which is not my aim.
My aim is to work with the internet and within its policies, so it
can get widespread use.

How much of skronk works today?  I'm nearing alpha of a version that's
hardwired to do DH exchange (using RSAREF2.0) and IDEA CBF (stolen from
PGP sources) for the symmetric encryption.  But I broke it recently
when I added hacks for servers to fake select() listening on both
skronked and normal ports, when the program only thinks it's only
listening on normal ports.


I gotta go ...     strick


==================


p.s.	need some wizard-level help here.

	I use syscall(2) when I reimplement read() write() connect()
	accept() etc. on SunOS. 

	On LINUX I borrowed code from the libc sources.

	On HPUX and Solaris and AIX I'm having difficulty finding
	a way to do what system calls do, without using the
	manufacture's packaging.  

	any help would be appreciated.