Subject: a potential security hole?

From: OKABE Nobuo <[email-masked]>
Date: Wed, 12 Feb 2003 14:07:43 +0900 (JST)

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

---

From: Michael Thomas <[email-masked]>
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.

More inline:

 > a kind of naming system that can update entry dynamically.

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

 >    between A and B can impersonate B because X can understand

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?

 >                                                      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

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 12 Feb 2003 16:35:26 -0500

>Bob and X somehow in collusion?

I'm a bit confused as well ... because if X know's B's key, then for
the purposes of Kerberos, X _is_ B, and that is something Kerberos
explicitly does _not_ deal with.

--Ken

---

From: OKABE Nobuo <[email-masked]>
Date: Thu, 13 Feb 2003 12:26:14 +0900 (JST)

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

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

> class, but as I said, I'm not understanding the

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

> You mean like Dynamic DNS? Or in the principal

Dynamic DNS (or something like that).

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

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

thanks,

---- nobuo

---

From: OKABE Nobuo <[email-masked]>
Date: Thu, 13 Feb 2003 12:28:54 +0900 (JST)

From: Ken Hornstein <[email-masked]>
Subject: Re: a potential security hole? 
Date: Wed, 12 Feb 2003 16:35:26 -0500

> explicitly does _not_ deal with.

Again, sorry for my poor contets.
I tried to explain the attack in my another mail
that replied to Michael. Please see it.

---- nobuo

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 13 Feb 2003 12:18:37 -0500

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

>    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

---

From: OKABE Nobuo <[email-masked]>
Date: Fri, 14 Feb 2003 09:45:28 +0900 (JST)

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

> that principal would be called host/bar.badguy.org@REALM).

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

> read it?   The AP_REQ is encrypted with B's key.

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

> case, I don't understand why B just doesn't give X his secret key.

Please see step 2) and 3).

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

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