"encrypt tcp connections" hacks

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.

strick at The Yak says:
> I take your opinions more seriously than perhaps I should,

I don't want to scare people into not doing things -- but I do want to
inform. Persons taking my opinion, or that of any authority, on face
value without doing their own reasoning, get what they deserve.

> 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.

Then do it...

> 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.

Well, in the long term, my hope is that people use IPSP for this. It
will mean that the kernels on their machines simply deal with all this
stuff and that userland applications get to ignore it 90% of the time.

> Let me name the ones I can think of.
> 
>   1.  	Matt Blaze just announced one.

>   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.

And the telnet; however, it has a library to let you do whatever you want.

>       (But I sure use it, even if it's just DES.)

In v5 there is more general support, I believe.

> 	Also Kerberos administration is a nightmare.

Thats really an interface issue, I think -- they have a lot of the
fundamental stuff down. If thats one's only complaint with Kerberos (I
have others) the "right thing" is to build a simplified administration
system. 

> 	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.

Thats quite untrue -- passwords in kerberos are set by the users, not
by the administrators!


>   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.

You only need ISODE for the ASN.1 compiler; you don't have to build
the whole thing.

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

There is swIPe, and the derived TIS product. Its a bit primitive since
it doesn't handle per-socket keying. There is stuff that I'm hacking
on between flames -- its going to be called swIPe II. It will conform
to my RFC drafts and should run out of the box on any 4.4BSD
system. I'm hoping people will back-port it to SunOS and the like.

There is also SSL, which is what the Netscape people are pushing --
stands for Secure Sockets Layer.

There is also the thing this guy Andy Heffernan did a draft on in
which you do this at the TCP layer; he uses a TCP option to pass IVs
and MACs.

There is also the method proposed by the AFT working group at the
IETF, a.k.a. the "socks" working group, for encrypting sockets.

There is also the thing that Miron Cuperman wrote for YTalk. It did
diffie-hellman key exchange followed by an encrypted session.

There are about three or four more that I can't bring to mind at the
moment but I'm damn sure I've seen them.

> 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.

Diffie-Hellman doesn't give you real security without some sort of way
to authenticate the exchange. Man in the middle gets you. You are then
down to either using signed exchanges or some sort of challenge or
conventionally keyed way of authenticating.

BTW, Kerberos most emphatically does not require active
administration. I've run it in an environment with thousands of hosts
with narry a person paying it any attention.

> 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.

Well, this is an admirable goal. Of course, the Netscape people want
to do the same thing with SSL, and others have proposed to do it, too.

Ultimately, the thing that is going to fix the net is IP layer
encryption -- anything at a higher layer can't really fix all the
problems reliably. (As an example, consider RST attacks against TCP
connections.) It also can't fix them pleasantly.

Meanwhile, of course, it is going to be a while before that stuff is
universally deployed. My reference implementation isn't going to be
here before April. It will be freely available, but it will only run
on some architectures, and it is unlikely to be idiot friendly or
perfect out of the box day one.

Understand, also, that as one of the few people here who writes code I
don't want to discourage you from continuing by any means!

However, I'd say that this isn't going to be a permanently deployed
thing on the net -- that much we can be pretty sure of.

> The discussion question is -- if we have so many hacks already -- 
> howcome they're not in use.

Probably people aren't that enthusiastic about them. Encrypted
sessions are in wide use for telnet and the like -- I do that sort of
thing regularly, and now that session stealing has become a fact of
the net I suspect that S/Key is going to vanish and be replaced by
various encrypted telnets. SMTP it doesn't make much sense to protect
because what you really want to protect is the contents -- i.e. via
PEM, MIME security multiparts, or some similar method (I favor PGP'ed
secure multiparts myself.)

> p.s.	need some wizard-level help here.
> 
> 	I use syscall(2) when I reimplement read() write() connect()
> 	accept() etc. on SunOS. 

Why? Why not just do the original calls? If you are trying to overlay
shared libraries, just rename the calls in the symbol tables or
relink the library or something similar...

Perry

On Feb 5,  9:02pm, Perry E. Metzger wrote:

> There is also SSL, which is what the Netscape people are pushing --
> stands for Secure Sockets Layer.
>
>
>-- End of excerpt from Perry E. Metzger

  Of course SSL is not really a solution.  First it requires that the server
