a potential security hole?

I'm trying -- somewhat unsucessfully -- to
understand the attack, but let me first ask a
question: is this attack specific to KINK itself,
or is it generally applicable to any Kerberos
application which does an ap-rep/ap-req as KINK
does? It looks to me like it might be in that
class, but as I said, I'm not understanding the
attack.

More inline:

OKABE Nobuo writes:
 > 
 > Hi all,
 > 
 > # Sorry if this kind of discussion had already been held so far.
 > # We got involved KINK recently.
 > 
 > We found a potential security hole using KINK with
 > a kind of naming system that can update entry dynamically.

You mean like Dynamic DNS? Or in the principal
database itself?


 > 3) A bad guy, Bob, takes over the SA pairs.
 > 
 > 
 >    First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb)
 >    of his naming system. Then, he initiates KINK for BAD@REALM.
 >    KINK on A starts KINK message. X that is a intermediate box
 >    between A and B can impersonate B because X can understand
 >    a ticket for BAD@REALM.

I assume here that "X" is the attaker, not Bob?
Otherwise I'm really confused because why would
Bob update his naming to point at "BAD"? Are
Bob and X somehow in collusion?

 >        A                           KDC              X             B
 > 
 >             TGS_REQ
 >               by ME@REALM
 >               for BAD@REALM
 >               w/  TGTa
 >         -------------------------->
 > 
 >             TGS_REP
 >               w/ TICKETx
 >         <--------------------------
 > 
 >             IPsrc:IPa, IPdst:IPb
 >             KINK_CREATE
 >               w/ AP_REQ (including TICKETx)
 >               w/ ISAKMP
 >         -------------------------------------------> X impersonates B.
 >                                                      X can reads AP_REQ
 >                                                      because X can understand TICKETx.

  But... is that impersonation, or is it Bob just
  changing name bindings such that it's now
  pointing to X? In any case, assuming the name
  binding was in DNS, the KDC doesn't use DNS so
  this would be a general DNS/Kerberos name
  mapping problem, not a KINK specific problem.

  If _not_, I don't understand why Bob would
  change the name binding in the KDC if it's not
  in his interest.

  I must be missing something.

	 Mike