Re: a potential security hole?

From: Ken Hornstein <[email protected]>
Subject: Re: a potential security hole? 
Date: Thu, 13 Feb 2003 12:18:37 -0500

> >Here are players:
> >
> >A:
> >    - A is a node.
> >    - A's IP adrs is "133.140.10.1".
> >    - A's FQDN is "foo.goodguy.org".
> >    - A's principal is "foo.goodguy.org@REALM".
> >    - A shares a Kerberos master key Ka with KDC.
> >    - Alice and Bob have their account in node A.
> >        
> >X: 
> >    - X is a node.
> >    - X's one of IP addresses is "133.140.10.2".
> >    - X's FQDN is "bar.badguy.org".
> >    - X's principal is "bar.badguy.org@REALM".
> >    - X shares a Kerberos master key Kx with KDC.
> 
> Whoah, okay, when you say the "master" key (Kx) are you talking about
> what is typically called the "master" key (K/M) in MIT implementations,
> the TGS key, or just the key assigned to that principal? (BTW, typically
> that principal would be called host/bar.badguy.org@REALM).

Sorry again.
I mean that Kx is the TGS key.

> >4)  The node X intercepts the KINK CREATE message whose destination
> >    is the node B. X can read the message because the message
> >    is for "bar.badguy.org@REALM".
> >    Then, X can reply a bogus KINK REPLY message to the A.
> 
> I don't follow this step; if the destination is B, how exactly can X
> read it?   The AP_REQ is encrypted with B's key.

No. The AP_REQ is encrypted with X's key.

> This seems like it requires cooperation between B and X; if that's the
> case, I don't understand why B just doesn't give X his secret key.

Please see step 2) and 3).

    2)  Bob updates X's IP address as a bogus one by dynamic DNS update,
        e.g. <bar.badguy.org, 133.140.20.30>.

Now IP address of "bar.badguy.org" becomes 133.140.20.30
that should be the B's one.

    3)  Then, Bob on the node A starts KINK between
        "foo.goodguy.org@REALM" and "bar.badguy.org@REALM".
        It means that IPsec will be established between
        "133.140.10.1" and "133.140.20.30".

By KINK's definition, principal is "kink/FQDN@REALM".
So KINK on the A throws the message to "bar.badguy.org"'s
IP address, that is 133.140.20.30 because of the step 2).

In another words, the KINK throws the message to
B's IP address.

Howeve the contet of the message is for "bar.badguy.org@REALM".
The X can read the message because X is "bar.badguy.org@REALM".

thanks,

---- nobuo