Re: a potential security hole?

First of all, sorry for my poor contents in the previous mail.

From: Michael Thomas <[email protected]>
Subject: a potential security hole?
Date: Wed, 12 Feb 2003 13:13:00 -0800 (PST)

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

I'm trying to explain the attack in detail.
please see the below.

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

Dynamic DNS (or something like that).

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

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.
    - X is a a intermediate box (ex. a router) between A and B.
    - Bob has his account in node A.

B:
    - B is a node.
    - B's IP adrs is "133.140.20.30".
    - B's FQDN is "boo.goodguy.org".
    - B's principal is "boo.goodguy.org@REALM".
    - B shares a Kerberos master key Ka with KDC.
    - Alice has her account in node B.



     user: Alicd and Bob            user: Bob                 user: Alice
      A ----------------------------------X-------------------------B
        133.140.10.1          133.140.10.2             133.140.20.30
        foo.goodguy.org     bar.badguy.org           boo.goodguy.org


Here is a story:

1)  Alice on the node A starts KINK between 
    "foo.goodguy.org@REALM" and "boo.goodguy.org@REALM".
    It means that IPsec is established between
    "133.140.10.1" and "133.140.20.30".

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

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

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.

5)  Finally, KINK negotiation is done between
    "foo.goodguy.org@REALM" and "bar.badguy.org@REALM".
    From the node A's viewpoint, the IPsec is re-established between
    "133.140.10.1" and "133.140.20.30".
    However, SA is installed in the node X, not the node B.

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

Thanks for your good point. I realized that this is not KINK
specific problem. In other words, this seems to be FQDN/IP
address mapping problem.

Do you know any information or pointer that
takes care of "a general DNS/Kerberos name mapping problem"
or related one as you mentioned ?

# Sorry if my question is well-known issues of Kerberos.

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

thanks,

---- nobuo