have a well-known RSA public key.  It is also not an optional service so it
requires new well-known ports for the secure services (such as https ).  Also
for some strange reason it uses two session keys (both generated at the client
end) one for client->server and another for server->client.  Not to mention I
distrust any protocol with provisions for sending bits of my key in the clear.
	Clinton


--

Perry advocates IPSP as an almost-panacea for Internet security.  I
disagree.  I'll quote only the most relevant bits:

   From: "Perry E. Metzger" <perry@imsi.com>

   > 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.

   Well, in the long term, my hope is that people use IPSP for this. It
   will mean that the kernels on their machines simply deal with all this
   stuff and that userland applications get to ignore it 90% of the time.

   [...]

   However, I'd say that this isn't going to be a permanently deployed
   thing on the net -- that much we can be pretty sure of.

The basic problem with assuming IPSP as a universal encryption
solution is that it answers an incomplete threat model.  IPSP works
where you trust the endpoints but not the intermediates.  When you
don't trust the endpoints for silence, but do trust them for routing,
IPSP doesn't work.  Let me make this concrete:

TIA on netcom.

Suppose I'm running extruded netcom ports on winsock clients using TIA
to multiplex the serial line.  (Some of you may be doing this right
now.)  My Netscape connection is passing from my MS Windows machine
through netcom over the internet to my web server of the moment.  IPSP
doesn't provide end-to-end security in this case, because the endpoint
for the IP packet (netcom) doesn't coincide with the endpoint of the
actual connection (the home machine).  A maxim:

Trust boundaries are not the same as machine boundaries.

It's fallacious to argue simply that everyone's going to be _on_ the
Internet soon enough anyway, and that this problem will go away.
Absolutely not.  If anything, this kind of proxying for Internet
connectivity is going to be come _more_ common, and that as a result
of cypherpunk projects for realtime proxy services, such as web and
ftp proxies.

