Subject: Re: ssh - are you nuts?!?
To: None <sjg@quick.com.au>
From: None <opentrax@email.com>
List: tech-security
Date: 12/20/2000 17:43:41
On 18 Dec, Simon J. Gerraty wrote:
>> > Authentication is pointless without a means of ensuring the integrity of
>> > the channel and encryption gives you that as a side effect.
>> >
>> My understanding is that authentication can be just as difficult
>> for SSH as it is for telnet. Do do you believe this
>> to be the case?
> 
> Unless you are talking about a non-standard telnet, that supports one
> of the interesting authentication options, then there's little
> comparison.  Strong authentication is not trivial to achieve. That's
> true for SSH and any authenticating telnet - or login.
> 
> SSH does a reasonable job, it supports RSA, and TIS, and even passwd.
> The other forms don't interest me.
> 
Okay, then you are stating that while authentication can be
an issue, you believe that SSH is doing a "reasonable job";
especially by offering such options as RSA and TIS.
Is that correct?


>> > So, with encryption as a given, why SSH and not say stelnet?
>> > 
>> > Standardization.  I'm speaking as one who over the years added encryption
>> > to telnet in a couple of different ways - settling on SSL in the form
>> > of stelnet.  Due to the (until very recent) export restrictions of the U.S.
>> > everyone who wanted an encrypting telnet had to invent their own.
>> > 
>> Is there a reason that "invent(ing) thier own" is not good?
>> It would seem to be a secure method.
> 
> Sorry, but is that a serious question?  Is this a homework assignment
> we are working on?  Ok, think about this.
> 
> 1. Ok, I've implemented stelnet, its nice and secure, I get strong
> authentication and encryption - provided that the target host has the
> appropriate server installed.
> 
Okay.

> 2. I have to interwork with a bunch of different sites, they've all
> invented their own "*telnet".  So I have N different clients and
> servers to install and maintain if I want to have secure
> communications outside of my own net.
> 
It a good point. I'd qualify it as a reason for SSH.
But, That follows with the assumption that if you have
N different clients and servers, each has been "tweaked"
by someone other than yourself. 
Isn't that a schenario issue with SSH also?

> 3. Wow!  A security advisory comes out, bug in telnet.  Doh!  I have N
> different versions of it to rush out and fix before I can sleep
> tonight.  And what about all the admins at all those other sites? have
> they fixed it two in their N versions?  Am I still safe?  I don't
> know...
> 
That's an extremely valid point. I may have to conceed that.
If I do dispute it, it will need to be in my talk.

> Now that the U.S. has relaxed export restrictions somewhat, there may
> well emerge a "standard" telnet which is secure, but frankly I think
> its too late.  The world has standardized on SSH.
> 
Well.... You can always read about my talk. :-)

>> I see your point on flexible key management, but wouldn't a centralized
>> key system have the following points against it:
>> 1) central point of failure
> 
> I'm talking about certs as used in SSL, there need be no single point
> of failure.  I don't like the cert based authentication schemes that
> rely on a directory server to hold all the public keys - they are
> generally designed by people who sell directory server's.  The only
> advantage they can offer is semi-real time checking if a cert has been
> revoked.   Publishing CRL's is after all the big headache faced by
> most PKI solutions.
> 
Can you expand on these "Publishing CRL" issues? Or at least
point me in the direction of more information?


>> 2) implied user laziness, because only one password is need over
>>    many systems.
>> In point #2, wouldn't many password be more secure?
> 
> No definitely not.  In the case of PKI we are dealing with a pass
> phrase which can be substantially longer than say an 8 char password. 
> The more passwords you force people to use, the more trivial they will
> be and the more likely they will be on post-it notes stuck to their
> monitor. 
> 
Okay, for the sake of arguement. I'll concide that, perhaps
many passwords on ALL users may not be effective.
But for System Admins, that would almost seem a must.
Would you agree?


> Note, I also don't think much of forcing people to change their
> passwords every month - for the same reasons.
> 
I'll mention this point in my talk, but not expand on it.
This point seems to be in need of analysis. 
Evidence in either direction for this policy is lacking.
However, if you know of any information on this, please
feel free to email me about it?

>> > But guess what - I use SSH as much or more than the above.  
>> > Why? Because everyone else does.  Because its "good enough"[TM] 
>> > and offers features that *telnet and SSLrsh don't which I and most 
>> > other users fine very handy.  I make use of its tunneling, compression
>> > and single signon support (no I don't forward the authentication agent to 
>> > sites I don't trust).
>> > 
>> So you say your willing to sacrifice some security for some
>> features in SSH. Is that correct?
> 
> Yep.  Because like I said, SSH is "good enough", especially when I've
> setup both client and server and avoided all the things I don't like.
> 
Okay. I can see this is a point to mention.
Woudl you agree?

>> > gets the job done so that's what we all use.  SSHv2 probably would have 
>> > taken over - but for the license.
>> > 
>> You're suggesting some issue with SSHv2. Could you elaborate on that?
> 
> The one I mentioned.  When SSHv2 first appeared it required a license
> fee for use in commercial environments, so guess what, everyone still
> uses SSHv1 or versions derrived from it which have no such
> restrictions.  There are now SSHv2 implementations which are free -
> I'm told, but they are relatively new, we'll have SSHv1 around for a
> while yet.
> 
Okay. Thanks for making mention and elaborating on that.

				Jessem.