a potential security hole?

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.
Here is one of scenarios.

1) Assumptions


   There are node A, B and X as the following table.
   Alice on A establishes secure communication with B by IPsec.
   Bob want to break Alice's security or privacy.

   =====+============+=======+===========+===========+============
   Node  Principal    key     FQDN/       User        Otherwise
                      shared  IP address
                      w/ KDC
   =====+============+=======+===========+===========+============
   A     ME@REALM     Ka      ME/         Alice, Bob  N/A
                              IPa
   -----+------------+-------+-----------+-----------+------------
   B     PEER@REALM   Kb      PEER/       Alice       N/A
                              IPb
   -----+------------+-------+-----------+-----------+------------
   X     BAD@REALM    Kx      BAD/        Bob         X is a 
                              IPx                     intermediate
                                                      box between
                                                      A and B
   =====+============+=======+===========+===========+============


2) Alice establishes IPsec by KINK.


   Alice establishes IPsec between A and B using KINK.


       A                           KDC                           B

            AS_REQ
              by ME@REALM
        -------------------------->

            AS_REP
              w/ TGTa
        <--------------------------

            TGS_REQ
              by ME@REALM
              for PEER@REALM
              w/  TGTa
        -------------------------->

            TGS_REP
              w/ TICKETb
        <--------------------------

            IPsrc:IPa, IPdst:IPb
            KINK_CREATE
              w/ AP_REQ (including TICKETb)
              w/ ISAKMP
        -------------------------------------------------------->

            IPsrc:IPb, IPdst:IPa
            KINK_REPLY
              w/ AP_REP
              w/ ISAKMP
        <--------------------------------------------------------


   Now IPsec was established between A and B.


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.


       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.

            IPsrc:IPb, IPdst:IPa
            KINK_REPLY
              w/ AP_REP
              w/ ISAKMP
        <------------------------------------------- X impersonates B.
                                                     X can create AP_REP
                                                     because X can
                                                     understand TICKETx.


To avoid this kink of attack, FQDN part of pricipal
must be restricted. 

Any other good ideas for against the attack?

# Again, if the WG had already discussed this kind of attack,
# please give us the pointers.

thanks,

---- nobuo