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

From: Jeffrey Altman <[email-masked]>
Date: Mon, 17 Apr 2000 6:53:05 EDT

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

I would really like to understand this attack.  But somehow I am
failing to.  Here is my scenario, you please explain how the attack is
performed.  

 . client retreives a forwardable TGT

 . client decides to telnet to foo.bar.edu.  telnet client performs
   forward DNS to retrieve ip address for said host.  (The IP 
   address is spoofed and attacker's compromised machine, 
   y.y.y.y, is provided instead.)

 . client retrieves service ticket for host/foo.bar.edu@REALM

 . client performs mutual auth with y.y.y.y using ticket
   host/foo.bar.edu@REALM.  Authentication fails.

This is a denial of service attack, not a successful attack.

As for the man in the middle attacks.  Even if I connect from A to
B and then to C, no *sensitive data* or forwarded credentials 
should be sent until after I have succeeded in the mutual
authentication AND successfully encrypted the channel in both
directions.  How is the person at B going to read anything I send or
receive? 

Clearly, if you send a forwardable credential to an unauthenticated
host or send it over an unencrypted channel you have problems.  Same
if you base the construction of your service ticket request upon data
stored in the DNS.  

Somehow I get the feeling you are referring to the use of one-way
authentication and insecure applications; not a weakness inherent in 
the protocol.

If I am wrong, please explain it to me.  If these holes are as obvious
as you seem to make them out to be then I am making some bad
assumptions about how to secure my infrastructure.

    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 15:14:21 +0200 (METDST)

>  . client retrieves service ticket for host/foo.bar.edu@REALM

Wrong.

The client passes either "[email-masked]" or "[email-masked]"
as a "hostbased service name to Kerberos (via or without GSS-API",
and the transformation into a Kerberos principal name canonicalizes
the hostname via DNS.  That's what rfc2743, Section 4.1 specifies
and what MIT Kerberos 5 has been doing all the time.

Therefore your client is going to acquire a service ticket to

   host/attackers.host.of.choice@ANY-TRUSTED-REALM

and perform a successful mutual authentication with the attackers
host of choice.

Man in the middle attack is possible when client uses
credential forwarding.

-Martin