slightly off-topic stuff about secure network tools....

[Greg A. Woods]

[ On Thursday, July 26, 2001 at 10:08:37 (-0400), Noel L Yap wrote: ]
> Subject: RE: New update to the CVS ACL patch to support user groups
>
> I thought SRP (secure remote password) was an authentication protocol only.  
> Are
> we talking about different SRP's?

Yes, SRP as a protocol is simply a means of doing strong authentication
over a public network.  However the reference implementation apparently
includes hooks to use strong encryption libraries (it used to bundle its
own strong encryption code) so that the sessions it authenticates can
also be protected.  The reference implementation also comes with a
fairly easy-to-use library that could be hooked into the standard *BSD
rsh & rshd.

One thing I'm not sure of is how/if SRP can provide secure session keys
for encrypting the session traffic, and whether or not the reference
implementation includes logic to negotiate and periodically change
session keys....

However SRP plus SSL's session-level encryption would offer such
features.  Similarly SRP could be plugged into SSH too.

> >  All of them require real Unix accounts
> >on the server though.  All of them require that the server trust the
> >client and vice versa.  Some of them also require that the network be
> >physically and logically secure (but not SSH or SRP or Stunnel).
> 
> I thought SSH's trust for the server is needed only for the initial server 
> host
> key distribution on the client.  If this is so, depending on the established
> procedures to obtain the host key, the SSH client needn't trust the server at
> all.

Trust goes a lot deeper than just the key management level, especially
when what you're authorising by granting such trust is the right to
execute jobs and access files as the authenticated user!

The SSH client must trust the server (and the server admin) to the not
allow the server's host key to be compromised (since that's how the
client authenticates the server), and of course the users must trust the
server is secure so that their use of the server is known to be secure
and so that they can be assured that nobody can spoof them on the server
and thus point blame for any attack at them.

In essence the SSH trust relationship is both many to one and one to
many.  The server admin grants trust to the users by granting trust to
the server to authenticate the user's client machines.  Normally the
server further delegates trust to the user's processes and files to
allow the user to grant more open access to specified client hosts.  The
server in addition must trust the users to maintain and operate their
client hosts securely (eg. not allow a Trojan program to be installed --
eg. one that could intercept and manage all the input and output that
the user sees and thus be able to insert commands in the SSH stream that
the user didn't type, hiding their output so that the user doesn't even
know they happened).  The users in turn trust the admin to maintain a
secure server so that they can be assured they've connected to the right
machine and that the data they store on that server is secure (including
not only their own SSH keys, but all the other stuff they have and do on
the server!).

This is why it's really not very smart to run SSH, or any kind of
network access protocol that provides authenticated user access, from
any un-trustable client system, such as any portable computer or any
system that itself has no real inherent security and no concept of user
identity and accountability.  SSH is really only trustworthy to use
between trusted servers.  Every remote job protocol that CVS might use
can only be as safe and secure as the weakest of the two machines
involved, no matter how much effort is put into protecting the data as
it travels over the wire.  Using SSH from an untrusted client makes all
of the authorised user's actions just as insecure as the untrusted
client is generally.

(Using SSL to access your bank account from an untrusted client computer
is just as equally insecure!  Banks that allow such nonsense are clearly
not thinking straight and are not following their own security policies
and not mapping them into the online realm properly -- they should issue
specifically signed certificates to every account holder, authorising
SSL connections only from clients presenting a properly signed
certificate, and they should give strict instructions to users on how to
secure their client systems as much as possible, perhaps even supplying
custom client software that scans for viruses and Trojan programs and
the like.  Yes this means almost every on-line system on the Internet
today that's not already protected by external means such as credit card
transactions are, is grossly insecure!  Almost everyone misuses SSL!)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>