Re: a potential security hole?

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

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

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.

--Ken