From owner-ietf-kink@mail.vpnc.org Mon Feb 3 06:49:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03861 for ; Mon, 3 Feb 2003 06:49:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13BlpX15886 for ietf-kink-bks; Mon, 3 Feb 2003 03:47:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Blod15882 for ; Mon, 3 Feb 2003 03:47:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03411; Mon, 3 Feb 2003 06:44:13 -0500 (EST) Message-Id: <200302031144.GAA03411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-05.txt Date: Mon, 03 Feb 2003 06:44:13 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, J. Vilhuber Filename : draft-ietf-kink-kink-05.txt Pages : 38 Date : 2003-1-31 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kink-kink-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kink-kink-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-31142936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31142936.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink@mail.vpnc.org Wed Feb 12 00:07:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28852 for ; Wed, 12 Feb 2003 00:07:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C585B27992 for ietf-kink-bks; Tue, 11 Feb 2003 21:08:05 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C57ud27983 for ; Tue, 11 Feb 2003 21:07:59 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57mY24018 for ; Wed, 12 Feb 2003 14:07:56 +0900 (JST) Received: from aml001-0m0001.mitaka.yokogawa.co.jp (aml001-0m0001.mitaka.yokogawa.co.jp [10.24.32.52]) by zns001-0m9002.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57jX24008 for ; Wed, 12 Feb 2003 14:07:48 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by aml001-0m0001.mitaka.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57iF14193 for ; Wed, 12 Feb 2003 14:07:44 +0900 (JST) Date: Wed, 12 Feb 2003 14:07:43 +0900 (JST) Message-Id: <20030212.140743.28781518.nov@tahi.org> To: ietf-kink@vpnc.org Subject: a potential security hole? From: OKABE Nobuo X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 owner-ietf-kink@mail.vpnc.org Wed Feb 12 16:12:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15738 for ; Wed, 12 Feb 2003 16:11:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CLDNU06628 for ietf-kink-bks; Wed, 12 Feb 2003 13:13:23 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLDGd06624 for ; Wed, 12 Feb 2003 13:13:16 -0800 (PST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CLD2SQ013780; Wed, 12 Feb 2003 13:13:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ10107; Wed, 12 Feb 2003 13:13:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05999; Wed, 12 Feb 2003 13:13:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15946.47324.427220.40352@thomasm-u1.cisco.com> Date: Wed, 12 Feb 2003 13:13:00 -0800 (PST) To: OKABE Nobuo Cc: ietf-kink@vpnc.org Subject: a potential security hole? In-Reply-To: <20030212.140743.28781518.nov@tahi.org> References: <20030212.140743.28781518.nov@tahi.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 From owner-ietf-kink@mail.vpnc.org Wed Feb 12 16:34:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16494 for ; Wed, 12 Feb 2003 16:34:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CLa3207137 for ietf-kink-bks; Wed, 12 Feb 2003 13:36:03 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLa2d07133 for ; Wed, 12 Feb 2003 13:36:02 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h1CLZPW8006831; Wed, 12 Feb 2003 16:35:26 -0500 (EST) Message-Id: <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> To: Michael Thomas cc: OKABE Nobuo , ietf-kink@vpnc.org Subject: Re: a potential security hole? In-reply-to: Your message of "Wed, 12 Feb 2003 13:13:00 PST." <15946.47324.427220.40352@thomasm-u1.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 12 Feb 2003 16:35:26 -0500 From: Ken Hornstein X-Spam-Score: hits=0 () User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > 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? 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 owner-ietf-kink@mail.vpnc.org Wed Feb 12 22:25:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22783 for ; Wed, 12 Feb 2003 22:25:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D3QJI15812 for ietf-kink-bks; Wed, 12 Feb 2003 19:26:19 -0800 (PST) Received: from smtp1.att.ne.jp (smtp1.att.ne.jp [165.76.15.137]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D3QCd15808 for ; Wed, 12 Feb 2003 19:26:12 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp1.att.ne.jp (Postfix) with ESMTP id 2560815495; Thu, 13 Feb 2003 12:26:15 +0900 (JST) Date: Thu, 13 Feb 2003 12:26:14 +0900 (JST) Message-Id: <20030213.122614.74757360.nov@tahi.org> To: mat@cisco.com Cc: ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <15946.47324.427220.40352@thomasm-u1.cisco.com> References: <20030212.140743.28781518.nov@tahi.org> <15946.47324.427220.40352@thomasm-u1.cisco.com> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First of all, sorry for my poor contents in the previous mail. From: Michael Thomas 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. . ^^^^^^^^^^^^^ 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 From owner-ietf-kink@mail.vpnc.org Wed Feb 12 22:28:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22816 for ; Wed, 12 Feb 2003 22:28:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D3Sr415900 for ietf-kink-bks; Wed, 12 Feb 2003 19:28:53 -0800 (PST) Received: from smtp3.att.ne.jp (smtp3.att.ne.jp [165.76.15.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D3Spd15896 for ; Wed, 12 Feb 2003 19:28:52 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp3.att.ne.jp (Postfix) with ESMTP id C7B6D15600; Thu, 13 Feb 2003 12:28:54 +0900 (JST) Date: Thu, 13 Feb 2003 12:28:54 +0900 (JST) Message-Id: <20030213.122854.41629712.nov@tahi.org> To: kenh@cmf.nrl.navy.mil Cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> References: <15946.47324.427220.40352@thomasm-u1.cisco.com> <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Ken Hornstein Subject: Re: a potential security hole? Date: Wed, 12 Feb 2003 16:35:26 -0500 > > > > 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? > > 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. 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 owner-ietf-kink@mail.vpnc.org Thu Feb 13 12:29:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19064 for ; Thu, 13 Feb 2003 12:29:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHR2416584 for ietf-kink-bks; Thu, 13 Feb 2003 09:27:02 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHR1d16577 for ; Thu, 13 Feb 2003 09:27:01 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h1DHIcW8017017; Thu, 13 Feb 2003 12:18:39 -0500 (EST) Message-Id: <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> To: OKABE Nobuo cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? In-reply-to: Your message of "Thu, 13 Feb 2003 12:26:14 +0900." <20030213.122614.74757360.nov@tahi.org> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 13 Feb 2003 12:18:37 -0500 From: Ken Hornstein X-Spam-Score: hits=0 () User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >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 From owner-ietf-kink@mail.vpnc.org Thu Feb 13 19:46:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24570 for ; Thu, 13 Feb 2003 19:46:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1E0jUi01928 for ietf-kink-bks; Thu, 13 Feb 2003 16:45:30 -0800 (PST) Received: from smtp2.att.ne.jp (smtp2.att.ne.jp [165.76.15.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E0jQd01923 for ; Thu, 13 Feb 2003 16:45:27 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp2.att.ne.jp (Postfix) with ESMTP id F1CD124F8C; Fri, 14 Feb 2003 09:45:28 +0900 (JST) Date: Fri, 14 Feb 2003 09:45:28 +0900 (JST) Message-Id: <20030214.094528.74756267.nov@tahi.org> To: kenh@cmf.nrl.navy.mil Cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> References: <20030213.122614.74757360.nov@tahi.org> <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Ken Hornstein Subject: Re: a potential security hole? Date: Thu, 13 Feb 2003 12:18:37 -0500 > >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). Sorry again. I mean that Kx is the TGS key. > >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. No. The AP_REQ is encrypted with X'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. Please see step 2) and 3). 2) Bob updates X's IP address as a bogus one by dynamic DNS update, e.g. . Now IP address of "bar.badguy.org" becomes 133.140.20.30 that should be the B's one. 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". 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