Subject: Re: comments on kerberos-revisions-05.txt

From: Jeffrey Altman <[email-masked]>
Date: Sat, 15 Apr 2000 0:56:33 EDT

> (Most of) the Kerberos guys are well aware of the issues.
> 
> Traditionally, all you give to your kerberized telnet is the hostname.
> Telnet will looks up the IP-addr via DNS and composes the hostbased
> service name as "host@given-hostname" and pass it to Kerberos, where
> it is processed according to the rules for hostbased service names,
> where the hostname part is canonicalized via DNS.  If the DNS lookups
> that telnet performs can be spoofed (which is possible in most
> installations today), an attacker can redirect the actual
> TCP connect to a host of his choice, and he can have you authenticate
> to the <host> principal of any machine in any of the trusted realms,
> and given a large installation there is probably a machine where
> he can break in and get access to the host principal's key.
> 

This discussion was very recently had on this mailing list when we
discussed the security weaknesses associated with the DNS Lookup
draft.  The problem you discuss is only if the telnet client performs
a reverse DNS lookup on the IP address received from the initial
hostname search.

If the reverse lookup is not performed your attack is simply a denial
of service.

> > SSH is even worse in that is relies on an insecure client operating
> > system and/or file systems to protect end user private keys.
> > 
> > I would not use SSH as an example upon which to recommend secure
> > protocols be based.
> 
> 
> Come on.
> 
> This applies to all software, be it SSH or Kerberos or something else.
> If you can not trust the machine, there is no software which you could
> add that would make it more trustworthy.

The problem with SSH is that its data is good for all time.  It does
not timeout and become invalid.  Windows machines are inherently
insecure.  The rate at which viruses are distributed as well as Back
Orifice being found on machines is outrageous.  To store private keys
and public keys with a list of the machines to which those keys are 
valid is absolutely insane.  

Last week we had a virus discovered that distributes itself by
searching out shares on nearby machines.  What a great way to
distribute back orifice.  Then all that is needed is a series of
probes to determine which machines have BO installed and use it to
read the SSH files from said machine.

Its a little harder to do this with a memory based cache storing
Kerberos credentials that will expire and must be used in association
with an IP address spoof.

Plus once the SSH data is retrieved and a breakin is discovered there
is no way for a sysadmin to know the scope of the damage.  The
password for the account can't be changed; the list of machines for
which the private key is valid is not available; ...

SSH with its public key authentication is a disaster waiting to
happen.  The only reason that I haven't written and published the
software to take advantage of this hole is because the Columbia
lawyers refuse to defend me when I get arrested and sent to jail for
assisting some teenager that uses the code to breakin to hundreds of
systems.

Kerberos is not the only other method for secure authentication.  SRP,
one time pads, ... are also fine examples of more secure methods for
insecure machines.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Apr 2000 09:32:41 +0200 (METDST)

> If the reverse lookup is not performed your attack is simply a denial

Maybe you thinking of a different problem?

The problem I'm talking of if with any regular use and gives
you at least target impersonation.  And if the victim had delegation of
credentials enabled, you can not only get access to these credentials,
you could also do a man in the middle attack (instead of trying to
impersonate the real target) and wait for other secret information
being disclosed during the session.
All this with spoofing the forward DNS resolution that will *always*
be performed if the target is specified by hostname.

Scenarios like "SecureCRT" with Kerberos-GSSAPI are probably at risk.
I don't know about the traditional kerberized telnet, but my assumption
is, that the spec for *forward* transformation of the hostbased service
name into a Kerberos principal name was adopted from Kerberos.

> valid is absolutely insane.  

Welcome to the world of Single Break-In^H^H^H^H^H^H^H^HSign-On.

I'm sorry, but I don't buy your arguments.  On insecure machines
you cannot add security by adding software.  Adding single sign-on
to vulnerable machines will make it easier for intruders to
compromise more machines after initial break-in.  It doesn't matter
whether the single sign-on is based on Kerberos, SSH or any other
software.  Requiring Hardware tokens (i.e. SmartCards) for each
and every authentication will help you, but it will also restrict
the features available from the single sign-on and it may significantly
impact the throughput of distributed software.

> with an IP address spoof.

Welcome to Windows 2000 Kerberos -- caching your password and providing
automatic ticket refresh.

> assisting some teenager that uses the code to breakin to hundreds of

Supply and use SSH with a PKI that supports certificate revocation
and you can invalidate the credentials.  SSH is a protocol, not just a
particular implementation.  No one forces you to use a tool that
is inadequate for your environments.  I'm using SSH on my windows
Machine, and I don't feel bad about it.  But I also browse the internet
with a HTML-only browser, use a plain-ASCII Email reader, ignoring
all non-ASCII Mime-Attachments that are sent to me.

-Martin