Recently went to an IPV6 talk. They said they planned to include security
in the lower protocols so that higher ones (such as ftp, http, etc. . . )
don't have to worry about it. Now we just have to see if IPV6 is adopted
permanently :-)
-----Original Message-----
From: Jeffry Smith [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 3:47 PM
To: Greater NH Linux Users' Group
Subject: Protocol Design (Was Re: Ways to protect Data (was Re: Why FTP
must die..)
Benjamin Scott said:
> On Thu, 1 Mar 2001, Ken D'Ambrosio wrote:
> > My point, however, is that it's still acting as a transport for insecure
> > protocols -- instead of having to set up VPNs or SSH, dammit, FIX THE
> > PROTOCOLS.
>
> I disagree. Why should every implementor of every protocol have to
worry
> about authentication, encryption, and so on? Why should we go back and
modify
> the billions of lines of existing code to support some new security
scheme?
> Why should every implementor have to maintain that security layer? Why
should
> administrators have to worry about different keys, options, and so on, for
> every possible protocol? Doesn't it make more sense to handle it in the
> transport layer? We don't expect HTTP to handle error correction. We
don't
> expect FTP to handle routing. We pass the work on to a common subsystem.
> Solve the problem once, and be done with it. That makes much more sense,
> IMNSHO.
>
I agree with Ben here. Part of the Rainbow series on Computer Security is
that the security systems be separate from the rest of the code, and have
well-defined entry-exit. This allows all subsystems to use a common
framework. It also matches the Unix philosophy of lots of little tools each
doing one thing well (the longer I spend in the computer field, the more
that philosophy makes sense).
Looking at the OMG's CORBA model for security, they handle it the same way -
you have encryption modules, authentication modules, logging modules, etc.
Other services that need encryption use the IIOP calls for the encryption,
they don't implement it themselves. Same for authentication. By the same
token, the encryption modules don't try to do routing, or document editing,
or ... You get the picture. Build small, well-defined tools, with known
interfaces.
Example - use SSL or SSH for tunneling, PAM to allow you to change the
authentication, and FTP/HTTP/whatever else for what they do. Route over TCP
that does retransmit / ACK for ensuring delivery.
Note that this has drifted well away from FTP, we're now talking protocol
design philosophy.
jeff
-----------------------------------------------------------------------
Jeffry Smith Technical Sales Consultant Mission Critical Linux
[EMAIL PROTECTED] phone:603.930.9739 fax:978.446.9470
-----------------------------------------------------------------------
Thought for today: swapped out n.
See swap. See also page out.
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
