Re: secure CVS connection

[Greg A. Woods]

[ On Saturday, March 2, 2002 at 16:07:55 (-0500), Jonah Tsai wrote: ]
> Subject: Re: secure CVS connection
>
> KDC is a real pain to setup/administrate, so unless you can do KDC 
> half-asleep, or you have large number of users that come and go, you'd 
> better off kick it off with SSH -- a lot easier to get going.

I couldn't agree more!  ;-)

Even if one thinks one can set up a KDC, are you sure you can set it up
securely?  There are a lot of very critical assumptions built into
Kerberos, and if you don't make your implementation adhere to them very
closely you end up with an authentication system that's probably less
secure than plain multi-use passwords!

>From the Kerberos FAQ:

  Subject: 1.18. Are there any known weaknesses in Kerberos?                    
                                                                                
   Kerberos makes no provisions for host security; it assumes that it is
   running on trusted hosts with an untrusted network.  If your host
   security is compromised, then Kerberos is compromised as well.

   However, the degree to which Kerberos is compromised depends on the
   host that is compromised.  If an attacker breaks into a multi-user
   machine and steals all of the tickets stored on that machine, he can
   impersonate the users who have tickets stored on that machine
   .... but only until those tickets expire.
                                                                                
   Kerberos uses a principal's password (encryption key) as the
   fundamental proof of identity.  If a user's Kerberos password is
   stolen by an attacker, then the attacker can impersonate that user
   with impunity.
                                                                                
   Since the KDC holds all of the passwords for all of the principals in
   a realm, if host security on the KDC is compromised, then the entire
   realm is compromised.

There are other special requirements too, such as having _securely_
synchronised system clocks.  Most people get this wrong.  Even I don't
have a truly secure clock synchronisation mechanism for my own network,
though I have enough monitoring to make sure any compromises of a system
clock are reported.

With a Kerberos-based authentication system there are many parts to set
up, and many parts to watch over constantly.

The good thing about SSH is that all the important authentication and
encryption bits are encapsulated in one pair of programs, and their
default configurations are to be quite reasonably secure.

> Eh? What's the following function doing in src/server.c, if "CVS does 
> not use it for that purpose"? I assume this function sets up the 
> encryption with a client, according the the comments in the function. 
> Unless this setup does not work for GSSAPI wrapping, otherwise the 
> communication between client and server is encrypted.

Yes, you may be right if I now understand the GSSAPI correctly -- my bad.

However it's really irrelevant in the long term since the type of
encryption normally used in at least Kerberos-5 is not anywhere nearly
so secure as what SSH provides.  CVS sessions can last quite a long time
-- probably long enough for dictionary attacks against the session keys
in some cases, esp. if the session encryption is just plain DES.  There
is ample predictable text in a CVS client/server conversation to help an
attacker to use dictionary-based attacks against that key.  I could be
wrong, but I believe replay attacks are also still possible.

        http://www.research.att.com/~smb/papers/kerblimit.usenix.ps

As far as I know even the very latest revisions of Kerberos-5 do not
address all of Bellovin's concerns.

See also.

        http://theory.stanford.edu/~tjw/krbpass.html

Note too that DH-EKE, SPEKE, and now B-SPEKE are apparently stronger
than what Kerberos-5 implements.  SSH includes similar mechanisms for
forward secrecy of session keys too, and it also resets the session key
frequently during long-running sessions.  I think even TLS would be
better in this respect.  I don't even know if the way CVS uses GSSAPI
allows for negotiation of an application subsession key or not -- it may
even use the same application session key for multiple connections that
happen during the ticket lifetime.

On the practical side of things it might also be useful to point out
that Steven Bellovin, one person who has done a lot of research into and
analysis of Kerberos and other authentication protocols, currently uses
SSH for his own remote access needs.

-- 
                                                                Greg A. Woods

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