You don't want to trust the proxy in an anonymization service to do
your crypto for you, just like (if you're smart) you won't trust your
secrets to netcom even for processes, much less for filesystems.  And
you can't say that all proxies are going to be IP-to-IP proxies,
either.  Some of them are going to be proxying the whole protocol,
some will participate partially, some not at all.  What this does
indicate, however, is that the need for peer-to-peer encryption will
be necessary at _each_ level of abstraction, and pretty much forever.

It will be an interesting and practical exercise in trust modeling to
figure out how to pass one layers policy requirement for a secure
channel to a service offering at a lower layer.  The problems involved
here are going to be extremely difficult to make work for anything
approaching generality.

Eric

Eric Hughes says:
> Perry advocates IPSP as an almost-panacea for Internet security.  I
> disagree.

Well, no; it doesn't fix things like mail for which the data needs to
be protected but not the link. However, I think I can answer some of
your other objections...

> TIA on netcom.

TIA is sort of a short term hack people are using to get around having
to have their administrators manage SLIP or PPP properly; I suspect
this difficulty will vanish with time.

> It's fallacious to argue simply that everyone's going to be _on_ the
> Internet soon enough anyway,

Well, IBM of all firms is trying very hard to make sure you are, and
Microsoft is even investing in UUNet to try to make sure of it, too.

Remember, by the way, that PPP is far cheaper per customer than shell
accounts, even though moronic providers right now don't make it look
that way.

IP is ultimately designed to be a proxy protocol that will work over
anything -- stuff like TIA simply gets around temporary mental
difficulties among providers in seeing things that way...<

Perry

On Mon, 6 Feb 1995, Perry E. Metzger wrote:

> Remember, by the way, that PPP is far cheaper per customer than shell
> accounts, even though moronic providers right now don't make it look
> that way.

PPP/SLIP is currently not cheaper per customer - if you figure in the 
time your help desk staff put in over the first couple of weeks of a new 
customer coming on line.  Many people who have barely ever used a BBS are 
deciding they "need their internet connection" and going SLIP/PPP even 
where a shell account would do most of what they want.

-Thomas

Thomas Grant Edwards says:
> On Mon, 6 Feb 1995, Perry E. Metzger wrote:
> 
> > Remember, by the way, that PPP is far cheaper per customer than shell
> > accounts, even though moronic providers right now don't make it look
> > that way.
> 
> PPP/SLIP is currently not cheaper per customer - if you figure in the 
> time your help desk staff put in over the first couple of weeks of a new 
> customer coming on line.

Thats because the providers never package things up cleanly. If they
sent a client on a disk, a la AOL, and they set things up to
autoconfigure, they'd never need to speak to the clients.

Perry

> Thats because the providers never package things up cleanly. If they
> sent a client on a disk, a la AOL, and they set things up to
> autoconfigure, they'd never need to speak to the clients.

    You've obviously never attempted to get a Windows product working for 
someone whose previous experience with a computer is limited to "Solitaire".

    I've done work with this ISP, and I can tell you it's nearly the most 
frustrating experience I've had in my life -- Windows has bizzare 
conflicts with software eating other software, ports getting set up 
wrong, and just general nastiness.  Even the slickest software needs 
helpline time - for whatever reason.

-jo

( --------[ Jonathan D. Cooper ]--------[ entropy@intnet.net ]-------- )
( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4  5B 12 A0 35 E0 9B C0 01 )
( home page: http://taz.hyperreal.com/~entropy/ ]---[ Key-ID: 4082CCB5 )

> 
>     You've obviously never attempted to get a Windows product working for 
> someone whose previous experience with a computer is limited to "Solitaire".
> 
>     I've done work with this ISP, and I can tell you it's nearly the most 
> frustrating experience I've had in my life -- Windows has bizzare 
> conflicts with software eating other software, ports getting set up 
> wrong, and just general nastiness.  Even the slickest software needs 
> helpline time - for whatever reason.
> 
I have been doing help desk related work for nearly 10 years and in my 
experience 'user friendly' is something you see on ads and never in the
software.

I have yet to see a piece of software that is useful and actually solves
a problem or does a job that doesn't also require an investment by the
help desk.

It simply ain't that easy.

On Mon, 6 Feb 1995, Jonathan Cooper wrote:
>     You've obviously never attempted to get a Windows product working for 
> someone whose previous experience with a computer is limited to "Solitaire".
> 
>     I've done work with this ISP, and I can tell you it's nearly the most 
> frustrating experience I've had in my life -- Windows has bizzare 
> conflicts with software eating other software, ports getting set up 
> wrong, and just general nastiness.  Even the slickest software needs 
> helpline time - for whatever reason.

Some software needs more than others.

Central Points desktop for windows -- a very complex and powerful 
product, had quite low help line costs.

On the other hand the messy and confused windows internet utilities,
produced by diverse people, often crudely ported from Unix by 
shareware operators who could not afford the time and effort 
for a proper setup program, or crudely ported by people who may 
have been Unix experts but most obviously were not windows
experts, (example: ftp softwares terminal emulator) are a total 
disaster, and this is why the help cost for SLIP lines is so 
high.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd@netcom.com

From: "Perry E. Metzger" <perry@imsi.com>

   Eric Hughes says:
   > Perry advocates IPSP as an almost-panacea for Internet security.  I
   > disagree.

   Well, no; it doesn't fix things like mail for which the data needs to
   be protected but not the link. 
   
In the case of email, there's the same discrepancy I pointed out
earlier -- the machine or filesystem boundary is not the same as the
trust boundary.  This will happen for email as well as more live and
online communications needs.

   TIA is sort of a short term hack people are using to get around having
   to have their administrators manage SLIP or PPP properly; I suspect
   this difficulty will vanish with time.

I agree with you that this particular example may be short lived, but
you appear to have ignored the more fundamental point I was making.
Namely, the existence of communications proxies which _change_ the
level of abstraction will be with us forever.  The TIA unix end
switches from TCP-to-the-world to IP-to-the-PC.  That's a level
switch.

   IP is ultimately designed to be a proxy protocol that will work over
   anything -- stuff like TIA simply gets around temporary mental
   difficulties among providers in seeing things that way...<

I'm not saying that IP proxies won't exist.  What I am saying is that
other forms of proxying will also exist.  Not all policies will be
able to be enforced at the IP level.  As soon as you want security
policy to apply to non-IP abstractions, IPSP is no longer primary,
even if it's still involved.

Firewall policies are a prime example of security policy enforced at
the TCP and UDP levels, with access control by port number.  External
firewalls, a class that includes packet laundries, web proxies, and
IRC anonymizers, will not for the most part operate at the IP level.

It's certain that IP security will greatly increase the overall
security of the Internet.  I'm not advocating its removal but rather
the acknowledgement that higher (and lower) level abstractions will
require their own cryptography.

Eric