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

From: Jeffrey Altman <[email-masked]>
Date: Fri, 14 Apr 2000 12:47:09 EDT

> My oberservations of hostbased service names are:
> - they are INSECURE how rfc2743 defines them and the way they have
>   been implemented in MIT Kerberos 5.

I'm not sure what you are saying here.  Is this supposed to mean that
because Kerberos 5 uses hostnames in Kerberos principals that Kerberos
5 is insecure?

Or just the GSSAPI implementation?

And in what way is it insecure?

> There is a popular telnet replacement called SSH which does just that.
> It eases the use by caching the identities (which are public keys in SSH)
> under the alias of the hostname.  You know that if you don't verify
> "authenticate" a host key (by transfering them out-of-band or comparing
> fingerprints), then you're taking a risk.
> I think it would be a good idea for apps such as telnet to use a similar
> scheme when adding security.  SSH's use of the hostname as the lookup
> key doesn't scale with firewall traversal, however.  Re-use of the
> host key in a server farm should work, however.

SSH in particular is insecure because it does rely on the caching
of public keys under the host name alias on insecure client operating
systems and file systems.

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.

    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: Fri, 14 Apr 2000 19:59:32 +0200 (METDST)

> And in what way is it insecure?

(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.

> I would not use SSH as an example upon which to recommend secure

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.

-Martin

---

From: Greg Hudson <[email-masked]>
Date: Fri, 14 Apr 2000 16:11:38 -0400

>> There is a popular telnet replacement called SSH which does just
>> that.  It eases the use by caching the identities (which are public
>> keys in SSH) under the alias of the hostname.

> SSH in particular is insecure because it does rely on the caching of
> public keys under the host name alias on insecure client operating

At the risk of descending into a rathole: if you're not going to trust
the client to safely store public keys, why are you going to trust the
client to accurately relay keystrokes?

And what does this have to do with SSH's practice of associating the
identity with the alias?  Kerberos would still work, with its current
key management, if you required each alias to have its own service key
(there are complications with the domain search, but that's an
implementation convenience issue).
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]