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

Reply via email to