From owner-ietf-kink Wed Aug 9 10:35:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05694 for ietf-kink-bks; Wed, 9 Aug 2000 10:35:27 -0700 (PDT) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05679 for ; Wed, 9 Aug 2000 10:35:12 -0700 (PDT) Received: from rcn.ihtfp.org (root@blamo [207.3.231.13]) by breeze.research.telcordia.com (8.10.1/8.10.1) with SMTP id e79HXtY01707 for ; Wed, 9 Aug 2000 13:33:56 -0400 (EDT) From: Derek Atkins Date: Wed, 09 Aug 2000 18:33:54 GMT Message-ID: <20000809.18335400@rcn.ihtfp.org> Subject: Welcome to IETF-KINK! To: ietf-kink@vpnc.org X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA05690 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, and welcome to the IETF-KINK mailing list. We're still in the throws of setting up this list and associated sites, but hopefully we can ramp up quickly and start getting some good conversation going on this list. The first item on the agenda are to agree on a set of requirements for the protocol. I'd like to limit discussion at this time to requirements only. Once we've agreed on the requirements then we can move on to protocol discussions. I'm hoping that Mike Thomas can send out a current draft of the requirements in order to start a discussion. Again, welcome to KINK. -derek From owner-ietf-kink Wed Aug 9 11:22:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06671 for ietf-kink-bks; Wed, 9 Aug 2000 11:22:56 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06667 for ; Wed, 9 Aug 2000 11:22:55 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA14248; Wed, 9 Aug 2000 11:21:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19911; Wed, 9 Aug 2000 11:21:42 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="hUL/GSCR9M" Content-Transfer-Encoding: 7bit Message-ID: <14737.41269.489166.117071@thomasm-u1.cisco.com> Date: Wed, 9 Aug 2000 11:21:41 -0700 (PDT) To: ietf-kink@vpnc.org Cc: mshore@cisco.com Subject: KINK requirements draft 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: --hUL/GSCR9M Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit As promised, here's the updated requirements draft. Note that I've changed the name from "charter" to "reqmt" to reflect that this is a requirements document. Mike --hUL/GSCR9M Content-Type: application/octet-stream Content-Disposition: attachment; filename="draft-thomas-kink-reqmt-00.txt" Content-Transfer-Encoding: base64 CgoKCgoKSU5URVJORVQtRFJBRlQgICAgICBLSU5LIFJlcXVpcmVtZW50cyAgICAgTWljaGFl bCBUaG9tYXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB dWd1c3QgOSwgMjAwMAoKCgoKCgogICAgICAgICAgICAgICAgS2VyYmVyaXplZCBJbnRlcm5l dCBOZWdvdGlhdGlvbiBvZiBLZXlzCgogICAgICAgICAgICAgICAgICAgICBkcmFmdC10aG9t YXMta2luay1yZXFtdC0wMC50eHQKCgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBk b2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5j ZSB3aXRoCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZwogICBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsCiAgIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAg IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4KCkFic3RyYWN0 CgogICBUaGUgS0lOSyB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBjcmVhdGUgYSBz dGFuZGFyZHMgdHJhY2sKICAgcHJvdG9jb2wgdG8gZmFjaWxpdGF0ZSBjZW50cmFsaXplZCBr ZXkgbWFuYWdlbWVudCBmb3IgSVBzZWMgc2VjdXJpdHkKICAgYXNzb2NpYXRpb25zIGFzIGRl ZmluZWQgaW4gUkZDIDI0MDEsIGFzIGFuIGFsdGVybmF0aXZlIHRvIElLRSAoUkZDCiAgIDI0 MDkpLiAgUGFydGljaXBhdGluZyBzeXN0ZW1zIHdpbGwgdXNlIHRoZSBLZXJiZXJvcyBhcmNo aXRlY3R1cmUgYXMKICAgZGVmaW5lZCBpbiBSRkMgMTUxMCAoYW5kIGl0cyBzdWNjZXNzb3Jz KSBmb3Iga2V5IG1hbmFnZW1lbnQuIFRoZSBnb2FsCiAgIG9mIHRoZSB3b3JraW5nIGdyb3Vw IGlzIHRvIHByb2R1Y2UgYSBzdHJlYW1saW5lZCwgZmFzdCwgZWFzaWx5CiAgIG1hbmFnZWQs IGFuZCBjcnlwdG9ncmFwaGljYWxseSBzb3VuZCBwcm90b2NvbCB3aXRob3V0IHJlcXVpcmlu ZwogICBwdWJsaWMga2V5LgoKICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgcmVxdWly ZSBjaGFuZ2VzIHRvIGVpdGhlciBJUHNlYyAoUkZDCiAgIDI0MDEpLCBvciBLZXJiZXJvcyAo UkZDIDE1MTApLgoKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFmdC10aG9tYXMta2lu ay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDFdCgoKCgoKSU5URVJORVQtRFJBRlQg IEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAgICA5IEF1Z3VzdCAy MDAwCgoKTW90aXZhdGlvbgoKICAgVGhlIElQc2VjIHdvcmtpbmcgZ3JvdXAgaGFzIGRlZmlu ZWQgYSBudW1iZXIgb2YgcHJvdG9jb2xzIHdoaWNoCiAgIHByb3ZpZGUgdGhlIGFiaWxpdHkg dG8gY3JlYXRlIGFuZCBtYWludGFpbiBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUKICAgc2Vj dXJpdHkgYXNzb2NpYXRpb25zIGF0IGxheWVyIHRocmVlIChpZSwgdGhlIElQIGxheWVyKS4g IFRoaXMgZWZmb3J0CiAgIGhhcyBwcm9kdWNlZCB0d28gZGlzdGluY3QgcHJvdG9jb2xzOgoK ICAgMSkgYSBtZWNoYW5pc20gdG8gZW5jcnlwdCBhbmQgYXV0aGVudGljYXRlIElQIGRhdGFn cmFtIHBheWxvYWRzIHdoaWNoCiAgICAgIGFzc3VtZXMgYSBzaGFyZWQgc2VjcmV0IGJldHdl ZW4gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIKCiAgIDIpIGEgbWVjaGFuaXNtIGZvciBJUHNl YyBwZWVycyB0byBwZXJmb3JtIG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgZXhj aGFuZ2Uga2V5aW5nIG1hdGVyaWFsCgogICBUaGUgSVBzZWMgd29ya2luZyBncm91cCBoYXMg ZGVmaW5lZCBhIHBlZXIgdG8gcGVlciBhdXRoZW50aWNhdGlvbiBhbmQKICAga2V5aW5nIG1l Y2hhbmlzbSwgSUtFIChSRkMgMjQwOSkuIE9uZSBvZiB0aGUgZHJhd2JhY2tzIG9mIGEgcGVl ciB0bwogICBwZWVyIHByb3RvY29sIGlzIHRoYXQgZWFjaCBwZWVyIG11c3Qga25vdyBhbmQg aW1wbGVtZW50IGEgc2l0ZSdzCiAgIHNlY3VyaXR5IHBvbGljeSB3aGljaCBpbiBwcmFjdGlj ZSBjYW4gYmUgcXVpdGUgY29tcGxleC4gSW4gYWRkaXRpb24sCiAgIHRoZSBsYWNrIG9mIGEg dHJ1c3RlZCB0aGlyZCBwYXJ0eSByZXF1aXJlcyB0aGUgdXNlIG9mIERpZmZpZSBIZWxsbWFu CiAgIChESCkgdG8gZXN0YWJsaXNoIGEgc2hhcmVkIHNlY3JldC4gREgsIHVuZm9ydHVuYXRl bHksIGlzIGNvbXB1dGF0aW9uLQogICBhbGx5IHF1aXRlIGV4cGVuc2l2ZSBhbmQgcHJvbmUg dG8gZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcy4gSUtFIGFsc28KICAgcmVsaWVzIG9uIFgu NTA5IGNlcnRpZmljYXRlcyB0byByZWFsaXplIHNjYWxhYmxlIGF1dGhlbnRpY2F0aW9uIG9m CiAgIHBlZXJzLiBEaWdpdGFsIHNpZ25hdHVyZXMgYXJlIGFsc28gY29tcHV0YXRpb25hbGx5 IGV4cGVuc2l2ZSBhbmQgY2VyLQogICB0aWZpY2F0ZSBiYXNlZCB0cnVzdCBtb2RlbHMgYXJl IGRpZmZpY3VsdCB0byBkZXBsb3kgaW4gcHJhY3RpY2UuCiAgIFdoaWxlIElLRSBkb2VzIGFs bG93IGZvciBwcmUtc2hhcmVkIHN5bW1ldHJpYyBrZXlzLCBrZXkgZGlzdHJpYnV0aW9uCiAg IGlzIHJlcXVpcmVkIGJldHdlZW4gYWxsIHBlZXJzIC0tIGFuIE8obl4yKSBwcm9ibGVtIC0t IHdoaWNoIGlzIHByb2ItCiAgIGxlbWF0aWMgZm9yIGxhcmdlIGRlcGxveW1lbnRzLgoKICAg S2VyYmVyb3MgKFJGQyAxNTEwKSBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgdHJ1c3RlZCB0 aGlyZCBwYXJ0eQogICBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50cyBhbmQgc2VydmVycy4g Q2xpZW50cyBhdXRoZW50aWNhdGUgdG8gYQogICBjZW50cmFsaXplZCBzZXJ2ZXIgLS0gdGhl IEtleSBEaXN0cmlidXRpb24gQ2VudGVyIC0tIHdoaWNoIGluIHR1cm4KICAgaXNzdWVzIHRp Y2tldHMgdGhhdCBzZXJ2ZXJzIGNhbiBkZWNyeXB0IHRodXMgcHJvdmluZyB0aGF0IHRoZSBj bGllbnQKICAgaXMgd2hvIGl0IGNsYWltcyB0byBiZS4gT25lIG9mIHRoZSBlbGVtZW50cyBv ZiBhIEtlcmJlcm9zIHRpY2tldCBpcyBhCiAgIHNlc3Npb24ga2V5IHdoaWNoIGlzIGdlbmVy YXRlZCBieSB0aGUgS0RDIHdoaWNoIG1heSBiZSB1c2VkIGJ5IHRoZQogICBjbGllbnQgYW5k IHNlcnZlciB0byBzaGFyZSBhIHNlY3JldC4gS2VyYmVyb3MgYWxzbyBhbGxvd3MgZm9yIGJv dGgKICAgc3ltbWV0cmljIGtleSBhdXRoZW50aWNhdGlvbiwgYXMgd2VsbCBhcyBjZXJ0aWZp Y2F0ZSBiYXNlZCBwdWJsaWMga2V5CiAgIGF1dGhlbnRpY2F0aW9uIChQS2luaXQpLiBTaW5j ZSB0aGUgYXV0aGVudGljYXRpb24gcGhhc2Ugb2YgS2VyYmVyb3MKICAgaXMgcGVyZm9ybWVk IGJ5IHRoZSBLREMsIHRoZXJlIGlzIG5vIG5lZWQgdG8gcGVyZm9ybSBleHBlbnNpdmUgREgg b3IKICAgWC41MDkgY2VydGlmaWNhdGUgc2lnbmF0dXJlcy92ZXJpZmljYXRpb24gb3BlcmF0 aW9ucyBvbiBzZXJ2ZXJzLgogICBXaGlsZSBjbGllbnRzIG1heSBhdXRoZW50aWNhdGUgdXNp bmcgWC41MDkgY2VydGlmaWNhdGVzLCB0aGUgYXV0aGVuLQogICB0aWNhdGlvbiBwaGFzZSBj YW4gYmUgYW1vcnRpemVkIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjcmVkZW50aWFscy4K ICAgVGhpcyBhbGxvd3MgYSBzaW5nbGUgREggYW5kIGNlcnRpZmljYXRlIGV4Y2hhbmdlIHRv IGJlIHVzZWQgdG8ga2V5CiAgIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB3aXRoIG1hbnkgc2Vy dmVycyBpbiBhIGNvbXB1dGF0aW9uYWxseSBlY29ub21pYwogICB3YXkuIEtlcmJlcm9zIGFs c28gc3VwcG9ydCBjbGllbnRzIHdpdGggc3ltbWV0cmljIGtleXMgYnV0IHVubGlrZQogICBJ S0UsIHRoZSBzeW1tZXRyaWMga2V5cyBhcmUgc3RvcmVkIGluIHRoZSBLREMgbWFraW5nIHRo ZSBudW1iZXIgb2YKICAga2V5cyBhbiBPKG4pIHByb2JsZW0gcmF0aGVyIHRoYW4gTyhuXjIp LiAgS2VyYmVyb3MgYWxzbyBhbGxvd3Mgc2VjdS0KICAgcml0eSBwb2xpY3kgdG8gYmUgbWFu YWdlZCBpbiBhIG1vcmUgY2VudHJhbGl6ZWQgZmFzaGlvbiwgcmF0aGVyIHRoYW4KICAgZXhw ZWN0aW5nIGVhY2ggcG90ZW50aWFsbHkgdW50cnVzdHdvcnRoeSBwZWVyIHRvIGFiaWRlIGJ5 IHN0YXRlZAogICBzZWN1cml0eSBwb2xpY2llcyBvZiBhbiBvcmdhbml6YXRpb24uCgoKClRo b21hcyAgICAgICAgICAgICAgICAgZHJhZnQtdGhvbWFzLWtpbmstcmVxbXQtMDAgICAgICAg ICAgICAgICBbUGFnZSAyXQoKCgoKCklOVEVSTkVULURSQUZUICBLZXJiZXJpemVkIEludGVy bmV0IE5lZ290aWF0aW9uIG9mIEtleXMgICAgOSBBdWd1c3QgMjAwMAoKCiAgIFRoZSBLSU5L IHdvcmtpbmcgZ3JvdXAgdGFrZXMgdGhlc2UgYmFzaWMgZmVhdHVyZXMgb2YgS2VyYmVyb3Mg YW5kCiAgIHVzZXMgdGhlbSB0byBpdHMgYWR2YW50YWdlIHRvIGNyZWF0ZSBhIHByb3RvY29s IHdoaWNoIGNhbiBlc3RhYmxpc2gKICAgYW5kIG1haW50YWluIElQc2VjIHNlY3VyaXR5IGFz c29jaWF0aW9ucyAoUkZDIDI0MDEpLiAgSXQgc2hvdWxkIGJlCiAgIG5vdGVkIHRoYXQgS0lO SyBpcyBub3QgYSByZXBsYWNlbWVudCBmb3IgSUtFLiAgSUtFIGhhcyBvbmUgcHJvcGVydHkK ICAgd2hpY2ggS0lOSyBjYW5ub3QgcmVwcm9kdWNlOiAgdGhlIGFiaWxpdHkgZm9yIHR3byBw ZWVycyB0byBtdXR1YWxseQogICBhdXRoZW50aWNhdGUgYW5kIGV4Y2hhbmdlIGtleXMgd2l0 aG91dCB0aGUgbmVlZCBmb3IgYW4gYWN0aXZlbHkgcGFyLQogICB0aWNpcGF0aW5nIHRoaXJk IHBhcnR5LiBIb3dldmVyLCB0aGVyZSBhcmUgbWFueSBzaXR1YXRpb25zIHdoZXJlIGEKICAg dHJ1c3RlZCB0aGlyZCBwYXJ0eSB3aGljaCBwcm94aWVzIGF1dGhlbnRpY2F0aW9uIGlzIHZp YWJsZSwgYW5kIGluCiAgIGZhY3QgZGVzaXJhYmxlLgoKICAgV2hpbGUgS2VyYmVyb3Mgc3Bl Y2lmaWVzIGEgc3RhbmRhcmQgcHJvdG9jb2wgYmV0d2VlbiB0aGUgY2xpZW50IGFuZAogICB0 aGUgS0RDIHRvIGdldCB0aWNrZXRzLCB0aGUgYWN0dWFsIHRpY2tldCBleGNoYW5nZSBiZXR3 ZWVuIGNsaWVudCBhbmQKICAgc2VydmVyIGlzIGFwcGxpY2F0aW9uIHNwZWNpZmljLiAgS0lO SyBpcyBpbnRlbmRlZCB0byBiZSBhbiBhbHRlcm5hLQogICB0aXZlIHRvIHJlcXVpcmluZyBl YWNoIGFwcGxpY2F0aW9uIGhhdmluZyBpdHMgb3duIG1ldGhvZCBvZiB0cmFuLQogICBzcG9y dGluZyBhbmQgdmFsaWRhdGluZyBzZXJ2aWNlIHRpY2tldHMgdXNpbmcgYSBwcm90b2NvbCB3 aGljaCBpcwogICBlZmZpY2llbnQgYW5kIHRhaWxvcmVkIHRvIHRoZSBzcGVjaWZpYyBuZWVk cyBvZiBLZXJiZXJvcyBhbmQgdGhlCiAgIGFwcGxpY2F0aW9ucyBmb3Igd2hpY2ggaXQgcHJv dmlkZXMga2V5aW5nIGFuZCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24uCgogICBHaXZlbiB0aGUg YWJvdmUsIGEgbmV3IGdlbmVyYWwga2V5aW5nIHByb3RvY29sIHdoaWNoIGxldmVyYWdlcyB0 aGUKICAgc2NhbGFiaWxpdHkgb2YgS2VyYmVyb3MgaXMgZGVzaXJhYmxlLiAgVGhlIHdvcmtp bmcgZ3JvdXAncyBmaXJzdCB0YXNrCiAgIGlzIHRvIGRlZmluZSB0aGlzIHByb3RvY29sIGFu ZCBkZWZpbmUgYW4gZG9tYWluIG9mIGludGVycHJldGF0aW9uIGZvcgogICBJUHNlYyB0byBl c3RhYmxpc2ggYW5kIG1haW50YWluIElQc2VjIHNlY3VyaXR5IGFzc29jaWF0aW9ucy4gVGhl IHByby0KICAgdG9jb2wgbXVzdCBiZSBhYmxlIHRvIHRha2UgZnVsbCBhZHZhbnRhZ2Ugb2Yg dGhlIGZlYXR1cmVzIG9mIFJGQyAyNDAxCiAgIGJ1dCBpbiB0aGUgY29udGV4dCBvZiBhIGNl bnRyYWxpemVkIGtleWluZyBhdXRob3JpdHkuCgpSZXF1aXJlbWVudHMKCiAgIEtJTksgbXVz dCBtZWV0IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzIGF0IGEgbWluaW11bToKCi0gICAg VGhlIHByb3RvY29sIG11c3QgdXNlIEtlcmJlcm9zIHRvIGNyZWF0ZSBzZXNzaW9uIGtleXMg aW4gYSBzZWN1cmUKICAgICBmYXNoaW9uCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGFi bGUgdG8gaW50ZWdyYXRlIGludG8gc2VjdXJpdHkgYXJjaGl0ZWN0dXJlCiAgICAgb2YgSVBT ZWMgKFJGQyAyNDAxKQoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBiZSBhYmxlIHRvIHN0YXJ0 IHVwIFNBJ3MgcmVnYXJkbGVzcyBvZiBhbnkKICAgICBjbGllbnQvc2VydmVyIGRpc3Bvc2l0 aW9uIGluIHRoZSBrZXlpbmcgcHJvdG9jb2wKCi0gICAgS2VyYmVyb3MgbWFrZXMgYSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZlcnM7IElQc2VjCiAgICAgZG9lcyBu b3QuIFRoZSBwcm90b2NvbCBtdXN0IGFsbG93IGZvciBJUHNlYyBzZWN1cml0eSBhc3NvY2lh dGlvbnMKICAgICB0byBiZSBpbml0aWF0ZWQgYnkgYm90aCBzZXJ2ZXJzIGFuZCBjbGllbnRz LCB0aHVzIHByZXNlcnZpbmcKICAgICBJUHNlYydzIHBlZXIgdG8gcGVlciBuYXR1cmUuCgot ICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gaW5pdGlhbGx5IGF1dGhlbnRpY2F0 ZSB1c2luZyBlaXRoZXIKICAgICBzZWNyZXQga2V5LCBvciBwdWJsaWMga2V5IGF1dGhlbnRp Y2F0aW9uLgoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBhY2NvbW1vZGF0ZSBhbnkgY29tYmlu YXRpb24gb2YgcHVibGljIGFuZCBzZWNyZXQKICAgICBrZXkgcGVlcnMKCgoKVGhvbWFzICAg ICAgICAgICAgICAgICBkcmFmdC10aG9tYXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAg IFtQYWdlIDNdCgoKCgoKSU5URVJORVQtRFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVn b3RpYXRpb24gb2YgS2V5cyAgICA5IEF1Z3VzdCAyMDAwCgoKLSAgICBUaGUgcHJvdG9jb2wg bXVzdCBiZSBhYmxlIHRvIGFsbG93IGEgcGVlciB0byBhdXRoZW50aWNhdGUgYW5kIHBhci0K ICAgICB0aWNpcGF0ZSBpbiBtYW55IHJlYWxtcwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBo YW5kbGUgYWJzb2x1dGUgdGltZSBza2V3IGdyYWNlZnVsbHkKCi0gICAgVGhlIHByb3RvY29s IG11c3QgYmUgYWJsZSB0byBjcmVhdGUsIG1vZGlmeSwgcmVrZXksIGFuZCBkZWxldGUKICAg ICBzZWN1cml0eSBhc3NvY2lhdGlvbnMKCi0gICAgVGhlIHByb3RvY29sIG11c3QgYmUgY2Fw YWJsZSBvZiBzZXR0aW5nIHVwIGJvdGggdHJhbnNwb3J0IGFuZCB0dW4tCiAgICAgbmVsIG1v ZGVzIG9mIElQU2VjCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGNhcGFibGUgb2Ygc2V0 dGluZyB1cCBib3RoIEFIIGFuZCBFU1Agc2VjdXJpdHkKICAgICBhc3NvY2lhdGlvbnMKCi0g ICAgVGhlIHByb3RvY29sIG11c3QgYmUgY2FwYWJsZSBvZiBuZWdvdGlhdGluZyBjaXBoZXIg c3VpdGVzCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGNhcGFibGUgb2Ygc2V0dGluZyB1 cCBJUHNlYyBmbG93IHNlbGVjdG9ycwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBiZSBjYXBh YmxlIG9mIHJla2V5aW5nIHdpdGhvdXQgdGhlIGFzc2lzdGFuY2Ugb2YKICAgICB0aGUgS0RD IGlmIHRoZSBzZXNzaW9uIHRpY2tldCBpcyBzdGlsbCB2YWxpZAoKLSAgICBUaGUgcHJvdG9j b2wgbXVzdCBtYWtlIGFuIGVmZm9ydCB0byBtaXRpZ2F0ZSB0aGlyZCBwYXJ0eSBEZW5pYWwg b2YKICAgICBTZXJ2aWNlIGF0dGFja3MgKGFrYSBab21iaWVzIGF0dGFja3MpCgotICAgIFRo ZSBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gYmUgdXNlZCBmb3IgbW9yZSB0aGFuIElQc2Vj IGtleWluZwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBzdXBwb3J0IGJvdGggSVB2NCBhbmQg SVB2NgoKCkRlbGl2ZXJhYmxlcwoKICAgICBUaGUgd29ya2luZyBncm91cCdzIHJlc3BvbnNp YmlsaXRpZXMgYXJlIGFzIGZvbGxvd3M6CgotICAgIENvbXBsZXRlIGEgcHJvdG9jb2wgd2hp Y2ggbWVldHMgdGhlIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBhYm92ZQoKLSAgICBLZWVwIGFs bCBLSU5LIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIG1vdmluZyBhbG9uZyBwdWJsaWNhdGlv biAvCiAgICAgc3RhbmRhcmRpemF0aW9uIHRyYWNrLgogICBUaGUgbGlzdCBvZiB0aGUgd29y a2luZyBncm91cCdzIGN1cnJlbnQgd29yayBpdGVtcyBpcyBhcyBmb2xsb3dzOgoKLSAgICBE ZWZpbmUgdGhlIGJhc2UgS2VyYmVyaXplZCBJbnRlcm5ldCBOZWdvdGlhdGlvbiBvZiBLZXlz IHByb3RvY29sLgoKR29hbHMgYW5kIE1pbGVzdG9uZXMKCgpTZXAgMjAwMCAgICAgIENvbnNl bnN1cyBvbiByZXF1aXJlbWVudHMgZG9jdW1lbnQKCkRlYyAyMDAwICAgICAgUmV2aWV3IGRy YWZ0cyBhdCBEZWMgSUVURgoKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFmdC10aG9t YXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDRdCgoKCgoKSU5URVJORVQt RFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAgICA5IEF1 Z3VzdCAyMDAwCgoKSmFuIDIwMDEgICAgICBDb25zZW5zdXMgb24gYmFzZSBkcmFmdCBwcm90 b2NvbAoKTWFyIDIwMDEgICAgICBXRyBMYXN0IGNhbGwgb24gZHJhZnQKCk1hciAyMDAxLUp1 biAyMDAxCiAgICAgICAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBCYWtlb2ZmcwoKQXVnIDIw MDEgICAgICBJbnRlcm9wZXJhYmlsaXR5IHJlc3VsdHMsIGRlY2lzaW9uIHRvIHJlY3ljbGUg b3IgbW92ZSBmb3ItCiAgICAgICAgICAgICAgd2FyZAoKQWRtaW5pc3RyYXRpdmEKCkNoYWly KHMpOgoKICBEZXJlayBBdGtpbnMgPHdhcmxvcmRAcmVzZWFyY2gudGVsY29yZGlhLmNvbT4K CkRvY3VtZW50IEVkaXRvcjoKCiAgVEJECgpJbnRlcm5ldCBBcmVhIERpcmVjdG9yKHMpOgoK ICBKZWZmcmV5IFNjaGlsbGVyIDxqaXNAbWl0LmVkdT4KICBNYXJjdXMgTGVlY2ggPG1sZWVj aEBub3J0ZWxuZXR3b3Jrcy5jb20+CgpJbnRlcm5ldCBBcmVhIEFkdmlzb3I6CgpUQkQKCk1h aWxpbmcgTGlzdHM6CgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogaWV0Zi1raW5rQHZwbmMub3Jn CiAgVG8gU3Vic2NyaWJlOiBtYWpvcmRvbW9AdnBuYy5vcmcKICBJbiBCb2R5OiBpbiBib2R5 OiBzdWJzY3JpYmUgaWV0Zi1raW5rCiAgQXJjaGl2ZTogZnRwOi8vCgpBY2tub3dsZWRnbWVu dHMKCiAgIFRoZSBvcmlnaW5hbCBLSU5LIEthYmFsIHdhczoKCiAgIE1pY2hhZWwgVGhvbWFz IChDaXNjbykKICAgRGF2aWQgTWNHcmV3IChDaXNjbykKICAgSmFuIFZpbGh1YmVyIChDaXNj bykKICAgSm9uYXRoYW4gVHJvc3RsZSAoQ2lzY28pCiAgIE1hdHQgSHVyIChDeWJlcnNhZmUp CiAgIE1pa2UgRnJvaCAoQ3liZXJzYWZlKQogICBTYXNoYSBNZWR2aW5za3kgKEdJKQogICBE ZXJlayBBdGtpbnMgKFRlbGNvcmRpYSkKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFm dC10aG9tYXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDVdCgoKCgoKSU5U RVJORVQtRFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAg ICA5IEF1Z3VzdCAyMDAwCgoKICAgSXQgbXVzdCBhbHNvIGJlIGFja25vd2xlZGdlZCB0aGF0 IHRoZSBQYWNrZXRjYWJsZSBTZWN1cml0eQogICBzcGVjaWZpY2F0aW9uIFBLVC1TUC1TRUMt STAxLTk5MTIwMSBwcm92aWRlZCB0aGUgcmF3IGZvZGRlcgogICBmb3IgdGhpcyBlZmZvcnQg aW4gaXRzIEtlcmJlcml6ZWQgSVBzZWMgc2VjdGlvbiwgYW5kIGFsbCBvZgogICB0aGUgZm9j dXMgdGVhbSBtZW1iZXJzIHdobyBwbGF5ZWQgYSBwYXJ0IGluIHRoZSBzcGVjLiBXZSBtdXN0 CiAgIGFsc28gYWNrbm93bGVkZ2UgTmFuY3kgRGF2b3VzdCBvZiBDYWJsZWxhYnMgZm9yIGtl ZXBpbmcgb3JkZXIKICAgaW4gb3VyIG5vcm1hbGx5IGRpc29yZGVybHkgcHJvY2VlZGluZ3Mu CgpSZWZlcmVuY2VzCgpbMV0gIFRoZSBDQVQgV29ya2luZyBHcm91cCwgSi4gS29obCwgQy5O ZXVtYW4sICJUaGUgS2VyYmVyb3MgTmV0d29yawogICAgIEF1dGhlbnRpY2F0aW9uIFNlcnZp Y2UgKFY1KSIsIFJGQyAxNTEwLCBTZXB0ZW1iZXIgMTk5MwoKWzJdICBUaGUgSVBzZWMgV29y a2luZyBHcm91cCwgUy4gS2VudCwgUi4gQXRraW5zb24sICJTZWN1cml0eSBBcmNoaXRlYy0K ICAgICB0dXJlIGZvciB0aGUgSW50ZXJuZXQgUHJvdG9jb2wiLCBSRkMgMjQwMSwgTm92ZW1i ZXIgMTk5OAoKWzNdICBUaGUgSVBzZWMgV29ya2luZyBHcm91cCwgRC4gSGFya2lucywgRC4g Q2FycmVsLCAiVGhlIEludGVybmV0IEtleQogICAgIEV4Y2hhbmdlIiwgUkZDIDI0MDksIE5v dmVtYmVyIDE5OTgKCkF1dGhvcidzIEFkZHJlc3MKCiAgICAgICAgICBNaWNoYWVsIFRob21h cwogICAgICAgICAgQ2lzY28gU3lzdGVtcwogICAgICAgICAgMzc1IEUgVGFzbWFuIFJkCiAg ICAgICAgICBTYW4gSm9zZSwgQ2EsIDk1MTM0LCBVU0EKICAgICAgICAgIFRlbDogKzEgNDA4 LTUyNS01Mzg2CiAgICAgICAgICBFLU1BSUw6IG1hdEBjaXNjby5jb20KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKClRob21hcyAgICAgICAgICAgICAgICAgZHJhZnQtdGhvbWFzLWtpbmst cmVxbXQtMDAgICAgICAgICAgICAgICBbUGFnZSA2XQoKCg== --hUL/GSCR9M-- From owner-ietf-kink Wed Aug 9 12:59:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08775 for ietf-kink-bks; Wed, 9 Aug 2000 12:59:24 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08771 for ; Wed, 9 Aug 2000 12:59:23 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e79JwMn04550; Wed, 9 Aug 2000 15:58:22 -0400 (EDT) Message-Id: <200008091958.e79JwMn04550@ginger.cmf.nrl.navy.mil> To: Michael Thomas cc: ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft In-reply-to: Your message of "Wed, 09 Aug 2000 11:21:41 PDT." <14737.41269.489166.117071@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, 09 Aug 2000 15:58:21 -0400 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >- The protocol must be able to be used for more than IPsec keying I seem to remember that the suggestion from the BOF was that this should be changed from a MUST to a MAY; does anyone else recall that? --Ken From owner-ietf-kink Wed Aug 9 13:19:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09133 for ietf-kink-bks; Wed, 9 Aug 2000 13:19:09 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.MIT.EDU [18.101.1.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09129 for ; Wed, 9 Aug 2000 13:19:08 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id QAA16668; Wed, 9 Aug 2000 16:18:00 -0400 To: Ken Hornstein Cc: Michael Thomas , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft References: <200008091958.e79JwMn04550@ginger.cmf.nrl.navy.mil> From: Derek Atkins Date: 09 Aug 2000 16:18:00 -0400 In-Reply-To: Ken Hornstein's message of "Wed, 09 Aug 2000 15:58:21 -0400" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Indeed, this seemed to be the consensus of the group for rev1 of the protocol. -derek Ken Hornstein writes: > >- The protocol must be able to be used for more than IPsec keying > > I seem to remember that the suggestion from the BOF was that this should > be changed from a MUST to a MAY; does anyone else recall that? > > --Ken -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Wed Aug 9 13:27:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09313 for ietf-kink-bks; Wed, 9 Aug 2000 13:27:57 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09308 for ; Wed, 9 Aug 2000 13:27:56 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29370; Wed, 9 Aug 2000 13:26:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19954; Wed, 9 Aug 2000 13:26:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14737.48756.558494.786127@thomasm-u1.cisco.com> Date: Wed, 9 Aug 2000 13:26:28 -0700 (PDT) To: Derek Atkins Cc: Ken Hornstein , Michael Thomas , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft In-Reply-To: References: <200008091958.e79JwMn04550@ginger.cmf.nrl.navy.mil> 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: Derek Atkins writes: > Indeed, this seemed to be the consensus of the group for rev1 of > the protocol. That's my recollection as well -- I didn't change any of the requirements based on the BOF itself. Were there any others? On this particular item, I think that there should be a must here, which is to say that there needs to be some extension mechanism, but phrased in such a way that it doesn't imply that we're biting off more than IPsec. How about: "the protocol must be able to be extended in the future." Mike From owner-ietf-kink Wed Aug 9 13:46:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09580 for ietf-kink-bks; Wed, 9 Aug 2000 13:46:12 -0700 (PDT) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09576 for ; Wed, 9 Aug 2000 13:46:10 -0700 (PDT) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JSRO3SMZKKDY0EA2@GI.COM> for ietf-kink@vpnc.org; Wed, 9 Aug 2000 13:44:44 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 09 Aug 2000 13:45:37 -0400 Content-return: allowed Date: Wed, 09 Aug 2000 16:46:27 -0400 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK requirements draft To: "'Michael Thomas'" , Derek Atkins Cc: Ken Hornstein , ietf-kink@vpnc.org, mshore@cisco.com Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4616@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Mike. If we don't provide for the extension mechanism, it would be very difficult in the future to use this protocol for anything other than IPSec. Adding an extension mechanism does not appear to be a huge task. Sasha. > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Wednesday, August 09, 2000 1:26 PM > To: Derek Atkins > Cc: Ken Hornstein; Michael Thomas; ietf-kink@vpnc.org; mshore@cisco.com > Subject: Re: KINK requirements draft > > Derek Atkins writes: > > Indeed, this seemed to be the consensus of the group for rev1 of > > the protocol. > > That's my recollection as well -- I didn't change any > of the requirements based on the BOF itself. Were there > any others? > > On this particular item, I think that there should be > a must here, which is to say that there needs to be > some extension mechanism, but phrased in such a way > that it doesn't imply that we're biting off more than > IPsec. How about: > > "the protocol must be able to be extended in > the future." > > Mike From owner-ietf-kink Wed Aug 9 13:49:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09638 for ietf-kink-bks; Wed, 9 Aug 2000 13:49:45 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09634 for ; Wed, 9 Aug 2000 13:49:44 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e79Kmxn05168 for ; Wed, 9 Aug 2000 16:48:59 -0400 (EDT) Message-Id: <200008092048.e79Kmxn05168@ginger.cmf.nrl.navy.mil> To: ietf-kink@vpnc.org Subject: Re: KINK requirements draft In-reply-to: Your message of "Wed, 09 Aug 2000 13:26:28 PDT." <14737.48756.558494.786127@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, 09 Aug 2000 16:48:58 -0400 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Derek Atkins writes: > > Indeed, this seemed to be the consensus of the group for rev1 of > > the protocol. > > That's my recollection as well -- I didn't change any > of the requirements based on the BOF itself. Were there > any others? > > On this particular item, I think that there should be > a must here, which is to say that there needs to be > some extension mechanism, but phrased in such a way > that it doesn't imply that we're biting off more than > IPsec. How about: > > "the protocol must be able to be extended in > the future." I just remember Jeff Schiller standing up and saying, "Options are bad for security protocols". I think that the consensus of the room was with him, and I think a MUST is a little strong for this; SHOULD might be the right thing. "SHOULD be able to extend in the future" is fine, IMHO, but I don't feel very strongly about this. --Ken From owner-ietf-kink Wed Aug 9 13:58:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09775 for ietf-kink-bks; Wed, 9 Aug 2000 13:58:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09771 for ; Wed, 9 Aug 2000 13:58:03 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22480; Wed, 9 Aug 2000 14:57:04 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA11313; Wed, 9 Aug 2000 16:55:05 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79Ksfk101092; Wed, 9 Aug 2000 16:54:41 -0400 (EDT) Message-Id: <200008092054.e79Ksfk101092@thunk.east.sun.com> From: Bill Sommerfeld To: "Medvinsky, Sasha (SD-EX)" cc: "'Michael Thomas'" , Derek Atkins , Ken Hornstein , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft In-reply-to: Your message of "Wed, 09 Aug 2000 16:46:27 EDT." <97DEDE66B3DCD11199D200805FA71BE202FD4616@ntas0027.gi.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Aug 2000 16:54:40 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: historically, working groups with open-ended scopes tend to have a lot harder time producing something of value. i'd rather leave references to key mgmt for non-ipsec protocols out of the charter entirely, but if we have to leave it in, make it a MAY, not a MUST. - Bill From owner-ietf-kink Wed Aug 9 14:50:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10727 for ietf-kink-bks; Wed, 9 Aug 2000 14:50:29 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10723 for ; Wed, 9 Aug 2000 14:50:28 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA11337; Wed, 9 Aug 2000 14:49:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19958; Wed, 9 Aug 2000 14:49:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14737.53723.419591.152677@thomasm-u1.cisco.com> Date: Wed, 9 Aug 2000 14:49:15 -0700 (PDT) To: Ken Hornstein Cc: ietf-kink@vpnc.org Subject: Re: KINK requirements draft In-Reply-To: <200008092048.e79Kmxn05168@ginger.cmf.nrl.navy.mil> References: <14737.48756.558494.786127@thomasm-u1.cisco.com> <200008092048.e79Kmxn05168@ginger.cmf.nrl.navy.mil> 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: Ken Hornstein writes: > I just remember Jeff Schiller standing up and saying, "Options are bad > for security protocols". I think that the consensus of the room was > with him, and I think a MUST is a little strong for this; SHOULD might > be the right thing. "SHOULD be able to extend in the future" is fine, > IMHO, but I don't feel very strongly about this. >From the protocol standpoint, I'd be happy with a top level protocol/DOI variable in the message header and just leave it at that. We've done some thrashing around on the previous list about trying to come up with generic payloads that any old protocol would need to use, etc, etc, and it's my personal opinion that it would be better to not lose too much sleep on that front and instead focus on getting our current task done. I'm firmly a middle out kind of designer in the first place so the hedge-focus-generalize is much more natural to me anyway... Mike From owner-ietf-kink Wed Aug 9 15:06:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA11140 for ietf-kink-bks; Wed, 9 Aug 2000 15:06:35 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11134 for ; Wed, 9 Aug 2000 15:06:33 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA07725; Wed, 9 Aug 2000 18:05:37 -0400 (EDT) Message-Id: <200008092205.SAA07725@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Medvinsky, Sasha (SD-EX)" cc: "'Michael Thomas'" , Derek Atkins , Ken Hornstein , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft In-reply-to: Your message of "Wed, 09 Aug 2000 16:46:27 EDT." <97DEDE66B3DCD11199D200805FA71BE202FD4616@ntas0027.gi.com> Date: Wed, 09 Aug 2000 18:05:37 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I suggest we not use MUST or SHOULD (or even the word "requirements") when writing "requirements". Or at least, we should use them sparingly, reserving them only for absolute requirements as opposed to design goals or merely desirable features. the MUST/SHOULD/MAY terminology was coined for use in protocol specifications which need to define conformance in a fairly concrete way. at the stage where a group is just trying to define the problem and its scope, such terms don't seem appropriate. in particular, we want to avoid insisting on features being in the protocol (resulting in protocol bloat) just because we wrote a MUST or SHOULD in a document when we didn't really understand what we were saying anyway. Keith From owner-ietf-kink Wed Aug 9 15:34:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA11919 for ietf-kink-bks; Wed, 9 Aug 2000 15:34:13 -0700 (PDT) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11915 for ; Wed, 9 Aug 2000 15:34:12 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA00499; Wed, 9 Aug 2000 15:33:28 -0700 (PDT) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Aug 2000 22:33:27 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 15:33:25 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE98FC@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: ietf-krb-wg@anl.gov Cc: ietf-kink@vpnc.org Subject: draft-ietf-iakerb-xx.txt discussion Date: Wed, 9 Aug 2000 15:33:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This mail has been copied the KINK mailing list, as the discussion seems germane to their endeavor. The standard way people seem to be thinking about deploying Kerberos in conjunction with 802.1X style networks and remote access IPsec is covered by draft-ietf-iakerb-xx.txt. In this model the connecting client assumes the role of the Kerberos client, and the "attachment point" (be it a VPN Gateway, 802.1 switch, whatever) or server occupies a dual role, first of a proxy as described in the draft, and then as the Kerberos server. The server proxies client ticket requests to the KDC, and then proxies any response back to the client. The client uses the proxied ticket to authenticate with the server sitting between it and the KDC. I am wondering whether there is an opportunity to do something else, something that on first blush appears a modest improvement, at least to me. The existing proxy model appears to have several features that render it somewhat less desirable than we might otherwise wish it to be. First, to be used in many of the environments people will want to use the protocol (e.g., remote access IPsec, authentication to a wired infrastructure over wireless LANs, etc.), the client will be "outside" the firewall and therefore completely untrusted. While assuming an untrusted client is standard, and while Kerberos was designed for this kind of environment, experience shows that many organizations have had trouble properly deploying Kerberos (their KDCs get hacked), and even more bitter experience shows they are therefore unwilling to expose their KDCs to messages from clients situated beyond their firewalls, because "the ones inside can be trusted and the ones outside the firewall can't be" (yeah, right). You can call this a deployment error (it is) and ignorance (it's that, too), but it is also market reality, because most people managing networks are not trained security professionals and never will be. It is certainly feasible that the proxy can protect the KDC (e.g., rate limiting messages, filter buffer overrun attacks, and the like), but I expect many organizations will still be loath to use such a system based on their experiences; implementors, after all, have a dubious track record at best of getting the security properties of proxies right the first or second or even third time around. Another problem is the client needs to know too much. It needs to know the identity of the server to format its ticket request, and this spells configuration, or at least the wrong kind. Configuration on clients is almost always a deployment barrier, and always a scaling issue. The draft attempts to address the problem by allowing the proxy (aka server) to fill in the realm name, but from my (perhaps warped) way of thinking, this is not quite right. It seems more likely to me that people will want to configure their remote access clients with the realm name, and connect to any attachment point that offers realm services, without regard to the identities of the servers providing that service. And the push toward greater mobility seems to indicate that clients are likely to belong to several realms, meaning they will possess credentials from multiple realms (with differing principal names), meaning they won't be able to identify themselves properly until they know what realm they are trying to enter. The realm is something that has to be configured on the client, because it will serve as the locator for the client's own proper principal name. Configuration is bad, but some kinds of configuration can't be avoided. A third problem is the proxy doesn't seem to be able to know the messages from the KDC it proxies back to the client are indeed live, because it doesn't contribute to the nonce, and it can't inspect the nonce in the KDC's response to the client. This seems to make the protocol susceptible to collusion between an insider and an outsider. A final potential problem to any network engineer is "unnecessary" messages. The proxy (i.e., server) has all it needs to initiate Kerberos-based mutual authentication with the client, but instead it is still in proxy mode, "squandering" the opportunity to optimize at least one message away. All of this makes me wonder whether it might be advantageous to alter the responsibilities of both the proxy and the client somewhat, effectively interchanging their roles. The client wanting to mutually authenticate would forward its identity to the proxy. The proxy would request from the KDC a ticket from its own host to the requesting client. Once it received the ticket, the proxy could use the ticket to initiate the authentication protocol with the client. This design seems to address all of the questions I raised above. It addresses the first issues, because the proxy/servers themselves (presumed to be under the organization's control) generate ticket requests, not the "untrusted" clients. It addresses the second problem in that client's don't have to care about the name of the attachment point, since the returned ticket and authenticator supply this. It addresses the third problem, because the proxy/server supplies the nonce (but that exposes the client to replay; see the discussion below). And it addresses the last issue, as it removes at least one message from the entire exchange. As noted above, the biggest problem I can see with this type of approach (aside from the disadvantage it is not what people are doing) seems to be the real remote access client needs to protect itself from replay attack by a rogue proxy/server; this is what its nonce in the ticket request does, after all. One way to address this might be to require the client to supply a nonce with its identity, and for the proxy/server to concatentate its own nonce at the end of the client's to insert into its ticket request. We would need some sort of convention to transfer the nonce back into, e.g., the server's authenticator to the client. I haven't worked out the details, only speculated that this might be a fruitful approach. I don't know if the above analysis of the current draft holds water, or whether the germ of an idea presented here actually represents an improvement on the draft, or is good idea, or even works. What do other people think? Jesse Walker Intel Corporation JF3-448 2111 N.E. 25th Avenue Hillsboro, OR 97124 (503) 712-1849 From owner-ietf-kink Thu Aug 10 13:42:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13650 for ietf-kink-bks; Thu, 10 Aug 2000 13:42:27 -0700 (PDT) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13646 for ; Thu, 10 Aug 2000 13:42:25 -0700 (PDT) Received: by snark.piermont.com (Postfix, from userid 1000) id 291031E0054; Thu, 10 Aug 2000 16:41:41 -0400 (EDT) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , Derek Atkins , Ken Hornstein , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft References: <97DEDE66B3DCD11199D200805FA71BE202FD4616@ntas0027.gi.com> From: "Perry E. Metzger" Date: 10 Aug 2000 16:41:41 -0400 In-Reply-To: "Medvinsky, Sasha's message of "Wed, 09 Aug 2000 16:46:27 -0400" Message-ID: <87em3w3l2y.fsf@snark.piermont.com> Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.6 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > I agree with Mike. If we don't provide for the extension mechanism, it > would be very difficult in the future to use this protocol for anything > other than IPSec. I think explicit group consensus was "it is fine if it can't be used for anything else." We bit off more than we could chew trying to make ISAKMP/IKE totally extensible and flexible. .pm From owner-ietf-kink Thu Aug 10 14:04:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14518 for ietf-kink-bks; Thu, 10 Aug 2000 14:04:18 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14511 for ; Thu, 10 Aug 2000 14:04:17 -0700 (PDT) Received: from localhost (ssh.cisco.com [171.69.10.34]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA08797; Thu, 10 Aug 2000 14:02:22 -0700 (PDT) Date: Thu, 10 Aug 2000 14:02:18 -0700 (PDT) From: Jan Vilhuber To: "Perry E. Metzger" cc: "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , Derek Atkins , Ken Hornstein , ietf-kink@vpnc.org, mshore@cisco.com Subject: Re: KINK requirements draft In-Reply-To: <87em3w3l2y.fsf@snark.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't think adding a DOI field somewhere is espeically onerous, nor complex. A few bytes in the interest of extensibility makes a lot of common sense to me, and doesn't burden the group with having to actually define other mechanisms, but allows for other people to USE other mechanisms. I've had secure multicast already asking me about this, so I KNOW there's interest for them to use it. It seems a bit short-sighted (and an overreaction) to slam the door on ANY kind of extensibility... I believe a DOI field makes sense, as does a private range (and vencod-id as in IKE), which allows people to experiment with new stuff. Neither of those place a huge burden on actually defining all lthey will ever be used for. If you make it too static and unchangeable, we'll just be here in a nother 6 months to try to come up with essentially the same thing for secure multicast. jan On 10 Aug 2000, Perry E. Metzger wrote: > > "Medvinsky, Sasha (SD-EX)" writes: > > I agree with Mike. If we don't provide for the extension mechanism, it > > would be very difficult in the future to use this protocol for anything > > other than IPSec. > > I think explicit group consensus was "it is fine if it can't be used > for anything else." > > We bit off more than we could chew trying to make ISAKMP/IKE totally > extensible and flexible. > > .pm > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Thu Aug 10 14:36:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15740 for ietf-kink-bks; Thu, 10 Aug 2000 14:36:48 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15735 for ; Thu, 10 Aug 2000 14:36:46 -0700 (PDT) Received: from localhost (ssh.cisco.com [171.69.10.34]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA11118; Thu, 10 Aug 2000 14:35:36 -0700 (PDT) Date: Thu, 10 Aug 2000 14:35:36 -0700 (PDT) From: Jan Vilhuber To: "Perry E. Metzger" cc: ietf-kink@vpnc.org Subject: Re: KINK requirements draft In-Reply-To: <87lmy4zuh3.fsf@snark.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 10 Aug 2000, Perry E. Metzger wrote: > > Jan Vilhuber writes: > > I don't think adding a DOI field somewhere is espeically onerous, nor > > complex. > > Adding an integer is fine. Modifying the design to be all-singing, > all-dancing is the issue. I think that, philosophically, we should be > biased towards simplicity. If we can do something trivial to make it > possible to use elsewhere, fine. If we spend time and effort on it, it > is a bad idea. > Agreed. I just don't want to see us go too far in the opposite direction and make a completely defined, no degrees of freedom, custom purpose protocol. I'm not proposing we spend a huge amount of time on it, but can we call for a consensus on putting in the DOI and possibly vendor-id with private ranges? I believe that's all that's needed for people to experiment (which we want to encourage) and for other protocols other than ipsec to leverage what we do here? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Thu Aug 10 15:04:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16704 for ietf-kink-bks; Thu, 10 Aug 2000 15:04:56 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16700 for ; Thu, 10 Aug 2000 15:04:54 -0700 (PDT) Received: from localhost (ssh.cisco.com [171.69.10.34]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA12598; Thu, 10 Aug 2000 15:03:43 -0700 (PDT) Date: Thu, 10 Aug 2000 15:03:43 -0700 (PDT) From: Jan Vilhuber To: "Perry E. Metzger" cc: ietf-kink@vpnc.org Subject: Re: KINK requirements draft In-Reply-To: <87snscx0bf.fsf@snark.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 10 Aug 2000, Perry E. Metzger wrote: > > Jan Vilhuber writes: > > Agreed. I just don't want to see us go too far in the opposite direction and > > make a completely defined, no degrees of freedom, custom purpose protocol. > > > > I'm not proposing we spend a huge amount of time on it, but can we call for a > > consensus on putting in the DOI and possibly vendor-id with private > > ranges? > > I think we shold wait on that until we've seen the protocol and know > where they'd go. It is premature -- the draft isn't out yet. > Good point. Thanks for the reminder. I'm supposed to throw out what we have so far ;) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Wed Aug 16 04:18:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA12214 for ietf-kink-bks; Wed, 16 Aug 2000 04:18:00 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12207 for ; Wed, 16 Aug 2000 04:17:59 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id HAA28121; Wed, 16 Aug 2000 07:17:46 -0400 (EDT) To: "Walker, Jesse" Cc: ietf-krb-wg@anl.gov, ietf-kink@vpnc.org Subject: Re: draft-ietf-iakerb-xx.txt discussion References: <392A357CE6FFD111AC3E00A0C99848B002FE98FC@hdsmsx31.hd.intel.com> Mime-Version: 1.0 From: Ken Raeburn Date: 16 Aug 2000 07:17:45 -0400 In-Reply-To: "Walker, Jesse"'s message of "Wed, 9 Aug 2000 15:33:22 -0700" Message-ID: Lines: 24 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Walker, Jesse" writes: > All of this makes me wonder whether it might be advantageous to alter the > responsibilities of both the proxy and the client somewhat, effectively > interchanging their roles. The client wanting to mutually authenticate would > forward its identity to the proxy. The proxy would request from the KDC a > ticket from its own host to the requesting client. Once it received the > ticket, the proxy could use the ticket to initiate the authentication > protocol with the client. If the client's key is derived from a password, interception of the message from the proxy to the client can lead to a dictionary attack opening against the client, because it has to be encrypted in the that key. Plain Kerberos doesn't prevent such an attack either when getting the initial TGT, but preauthentication methods can be designed to do so, and they only work when getting the initial TGT. Using the "user to user" mode is more secure when the "server" may be a user with a relatively weak password-based key instead of a service with a stronger random binary key. We shouldn't design protocols that shut out such measures, if we can avoid it. I think the extra protection is worth the extra traffic. Ken From owner-ietf-kink Mon Aug 28 14:01:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28411 for ietf-kink-bks; Mon, 28 Aug 2000 14:01:48 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28407 for ; Mon, 28 Aug 2000 14:01:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA28327 for ; Mon, 28 Aug 2000 14:02:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA25374; Mon, 28 Aug 2000 14:02:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14762.54098.196051.956838@thomasm-u1.cisco.com> Date: Mon, 28 Aug 2000 14:02:10 -0700 (PDT) To: ietf-kink@vpnc.org Subject: PK realm naming 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: One of the requirements is that a KINK initiator does not need to know how the remote peer authenticated to the KDC. This isn't a problem except for the case where you have a cross realm peer who authenticated using PKInit. It would clearly be suboptimal to have the initiator try to get a service ticket only to have that fail at the KDC followed by a User-User exchange. Much better would be that the initator know ahead of time whether a given realm is a PK realm so that it can know whether to launch a 4 message U-U exchange instead of 2 message client-server exchange. So the question I have is is there a way to know ahead of time whether a remote realm is a PK realm? If not, could we invent a way and still be within the bounds of rfc1510bis? Mike PS: we will have the first cut of a draft out very soon From owner-ietf-kink Mon Sep 18 17:00:06 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA29132 for ietf-kink-bks; Mon, 18 Sep 2000 17:00:06 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29127 for ; Mon, 18 Sep 2000 17:00:04 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA26218 for ; Mon, 18 Sep 2000 17:02:14 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA01837; Mon, 18 Sep 2000 17:02:14 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bS/BD/5559" Content-Transfer-Encoding: 7bit Message-ID: <14790.44293.570062.666313@thomasm-u1.cisco.com> Date: Mon, 18 Sep 2000 17:02:13 -0700 (PDT) To: ietf-kink@vpnc.org Subject: latest requirements draft 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: --bS/BD/5559 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I've submitted the requirements draft again as: draft-thomas-kink-reqmt-00.txt I don't believe that it is substantially different than the initial charter document and the first set of requirements I sent to this list. This is supposed to be done by end of September, assumedly for last call as an informational RFC or somesuch. Derek -- should this be changed to draft-kink-kink-reqmt since the WG has officially been formed? Mike --bS/BD/5559 Content-Type: application/octet-stream Content-Disposition: attachment; filename="draft-thomas-kink-reqmt-00.txt" Content-Transfer-Encoding: base64 CgoKCgoKSU5URVJORVQtRFJBRlQgICAgICBLSU5LIFJlcXVpcmVtZW50cyAgICAgTWljaGFl bCBUaG9tYXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB dWd1c3QgOSwgMjAwMAoKCgoKCgogICAgICAgICAgICAgICAgS2VyYmVyaXplZCBJbnRlcm5l dCBOZWdvdGlhdGlvbiBvZiBLZXlzCgogICAgICAgICAgICAgICAgICAgICBkcmFmdC10aG9t YXMta2luay1yZXFtdC0wMC50eHQKCgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBk b2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5j ZSB3aXRoCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZwogICBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsCiAgIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAg IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4KCkFic3RyYWN0 CgogICBUaGUgS0lOSyB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBjcmVhdGUgYSBz dGFuZGFyZHMgdHJhY2sKICAgcHJvdG9jb2wgdG8gZmFjaWxpdGF0ZSBjZW50cmFsaXplZCBr ZXkgbWFuYWdlbWVudCBmb3IgSVBzZWMgc2VjdXJpdHkKICAgYXNzb2NpYXRpb25zIGFzIGRl ZmluZWQgaW4gUkZDIDI0MDEsIGFzIGFuIGFsdGVybmF0aXZlIHRvIElLRSAoUkZDCiAgIDI0 MDkpLiAgUGFydGljaXBhdGluZyBzeXN0ZW1zIHdpbGwgdXNlIHRoZSBLZXJiZXJvcyBhcmNo aXRlY3R1cmUgYXMKICAgZGVmaW5lZCBpbiBSRkMgMTUxMCAoYW5kIGl0cyBzdWNjZXNzb3Jz KSBmb3Iga2V5IG1hbmFnZW1lbnQuIFRoZSBnb2FsCiAgIG9mIHRoZSB3b3JraW5nIGdyb3Vw IGlzIHRvIHByb2R1Y2UgYSBzdHJlYW1saW5lZCwgZmFzdCwgZWFzaWx5CiAgIG1hbmFnZWQs IGFuZCBjcnlwdG9ncmFwaGljYWxseSBzb3VuZCBwcm90b2NvbCB3aXRob3V0IHJlcXVpcmlu ZwogICBwdWJsaWMga2V5LgoKICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgcmVxdWly ZSBjaGFuZ2VzIHRvIGVpdGhlciBJUHNlYyAoUkZDCiAgIDI0MDEpLCBvciBLZXJiZXJvcyAo UkZDIDE1MTApLgoKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFmdC10aG9tYXMta2lu ay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDFdCgoKCgoKSU5URVJORVQtRFJBRlQg IEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAgICA5IEF1Z3VzdCAy MDAwCgoKTW90aXZhdGlvbgoKICAgVGhlIElQc2VjIHdvcmtpbmcgZ3JvdXAgaGFzIGRlZmlu ZWQgYSBudW1iZXIgb2YgcHJvdG9jb2xzIHdoaWNoCiAgIHByb3ZpZGUgdGhlIGFiaWxpdHkg dG8gY3JlYXRlIGFuZCBtYWludGFpbiBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUKICAgc2Vj dXJpdHkgYXNzb2NpYXRpb25zIGF0IGxheWVyIHRocmVlIChpZSwgdGhlIElQIGxheWVyKS4g IFRoaXMgZWZmb3J0CiAgIGhhcyBwcm9kdWNlZCB0d28gZGlzdGluY3QgcHJvdG9jb2xzOgoK ICAgMSkgYSBtZWNoYW5pc20gdG8gZW5jcnlwdCBhbmQgYXV0aGVudGljYXRlIElQIGRhdGFn cmFtIHBheWxvYWRzIHdoaWNoCiAgICAgIGFzc3VtZXMgYSBzaGFyZWQgc2VjcmV0IGJldHdl ZW4gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIKCiAgIDIpIGEgbWVjaGFuaXNtIGZvciBJUHNl YyBwZWVycyB0byBwZXJmb3JtIG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgZXhj aGFuZ2Uga2V5aW5nIG1hdGVyaWFsCgogICBUaGUgSVBzZWMgd29ya2luZyBncm91cCBoYXMg ZGVmaW5lZCBhIHBlZXIgdG8gcGVlciBhdXRoZW50aWNhdGlvbiBhbmQKICAga2V5aW5nIG1l Y2hhbmlzbSwgSUtFIChSRkMgMjQwOSkuIE9uZSBvZiB0aGUgZHJhd2JhY2tzIG9mIGEgcGVl ciB0bwogICBwZWVyIHByb3RvY29sIGlzIHRoYXQgZWFjaCBwZWVyIG11c3Qga25vdyBhbmQg aW1wbGVtZW50IGEgc2l0ZSdzCiAgIHNlY3VyaXR5IHBvbGljeSB3aGljaCBpbiBwcmFjdGlj ZSBjYW4gYmUgcXVpdGUgY29tcGxleC4gSW4gYWRkaXRpb24sCiAgIHRoZSBsYWNrIG9mIGEg dHJ1c3RlZCB0aGlyZCBwYXJ0eSByZXF1aXJlcyB0aGUgdXNlIG9mIERpZmZpZSBIZWxsbWFu CiAgIChESCkgdG8gZXN0YWJsaXNoIGEgc2hhcmVkIHNlY3JldC4gREgsIHVuZm9ydHVuYXRl bHksIGlzIGNvbXB1dGF0aW9uLQogICBhbGx5IHF1aXRlIGV4cGVuc2l2ZSBhbmQgcHJvbmUg dG8gZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcy4gSUtFIGFsc28KICAgcmVsaWVzIG9uIFgu NTA5IGNlcnRpZmljYXRlcyB0byByZWFsaXplIHNjYWxhYmxlIGF1dGhlbnRpY2F0aW9uIG9m CiAgIHBlZXJzLiBEaWdpdGFsIHNpZ25hdHVyZXMgYXJlIGFsc28gY29tcHV0YXRpb25hbGx5 IGV4cGVuc2l2ZSBhbmQgY2VyLQogICB0aWZpY2F0ZSBiYXNlZCB0cnVzdCBtb2RlbHMgYXJl IGRpZmZpY3VsdCB0byBkZXBsb3kgaW4gcHJhY3RpY2UuCiAgIFdoaWxlIElLRSBkb2VzIGFs bG93IGZvciBwcmUtc2hhcmVkIHN5bW1ldHJpYyBrZXlzLCBrZXkgZGlzdHJpYnV0aW9uCiAg IGlzIHJlcXVpcmVkIGJldHdlZW4gYWxsIHBlZXJzIC0tIGFuIE8obl4yKSBwcm9ibGVtIC0t IHdoaWNoIGlzIHByb2ItCiAgIGxlbWF0aWMgZm9yIGxhcmdlIGRlcGxveW1lbnRzLgoKICAg S2VyYmVyb3MgKFJGQyAxNTEwKSBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgdHJ1c3RlZCB0 aGlyZCBwYXJ0eQogICBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50cyBhbmQgc2VydmVycy4g Q2xpZW50cyBhdXRoZW50aWNhdGUgdG8gYQogICBjZW50cmFsaXplZCBzZXJ2ZXIgLS0gdGhl IEtleSBEaXN0cmlidXRpb24gQ2VudGVyIC0tIHdoaWNoIGluIHR1cm4KICAgaXNzdWVzIHRp Y2tldHMgdGhhdCBzZXJ2ZXJzIGNhbiBkZWNyeXB0IHRodXMgcHJvdmluZyB0aGF0IHRoZSBj bGllbnQKICAgaXMgd2hvIGl0IGNsYWltcyB0byBiZS4gT25lIG9mIHRoZSBlbGVtZW50cyBv ZiBhIEtlcmJlcm9zIHRpY2tldCBpcyBhCiAgIHNlc3Npb24ga2V5IHdoaWNoIGlzIGdlbmVy YXRlZCBieSB0aGUgS0RDIHdoaWNoIG1heSBiZSB1c2VkIGJ5IHRoZQogICBjbGllbnQgYW5k IHNlcnZlciB0byBzaGFyZSBhIHNlY3JldC4gS2VyYmVyb3MgYWxzbyBhbGxvd3MgZm9yIGJv dGgKICAgc3ltbWV0cmljIGtleSBhdXRoZW50aWNhdGlvbiwgYXMgd2VsbCBhcyBjZXJ0aWZp Y2F0ZSBiYXNlZCBwdWJsaWMga2V5CiAgIGF1dGhlbnRpY2F0aW9uIChQS2luaXQpLiBTaW5j ZSB0aGUgYXV0aGVudGljYXRpb24gcGhhc2Ugb2YgS2VyYmVyb3MKICAgaXMgcGVyZm9ybWVk IGJ5IHRoZSBLREMsIHRoZXJlIGlzIG5vIG5lZWQgdG8gcGVyZm9ybSBleHBlbnNpdmUgREgg b3IKICAgWC41MDkgY2VydGlmaWNhdGUgc2lnbmF0dXJlcy92ZXJpZmljYXRpb24gb3BlcmF0 aW9ucyBvbiBzZXJ2ZXJzLgogICBXaGlsZSBjbGllbnRzIG1heSBhdXRoZW50aWNhdGUgdXNp bmcgWC41MDkgY2VydGlmaWNhdGVzLCB0aGUgYXV0aGVuLQogICB0aWNhdGlvbiBwaGFzZSBj YW4gYmUgYW1vcnRpemVkIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjcmVkZW50aWFscy4K ICAgVGhpcyBhbGxvd3MgYSBzaW5nbGUgREggYW5kIGNlcnRpZmljYXRlIGV4Y2hhbmdlIHRv IGJlIHVzZWQgdG8ga2V5CiAgIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB3aXRoIG1hbnkgc2Vy dmVycyBpbiBhIGNvbXB1dGF0aW9uYWxseSBlY29ub21pYwogICB3YXkuIEtlcmJlcm9zIGFs c28gc3VwcG9ydCBjbGllbnRzIHdpdGggc3ltbWV0cmljIGtleXMgYnV0IHVubGlrZQogICBJ S0UsIHRoZSBzeW1tZXRyaWMga2V5cyBhcmUgc3RvcmVkIGluIHRoZSBLREMgbWFraW5nIHRo ZSBudW1iZXIgb2YKICAga2V5cyBhbiBPKG4pIHByb2JsZW0gcmF0aGVyIHRoYW4gTyhuXjIp LiAgS2VyYmVyb3MgYWxzbyBhbGxvd3Mgc2VjdS0KICAgcml0eSBwb2xpY3kgdG8gYmUgbWFu YWdlZCBpbiBhIG1vcmUgY2VudHJhbGl6ZWQgZmFzaGlvbiwgcmF0aGVyIHRoYW4KICAgZXhw ZWN0aW5nIGVhY2ggcG90ZW50aWFsbHkgdW50cnVzdHdvcnRoeSBwZWVyIHRvIGFiaWRlIGJ5 IHN0YXRlZAogICBzZWN1cml0eSBwb2xpY2llcyBvZiBhbiBvcmdhbml6YXRpb24uCgoKClRo b21hcyAgICAgICAgICAgICAgICAgZHJhZnQtdGhvbWFzLWtpbmstcmVxbXQtMDAgICAgICAg ICAgICAgICBbUGFnZSAyXQoKCgoKCklOVEVSTkVULURSQUZUICBLZXJiZXJpemVkIEludGVy bmV0IE5lZ290aWF0aW9uIG9mIEtleXMgICAgOSBBdWd1c3QgMjAwMAoKCiAgIFRoZSBLSU5L IHdvcmtpbmcgZ3JvdXAgdGFrZXMgdGhlc2UgYmFzaWMgZmVhdHVyZXMgb2YgS2VyYmVyb3Mg YW5kCiAgIHVzZXMgdGhlbSB0byBpdHMgYWR2YW50YWdlIHRvIGNyZWF0ZSBhIHByb3RvY29s IHdoaWNoIGNhbiBlc3RhYmxpc2gKICAgYW5kIG1haW50YWluIElQc2VjIHNlY3VyaXR5IGFz c29jaWF0aW9ucyAoUkZDIDI0MDEpLiAgSXQgc2hvdWxkIGJlCiAgIG5vdGVkIHRoYXQgS0lO SyBpcyBub3QgYSByZXBsYWNlbWVudCBmb3IgSUtFLiAgSUtFIGhhcyBvbmUgcHJvcGVydHkK ICAgd2hpY2ggS0lOSyBjYW5ub3QgcmVwcm9kdWNlOiAgdGhlIGFiaWxpdHkgZm9yIHR3byBw ZWVycyB0byBtdXR1YWxseQogICBhdXRoZW50aWNhdGUgYW5kIGV4Y2hhbmdlIGtleXMgd2l0 aG91dCB0aGUgbmVlZCBmb3IgYW4gYWN0aXZlbHkgcGFyLQogICB0aWNpcGF0aW5nIHRoaXJk IHBhcnR5LiBIb3dldmVyLCB0aGVyZSBhcmUgbWFueSBzaXR1YXRpb25zIHdoZXJlIGEKICAg dHJ1c3RlZCB0aGlyZCBwYXJ0eSB3aGljaCBwcm94aWVzIGF1dGhlbnRpY2F0aW9uIGlzIHZp YWJsZSwgYW5kIGluCiAgIGZhY3QgZGVzaXJhYmxlLgoKICAgV2hpbGUgS2VyYmVyb3Mgc3Bl Y2lmaWVzIGEgc3RhbmRhcmQgcHJvdG9jb2wgYmV0d2VlbiB0aGUgY2xpZW50IGFuZAogICB0 aGUgS0RDIHRvIGdldCB0aWNrZXRzLCB0aGUgYWN0dWFsIHRpY2tldCBleGNoYW5nZSBiZXR3 ZWVuIGNsaWVudCBhbmQKICAgc2VydmVyIGlzIGFwcGxpY2F0aW9uIHNwZWNpZmljLiAgS0lO SyBpcyBpbnRlbmRlZCB0byBiZSBhbiBhbHRlcm5hLQogICB0aXZlIHRvIHJlcXVpcmluZyBl YWNoIGFwcGxpY2F0aW9uIGhhdmluZyBpdHMgb3duIG1ldGhvZCBvZiB0cmFuLQogICBzcG9y dGluZyBhbmQgdmFsaWRhdGluZyBzZXJ2aWNlIHRpY2tldHMgdXNpbmcgYSBwcm90b2NvbCB3 aGljaCBpcwogICBlZmZpY2llbnQgYW5kIHRhaWxvcmVkIHRvIHRoZSBzcGVjaWZpYyBuZWVk cyBvZiBLZXJiZXJvcyBhbmQgdGhlCiAgIGFwcGxpY2F0aW9ucyBmb3Igd2hpY2ggaXQgcHJv dmlkZXMga2V5aW5nIGFuZCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24uCgogICBHaXZlbiB0aGUg YWJvdmUsIGEgbmV3IGdlbmVyYWwga2V5aW5nIHByb3RvY29sIHdoaWNoIGxldmVyYWdlcyB0 aGUKICAgc2NhbGFiaWxpdHkgb2YgS2VyYmVyb3MgaXMgZGVzaXJhYmxlLiAgVGhlIHdvcmtp bmcgZ3JvdXAncyBmaXJzdCB0YXNrCiAgIGlzIHRvIGRlZmluZSB0aGlzIHByb3RvY29sIGFu ZCBkZWZpbmUgYW4gZG9tYWluIG9mIGludGVycHJldGF0aW9uIGZvcgogICBJUHNlYyB0byBl c3RhYmxpc2ggYW5kIG1haW50YWluIElQc2VjIHNlY3VyaXR5IGFzc29jaWF0aW9ucy4gVGhl IHByby0KICAgdG9jb2wgbXVzdCBiZSBhYmxlIHRvIHRha2UgZnVsbCBhZHZhbnRhZ2Ugb2Yg dGhlIGZlYXR1cmVzIG9mIFJGQyAyNDAxCiAgIGJ1dCBpbiB0aGUgY29udGV4dCBvZiBhIGNl bnRyYWxpemVkIGtleWluZyBhdXRob3JpdHkuCgpSZXF1aXJlbWVudHMKCiAgIEtJTksgbXVz dCBtZWV0IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzIGF0IGEgbWluaW11bToKCi0gICAg VGhlIHByb3RvY29sIG11c3QgdXNlIEtlcmJlcm9zIHRvIGNyZWF0ZSBzZXNzaW9uIGtleXMg aW4gYSBzZWN1cmUKICAgICBmYXNoaW9uCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGFi bGUgdG8gaW50ZWdyYXRlIGludG8gc2VjdXJpdHkgYXJjaGl0ZWN0dXJlCiAgICAgb2YgSVBT ZWMgKFJGQyAyNDAxKQoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBiZSBhYmxlIHRvIHN0YXJ0 IHVwIFNBJ3MgcmVnYXJkbGVzcyBvZiBhbnkKICAgICBjbGllbnQvc2VydmVyIGRpc3Bvc2l0 aW9uIGluIHRoZSBrZXlpbmcgcHJvdG9jb2wKCi0gICAgS2VyYmVyb3MgbWFrZXMgYSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZlcnM7IElQc2VjCiAgICAgZG9lcyBu b3QuIFRoZSBwcm90b2NvbCBtdXN0IGFsbG93IGZvciBJUHNlYyBzZWN1cml0eSBhc3NvY2lh dGlvbnMKICAgICB0byBiZSBpbml0aWF0ZWQgYnkgYm90aCBzZXJ2ZXJzIGFuZCBjbGllbnRz LCB0aHVzIHByZXNlcnZpbmcKICAgICBJUHNlYydzIHBlZXIgdG8gcGVlciBuYXR1cmUuCgot ICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gaW5pdGlhbGx5IGF1dGhlbnRpY2F0 ZSB1c2luZyBlaXRoZXIKICAgICBzZWNyZXQga2V5LCBvciBwdWJsaWMga2V5IGF1dGhlbnRp Y2F0aW9uLgoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBhY2NvbW1vZGF0ZSBhbnkgY29tYmlu YXRpb24gb2YgcHVibGljIGFuZCBzZWNyZXQKICAgICBrZXkgcGVlcnMKCgoKVGhvbWFzICAg ICAgICAgICAgICAgICBkcmFmdC10aG9tYXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAg IFtQYWdlIDNdCgoKCgoKSU5URVJORVQtRFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVn b3RpYXRpb24gb2YgS2V5cyAgICA5IEF1Z3VzdCAyMDAwCgoKLSAgICBUaGUgcHJvdG9jb2wg bXVzdCBiZSBhYmxlIHRvIGFsbG93IGEgcGVlciB0byBhdXRoZW50aWNhdGUgYW5kIHBhci0K ICAgICB0aWNpcGF0ZSBpbiBtYW55IHJlYWxtcwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBo YW5kbGUgYWJzb2x1dGUgdGltZSBza2V3IGdyYWNlZnVsbHkKCi0gICAgVGhlIHByb3RvY29s IG11c3QgYmUgYWJsZSB0byBjcmVhdGUsIG1vZGlmeSwgcmVrZXksIGFuZCBkZWxldGUKICAg ICBzZWN1cml0eSBhc3NvY2lhdGlvbnMKCi0gICAgVGhlIHByb3RvY29sIG11c3QgYmUgY2Fw YWJsZSBvZiBzZXR0aW5nIHVwIGJvdGggdHJhbnNwb3J0IGFuZCB0dW4tCiAgICAgbmVsIG1v ZGVzIG9mIElQU2VjCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGNhcGFibGUgb2Ygc2V0 dGluZyB1cCBib3RoIEFIIGFuZCBFU1Agc2VjdXJpdHkKICAgICBhc3NvY2lhdGlvbnMKCi0g ICAgVGhlIHByb3RvY29sIG11c3QgYmUgY2FwYWJsZSBvZiBuZWdvdGlhdGluZyBjaXBoZXIg c3VpdGVzCgotICAgIFRoZSBwcm90b2NvbCBtdXN0IGJlIGNhcGFibGUgb2Ygc2V0dGluZyB1 cCBJUHNlYyBmbG93IHNlbGVjdG9ycwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBiZSBjYXBh YmxlIG9mIHJla2V5aW5nIHdpdGhvdXQgdGhlIGFzc2lzdGFuY2Ugb2YKICAgICB0aGUgS0RD IGlmIHRoZSBzZXNzaW9uIHRpY2tldCBpcyBzdGlsbCB2YWxpZAoKLSAgICBUaGUgcHJvdG9j b2wgbXVzdCBtYWtlIGFuIGVmZm9ydCB0byBtaXRpZ2F0ZSB0aGlyZCBwYXJ0eSBEZW5pYWwg b2YKICAgICBTZXJ2aWNlIGF0dGFja3MgKGFrYSBab21iaWVzIGF0dGFja3MpCgotICAgIFRo ZSBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gYmUgdXNlZCBmb3IgbW9yZSB0aGFuIElQc2Vj IGtleWluZwoKLSAgICBUaGUgcHJvdG9jb2wgbXVzdCBzdXBwb3J0IGJvdGggSVB2NCBhbmQg SVB2NgoKCkRlbGl2ZXJhYmxlcwoKICAgICBUaGUgd29ya2luZyBncm91cCdzIHJlc3BvbnNp YmlsaXRpZXMgYXJlIGFzIGZvbGxvd3M6CgotICAgIENvbXBsZXRlIGEgcHJvdG9jb2wgd2hp Y2ggbWVldHMgdGhlIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBhYm92ZQoKLSAgICBLZWVwIGFs bCBLSU5LIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIG1vdmluZyBhbG9uZyBwdWJsaWNhdGlv biAvCiAgICAgc3RhbmRhcmRpemF0aW9uIHRyYWNrLgogICBUaGUgbGlzdCBvZiB0aGUgd29y a2luZyBncm91cCdzIGN1cnJlbnQgd29yayBpdGVtcyBpcyBhcyBmb2xsb3dzOgoKLSAgICBE ZWZpbmUgdGhlIGJhc2UgS2VyYmVyaXplZCBJbnRlcm5ldCBOZWdvdGlhdGlvbiBvZiBLZXlz IHByb3RvY29sLgoKR29hbHMgYW5kIE1pbGVzdG9uZXMKCgpTZXAgMjAwMCAgICAgIENvbnNl bnN1cyBvbiByZXF1aXJlbWVudHMgZG9jdW1lbnQKCkRlYyAyMDAwICAgICAgUmV2aWV3IGRy YWZ0cyBhdCBEZWMgSUVURgoKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFmdC10aG9t YXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDRdCgoKCgoKSU5URVJORVQt RFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAgICA5IEF1 Z3VzdCAyMDAwCgoKSmFuIDIwMDEgICAgICBDb25zZW5zdXMgb24gYmFzZSBkcmFmdCBwcm90 b2NvbAoKTWFyIDIwMDEgICAgICBXRyBMYXN0IGNhbGwgb24gZHJhZnQKCk1hciAyMDAxLUp1 biAyMDAxCiAgICAgICAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBCYWtlb2ZmcwoKQXVnIDIw MDEgICAgICBJbnRlcm9wZXJhYmlsaXR5IHJlc3VsdHMsIGRlY2lzaW9uIHRvIHJlY3ljbGUg b3IgbW92ZSBmb3ItCiAgICAgICAgICAgICAgd2FyZAoKQWRtaW5pc3RyYXRpdmEKCkNoYWly KHMpOgoKICBEZXJlayBBdGtpbnMgPHdhcmxvcmRAcmVzZWFyY2gudGVsY29yZGlhLmNvbT4K CkRvY3VtZW50IEVkaXRvcjoKCiAgVEJECgpJbnRlcm5ldCBBcmVhIERpcmVjdG9yKHMpOgoK ICBKZWZmcmV5IFNjaGlsbGVyIDxqaXNAbWl0LmVkdT4KICBNYXJjdXMgTGVlY2ggPG1sZWVj aEBub3J0ZWxuZXR3b3Jrcy5jb20+CgpJbnRlcm5ldCBBcmVhIEFkdmlzb3I6CgpUQkQKCk1h aWxpbmcgTGlzdHM6CgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogaWV0Zi1raW5rQHZwbmMub3Jn CiAgVG8gU3Vic2NyaWJlOiBtYWpvcmRvbW9AdnBuYy5vcmcKICBJbiBCb2R5OiBpbiBib2R5 OiBzdWJzY3JpYmUgaWV0Zi1raW5rCiAgQXJjaGl2ZTogZnRwOi8vCgpBY2tub3dsZWRnbWVu dHMKCiAgIFRoZSBvcmlnaW5hbCBLSU5LIEthYmFsIHdhczoKCiAgIE1pY2hhZWwgVGhvbWFz IChDaXNjbykKICAgRGF2aWQgTWNHcmV3IChDaXNjbykKICAgSmFuIFZpbGh1YmVyIChDaXNj bykKICAgSm9uYXRoYW4gVHJvc3RsZSAoQ2lzY28pCiAgIE1hdHQgSHVyIChDeWJlcnNhZmUp CiAgIE1pa2UgRnJvaCAoQ3liZXJzYWZlKQogICBTYXNoYSBNZWR2aW5za3kgKEdJKQogICBE ZXJlayBBdGtpbnMgKFRlbGNvcmRpYSkKCgoKVGhvbWFzICAgICAgICAgICAgICAgICBkcmFm dC10aG9tYXMta2luay1yZXFtdC0wMCAgICAgICAgICAgICAgIFtQYWdlIDVdCgoKCgoKSU5U RVJORVQtRFJBRlQgIEtlcmJlcml6ZWQgSW50ZXJuZXQgTmVnb3RpYXRpb24gb2YgS2V5cyAg ICA5IEF1Z3VzdCAyMDAwCgoKICAgSXQgbXVzdCBhbHNvIGJlIGFja25vd2xlZGdlZCB0aGF0 IHRoZSBQYWNrZXRjYWJsZSBTZWN1cml0eQogICBzcGVjaWZpY2F0aW9uIFBLVC1TUC1TRUMt STAxLTk5MTIwMSBwcm92aWRlZCB0aGUgcmF3IGZvZGRlcgogICBmb3IgdGhpcyBlZmZvcnQg aW4gaXRzIEtlcmJlcml6ZWQgSVBzZWMgc2VjdGlvbiwgYW5kIGFsbCBvZgogICB0aGUgZm9j dXMgdGVhbSBtZW1iZXJzIHdobyBwbGF5ZWQgYSBwYXJ0IGluIHRoZSBzcGVjLiBXZSBtdXN0 CiAgIGFsc28gYWNrbm93bGVkZ2UgTmFuY3kgRGF2b3VzdCBvZiBDYWJsZWxhYnMgZm9yIGtl ZXBpbmcgb3JkZXIKICAgaW4gb3VyIG5vcm1hbGx5IGRpc29yZGVybHkgcHJvY2VlZGluZ3Mu CgpSZWZlcmVuY2VzCgpbMV0gIFRoZSBDQVQgV29ya2luZyBHcm91cCwgSi4gS29obCwgQy5O ZXVtYW4sICJUaGUgS2VyYmVyb3MgTmV0d29yawogICAgIEF1dGhlbnRpY2F0aW9uIFNlcnZp Y2UgKFY1KSIsIFJGQyAxNTEwLCBTZXB0ZW1iZXIgMTk5MwoKWzJdICBUaGUgSVBzZWMgV29y a2luZyBHcm91cCwgUy4gS2VudCwgUi4gQXRraW5zb24sICJTZWN1cml0eSBBcmNoaXRlYy0K ICAgICB0dXJlIGZvciB0aGUgSW50ZXJuZXQgUHJvdG9jb2wiLCBSRkMgMjQwMSwgTm92ZW1i ZXIgMTk5OAoKWzNdICBUaGUgSVBzZWMgV29ya2luZyBHcm91cCwgRC4gSGFya2lucywgRC4g Q2FycmVsLCAiVGhlIEludGVybmV0IEtleQogICAgIEV4Y2hhbmdlIiwgUkZDIDI0MDksIE5v dmVtYmVyIDE5OTgKCkF1dGhvcidzIEFkZHJlc3MKCiAgICAgICAgICBNaWNoYWVsIFRob21h cwogICAgICAgICAgQ2lzY28gU3lzdGVtcwogICAgICAgICAgMzc1IEUgVGFzbWFuIFJkCiAg ICAgICAgICBTYW4gSm9zZSwgQ2EsIDk1MTM0LCBVU0EKICAgICAgICAgIFRlbDogKzEgNDA4 LTUyNS01Mzg2CiAgICAgICAgICBFLU1BSUw6IG1hdEBjaXNjby5jb20KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKClRob21hcyAgICAgICAgICAgICAgICAgZHJhZnQtdGhvbWFzLWtpbmst cmVxbXQtMDAgICAgICAgICAgICAgICBbUGFnZSA2XQoKCg== --bS/BD/5559-- From owner-ietf-kink Tue Sep 19 05:09:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20124 for ietf-kink-bks; Tue, 19 Sep 2000 05:09:19 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.MIT.EDU [18.101.1.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20120 for ; Tue, 19 Sep 2000 05:09:17 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id IAA28252; Tue, 19 Sep 2000 08:11:50 -0400 To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: latest requirements draft References: <14790.44293.570062.666313@thomasm-u1.cisco.com> From: Derek Atkins Date: 19 Sep 2000 08:11:48 -0400 In-Reply-To: Michael Thomas's message of "Mon, 18 Sep 2000 17:02:13 -0700 (PDT)" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, this should be renamed to draft-ietf-kink-requirements (or -reqmt) -derek Michael Thomas writes: > Derek -- should this be changed to > draft-kink-kink-reqmt since the WG has officially > been formed? -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Fri Oct 6 16:27:25 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17762 for ietf-kink-bks; Fri, 6 Oct 2000 16:27:25 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17757 for ; Fri, 6 Oct 2000 16:27:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 6 Oct 2000 16:31:41 -0700 To: ietf-kink@vpnc.org From: Paul Hoffman / VPNC Subject: I-D ACTION:draft-ietf-kink-reqmt-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >From owner-ietf-kink Fri Oct 6 03:27:03 2000 >Received: from ietf.org (odin.ietf.org [132.151.1.176]) > by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29529 > for ; Fri, 6 Oct 2000 03:27:03 -0700 (PDT) >Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27491; > Fri, 6 Oct 2000 06:31:06 -0400 (EDT) >Message-Id: <200010061031.GAA27491@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-reqmt-00.txt >Date: Fri, 06 Oct 2000 06:31:06 -0400 >Sender: nsyracus@cnri.reston.va.us > >--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 > Author(s) : M. Thomas > Filename : draft-ietf-kink-reqmt-00.txt > Pages : 6 > Date : 05-Oct-00 > >The KINK working group is chartered to create a standards track >protocol to facilitate centralized key management for IPsec security >associations as defined in RFC 2401, as an alternative to IKE (RFC >2409). Participating systems will use the Kerberos architecture as >defined in RFC 1510 (and its successors) for key management. The goal >of the working group is to produce a streamlined, fast, easily >managed, and cryptographically sound protocol without requiring >public key. >The working group will not require changes to either IPsec (RFC >2401), or Kerberos (RFC 1510). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-kink-reqmt-00.txt > >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-reqmt-00.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-reqmt-00.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: <20001005145931.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-kink-reqmt-00.txt > >--OtherAccess >Content-Type: Message/External-body; > name="draft-ietf-kink-reqmt-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > >Content-Type: text/plain >Content-ID: <20001005145931.I-D@ietf.org> > >--OtherAccess-- > >--NextPart-- From owner-ietf-kink Fri Oct 6 16:27:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17766 for ietf-kink-bks; Fri, 6 Oct 2000 16:27:26 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17761 for ; Fri, 6 Oct 2000 16:27:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 6 Oct 2000 16:31:35 -0700 To: ietf-kink@vpnc.org From: Paul Hoffman / VPNC Subject: I-D ACTION:draft-ietf-kink-kink-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Date: Fri, 6 Oct 2000 03:27:06 -0700 (PDT) >From: owner-ietf-kink@mail.vpnc.org >To: owner-ietf-kink@mail.vpnc.org >Subject: BOUNCE ietf-kink@mail.vpnc.org: Non-member submission >from [Internet-Drafts@ietf.org] > > >From owner-ietf-kink Fri Oct 6 03:27:05 2000 >Received: from ietf.org (odin.ietf.org [132.151.1.176]) > by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29534 > for ; Fri, 6 Oct 2000 03:27:04 -0700 (PDT) >Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27516; > Fri, 6 Oct 2000 06:31:11 -0400 (EDT) >Message-Id: <200010061031.GAA27516@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-00.txt >Date: Fri, 06 Oct 2000 06:31:11 -0400 >Sender: nsyracus@cnri.reston.va.us > >--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. Froh, M. Hur, D. McGrew, S. Medvinsky, > M. Thomas, J. Vilhuber > Filename : draft-ietf-kink-kink-00.txt > Pages : 30 > Date : 05-Oct-00 > >The KINK Working Group will create a standards track protocol to >facilitate centralized key exchange in an application independent >fashion. Participating systems will use the Kerberos architecture as >defined in RFC 1510 for key management and the KINK protocol between >applications. The goal of KINK is to produce a low-latency, >computationally inexpensive, easily managed, and cryptographically >sound protocol that is flexible enough to be able to be extended for >many applications. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-00.txt > >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-00.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-00.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: <20001005145941.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-kink-kink-00.txt > >--OtherAccess >Content-Type: Message/External-body; > name="draft-ietf-kink-kink-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > >Content-Type: text/plain >Content-ID: <20001005145941.I-D@ietf.org> > >--OtherAccess-- > >--NextPart-- From owner-ietf-kink Fri Oct 13 07:12:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20061 for ietf-kink-bks; Fri, 13 Oct 2000 07:12:44 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20055 for ; Fri, 13 Oct 2000 07:12:42 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA22430; Fri, 13 Oct 2000 10:17:19 -0400 To: ietf-kink@vpnc.org Subject: Discussion of current drafts? Agenda Topics? From: Derek Atkins Date: 13 Oct 2000 10:17:14 -0400 Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings, 0) As you all know, we've been sanctioned into a real working group. So, we exist now. 1) Mike Thomas has submitted two drafts, the KINK requirements draft and a draft KINK protocol. According to our original schedule, we were supposed to have already finalized the KINK requirements by now. I haven't seen any discussion, yet, on the drafts. If I don't see any discussion soon, then I'll assume there are no issues with the requirements draft and request a last call on it. The documents in question are: draft-ietf-kink-reqmt-00.txt draft-ietf-kink-kink-00.txt 2) It's also time to come up with an Agenda and request a WG timeslot in San Diego. If you'd like to request a slot to talk at the meeting, please send me mail with the topic and estimated time you'll need. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Fri Oct 13 07:58:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21475 for ietf-kink-bks; Fri, 13 Oct 2000 07:58:54 -0700 (PDT) Received: from fnord.ir.bbn.com (FNORD.IR.BBN.COM [192.1.100.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA21470 for ; Fri, 13 Oct 2000 07:58:52 -0700 (PDT) Message-Id: <200010131458.HAA21470@ns.secondary.com> Received: (qmail 73137 invoked from network); 13 Oct 2000 15:03:35 -0000 Received: from localhost.bbn.com (HELO fnord.ir.bbn.com) (127.0.0.1) by localhost.bbn.com with SMTP; 13 Oct 2000 15:03:35 -0000 From: Greg Troxel To: ietf-kink@vpnc.org Subject: lack of PFS considered harmful In-Reply-To: Message from Derek Atkins of "13 Oct 2000 10:17:14 EDT." Date: Fri, 13 Oct 2000 11:03:35 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding: draft-ietf-kink-reqmt-00.txt draft-ietf-kink-kink-00.txt I am concerned about the lack of consideration for PFS. At a minimum this needs to be in the (currently blank) security considerations section. It should be noted that KINK is a complement to and not a replacement for the Internet Key Exchange [IKE], as KINK requires the use of an online authentication server and cannot provide identity protection nor perfect forward secrecy (as described in [RFC2412]). There are many situations in which centralized key management is desirable. This text can be read to imply that KINK cannot provide identity provide or PFS because it uses of an online authentication server. I'm guessing that this isn't what was intended, but a clarification would be helpful. I believe that the use of centralized key management (vs. certificates) is orthogonal to PFS. It appears on quick reading of the draft that someone who compromises a principal's key years hence will still be able to recover all plaintext, since the IPsec session key is encrypted in the krb session key. I'll make my opinion explicit that all interactive login sessions need PFS protection, and that given how cheap PFS implementation is on today's machines, it isn't reasonable to omit it. Since it seems to be the goal to set up a campus to use KINK instead of IKE, it would be nice for KINK to be able to meet this requirement. One solution of course is to perform double-ephemeral DH, and authenticate that with Kerberos. This gets somewhat closer to IKE with Kerberos authentication. Is it the goal of KINK to have a protocol that does not use public key operations, or one that does not require them in all cases, or that does not require them in any case? It may also be that adding a PFS option to Kerberos (independently of kink) is desirable. Greg From owner-ietf-kink Fri Oct 13 08:16:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22502 for ietf-kink-bks; Fri, 13 Oct 2000 08:16:40 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22495 for ; Fri, 13 Oct 2000 08:16:39 -0700 (PDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA13959; Fri, 13 Oct 2000 08:20:58 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-122.cisco.com [171.71.147.122]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id APX04544 (AUTH mcgrew); Fri, 13 Oct 2000 08:20:51 -0700 (PDT) Message-ID: <39E7295B.AFE9566F@cisco.com> Date: Fri, 13 Oct 2000 08:25:15 -0700 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Troxel CC: ietf-kink@vpnc.org Subject: Re: lack of PFS considered harmful References: <200010131458.HAA21470@ns.secondary.com> 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: Greg, Greg Troxel wrote: > > Regarding: > > draft-ietf-kink-reqmt-00.txt > draft-ietf-kink-kink-00.txt > > I am concerned about the lack of consideration for PFS. > At a minimum this needs to be in the (currently blank) security > considerations section. > > It should be noted > that KINK is a complement to and not a replacement for the Internet > Key Exchange [IKE], as KINK requires the use of an online > authentication server and cannot provide identity protection nor > perfect forward secrecy (as described in [RFC2412]). There are many > situations in which centralized key management is desirable. > > This text can be read to imply that KINK cannot provide identity > provide or PFS because it uses of an online authentication server. > I'm guessing that this isn't what was intended, but a clarification > would be helpful. no, you read it right. > > I believe that the use of centralized key management > (vs. certificates) is orthogonal to PFS. It appears on quick reading > of the draft that someone who compromises a principal's key years > hence will still be able to recover all plaintext, since the IPsec > session key is encrypted in the krb session key. > > I'll make my opinion explicit that all interactive login sessions need > PFS protection, and that given how cheap PFS implementation is on > today's machines, it isn't reasonable to omit it. Since it seems to > be the goal to set up a campus to use KINK instead of IKE, it would be > nice for KINK to be able to meet this requirement. We explicitly made PFS a non-goal. On machines such as wireless handsets and other embedded systems, PFS isn't cheap. Also, PFS can be a bottleneck for aggregation servers as well. So while desktop machines typically have no problem with PFS, there are still lots of devices that do. > > One solution of course is to perform double-ephemeral DH, and > authenticate that with Kerberos. This gets somewhat closer to IKE > with Kerberos authentication. And this is exactly what GSSAPI IKE does. >s it the goal of KINK to have a > protocol that does not use public key operations, or one that does not > require them in all cases, or that does not require them in any case? > Yes, that's right. From a standards perspective, it may be good that we don't do all of those things, since IKE already does them. > It may also be that adding a PFS option to Kerberos (independently of > kink) is desirable. I agree completely. Thanks for your comments, David > > Greg From owner-ietf-kink Fri Oct 13 09:15:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA27379 for ietf-kink-bks; Fri, 13 Oct 2000 09:15:15 -0700 (PDT) Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27373 for ; Fri, 13 Oct 2000 09:15:14 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA19802; Fri, 13 Oct 2000 09:19:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10168; Fri, 13 Oct 2000 09:19:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14823.13840.220998.540752@thomasm-u1.cisco.com> Date: Fri, 13 Oct 2000 09:19:28 -0700 (PDT) To: Greg Troxel Cc: ietf-kink@vpnc.org Subject: lack of PFS considered harmful In-Reply-To: <200010131458.HAA21470@ns.secondary.com> References: <200010131458.HAA21470@ns.secondary.com> 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: Greg Troxel writes: > Regarding: > > draft-ietf-kink-reqmt-00.txt > draft-ietf-kink-kink-00.txt > > I am concerned about the lack of consideration for PFS. > At a minimum this needs to be in the (currently blank) security > considerations section. Greg, I agree with David's comments and have nothing to add. The security considerations section was left blank mainly because we wanted to get the draft out as soon as possible. Also: we expected to get feedback which we could incorporate into the section. What I would propose to add to the security considerations on this topic is: "KINK uses Kerberos cryptographic mechanisms for key exchange and as such is limited to what Kerberos provides. These limitations include PFS [, ...]. It is not a goal of KINK to address Kerberos issues as they would be better addressed by Kerberos itself." Mike > > It should be noted > that KINK is a complement to and not a replacement for the Internet > Key Exchange [IKE], as KINK requires the use of an online > authentication server and cannot provide identity protection nor > perfect forward secrecy (as described in [RFC2412]). There are many > situations in which centralized key management is desirable. > > This text can be read to imply that KINK cannot provide identity > provide or PFS because it uses of an online authentication server. > I'm guessing that this isn't what was intended, but a clarification > would be helpful. > > I believe that the use of centralized key management > (vs. certificates) is orthogonal to PFS. It appears on quick reading > of the draft that someone who compromises a principal's key years > hence will still be able to recover all plaintext, since the IPsec > session key is encrypted in the krb session key. > > I'll make my opinion explicit that all interactive login sessions need > PFS protection, and that given how cheap PFS implementation is on > today's machines, it isn't reasonable to omit it. Since it seems to > be the goal to set up a campus to use KINK instead of IKE, it would be > nice for KINK to be able to meet this requirement. > > One solution of course is to perform double-ephemeral DH, and > authenticate that with Kerberos. This gets somewhat closer to IKE > with Kerberos authentication. Is it the goal of KINK to have a > protocol that does not use public key operations, or one that does not > require them in all cases, or that does not require them in any case? > > It may also be that adding a PFS option to Kerberos (independently of > kink) is desirable. > > Greg > From owner-ietf-kink Fri Oct 13 16:54:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09339 for ietf-kink-bks; Fri, 13 Oct 2000 16:54:30 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09335 for ; Fri, 13 Oct 2000 16:54:28 -0700 (PDT) Received: from dhcp-71-147-154.cisco.com (vilhuber@dhcp-71-147-154.cisco.com [171.71.147.154]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA05241; Fri, 13 Oct 2000 16:58:15 -0700 (PDT) Date: Fri, 13 Oct 2000 16:58:51 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Michael Thomas cc: Greg Troxel , ietf-kink@vpnc.org Subject: Re: lack of PFS considered harmful In-Reply-To: <14823.13840.220998.540752@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That paragraph sounds great to me. I second the motion ;) jan On Fri, 13 Oct 2000, Michael Thomas wrote: > Greg Troxel writes: > > Regarding: > > > > draft-ietf-kink-reqmt-00.txt > > draft-ietf-kink-kink-00.txt > > > > I am concerned about the lack of consideration for PFS. > > At a minimum this needs to be in the (currently blank) security > > considerations section. > > Greg, > > I agree with David's comments and have nothing to > add. The security considerations section was left > blank mainly because we wanted to get the draft > out as soon as possible. Also: we expected to get > feedback which we could incorporate into the > section. > > What I would propose to add to the security > considerations on this topic is: "KINK uses > Kerberos cryptographic mechanisms for key exchange > and as such is limited to what Kerberos provides. > These limitations include PFS [, ...]. It is not > a goal of KINK to address Kerberos issues as they > would be better addressed by Kerberos itself." > > Mike > > > > > > It should be noted > > that KINK is a complement to and not a replacement for the Internet > > Key Exchange [IKE], as KINK requires the use of an online > > authentication server and cannot provide identity protection nor > > perfect forward secrecy (as described in [RFC2412]). There are many > > situations in which centralized key management is desirable. > > > > This text can be read to imply that KINK cannot provide identity > > provide or PFS because it uses of an online authentication server. > > I'm guessing that this isn't what was intended, but a clarification > > would be helpful. > > > > I believe that the use of centralized key management > > (vs. certificates) is orthogonal to PFS. It appears on quick reading > > of the draft that someone who compromises a principal's key years > > hence will still be able to recover all plaintext, since the IPsec > > session key is encrypted in the krb session key. > > > > I'll make my opinion explicit that all interactive login sessions need > > PFS protection, and that given how cheap PFS implementation is on > > today's machines, it isn't reasonable to omit it. Since it seems to > > be the goal to set up a campus to use KINK instead of IKE, it would be > > nice for KINK to be able to meet this requirement. > > > > One solution of course is to perform double-ephemeral DH, and > > authenticate that with Kerberos. This gets somewhat closer to IKE > > with Kerberos authentication. Is it the goal of KINK to have a > > protocol that does not use public key operations, or one that does not > > require them in all cases, or that does not require them in any case? > > > > It may also be that adding a PFS option to Kerberos (independently of > > kink) is desirable. > > > > Greg > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Fri Oct 13 17:33:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA10264 for ietf-kink-bks; Fri, 13 Oct 2000 17:33:32 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10260 for ; Fri, 13 Oct 2000 17:33:31 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Oct 2000 17:36:42 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Oct 2000 17:37:48 -0700 (Pacific Daylight Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Oct 2000 17:37:48 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: lack of PFS considered harmful MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03576.F98FB468" Date: Fri, 13 Oct 2000 17:37:47 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C07626574472FA8@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: lack of PFS considered harmful Thread-Index: AcA1cc92dnbfyPvnQLeqjpo8sK2RQgABEARg From: "Paul Leach" To: "Jan Vilhuber" , "Michael Thomas" Cc: "Greg Troxel" , X-OriginalArrivalTime: 14 Oct 2000 00:37:48.0360 (UTC) FILETIME=[FA07C480:01C03576] Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C03576.F98FB468 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree too, that PFS needs to be done via Kerberos itself. The good news is that I believe use of PK options of Kerberos with Diffie-Hellman certified keys gets us pretty close to PFS. (One would need to use both PKINIT for AS_REQs; and PKCROSS to exchange keys between the KDC and the server, instead of using a long term server symmetric secret key. It don't believe it is currently envisioned to use PKCROSS for KDC to server key exchange, only for cross realm KDC to KDC key exchange, but it doesn't seem all that hard to adopt PKCROSS for the task.) > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, October 13, 2000 4:59 PM > To: Michael Thomas > Cc: Greg Troxel; ietf-kink@vpnc.org > Subject: Re: lack of PFS considered harmful >=20 >=20 > That paragraph sounds great to me. I second the motion ;) >=20 > jan >=20 >=20 > On Fri, 13 Oct 2000, Michael Thomas wrote: >=20 > > Greg Troxel writes: > > > Regarding: > > >=20 > > > draft-ietf-kink-reqmt-00.txt > > > draft-ietf-kink-kink-00.txt > > >=20 > > > I am concerned about the lack of consideration for PFS. > > > At a minimum this needs to be in the (currently blank) security > > > considerations section. ------_=_NextPart_001_01C03576.F98FB468 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: lack of PFS considered harmful

I agree too, that PFS needs to be done via Kerberos = itself. The good news is that I believe use of PK options of Kerberos = with Diffie-Hellman certified keys gets us pretty close to PFS. (One = would need to use both PKINIT for AS_REQs; and PKCROSS to exchange keys = between the KDC and the server, instead of using a long term server = symmetric secret key. It don't believe it is currently envisioned to use = PKCROSS for KDC to server key exchange, only for cross realm KDC to KDC = key exchange, but it doesn't seem all that hard to adopt PKCROSS for the = task.)

> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Friday, October 13, 2000 4:59 PM
> To: Michael Thomas
> Cc: Greg Troxel; ietf-kink@vpnc.org
> Subject: Re: lack of PFS considered = harmful
>
>
> That paragraph sounds great to me. I second the = motion ;)
>
> jan
>
>
> On Fri, 13 Oct 2000, Michael Thomas = wrote:
>
> > Greg Troxel writes:
> >  > Regarding:
> >  >
> >  >  = draft-ietf-kink-reqmt-00.txt
> >  >  = draft-ietf-kink-kink-00.txt
> >  >
> >  > I am concerned about the lack of = consideration for PFS.
> >  > At a minimum this needs to be in = the (currently blank) security
> >  > considerations section.

------_=_NextPart_001_01C03576.F98FB468-- From owner-ietf-kink Fri Oct 13 17:56:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA10523 for ietf-kink-bks; Fri, 13 Oct 2000 17:56:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10519 for ; Fri, 13 Oct 2000 17:56:08 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18594; Fri, 13 Oct 2000 19:00:48 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA29645; Fri, 13 Oct 2000 21:00:47 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e9E10Bl151199; Fri, 13 Oct 2000 21:00:11 -0400 (EDT) Message-Id: <200010140100.e9E10Bl151199@thunk.east.sun.com> From: Bill Sommerfeld To: "Paul Leach" cc: "Jan Vilhuber" , "Michael Thomas" , "Greg Troxel" , ietf-kink@vpnc.org Subject: Re: lack of PFS considered harmful In-reply-to: Your message of "Fri, 13 Oct 2000 17:37:47 PDT." <5B90AD65A9E8934987DB0C8C07626574472FA8@DF-BOWWOW.platinum.corp.microsoft.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 13 Oct 2000 21:00:11 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The good news is that I believe use of PK options of Kerberos with > Diffie-Hellman certified keys gets us pretty close to PFS. "Pretty Close" and "Perfect" don't mix. Also, requiring changes to the Kerberos protocol or KDC to support KINK would be out of scope for this working group. I still think the path of least resistance for KINK is to reuse as much of IKE as possible, just using kerberos as an authentication method.. - Bill From owner-ietf-kink Fri Oct 13 18:02:00 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA10636 for ietf-kink-bks; Fri, 13 Oct 2000 18:02:00 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10632 for ; Fri, 13 Oct 2000 18:01:56 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Oct 2000 18:04:32 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Oct 2000 18:05:38 -0700 (Pacific Daylight Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Oct 2000 18:05:38 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: lack of PFS considered harmful MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0357A.DCDABFD8" Date: Fri, 13 Oct 2000 18:05:37 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657446D2E1@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: lack of PFS considered harmful Thread-Index: AcA1ekMWY5xrNc6WRVaPdfVB1tG25wAADsxA From: "Paul Leach" To: Cc: "Jan Vilhuber" , "Michael Thomas" , "Greg Troxel" , X-OriginalArrivalTime: 14 Oct 2000 01:05:38.0174 (UTC) FILETIME=[DD5129E0:01C0357A] Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0357A.DCDABFD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Friday, October 13, 2000 6:00 PM > To: Paul Leach > Cc: Jan Vilhuber; Michael Thomas; Greg Troxel; ietf-kink@vpnc.org > Subject: Re: lack of PFS considered harmful=20 >=20 >=20 > > The good news is that I believe use of PK options of Kerberos with > > Diffie-Hellman certified keys gets us pretty close to PFS. >=20 > "Pretty Close" and "Perfect" don't mix. Also, requiring changes to > the Kerberos protocol or KDC to support KINK would be out of scope for > this working group. I agree. In fact, I agreed in the part of the post you excised. I was just noting that the fix to kerberos (and the fact that it's pretty close indeed means that a fix would be needed) might not be too hard. >=20 > I still think the path of least resistance for KINK is to reuse as > much of IKE as possible, just using kerberos as an authentication > method.. Yuck. The road to hell is often the path of least resistance. Paul ------_=_NextPart_001_01C0357A.DCDABFD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: lack of PFS considered harmful

> -----Original Message-----
> From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com]
> Sent: Friday, October 13, 2000 6:00 PM
> To: Paul Leach
> Cc: Jan Vilhuber; Michael Thomas; Greg Troxel; = ietf-kink@vpnc.org
> Subject: Re: lack of PFS considered harmful =
>
>
> > The good news is that I believe use of PK = options of Kerberos with
> > Diffie-Hellman certified keys gets us = pretty close to PFS.
>
> "Pretty Close" and "Perfect" = don't mix.  Also, requiring changes to
> the Kerberos protocol or KDC to support KINK = would be out of scope for
> this working group.

I agree. In fact, I agreed in the part of the post you = excised. I was just noting that the fix to kerberos (and the fact that = it's pretty close indeed means that a fix would be needed) might not be = too hard.

>
> I still think the path of least resistance for = KINK is to reuse as
> much of IKE as possible, just using kerberos as = an authentication
> method..

Yuck.  The road to hell is often the path of = least resistance.

Paul

------_=_NextPart_001_01C0357A.DCDABFD8-- From owner-ietf-kink Sat Oct 14 10:21:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04965 for ietf-kink-bks; Sat, 14 Oct 2000 10:21:01 -0700 (PDT) Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04961 for ; Sat, 14 Oct 2000 10:20:59 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA18689; Sat, 14 Oct 2000 10:24:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10468; Sat, 14 Oct 2000 10:24:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14824.38626.853445.519932@thomasm-u1.cisco.com> Date: Sat, 14 Oct 2000 10:24:50 -0700 (PDT) To: sommerfeld@east.sun.com Cc: "Paul Leach" , "Jan Vilhuber" , "Michael Thomas" , "Greg Troxel" , ietf-kink@vpnc.org Subject: Re: lack of PFS considered harmful In-Reply-To: <200010140100.e9E10Bl151199@thunk.east.sun.com> References: <5B90AD65A9E8934987DB0C8C07626574472FA8@DF-BOWWOW.platinum.corp.microsoft.com> <200010140100.e9E10Bl151199@thunk.east.sun.com> 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: Bill Sommerfeld writes: > > The good news is that I believe use of PK options of Kerberos with > > Diffie-Hellman certified keys gets us pretty close to PFS. > > "Pretty Close" and "Perfect" don't mix. Also, requiring changes to > the Kerberos protocol or KDC to support KINK would be out of scope for > this working group. The point was that this is a more general issue for Kerberos itself, and the better route would be to take it up with that WG so that all Kerberos applications would benefit. > I still think the path of least resistance for KINK is to reuse as > much of IKE as possible, just using kerberos as an authentication > method.. I believe there are already drafts which attempt to do exactly that; that's not the goal of this WG though. The main goal here is to leverage Kerberos as a key exchange and authentication mechanism. Grafting IKE key exchange or authentication mechanisms into KINK sort of misses the point. Mike From owner-ietf-kink Sat Oct 14 18:07:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA09934 for ietf-kink-bks; Sat, 14 Oct 2000 18:07:22 -0700 (PDT) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09930 for ; Sat, 14 Oct 2000 18:07:20 -0700 (PDT) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id SAA03893; Sat, 14 Oct 2000 18:11:36 -0700 (PDT) Date: Sat, 14 Oct 2000 18:11:21 -0700 (PDT) From: Jan Vilhuber To: Paul Leach cc: sommerfeld@east.sun.com, Michael Thomas , Greg Troxel , ietf-kink@vpnc.org Subject: RE: lack of PFS considered harmful In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657446D2E1@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 13 Oct 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > > Sent: Friday, October 13, 2000 6:00 PM > > To: Paul Leach > > Cc: Jan Vilhuber; Michael Thomas; Greg Troxel; ietf-kink@vpnc.org > > Subject: Re: lack of PFS considered harmful > > > > > > > The good news is that I believe use of PK options of Kerberos with > > > Diffie-Hellman certified keys gets us pretty close to PFS. > > > > "Pretty Close" and "Perfect" don't mix. Also, requiring changes to > > the Kerberos protocol or KDC to support KINK would be out of scope for > > this working group. > > I agree. In fact, I agreed in the part of the post you excised. I was > just noting that the fix to kerberos (and the fact that it's pretty > close indeed means that a fix would be needed) might not be too hard. > > > > > I still think the path of least resistance for KINK is to reuse as > > much of IKE as possible, just using kerberos as an authentication > > method.. > > Yuck. The road to hell is often the path of least resistance. > And IKE bashing (Yuck! NOT IKE!) seems to be some sort of 'least resistance' kind of thing, too. It makes perfect sense to reuse IKE packet formats where possible. No one is suggesting doing cookies, and other things that make IKE complicated. Reusing packet-formats make perfect sense because there's well-tested code to parse them already out there. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Sat Oct 14 18:10:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA09975 for ietf-kink-bks; Sat, 14 Oct 2000 18:10:00 -0700 (PDT) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09968 for ; Sat, 14 Oct 2000 18:09:59 -0700 (PDT) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id SAA03940; Sat, 14 Oct 2000 18:13:53 -0700 (PDT) Date: Sat, 14 Oct 2000 18:13:52 -0700 (PDT) From: Jan Vilhuber To: Michael Thomas cc: sommerfeld@east.sun.com, Paul Leach , Greg Troxel , ietf-kink@vpnc.org Subject: Re: lack of PFS considered harmful In-Reply-To: <14824.38626.853445.519932@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 14 Oct 2000, Michael Thomas wrote: > Bill Sommerfeld writes: > > > The good news is that I believe use of PK options of Kerberos with > > > Diffie-Hellman certified keys gets us pretty close to PFS. > > > > "Pretty Close" and "Perfect" don't mix. Also, requiring changes to > > the Kerberos protocol or KDC to support KINK would be out of scope for > > this working group. > > The point was that this is a more general issue > for Kerberos itself, and the better route would > be to take it up with that WG so that all > Kerberos applications would benefit. > > > I still think the path of least resistance for KINK is to reuse as > > much of IKE as possible, just using kerberos as an authentication > > method.. > > I believe there are already drafts which attempt to > do exactly that; that's not the goal of this WG > though. The main goal here is to leverage > Kerberos as a key exchange and authentication > mechanism. Grafting IKE key exchange or > authentication mechanisms into KINK sort of > misses the point. > Depends on how you look at it. The original idea was to use a simplified 2 packet quick-mode exchange (scratch the last message, and let kerberos do freshness and replay-protection) to carry the proposals and such, and let kerberos do the encryption, mutual authentication, and replay-protection. This sort of division makes it easy to parse the packets, and also makes it easy to implement and analyze. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Oct 30 16:01:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA25523 for ietf-kink-bks; Mon, 30 Oct 2000 16:01:20 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25518 for ; Mon, 30 Oct 2000 16:01:18 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JVY4A8KI1CEZE7XF@GI.COM> for ietf-kink@vpnc.org; Mon, 30 Oct 2000 11:58:17 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 11:57:27 -0500 Content-return: allowed Date: Mon, 30 Oct 2000 15:00:25 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: alternative to user-to-user Kerberos in KINK To: "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD47EC@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The user-to-user Kerberos mode in KINK is intended to address the situation with PKINIT clients that do not have symmetric client keys registered with the KDC and therefore a Kerberized server cannot get a standard ticket for such a client. But the server still has to obtain user-to-user tickets for clients, which brings up the following issues: 1) Under some architecures, such as VoIP, fast failover time from a primary to a backup application server is critical. With the current protocol, the backup server would have to go to the KDC and get user-to-user tickets for all of the clients with which it needs to establish IPSec SAs. This adds to the recovery time and adds additional performance/reliability requirements to the KDC. The number of clients per server can be large - 100,000 clients / Call Server is possible in the PacketCable architecture. It is possible for the server to save user-to-user tickets and corresponding session keys into some shared database, which is undesirable in terms of complexity as well as security. 2) Load balancing between multiple Call Servers is sometimes used in the VoIP architecture - support for it is mandatory in the PacketCable standard. The user-to-user tickets again either add to the rekeying time (which delays the switch-over time for a client between servers) or adds the complication of a shared database of user-to-user tickets. 3) A standard Kerberized server that doesn't support the user-to-user tickets is a lot simpler to implement. It would implement a very small percentage of the Kerberos protocol - just the AP Req/AP Rep/KRB-ERROR messages. With the user-to-user mode, the server needs the complete Kerberos client implementation and in addition may need to support a very large ticket cache for user-to-user tickets. 4) Setting per-user policy is awkward for user-to-user requests. Normally, the user policy is associated with the client, but in this case the client is the server. Kerberos allows a user to pass authorization data in a TGS Request (which may be insecure, depending on the content of that authorization data), which would not be possible if it is the server getting a ticket for the client. 5) Setting per-user policy in a cross-realm case is even more awkward. The server's GetTGT request would most likely contain the server's realm name (as the server may not know the client's realm). This means that the response to the GetTGT will contain a cross-realm TGT for the client. So, the server's KDC will wind up issuing a server a user-to-user ticket for a client principal that is not even in that KDC's realm. There are alternative methods for handling PKINIT clients that address most of the above issues. What I propose, is the following modification to the protocol. The GetTGT message flow in section 4.2 can be replaced with the following: A B ------ ------ 1 AuthenticateRequest+ServerPrincipalName---------------> 2 <------------------------------------AuthenticateReply+AP_REQ 3 CREATE+ISAKMP (keyed cksum with sess key)--------> 4 <------------REPLY+ISAKMP(keyed cksum with sess key) In the above flows, there needs to be a way to tie flows 2 and 3 together - for example the client timestamp inside AP_REQ can be repeated in flow 3. In addition, there is already an XID in the header for this key management session. (It is also possible to include the AP_REP in flow 3.) In the above flows, the AuthenticateRequest is not authenticated, just like the GetTGT message. There is the denial of service argument against the above flow since anyone can send the AuthenticateRequest. If C impersonates A and sends the AuthenticateRequest, B will have to reply, but A will reject the reply because the XID (session ID in the header) will not match anything that A sent out. The denial of service arguments are: a) denial of service on the KDC - B may need to get a ticket for A if it doesn't have it already. But, even if KDC receives an invalid TGS_REQ, it still has to decrypt it to see that it is invalid. I don't think that the extra work of issuing a ticket is a major problem. Also, clients should cache the tickets, and the number of servers in the KDC database is probably not that big. Also, the clients should excersize access control and know ahead of time which servers they should be talking to. b) denial of service on the clients - this is similar to (a), except that the client's ticket cache is filled up. This is really the same case as (a), because when the client's ticket cache is filled up it can remove one of the entries. It just means that if the client gets a request that needs the removed ticket, the client will request it from the KDC again. Also, with the current KINK protocol, similar denial of service attacks are possible. In that protocol, the GetTGT message only specifies the realm. If the server doesn't know the client's name, it might get the wrong client TGT and get a user-to-user ticket for a wrong client. If the server then finds out that the resulting user-to-user ticket is not accepted by the legitimate client, it will probably retry with another GetTGT message that could also result in a wrong TGT (inserted by an adversary) and then a wrong user-to-user ticket, ... From owner-ietf-kink Tue Oct 31 14:54:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA11835 for ietf-kink-bks; Tue, 31 Oct 2000 14:54:43 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11830 for ; Tue, 31 Oct 2000 14:54:41 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e9VN0gH09352 for ; Tue, 31 Oct 2000 18:00:42 -0500 (EST) Message-Id: <200010312300.e9VN0gH09352@ginger.cmf.nrl.navy.mil> To: "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 30 Oct 2000 15:00:25 EST." <97DEDE66B3DCD11199D200805FA71BE202FD47EC@ntas0027.gi.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: Tue, 31 Oct 2000 18:00:41 -0500 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 3) A standard Kerberized server that doesn't support the >user-to-user tickets is a lot simpler to implement. If you don't handle a TGS_REQ, I don't think you could call it "Kerberos"; and from looking at a sample KDC, I don't think a TGS_REQ really adds that much complexity (compared to how much else you have to implement to do Kerberos). --Ken From owner-ietf-kink Fri Nov 3 11:38:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA14703 for ietf-kink-bks; Fri, 3 Nov 2000 11:38:47 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14699 for ; Fri, 3 Nov 2000 11:38:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA15705; Fri, 3 Nov 2000 11:44:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01988; Fri, 3 Nov 2000 11:44:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14851.5550.610343.923802@thomasm-u1.cisco.com> Date: Fri, 3 Nov 2000 11:44:46 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'ietf-kink@vpnc.org'" Subject: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD47EC@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD47EC@ntas0027.gi.com> 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: After talking to Matt Hur about this and thinking about this for a long time, I think the better part of valor here may, in fact, be avoidance. Taking a giant step backward, the root of all of the trouble here is that KINK is, in fact, a peer to peer protocol where PKinit expects a client server relationship. The main problem is that PKinit authenticated clients do not share a symmetric key at the KDC so the KDC cannot issue a service ticket directly thus bringing on the issues related to user-user mode. If the PKinit client did share a key with the KDC, the KINK peer would just obtain a normal service ticket and that would be that. Therefore, I think that I agree with Matt's contention that a much better strategy for use of PKinit would be to use PKinit as an enrollment strategy into a kerberos realm rather than an authentication strategy, per se. Ie, a client authenticates to the KDC using a cert but the KDC then enrolls it with a symmetric key and saves that key in its principal database. I haven't looked at this exhaustively, but I think that this strategy could be implemented using either no or minimal changes to PKinit -- the obvious thing to do is use the session key from the TGT from the PKinit AS-REQ as the symmetric key. My proposal is that we deal with this problem as a PKinit issue rather than a KINK issue because this is a generic problem with PKinit -- KINK is just the first to stumble upon the implications of using PKinit in a peer to peer application. The advantage here is that we could avoid *all* unauthenticated requests which from a DoS standpoint seems like a much better idea. Mike Medvinsky, Sasha (SD-EX) writes: > The user-to-user Kerberos mode in KINK is intended to address the situation > with PKINIT clients that do not have symmetric client keys registered with > the KDC and therefore a Kerberized server cannot get a standard ticket for > such a client. But the server still has to obtain user-to-user tickets for > clients, which brings up the following issues: > > 1) Under some architecures, such as VoIP, fast failover time from a > primary to a backup application server is critical. With the current > protocol, the backup server would have to go to the KDC and get user-to-user > tickets for all of the clients with which it needs to establish IPSec SAs. > This adds to the recovery time and adds additional performance/reliability > requirements to the KDC. The number of clients per server can be large - > 100,000 clients / Call Server is possible in the PacketCable architecture. > > It is possible for the server to save user-to-user tickets and > corresponding session keys into some shared database, which is undesirable > in terms of complexity as well as security. > > 2) Load balancing between multiple Call Servers is sometimes used in > the VoIP architecture - support for it is mandatory in the PacketCable > standard. The user-to-user tickets again either add to the rekeying time > (which delays the switch-over time for a client between servers) or adds the > complication of a shared database of user-to-user tickets. > > 3) A standard Kerberized server that doesn't support the > user-to-user tickets is a lot simpler to implement. It would implement a > very small percentage of the Kerberos protocol - just the AP Req/AP > Rep/KRB-ERROR messages. With the user-to-user mode, the server needs the > complete Kerberos client implementation and in addition may need to support > a very large ticket cache for user-to-user tickets. > > 4) Setting per-user policy is awkward for user-to-user requests. > Normally, the user policy is associated with the client, but in this case > the client is the server. Kerberos allows a user to pass authorization data > in a TGS Request (which may be insecure, depending on the content of that > authorization data), which would not be possible if it is the server getting > a ticket for the client. > > 5) Setting per-user policy in a cross-realm case is even more > awkward. The server's GetTGT request would most likely contain the server's > realm name (as the server may not know the client's realm). This means that > the response to the GetTGT will contain a cross-realm TGT for the client. > So, the server's KDC will wind up issuing a server a user-to-user ticket for > a client principal that is not even in that KDC's realm. > > There are alternative methods for handling PKINIT clients that address most > of the above issues. What I propose, is the following modification to the > protocol. The GetTGT message flow in section 4.2 can be replaced with the > following: > > A > B > ------ > ------ > 1 AuthenticateRequest+ServerPrincipalName---------------> > > 2 <------------------------------------AuthenticateReply+AP_REQ > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > In the above flows, there needs to be a way to tie flows 2 and 3 together - > for example the client timestamp inside AP_REQ can be repeated in flow 3. > In addition, there is already an XID in the header for this key management > session. (It is also possible to include the AP_REP in flow 3.) > > In the above flows, the AuthenticateRequest is not authenticated, just like > the GetTGT message. There is the denial of service argument against the > above flow since anyone can send the AuthenticateRequest. If C impersonates > A and sends the AuthenticateRequest, B will have to reply, but A will reject > the reply because the XID (session ID in the header) will not match anything > that A sent out. The denial of service arguments are: > > a) denial of service on the KDC - B may need to get a ticket for A > if it doesn't have it already. But, even if KDC receives an invalid > TGS_REQ, it still has to decrypt it to see that it is invalid. I don't > think that the extra work of issuing a ticket is a major problem. Also, > clients should cache the tickets, and the number of servers in the KDC > database is probably not that big. Also, the clients should excersize > access control and know ahead of time which servers they should be talking > to. > > b) denial of service on the clients - this is similar to (a), except > that the client's ticket cache is filled up. This is really the same case > as (a), because when the client's ticket cache is filled up it can remove > one of the entries. It just means that if the client gets a request that > needs the removed ticket, the client will request it from the KDC again. > > Also, with the current KINK protocol, similar denial of service attacks are > possible. In that protocol, the GetTGT message only specifies the realm. > If the server doesn't know the client's name, it might get the wrong client > TGT and get a user-to-user ticket for a wrong client. If the server then > finds out that the resulting user-to-user ticket is not accepted by the > legitimate client, it will probably retry with another GetTGT message that > could also result in a wrong TGT (inserted by an adversary) and then a wrong > user-to-user ticket, ... > From owner-ietf-kink Fri Nov 3 11:57:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA15486 for ietf-kink-bks; Fri, 3 Nov 2000 11:57:56 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15480 for ; Fri, 3 Nov 2000 11:57:54 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JW3PLQT1VAEZGNF2@GI.COM> for ietf-kink@vpnc.org; Fri, 3 Nov 2000 12:03:24 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 03 Nov 2000 12:00:14 -0500 Content-return: allowed Date: Fri, 03 Nov 2000 15:03:10 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4809@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, As per my previous email, I listed what I consider to be problems associated with a server obtaining tickets for a large number of its clients. While I would support a change to PKINIT that allows automatic generation of client keys that are saved in the KDC database, I don't believe that it addresses this issue. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, November 03, 2000 11:45 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'ietf-kink@vpnc.org' > Subject: alternative to user-to-user Kerberos in KINK > > > > After talking to Matt Hur about this and thinking > about this for a long time, I think the better > part of valor here may, in fact, be avoidance. > > Taking a giant step backward, the root of all of > the trouble here is that KINK is, in fact, a peer > to peer protocol where PKinit expects a client > server relationship. The main problem is that > PKinit authenticated clients do not share a > symmetric key at the KDC so the KDC cannot issue a > service ticket directly thus bringing on the > issues related to user-user mode. If the PKinit > client did share a key with the KDC, the KINK peer > would just obtain a normal service ticket and that > would be that. > > Therefore, I think that I agree with Matt's > contention that a much better strategy for use of > PKinit would be to use PKinit as an enrollment > strategy into a kerberos realm rather than an > authentication strategy, per se. Ie, a client > authenticates to the KDC using a cert but the KDC > then enrolls it with a symmetric key and saves > that key in its principal database. I haven't > looked at this exhaustively, but I think that this > strategy could be implemented using either no or > minimal changes to PKinit -- the obvious thing to > do is use the session key from the TGT from the > PKinit AS-REQ as the symmetric key. > > My proposal is that we deal with this problem as a > PKinit issue rather than a KINK issue because this > is a generic problem with PKinit -- KINK is just > the first to stumble upon the implications of > using PKinit in a peer to peer application. The > advantage here is that we could avoid *all* > unauthenticated requests which from a DoS > standpoint seems like a much better idea. > > Mike > > Medvinsky, Sasha (SD-EX) writes: > > The user-to-user Kerberos mode in KINK is intended to > address the situation > > with PKINIT clients that do not have symmetric client keys > registered with > > the KDC and therefore a Kerberized server cannot get a > standard ticket for > > such a client. But the server still has to obtain > user-to-user tickets for > > clients, which brings up the following issues: > > > > 1) Under some architecures, such as VoIP, fast failover > time from a > > primary to a backup application server is critical. With > the current > > protocol, the backup server would have to go to the KDC > and get user-to-user > > tickets for all of the clients with which it needs to > establish IPSec SAs. > > This adds to the recovery time and adds additional > performance/reliability > > requirements to the KDC. The number of clients per server > can be large - > > 100,000 clients / Call Server is possible in the > PacketCable architecture. > > > > It is possible for the server to save user-to-user tickets and > > corresponding session keys into some shared database, > which is undesirable > > in terms of complexity as well as security. > > > > 2) Load balancing between multiple Call Servers is > sometimes used in > > the VoIP architecture - support for it is mandatory in the > PacketCable > > standard. The user-to-user tickets again either add to > the rekeying time > > (which delays the switch-over time for a client between > servers) or adds the > > complication of a shared database of user-to-user tickets. > > > > 3) A standard Kerberized server that doesn't support the > > user-to-user tickets is a lot simpler to implement. It > would implement a > > very small percentage of the Kerberos protocol - just the AP Req/AP > > Rep/KRB-ERROR messages. With the user-to-user mode, the > server needs the > > complete Kerberos client implementation and in addition > may need to support > > a very large ticket cache for user-to-user tickets. > > > > 4) Setting per-user policy is awkward for user-to-user requests. > > Normally, the user policy is associated with the client, > but in this case > > the client is the server. Kerberos allows a user to pass > authorization data > > in a TGS Request (which may be insecure, depending on the > content of that > > authorization data), which would not be possible if it is > the server getting > > a ticket for the client. > > > > 5) Setting per-user policy in a cross-realm case is even more > > awkward. The server's GetTGT request would most likely > contain the server's > > realm name (as the server may not know the client's > realm). This means that > > the response to the GetTGT will contain a cross-realm TGT > for the client. > > So, the server's KDC will wind up issuing a server a > user-to-user ticket for > > a client principal that is not even in that KDC's realm. > > > > There are alternative methods for handling PKINIT clients > that address most > > of the above issues. What I propose, is the following > modification to the > > protocol. The GetTGT message flow in section 4.2 can be > replaced with the > > following: > > > > A > > B > > ------ > > ------ > > 1 AuthenticateRequest+ServerPrincipalName---------------> > > > > 2 > <------------------------------------AuthenticateReply+AP_REQ > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > > > In the above flows, there needs to be a way to tie flows 2 > and 3 together - > > for example the client timestamp inside AP_REQ can be > repeated in flow 3. > > In addition, there is already an XID in the header for > this key management > > session. (It is also possible to include the AP_REP in flow 3.) > > > > In the above flows, the AuthenticateRequest is not > authenticated, just like > > the GetTGT message. There is the denial of service > argument against the > > above flow since anyone can send the AuthenticateRequest. > If C impersonates > > A and sends the AuthenticateRequest, B will have to reply, > but A will reject > > the reply because the XID (session ID in the header) will > not match anything > > that A sent out. The denial of service arguments are: > > > > a) denial of service on the KDC - B may need to get a > ticket for A > > if it doesn't have it already. But, even if KDC receives > an invalid > > TGS_REQ, it still has to decrypt it to see that it is > invalid. I don't > > think that the extra work of issuing a ticket is a major > problem. Also, > > clients should cache the tickets, and the number of > servers in the KDC > > database is probably not that big. Also, the clients > should excersize > > access control and know ahead of time which servers they > should be talking > > to. > > > > b) denial of service on the clients - this is similar > to (a), except > > that the client's ticket cache is filled up. This is > really the same case > > as (a), because when the client's ticket cache is filled > up it can remove > > one of the entries. It just means that if the client gets > a request that > > needs the removed ticket, the client will request it from > the KDC again. > > > > Also, with the current KINK protocol, similar denial of > service attacks are > > possible. In that protocol, the GetTGT message only > specifies the realm. > > If the server doesn't know the client's name, it might get > the wrong client > > TGT and get a user-to-user ticket for a wrong client. If > the server then > > finds out that the resulting user-to-user ticket is not > accepted by the > > legitimate client, it will probably retry with another > GetTGT message that > > could also result in a wrong TGT (inserted by an > adversary) and then a wrong > > user-to-user ticket, ... > > > From owner-ietf-kink Fri Nov 3 12:17:35 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16744 for ietf-kink-bks; Fri, 3 Nov 2000 12:17:35 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16739 for ; Fri, 3 Nov 2000 12:17:33 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA16576; Fri, 3 Nov 2000 12:23:34 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA01991; Fri, 3 Nov 2000 12:23:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14851.7878.201034.633996@thomasm-u1.cisco.com> Date: Fri, 3 Nov 2000 12:23:34 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD4809@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD4809@ntas0027.gi.com> 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: Medvinsky, Sasha (SD-EX) writes: > As per my previous email, I listed what I consider to be problems associated > with a server obtaining tickets for a large number of its clients. While I > would support a change to PKINIT that allows automatic generation of client > keys that are saved in the KDC database, I don't believe that it addresses > this issue. It would either eliminate or mitigate the need for U-U. The only other argument I see is the potential need for a server to get tickets for the clients in a failover situations, etc. IPsec keying is fundamentally a peer to peer protocol. In my opinion adding a mode which is vulnerable to DoS attacks (and worse, third party DoS attacks) to preserve a client server architecture is not a worthwhile tradeoff to save what amounts to disk space for a large ticket cache. Also: a server only needs to obtain tickets for clients if there does not exist an SA *and* it has a reason to talk to the client. Until then, the non-existence of the SA is not hurting much more than a possible extra round trip or two in exceptional conditions, assuming that the client does not key the SA itself. Mike > > Sasha. > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, November 03, 2000 11:45 AM > > To: Medvinsky, Sasha (SD-EX) > > Cc: 'ietf-kink@vpnc.org' > > Subject: alternative to user-to-user Kerberos in KINK > > > > > > > > After talking to Matt Hur about this and thinking > > about this for a long time, I think the better > > part of valor here may, in fact, be avoidance. > > > > Taking a giant step backward, the root of all of > > the trouble here is that KINK is, in fact, a peer > > to peer protocol where PKinit expects a client > > server relationship. The main problem is that > > PKinit authenticated clients do not share a > > symmetric key at the KDC so the KDC cannot issue a > > service ticket directly thus bringing on the > > issues related to user-user mode. If the PKinit > > client did share a key with the KDC, the KINK peer > > would just obtain a normal service ticket and that > > would be that. > > > > Therefore, I think that I agree with Matt's > > contention that a much better strategy for use of > > PKinit would be to use PKinit as an enrollment > > strategy into a kerberos realm rather than an > > authentication strategy, per se. Ie, a client > > authenticates to the KDC using a cert but the KDC > > then enrolls it with a symmetric key and saves > > that key in its principal database. I haven't > > looked at this exhaustively, but I think that this > > strategy could be implemented using either no or > > minimal changes to PKinit -- the obvious thing to > > do is use the session key from the TGT from the > > PKinit AS-REQ as the symmetric key. > > > > My proposal is that we deal with this problem as a > > PKinit issue rather than a KINK issue because this > > is a generic problem with PKinit -- KINK is just > > the first to stumble upon the implications of > > using PKinit in a peer to peer application. The > > advantage here is that we could avoid *all* > > unauthenticated requests which from a DoS > > standpoint seems like a much better idea. > > > > Mike > > > > Medvinsky, Sasha (SD-EX) writes: > > > The user-to-user Kerberos mode in KINK is intended to > > address the situation > > > with PKINIT clients that do not have symmetric client keys > > registered with > > > the KDC and therefore a Kerberized server cannot get a > > standard ticket for > > > such a client. But the server still has to obtain > > user-to-user tickets for > > > clients, which brings up the following issues: > > > > > > 1) Under some architecures, such as VoIP, fast failover > > time from a > > > primary to a backup application server is critical. With > > the current > > > protocol, the backup server would have to go to the KDC > > and get user-to-user > > > tickets for all of the clients with which it needs to > > establish IPSec SAs. > > > This adds to the recovery time and adds additional > > performance/reliability > > > requirements to the KDC. The number of clients per server > > can be large - > > > 100,000 clients / Call Server is possible in the > > PacketCable architecture. > > > > > > It is possible for the server to save user-to-user tickets and > > > corresponding session keys into some shared database, > > which is undesirable > > > in terms of complexity as well as security. > > > > > > 2) Load balancing between multiple Call Servers is > > sometimes used in > > > the VoIP architecture - support for it is mandatory in the > > PacketCable > > > standard. The user-to-user tickets again either add to > > the rekeying time > > > (which delays the switch-over time for a client between > > servers) or adds the > > > complication of a shared database of user-to-user tickets. > > > > > > 3) A standard Kerberized server that doesn't support the > > > user-to-user tickets is a lot simpler to implement. It > > would implement a > > > very small percentage of the Kerberos protocol - just the AP Req/AP > > > Rep/KRB-ERROR messages. With the user-to-user mode, the > > server needs the > > > complete Kerberos client implementation and in addition > > may need to support > > > a very large ticket cache for user-to-user tickets. > > > > > > 4) Setting per-user policy is awkward for user-to-user requests. > > > Normally, the user policy is associated with the client, > > but in this case > > > the client is the server. Kerberos allows a user to pass > > authorization data > > > in a TGS Request (which may be insecure, depending on the > > content of that > > > authorization data), which would not be possible if it is > > the server getting > > > a ticket for the client. > > > > > > 5) Setting per-user policy in a cross-realm case is even more > > > awkward. The server's GetTGT request would most likely > > contain the server's > > > realm name (as the server may not know the client's > > realm). This means that > > > the response to the GetTGT will contain a cross-realm TGT > > for the client. > > > So, the server's KDC will wind up issuing a server a > > user-to-user ticket for > > > a client principal that is not even in that KDC's realm. > > > > > > There are alternative methods for handling PKINIT clients > > that address most > > > of the above issues. What I propose, is the following > > modification to the > > > protocol. The GetTGT message flow in section 4.2 can be > > replaced with the > > > following: > > > > > > A > > > B > > > ------ > > > ------ > > > 1 AuthenticateRequest+ServerPrincipalName---------------> > > > > > > 2 > > <------------------------------------AuthenticateReply+AP_REQ > > > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > > > > > In the above flows, there needs to be a way to tie flows 2 > > and 3 together - > > > for example the client timestamp inside AP_REQ can be > > repeated in flow 3. > > > In addition, there is already an XID in the header for > > this key management > > > session. (It is also possible to include the AP_REP in flow 3.) > > > > > > In the above flows, the AuthenticateRequest is not > > authenticated, just like > > > the GetTGT message. There is the denial of service > > argument against the > > > above flow since anyone can send the AuthenticateRequest. > > If C impersonates > > > A and sends the AuthenticateRequest, B will have to reply, > > but A will reject > > > the reply because the XID (session ID in the header) will > > not match anything > > > that A sent out. The denial of service arguments are: > > > > > > a) denial of service on the KDC - B may need to get a > > ticket for A > > > if it doesn't have it already. But, even if KDC receives > > an invalid > > > TGS_REQ, it still has to decrypt it to see that it is > > invalid. I don't > > > think that the extra work of issuing a ticket is a major > > problem. Also, > > > clients should cache the tickets, and the number of > > servers in the KDC > > > database is probably not that big. Also, the clients > > should excersize > > > access control and know ahead of time which servers they > > should be talking > > > to. > > > > > > b) denial of service on the clients - this is similar > > to (a), except > > > that the client's ticket cache is filled up. This is > > really the same case > > > as (a), because when the client's ticket cache is filled > > up it can remove > > > one of the entries. It just means that if the client gets > > a request that > > > needs the removed ticket, the client will request it from > > the KDC again. > > > > > > Also, with the current KINK protocol, similar denial of > > service attacks are > > > possible. In that protocol, the GetTGT message only > > specifies the realm. > > > If the server doesn't know the client's name, it might get > > the wrong client > > > TGT and get a user-to-user ticket for a wrong client. If > > the server then > > > finds out that the resulting user-to-user ticket is not > > accepted by the > > > legitimate client, it will probably retry with another > > GetTGT message that > > > could also result in a wrong TGT (inserted by an > > adversary) and then a wrong > > > user-to-user ticket, ... > > > > > > From owner-ietf-kink Fri Nov 3 13:26:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA18336 for ietf-kink-bks; Fri, 3 Nov 2000 13:26:17 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18332 for ; Fri, 3 Nov 2000 13:26:16 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA11623; Fri, 3 Nov 2000 13:26:56 -0800 (PST) Date: Fri, 3 Nov 2000 13:26:43 -0800 (PST) From: Jan Vilhuber To: Michael Thomas cc: "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <14851.5550.610343.923802@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This sounds like an excellent avenue to pursue. jan On Fri, 3 Nov 2000, Michael Thomas wrote: > > After talking to Matt Hur about this and thinking > about this for a long time, I think the better > part of valor here may, in fact, be avoidance. > > Taking a giant step backward, the root of all of > the trouble here is that KINK is, in fact, a peer > to peer protocol where PKinit expects a client > server relationship. The main problem is that > PKinit authenticated clients do not share a > symmetric key at the KDC so the KDC cannot issue a > service ticket directly thus bringing on the > issues related to user-user mode. If the PKinit > client did share a key with the KDC, the KINK peer > would just obtain a normal service ticket and that > would be that. > > Therefore, I think that I agree with Matt's > contention that a much better strategy for use of > PKinit would be to use PKinit as an enrollment > strategy into a kerberos realm rather than an > authentication strategy, per se. Ie, a client > authenticates to the KDC using a cert but the KDC > then enrolls it with a symmetric key and saves > that key in its principal database. I haven't > looked at this exhaustively, but I think that this > strategy could be implemented using either no or > minimal changes to PKinit -- the obvious thing to > do is use the session key from the TGT from the > PKinit AS-REQ as the symmetric key. > > My proposal is that we deal with this problem as a > PKinit issue rather than a KINK issue because this > is a generic problem with PKinit -- KINK is just > the first to stumble upon the implications of > using PKinit in a peer to peer application. The > advantage here is that we could avoid *all* > unauthenticated requests which from a DoS > standpoint seems like a much better idea. > > Mike > > Medvinsky, Sasha (SD-EX) writes: > > The user-to-user Kerberos mode in KINK is intended to address the situation > > with PKINIT clients that do not have symmetric client keys registered with > > the KDC and therefore a Kerberized server cannot get a standard ticket for > > such a client. But the server still has to obtain user-to-user tickets for > > clients, which brings up the following issues: > > > > 1) Under some architecures, such as VoIP, fast failover time from a > > primary to a backup application server is critical. With the current > > protocol, the backup server would have to go to the KDC and get user-to-user > > tickets for all of the clients with which it needs to establish IPSec SAs. > > This adds to the recovery time and adds additional performance/reliability > > requirements to the KDC. The number of clients per server can be large - > > 100,000 clients / Call Server is possible in the PacketCable architecture. > > > > It is possible for the server to save user-to-user tickets and > > corresponding session keys into some shared database, which is undesirable > > in terms of complexity as well as security. > > > > 2) Load balancing between multiple Call Servers is sometimes used in > > the VoIP architecture - support for it is mandatory in the PacketCable > > standard. The user-to-user tickets again either add to the rekeying time > > (which delays the switch-over time for a client between servers) or adds the > > complication of a shared database of user-to-user tickets. > > > > 3) A standard Kerberized server that doesn't support the > > user-to-user tickets is a lot simpler to implement. It would implement a > > very small percentage of the Kerberos protocol - just the AP Req/AP > > Rep/KRB-ERROR messages. With the user-to-user mode, the server needs the > > complete Kerberos client implementation and in addition may need to support > > a very large ticket cache for user-to-user tickets. > > > > 4) Setting per-user policy is awkward for user-to-user requests. > > Normally, the user policy is associated with the client, but in this case > > the client is the server. Kerberos allows a user to pass authorization data > > in a TGS Request (which may be insecure, depending on the content of that > > authorization data), which would not be possible if it is the server getting > > a ticket for the client. > > > > 5) Setting per-user policy in a cross-realm case is even more > > awkward. The server's GetTGT request would most likely contain the server's > > realm name (as the server may not know the client's realm). This means that > > the response to the GetTGT will contain a cross-realm TGT for the client. > > So, the server's KDC will wind up issuing a server a user-to-user ticket for > > a client principal that is not even in that KDC's realm. > > > > There are alternative methods for handling PKINIT clients that address most > > of the above issues. What I propose, is the following modification to the > > protocol. The GetTGT message flow in section 4.2 can be replaced with the > > following: > > > > A > > B > > ------ > > ------ > > 1 AuthenticateRequest+ServerPrincipalName---------------> > > > > 2 <------------------------------------AuthenticateReply+AP_REQ > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > > > In the above flows, there needs to be a way to tie flows 2 and 3 together - > > for example the client timestamp inside AP_REQ can be repeated in flow 3. > > In addition, there is already an XID in the header for this key management > > session. (It is also possible to include the AP_REP in flow 3.) > > > > In the above flows, the AuthenticateRequest is not authenticated, just like > > the GetTGT message. There is the denial of service argument against the > > above flow since anyone can send the AuthenticateRequest. If C impersonates > > A and sends the AuthenticateRequest, B will have to reply, but A will reject > > the reply because the XID (session ID in the header) will not match anything > > that A sent out. The denial of service arguments are: > > > > a) denial of service on the KDC - B may need to get a ticket for A > > if it doesn't have it already. But, even if KDC receives an invalid > > TGS_REQ, it still has to decrypt it to see that it is invalid. I don't > > think that the extra work of issuing a ticket is a major problem. Also, > > clients should cache the tickets, and the number of servers in the KDC > > database is probably not that big. Also, the clients should excersize > > access control and know ahead of time which servers they should be talking > > to. > > > > b) denial of service on the clients - this is similar to (a), except > > that the client's ticket cache is filled up. This is really the same case > > as (a), because when the client's ticket cache is filled up it can remove > > one of the entries. It just means that if the client gets a request that > > needs the removed ticket, the client will request it from the KDC again. > > > > Also, with the current KINK protocol, similar denial of service attacks are > > possible. In that protocol, the GetTGT message only specifies the realm. > > If the server doesn't know the client's name, it might get the wrong client > > TGT and get a user-to-user ticket for a wrong client. If the server then > > finds out that the resulting user-to-user ticket is not accepted by the > > legitimate client, it will probably retry with another GetTGT message that > > could also result in a wrong TGT (inserted by an adversary) and then a wrong > > user-to-user ticket, ... > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Sat Nov 4 05:08:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA10978 for ietf-kink-bks; Sat, 4 Nov 2000 05:08:15 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10974 for ; Sat, 4 Nov 2000 05:08:14 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JW4OI62ASUEZGWWD@GI.COM> for ietf-kink@vpnc.org; Sat, 4 Nov 2000 05:14:11 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 03 Nov 2000 13:59:01 -0500 Content-return: allowed Date: Fri, 03 Nov 2000 17:02:01 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD480C@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, DoS attacks are always possible - it is just a matter of degree. As I described them in my previous email, I don't see those denial of service attacks as serious. A few roundtrips for a single connection is certainly no problem, when you have 100,000 of them to a single server in a real-time application, it is a real issue. The protocol will work either way, but I would not want to for example downgrade the scalability of PacketCable architecture by using your proposed approach. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, November 03, 2000 12:24 PM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > Medvinsky, Sasha (SD-EX) writes: > > As per my previous email, I listed what I consider to be > problems associated > > with a server obtaining tickets for a large number of its > clients. While I > > would support a change to PKINIT that allows automatic > generation of client > > keys that are saved in the KDC database, I don't believe > that it addresses > > this issue. > > It would either eliminate or mitigate the need for U-U. > > The only other argument I see is the potential need for > a server to get tickets for the clients in a failover > situations, etc. IPsec keying is fundamentally a peer > to peer protocol. In my opinion adding a mode > which is vulnerable to DoS attacks (and worse, > third party DoS attacks) to preserve a client > server architecture is not a worthwhile > tradeoff to save what amounts to disk space > for a large ticket cache. Also: a server only > needs to obtain tickets for clients if there > does not exist an SA *and* it has a reason to > talk to the client. Until then, the > non-existence of the SA is not hurting much > more than a possible extra round trip or two in > exceptional conditions, assuming that the > client does not key the SA itself. > > Mike > > > > > > > Sasha. > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Friday, November 03, 2000 11:45 AM > > > To: Medvinsky, Sasha (SD-EX) > > > Cc: 'ietf-kink@vpnc.org' > > > Subject: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > After talking to Matt Hur about this and thinking > > > about this for a long time, I think the better > > > part of valor here may, in fact, be avoidance. > > > > > > Taking a giant step backward, the root of all of > > > the trouble here is that KINK is, in fact, a peer > > > to peer protocol where PKinit expects a client > > > server relationship. The main problem is that > > > PKinit authenticated clients do not share a > > > symmetric key at the KDC so the KDC cannot issue a > > > service ticket directly thus bringing on the > > > issues related to user-user mode. If the PKinit > > > client did share a key with the KDC, the KINK peer > > > would just obtain a normal service ticket and that > > > would be that. > > > > > > Therefore, I think that I agree with Matt's > > > contention that a much better strategy for use of > > > PKinit would be to use PKinit as an enrollment > > > strategy into a kerberos realm rather than an > > > authentication strategy, per se. Ie, a client > > > authenticates to the KDC using a cert but the KDC > > > then enrolls it with a symmetric key and saves > > > that key in its principal database. I haven't > > > looked at this exhaustively, but I think that this > > > strategy could be implemented using either no or > > > minimal changes to PKinit -- the obvious thing to > > > do is use the session key from the TGT from the > > > PKinit AS-REQ as the symmetric key. > > > > > > My proposal is that we deal with this problem as a > > > PKinit issue rather than a KINK issue because this > > > is a generic problem with PKinit -- KINK is just > > > the first to stumble upon the implications of > > > using PKinit in a peer to peer application. The > > > advantage here is that we could avoid *all* > > > unauthenticated requests which from a DoS > > > standpoint seems like a much better idea. > > > > > > Mike > > > > > > Medvinsky, Sasha (SD-EX) writes: > > > > The user-to-user Kerberos mode in KINK is intended to > > > address the situation > > > > with PKINIT clients that do not have symmetric client keys > > > registered with > > > > the KDC and therefore a Kerberized server cannot get a > > > standard ticket for > > > > such a client. But the server still has to obtain > > > user-to-user tickets for > > > > clients, which brings up the following issues: > > > > > > > > 1) Under some architecures, such as VoIP, fast failover > > > time from a > > > > primary to a backup application server is critical. With > > > the current > > > > protocol, the backup server would have to go to the KDC > > > and get user-to-user > > > > tickets for all of the clients with which it needs to > > > establish IPSec SAs. > > > > This adds to the recovery time and adds additional > > > performance/reliability > > > > requirements to the KDC. The number of clients per server > > > can be large - > > > > 100,000 clients / Call Server is possible in the > > > PacketCable architecture. > > > > > > > > It is possible for the server to save > user-to-user tickets and > > > > corresponding session keys into some shared database, > > > which is undesirable > > > > in terms of complexity as well as security. > > > > > > > > 2) Load balancing between multiple Call Servers is > > > sometimes used in > > > > the VoIP architecture - support for it is mandatory in the > > > PacketCable > > > > standard. The user-to-user tickets again either add to > > > the rekeying time > > > > (which delays the switch-over time for a client between > > > servers) or adds the > > > > complication of a shared database of user-to-user tickets. > > > > > > > > 3) A standard Kerberized server that doesn't support the > > > > user-to-user tickets is a lot simpler to implement. It > > > would implement a > > > > very small percentage of the Kerberos protocol - just > the AP Req/AP > > > > Rep/KRB-ERROR messages. With the user-to-user mode, the > > > server needs the > > > > complete Kerberos client implementation and in addition > > > may need to support > > > > a very large ticket cache for user-to-user tickets. > > > > > > > > 4) Setting per-user policy is awkward for > user-to-user requests. > > > > Normally, the user policy is associated with the client, > > > but in this case > > > > the client is the server. Kerberos allows a user to pass > > > authorization data > > > > in a TGS Request (which may be insecure, depending on the > > > content of that > > > > authorization data), which would not be possible if it is > > > the server getting > > > > a ticket for the client. > > > > > > > > 5) Setting per-user policy in a cross-realm > case is even more > > > > awkward. The server's GetTGT request would most likely > > > contain the server's > > > > realm name (as the server may not know the client's > > > realm). This means that > > > > the response to the GetTGT will contain a cross-realm TGT > > > for the client. > > > > So, the server's KDC will wind up issuing a server a > > > user-to-user ticket for > > > > a client principal that is not even in that KDC's realm. > > > > > > > > There are alternative methods for handling PKINIT clients > > > that address most > > > > of the above issues. What I propose, is the following > > > modification to the > > > > protocol. The GetTGT message flow in section 4.2 can be > > > replaced with the > > > > following: > > > > > > > > A > > > > B > > > > ------ > > > > ------ > > > > 1 AuthenticateRequest+ServerPrincipalName---------------> > > > > > > > > 2 > > > <------------------------------------AuthenticateReply+AP_REQ > > > > > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > > > > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > > > > > > > In the above flows, there needs to be a way to tie flows 2 > > > and 3 together - > > > > for example the client timestamp inside AP_REQ can be > > > repeated in flow 3. > > > > In addition, there is already an XID in the header for > > > this key management > > > > session. (It is also possible to include the AP_REP > in flow 3.) > > > > > > > > In the above flows, the AuthenticateRequest is not > > > authenticated, just like > > > > the GetTGT message. There is the denial of service > > > argument against the > > > > above flow since anyone can send the AuthenticateRequest. > > > If C impersonates > > > > A and sends the AuthenticateRequest, B will have to reply, > > > but A will reject > > > > the reply because the XID (session ID in the header) will > > > not match anything > > > > that A sent out. The denial of service arguments are: > > > > > > > > a) denial of service on the KDC - B may need to get a > > > ticket for A > > > > if it doesn't have it already. But, even if KDC receives > > > an invalid > > > > TGS_REQ, it still has to decrypt it to see that it is > > > invalid. I don't > > > > think that the extra work of issuing a ticket is a major > > > problem. Also, > > > > clients should cache the tickets, and the number of > > > servers in the KDC > > > > database is probably not that big. Also, the clients > > > should excersize > > > > access control and know ahead of time which servers they > > > should be talking > > > > to. > > > > > > > > b) denial of service on the clients - this is similar > > > to (a), except > > > > that the client's ticket cache is filled up. This is > > > really the same case > > > > as (a), because when the client's ticket cache is filled > > > up it can remove > > > > one of the entries. It just means that if the client gets > > > a request that > > > > needs the removed ticket, the client will request it from > > > the KDC again. > > > > > > > > Also, with the current KINK protocol, similar denial of > > > service attacks are > > > > possible. In that protocol, the GetTGT message only > > > specifies the realm. > > > > If the server doesn't know the client's name, it might get > > > the wrong client > > > > TGT and get a user-to-user ticket for a wrong client. If > > > the server then > > > > finds out that the resulting user-to-user ticket is not > > > accepted by the > > > > legitimate client, it will probably retry with another > > > GetTGT message that > > > > could also result in a wrong TGT (inserted by an > > > adversary) and then a wrong > > > > user-to-user ticket, ... > > > > > > > > > > From owner-ietf-kink Sat Nov 4 11:11:50 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA02461 for ietf-kink-bks; Sat, 4 Nov 2000 11:11:50 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02457 for ; Sat, 4 Nov 2000 11:11:49 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA15751; Sat, 4 Nov 2000 11:17:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02252; Sat, 4 Nov 2000 11:17:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14852.24803.66583.708633@thomasm-u1.cisco.com> Date: Sat, 4 Nov 2000 11:17:55 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD480C@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD480C@ntas0027.gi.com> 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: Medvinsky, Sasha (SD-EX) writes: > DoS attacks are always possible - it is just a matter of degree. As I > described them in my previous email, I don't see those denial of service > attacks as serious. I would say that any scenario which explicitly allows for a third party DoS attack against a KDC is pretty suspect. With the wakeup method you propose, the attacker merely spoofs the address of the peer and attaches an appropriate number of bits to resemble a ticket. Computationally, this is trivial. However, the receiver would then have to create an TGS-REQ with the two tickets and send the request to the KDC. This is computationally expensive. The KDC would then have to decrypt the request and act on it which is computationally expensive. In the U-U scenario, the burden of creating the TGS-REQ lies on the attacker. The GetTGT response is not authenticated so it costs the receiver little. The cost at the KDC is the same. However, there is little profit in involving the U-U peer if the attacker doesn't already have a legitimate TGT: the attacker could just as easily have spoofed the entire U-U TGS-REQ to cause a direct DoS attack on the KDC. Also: the attack originates from its _source_ rather than an uninterested third party as in above. Thus the CPU burden scorecard is: U-U Wakeup attacker low low peer low high kdc high high And this does not take into account the harm of an attacker with a legitimate TGT flooding the ticket cache of a peer which is also not a problem with the U-U approach. > A few roundtrips for a single connection is certainly no problem, when you > have 100,000 of them to a single server in a real-time application, it is a > real issue. The protocol will work either way, but I would not want to for > example downgrade the scalability of PacketCable architecture by using your > proposed approach. There are other ways to deal with this which don't need to involve the protocol itself. I don't favor building in a zombie attack into the protocol when other options are viable. Mike > > Sasha. > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, November 03, 2000 12:24 PM > > To: Medvinsky, Sasha (SD-EX) > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > > > Medvinsky, Sasha (SD-EX) writes: > > > As per my previous email, I listed what I consider to be > > problems associated > > > with a server obtaining tickets for a large number of its > > clients. While I > > > would support a change to PKINIT that allows automatic > > generation of client > > > keys that are saved in the KDC database, I don't believe > > that it addresses > > > this issue. > > > > It would either eliminate or mitigate the need for U-U. > > > > The only other argument I see is the potential need for > > a server to get tickets for the clients in a failover > > situations, etc. IPsec keying is fundamentally a peer > > to peer protocol. In my opinion adding a mode > > which is vulnerable to DoS attacks (and worse, > > third party DoS attacks) to preserve a client > > server architecture is not a worthwhile > > tradeoff to save what amounts to disk space > > for a large ticket cache. Also: a server only > > needs to obtain tickets for clients if there > > does not exist an SA *and* it has a reason to > > talk to the client. Until then, the > > non-existence of the SA is not hurting much > > more than a possible extra round trip or two in > > exceptional conditions, assuming that the > > client does not key the SA itself. > > > > Mike > > > > > > > > > > > > Sasha. > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Friday, November 03, 2000 11:45 AM > > > > To: Medvinsky, Sasha (SD-EX) > > > > Cc: 'ietf-kink@vpnc.org' > > > > Subject: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > > > > > After talking to Matt Hur about this and thinking > > > > about this for a long time, I think the better > > > > part of valor here may, in fact, be avoidance. > > > > > > > > Taking a giant step backward, the root of all of > > > > the trouble here is that KINK is, in fact, a peer > > > > to peer protocol where PKinit expects a client > > > > server relationship. The main problem is that > > > > PKinit authenticated clients do not share a > > > > symmetric key at the KDC so the KDC cannot issue a > > > > service ticket directly thus bringing on the > > > > issues related to user-user mode. If the PKinit > > > > client did share a key with the KDC, the KINK peer > > > > would just obtain a normal service ticket and that > > > > would be that. > > > > > > > > Therefore, I think that I agree with Matt's > > > > contention that a much better strategy for use of > > > > PKinit would be to use PKinit as an enrollment > > > > strategy into a kerberos realm rather than an > > > > authentication strategy, per se. Ie, a client > > > > authenticates to the KDC using a cert but the KDC > > > > then enrolls it with a symmetric key and saves > > > > that key in its principal database. I haven't > > > > looked at this exhaustively, but I think that this > > > > strategy could be implemented using either no or > > > > minimal changes to PKinit -- the obvious thing to > > > > do is use the session key from the TGT from the > > > > PKinit AS-REQ as the symmetric key. > > > > > > > > My proposal is that we deal with this problem as a > > > > PKinit issue rather than a KINK issue because this > > > > is a generic problem with PKinit -- KINK is just > > > > the first to stumble upon the implications of > > > > using PKinit in a peer to peer application. The > > > > advantage here is that we could avoid *all* > > > > unauthenticated requests which from a DoS > > > > standpoint seems like a much better idea. > > > > > > > > Mike > > > > > > > > Medvinsky, Sasha (SD-EX) writes: > > > > > The user-to-user Kerberos mode in KINK is intended to > > > > address the situation > > > > > with PKINIT clients that do not have symmetric client keys > > > > registered with > > > > > the KDC and therefore a Kerberized server cannot get a > > > > standard ticket for > > > > > such a client. But the server still has to obtain > > > > user-to-user tickets for > > > > > clients, which brings up the following issues: > > > > > > > > > > 1) Under some architecures, such as VoIP, fast failover > > > > time from a > > > > > primary to a backup application server is critical. With > > > > the current > > > > > protocol, the backup server would have to go to the KDC > > > > and get user-to-user > > > > > tickets for all of the clients with which it needs to > > > > establish IPSec SAs. > > > > > This adds to the recovery time and adds additional > > > > performance/reliability > > > > > requirements to the KDC. The number of clients per server > > > > can be large - > > > > > 100,000 clients / Call Server is possible in the > > > > PacketCable architecture. > > > > > > > > > > It is possible for the server to save > > user-to-user tickets and > > > > > corresponding session keys into some shared database, > > > > which is undesirable > > > > > in terms of complexity as well as security. > > > > > > > > > > 2) Load balancing between multiple Call Servers is > > > > sometimes used in > > > > > the VoIP architecture - support for it is mandatory in the > > > > PacketCable > > > > > standard. The user-to-user tickets again either add to > > > > the rekeying time > > > > > (which delays the switch-over time for a client between > > > > servers) or adds the > > > > > complication of a shared database of user-to-user tickets. > > > > > > > > > > 3) A standard Kerberized server that doesn't support the > > > > > user-to-user tickets is a lot simpler to implement. It > > > > would implement a > > > > > very small percentage of the Kerberos protocol - just > > the AP Req/AP > > > > > Rep/KRB-ERROR messages. With the user-to-user mode, the > > > > server needs the > > > > > complete Kerberos client implementation and in addition > > > > may need to support > > > > > a very large ticket cache for user-to-user tickets. > > > > > > > > > > 4) Setting per-user policy is awkward for > > user-to-user requests. > > > > > Normally, the user policy is associated with the client, > > > > but in this case > > > > > the client is the server. Kerberos allows a user to pass > > > > authorization data > > > > > in a TGS Request (which may be insecure, depending on the > > > > content of that > > > > > authorization data), which would not be possible if it is > > > > the server getting > > > > > a ticket for the client. > > > > > > > > > > 5) Setting per-user policy in a cross-realm > > case is even more > > > > > awkward. The server's GetTGT request would most likely > > > > contain the server's > > > > > realm name (as the server may not know the client's > > > > realm). This means that > > > > > the response to the GetTGT will contain a cross-realm TGT > > > > for the client. > > > > > So, the server's KDC will wind up issuing a server a > > > > user-to-user ticket for > > > > > a client principal that is not even in that KDC's realm. > > > > > > > > > > There are alternative methods for handling PKINIT clients > > > > that address most > > > > > of the above issues. What I propose, is the following > > > > modification to the > > > > > protocol. The GetTGT message flow in section 4.2 can be > > > > replaced with the > > > > > following: > > > > > > > > > > A > > > > > B > > > > > ------ > > > > > ------ > > > > > 1 AuthenticateRequest+ServerPrincipalName---------------> > > > > > > > > > > 2 > > > > <------------------------------------AuthenticateReply+AP_REQ > > > > > > > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > > > > > > > 4 <------------REPLY+ISAKMP(keyed cksum with sess key) > > > > > > > > > > In the above flows, there needs to be a way to tie flows 2 > > > > and 3 together - > > > > > for example the client timestamp inside AP_REQ can be > > > > repeated in flow 3. > > > > > In addition, there is already an XID in the header for > > > > this key management > > > > > session. (It is also possible to include the AP_REP > > in flow 3.) > > > > > > > > > > In the above flows, the AuthenticateRequest is not > > > > authenticated, just like > > > > > the GetTGT message. There is the denial of service > > > > argument against the > > > > > above flow since anyone can send the AuthenticateRequest. > > > > If C impersonates > > > > > A and sends the AuthenticateRequest, B will have to reply, > > > > but A will reject > > > > > the reply because the XID (session ID in the header) will > > > > not match anything > > > > > that A sent out. The denial of service arguments are: > > > > > > > > > > a) denial of service on the KDC - B may need to get a > > > > ticket for A > > > > > if it doesn't have it already. But, even if KDC receives > > > > an invalid > > > > > TGS_REQ, it still has to decrypt it to see that it is > > > > invalid. I don't > > > > > think that the extra work of issuing a ticket is a major > > > > problem. Also, > > > > > clients should cache the tickets, and the number of > > > > servers in the KDC > > > > > database is probably not that big. Also, the clients > > > > should excersize > > > > > access control and know ahead of time which servers they > > > > should be talking > > > > > to. > > > > > > > > > > b) denial of service on the clients - this is similar > > > > to (a), except > > > > > that the client's ticket cache is filled up. This is > > > > really the same case > > > > > as (a), because when the client's ticket cache is filled > > > > up it can remove > > > > > one of the entries. It just means that if the client gets > > > > a request that > > > > > needs the removed ticket, the client will request it from > > > > the KDC again. > > > > > > > > > > Also, with the current KINK protocol, similar denial of > > > > service attacks are > > > > > possible. In that protocol, the GetTGT message only > > > > specifies the realm. > > > > > If the server doesn't know the client's name, it might get > > > > the wrong client > > > > > TGT and get a user-to-user ticket for a wrong client. If > > > > the server then > > > > > finds out that the resulting user-to-user ticket is not > > > > accepted by the > > > > > legitimate client, it will probably retry with another > > > > GetTGT message that > > > > > could also result in a wrong TGT (inserted by an > > > > adversary) and then a wrong > > > > > user-to-user ticket, ... > > > > > > > > > > > > > > > From owner-ietf-kink Thu Nov 9 12:38:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00674 for ietf-kink-bks; Thu, 9 Nov 2000 12:38:28 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00661 for ; Thu, 9 Nov 2000 12:38:24 -0800 (PST) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA26181 for ; Thu, 9 Nov 2000 12:45:12 -0800 (PST) Received: from mhur-w2k1.cisco.com (sjc-vpn-66.cisco.com [10.21.64.66]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAB02222; Thu, 9 Nov 2000 12:45:08 -0800 (PST) Message-Id: <4.3.2.7.2.20001109124546.00b54c18@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 12:46:59 -0800 To: ietf-kink@vpnc.org From: Matthew Hur Subject: meeting agenda? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Do we have a meeting slot and agenda yet for the San Diego IETF? Mike, were you going to run through an overview and open issues for the protocol draft? --Matt From owner-ietf-kink Thu Nov 9 13:01:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01554 for ietf-kink-bks; Thu, 9 Nov 2000 13:01:50 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA01550 for ; Thu, 9 Nov 2000 13:01:47 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA09849; Thu, 9 Nov 00 16:08:15 EST Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id QAA02127; Thu, 9 Nov 2000 16:08:39 -0500 (EST) Received: from indiana.mit.edu (INDIANA.MIT.EDU [18.18.1.138]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id QAA16806; Thu, 9 Nov 2000 16:08:35 -0500 (EST) Received: (from warlord@localhost) by indiana.mit.edu (8.9.3) id QAA05076; Thu, 9 Nov 2000 16:08:34 -0500 (EST) To: Matthew Hur Cc: ietf-kink@vpnc.org Subject: Re: meeting agenda? References: <4.3.2.7.2.20001109124546.00b54c18@mira-sjc5-5.cisco.com> From: Derek Atkins Date: 09 Nov 2000 16:08:34 -0500 In-Reply-To: Matthew Hur's message of "Thu, 09 Nov 2000 12:46:59 -0800" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We currently have a 1 hour slot on Tuesday, however we do not, yet, have an agenda, as nobody has said they have anything to say :) So, if you want to speak in San Diego, let me know. Soon. If we need more than an hour, I need to let the Secretariat know by next week. -derek Matthew Hur writes: > Do we have a meeting slot and agenda yet for the San Diego IETF? > > Mike, were you going to run through an overview and open issues for the > protocol draft? > > --Matt > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Nov 9 13:22:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01903 for ietf-kink-bks; Thu, 9 Nov 2000 13:22:19 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01898 for ; Thu, 9 Nov 2000 13:22:16 -0800 (PST) Received: from grand-central-station.MIT.EDU (GRAND-CENTRAL-STATION.MIT.EDU [18.69.0.34]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA01903 for ; Thu, 9 Nov 2000 16:29:02 -0500 (EST) Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id QAA08879 for ; Thu, 9 Nov 2000 16:29:01 -0500 (EST) Received: from indiana.mit.edu (INDIANA.MIT.EDU [18.18.1.138]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id QAA24189 for ; Thu, 9 Nov 2000 16:29:01 -0500 (EST) Received: (from warlord@localhost) by indiana.mit.edu (8.9.3) id QAA05109; Thu, 9 Nov 2000 16:29:01 -0500 (EST) To: ietf-kink@vpnc.org Subject: San Diego Agenda: Call for speakers From: Derek Atkins Date: 09 Nov 2000 16:29:00 -0500 Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'm currently working on a draft agenda for San Diego. According to the IETF Agenda, we have Tuesday afternoon, 1300-1400. Obviously that is subject to change. My goals for San Diego: finalize the requirements document and issue a last call discuss the draft protocol As I mentioned in a previous mail, if you want to speak in San Diego, let me know SOON. If you don't warn me by mid week next week, then you may not get a chance to speak. So, let me know sooner (rather than later) Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Fri Nov 10 12:42:11 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04115 for ietf-kink-bks; Fri, 10 Nov 2000 12:42:11 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04110 for ; Fri, 10 Nov 2000 12:42:09 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWDJ8GH22IEZM1VM@GI.COM> for ietf-kink@vpnc.org; Fri, 10 Nov 2000 12:48:39 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 12:47:38 -0500 Content-return: allowed Date: Fri, 10 Nov 2000 15:50:40 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Ken Hornstein'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4857@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ken, This includes both AS_REQ and TGS_REQ. In my proposal, a Kerberized server would not have to generate either. The key management protocol between the IPSec peers is not Kerberos anyway - it just utilizes Kerberos objects for authentication. Sasha. > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Tuesday, October 31, 2000 3:01 PM > To: 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > 3) A standard Kerberized server that doesn't support the > >user-to-user tickets is a lot simpler to implement. > > If you don't handle a TGS_REQ, I don't think you could call > it "Kerberos"; > and from looking at a sample KDC, I don't think a TGS_REQ > really adds that > much complexity (compared to how much else you have to implement to > do Kerberos). > > --Ken > From owner-ietf-kink Mon Nov 13 08:21:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04859 for ietf-kink-bks; Mon, 13 Nov 2000 08:21:04 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04855 for ; Mon, 13 Nov 2000 08:21:03 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id eADGRxH03274; Mon, 13 Nov 2000 11:28:00 -0500 (EST) Message-Id: <200011131628.eADGRxH03274@ginger.cmf.nrl.navy.mil> To: "Medvinsky, Sasha (SD-EX)" cc: "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Fri, 10 Nov 2000 15:50:40 EST." <97DEDE66B3DCD11199D200805FA71BE202FD4857@ntas0027.gi.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: Mon, 13 Nov 2000 11:27:59 -0500 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >This includes both AS_REQ and TGS_REQ. In my proposal, a Kerberized server >would not have to generate either. The key management protocol between the >IPSec peers is not Kerberos anyway - it just utilizes Kerberos objects for >authentication. I understand that, but one of your justifications is that it's easier to develop a KDC that doesn't have to implement U2U tickets. My point is: a) I'm not convinced it's significantly easier b) Such a KDC couldn't claim to implement the Kerberos protocol So I don't think this is a very good argument. --Ken From owner-ietf-kink Mon Nov 13 10:25:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12759 for ietf-kink-bks; Mon, 13 Nov 2000 10:25:37 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12753 for ; Mon, 13 Nov 2000 10:25:36 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWHLCERKO2EZNSTN@GI.COM> for ietf-kink@vpnc.org; Mon, 13 Nov 2000 10:32:16 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 10:31:13 -0500 Content-return: allowed Date: Mon, 13 Nov 2000 13:34:29 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Ken Hornstein'" Cc: "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4869@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ken, I am sorry if my email was confusing in that regard - I probably said that it is easier to implement a "server", which definitely did not mean the KDC. I agree that what I proposed has no effect on the development of the KDC. I would say that a general-purpose KDC should implement U2U regardless. I was talking about a Kerberized service, not a KDC. This is a Kerberized service that accepts AP Requests and responds with AP Replies. I was proposing that a Kerberized service is able to initiate Kerberized key management without the need to obtain (U2U) tickets for its clients. Sasha. > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, November 13, 2000 8:28 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > >This includes both AS_REQ and TGS_REQ. In my proposal, a > Kerberized server > >would not have to generate either. The key management > protocol between the > >IPSec peers is not Kerberos anyway - it just utilizes > Kerberos objects for > >authentication. > > I understand that, but one of your justifications is that it's easier > to develop a KDC that doesn't have to implement U2U tickets. My point > is: > > a) I'm not convinced it's significantly easier > b) Such a KDC couldn't claim to implement the Kerberos protocol > > So I don't think this is a very good argument. > > --Ken > From owner-ietf-kink Mon Nov 13 12:15:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA18479 for ietf-kink-bks; Mon, 13 Nov 2000 12:15:44 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18475 for ; Mon, 13 Nov 2000 12:15:42 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id eADKMnH05309; Mon, 13 Nov 2000 15:22:49 -0500 (EST) Message-Id: <200011132022.eADKMnH05309@ginger.cmf.nrl.navy.mil> To: "Medvinsky, Sasha (SD-EX)" cc: "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 13 Nov 2000 13:34:29 EST." <97DEDE66B3DCD11199D200805FA71BE202FD4869@ntas0027.gi.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: Mon, 13 Nov 2000 15:22:48 -0500 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >I was talking about a Kerberized service, not a KDC. This is a Kerberized >service that accepts AP Requests and responds with AP Replies. I was >proposing that a Kerberized service is able to initiate Kerberized key >management without the need to obtain (U2U) tickets for its clients. Ah, okay, I understand now. FWIW, I prefer the term "application servers" to minimize confusion between the KDC and other servers. --Ken From owner-ietf-kink Tue Nov 14 12:06:06 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16286 for ietf-kink-bks; Tue, 14 Nov 2000 12:06:06 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16281 for ; Tue, 14 Nov 2000 12:06:04 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWJ35MLQTUEZP7TD@GI.COM> for ietf-kink@vpnc.org; Tue, 14 Nov 2000 12:12:58 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 12:11:56 -0500 Content-return: allowed Date: Tue, 14 Nov 2000 15:15:12 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4887@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, My replies are below. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Saturday, November 04, 2000 11:18 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > Medvinsky, Sasha (SD-EX) writes: > > DoS attacks are always possible - it is just a matter of > degree. As I > > described them in my previous email, I don't see those > denial of service > > attacks as serious. > > I would say that any scenario which explicitly allows for > a third party DoS attack against a KDC is pretty suspect. > With the wakeup method you propose, the attacker merely > spoofs the address of the peer and attaches an appropriate > number of bits to resemble a ticket. Computationally, this > is trivial. However, the receiver would then have to > create an TGS-REQ with the two tickets and send the > request to the KDC. This is computationally expensive. [sasha] I was not proposing the U2U mode - there is only one ticket in the TGS-REQ. Regardless, symmetric key encryption is not that expensive, not any more expensive than say sending out IP packets protected with IPSec ESP. Also, consider just receiving a bad AP Request - it has to be decrypted and validated (or invalidated). That is the same amount of work. And, if the client already has a ticket for that server - it won't send out a TGS-REQ. Also, the client should really have an Access Control List of the servers it wants to talk to and would not normally respond to a request from a server it doesn't know about. Even if a client did respond to any such server - the KDC has only a limited number of them in its database. > The KDC would then have to decrypt the request and > act on it which is computationally expensive. [sasha] Decrypting a valid TGS-REQ is not any more expensive than decrypting and invalidating a bogus TGS-REQ that anyone can send out. Genetating a reply for a valid request would triple the cryptographic work done by the KDC (it has to encrypt the ticket and TGS-REP). However, since clients cache tickets and should have an ACL of servers, it is a lot easier to overwhelm the KDC by just sending it bad AS-REQ messages with PKINIT, forcing the KDC to perform digital signature verifications. Also, the Kerberos specification explicitly states that it does not address denial of service. > > In the U-U scenario, the burden of creating the > TGS-REQ lies on the attacker. The GetTGT > response is not authenticated so it costs the > receiver little. The cost at the KDC is the > same. However, there is little profit in > involving the U-U peer if the attacker doesn't already > have a legitimate TGT: the attacker could just > as easily have spoofed the entire U-U TGS-REQ > to cause a direct DoS attack on the KDC. Also: the > attack originates from its _source_ rather than > an uninterested third party as in above. > > Thus the CPU burden scorecard is: > > U-U Wakeup > attacker low low > peer low high [sasha]As I commented above, encrypting a TGS-REQ hardly qualifies as a high cost to the peer. In a normal scenario where either peer can send an AP-REQ, having to decrypt and invalidate a bogus AP-REQ is the same amount of work. > kdc high high > > And this does not take into account the harm > of an attacker with a legitimate TGT flooding > the ticket cache of a peer which is also not > a problem with the U-U approach. > > > A few roundtrips for a single connection is certainly no > problem, when you > > have 100,000 of them to a single server in a real-time > application, it is a > > real issue. The protocol will work either way, but I > would not want to for > > example downgrade the scalability of PacketCable > architecture by using your > > proposed approach. > > There are other ways to deal with this which > don't need to involve the protocol itself. > I don't favor building in a zombie attack into > the protocol when other options are viable. > > Mike > > > > > Sasha. > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Friday, November 03, 2000 12:24 PM > > > To: Medvinsky, Sasha (SD-EX) > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > > > > > > Medvinsky, Sasha (SD-EX) writes: > > > > As per my previous email, I listed what I consider to be > > > problems associated > > > > with a server obtaining tickets for a large number of its > > > clients. While I > > > > would support a change to PKINIT that allows automatic > > > generation of client > > > > keys that are saved in the KDC database, I don't believe > > > that it addresses > > > > this issue. > > > > > > It would either eliminate or mitigate the need for U-U. > > > > > > The only other argument I see is the potential need for > > > a server to get tickets for the clients in a failover > > > situations, etc. IPsec keying is fundamentally a peer > > > to peer protocol. In my opinion adding a mode > > > which is vulnerable to DoS attacks (and worse, > > > third party DoS attacks) to preserve a client > > > server architecture is not a worthwhile > > > tradeoff to save what amounts to disk space > > > for a large ticket cache. Also: a server only > > > needs to obtain tickets for clients if there > > > does not exist an SA *and* it has a reason to > > > talk to the client. Until then, the > > > non-existence of the SA is not hurting much > > > more than a possible extra round trip or two in > > > exceptional conditions, assuming that the > > > client does not key the SA itself. > > > > > > Mike > > > > > > > > > > > > > > > > > Sasha. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Friday, November 03, 2000 11:45 AM > > > > > To: Medvinsky, Sasha (SD-EX) > > > > > Cc: 'ietf-kink@vpnc.org' > > > > > Subject: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > > > > > > > > > After talking to Matt Hur about this and thinking > > > > > about this for a long time, I think the better > > > > > part of valor here may, in fact, be avoidance. > > > > > > > > > > Taking a giant step backward, the root of all of > > > > > the trouble here is that KINK is, in fact, a peer > > > > > to peer protocol where PKinit expects a client > > > > > server relationship. The main problem is that > > > > > PKinit authenticated clients do not share a > > > > > symmetric key at the KDC so the KDC cannot issue a > > > > > service ticket directly thus bringing on the > > > > > issues related to user-user mode. If the PKinit > > > > > client did share a key with the KDC, the KINK peer > > > > > would just obtain a normal service ticket and that > > > > > would be that. > > > > > > > > > > Therefore, I think that I agree with Matt's > > > > > contention that a much better strategy for use of > > > > > PKinit would be to use PKinit as an enrollment > > > > > strategy into a kerberos realm rather than an > > > > > authentication strategy, per se. Ie, a client > > > > > authenticates to the KDC using a cert but the KDC > > > > > then enrolls it with a symmetric key and saves > > > > > that key in its principal database. I haven't > > > > > looked at this exhaustively, but I think that this > > > > > strategy could be implemented using either no or > > > > > minimal changes to PKinit -- the obvious thing to > > > > > do is use the session key from the TGT from the > > > > > PKinit AS-REQ as the symmetric key. > > > > > > > > > > My proposal is that we deal with this problem as a > > > > > PKinit issue rather than a KINK issue because this > > > > > is a generic problem with PKinit -- KINK is just > > > > > the first to stumble upon the implications of > > > > > using PKinit in a peer to peer application. The > > > > > advantage here is that we could avoid *all* > > > > > unauthenticated requests which from a DoS > > > > > standpoint seems like a much better idea. > > > > > > > > > > Mike > > > > > > > > > > Medvinsky, Sasha (SD-EX) writes: > > > > > > The user-to-user Kerberos mode in KINK is intended to > > > > > address the situation > > > > > > with PKINIT clients that do not have symmetric > client keys > > > > > registered with > > > > > > the KDC and therefore a Kerberized server cannot get a > > > > > standard ticket for > > > > > > such a client. But the server still has to obtain > > > > > user-to-user tickets for > > > > > > clients, which brings up the following issues: > > > > > > > > > > > > 1) Under some architecures, such as VoIP, fast failover > > > > > time from a > > > > > > primary to a backup application server is > critical. With > > > > > the current > > > > > > protocol, the backup server would have to go to the KDC > > > > > and get user-to-user > > > > > > tickets for all of the clients with which it needs to > > > > > establish IPSec SAs. > > > > > > This adds to the recovery time and adds additional > > > > > performance/reliability > > > > > > requirements to the KDC. The number of clients > per server > > > > > can be large - > > > > > > 100,000 clients / Call Server is possible in the > > > > > PacketCable architecture. > > > > > > > > > > > > It is possible for the server to save > > > user-to-user tickets and > > > > > > corresponding session keys into some shared database, > > > > > which is undesirable > > > > > > in terms of complexity as well as security. > > > > > > > > > > > > 2) Load balancing between multiple Call Servers is > > > > > sometimes used in > > > > > > the VoIP architecture - support for it is > mandatory in the > > > > > PacketCable > > > > > > standard. The user-to-user tickets again either add to > > > > > the rekeying time > > > > > > (which delays the switch-over time for a client between > > > > > servers) or adds the > > > > > > complication of a shared database of > user-to-user tickets. > > > > > > > > > > > > 3) A standard Kerberized server that doesn't support the > > > > > > user-to-user tickets is a lot simpler to implement. It > > > > > would implement a > > > > > > very small percentage of the Kerberos protocol - just > > > the AP Req/AP > > > > > > Rep/KRB-ERROR messages. With the user-to-user mode, the > > > > > server needs the > > > > > > complete Kerberos client implementation and in addition > > > > > may need to support > > > > > > a very large ticket cache for user-to-user tickets. > > > > > > > > > > > > 4) Setting per-user policy is awkward for > > > user-to-user requests. > > > > > > Normally, the user policy is associated with the client, > > > > > but in this case > > > > > > the client is the server. Kerberos allows a > user to pass > > > > > authorization data > > > > > > in a TGS Request (which may be insecure, > depending on the > > > > > content of that > > > > > > authorization data), which would not be possible > if it is > > > > > the server getting > > > > > > a ticket for the client. > > > > > > > > > > > > 5) Setting per-user policy in a cross-realm > > > case is even more > > > > > > awkward. The server's GetTGT request would most likely > > > > > contain the server's > > > > > > realm name (as the server may not know the client's > > > > > realm). This means that > > > > > > the response to the GetTGT will contain a > cross-realm TGT > > > > > for the client. > > > > > > So, the server's KDC will wind up issuing a server a > > > > > user-to-user ticket for > > > > > > a client principal that is not even in that KDC's realm. > > > > > > > > > > > > There are alternative methods for handling > PKINIT clients > > > > > that address most > > > > > > of the above issues. What I propose, is the following > > > > > modification to the > > > > > > protocol. The GetTGT message flow in section 4.2 can be > > > > > replaced with the > > > > > > following: > > > > > > > > > > > > A > > > > > > B > > > > > > ------ > > > > > > ------ > > > > > > 1 > AuthenticateRequest+ServerPrincipalName---------------> > > > > > > > > > > > > 2 > > > > > > <------------------------------------AuthenticateReply+AP_REQ > > > > > > > > > > > > 3 CREATE+ISAKMP (keyed cksum with sess key)--------> > > > > > > > > > > > > 4 <------------REPLY+ISAKMP(keyed cksum with > sess key) > > > > > > > > > > > > In the above flows, there needs to be a way to > tie flows 2 > > > > > and 3 together - > > > > > > for example the client timestamp inside AP_REQ can be > > > > > repeated in flow 3. > > > > > > In addition, there is already an XID in the header for > > > > > this key management > > > > > > session. (It is also possible to include the AP_REP > > > in flow 3.) > > > > > > > > > > > > In the above flows, the AuthenticateRequest is not > > > > > authenticated, just like > > > > > > the GetTGT message. There is the denial of service > > > > > argument against the > > > > > > above flow since anyone can send the > AuthenticateRequest. > > > > > If C impersonates > > > > > > A and sends the AuthenticateRequest, B will have > to reply, > > > > > but A will reject > > > > > > the reply because the XID (session ID in the > header) will > > > > > not match anything > > > > > > that A sent out. The denial of service arguments are: > > > > > > > > > > > > a) denial of service on the KDC - B may need to get a > > > > > ticket for A > > > > > > if it doesn't have it already. But, even if KDC > receives > > > > > an invalid > > > > > > TGS_REQ, it still has to decrypt it to see that it is > > > > > invalid. I don't > > > > > > think that the extra work of issuing a ticket is a major > > > > > problem. Also, > > > > > > clients should cache the tickets, and the number of > > > > > servers in the KDC > > > > > > database is probably not that big. Also, the clients > > > > > should excersize > > > > > > access control and know ahead of time which servers they > > > > > should be talking > > > > > > to. > > > > > > > > > > > > b) denial of service on the clients - this is similar > > > > > to (a), except > > > > > > that the client's ticket cache is filled up. This is > > > > > really the same case > > > > > > as (a), because when the client's ticket cache is filled > > > > > up it can remove > > > > > > one of the entries. It just means that if the > client gets > > > > > a request that > > > > > > needs the removed ticket, the client will > request it from > > > > > the KDC again. > > > > > > > > > > > > Also, with the current KINK protocol, similar denial of > > > > > service attacks are > > > > > > possible. In that protocol, the GetTGT message only > > > > > specifies the realm. > > > > > > If the server doesn't know the client's name, it > might get > > > > > the wrong client > > > > > > TGT and get a user-to-user ticket for a wrong > client. If > > > > > the server then > > > > > > finds out that the resulting user-to-user ticket is not > > > > > accepted by the > > > > > > legitimate client, it will probably retry with another > > > > > GetTGT message that > > > > > > could also result in a wrong TGT (inserted by an > > > > > adversary) and then a wrong > > > > > > user-to-user ticket, ... > > > > > > > > > > > > > > > > > > > > > From owner-ietf-kink Mon Nov 20 07:29:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15753 for ietf-kink-bks; Mon, 20 Nov 2000 07:29:50 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15742 for ; Mon, 20 Nov 2000 07:29:49 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA28359; Mon, 20 Nov 2000 10:30:25 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD4887@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 10:30:24 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Tue, 14 Nov 2000 15:15:12 -0500" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > Also, the client should really have an Access Control List of the servers it > wants to talk to and would not normally respond to a request from a server > it doesn't know about. Even if a client did respond to any such server - > the KDC has only a limited number of them in its database. This doesn't make sense in the KINK framework. KINK is meant as a peer-to-peer protocol. You cannot expect a KINK Peer to necessarily know what other peers to expect to talk to it. I think you are applying PacketCable architecture requirements to KINK, in a way that those requirements do not apply. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 10:56:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04900 for ietf-kink-bks; Mon, 20 Nov 2000 10:56:15 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04895 for ; Mon, 20 Nov 2000 10:56:12 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWRE8LVTPEEZS0H2@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 10:56:18 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 10:55:10 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 13:58:29 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Derek Atkins'" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, KINK is a peer-to-peer protocol, but Kerberos is not. A client-server architecture is more commonly used with Kerberos than the user-to-user case. I would say Kerberos looses some of its advantages when it is used in the user-to-user mode. There is nothing special about the PacketCable architecture, except that it assumes a client-server architecture and I don't think that we should exclude it from KINK. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Monday, November 20, 2000 7:30 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > "Medvinsky, Sasha (SD-EX)" writes: > > > Also, the client should really have an Access Control List > of the servers it > > wants to talk to and would not normally respond to a > request from a server > > it doesn't know about. Even if a client did respond to any > such server - > > the KDC has only a limited number of them in its database. > > This doesn't make sense in the KINK framework. KINK is meant as a > peer-to-peer protocol. You cannot expect a KINK Peer to necessarily > know what other peers to expect to talk to it. I think you are > applying PacketCable architecture requirements to KINK, in a way that > those requirements do not apply. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink Mon Nov 20 11:05:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05178 for ietf-kink-bks; Mon, 20 Nov 2000 11:05:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05174 for ; Mon, 20 Nov 2000 11:05:46 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06373; Mon, 20 Nov 2000 12:06:25 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23833; Mon, 20 Nov 2000 14:06:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKJ5ha235660; Mon, 20 Nov 2000 14:05:43 -0500 (EST) Message-Id: <200011201905.eAKJ5ha235660@thunk.east.sun.com> From: Bill Sommerfeld To: "Medvinsky, Sasha (SD-EX)" cc: "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:58:29 EST." <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 14:05:43 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > KINK is a peer-to-peer protocol, yes > but Kerberos is not. kerberos is a 3-party protocol involving a KDC and two principals. All principals in possession of their long term key can trivially do peer-to-peer authentication. the user-to-user extension in kerberos v5 also lets "clients" which only have a TGT do peer-to-peer authentication without posession of the long-term key. - Bill From owner-ietf-kink Mon Nov 20 11:10:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05361 for ietf-kink-bks; Mon, 20 Nov 2000 11:10:15 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05357 for ; Mon, 20 Nov 2000 11:10:14 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA28576; Mon, 20 Nov 2000 14:10:53 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 14:10:52 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Mon, 20 Nov 2000 13:58:29 -0500" Message-ID: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > Derek, > > KINK is a peer-to-peer protocol, but Kerberos is not. A client-server > architecture is more commonly used with Kerberos than the user-to-user case. > I would say Kerberos looses some of its advantages when it is used in the > user-to-user mode. > > There is nothing special about the PacketCable architecture, except that it > assumes a client-server architecture and I don't think that we should > exclude it from KINK. > > Sasha. The special case of PacketCable is that servers may need to initiate IPSec with clients, but you don't want to have the server store keys. So, you want to be able to securely "handoff" the authentication to the clients, via a wakeup or other mechanism. What this amounts to is the application server telling the application client something like "I want to authenticate to you, so initiate an authentication to me". This is particularly a problem with PKINIT entities, as you cannot obtain an AP_REQ for a PKINIT ID. I believe that the latter problem is one that KINK will have to solve (most likely by using user-2-user, initiated by either party). However, I do believe that the former is out-of-scope for KINK. I don't think KINK should try to worry about forcing the initiator of sessions. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 11:10:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05349 for ietf-kink-bks; Mon, 20 Nov 2000 11:10:09 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05345 for ; Mon, 20 Nov 2000 11:10:08 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWREPUBEIWEZRYXM@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 11:10:16 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:09:03 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 14:12:24 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'sommerfeld@east.sun.com'" Cc: "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All I was saying is that although you can do peer-to-peer authentication with Kerberos, you shouldn't require it for an architecture where you don't have a peer-to-peer relationship. Sasha. > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Monday, November 20, 2000 11:06 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Derek Atkins'; 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > KINK is a peer-to-peer protocol, > > yes > > > but Kerberos is not. > > kerberos is a 3-party protocol involving a KDC and two principals. > > All principals in possession of their long term key can trivially do > peer-to-peer authentication. the user-to-user extension in kerberos > v5 also lets "clients" which only have a TGT do peer-to-peer > authentication without posession of the long-term key. > > - Bill > From owner-ietf-kink Mon Nov 20 11:14:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05470 for ietf-kink-bks; Mon, 20 Nov 2000 11:14:32 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05466 for ; Mon, 20 Nov 2000 11:14:30 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWREV9SW9GEZS3R0@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 11:14:43 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:13:26 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 14:16:47 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Derek Atkins'" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B1@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What makes this "hand-off of authentication to clients" out of scope for KINK? Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Monday, November 20, 2000 11:11 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > "Medvinsky, Sasha (SD-EX)" writes: > > > Derek, > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > client-server > > architecture is more commonly used with Kerberos than the > user-to-user case. > > I would say Kerberos looses some of its advantages when it > is used in the > > user-to-user mode. > > > > There is nothing special about the PacketCable > architecture, except that it > > assumes a client-server architecture and I don't think that > we should > > exclude it from KINK. > > > > Sasha. > > The special case of PacketCable is that servers may need to initiate > IPSec with clients, but you don't want to have the server store keys. > So, you want to be able to securely "handoff" the authentication to > the clients, via a wakeup or other mechanism. What this amounts to is > the application server telling the application client something like > "I want to authenticate to you, so initiate an authentication to me". > This is particularly a problem with PKINIT entities, as you cannot > obtain an AP_REQ for a PKINIT ID. > > I believe that the latter problem is one that KINK will have to solve > (most likely by using user-2-user, initiated by either party). > However, I do believe that the former is out-of-scope for KINK. I > don't think KINK should try to worry about forcing the initiator of > sessions. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink Mon Nov 20 11:33:21 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06707 for ietf-kink-bks; Mon, 20 Nov 2000 11:33:21 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06703 for ; Mon, 20 Nov 2000 11:33:20 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA28591; Mon, 20 Nov 2000 14:34:02 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD48B1@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 14:34:02 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Mon, 20 Nov 2000 14:16:47 -0500" Message-ID: Lines: 95 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I consider it out of scope because it adds uncesseary complexity to the general KINK protocol. It is complexity that perhaps PacketCable needs (or, more likely, wants), but it is not complexity that makes sense, IMHO, for a general-purpose IPSec key management protocol. It either forces us to add options to the protcol (thereby adding complexity), or it forces us to always handoff authentication and design a secure way to doing so (also adding complextity). The problem is that there is no way to always know a priori whether a peer is a PKINIT peer (where PKINIT peer is one that only has a TGT to work with, which implies normal users as well as PKINIT-based hosts) or a normal peer. In order to reduce complexity in KINK we have to optimize for either PKINIT or non-PKINIT peers. I believe that non-PKINIT peers are the "normal" case (namely, hosts with krb5 keytabs). Based upon this assumption (we should probably discuss whether this assumption has merits), we should optimize the protocol for non-PKINIT. This implies that we should try normal Kerberos, and if we cannot obtain an AP_REQ, then we try U2U. It means an extra round-trip to the KDC in the case of a PKINIT peer the first time we try to authenticate. We can always cache U2U tickets. Alternately, if we optimize for PKINIT peers, we should just use U2U at all times. However, in neither case do we try to offload authentication from one entity to the other. The initiator is always the initiator, the responder is always the responder. Never are we trying to have the initiator tell the responder to initiate authentication. -derek "Medvinsky, Sasha (SD-EX)" writes: > What makes this "hand-off of authentication to clients" out of scope for > KINK? > > Sasha. > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@mit.edu] > > Sent: Monday, November 20, 2000 11:11 AM > > To: Medvinsky, Sasha (SD-EX) > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > Derek, > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > client-server > > > architecture is more commonly used with Kerberos than the > > user-to-user case. > > > I would say Kerberos looses some of its advantages when it > > is used in the > > > user-to-user mode. > > > > > > There is nothing special about the PacketCable > > architecture, except that it > > > assumes a client-server architecture and I don't think that > > we should > > > exclude it from KINK. > > > > > > Sasha. > > > > The special case of PacketCable is that servers may need to initiate > > IPSec with clients, but you don't want to have the server store keys. > > So, you want to be able to securely "handoff" the authentication to > > the clients, via a wakeup or other mechanism. What this amounts to is > > the application server telling the application client something like > > "I want to authenticate to you, so initiate an authentication to me". > > This is particularly a problem with PKINIT entities, as you cannot > > obtain an AP_REQ for a PKINIT ID. > > > > I believe that the latter problem is one that KINK will have to solve > > (most likely by using user-2-user, initiated by either party). > > However, I do believe that the former is out-of-scope for KINK. I > > don't think KINK should try to worry about forcing the initiator of > > sessions. > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 11:54:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA08292 for ietf-kink-bks; Mon, 20 Nov 2000 11:54:59 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08288 for ; Mon, 20 Nov 2000 11:54:58 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id LAA17904; Mon, 20 Nov 2000 11:55:07 -0800 (PST) Date: Mon, 20 Nov 2000 11:55:06 -0800 (PST) From: Jan Vilhuber To: Derek Atkins cc: "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As Michael pointed out a few weeks ago, if we assume some sort of enrollment protocol, that creates a shared secret between pkinit clients and KDC, then the pkinit case becomes the general case, i.e. anyone can initiate to a pkinit client, after the pkinit client has 'enrolled' with a KDC (and you wouldn't even need u-u). Rather than add complexity to KINK, I would prefer we put together an enrollment proposal, either within THIS group, or propose it in the kerberos WG. jan On 20 Nov 2000, Derek Atkins wrote: > I consider it out of scope because it adds uncesseary complexity to > the general KINK protocol. It is complexity that perhaps PacketCable > needs (or, more likely, wants), but it is not complexity that makes > sense, IMHO, for a general-purpose IPSec key management protocol. It > either forces us to add options to the protcol (thereby adding > complexity), or it forces us to always handoff authentication and > design a secure way to doing so (also adding complextity). > > The problem is that there is no way to always know a priori whether a > peer is a PKINIT peer (where PKINIT peer is one that only has a TGT to > work with, which implies normal users as well as PKINIT-based hosts) > or a normal peer. In order to reduce complexity in KINK we have to > optimize for either PKINIT or non-PKINIT peers. I believe that > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > keytabs). > > Based upon this assumption (we should probably discuss whether this > assumption has merits), we should optimize the protocol for > non-PKINIT. This implies that we should try normal Kerberos, and if > we cannot obtain an AP_REQ, then we try U2U. It means an extra > round-trip to the KDC in the case of a PKINIT peer the first time we > try to authenticate. We can always cache U2U tickets. Alternately, > if we optimize for PKINIT peers, we should just use U2U at all times. > > However, in neither case do we try to offload authentication from one > entity to the other. The initiator is always the initiator, the > responder is always the responder. Never are we trying to have the > initiator tell the responder to initiate authentication. > > -derek > > "Medvinsky, Sasha (SD-EX)" writes: > > > What makes this "hand-off of authentication to clients" out of scope for > > KINK? > > > > Sasha. > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > Sent: Monday, November 20, 2000 11:11 AM > > > To: Medvinsky, Sasha (SD-EX) > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > Derek, > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > client-server > > > > architecture is more commonly used with Kerberos than the > > > user-to-user case. > > > > I would say Kerberos looses some of its advantages when it > > > is used in the > > > > user-to-user mode. > > > > > > > > There is nothing special about the PacketCable > > > architecture, except that it > > > > assumes a client-server architecture and I don't think that > > > we should > > > > exclude it from KINK. > > > > > > > > Sasha. > > > > > > The special case of PacketCable is that servers may need to initiate > > > IPSec with clients, but you don't want to have the server store keys. > > > So, you want to be able to securely "handoff" the authentication to > > > the clients, via a wakeup or other mechanism. What this amounts to is > > > the application server telling the application client something like > > > "I want to authenticate to you, so initiate an authentication to me". > > > This is particularly a problem with PKINIT entities, as you cannot > > > obtain an AP_REQ for a PKINIT ID. > > > > > > I believe that the latter problem is one that KINK will have to solve > > > (most likely by using user-2-user, initiated by either party). > > > However, I do believe that the former is out-of-scope for KINK. I > > > don't think KINK should try to worry about forcing the initiator of > > > sessions. > > > > > > -derek > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord@MIT.EDU PGP key available > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 12:45:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA10327 for ietf-kink-bks; Mon, 20 Nov 2000 12:45:40 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10316 for ; Mon, 20 Nov 2000 12:45:35 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWRI2MW2N6EZS7UO@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 12:46:03 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 12:44:52 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 15:48:09 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Jan Vilhuber'" , Derek Atkins Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B4@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As I replied to Mike's email, this client enrollment would eliminate some of the disadvantages of the user-to-user mode (e.g. adding user policy/authorization into the tickets), but would still require a server to obtain/maintain tickets for its clients. I also listed benefits of not having to do that. Sasha. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Monday, November 20, 2000 11:55 AM > To: Derek Atkins > Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > As Michael pointed out a few weeks ago, if we assume some > sort of enrollment > protocol, that creates a shared secret between pkinit clients > and KDC, then > the pkinit case becomes the general case, i.e. anyone can > initiate to a > pkinit client, after the pkinit client has 'enrolled' with a > KDC (and you > wouldn't even need u-u). > > Rather than add complexity to KINK, I would prefer we put together an > enrollment proposal, either within THIS group, or propose it > in the kerberos > WG. > > jan > > > > > On 20 Nov 2000, Derek Atkins wrote: > > > I consider it out of scope because it adds uncesseary complexity to > > the general KINK protocol. It is complexity that perhaps > PacketCable > > needs (or, more likely, wants), but it is not complexity that makes > > sense, IMHO, for a general-purpose IPSec key management > protocol. It > > either forces us to add options to the protcol (thereby adding > > complexity), or it forces us to always handoff authentication and > > design a secure way to doing so (also adding complextity). > > > > The problem is that there is no way to always know a priori > whether a > > peer is a PKINIT peer (where PKINIT peer is one that only > has a TGT to > > work with, which implies normal users as well as PKINIT-based hosts) > > or a normal peer. In order to reduce complexity in KINK we have to > > optimize for either PKINIT or non-PKINIT peers. I believe that > > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > > keytabs). > > > > Based upon this assumption (we should probably discuss whether this > > assumption has merits), we should optimize the protocol for > > non-PKINIT. This implies that we should try normal Kerberos, and if > > we cannot obtain an AP_REQ, then we try U2U. It means an extra > > round-trip to the KDC in the case of a PKINIT peer the first time we > > try to authenticate. We can always cache U2U tickets. Alternately, > > if we optimize for PKINIT peers, we should just use U2U at > all times. > > > > However, in neither case do we try to offload > authentication from one > > entity to the other. The initiator is always the initiator, the > > responder is always the responder. Never are we trying to have the > > initiator tell the responder to initiate authentication. > > > > -derek > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > What makes this "hand-off of authentication to clients" > out of scope for > > > KINK? > > > > > > Sasha. > > > > > > > -----Original Message----- > > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > > Sent: Monday, November 20, 2000 11:11 AM > > > > To: Medvinsky, Sasha (SD-EX) > > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > > > Derek, > > > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > > client-server > > > > > architecture is more commonly used with Kerberos than the > > > > user-to-user case. > > > > > I would say Kerberos looses some of its advantages when it > > > > is used in the > > > > > user-to-user mode. > > > > > > > > > > There is nothing special about the PacketCable > > > > architecture, except that it > > > > > assumes a client-server architecture and I don't think that > > > > we should > > > > > exclude it from KINK. > > > > > > > > > > Sasha. > > > > > > > > The special case of PacketCable is that servers may > need to initiate > > > > IPSec with clients, but you don't want to have the > server store keys. > > > > So, you want to be able to securely "handoff" the > authentication to > > > > the clients, via a wakeup or other mechanism. What > this amounts to is > > > > the application server telling the application client > something like > > > > "I want to authenticate to you, so initiate an > authentication to me". > > > > This is particularly a problem with PKINIT entities, as > you cannot > > > > obtain an AP_REQ for a PKINIT ID. > > > > > > > > I believe that the latter problem is one that KINK will > have to solve > > > > (most likely by using user-2-user, initiated by either party). > > > > However, I do believe that the former is out-of-scope > for KINK. I > > > > don't think KINK should try to worry about forcing the > initiator of > > > > sessions. > > > > > > > > -derek > > > > > > > > -- > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > > Member, MIT Student Information Processing Board (SIPB) > > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > > warlord@MIT.EDU PGP key available > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > warlord@MIT.EDU PGP key available > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ietf-kink Mon Nov 20 13:17:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11922 for ietf-kink-bks; Mon, 20 Nov 2000 13:17:40 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11918 for ; Mon, 20 Nov 2000 13:17:39 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA22711; Mon, 20 Nov 2000 13:17:20 -0800 (PST) Date: Mon, 20 Nov 2000 13:17:20 -0800 (PST) From: Jan Vilhuber To: "Medvinsky, Sasha (SD-EX)" cc: Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48B4@ntas0027.gi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Medvinsky, Sasha (SD-EX) wrote: > As I replied to Mike's email, this client enrollment would eliminate some of > the disadvantages of the user-to-user mode (e.g. adding user > policy/authorization into the tickets), but would still require a server to > obtain/maintain tickets for its clients. Which gets back to the fact that KINK is for peer-to-peer, so any server is a client and any client is a server. So they all need to be principals in the KDC, so we need to enroll them. Unless you want to do u-u, I guess, which complicates things. I'd prefer to have them enrolled. jan > I also listed benefits of not > having to do that. > > Sasha. > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Monday, November 20, 2000 11:55 AM > > To: Derek Atkins > > Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > As Michael pointed out a few weeks ago, if we assume some > > sort of enrollment > > protocol, that creates a shared secret between pkinit clients > > and KDC, then > > the pkinit case becomes the general case, i.e. anyone can > > initiate to a > > pkinit client, after the pkinit client has 'enrolled' with a > > KDC (and you > > wouldn't even need u-u). > > > > Rather than add complexity to KINK, I would prefer we put together an > > enrollment proposal, either within THIS group, or propose it > > in the kerberos > > WG. > > > > jan > > > > > > > > > > On 20 Nov 2000, Derek Atkins wrote: > > > > > I consider it out of scope because it adds uncesseary complexity to > > > the general KINK protocol. It is complexity that perhaps > > PacketCable > > > needs (or, more likely, wants), but it is not complexity that makes > > > sense, IMHO, for a general-purpose IPSec key management > > protocol. It > > > either forces us to add options to the protcol (thereby adding > > > complexity), or it forces us to always handoff authentication and > > > design a secure way to doing so (also adding complextity). > > > > > > The problem is that there is no way to always know a priori > > whether a > > > peer is a PKINIT peer (where PKINIT peer is one that only > > has a TGT to > > > work with, which implies normal users as well as PKINIT-based hosts) > > > or a normal peer. In order to reduce complexity in KINK we have to > > > optimize for either PKINIT or non-PKINIT peers. I believe that > > > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > > > keytabs). > > > > > > Based upon this assumption (we should probably discuss whether this > > > assumption has merits), we should optimize the protocol for > > > non-PKINIT. This implies that we should try normal Kerberos, and if > > > we cannot obtain an AP_REQ, then we try U2U. It means an extra > > > round-trip to the KDC in the case of a PKINIT peer the first time we > > > try to authenticate. We can always cache U2U tickets. Alternately, > > > if we optimize for PKINIT peers, we should just use U2U at > > all times. > > > > > > However, in neither case do we try to offload > > authentication from one > > > entity to the other. The initiator is always the initiator, the > > > responder is always the responder. Never are we trying to have the > > > initiator tell the responder to initiate authentication. > > > > > > -derek > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > What makes this "hand-off of authentication to clients" > > out of scope for > > > > KINK? > > > > > > > > Sasha. > > > > > > > > > -----Original Message----- > > > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > > > Sent: Monday, November 20, 2000 11:11 AM > > > > > To: Medvinsky, Sasha (SD-EX) > > > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > > > > > Derek, > > > > > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > > > client-server > > > > > > architecture is more commonly used with Kerberos than the > > > > > user-to-user case. > > > > > > I would say Kerberos looses some of its advantages when it > > > > > is used in the > > > > > > user-to-user mode. > > > > > > > > > > > > There is nothing special about the PacketCable > > > > > architecture, except that it > > > > > > assumes a client-server architecture and I don't think that > > > > > we should > > > > > > exclude it from KINK. > > > > > > > > > > > > Sasha. > > > > > > > > > > The special case of PacketCable is that servers may > > need to initiate > > > > > IPSec with clients, but you don't want to have the > > server store keys. > > > > > So, you want to be able to securely "handoff" the > > authentication to > > > > > the clients, via a wakeup or other mechanism. What > > this amounts to is > > > > > the application server telling the application client > > something like > > > > > "I want to authenticate to you, so initiate an > > authentication to me". > > > > > This is particularly a problem with PKINIT entities, as > > you cannot > > > > > obtain an AP_REQ for a PKINIT ID. > > > > > > > > > > I believe that the latter problem is one that KINK will > > have to solve > > > > > (most likely by using user-2-user, initiated by either party). > > > > > However, I do believe that the former is out-of-scope > > for KINK. I > > > > > don't think KINK should try to worry about forcing the > > initiator of > > > > > sessions. > > > > > > > > > > -derek > > > > > > > > > > -- > > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > > > Member, MIT Student Information Processing Board (SIPB) > > > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > > > warlord@MIT.EDU PGP key available > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > > > warlord@MIT.EDU PGP key available > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 13:25:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12264 for ietf-kink-bks; Mon, 20 Nov 2000 13:25:25 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12260 for ; Mon, 20 Nov 2000 13:25:23 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04997; Mon, 20 Nov 2000 13:26:02 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA25239; Mon, 20 Nov 2000 16:25:57 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKLPGa236169; Mon, 20 Nov 2000 16:25:16 -0500 (EST) Message-Id: <200011202125.eAKLPGa236169@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:17:20 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 16:25:15 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > have them enrolled. depends on how you measure complexity. i suspect a new enrollment protocol would be more complex than just using u-u. - Bill From owner-ietf-kink Mon Nov 20 13:31:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12435 for ietf-kink-bks; Mon, 20 Nov 2000 13:31:37 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12431 for ; Mon, 20 Nov 2000 13:31:36 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA23427; Mon, 20 Nov 2000 13:31:15 -0800 (PST) Date: Mon, 20 Nov 2000 13:31:15 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202125.eAKLPGa236169@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > > have them enrolled. > > depends on how you measure complexity. Agreed. I measure it in terms of added complexity WITHIN the same protocol. A new enrollment protocol may be somewhat complex, but this complexity is orthogonal to KINK, thus making KINK easier to analyze for security. Adding more exchanges for corner-cases certainly doesn't help people analyze it for weaknesses. > i suspect a new enrollment > protocol would be more complex than just using u-u. > But it may be usefull to other people as well. Two semi-complex protocols are better than one hyper-complex one. In my opinion, anyway. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 13:38:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12660 for ietf-kink-bks; Mon, 20 Nov 2000 13:38:52 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12654 for ; Mon, 20 Nov 2000 13:38:51 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13770; Mon, 20 Nov 2000 13:39:27 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA28812; Mon, 20 Nov 2000 16:39:24 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKLcha236255; Mon, 20 Nov 2000 16:38:43 -0500 (EST) Message-Id: <200011202138.eAKLcha236255@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:31:15 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 16:38:42 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > new enrollment protocol may be somewhat complex, but this complexity is > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > more exchanges for corner-cases certainly doesn't help people analyze it for > weaknesses. true. i've suggested on numerous occasions that KINK should avoid this problem by always using user-to-user. - Bill From owner-ietf-kink Mon Nov 20 13:46:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12902 for ietf-kink-bks; Mon, 20 Nov 2000 13:46:52 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12897 for ; Mon, 20 Nov 2000 13:46:50 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA24233; Mon, 20 Nov 2000 13:46:30 -0800 (PST) Date: Mon, 20 Nov 2000 13:46:29 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202138.eAKLcha236255@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > > new enrollment protocol may be somewhat complex, but this complexity is > > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > > more exchanges for corner-cases certainly doesn't help people analyze it for > > weaknesses. > > true. i've suggested on numerous occasions that KINK should avoid > this problem by always using user-to-user. > I guess that's one way. The other is to never use u-u, and force everyone to be a principal in the KDC. Not being 100% kerberos-expert, this appeals to me more, especially in light of the fact that a pkinit-enrollment may be usefull in other protocols/occasions (I'm guessing). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 14:30:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14131 for ietf-kink-bks; Mon, 20 Nov 2000 14:30:30 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14127 for ; Mon, 20 Nov 2000 14:30:28 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA28827; Mon, 20 Nov 2000 17:31:13 -0500 To: Jan Vilhuber Cc: Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: From: Derek Atkins Date: 20 Nov 2000 17:31:13 -0500 In-Reply-To: Jan Vilhuber's message of "Mon, 20 Nov 2000 13:46:29 -0800 (PST)" Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jan Vilhuber writes: > I guess that's one way. The other is to never use u-u, and force everyone to > be a principal in the KDC. Not being 100% kerberos-expert, this appeals to me > more, especially in light of the fact that a pkinit-enrollment may be usefull > in other protocols/occasions (I'm guessing). The problem is that this wont work for, a user being the responder. A user would be enrolled in the KDC, but they have a password, not a keytab. So, the system would only have a TGT credential to work with (although a foreign system would still be able to get a "valid" service-key response from the KDC). Perhaps we just don't care; or perhaps "users" can only be IPSec initiators. -derek > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 14:37:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14300 for ietf-kink-bks; Mon, 20 Nov 2000 14:37:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14295 for ; Mon, 20 Nov 2000 14:37:15 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09636; Mon, 20 Nov 2000 15:37:50 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA23184; Mon, 20 Nov 2000 17:37:49 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKMb7a236351; Mon, 20 Nov 2000 17:37:07 -0500 (EST) Message-Id: <200011202237.eAKMb7a236351@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: Jan Vilhuber , Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 17:31:13 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 17:37:07 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Perhaps we just don't care; or perhaps "users" can only be IPSec > initiators. That won't work in the general case since many possible uses of ipsec require peer-to-peer keying. (or, rather, require either end to be able to initiate rekeying). - Bill From owner-ietf-kink Mon Nov 20 14:56:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14864 for ietf-kink-bks; Mon, 20 Nov 2000 14:56:27 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14859 for ; Mon, 20 Nov 2000 14:56:25 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA28842; Mon, 20 Nov 2000 17:57:06 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202237.eAKMb7a236351@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 17:57:06 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 17:37:07 -0500" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > > Perhaps we just don't care; or perhaps "users" can only be IPSec > > initiators. > > That won't work in the general case since many possible uses of ipsec > require peer-to-peer keying. (or, rather, require either end to be > able to initiate rekeying). It works for road-warrior VPNs :) In other cases, you probably aren't authenticating users to users, or hosts to users, but rather hosts to hosts. So I don't think it matters there, either. The only case I can truly think of where you might want to have the user authenticate one end is for a road-warrior VPN solution, and in that case, no, the server WONT be initiating anything :) > - Bill -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 15:00:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA14981 for ietf-kink-bks; Mon, 20 Nov 2000 15:00:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14977 for ; Mon, 20 Nov 2000 15:00:53 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26707; Mon, 20 Nov 2000 16:01:35 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA27969; Mon, 20 Nov 2000 18:01:33 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKN0pa236400; Mon, 20 Nov 2000 18:00:51 -0500 (EST) Message-Id: <200011202300.eAKN0pa236400@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 17:57:06 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:00:51 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It works for road-warrior VPNs :) that's nice. > In other cases, you probably aren't authenticating users to users, or > hosts to users, but rather hosts to hosts. This is an unwarranted assumption, and the ipsec implementation i'm working on doesn't make that assumption. > So I don't think it matters there, either. I think it does. - Bill From owner-ietf-kink Mon Nov 20 15:03:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15048 for ietf-kink-bks; Mon, 20 Nov 2000 15:03:24 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15040 for ; Mon, 20 Nov 2000 15:03:22 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28852; Mon, 20 Nov 2000 18:04:08 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202300.eAKN0pa236400@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:04:08 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:00:51 -0500" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, clearly we disagree. :) We'll see what the group at large thinks. -derek Bill Sommerfeld writes: > > It works for road-warrior VPNs :) > > that's nice. > > > In other cases, you probably aren't authenticating users to users, or > > hosts to users, but rather hosts to hosts. > > This is an unwarranted assumption, and the ipsec implementation i'm > working on doesn't make that assumption. > > > So I don't think it matters there, either. > > I think it does. > > - Bill -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 15:07:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15170 for ietf-kink-bks; Mon, 20 Nov 2000 15:07:45 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15164 for ; Mon, 20 Nov 2000 15:07:44 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA28340; Mon, 20 Nov 2000 15:07:54 -0800 (PST) Date: Mon, 20 Nov 2000 15:07:53 -0800 (PST) From: Jan Vilhuber To: Derek Atkins cc: sommerfeld@east.sun.com, "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 20 Nov 2000, Derek Atkins wrote: > Bill Sommerfeld writes: > > > > Perhaps we just don't care; or perhaps "users" can only be IPSec > > > initiators. > > > > That won't work in the general case since many possible uses of ipsec > > require peer-to-peer keying. (or, rather, require either end to be > > able to initiate rekeying). > > It works for road-warrior VPNs :) > > In other cases, you probably aren't authenticating users to users, or > hosts to users, but rather hosts to hosts. So I don't think it > matters there, either. The only case I can truly think of where you > might want to have the user authenticate one end is for a road-warrior > VPN solution, and in that case, no, the server WONT be initiating > anything :) > It might also be worthwhile to do what IKE failed to do, which is to spell out re-keying behaviour. If we spell out that the original initiator needs to be the one to reinitiate a re-key, then problems won't arise. That's not to say that initiation can not be in both directions, but if someone will be a responder, that host/user MUST be a principal in the KDC. That covers your road-warrior example, as those users may NOT need to be principals, assuming they will always initiate and will always initiate a re-key. Whether the semantics I propose above are the correct ones, or not, I think this should be in the draft somewhere to avoid ambuguities in rekeying which we now have to deal with in IKE (See Jenkins draft). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 15:22:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15483 for ietf-kink-bks; Mon, 20 Nov 2000 15:22:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15478 for ; Mon, 20 Nov 2000 15:22:30 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10761; Mon, 20 Nov 2000 16:23:13 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA01759; Mon, 20 Nov 2000 18:23:12 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNMUa236427; Mon, 20 Nov 2000 18:22:30 -0500 (EST) Message-Id: <200011202322.eAKNMUa236427@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Derek Atkins , sommerfeld@east.sun.com, "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 15:07:53 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:22:29 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It might also be worthwhile to do what IKE failed to do, which is to spell > out re-keying behaviour. If we spell out that the original initiator needs to > be the one to reinitiate a re-key, then problems won't arise. How can that possibly work in a non-VPN, non-connection-oriented scenario? Does the initiator *always* recreate an expiring SA, just in case the peer might want to send something in the future? Do you engage in some sort of layering violation, peeking into TCP to see if there are still open connections or tracking connection state in the IP layer? Or do you not care about long-lived connections, and let them drop if the initiator doesn't have the session up? I'm not happy with any of these alternatives.. the responder must be able to turn around and reinitiate back to the initiator.. - Bill From owner-ietf-kink Mon Nov 20 15:32:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15643 for ietf-kink-bks; Mon, 20 Nov 2000 15:32:38 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15639 for ; Mon, 20 Nov 2000 15:32:36 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28879; Mon, 20 Nov 2000 18:33:21 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202322.eAKNMUa236427@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:33:20 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:22:29 -0500" Message-ID: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? If you're using user-authentication, then yes, you should keep it up, as long as your TGT is valid. Once the TGT expires, you can let the connection drop. The user has to reauthenticate themselves to the system anyways; alternatively they can re-initialize IPSec by hand at the same time that they get new tickets. > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? If your user TGT expires, you HAVE to let them drop anyways. Unless you're expecting to have a UI violation where the kernel will asynchronously pop up some UI function to ask the user for username/password in order to obtain a TGT when it's expired? So, in the user-auth case, no, I don't care about long-lived connections. They can't exist without user intervention. > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. And I think limiting this particular case to host-host authentication is a reasonable protocol limitation. > - Bill -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 15:36:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15699 for ietf-kink-bks; Mon, 20 Nov 2000 15:36:33 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15695 for ; Mon, 20 Nov 2000 15:36:32 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA29634; Mon, 20 Nov 2000 15:36:45 -0800 (PST) Date: Mon, 20 Nov 2000 15:36:45 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202322.eAKNMUa236427@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > I didn't say it was perfect. ;) > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > No. We do none of that. We don't even do what I described above. It's just an idea. If it doesn't pan out, it doesn't pan out. > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > If the initiator is a road-warrior, whose dynamic-IP connection went down as well (due to timeout or whatever), then it might not matter. Your objection is valid, though. jan > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 15:36:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15690 for ietf-kink-bks; Mon, 20 Nov 2000 15:36:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15686 for ; Mon, 20 Nov 2000 15:36:26 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20399; Mon, 20 Nov 2000 16:37:06 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA04253; Mon, 20 Nov 2000 18:37:04 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNaMa236461; Mon, 20 Nov 2000 18:36:22 -0500 (EST) Message-Id: <200011202336.eAKNaMa236461@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 18:33:20 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:36:22 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > If you're using user-authentication, then yes, you should keep it up, > as long as your TGT is valid. Why? In many cases, we might have nothing further to send to the peer.. > If your user TGT expires, you HAVE to let them drop anyways. Unless > you're expecting to have a UI violation where the kernel will > asynchronously pop up some UI function to ask the user for > username/password in order to obtain a TGT when it's expired? BTW, that would be the key management daemon, not the kernel.. - Bill From owner-ietf-kink Mon Nov 20 15:50:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15877 for ietf-kink-bks; Mon, 20 Nov 2000 15:50:13 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15873 for ; Mon, 20 Nov 2000 15:50:12 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28896; Mon, 20 Nov 2000 18:50:57 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202336.eAKNaMa236461@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:50:56 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:36:22 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > > If your user TGT expires, you HAVE to let them drop anyways. Unless > > you're expecting to have a UI violation where the kernel will > > asynchronously pop up some UI function to ask the user for > > username/password in order to obtain a TGT when it's expired? > > BTW, that would be the key management daemon, not the kernel.. It's still a system daemon, not a user app. So, how do you get the user's credentials there anyways? And how do you report to the user when those tickets expire? > - Bill -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 20 15:57:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16010 for ietf-kink-bks; Mon, 20 Nov 2000 15:57:44 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16005 for ; Mon, 20 Nov 2000 15:57:43 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA00493; Mon, 20 Nov 2000 15:57:55 -0800 (PST) Date: Mon, 20 Nov 2000 15:57:55 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202336.eAKNaMa236461@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > If you're using user-authentication, then yes, you should keep it up, > > as long as your TGT is valid. > > Why? In many cases, we might have nothing further to send to the peer.. > So you an idle-timer. Host-to-host probably doesn't want this, but vpn probably will. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 15:59:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16034 for ietf-kink-bks; Mon, 20 Nov 2000 15:59:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16030 for ; Mon, 20 Nov 2000 15:59:10 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06024; Mon, 20 Nov 2000 16:59:53 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA07837; Mon, 20 Nov 2000 18:59:52 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNx9a236511; Mon, 20 Nov 2000 18:59:09 -0500 (EST) Message-Id: <200011202359.eAKNx9a236511@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Bill Sommerfeld , Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 15:57:55 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:59:09 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So you an idle-timer. Host-to-host probably doesn't want this, but vpn > probably will. That only detects that we wanted to send something recently, not that the peer might want to send us something in the future... - Bill From owner-ietf-kink Mon Nov 20 16:04:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16115 for ietf-kink-bks; Mon, 20 Nov 2000 16:04:23 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16111 for ; Mon, 20 Nov 2000 16:04:21 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id QAA00764; Mon, 20 Nov 2000 16:04:00 -0800 (PST) Date: Mon, 20 Nov 2000 16:04:00 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202359.eAKNx9a236511@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > So you an idle-timer. Host-to-host probably doesn't want this, but vpn > > probably will. > > That only detects that we wanted to send something recently, not that > the peer might want to send us something in the future... > As I said: In a dial-up/vpn scenario that doesn't matter. If you have something to send, and the link has gone away (or the SA's have died, which amounts to the same thing), you're out of luck anyway. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 20 16:10:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16198 for ietf-kink-bks; Mon, 20 Nov 2000 16:10:52 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16194 for ; Mon, 20 Nov 2000 16:10:51 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27773; Mon, 20 Nov 2000 16:11:33 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA27375; Mon, 20 Nov 2000 19:11:32 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAL0Aoa236559; Mon, 20 Nov 2000 19:10:50 -0500 (EST) Message-Id: <200011210010.eAL0Aoa236559@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 18:50:56 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 19:10:49 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It's still a system daemon, not a user app. So, how do you get the > user's credentials there anyways? I can think of a number of ways, one of which is a per-user authentication proxy which is connected to the key management daemon at login time, which can run with a UI. - Bill From owner-ietf-kink Tue Nov 21 02:56:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26842 for ietf-kink-bks; Tue, 21 Nov 2000 02:56:25 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26836 for ; Tue, 21 Nov 2000 02:56:24 -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 FAA00795; Tue, 21 Nov 2000 05:57:11 -0500 (EST) Message-Id: <200011211057.FAA00795@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-ike-over-kkmp-00.txt Date: Tue, 21 Nov 2000 05:57:10 -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 : Running IKE Phase 2 over Artificial Kerberos IKE SA Author(s) : T. Kivinen Filename : draft-ietf-kink-ike-over-kkmp-00.txt Pages : 6 Date : 20-Nov-00 This document defines how to create artificial IKE SA using kerberos [RFC-1510]. It defines how to calculate SKEYID, cookies and IV needed by the IKE SA from the Kerberos session key. After the artificial IKE SA is created, it can be used to run normal IKE [RFC-2409] phase 2 negotia- tions. Those negotiations include quick Mode (creating IPsec SA), new group mode, delete notifications, and error notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-ike-over-kkmp-00.txt 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-ike-over-kkmp-00.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-ike-over-kkmp-00.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: <20001120151452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-ike-over-kkmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-ike-over-kkmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001120151452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue Nov 21 07:37:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19873 for ietf-kink-bks; Tue, 21 Nov 2000 07:37:12 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19868 for ; Tue, 21 Nov 2000 07:37:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24031; Tue, 21 Nov 2000 07:37:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07553; Tue, 21 Nov 2000 07:37:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.38582.343689.600494@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:37:26 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202125.eAKLPGa236169@thunk.east.sun.com> References: <200011202125.eAKLPGa236169@thunk.east.sun.com> 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: Bill Sommerfeld writes: > > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > > have them enrolled. > > depends on how you measure complexity. i suspect a new enrollment > protocol would be more complex than just using u-u. We're a little bit afield of KINK here, but... I've been thinking that the enrollment _protocol_ doesn't need to be complicated at all: it could just be a normal PKINIT Kerberos AS-REQ, perhaps with a flag that tells the KDC to enroll the principal with the session key that it puts into the TGT. Perhaps it can even be done without an explicit flag. That would have the nice property that you'd also get symmetric key refresh basically for free, though it does force the KDC to deal with previous and next keys instead of just one key. That said, I think that the harder problem is going to come down to all of the implications of distributed database propogation on the KDC's. That, of course, is an application problem though. Mike From owner-ietf-kink Tue Nov 21 07:39:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20011 for ietf-kink-bks; Tue, 21 Nov 2000 07:39:57 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20005 for ; Tue, 21 Nov 2000 07:39:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24083; Tue, 21 Nov 2000 07:40:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07556; Tue, 21 Nov 2000 07:40:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.38746.494551.568022@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:40:10 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202138.eAKLcha236255@thunk.east.sun.com> References: <200011202138.eAKLcha236255@thunk.east.sun.com> 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: Bill Sommerfeld writes: > > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > > new enrollment protocol may be somewhat complex, but this complexity is > > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > > more exchanges for corner-cases certainly doesn't help people analyze it for > > weaknesses. > > true. i've suggested on numerous occasions that KINK should avoid > this problem by always using user-to-user. User-User pretty much forces the normal create SA case to be a two round trip affair. One of the goals here is to reduce keying latency, and cutting out round trips is an obvious means to that goal. Mike From owner-ietf-kink Tue Nov 21 07:55:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA23388 for ietf-kink-bks; Tue, 21 Nov 2000 07:55:01 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23384 for ; Tue, 21 Nov 2000 07:55:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24316; Tue, 21 Nov 2000 07:55:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07559; Tue, 21 Nov 2000 07:55:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.39649.745697.39680@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:55:13 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202322.eAKNMUa236427@thunk.east.sun.com> References: <200011202322.eAKNMUa236427@thunk.east.sun.com> 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: I guess I don't quite grok the dilemma here. Initiator and responder only matter when setting up/tearing down the SA. Though perhaps not optimal, there shouldn't be a problem having two SA's with the same flow spec between two hosts -- they just needs to chose one. Assuming that either party can tear down an existing SA (which now that I think about it may not work in the current draft), you have the situation where either side can manage the SA's any way they see fit. What am I missing? Mike Bill Sommerfeld writes: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > From owner-ietf-kink Tue Nov 21 08:03:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24183 for ietf-kink-bks; Tue, 21 Nov 2000 08:03:49 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24178 for ; Tue, 21 Nov 2000 08:03:47 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24455; Tue, 21 Nov 2000 08:04:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07562; Tue, 21 Nov 2000 08:04:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.40180.929436.605303@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:04:04 -0800 (PST) To: Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202322.eAKNMUa236427@thunk.east.sun.com> 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: Derek Atkins writes: > If you're using user-authentication, then yes, you should keep it up, > as long as your TGT is valid. Once the TGT expires, you can let the > connection drop. I don't think I agree. The current draft has a lifetime of the SA which may be shorter than the length of the service ticket. This is probably useful if your sessions are plentiful, random and short lived. Using a short lifetime mitigates the need to explicitly delete SA's. > If your user TGT expires, you HAVE to let them drop anyways. Unless > you're expecting to have a UI violation where the kernel will > asynchronously pop up some UI function to ask the user for > username/password in order to obtain a TGT when it's expired? What's wrong with this? That's all that getty is, in some sense. > So, in the user-auth case, no, I don't care about long-lived > connections. They can't exist without user intervention. Is a smart card "user auth"? > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > And I think limiting this particular case to host-host authentication > is a reasonable protocol limitation. Well, _I_ don't think we should be so limited, but fortunately, this looks like an implementation issue, not a protocol issue. Mike From owner-ietf-kink Tue Nov 21 08:10:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24660 for ietf-kink-bks; Tue, 21 Nov 2000 08:10:16 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24642 for ; Tue, 21 Nov 2000 08:10:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24531; Tue, 21 Nov 2000 08:10:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07565; Tue, 21 Nov 2000 08:10:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.40554.533913.28856@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:10:18 -0800 (PST) To: Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202336.eAKNaMa236461@thunk.east.sun.com> 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: Derek Atkins writes: > Bill Sommerfeld writes: > > > > If your user TGT expires, you HAVE to let them drop anyways. Unless > > > you're expecting to have a UI violation where the kernel will > > > asynchronously pop up some UI function to ask the user for > > > username/password in order to obtain a TGT when it's expired? > > > > BTW, that would be the key management daemon, not the kernel.. > > It's still a system daemon, not a user app. So, how do you get the > user's credentials there anyways? And how do you report to the user > when those tickets expire? C'mon, Derik. Netscrape manages to figure out how to prompt the user for credentials... this doesn't seem like rocket science. The important interface is the kernel/user boundary; once it's outside of the kernel, it's not very difficult to imagine an event driven this or that that could handle this quite cleanly. Mike From owner-ietf-kink Tue Nov 21 08:11:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24737 for ietf-kink-bks; Tue, 21 Nov 2000 08:11:18 -0800 (PST) Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24732 for ; Tue, 21 Nov 2000 08:11:16 -0800 (PST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA10260; Tue, 21 Nov 2000 16:12:02 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 16:12:01 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 08:12:00 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Tue, 21 Nov 2000 08:11:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, How, when, and if they choose one is precisely the issue. This was something left unspecified in the interaction between IKE and IPsec, and as a result vendors implemented conformant but non-interoperable solutions to this problem. -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, November 21, 2000 7:55 AM To: sommerfeld@east.sun.com Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: Re: alternative to user-to-user Kerberos in KINK I guess I don't quite grok the dilemma here. Initiator and responder only matter when setting up/tearing down the SA. Though perhaps not optimal, there shouldn't be a problem having two SA's with the same flow spec between two hosts -- they just needs to chose one. Assuming that either party can tear down an existing SA (which now that I think about it may not work in the current draft), you have the situation where either side can manage the SA's any way they see fit. What am I missing? Mike Bill Sommerfeld writes: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > From owner-ietf-kink Tue Nov 21 08:25:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25199 for ietf-kink-bks; Tue, 21 Nov 2000 08:25:17 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25195 for ; Tue, 21 Nov 2000 08:25:16 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24914; Tue, 21 Nov 2000 08:25:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07574; Tue, 21 Nov 2000 08:25:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.41468.325527.359049@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:25:32 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> 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: Jesse, Correct me if I'm wrong, but this sure looks like it's out of the scope of the keying protocol per se. It seems like it would be better to have a BCP or something with base IPsec which defines what the expected behavior ought to be when you have two SA's with the same flow spec. Mike Walker, Jesse writes: > Mike, > > How, when, and if they choose one is precisely the issue. This was something > left unspecified in the interaction between IKE and IPsec, and as a result > vendors implemented conformant but non-interoperable solutions to this > problem. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:55 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > I guess I don't quite grok the dilemma here. Initiator and > responder only matter when setting up/tearing down the > SA. Though perhaps not optimal, there shouldn't be a > problem having two SA's with the same flow spec between > two hosts -- they just needs to chose one. Assuming > that either party can tear down an existing SA (which > now that I think about it may not work in the current > draft), you have the situation where either side can > manage the SA's any way they see fit. > > What am I missing? > > Mike > > Bill Sommerfeld writes: > > > It might also be worthwhile to do what IKE failed to do, which is to > spell > > > out re-keying behaviour. If we spell out that the original initiator > needs to > > > be the one to reinitiate a re-key, then problems won't arise. > > > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > > > Do you engage in some sort of layering violation, peeking into TCP to > > see if there are still open connections or tracking connection state > > in the IP layer? > > > > Or do you not care about long-lived connections, and let them drop if > > the initiator doesn't have the session up? > > > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > > > - Bill > > > > From owner-ietf-kink Tue Nov 21 09:21:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29188 for ietf-kink-bks; Tue, 21 Nov 2000 09:21:00 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29179 for ; Tue, 21 Nov 2000 09:20:58 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id MAA29606; Tue, 21 Nov 2000 12:21:45 -0500 To: Michael Thomas Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202336.eAKNaMa236461@thunk.east.sun.com> <14874.40554.533913.28856@thomasm-u1.cisco.com> From: Derek Atkins Date: 21 Nov 2000 12:21:44 -0500 In-Reply-To: Michael Thomas's message of "Tue, 21 Nov 2000 08:10:18 -0800 (PST)" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > C'mon, Derik. Netscrape manages to figure out how to prompt > the user for credentials... this doesn't seem like rocket > science. The important interface is the kernel/user boundary; > once it's outside of the kernel, it's not very difficult > to imagine an event driven this or that that could handle this > quite cleanly. Netscrape is a single application. I haven't seen it interact with IPSec. I'm not saying that we can't register a user-agent with the key management daemon to ask for user input. IKE-XAuth certainly requires something like that. I'm just pointing out implementation issues. There's more than just kernel/user boundary, there's also a daemon(background-process)/UI boundary. No, it's not insurmountable. But I also don't think a protocol like this should necessarily mandate a particular UI requirement. > Mike -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Tue Nov 21 09:26:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29611 for ietf-kink-bks; Tue, 21 Nov 2000 09:26:04 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29605 for ; Tue, 21 Nov 2000 09:26:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA26472; Tue, 21 Nov 2000 09:26:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07593; Tue, 21 Nov 2000 09:26:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.45111.798172.241271@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 09:26:15 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202336.eAKNaMa236461@thunk.east.sun.com> <14874.40554.533913.28856@thomasm-u1.cisco.com> 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: Derek Atkins writes: > There's more than just kernel/user boundary, there's also a > daemon(background-process)/UI boundary. No, it's not insurmountable. > But I also don't think a protocol like this should necessarily mandate > a particular UI requirement. Well, I don't either but the good news is that nobody's mandating anything on that count. Everybody is entitled to their own way of getting KINK key(s). Mike From owner-ietf-kink Tue Nov 21 10:05:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02017 for ietf-kink-bks; Tue, 21 Nov 2000 10:05:32 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02013 for ; Tue, 21 Nov 2000 10:05:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA27572; Tue, 21 Nov 2000 10:05:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07606; Tue, 21 Nov 2000 10:05:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.47452.245075.146852@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 10:05:16 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'sommerfeld@east.sun.com'" , "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> 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: Medvinsky, Sasha (SD-EX) writes: > All I was saying is that although you can do peer-to-peer authentication > with Kerberos, you shouldn't require it for an architecture where you don't > have a peer-to-peer relationship. I think client/server and peer-peer is somewhat misleading. Colloquially, client/server means that clients initiate transactions, not servers. Peer to peer means that no such distinction is drawn. I don't think that Kerberos, per se, has much to say on that front because "client" machines can host services and "server" machines can act as clients, so it appears to _mostly_ be a distinction without a difference. There are only two things that I know of which requires me to qualify myself above: 1) clients may authenticate using PKINIT which leads to the U-U/enrollment debate 2) it may be a worthwhile optimization to allow machines which subtend large numbers of users (let's not call them clients, because that's misleading) to have the abilty to require the high fanout devices to get and maintain tickets, thus avoiding duplication of effort and storage. #1 seems like we may be headed toward consensus that Matt's idea of enrollment may be a reasonable idea to pursue for PKinit. U-U should also be a fallback. The dispute seems mostly over #2. I still feel really uneasy about the inherent DoS attacks. I'm also not convinced that the real-life use of KINK cannot avoid this dilemma for the most part. Given the downside, I think that waiting to see real implementation experience would be a more prudent course of action. Mike From owner-ietf-kink Wed Nov 22 07:30:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA09054 for ietf-kink-bks; Wed, 22 Nov 2000 07:30:49 -0800 (PST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09044 for ; Wed, 22 Nov 2000 07:30:47 -0800 (PST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id HAA17884; Wed, 22 Nov 2000 07:31:42 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 22 Nov 2000 15:31:42 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 07:31:41 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Wed, 22 Nov 2000 07:31:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, I think sidestepping the issue is a fundamental strategic mistake that will render KINK far less relevant than it could otherwise be. Rightly or wrongly, my belief is that one of the justifications for KINK's existence is a number of interoperability issues could never be resolved for IKE. In particular, this issue was never fully addressed for the IKE/IPsec interaction (it is usually referred to as the rekey issue). My recollection is that by the time Tim Jenkins finally published a reasonable way to resolve the problem, vendors had already implemented 8 conformant but non-interoperable algorithms for accomplishing the coordination, and it thereby became infeasible to get any consensus on how to move forward, since no one was willing to give up their own approach. With KINK there is a clean slate, and if the issue is addressed up front, there is a far, far better chance for genuine interoperability. It is not hard to specify an algorithm--the implementation history of the IKE/IPsec interaction gives us at least 8 to choose from! All the spec should do is specify one and decree once and for all that that's how to do it when using KINK. -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, November 21, 2000 8:26 AM To: Walker, Jesse Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: RE: alternative to user-to-user Kerberos in KINK Jesse, Correct me if I'm wrong, but this sure looks like it's out of the scope of the keying protocol per se. It seems like it would be better to have a BCP or something with base IPsec which defines what the expected behavior ought to be when you have two SA's with the same flow spec. Mike Walker, Jesse writes: > Mike, > > How, when, and if they choose one is precisely the issue. This was something > left unspecified in the interaction between IKE and IPsec, and as a result > vendors implemented conformant but non-interoperable solutions to this > problem. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:55 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > I guess I don't quite grok the dilemma here. Initiator and > responder only matter when setting up/tearing down the > SA. Though perhaps not optimal, there shouldn't be a > problem having two SA's with the same flow spec between > two hosts -- they just needs to chose one. Assuming > that either party can tear down an existing SA (which > now that I think about it may not work in the current > draft), you have the situation where either side can > manage the SA's any way they see fit. > > What am I missing? > > Mike > > Bill Sommerfeld writes: > > > It might also be worthwhile to do what IKE failed to do, which is to > spell > > > out re-keying behaviour. If we spell out that the original initiator > needs to > > > be the one to reinitiate a re-key, then problems won't arise. > > > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > > > Do you engage in some sort of layering violation, peeking into TCP to > > see if there are still open connections or tracking connection state > > in the IP layer? > > > > Or do you not care about long-lived connections, and let them drop if > > the initiator doesn't have the session up? > > > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > > > - Bill > > > > From owner-ietf-kink Wed Nov 22 09:21:27 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20064 for ietf-kink-bks; Wed, 22 Nov 2000 09:21:27 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20057 for ; Wed, 22 Nov 2000 09:21:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA12499; Wed, 22 Nov 2000 09:21:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08031; Wed, 22 Nov 2000 09:21:51 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14876.174.903678.329297@thomasm-u1.cisco.com> Date: Wed, 22 Nov 2000 09:21:50 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> 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: OK, I'm obviously not up to speed on the rekeying wars and I don't remember the details of the jenkins draft. I'm also not sure what, in particular, was the hole that so many people drove through. Showing my ignorance, if it's only a matter in KINK of also describing how the selectors are processed when you have two identical ones, could we just say that you choose the newest one to send on? Does this actually even matter? Thus to rekey, the _rekeying_ initiator would CREATE a new SA on SPI Y, and DELETE the old SPI on X. During the transition, there are a few conditions: 0) The CREATE has not been sent; both initiator and responder MUST process on the old SPI (ie, it's the normal steady state of the previous SA). 1) The CREATE REPLY has not arrived; the initiator MUST consider only the old SPI for sending and receiving traffic. 2) The DELETE has not arrived; the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following two are optional; the initiator MAY allow the old SPI to time out: 3) The DELETE REPLY has not arrived; same as (2) for the responder. For the initiator, it MUST accept traffic on either SPI, but only send on the new SPI. 4) The DELETE REPLY is received; same as (0). Am I out in left field here? Mike Walker, Jesse writes: > Mike, > > I think sidestepping the issue is a fundamental strategic mistake that will > render KINK far less relevant than it could otherwise be. > > Rightly or wrongly, my belief is that one of the justifications for KINK's > existence is a number of interoperability issues could never be resolved for > IKE. In particular, this issue was never fully addressed for the IKE/IPsec > interaction (it is usually referred to as the rekey issue). My recollection > is that by the time Tim Jenkins finally published a reasonable way to > resolve the problem, vendors had already implemented 8 conformant but > non-interoperable algorithms for accomplishing the coordination, and it > thereby became infeasible to get any consensus on how to move forward, since > no one was willing to give up their own approach. > > With KINK there is a clean slate, and if the issue is addressed up front, > there is a far, far better chance for genuine interoperability. It is not > hard to specify an algorithm--the implementation history of the IKE/IPsec > interaction gives us at least 8 to choose from! All the spec should do is > specify one and decree once and for all that that's how to do it when using > KINK. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:26 AM > To: Walker, Jesse > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > Jesse, > > Correct me if I'm wrong, but this sure looks like > it's out of the scope of the keying protocol per > se. It seems like it would be better to have a BCP > or something with base IPsec which defines what > the expected behavior ought to be when you have > two SA's with the same flow spec. > > Mike > > Walker, Jesse writes: > > Mike, > > > > How, when, and if they choose one is precisely the issue. This was > something > > left unspecified in the interaction between IKE and IPsec, and as a > result > > vendors implemented conformant but non-interoperable solutions to this > > problem. > > > > -- Jesse > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:55 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > I guess I don't quite grok the dilemma here. Initiator and > > responder only matter when setting up/tearing down the > > SA. Though perhaps not optimal, there shouldn't be a > > problem having two SA's with the same flow spec between > > two hosts -- they just needs to chose one. Assuming > > that either party can tear down an existing SA (which > > now that I think about it may not work in the current > > draft), you have the situation where either side can > > manage the SA's any way they see fit. > > > > What am I missing? > > > > Mike > > > > Bill Sommerfeld writes: > > > > It might also be worthwhile to do what IKE failed to do, which is to > > spell > > > > out re-keying behaviour. If we spell out that the original initiator > > needs to > > > > be the one to reinitiate a re-key, then problems won't arise. > > > > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > > > Do you engage in some sort of layering violation, peeking into TCP to > > > see if there are still open connections or tracking connection state > > > in the IP layer? > > > > > > Or do you not care about long-lived connections, and let them drop if > > > the initiator doesn't have the session up? > > > > > > I'm not happy with any of these alternatives.. the responder must be > > > able to turn around and reinitiate back to the initiator.. > > > > > > - Bill > > > > > > > > > From owner-ietf-kink Wed Nov 22 17:28:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09393 for ietf-kink-bks; Wed, 22 Nov 2000 17:28:49 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09387 for ; Wed, 22 Nov 2000 17:28:47 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWUKJD3RDOEZTHTS@GI.COM> for ietf-kink@vpnc.org; Wed, 22 Nov 2000 17:29:08 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:27:59 -0500 Content-return: allowed Date: Wed, 22 Nov 2000 20:31:06 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" , sommerfeld@east.sun.com Cc: Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, I don't think there is a need for an new enrollment protocol - it has been defined already. An authenticated PKINIT client would get a service ticket for an "Change Password Service" and then set its symmetric service key with an existing protocol in http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx t. Despite the title of the draft, it allows updates to service keys as well as client passwords. Although the draft was originally intended for updates to an existing key, there is no reason why it couldn't create a new key as well. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:37 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > Bill Sommerfeld writes: > > > Unless you want to do u-u, I guess, which complicates > things. I'd prefer to > > > have them enrolled. > > > > depends on how you measure complexity. i suspect a new enrollment > > protocol would be more complex than just using u-u. > > We're a little bit afield of KINK here, but... > > I've been thinking that the enrollment _protocol_ > doesn't need to be complicated at all: it could > just be a normal PKINIT Kerberos AS-REQ, perhaps > with a flag that tells the KDC to enroll the > principal with the session key that it puts into > the TGT. Perhaps it can even be done without an > explicit flag. That would have the nice property > that you'd also get symmetric key refresh basically > for free, though it does force the KDC to deal with > previous and next keys instead of just one key. > > That said, I think that the harder problem is > going to come down to all of the implications of > distributed database propogation on the KDC's. > That, of course, is an application problem though. > > Mike > From owner-ietf-kink Wed Nov 22 17:45:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09771 for ietf-kink-bks; Wed, 22 Nov 2000 17:45:13 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09767 for ; Wed, 22 Nov 2000 17:45:12 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWUL3T5K36EZTB7E@GI.COM> for ietf-kink@vpnc.org; Wed, 22 Nov 2000 17:45:38 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:44:28 -0500 Content-return: allowed Date: Wed, 22 Nov 2000 20:47:35 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" , Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48D2@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Mike. With Kerberos upgraded to 3-DES or AES, tickets could safely last for weeks - which improves system scalability, you don't have to contact the KDC as often. Tickets may also be used for some purpose other than IPSec. The lifetime of SAs should not be tied to the ticket lifetime (although they can't exceed it). > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:04 AM > To: Derek Atkins > Cc: sommerfeld@east.sun.com; Jan Vilhuber; Medvinsky, Sasha (SD-EX); > 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > Derek Atkins writes: > > If you're using user-authentication, then yes, you should > keep it up, > > as long as your TGT is valid. Once the TGT expires, you > can let the > > connection drop. > > I don't think I agree. The current draft has a lifetime of > the SA which may be shorter than the length of the service > ticket. This is probably useful if your sessions are > plentiful, random and short lived. Using a short lifetime > mitigates the need to explicitly delete SA's. From owner-ietf-kink Mon Nov 27 10:43:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA21156 for ietf-kink-bks; Mon, 27 Nov 2000 10:43:30 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21149 for ; Mon, 27 Nov 2000 10:43:28 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id SAA04206; Mon, 27 Nov 2000 18:46:02 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 27 Nov 2000 18:44:37 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 10:44:36 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Mon, 27 Nov 2000 10:44:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, You have proposed a very good start. Here are some comments. a. The document needs to specify a way to identify who is indeed the rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses and then arbitrarily decrees the larger of the two wins; perhaps we employ something similar.) b. If KINK rekeying works like IKE rekeying, in that each peer has to contribute nonces and the like as entropy for computing the new SA keys, it is not evident that (2) below is correct. This is because the responder does not know that the initiator can compute the correct SA keys for the new SA until after it knows the peer has received its CREATE REPLY; it will be sending traffic into a black hole if the CREATE REPLY is lost. The responder should indeed receive on both old and new SA as (2) suggests, but perhaps it may be better to continue sending on the old send SA until the DELETE from the initiator arrives. Then if its CREATE REPLY never arrives, communication can at least continue until the SA key expires. (In a two-phase commit protocol, you don't commit until phase 2.) c. If you buy (b) above, then the initiator needs a retry timer for its CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry timer for CREATE REPLY (to ellicit a DELETE). I think (3) is correct or almost correct in the case it actually receives a CREATE REPLY: the initiator sends on the new SA, but receives on both the old and the new. It knows the responder knows the keys for the new SAs, because it received the CREATE REPLY. But it can't do away with the old SA until it receives the DELETE REPLY from the responder (or key expiry), because it doesn't know that the responder has comitted to use the new SAs. I do not think this is optional behavior; I think it is mandatory to make interoperability a possibility. d. What seems optional is the responder could send a DELETE REPLY and delete its old SAs if it receives traffic from the initiator on the new SA; this says conclusively that the peer received its CREATE REPLAY, because it is protecting its traffic under the new SPIs and keys associated with the new SA. Likewise, the initiator can finally delete its old SAs if it receives traffic on the new SA. This is conclusive evidence that the responder has received either its DELETE REPLY or noticed that the new SA is in use. This optional provision will allow progress if the DELETE/DELETE REPLY messages are all lost but the IPsec datagrams can still get through. It is optional because retries of the CREATE REPLY and DELETE messages should eventually cause convergence if the peers are still reachable to each other. e. We don't have any behavior for when an expected reply never arrives. Presumably we want to continue using the old SAs until their keys expire, but this is counter to the decisions discussed above about when to start sending on the new SA. So maybe there isn't a retry limit on DELETEs? Or maybe the reasoning of when to begin sending on the new SA is wrong? -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, November 22, 2000 9:22 AM To: Walker, Jesse Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: RE: alternative to user-to-user Kerberos in KINK OK, I'm obviously not up to speed on the rekeying wars and I don't remember the details of the jenkins draft. I'm also not sure what, in particular, was the hole that so many people drove through. Showing my ignorance, if it's only a matter in KINK of also describing how the selectors are processed when you have two identical ones, could we just say that you choose the newest one to send on? Does this actually even matter? Thus to rekey, the _rekeying_ initiator would CREATE a new SA on SPI Y, and DELETE the old SPI on X. During the transition, there are a few conditions: 0) The CREATE has not been sent; both initiator and responder MUST process on the old SPI (ie, it's the normal steady state of the previous SA). 1) The CREATE REPLY has not arrived; the initiator MUST consider only the old SPI for sending and receiving traffic. 2) The DELETE has not arrived; the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following two are optional; the initiator MAY allow the old SPI to time out: 3) The DELETE REPLY has not arrived; same as (2) for the responder. For the initiator, it MUST accept traffic on either SPI, but only send on the new SPI. 4) The DELETE REPLY is received; same as (0). Am I out in left field here? Mike Walker, Jesse writes: > Mike, > > I think sidestepping the issue is a fundamental strategic mistake that will > render KINK far less relevant than it could otherwise be. > > Rightly or wrongly, my belief is that one of the justifications for KINK's > existence is a number of interoperability issues could never be resolved for > IKE. In particular, this issue was never fully addressed for the IKE/IPsec > interaction (it is usually referred to as the rekey issue). My recollection > is that by the time Tim Jenkins finally published a reasonable way to > resolve the problem, vendors had already implemented 8 conformant but > non-interoperable algorithms for accomplishing the coordination, and it > thereby became infeasible to get any consensus on how to move forward, since > no one was willing to give up their own approach. > > With KINK there is a clean slate, and if the issue is addressed up front, > there is a far, far better chance for genuine interoperability. It is not > hard to specify an algorithm--the implementation history of the IKE/IPsec > interaction gives us at least 8 to choose from! All the spec should do is > specify one and decree once and for all that that's how to do it when using > KINK. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:26 AM > To: Walker, Jesse > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > Jesse, > > Correct me if I'm wrong, but this sure looks like > it's out of the scope of the keying protocol per > se. It seems like it would be better to have a BCP > or something with base IPsec which defines what > the expected behavior ought to be when you have > two SA's with the same flow spec. > > Mike > > Walker, Jesse writes: > > Mike, > > > > How, when, and if they choose one is precisely the issue. This was > something > > left unspecified in the interaction between IKE and IPsec, and as a > result > > vendors implemented conformant but non-interoperable solutions to this > > problem. > > > > -- Jesse > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:55 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > I guess I don't quite grok the dilemma here. Initiator and > > responder only matter when setting up/tearing down the > > SA. Though perhaps not optimal, there shouldn't be a > > problem having two SA's with the same flow spec between > > two hosts -- they just needs to chose one. Assuming > > that either party can tear down an existing SA (which > > now that I think about it may not work in the current > > draft), you have the situation where either side can > > manage the SA's any way they see fit. > > > > What am I missing? > > > > Mike > > > > Bill Sommerfeld writes: > > > > It might also be worthwhile to do what IKE failed to do, which is to > > spell > > > > out re-keying behaviour. If we spell out that the original initiator > > needs to > > > > be the one to reinitiate a re-key, then problems won't arise. > > > > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > > > Do you engage in some sort of layering violation, peeking into TCP to > > > see if there are still open connections or tracking connection state > > > in the IP layer? > > > > > > Or do you not care about long-lived connections, and let them drop if > > > the initiator doesn't have the session up? > > > > > > I'm not happy with any of these alternatives.. the responder must be > > > able to turn around and reinitiate back to the initiator.. > > > > > > - Bill > > > > > > > > > From owner-ietf-kink Mon Nov 27 12:25:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29032 for ietf-kink-bks; Mon, 27 Nov 2000 12:25:22 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29027 for ; Mon, 27 Nov 2000 12:25:20 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id PAA08163; Mon, 27 Nov 2000 15:26:31 -0500 To: ietf-kink@vpnc.org Subject: KINK Draft Agenda From: Derek Atkins Date: 27 Nov 2000 15:26:31 -0500 Message-ID: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the draft agenda for the KINK WG meeting in San Diego, with times for everyone who has asked to speak. Let me know if there should be any changes. -derek Kerberized Internet Nogotiation of Keys Working Group (KINK) Chairs: Derek Atkins John Trostle San Diego Meeting Time: Tuesday 1300-1400 Draft Agenda Who When Derek Atkins - Telcordia Agenda Bashing :00-:03 Mike Thomas - Cisco KINK Requirements :05-:20 Mike Thoman - Cisco KINK Draft Protocol :20-:33 Sasha Medvinsky - Motorola server-initiated key management :35-:45 with PKINIT clients Tero Kivinen - SSH IKE-Over-KKMP :48-:59 -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Nov 27 14:28:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA05434 for ietf-kink-bks; Mon, 27 Nov 2000 14:28:09 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05427 for ; Mon, 27 Nov 2000 14:28:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA21586; Mon, 27 Nov 2000 14:28:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09465; Mon, 27 Nov 2000 14:28:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14882.57385.532385.969881@thomasm-u1.cisco.com> Date: Mon, 27 Nov 2000 14:28:57 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , sommerfeld@east.sun.com, Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> 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: I'm all for begging, borrowing or stealing. I only scanned the draft over quickly -- is there a way for the KDC to specify the password? That seems like it would give the best password source since by definition the KDC's RNG better be good. Mike Medvinsky, Sasha (SD-EX) writes: > Mike, > > I don't think there is a need for an new enrollment protocol - it has been > defined already. An authenticated PKINIT client would get a service ticket > for an "Change Password Service" and then set its symmetric service key with > an existing protocol in > http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx > t. > > Despite the title of the draft, it allows updates to service keys as well as > client passwords. Although the draft was originally intended for updates to > an existing key, there is no reason why it couldn't create a new key as > well. > > Sasha. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:37 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > Bill Sommerfeld writes: > > > > Unless you want to do u-u, I guess, which complicates > > things. I'd prefer to > > > > have them enrolled. > > > > > > depends on how you measure complexity. i suspect a new enrollment > > > protocol would be more complex than just using u-u. > > > > We're a little bit afield of KINK here, but... > > > > I've been thinking that the enrollment _protocol_ > > doesn't need to be complicated at all: it could > > just be a normal PKINIT Kerberos AS-REQ, perhaps > > with a flag that tells the KDC to enroll the > > principal with the session key that it puts into > > the TGT. Perhaps it can even be done without an > > explicit flag. That would have the nice property > > that you'd also get symmetric key refresh basically > > for free, though it does force the KDC to deal with > > previous and next keys instead of just one key. > > > > That said, I think that the harder problem is > > going to come down to all of the implications of > > distributed database propogation on the KDC's. > > That, of course, is an application problem though. > > > > Mike > > > From owner-ietf-kink Mon Nov 27 14:57:16 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06457 for ietf-kink-bks; Mon, 27 Nov 2000 14:57:16 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06453 for ; Mon, 27 Nov 2000 14:57:15 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JX1EPJCBB6EZV4DD@GI.COM> for ietf-kink@vpnc.org; Mon, 27 Nov 2000 14:57:57 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 14:56:39 -0500 Content-return: allowed Date: Mon, 27 Nov 2000 18:00:05 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: sommerfeld@east.sun.com, Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48E0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In that draft, it is always the client that specifies the new key or password. You can always recommend that the client uses the session key as a seed into its pseudo-random number generator. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, November 27, 2000 2:29 PM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; sommerfeld@east.sun.com; Jan Vilhuber; Derek > Atkins; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > I'm all for begging, borrowing or stealing. I only > scanned the draft over quickly -- is there a way > for the KDC to specify the password? That seems > like it would give the best password source since > by definition the KDC's RNG better be good. > > Mike > > Medvinsky, Sasha (SD-EX) writes: > > Mike, > > > > I don't think there is a need for an new enrollment > protocol - it has been > > defined already. An authenticated PKINIT client would get > a service ticket > > for an "Change Password Service" and then set its > symmetric service key with > > an existing protocol in > > http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx > t. > > Despite the title of the draft, it allows updates to service keys as well as > client passwords. Although the draft was originally intended for updates to > an existing key, there is no reason why it couldn't create a new key as > well. > > Sasha. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:37 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > Bill Sommerfeld writes: > > > > Unless you want to do u-u, I guess, which complicates > > things. I'd prefer to > > > > have them enrolled. > > > > > > depends on how you measure complexity. i suspect a new enrollment > > > protocol would be more complex than just using u-u. > > > > We're a little bit afield of KINK here, but... > > > > I've been thinking that the enrollment _protocol_ > > doesn't need to be complicated at all: it could > > just be a normal PKINIT Kerberos AS-REQ, perhaps > > with a flag that tells the KDC to enroll the > > principal with the session key that it puts into > > the TGT. Perhaps it can even be done without an > > explicit flag. That would have the nice property > > that you'd also get symmetric key refresh basically > > for free, though it does force the KDC to deal with > > previous and next keys instead of just one key. > > > > That said, I think that the harder problem is > > going to come down to all of the implications of > > distributed database propogation on the KDC's. > > That, of course, is an application problem though. > > > > Mike > > > From owner-ietf-kink Tue Nov 28 17:46:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20810 for ietf-kink-bks; Tue, 28 Nov 2000 17:46:30 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20806 for ; Tue, 28 Nov 2000 17:46:29 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JX2YX3IGBIEZVTMV@GI.COM> for ietf-kink@vpnc.org; Tue, 28 Nov 2000 17:47:25 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 17:46:11 -0500 Content-return: allowed Date: Tue, 28 Nov 2000 20:49:39 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: "'sommerfeld@east.sun.com'" , "'Derek Atkins'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48FE@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, The DoS attacks do not apply in the case where clients have a list of servers that they are talking to, where by client and server I mean Kerberos client and application server. In other words, a client will reject a WakeUp if the server name is not in its ACL. This works fine in PacketCable and so if it is not generally useful in KINK, we would leave it as a PacketCable-specific extension that addresses issue #2 you have listed below. Or maybe it could be a separate draft under KINK called something like "client-server profile and extensions to KINK". Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 10:05 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'sommerfeld@east.sun.com'; 'Derek Atkins'; 'Michael Thomas'; > 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > Medvinsky, Sasha (SD-EX) writes: > > All I was saying is that although you can do peer-to-peer > authentication > > with Kerberos, you shouldn't require it for an > architecture where you don't > > have a peer-to-peer relationship. > > I think client/server and peer-peer is somewhat > misleading. Colloquially, client/server means that > clients initiate transactions, not servers. Peer > to peer means that no such distinction is drawn. > > I don't think that Kerberos, per se, has much to > say on that front because "client" machines can > host services and "server" machines can act as > clients, so it appears to _mostly_ be a distinction > without a difference. > > There are only two things that I know of which > requires me to qualify myself above: > > 1) clients may authenticate using PKINIT which > leads to the U-U/enrollment debate > 2) it may be a worthwhile optimization to allow > machines which subtend large numbers of users > (let's not call them clients, because that's > misleading) to have the abilty to require > the high fanout devices to get and maintain > tickets, thus avoiding duplication of effort > and storage. > > #1 seems like we may be headed toward consensus > that Matt's idea of enrollment may be a reasonable > idea to pursue for PKinit. U-U should also be a > fallback. The dispute seems mostly > over #2. I still feel really uneasy about the > inherent DoS attacks. I'm also not convinced that > the real-life use of KINK cannot avoid this dilemma > for the most part. > > Given the downside, I think that waiting to see > real implementation experience would be a more > prudent course of action. > > Mike > From owner-ietf-kink Sun Dec 3 14:42:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06917 for ietf-kink-bks; Sun, 3 Dec 2000 14:42:47 -0800 (PST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06913 for ; Sun, 3 Dec 2000 14:42:45 -0800 (PST) Received: from jariws1 (a96d14hel.dial.kolumbus.fi [212.54.29.96]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id AAA18581; Mon, 4 Dec 2000 00:44:33 +0200 (EET) Message-ID: <005d01c05d7a$9dc1f020$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: , Subject: Another DOI on top of ISAKMP/IKE -- draft-arkko-map-doi-00.txt Date: Mon, 4 Dec 2000 00:44:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello. We have produced a new Internet Draft, describing how ISAKMP (and IKE to a large extent, or even KINK) could be reused in the context of protecting one non-IP protocol in mobile networks. We would appreciate getting the group's opinion on this approach. Background: =========== The 3GPP (third generation mobile network standardization forum) is working on security for their MAP protocol. MAP is a central protocol in GSM networks, and continues to be used at least for a while also in 3G networks; perhaps eventually however completely replaced by protocols such as SIP and AAA. As MAP transports sensitive data used e.g. in the authentication of GSM phones, operators are being increasingly concerned that MAP messages are transported in the clear. Now, a security mechanism has been designed to encrypt and integrity protect MAP messages. MAP runs over SS7, ad the security mechanism inserts a header between the SS7 and MAP parts of packets. The network arrangement is typically such that servers from two operator networks (visiting and home) need to talk to each other. Both IP and SS7 connectivity exists. There is a large number of operators. However, the fact that we can encrypt MAP messages is not enough by itself. We also need to configure and create MAP SAs in a scalable manner, and we need to have lifetimes for the use of the SAs. For this we need key management. Our involvement: ================ We'been working on slight modification of the IPSEC DOI in order to use ISAKMP/IKE to negotiate the MAP security associations. It turns out that IKE phase 1 can be used as-is (alternatively KINK), and that phase 2 is modified only with respect to the meaning of the SA data. For details, see the I-D http://search.ietf.org/internet-drafts/draft-arkko-map-doi-00.txt There are also other possible alternatives to implement the same functionality. A completely new and MAP-specific key management protocol over IP has also been discussed but we'd rather reuse IKE since that is used also for other purposes, is quite complete, can be deployed fast, and we could reuse implementations. An alternative protocol could also be developed solely on top of SS7. And then to the issues on which we'd like your opinion: =========================================== 1) What is your technical opinion of the approach? 2) If we decide to go for this approach within the mobile networks, how should this work proceed in the IETF world? An informational RFC? Will these be allowed while some standards track IPsec/IKE modifications are on hold? What is the process for getting a new Informational RFC? 3) Should we discuss this in San Diego? 4) What about possible future assignments of numbers from the spaces defined by a new DOI? Jari Arkko From owner-ietf-kink Mon Dec 11 18:52:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA12420 for ietf-kink-bks; Mon, 11 Dec 2000 18:52:20 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12416 for ; Mon, 11 Dec 2000 18:52:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA22507; Mon, 11 Dec 2000 18:54:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA13883; Mon, 11 Dec 2000 18:54:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14901.37725.199149.11272@thomasm-u1.cisco.com> Date: Mon, 11 Dec 2000 18:54:21 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> 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: I'm going to bring this up tomorrow. Hopefully, this will refresh everybody. Answers inline: Walker, Jesse writes: > Mike, > > You have proposed a very good start. Here are some comments. > > a. The document needs to specify a way to identify who is indeed the > rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses > and then arbitrarily decrees the larger of the two wins; perhaps we employ > something similar.) I guess I don't understand what a tie means. The current draft says that the initiator is the only one that initiates a rekeying operation. Even if there is some clock skew where you could get into a situation where there is a collision, isn't the worst outcome two SA's for, essentially, the same traffic? If so, shouldn't there be two valid SA's, and that the old "conserative on what you send, liberal on what you receive" should apply? > > b. If KINK rekeying works like IKE rekeying, in that each peer has to > contribute nonces and the like as entropy for computing the new SA keys, it > is not evident that (2) below is correct. This is because the responder does > not know that the initiator can compute the correct SA keys for the new SA > until after it knows the peer has received its CREATE REPLY; it will be > sending traffic into a black hole if the CREATE REPLY is lost. The responder > should indeed receive on both old and new SA as (2) suggests, but perhaps it > may be better to continue sending on the old send SA until the DELETE from > the initiator arrives. Then if its CREATE REPLY never arrives, communication > can at least continue until the SA key expires. (In a two-phase commit > protocol, you don't commit until phase 2.) I believe that we can solve that by having the responder set the ACKREQ bit, which will cause the initiator to send an ACK. I definitely don't want it to be contingent on arrival of a DELETE because I think it's worthwhile to just allow the old SA to timeout. > > c. If you buy (b) above, then the initiator needs a retry timer for its > CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry > timer for CREATE REPLY (to ellicit a DELETE). s/DELETE/ACK and I agree. How about this text: In order to rekey a security association, a standard CREATE SA flow is initiated by the original initiator of the security association and it MUST set the ACKREQ to elicit a three way handshake. The old security association MAY be deleted after the new security association is created. In order to prevent ambiguity on which security association should be used, KINK mandates the following: o Receivers MUST be able to accept packets simultaneously on two security associations for otherwise identical flows. o If the CREATE REPLY has not arrived, the initiator MUST consider only the old SPI for sending and receiving traffic. o If the ACK has not arrived, the responder MUST choose the old SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following only apply if the initator desires to DELETE the old security association: o If the DELETE REPLY has not arrived, the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. For the initiator,it MUST accept traffic on either SPI, but only send on the new SPI. > e. We don't have any behavior for when an expected reply never arrives. I think I've covered the cases here. Can you find a hole? > Presumably we want to continue using the old SAs until their keys expire, Yes, unless there's proof the other side knows about the new SA. > but this is counter to the decisions discussed above about when to start > sending on the new SA. So maybe there isn't a retry limit on DELETEs? I've tweaked the above a bit; and heavens no on limitless retries :-) Mike From owner-ietf-kink Tue Dec 19 20:52:58 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA13435 for ietf-kink-bks; Tue, 19 Dec 2000 20:52:58 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA13431 for ; Tue, 19 Dec 2000 20:52:57 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA00408; Tue, 19 Dec 2000 20:55:41 -0800 (PST) Message-Id: <4.1.20001219205428.00b9fb30@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Dec 2000 20:58:05 -0800 To: ietf-kink@vpnc.org From: Jonathan Trostle Subject: 49th IETF KINK WG minutes Cc: jtrostle@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have enclosed the KINK WG meeting minutes. Please send any comments in the next two days. Thanks, Jonathan KINK WG Meeting Minutes (49th IETF at San Diego, CA, Tuesday, Dec. 12) Reported by Lisa Dussealt and Jonathan Trostle INTRODUCTION The first meeting of the KINK WG took place on December 12th, Tuesday 1-2PM at the 49th IETF. Derek Atkins and Jonathan Trostle opened the meeting with the following list of agenda items: KINK Agenda: KINK Requirements Draft - Mike Thomas KINK Key Management Draft - Mike Thomas Server Initiated Authentication - Sasha Medvinsky Artificial Phase 1 SA Key Management Draft - Tero Kivinen The immediate goals of the WG are to move the requirements draft into WG last call in January, and to proceed with standardization of a key management specification. KINK REQUIREMENTS ----------------------------------- The WG chairs plan to put the requirements draft into WG last call in January. The current requirements draft specifies that both symmetric key and public key (pkinit) clients must be supported; it was suggested that initial authentication is outside the scope of the draft. Initial authentication is mentioned in the draft since pkinit clients will not generally have a symmetric key in the Kerberos database, and the draft needs to accomodate such clients acting as servers (by using user-user authentication). The latter is a required scenario for packetcable security. There was some discussion on the list of whether the protocol must be capable of rekeying, but this seems to be outside of the scope of the work. Currently this is in the requirements document. Paul Hoffman stated that he would discuss it on the list. Derek stated that although it's a good goal to have, it's not a hard requirement. The question was raised whether there ought to be a requirement to work with IPSP. Marcus Leech stated that it should be the other way around: IPSP ought to work with the policies. KINK is an effector of these policies. Paul Hoffman mentioned that there was also interest in using other authentication protocols to fake a phase 1 SA in the same manner that Tero Kivinen's draft uses Kerberos to create the artificial phase 1 SA. For now, a general mechanism to allow other authentication mechanisms to be plugged in is out of scope. An audience member asked whether there ought to be motivation in the draft as well as requirements. In particular, more details on why RFC 2409 (IKE) is not adequate to solve the set of scenarios being targetted by the WG are desired. Derek and Mike Thomas indicated that additional concrete motivational suggestions would be welcome. Mike also suggested that the design documents explain the reasoning behind their choices. Scott Fluhrer asked about requirements for peer discovery; Jonathan Trostle replied that if you don't know who your peer is then there would be issues with respect to who you are authenticating. Mike stated that the issue appeared to be orthogonal. KINK KEY MANAGEMENT DRAFT ---------------------------------------------------- Michael Thomas led this discussion. The goals of the draft are to use Kerberos (AP_REQ and AP_REP) messages to establish an IPSEC SA using two messages (or three messages in some cases). The protocol uses a command, reply, and ack messages exchange: Initiator -------------> Responder CMD Initiator <------------ Responder REPLY Initiator -------------> Responder ACK Several message types are defined (create, delete, etc.) and these messages use a sequence of ISAKMP defined payloads (currently these payloads are defined by value in the draft). For example, the ISAKMP SA, proposal, and transform payloads are used in the create message to create a new SA. The draft also defines new messages to be used to obtain a peer's Kerberos ticket granting ticket (TGT) and to send a TGT to the peer, so that user-user authentication can be used. Using user-user authentication handles the case where the client is a pkinit client and does not have a long term key in the Kerberos database. Key derivation for the IPSEC SA is defined in the draft. The key derivation can be accomplished in the two message exchange if the responder is willing to not contribute to the keys for its outbound SA. If not, the responder sets the ack bit in the reply and the initiator will use the responder nonce as additional input into its inbound SA keys. Both initiator and responder nonces are used as input into the initiator's outbound SA keys. Mike Thomas sent some mail to the list regarding what is needed in order to rekey a security association. Jesse Walker's contention was that the text in the draft was not explicit enough, so Mike took some of his input from his last mail, and the current text is the result. Mike stated that we need to create a new SA that describes the new SA, basically for the same flow, and set up some rules for which SA to use at which times. Mike solicits comments on the WG list. Mike wants to clarify whether the initiator or responder can kill off whatever SA they like. Mike would like more examination of the key derivation material in the draft. He indicated that more work is needed on the error messages too. Mike looked at Freeswan/Pluto and hopes to have an implementation by the next IETF (March 2001). SERVER INITIATED AUTHENTICATION ---------------------------------------------------------- Sasha led the discussion here. Sasha's main concern is in a packetcable scenario where there are many clients communicating with a single server. There is a standby server that takes over when the first server fails. With the existing KINK draft user to user approach, the server must request the client's TGT and then obtain a service ticket targetted at the client. Sasha would like to send a new message, the wakeup message, from the server to the client to indicate to the client that it should obtain a service ticket for the server and then authenticate to the server. Thus some of the work is shifted from the server to the client thus improving scalability and performance of the server in this failover scenario. One concern that was expressed regarding Sasha's approach is that 3rd party denial of service attacks would be easy to launch and potentially difficult to track. In particular, a malicious peer could send wakeups (which are unauthenticated) to a large number of clients in order to bring down a given server(s) and also temporarily remove a KDC from service. Additionally, data would not flow earlier on the IPSEC SA. Alternative solutions include the sharing the ticket cache between the two servers, and pre-establishment of IPSEC SA's between the clients and the backup server. Sasha also raised some concerns regarding authorization data in tickets when using user-user authentication. Matt Hur and others disagreed with this line of reasoning, saying that the KDC could just as easily bind policy and authorization data for either the client or the server into the ticket. Additionally, some denial of service attacks might be mitigated if the client has an access control list which would prevent some wake up requests from being acted upon. Access control lists would not be applicable in all environments, and would only partially mitigate denial of service attacks in environments where they could be used. There was a desire to resolve this issue at the WG meeting rather than move the discussion to the WG list, but since roughly 10 people had read the draft, it was decided to move the discussion to the list and obtain consensus there. ARTIFICIAL KERBEROS IKE SA DRAFT ----------------------------------------------------------- Tero Kivinen presented his draft for KINK key management: draft-ietf-kink-ike-over-kkmp-00.txt. The draft uses a newly defined Kerberos payload to exchange the AP_REQ and AP_REP messages. At that point, the two peers share the Kerberos session key which is used to create the following shared state (corresponding to a successful phase 1 exchange): cookies, SKEYID for key material, and IV. Everything that is in IKE phase 2 can be supported: new group mode, quick mode, etc. Tero claimed that his draft is quite simple to implement. Tero has implemented IKE, and he stated that his new draft would take one day to implement. Tero also stated that any new features or improvements to phase 2 IKE could also be reflected in his work since it builds upon IKE. Tero noted that he needed to add the capability for Kerberos user-user messages. The Kerberos payload message in his draft could be used to transport KRB_TGT_REQ and KRB_TGT_REPLY messages, in order to support user to user messages. An audience member questioned the possibility of replays. Tero stated that if the SA is already valid, then they see there is duplicate SA numbers so they drop the packet immediately. When it doesn't see any traffic coming through, it doesn't do any expensive calculation. Derek pointed out that the Kerberos authenticator contains a timestamp to prevent replays. Another audience member also asked whether the Kerberos session key was big enough; the response was that the key is typed so it will be the right size for whatever crypto algorithm is being used. From owner-ietf-kink Thu Jan 4 10:36:33 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00427 for ietf-kink-bks; Thu, 4 Jan 2001 10:36:33 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00419 for ; Thu, 4 Jan 2001 10:36:31 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id NAA25847; Thu, 4 Jan 2001 13:40:57 -0500 To: ietf-kink@vpnc.org Cc: mat@cisco.com Subject: My comments on the KINK Requirements From: Derek Atkins Date: 04 Jan 2001 13:40:57 -0500 Message-ID: Lines: 120 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike (and everyone), Here are my comments on the requirements draft. I've put my comments inline with your draft pieces (and I've cut out areas where I have no comments). -derek Requirements KINK must meet the following requirements at a minimum: - The protocol must use Kerberos to create session keys in a secure fashion A side effect of this is that the protocol must use the Kerberos session key as part of the generation of IPSec keys. - The protocol must be able to start up SA's regardless of any client/server disposition in the keying protocol In other words, either IPSec peer can be the initiator or responder, regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server' (has a keytab). - Kerberos makes a distinction between clients and servers; IPsec does not. The protocol must allow for IPsec security associations to be initiated by both servers and clients, thus preserving IPsec's peer to peer nature. Isn't this the same thing, just said differently? - The protocol must be able to initially authenticate using either secret key, or public key authentication. - The protocol must accommodate any combination of public and secret key peers I'm not convinced we need to reference public/secret key. We just use what Kerberos provides. So, I think these two requirements can probably be rewritten to say: - The protocol must allow an initiator or a responder (or both) to authenticate with just a TGT (using Kerberos User-to-User). [snip] - The protocol must be capable of rekeying without the assistance of the KDC if the session ticket is still valid Using the phrase "Kerberos session ticket" is probably clearer. The following sections do not belong in the requirements draft: ---------begin Deliverables The working group's responsibilities are as follows: - Complete a protocol which meets the requirements outlined above - Keep all KINK working group documents moving along publication / standardization track. The list of the working group's current work items is as follows: - Define the base Kerberized Internet Negotiation of Keys protocol. Goals and Milestones Sep 2000 Consensus on requirements document Dec 2000 Review drafts at Dec IETF Jan 2001 Consensus on base draft protocol Mar 2001 WG Last call on draft Mar 2001-Jun 2001 Interoperability Bakeoffs Aug 2001 Interoperability results, decision to recycle or move for- ward Administrativa Chair(s): Derek Atkins Document Editor: TBD Internet Area Director(s): Jeffrey Schiller Marcus Leech Internet Area Advisor: TBD Mailing Lists: General Discussion: ietf-kink@vpnc.org To Subscribe: majordomo@vpnc.org In Body: in body: subscribe ietf-kink Archive: ftp:// ---------end -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Mon Jan 15 21:43:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA10178 for ietf-kink-bks; Mon, 15 Jan 2001 21:43:29 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10174 for ; Mon, 15 Jan 2001 21:43:27 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA25692; Mon, 15 Jan 2001 21:48:25 -0800 (PST) Message-Id: <4.1.20010115213717.00c432e0@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Jan 2001 21:51:11 -0800 To: smedvinsky@gi.com From: Jonathan Trostle Subject: KINK user-user scenario Cc: jtrostle@cisco.com, ietf-kink@vpnc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sasha, Does the following approach satisfy your concern regarding the app server having to do too much work in a failover scenario? The app server sends a TGT_REP message (basically containing its TGT) to the client, and the client then takes the TGT and uses it as an additional ticket in a TGS exchange with the KDC, and then sends an AP_REQ to the app server (using user-user mode). The advantage of this approach versus the packetcable wakeup message, from a DoS perspective, is that an attacker has to actually obtain the victim's TGT which should limit these types of attacks (the attacker has to be on the wire instead of on the other side of the Internet). And the majority of the work is shifted to the client instead of the app server. Jonathan From owner-ietf-kink Tue Jan 16 06:59:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02658 for ietf-kink-bks; Tue, 16 Jan 2001 06:59:11 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02654 for ; Tue, 16 Jan 2001 06:59:10 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA17396; Tue, 16 Jan 2001 10:04:28 -0500 To: Jonathan Trostle Cc: smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <4.1.20010115213717.00c432e0@nsm-mail2> From: Derek Atkins Date: 16 Jan 2001 10:04:28 -0500 In-Reply-To: Jonathan Trostle's message of "Mon, 15 Jan 2001 21:51:11 -0800" Message-ID: Lines: 45 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: An attacker can still cause the app-client and KDC to do work this way. Rememeber that the client cannot read the app-server's TGT, so it had no idea whether it is valid or who really sent it. Therefore, it has to blindly build a request around the TGT and send it to the KDC, not knowing if it's valid. The KDC then needs to process the request and build and return an error to the client (assuming it was forged). Luckily this wont affect the app-server, necessarily. Do we throw out any existing SA's in the process? (I would suggest that the answer is 'no'.) I would also think that we would need to have some level of request limiting so an attacker can't repeatedly bounce tons of messages off a single app-client. However you can still get a distributed attack against the KDC, because an attacker can build a single "fake" packet and send it to all the app-clients it can find. Then all those app-clients will blindly request out to the KDC. -derek Jonathan Trostle writes: > Sasha, > > Does the following approach satisfy your concern regarding the app server > having to do too much work in a failover scenario? > > The app server sends a TGT_REP message (basically containing its TGT) to > the client, and the client then takes the TGT and uses it as an additional > ticket in a TGS exchange with the KDC, and then sends an AP_REQ to the app > server (using user-user mode). The advantage of this approach versus the > packetcable wakeup message, from a DoS perspective, is that an attacker has > to actually obtain the victim's TGT which should limit these types of > attacks (the attacker has to be on the wire instead of on the other side of > the Internet). And the majority of the work is shifted to the client > instead of the app server. > > Jonathan -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Tue Jan 16 07:47:23 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08636 for ietf-kink-bks; Tue, 16 Jan 2001 07:47:23 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08628 for ; Tue, 16 Jan 2001 07:47:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA11011; Tue, 16 Jan 2001 07:52:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA23905; Tue, 16 Jan 2001 07:52:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14948.28199.233298.290353@thomasm-u1.cisco.com> Date: Tue, 16 Jan 2001 07:52:07 -0800 (PST) To: Derek Atkins Cc: Jonathan Trostle , smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-Reply-To: References: <4.1.20010115213717.00c432e0@nsm-mail2> 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: Derek Atkins writes: > Luckily this wont affect the app-server, necessarily. Do we throw out > any existing SA's in the process? (I would suggest that the answer is > 'no'.) Because of an unauthenticated request? I'd say "heavens no" :-) > I would also think that we would need to have some level of > request limiting so an attacker can't repeatedly bounce tons of > messages off a single app-client. Sure... this is true of every protocol which is subject to DoS attacks... which is every protocol, I suspect. The question I have is whether we need to be explicit here, or whether we could just point to a BCP-like document which outlines general strategies for coping with and/or narrowing DoS opportunities. > However you can still get a distributed attack against the KDC, > because an attacker can build a single "fake" packet and send it to > all the app-clients it can find. Then all those app-clients will > blindly request out to the KDC. Yes. This is the thing that really bothers me. A single well placed attacker could flood its n-B-T ethernet segment with U-U kinds of requests to high fan out gateways and slag an entire farm of KDC's. Since it's not coming from a point source, it makes it very hard to defend as well as trace back. Mike From owner-ietf-kink Tue Jan 16 15:28:36 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA04329 for ietf-kink-bks; Tue, 16 Jan 2001 15:28:36 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04325 for ; Tue, 16 Jan 2001 15:28:34 -0800 (PST) Received: from jtrostle-nt2 (dhcp-128-107-141-198.cisco.com [128.107.141.198]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id PAA11595; Tue, 16 Jan 2001 15:33:01 -0800 (PST) Message-Id: <4.1.20010116152508.00c416a0@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 16 Jan 2001 15:35:47 -0800 To: Derek Atkins , Jonathan Trostle From: Jonathan Trostle Subject: Re: KINK user-user scenario Cc: smedvinsky@gi.com, ietf-kink@vpnc.org In-Reply-To: References: <4.1.20010115213717.00c432e0@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:04 AM 1/16/01 -0500, Derek Atkins wrote: >An attacker can still cause the app-client and KDC to do work this >way. Rememeber that the client cannot read the app-server's TGT, so >it had no idea whether it is valid or who really sent it. Therefore, >it has to blindly build a request around the TGT and send it to the >KDC, not knowing if it's valid. The KDC then needs to process the >request and build and return an error to the client (assuming it was >forged). Right, but the situation isn't as bad (with respect to DoS attacks) as when using a pure wakeup approach. Of course, DoS attacks are even harder when using the approach currently specified. My thought was to find a middle ground between DoS attack concerns and having the app servers do less work. > >Luckily this wont affect the app-server, necessarily. Do we throw out >any existing SA's in the process? (I would suggest that the answer is >'no'.) I would also think that we would need to have some level of I would hope that no would be the right answer. >request limiting so an attacker can't repeatedly bounce tons of >messages off a single app-client. Makes sense. > >However you can still get a distributed attack against the KDC, >because an attacker can build a single "fake" packet and send it to >all the app-clients it can find. Then all those app-clients will >blindly request out to the KDC. True, but you can send unauthenticated messages to the KDC to do a DoS attack on a KDC. The difference is that you would have to trace from the app clients instead of the KDC, but tracing from the KDC might be easier. Jonathan > >-derek > >Jonathan Trostle writes: > >> Sasha, >> >> Does the following approach satisfy your concern regarding the app server >> having to do too much work in a failover scenario? >> >> The app server sends a TGT_REP message (basically containing its TGT) to >> the client, and the client then takes the TGT and uses it as an additional >> ticket in a TGS exchange with the KDC, and then sends an AP_REQ to the app >> server (using user-user mode). The advantage of this approach versus the >> packetcable wakeup message, from a DoS perspective, is that an attacker has >> to actually obtain the victim's TGT which should limit these types of >> attacks (the attacker has to be on the wire instead of on the other side of >> the Internet). And the majority of the work is shifted to the client >> instead of the app server. >> >> Jonathan > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ietf-kink Wed Jan 17 08:50:34 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17054 for ietf-kink-bks; Wed, 17 Jan 2001 08:50:34 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17050 for ; Wed, 17 Jan 2001 08:50:33 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id LAA01590; Wed, 17 Jan 2001 11:56:08 -0500 To: Jonathan Trostle Cc: smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> From: Derek Atkins Date: 17 Jan 2001 11:56:08 -0500 In-Reply-To: Jonathan Trostle's message of "Tue, 16 Jan 2001 15:35:47 -0800" Message-ID: Lines: 69 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jonathan Trostle writes: > Right, but the situation isn't as bad (with respect to DoS attacks) as when > using a pure wakeup approach. Of course, DoS attacks are even harder when > using the approach currently specified. My thought was to find a middle > ground between DoS attack concerns and having the app servers do less work. Clearly this is a question we need to ask the Working Group at large: Should we complicate the KINK protocol in order to support an architecure where the application servers don't want to store kerberos U2U tickets? Or perhaps a better phrasing is "which is more important, more protection against DoS style attacks or supporting an architecture where application servers don't store U2U tickets?" > True, but you can send unauthenticated messages to the KDC to do a DoS > attack on a KDC. The difference is that you would have to trace from the > app clients instead of the KDC, but tracing from the KDC might be easier. The other difference is that a) the attacker needs to do more work this way (they need to build a new request every time), and b) by bouncing off an application-client, they can cause even more traffic to hit the KDC. Not to mention that by bouncing the attacks they wind up reducing the individual flows to each app-client (making it harder to trace) while still having a large aggregation at the KDC, in addition to hiding their IP Address. I guess the real question that needs to be answered (and this may have to wait until Minneapolis when we can call for a show of hands) is which goal is more important? I think we'll have to make this choice, unless someone can come up with an approach that allows the initiator to handoff the Kerberos U2U request to the recipient while retaining the DoS protection characteristics of the current protocol. I can see one approach but it adds one extra message to the protocol: App-Client App-Server KDC <--- Inititate (1) GetTGT (2) ------> <----- U2U TGT (3) TGS_REQ ---------------------> <------------------------TGS_REP AP_REQ (4)-----> <------ AP_REP (5) Basically, if the initiator (the app-server in this case) knows it wants to handoff to the responder, then in the initiate message (1) it basically just sends a message that says "I want to initiate KINK with a handoff. Here's my cookie." The responder replies (2) with "Send your TGT. Here's your cookie back." The initiator can verify the cookie (so it wont do extra work) and then the standard KINK U2U continues: (3) send TGT with cookie (to continue transaction) (4) U2U AP_REQ (5) AP_REP So basicaly we add one extra message here (#1) that is basically an "initiate handoff" message but no real work is happens until after message 3. But the only way to get to message three is if both initiator and responder agree to complete a protocol. We would also need to add a flag to the GetTGT message to say whether it's being used as an initiate or a response. So, what do people think of this proposal? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Wed Jan 17 13:57:57 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA02308 for ietf-kink-bks; Wed, 17 Jan 2001 13:57:57 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02303 for ; Wed, 17 Jan 2001 13:57:55 -0800 (PST) Received: from jtrostle-nt2 (dhcp-128-107-141-198.cisco.com [128.107.141.198]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA09711; Wed, 17 Jan 2001 14:03:00 -0800 (PST) Message-Id: <4.1.20010117135355.00c1ea30@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Jan 2001 14:05:47 -0800 To: Derek Atkins , Jonathan Trostle From: Jonathan Trostle Subject: Re: KINK user-user scenario Cc: smedvinsky@gi.com, ietf-kink@vpnc.org In-Reply-To: References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:56 AM 1/17/01 -0500, Derek Atkins wrote: >Jonathan Trostle writes: > >> Right, but the situation isn't as bad (with respect to DoS attacks) as when >> using a pure wakeup approach. Of course, DoS attacks are even harder when >> using the approach currently specified. My thought was to find a middle >> ground between DoS attack concerns and having the app servers do less work. > >Clearly this is a question we need to ask the Working Group at large: >Should we complicate the KINK protocol in order to support an >architecure where the application servers don't want to store kerberos >U2U tickets? Or perhaps a better phrasing is "which is more >important, more protection against DoS style attacks or supporting an >architecture where application servers don't store U2U tickets?" > >> True, but you can send unauthenticated messages to the KDC to do a DoS >> attack on a KDC. The difference is that you would have to trace from the >> app clients instead of the KDC, but tracing from the KDC might be easier. > >The other difference is that a) the attacker needs to do more work >this way (they need to build a new request every time), and b) by Not clear to me why the request would be different each time except for the IP address which the attacker would change for each request anyway. An attacker can easily build AS requests in advance and use these to saturate a KDC, without any help from other hosts. >bouncing off an application-client, they can cause even more traffic >to hit the KDC. Not to mention that by bouncing the attacks they wind >up reducing the individual flows to each app-client (making it harder >to trace) while still having a large aggregation at the KDC, in >addition to hiding their IP Address. > >I guess the real question that needs to be answered (and this may have >to wait until Minneapolis when we can call for a show of hands) is >which goal is more important? I think we'll have to make this choice, >unless someone can come up with an approach that allows the initiator >to handoff the Kerberos U2U request to the recipient while retaining >the DoS protection characteristics of the current protocol. > >I can see one approach but it adds one extra message to the protocol: > >App-Client App-Server KDC > <--- Inititate (1) > GetTGT (2) ------> > <----- U2U TGT (3) > TGS_REQ ---------------------> > <------------------------TGS_REP > AP_REQ (4)-----> > <------ AP_REP (5) > >Basically, if the initiator (the app-server in this case) knows it >wants to handoff to the responder, then in the initiate message (1) it >basically just sends a message that says "I want to initiate KINK with >a handoff. Here's my cookie." The responder replies (2) with "Send >your TGT. Here's your cookie back." The initiator can verify the >cookie (so it wont do extra work) and then the standard KINK U2U >continues: (3) send TGT with cookie (to continue transaction) (4) U2U >AP_REQ (5) AP_REP > >So basicaly we add one extra message here (#1) that is basically an >"initiate handoff" message but no real work is happens until after >message 3. But the only way to get to message three is if both >initiator and responder agree to complete a protocol. We would also >need to add a flag to the GetTGT message to say whether it's being >used as an initiate or a response. > >So, what do people think of this proposal? Interesting protocol, but one issue in the past has been the need to get data flowing over an SA after a minimum number of messages. Jonathan > >-derek > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Jan 18 07:30:10 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15550 for ietf-kink-bks; Thu, 18 Jan 2001 07:30:10 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15537 for ; Thu, 18 Jan 2001 07:30:08 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA02264; Thu, 18 Jan 2001 10:35:47 -0500 To: Jonathan Trostle Cc: smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> <4.1.20010117135355.00c1ea30@nsm-mail2> From: Derek Atkins Date: 18 Jan 2001 10:35:47 -0500 In-Reply-To: Jonathan Trostle's message of "Wed, 17 Jan 2001 14:05:47 -0800" Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jonathan Trostle writes: > Not clear to me why the request would be different each time except for the > IP address which the attacker would change for each request anyway. An > attacker can easily build AS requests in advance and use these to saturate > a KDC, without any help from other hosts. The KDC keeps a replay cache. The first thing it does is check to see if it's seen the request before, and if it has, then it ignores it. This means that an attacker change the request for every message. Granted, this just implies changing one byte, but it also must change the checksum as well. A MUCH easier attack would be to generate a single "TGT" and send it off to a thousand app-clients, each of which will expend energy building a "real" message for the KDC. I've just reduced the attacker's overhead by 1000:1. The benefits of this attack are two-fold. One, it's much less work for the attacker. Two, it hides the attacker's address because there are only low-level flows to each app-client and nothing to the KDC. > Interesting protocol, but one issue in the past has been the need to get > data flowing over an SA after a minimum number of messages. This is true. However I believe that that an Initiator Handoff is a special case scenario and not something that happens very often or in very many cases. In most cases I would think that KINK would be used as a true peer-to-peer protocol. Adding one extra message to a special case scenario is not, IMHO, a showstopper. But let's see what others in the WG think. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Jan 18 07:55:28 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18630 for ietf-kink-bks; Thu, 18 Jan 2001 07:55:28 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18625 for ; Thu, 18 Jan 2001 07:55:26 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id f0IG0s902662; Thu, 18 Jan 2001 11:00:54 -0500 (EST) Message-Id: <200101181600.f0IG0s902662@ginger.cmf.nrl.navy.mil> To: Derek Atkins cc: ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-reply-to: Your message of "18 Jan 2001 10:35:47 EST." 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, 18 Jan 2001 11:00:54 -0500 From: Ken Hornstein Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >The KDC keeps a replay cache. The first thing it does is check to see >if it's seen the request before, and if it has, then it ignores it. FYI - I'm not sure that's true anymore (for example, recent MIT releases have the KDC replay cache turned off). --Ken From owner-ietf-kink Thu Jan 18 10:34:01 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA28123 for ietf-kink-bks; Thu, 18 Jan 2001 10:34:01 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28119 for ; Thu, 18 Jan 2001 10:34:00 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA29112; Thu, 18 Jan 2001 10:39:05 -0800 (PST) Message-Id: <4.1.20010118092229.00c2f150@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Jan 2001 10:41:53 -0800 To: Derek Atkins , Jonathan Trostle From: Jonathan Trostle Subject: Re: KINK user-user scenario Cc: smedvinsky@gi.com, ietf-kink@vpnc.org In-Reply-To: References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> <4.1.20010117135355.00c1ea30@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:35 AM 1/18/01 -0500, Derek Atkins wrote: >Jonathan Trostle writes: > >> Not clear to me why the request would be different each time except for the >> IP address which the attacker would change for each request anyway. An >> attacker can easily build AS requests in advance and use these to saturate >> a KDC, without any help from other hosts. > >The KDC keeps a replay cache. The first thing it does is check to see >if it's seen the request before, and if it has, then it ignores it. >This means that an attacker change the request for every message. >Granted, this just implies changing one byte, but it also must change >the checksum as well. There is no checksum in the AS request. > >A MUCH easier attack would be to generate a single "TGT" and send it >off to a thousand app-clients, each of which will expend energy >building a "real" message for the KDC. I've just reduced the >attacker's overhead by 1000:1. The benefits of this attack are >two-fold. One, it's much less work for the attacker. Two, it hides >the attacker's address because there are only low-level flows to each >app-client and nothing to the KDC. TGT's are captured off the wire, unless the attacker wants to use his own TGT which is unlikely. So this localizes the attack to a particular principal's location and is a good place to initiate intrusion detection. Jonathan > >> Interesting protocol, but one issue in the past has been the need to get >> data flowing over an SA after a minimum number of messages. > >This is true. However I believe that that an Initiator Handoff is a >special case scenario and not something that happens very often or in >very many cases. In most cases I would think that KINK would be used >as a true peer-to-peer protocol. Adding one extra message to a >special case scenario is not, IMHO, a showstopper. But let's see what >others in the WG think. > >-derek > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Jan 18 10:49:59 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA28650 for ietf-kink-bks; Thu, 18 Jan 2001 10:49:59 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28646 for ; Thu, 18 Jan 2001 10:49:58 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id NAA23287; Thu, 18 Jan 2001 13:55:33 -0500 To: Jonathan Trostle Cc: smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> <4.1.20010117135355.00c1ea30@nsm-mail2> <4.1.20010118092229.00c2f150@nsm-mail2> From: Derek Atkins Date: 18 Jan 2001 13:55:33 -0500 In-Reply-To: Jonathan Trostle's message of "Thu, 18 Jan 2001 10:41:53 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jonathan Trostle writes: > TGT's are captured off the wire, unless the attacker wants to use his own > TGT which is unlikely. So this localizes the attack to a particular > principal's location and is a good place to initiate intrusion detection. Who says an attacker needs to use a real TGT? The TGT need only look valid enough that: a) the client believes it is a TGT and forwards it to the KDC, and b) the KDC believes it is a TGT and tries to decrypt it. Keep in mind that a client usually cannot do much in terms of TGT validation. It certainly cannot decrypt the TGT. All it can do is look at the ASN.1 formatting and make sure it looks like a TGT. Similarly, the KDC just needs to get far enough in the ASN.1 encoding to actually try to decrypt the TGT. This means an attacker does not have to capture anything off the wire in order to mount this attack. They just build a fake TGT using the ASN.1 encoding, a "known service principal", and then use any random key to encrypt the encrypted portion of the TGT. It doesn't matter that the KDC can't decrypt it; that's the point -- you want the KDC to _try_ to decrypt it and fail. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Jan 18 11:56:51 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03043 for ietf-kink-bks; Thu, 18 Jan 2001 11:56:51 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03039 for ; Thu, 18 Jan 2001 11:56:50 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZ1VP8QSSYF0JSZH@GI.COM> for ietf-kink@vpnc.org; Thu, 18 Jan 2001 12:01:54 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 11:59:08 -0500 Content-return: allowed Date: Thu, 18 Jan 2001 15:02:54 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK user-user scenario To: "'Jonathan Trostle'" , Derek Atkins Cc: ietf-kink@vpnc.org Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4AE8@NTAS0027> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jonathan, Yes there is a checksum in the AS Request - if you are using a pre-authenticator such as an encrypted timestamp or PKINIT. These preauthenticators now contain a checksum over the request message body. Sasha. > -----Original Message----- > From: Jonathan Trostle [mailto:jtrostle@cisco.com] > Sent: Thursday, January 18, 2001 10:42 AM > To: Derek Atkins; Jonathan Trostle > Cc: smedvinsky@GI.COM; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > At 10:35 AM 1/18/01 -0500, Derek Atkins wrote: > >Jonathan Trostle writes: > > > >> Not clear to me why the request would be different each > time except for the > >> IP address which the attacker would change for each > request anyway. An > >> attacker can easily build AS requests in advance and use > these to saturate > >> a KDC, without any help from other hosts. > > > >The KDC keeps a replay cache. The first thing it does is > check to see > >if it's seen the request before, and if it has, then it ignores it. > >This means that an attacker change the request for every message. > >Granted, this just implies changing one byte, but it also must change > >the checksum as well. > > There is no checksum in the AS request. > > > > >A MUCH easier attack would be to generate a single "TGT" and send it > >off to a thousand app-clients, each of which will expend energy > >building a "real" message for the KDC. I've just reduced the > >attacker's overhead by 1000:1. The benefits of this attack are > >two-fold. One, it's much less work for the attacker. Two, it hides > >the attacker's address because there are only low-level flows to each > >app-client and nothing to the KDC. > > TGT's are captured off the wire, unless the attacker wants to > use his own > TGT which is unlikely. So this localizes the attack to a particular > principal's location and is a good place to initiate > intrusion detection. > > Jonathan > > > > >> Interesting protocol, but one issue in the past has been > the need to get > >> data flowing over an SA after a minimum number of messages. > > > >This is true. However I believe that that an Initiator Handoff is a > >special case scenario and not something that happens very often or in > >very many cases. In most cases I would think that KINK would be used > >as a true peer-to-peer protocol. Adding one extra message to a > >special case scenario is not, IMHO, a showstopper. But > let's see what > >others in the WG think. > > > >-derek > > > >-- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > From owner-ietf-kink Thu Jan 18 12:55:32 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA06230 for ietf-kink-bks; Thu, 18 Jan 2001 12:55:32 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06226 for ; Thu, 18 Jan 2001 12:55:31 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA10020; Thu, 18 Jan 2001 13:00:38 -0800 (PST) Message-Id: <4.1.20010118114717.00c3e3d0@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Jan 2001 13:03:26 -0800 To: Derek Atkins , Jonathan Trostle From: Jonathan Trostle Subject: Re: KINK user-user scenario Cc: smedvinsky@gi.com, ietf-kink@vpnc.org In-Reply-To: References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> <4.1.20010117135355.00c1ea30@nsm-mail2> <4.1.20010118092229.00c2f150@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Kerberos is vulnerable to these types of DoS attacks already. For example, an attacker can create a delegated request targetted at himself with a bogus krb creds inside and then send that out in multiple delegated request to 1000 servers which then try to authenticate to the KDC using the bogus krb creds. I'm not convinced we should go to a lot of work to try to prevent these types of attacks, because we will only be able to give some improvement to a few cases instead of all the cases. Some sort of IDS system would probably be needed to handle these types of attacks and might do an equally good job against all of them. Jonathan At 01:55 PM 1/18/01 -0500, Derek Atkins wrote: >Jonathan Trostle writes: > >> TGT's are captured off the wire, unless the attacker wants to use his own >> TGT which is unlikely. So this localizes the attack to a particular >> principal's location and is a good place to initiate intrusion detection. > >Who says an attacker needs to use a real TGT? The TGT need only look >valid enough that: > > a) the client believes it is a TGT and forwards it to the KDC, and > b) the KDC believes it is a TGT and tries to decrypt it. > >Keep in mind that a client usually cannot do much in terms of TGT >validation. It certainly cannot decrypt the TGT. All it can do is >look at the ASN.1 formatting and make sure it looks like a TGT. >Similarly, the KDC just needs to get far enough in the ASN.1 encoding >to actually try to decrypt the TGT. > >This means an attacker does not have to capture anything off the wire >in order to mount this attack. They just build a fake TGT using the >ASN.1 encoding, a "known service principal", and then use any random >key to encrypt the encrypted portion of the TGT. It doesn't matter >that the KDC can't decrypt it; that's the point -- you want the KDC to >_try_ to decrypt it and fail. > >-derek > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ietf-kink Thu Jan 18 13:44:39 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08782 for ietf-kink-bks; Thu, 18 Jan 2001 13:44:39 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08778 for ; Thu, 18 Jan 2001 13:44:37 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA13395; Thu, 18 Jan 2001 13:49:46 -0800 (PST) Message-Id: <4.1.20010118135027.00c3d210@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Jan 2001 13:52:34 -0800 To: "Medvinsky, Sasha (SD-EX)" , "'Jonathan Trostle'" , Derek Atkins From: Jonathan Trostle Subject: RE: KINK user-user scenario Cc: ietf-kink@vpnc.org In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD4AE8@NTAS0027> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The KDC will process an AS request without a preauthenticator. It doesn't really matter though, since as Derek points out, the preauthenticator does not need to be valid in order to force the KDC to do work. Jonathan At 03:02 PM 1/18/01 -0500, Medvinsky, Sasha (SD-EX) wrote: >Jonathan, > >Yes there is a checksum in the AS Request - if you are using a >pre-authenticator such as an encrypted timestamp or PKINIT. These >preauthenticators now contain a checksum over the request message body. > >Sasha. > >> -----Original Message----- >> From: Jonathan Trostle [mailto:jtrostle@cisco.com] >> Sent: Thursday, January 18, 2001 10:42 AM >> To: Derek Atkins; Jonathan Trostle >> Cc: smedvinsky@GI.COM; ietf-kink@vpnc.org >> Subject: Re: KINK user-user scenario >> >> >> At 10:35 AM 1/18/01 -0500, Derek Atkins wrote: >> >Jonathan Trostle writes: >> > >> >> Not clear to me why the request would be different each >> time except for the >> >> IP address which the attacker would change for each >> request anyway. An >> >> attacker can easily build AS requests in advance and use >> these to saturate >> >> a KDC, without any help from other hosts. >> > >> >The KDC keeps a replay cache. The first thing it does is >> check to see >> >if it's seen the request before, and if it has, then it ignores it. >> >This means that an attacker change the request for every message. >> >Granted, this just implies changing one byte, but it also must change >> >the checksum as well. >> >> There is no checksum in the AS request. >> >> > >> >A MUCH easier attack would be to generate a single "TGT" and send it >> >off to a thousand app-clients, each of which will expend energy >> >building a "real" message for the KDC. I've just reduced the >> >attacker's overhead by 1000:1. The benefits of this attack are >> >two-fold. One, it's much less work for the attacker. Two, it hides >> >the attacker's address because there are only low-level flows to each >> >app-client and nothing to the KDC. >> >> TGT's are captured off the wire, unless the attacker wants to >> use his own >> TGT which is unlikely. So this localizes the attack to a particular >> principal's location and is a good place to initiate >> intrusion detection. >> >> Jonathan >> >> > >> >> Interesting protocol, but one issue in the past has been >> the need to get >> >> data flowing over an SA after a minimum number of messages. >> > >> >This is true. However I believe that that an Initiator Handoff is a >> >special case scenario and not something that happens very often or in >> >very many cases. In most cases I would think that KINK would be used >> >as a true peer-to-peer protocol. Adding one extra message to a >> >special case scenario is not, IMHO, a showstopper. But >> let's see what >> >others in the WG think. >> > >> >-derek >> > >> >-- >> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> > Member, MIT Student Information Processing Board (SIPB) >> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> > warlord@MIT.EDU PGP key available >> From owner-ietf-kink Thu Jan 18 14:14:05 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA09793 for ietf-kink-bks; Thu, 18 Jan 2001 14:14:05 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09789 for ; Thu, 18 Jan 2001 14:14:03 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZ20INCBJKF0JSZM@GI.COM> for ietf-kink@vpnc.org; Thu, 18 Jan 2001 14:19:16 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 14:17:22 -0500 Content-return: allowed Date: Thu, 18 Jan 2001 17:20:59 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK user-user scenario To: "'Derek Atkins'" , Jonathan Trostle Cc: ietf-kink@vpnc.org Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4AF1@NTAS0027> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, In your flows below, I would make the flows (2) and (3) optional, since U2U is optional in Kerberos. Flows (2) and (3) add some extra non-cryptographic work for the attacker trying to do the denial of service, but also adds extra work and messages to the protocol. So, I would make them optional, if you want that extra protection against denial of service, where the denial of service applies when the app-client doesn't use access control when receiving the 'Initiate' message. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Wednesday, January 17, 2001 8:56 AM > To: Jonathan Trostle > Cc: smedvinsky@GI.COM; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > Jonathan Trostle writes: > > > Right, but the situation isn't as bad (with respect to DoS > attacks) as when > > using a pure wakeup approach. Of course, DoS attacks are > even harder when > > using the approach currently specified. My thought was to > find a middle > > ground between DoS attack concerns and having the app > servers do less work. > > Clearly this is a question we need to ask the Working Group at large: > Should we complicate the KINK protocol in order to support an > architecure where the application servers don't want to store kerberos > U2U tickets? Or perhaps a better phrasing is "which is more > important, more protection against DoS style attacks or supporting an > architecture where application servers don't store U2U tickets?" > > > True, but you can send unauthenticated messages to the KDC > to do a DoS > > attack on a KDC. The difference is that you would have to > trace from the > > app clients instead of the KDC, but tracing from the KDC > might be easier. > > The other difference is that a) the attacker needs to do more work > this way (they need to build a new request every time), and b) by > bouncing off an application-client, they can cause even more traffic > to hit the KDC. Not to mention that by bouncing the attacks they wind > up reducing the individual flows to each app-client (making it harder > to trace) while still having a large aggregation at the KDC, in > addition to hiding their IP Address. > > I guess the real question that needs to be answered (and this may have > to wait until Minneapolis when we can call for a show of hands) is > which goal is more important? I think we'll have to make this choice, > unless someone can come up with an approach that allows the initiator > to handoff the Kerberos U2U request to the recipient while retaining > the DoS protection characteristics of the current protocol. > > I can see one approach but it adds one extra message to the protocol: > > App-Client App-Server KDC > <--- Inititate (1) > GetTGT (2) ------> > <----- U2U TGT (3) > TGS_REQ ---------------------> > <------------------------TGS_REP > AP_REQ (4)-----> > <------ AP_REP (5) > > Basically, if the initiator (the app-server in this case) knows it > wants to handoff to the responder, then in the initiate message (1) it > basically just sends a message that says "I want to initiate KINK with > a handoff. Here's my cookie." The responder replies (2) with "Send > your TGT. Here's your cookie back." The initiator can verify the > cookie (so it wont do extra work) and then the standard KINK U2U > continues: (3) send TGT with cookie (to continue transaction) (4) U2U > AP_REQ (5) AP_REP > > So basicaly we add one extra message here (#1) that is basically an > "initiate handoff" message but no real work is happens until after > message 3. But the only way to get to message three is if both > initiator and responder agree to complete a protocol. We would also > need to add a flag to the GetTGT message to say whether it's being > used as an initiate or a response. > > So, what do people think of this proposal? > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink Thu Jan 18 16:31:38 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18241 for ietf-kink-bks; Thu, 18 Jan 2001 16:31:38 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18237 for ; Thu, 18 Jan 2001 16:31:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA18477; Thu, 18 Jan 2001 16:36:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA24792; Thu, 18 Jan 2001 16:36:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.35870.729168.267643@thomasm-u1.cisco.com> Date: Thu, 18 Jan 2001 16:36:46 -0800 (PST) To: Jonathan Trostle Cc: Derek Atkins , smedvinsky@gi.com, ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-Reply-To: <4.1.20010118114717.00c3e3d0@nsm-mail2> References: <4.1.20010115213717.00c432e0@nsm-mail2> <4.1.20010116152508.00c416a0@nsm-mail2> <4.1.20010117135355.00c1ea30@nsm-mail2> <4.1.20010118092229.00c2f150@nsm-mail2> <4.1.20010118114717.00c3e3d0@nsm-mail2> 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: Jonathan Trostle writes: > Kerberos is vulnerable to these types of DoS attacks already. For example, > an attacker can create a delegated request targetted at himself with a > bogus krb creds inside and then send that out in multiple delegated request > to 1000 servers which then try to authenticate to the KDC using the bogus > krb creds. > > I'm not convinced we should go to a lot of work to try to prevent these > types of attacks, because we will only be able to give some improvement to > a few cases instead of all the cases. Some sort of IDS system would > probably be needed to handle these types of attacks and might do an equally > good job against all of them. As currently instantiated in draft-ietf-kink-kink-00, this DoS attack does not exist. Adding some sort of wakeup mechanism explicitly allows the attack. I'd say that these proposals go out their way to *allow* the attack. That to my mind is bogus. Mike From owner-ietf-kink Thu Jan 18 16:50:37 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18572 for ietf-kink-bks; Thu, 18 Jan 2001 16:50:37 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18568 for ; Thu, 18 Jan 2001 16:50:35 -0800 (PST) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA25816; Thu, 18 Jan 2001 16:56:04 -0800 (PST) Received: from mhur-w2k.cisco.com (sjc-vpn-243.cisco.com [10.21.64.243]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id ABV12494; Thu, 18 Jan 2001 16:55:46 -0800 (PST) Message-Id: <4.3.2.7.2.20010118143924.03e6df98@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jan 2001 14:42:04 -0800 To: Derek Atkins , ietf-kink@vpnc.org From: Matthew Hur Subject: Re: My comments on the KINK Requirements Cc: mat@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:40 PM 1/4/2001 -0500, Derek Atkins wrote: >- The protocol must be able to initially authenticate using either > secret key, or public key authentication. > >- The protocol must accommodate any combination of public and secret > key peers > >I'm not convinced we need to reference public/secret key. We just use >what Kerberos provides. So, I think these two requirements can >probably be rewritten to say: > > - The protocol must allow an initiator or a responder (or both) to > authenticate with just a TGT (using Kerberos User-to-User). I'm not sure that this is very clear either. How about: - The protocol must support Kerberos User-to-User mode for cases in which a principal does not have an entry in the Kerberos principal database (i.e. uses PKINIT). From owner-ietf-kink Fri Jan 19 07:20:06 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA20945 for ietf-kink-bks; Fri, 19 Jan 2001 07:20:06 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20931 for ; Fri, 19 Jan 2001 07:20:04 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA01968; Fri, 19 Jan 2001 10:25:39 -0500 To: Matthew Hur Cc: ietf-kink@vpnc.org, mat@cisco.com Subject: Re: My comments on the KINK Requirements References: <4.3.2.7.2.20010118143924.03e6df98@mira-sjc5-5.cisco.com> From: Derek Atkins Date: 19 Jan 2001 10:25:39 -0500 In-Reply-To: Matthew Hur's message of "Thu, 18 Jan 2001 14:42:04 -0800" Message-ID: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Hur writes: > > > > - The protocol must allow an initiator or a responder (or both) to > > authenticate with just a TGT (using Kerberos User-to-User). > > I'm not sure that this is very clear either. How about: > - The protocol must support Kerberos User-to-User mode for cases in which > a principal does not have an entry in the Kerberos principal database (i.e. > uses PKINIT). Unfortunately this ignores the case where the principal DOES have an entry in the KDC but doesn't have a keytab (i.e. a Kerberos User). I was trying to cover both cases. Perhaps: - The protocol must support Kerberos User-to-User mode for cases in which the initiator cannot obtain an AP_REQ for the responder (i.e. the responder is a PKINIT client) or the responder cannot decrypt and AP_REQ from the initiator (i.e. the ressponder doesn't have a Kerberos Keytab, just a TGT). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Fri Jan 19 11:10:38 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA01551 for ietf-kink-bks; Fri, 19 Jan 2001 11:10:38 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01547 for ; Fri, 19 Jan 2001 11:10:36 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA17518; Fri, 19 Jan 2001 14:16:05 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4AF1@NTAS0027> From: Derek Atkins Date: 19 Jan 2001 14:16:05 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Thu, 18 Jan 2001 17:20:59 -0500" Message-ID: Lines: 159 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > Derek, > > In your flows below, I would make the flows (2) and (3) optional, since U2U > is optional in Kerberos. Flows (2) and (3) add some extra non-cryptographic Um, where do you find that? Section 9.1 of RFC 1510 says that User-to-user is ""mandatory to implement" but is "may be disabled by policy". So, where are you getting the fact that U2U is optional in Kerberos? > work for the attacker trying to do the denial of service, but also adds > extra work and messages to the protocol. So, I would make them optional, if > you want that extra protection against denial of service, where the denial > of service applies when the app-client doesn't use access control when > receiving the 'Initiate' message. Honestly, I'd prefer to have as few optional parts of the KINK protocol as possible. I'd like to have a simple state machine that describes the full protocol, limiting optional portions. As soon as you start down the "make that optional" path, you start down the same path as IKE. I'd like not to make that same mistake. Now, I will certainly conceed that in an Initiator-Handoff situation the "responder" may be able to obtain an AP_REQ directly for the initiator, which implies that you don't need to use User-to-User. In _that_ case, yes, we should allow the use of a direct AP_REQ instead of the U2U flow, and we can solve the DoS case by doing the same thing with cookies. When the responder send's its AP_REQ to the initiator in response to the Handoff, it includes the cookie from the Initiator. That way the Initiator need not do any work unless the cookie is recognized. So, we have this (more complete) flow of the Initiator-Handoff sub-protocol: App-Client App-Server KDC <--- Inititate { if no ticket is cached ... { direct case: TGS_REQ ---------------------> <------------------------TGS_REP } { U2U case (or if direct case failed): GetTGT* ---------> <---------- U2U TGT TGS_REQ ---------------------> <------------------------TGS_REP } } AP_REQ* --------> <--------- AP_REP Basically, the whole protocol beyond the Initiate is the same "KINK" protocol, except that the GetTGT or AP_REQ need to be differentiated in a way that the server can tell that it is a response to an Initiate-Handoff message rather than a regular KINK Initiate. Does this work for you, Sasha? I think that this still protects us from the DoS attacks. -derek > Sasha. > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@mit.edu] > > Sent: Wednesday, January 17, 2001 8:56 AM > > To: Jonathan Trostle > > Cc: smedvinsky@GI.COM; ietf-kink@vpnc.org > > Subject: Re: KINK user-user scenario > > > > > > Jonathan Trostle writes: > > > > > Right, but the situation isn't as bad (with respect to DoS > > attacks) as when > > > using a pure wakeup approach. Of course, DoS attacks are > > even harder when > > > using the approach currently specified. My thought was to > > find a middle > > > ground between DoS attack concerns and having the app > > servers do less work. > > > > Clearly this is a question we need to ask the Working Group at large: > > Should we complicate the KINK protocol in order to support an > > architecure where the application servers don't want to store kerberos > > U2U tickets? Or perhaps a better phrasing is "which is more > > important, more protection against DoS style attacks or supporting an > > architecture where application servers don't store U2U tickets?" > > > > > True, but you can send unauthenticated messages to the KDC > > to do a DoS > > > attack on a KDC. The difference is that you would have to > > trace from the > > > app clients instead of the KDC, but tracing from the KDC > > might be easier. > > > > The other difference is that a) the attacker needs to do more work > > this way (they need to build a new request every time), and b) by > > bouncing off an application-client, they can cause even more traffic > > to hit the KDC. Not to mention that by bouncing the attacks they wind > > up reducing the individual flows to each app-client (making it harder > > to trace) while still having a large aggregation at the KDC, in > > addition to hiding their IP Address. > > > > I guess the real question that needs to be answered (and this may have > > to wait until Minneapolis when we can call for a show of hands) is > > which goal is more important? I think we'll have to make this choice, > > unless someone can come up with an approach that allows the initiator > > to handoff the Kerberos U2U request to the recipient while retaining > > the DoS protection characteristics of the current protocol. > > > > I can see one approach but it adds one extra message to the protocol: > > > > App-Client App-Server KDC > > <--- Inititate (1) > > GetTGT (2) ------> > > <----- U2U TGT (3) > > TGS_REQ ---------------------> > > <------------------------TGS_REP > > AP_REQ (4)-----> > > <------ AP_REP (5) > > > > Basically, if the initiator (the app-server in this case) knows it > > wants to handoff to the responder, then in the initiate message (1) it > > basically just sends a message that says "I want to initiate KINK with > > a handoff. Here's my cookie." The responder replies (2) with "Send > > your TGT. Here's your cookie back." The initiator can verify the > > cookie (so it wont do extra work) and then the standard KINK U2U > > continues: (3) send TGT with cookie (to continue transaction) (4) U2U > > AP_REQ (5) AP_REP > > > > So basicaly we add one extra message here (#1) that is basically an > > "initiate handoff" message but no real work is happens until after > > message 3. But the only way to get to message three is if both > > initiator and responder agree to complete a protocol. We would also > > need to add a flag to the GetTGT message to say whether it's being > > used as an initiate or a response. > > > > So, what do people think of this proposal? > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Tue Jan 23 16:28:31 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16648 for ietf-kink-bks; Tue, 23 Jan 2001 16:28:31 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16644 for ; Tue, 23 Jan 2001 16:28:30 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA04852; Tue, 23 Jan 2001 16:33:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR00038; Tue, 23 Jan 2001 16:33:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26706; Tue, 23 Jan 2001 16:33:28 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.8919.920126.391626@thomasm-u1.cisco.com> Date: Tue, 23 Jan 2001 16:33:27 -0800 (PST) To: Derek Atkins Cc: "Medvinsky, Sasha (SD-EX)" , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-Reply-To: References: <97DEDE66B3DCD11199D200805FA71BE202FD4AF1@NTAS0027> 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: Derek Atkins writes: > App-Client App-Server KDC > <--- Inititate > > { if no ticket is cached ... > > { direct case: > TGS_REQ ---------------------> > <------------------------TGS_REP > } > { U2U case (or if direct case failed): > GetTGT* ---------> > <---------- U2U TGT > TGS_REQ ---------------------> > <------------------------TGS_REP > } > } > > AP_REQ* --------> > <--------- AP_REP > > Basically, the whole protocol beyond the Initiate is the same "KINK" > protocol, except that the GetTGT or AP_REQ need to be differentiated > in a way that the server can tell that it is a response to an > Initiate-Handoff message rather than a regular KINK Initiate. > > Does this work for you, Sasha? I think that this still protects us > from the DoS attacks. How so? This looks the same to me as any other wakeup scheme: a minimal amount of work by the attacker (the "server" in your diagram) causes the attacked (client, KDC) to generate a non-minimal amount of work and traffic. This looks like the same old Zombie kind of attack as before. Mike From owner-ietf-kink Tue Jan 23 16:45:49 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16985 for ietf-kink-bks; Tue, 23 Jan 2001 16:45:49 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16981 for ; Tue, 23 Jan 2001 16:45:47 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA21736; Tue, 23 Jan 2001 16:51:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR00039; Tue, 23 Jan 2001 16:51:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26759; Tue, 23 Jan 2001 16:51:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.9993.50274.374931@thomasm-u1.cisco.com> Date: Tue, 23 Jan 2001 16:51:21 -0800 (PST) To: Derek Atkins Cc: ietf-kink@vpnc.org, mat@cisco.com Subject: My comments on the KINK Requirements In-Reply-To: References: 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: So, I'm trying to collect the conclusion of this thread to finalize the requirements draft. I'd like to get this done soon. I'll respond to each of these, and hopefully we can wrap this up. Derek Atkins writes: > KINK must meet the following requirements at a minimum: > > - The protocol must use Kerberos to create session keys in a secure > fashion > > A side effect of this is that the protocol must use the Kerberos > session key as part of the generation of IPSec keys. Correct. Do you think we need to be explicit about the generation part? > > - The protocol must be able to start up SA's regardless of any > client/server disposition in the keying protocol > > In other words, either IPSec peer can be the initiator or responder, > regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos > 'server' (has a keytab). Correct. > > - Kerberos makes a distinction between clients and servers; IPsec > does not. The protocol must allow for IPsec security associations > to be initiated by both servers and clients, thus preserving > IPsec's peer to peer nature. > > Isn't this the same thing, just said differently? Yeah, probably. Which version do you like better? :-) > - The protocol must be able to initially authenticate using either > secret key, or public key authentication. > > - The protocol must accommodate any combination of public and secret > key peers > > I'm not convinced we need to reference public/secret key. We just use > what Kerberos provides. So, I think these two requirements can > probably be rewritten to say: > > - The protocol must allow an initiator or a responder (or both) to > authenticate with just a TGT (using Kerberos User-to-User). This is what lead to your discussion with Matt. I'm cool with your final wording if Matt is. > - The protocol must be capable of rekeying without the assistance of > the KDC if the session ticket is still valid > > Using the phrase "Kerberos session ticket" is probably clearer. Ok. > The following sections do not belong in the requirements draft: Right. Will nuke. From owner-ietf-kink Tue Jan 23 17:34:19 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA17819 for ietf-kink-bks; Tue, 23 Jan 2001 17:34:19 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17815 for ; Tue, 23 Jan 2001 17:34:17 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id UAA19202; Tue, 23 Jan 2001 20:40:24 -0500 To: Michael Thomas Cc: "Medvinsky, Sasha (SD-EX)" , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4AF1@NTAS0027> <14958.8919.920126.391626@thomasm-u1.cisco.com> From: Derek Atkins Date: 23 Jan 2001 20:40:24 -0500 In-Reply-To: Michael Thomas's message of "Tue, 23 Jan 2001 16:33:27 -0800 (PST)" Message-ID: Lines: 79 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > Derek Atkins writes: > > App-Client App-Server KDC > > <--- Inititate > > > > { if no ticket is cached ... > > > > { direct case: > > TGS_REQ ---------------------> > > <------------------------TGS_REP > > } > > { U2U case (or if direct case failed): > > GetTGT* ---------> > > <---------- U2U TGT > > TGS_REQ ---------------------> > > <------------------------TGS_REP > > } > > } > > > > AP_REQ* --------> > > <--------- AP_REP > > [snip] > How so? This looks the same to me as any other wakeup > scheme: a minimal amount of work by the attacker (the > "server" in your diagram) causes the attacked (client, > KDC) to generate a non-minimal amount of work and > traffic. This looks like the same old Zombie kind of > attack as before. It's a modification to the wakeup scheme. Honestly, I was thinking about it in terms of U2U, not regular mode. In the U2U mode, this does protect against the DoS attacks. But you're right, the regular case only protects the App Server, not the client or KDC (which I suppose implies an impact on the App Server in that the client will try to initiate connections with anyone). This hybrid was based on the pushback of "too many messages". Obviously we can go back to my prior suggestion which basically adds one round trip in order to perform the handoff. As I said, this is a question for the WG. How important is the handoff situation, versus how many extra messages do we want to add to support the handoff? And which is more important to the WG, supporting a handoff situation with fewer messages or protecting against DoS? (Putting on my chairman hat, I would suggest that protecting against DoS is more important than supporting handoffs with fewer messages -- without my hat I consider handoffs to be a lower priority). So, we can go back to my older suggestion: C S K <-- Init Ack --> (Ack == "GetTGT") <--- TGT TGS_REQ -------> (REQ/REP can be repeated for service ticket <----------- TGS_REP to U2U failover or ignored for cached tickets) AP_REQ-> <- AP_REP Where the TGS_REQ/TGS_REP could theoretically be either a regular service-ticket request, a U2U request, or potentially both. Obviously using U2U is just as cheap as anything else at this point. ;) I believe that this protocol _does_ protect against the DoS attacks in all cases, but it does add one extra roundtrip in the case of a non-U2U case over Sasha's wakeup protocol. > Mike -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Tue Jan 23 17:48:37 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA18437 for ietf-kink-bks; Tue, 23 Jan 2001 17:48:37 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18433 for ; Tue, 23 Jan 2001 17:48:35 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZ97GT1QHAF0M1VF@GI.COM> for ietf-kink@vpnc.org; Tue, 23 Jan 2001 17:54:09 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 17:52:11 -0500 Content-return: allowed Date: Tue, 23 Jan 2001 20:56:03 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK user-user scenario To: "'Derek Atkins'" , Michael Thomas Cc: Jonathan Trostle , ietf-kink@vpnc.org Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4B26@NTAS0027> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, I don't agree that your proposal below protects against all types of DOS attacks. It is no different in that respect than my proposal. The adversary doesn't even have to possess a valid TGT. When the client receives a response to a "GetTGT", it has no way to verify the TGT and simply has to send it over to the KDC. If the adversary wants to have a valid TGT, it can get that as well - by snooping. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Tuesday, January 23, 2001 5:40 PM > To: Michael Thomas > Cc: Medvinsky, Sasha (SD-EX); Jonathan Trostle; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > Michael Thomas writes: > > > Derek Atkins writes: > > > App-Client App-Server KDC > > > <--- Inititate > > > > > > { if no ticket is cached ... > > > > > > { direct case: > > > TGS_REQ ---------------------> > > > <------------------------TGS_REP > > > } > > > { U2U case (or if direct case failed): > > > GetTGT* ---------> > > > <---------- U2U TGT > > > TGS_REQ ---------------------> > > > <------------------------TGS_REP > > > } > > > } > > > > > > AP_REQ* --------> > > > <--------- AP_REP > > > > [snip] > > How so? This looks the same to me as any other wakeup > > scheme: a minimal amount of work by the attacker (the > > "server" in your diagram) causes the attacked (client, > > KDC) to generate a non-minimal amount of work and > > traffic. This looks like the same old Zombie kind of > > attack as before. > > It's a modification to the wakeup scheme. Honestly, I was thinking > about it in terms of U2U, not regular mode. In the U2U mode, this > does protect against the DoS attacks. But you're right, the regular > case only protects the App Server, not the client or KDC (which I > suppose implies an impact on the App Server in that the client will > try to initiate connections with anyone). > > This hybrid was based on the pushback of "too many messages". > Obviously we can go back to my prior suggestion which basically adds > one round trip in order to perform the handoff. > > As I said, this is a question for the WG. How important is the > handoff situation, versus how many extra messages do we want to add to > support the handoff? And which is more important to the WG, > supporting a handoff situation with fewer messages or protecting > against DoS? (Putting on my chairman hat, I would suggest that > protecting against DoS is more important than supporting handoffs with > fewer messages -- without my hat I consider handoffs to be a lower > priority). > > So, we can go back to my older suggestion: > > C S K > <-- Init > Ack --> (Ack == "GetTGT") > <--- TGT > TGS_REQ -------> (REQ/REP can be repeated for > service ticket > <----------- TGS_REP to U2U failover or ignored for > cached tickets) > AP_REQ-> > <- AP_REP > > Where the TGS_REQ/TGS_REP could theoretically be either a regular > service-ticket request, a U2U request, or potentially both. Obviously > using U2U is just as cheap as anything else at this point. ;) > > I believe that this protocol _does_ protect against the DoS attacks in > all cases, but it does add one extra roundtrip in the case of a > non-U2U case over Sasha's wakeup protocol. > > > Mike > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink Tue Jan 23 18:08:35 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA18843 for ietf-kink-bks; Tue, 23 Jan 2001 18:08:35 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18838 for ; Tue, 23 Jan 2001 18:08:33 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id VAA19224; Tue, 23 Jan 2001 21:14:40 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B26@NTAS0027> From: Derek Atkins Date: 23 Jan 2001 21:14:40 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Tue, 23 Jan 2001 20:56:03 -0500" Message-ID: Lines: 129 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You're forgetting the client and server cookies :) The client verifies that the TGT is from the real server because it contains a cookie that the client inserted into the GetTGT request. The attacker would have to guess the client's 'cookie' in order to send a TGT that the client will accept. In other words, the GetTGT request contains two cookies, the server cookie as well as the client cookie. Sure, you're sacked if the attacker can snoop on the network. But in case you have other, bigger problems (and zombies are the worst of your worries). Note that the validity of the TGT is being completely ignored. What we get from this protocol is that both the client and the server are mutually aware that they want to perform a handoff. -derek "Medvinsky, Sasha (SD-EX)" writes: > Derek, > > I don't agree that your proposal below protects against all types of DOS > attacks. It is no different in that respect than my proposal. The > adversary doesn't even have to possess a valid TGT. When the client receives > a response to a "GetTGT", it has no way to verify the TGT and simply has to > send it over to the KDC. If the adversary wants to have a valid TGT, it can > get that as well - by snooping. > > Sasha. > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Tuesday, January 23, 2001 5:40 PM > > To: Michael Thomas > > Cc: Medvinsky, Sasha (SD-EX); Jonathan Trostle; ietf-kink@vpnc.org > > Subject: Re: KINK user-user scenario > > > > > > Michael Thomas writes: > > > > > Derek Atkins writes: > > > > App-Client App-Server KDC > > > > <--- Inititate > > > > > > > > { if no ticket is cached ... > > > > > > > > { direct case: > > > > TGS_REQ ---------------------> > > > > <------------------------TGS_REP > > > > } > > > > { U2U case (or if direct case failed): > > > > GetTGT* ---------> > > > > <---------- U2U TGT > > > > TGS_REQ ---------------------> > > > > <------------------------TGS_REP > > > > } > > > > } > > > > > > > > AP_REQ* --------> > > > > <--------- AP_REP > > > > > > [snip] > > > How so? This looks the same to me as any other wakeup > > > scheme: a minimal amount of work by the attacker (the > > > "server" in your diagram) causes the attacked (client, > > > KDC) to generate a non-minimal amount of work and > > > traffic. This looks like the same old Zombie kind of > > > attack as before. > > > > It's a modification to the wakeup scheme. Honestly, I was thinking > > about it in terms of U2U, not regular mode. In the U2U mode, this > > does protect against the DoS attacks. But you're right, the regular > > case only protects the App Server, not the client or KDC (which I > > suppose implies an impact on the App Server in that the client will > > try to initiate connections with anyone). > > > > This hybrid was based on the pushback of "too many messages". > > Obviously we can go back to my prior suggestion which basically adds > > one round trip in order to perform the handoff. > > > > As I said, this is a question for the WG. How important is the > > handoff situation, versus how many extra messages do we want to add to > > support the handoff? And which is more important to the WG, > > supporting a handoff situation with fewer messages or protecting > > against DoS? (Putting on my chairman hat, I would suggest that > > protecting against DoS is more important than supporting handoffs with > > fewer messages -- without my hat I consider handoffs to be a lower > > priority). > > > > So, we can go back to my older suggestion: > > > > C S K > > <-- Init > > Ack --> (Ack == "GetTGT") > > <--- TGT > > TGS_REQ -------> (REQ/REP can be repeated for > > service ticket > > <----------- TGS_REP to U2U failover or ignored for > > cached tickets) > > AP_REQ-> > > <- AP_REP > > > > Where the TGS_REQ/TGS_REP could theoretically be either a regular > > service-ticket request, a U2U request, or potentially both. Obviously > > using U2U is just as cheap as anything else at this point. ;) > > > > I believe that this protocol _does_ protect against the DoS attacks in > > all cases, but it does add one extra roundtrip in the case of a > > non-U2U case over Sasha's wakeup protocol. > > > > > Mike > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink Wed Jan 24 12:11:13 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11842 for ietf-kink-bks; Wed, 24 Jan 2001 12:11:13 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11838 for ; Wed, 24 Jan 2001 12:11:10 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZA9YXXKOSF0M1TG@GI.COM> for ietf-kink@vpnc.org; Wed, 24 Jan 2001 12:16:50 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 12:14:51 -0500 Content-return: allowed Date: Wed, 24 Jan 2001 15:18:28 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK user-user scenario To: "'Derek Atkins'" Cc: Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4B2B@NTAS0027> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, What I meant is that anyone can send the 'Initiate' command in your proposed sequence and when the bogus server then gets a GetTGT request, it can reply with whatever TGT it likes - valid or not. In my proposal: server -> client: Authenticate Request client -> server: AP Request server -> client: AP Reply The Authenticate Request and AP Request are also tied together with a 'server cookie' and so if the Authenticate Request is from an adversary impersonating some server and the AP Request is to a real server - the real server will drop the AP Request. So, the Denial of Service attack wasn't on the server. Mike Thomas brought up the issue of the zombie attacks on the KDC, where the clients will send TGS Requests to the KDC after a bogus Authenticate Request. Your proposal doesn't help with this denial of service attack - anyone can still send the 'Initiate' and wait for the GetTGT, respond with anything they like. The KDC would still get hit with the TGS requests for user-to-user tickets possibly with bogus server TGTs. So, it requires an adversary to implement a couple more messages. If you want to use the user-to-user mode, the Authenticate Request could contain the server's TGT as Mike once proposed. I am not sure that this denial of service attack on the KDC is a big problem, but my point is that the extra two messages in your proposed flows (GetTGT requst and response) don't provide any additional security. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Tuesday, January 23, 2001 6:15 PM > To: Medvinsky, Sasha (SD-EX) > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > You're forgetting the client and server cookies :) > > The client verifies that the TGT is from the real server because it > contains a cookie that the client inserted into the GetTGT request. > The attacker would have to guess the client's 'cookie' in order to > send a TGT that the client will accept. In other words, the GetTGT > request contains two cookies, the server cookie as well as the client > cookie. > > Sure, you're sacked if the attacker can snoop on the network. But in > case you have other, bigger problems (and zombies are the worst of > your worries). > > Note that the validity of the TGT is being completely ignored. What > we get from this protocol is that both the client and the server are > mutually aware that they want to perform a handoff. > > -derek > > "Medvinsky, Sasha (SD-EX)" writes: > > > Derek, > > > > I don't agree that your proposal below protects against all > types of DOS > > attacks. It is no different in that respect than my proposal. The > > adversary doesn't even have to possess a valid TGT. When > the client receives > > a response to a "GetTGT", it has no way to verify the TGT > and simply has to > > send it over to the KDC. If the adversary wants to have a > valid TGT, it can > > get that as well - by snooping. > > > > Sasha. > > > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Tuesday, January 23, 2001 5:40 PM > > > To: Michael Thomas > > > Cc: Medvinsky, Sasha (SD-EX); Jonathan Trostle; ietf-kink@vpnc.org > > > Subject: Re: KINK user-user scenario > > > > > > > > > Michael Thomas writes: > > > > > > > Derek Atkins writes: > > > > > App-Client App-Server KDC > > > > > <--- Inititate > > > > > > > > > > { if no ticket is cached ... > > > > > > > > > > { direct case: > > > > > TGS_REQ ---------------------> > > > > > <------------------------TGS_REP > > > > > } > > > > > { U2U case (or if direct case failed): > > > > > GetTGT* ---------> > > > > > <---------- U2U TGT > > > > > TGS_REQ ---------------------> > > > > > <------------------------TGS_REP > > > > > } > > > > > } > > > > > > > > > > AP_REQ* --------> > > > > > <--------- AP_REP > > > > > > > > [snip] > > > > How so? This looks the same to me as any other wakeup > > > > scheme: a minimal amount of work by the attacker (the > > > > "server" in your diagram) causes the attacked (client, > > > > KDC) to generate a non-minimal amount of work and > > > > traffic. This looks like the same old Zombie kind of > > > > attack as before. > > > > > > It's a modification to the wakeup scheme. Honestly, I > was thinking > > > about it in terms of U2U, not regular mode. In the U2U mode, this > > > does protect against the DoS attacks. But you're right, > the regular > > > case only protects the App Server, not the client or KDC (which I > > > suppose implies an impact on the App Server in that the > client will > > > try to initiate connections with anyone). > > > > > > This hybrid was based on the pushback of "too many messages". > > > Obviously we can go back to my prior suggestion which > basically adds > > > one round trip in order to perform the handoff. > > > > > > As I said, this is a question for the WG. How important is the > > > handoff situation, versus how many extra messages do we > want to add to > > > support the handoff? And which is more important to the WG, > > > supporting a handoff situation with fewer messages or protecting > > > against DoS? (Putting on my chairman hat, I would suggest that > > > protecting against DoS is more important than supporting > handoffs with > > > fewer messages -- without my hat I consider handoffs to be a lower > > > priority). > > > > > > So, we can go back to my older suggestion: > > > > > > C S K > > > <-- Init > > > Ack --> (Ack == "GetTGT") > > > <--- TGT > > > TGS_REQ -------> (REQ/REP can be repeated for > > > service ticket > > > <----------- TGS_REP to U2U failover or ignored for > > > cached tickets) > > > AP_REQ-> > > > <- AP_REP > > > > > > Where the TGS_REQ/TGS_REP could theoretically be either a regular > > > service-ticket request, a U2U request, or potentially > both. Obviously > > > using U2U is just as cheap as anything else at this point. ;) > > > > > > I believe that this protocol _does_ protect against the > DoS attacks in > > > all cases, but it does add one extra roundtrip in the case of a > > > non-U2U case over Sasha's wakeup protocol. > > > > > > > Mike > > > > > > -derek > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink Wed Jan 24 12:22:02 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA13083 for ietf-kink-bks; Wed, 24 Jan 2001 12:22:02 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13065 for ; Wed, 24 Jan 2001 12:21:59 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id PAA19925; Wed, 24 Jan 2001 15:28:04 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2B@NTAS0027> From: Derek Atkins Date: 24 Jan 2001 15:28:04 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Wed, 24 Jan 2001 15:18:28 -0500" Message-ID: Lines: 210 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ahh, but those extra packets DO provide extra security -- it requires the attacker to not only stay in the loop but to provide their real IP Address in order to get proper responses from the client and back to the client. This type of attack is extremely easy to track down, and it directly points to the attacker. In other words, in my version of the protocol the attacker must provide their real identity (IP Address) before any work is done by the client or KDC. In your version, the attacker could send a fake source-address and never be tracked down. Also, you leave out the client->KDC and KDC->client messages (before the AP Request).. Your protocol is just as suspect as mine in that respect -- the client would make a KDC request if it needs a ticket (just like it would in mine). The difference is that in my protocol, the client knows that the "server" (or attacker) is real and wants to be a part of the protocol. If it's an attacker, we know who it is. -derek "Medvinsky, Sasha (SD-EX)" writes: > Derek, > > What I meant is that anyone can send the 'Initiate' command in your proposed > sequence and when the bogus server then gets a GetTGT request, it can reply > with whatever TGT it likes - valid or not. > > In my proposal: server -> client: Authenticate Request > client -> server: AP Request > server -> client: AP Reply > > The Authenticate Request and AP Request are also tied together with a > 'server cookie' and so if the Authenticate Request is from an adversary > impersonating some server and the AP Request is to a real server - the real > server will drop the AP Request. So, the Denial of Service attack wasn't on > the server. Mike Thomas brought up the issue of the zombie attacks on the > KDC, where the clients will send TGS Requests to the KDC after a bogus > Authenticate Request. > > Your proposal doesn't help with this denial of service attack - anyone can > still send the 'Initiate' and wait for the GetTGT, respond with anything > they like. The KDC would still get hit with the TGS requests for > user-to-user tickets possibly with bogus server TGTs. So, it requires an > adversary to implement a couple more messages. If you want to use the > user-to-user mode, the Authenticate Request could contain the server's TGT > as Mike once proposed. > > I am not sure that this denial of service attack on the KDC is a big > problem, but my point is that the extra two messages in your proposed flows > (GetTGT requst and response) don't provide any additional security. > > Sasha. > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Tuesday, January 23, 2001 6:15 PM > > To: Medvinsky, Sasha (SD-EX) > > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > > Subject: Re: KINK user-user scenario > > > > > > You're forgetting the client and server cookies :) > > > > The client verifies that the TGT is from the real server because it > > contains a cookie that the client inserted into the GetTGT request. > > The attacker would have to guess the client's 'cookie' in order to > > send a TGT that the client will accept. In other words, the GetTGT > > request contains two cookies, the server cookie as well as the client > > cookie. > > > > Sure, you're sacked if the attacker can snoop on the network. But in > > case you have other, bigger problems (and zombies are the worst of > > your worries). > > > > Note that the validity of the TGT is being completely ignored. What > > we get from this protocol is that both the client and the server are > > mutually aware that they want to perform a handoff. > > > > -derek > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > Derek, > > > > > > I don't agree that your proposal below protects against all > > types of DOS > > > attacks. It is no different in that respect than my proposal. The > > > adversary doesn't even have to possess a valid TGT. When > > the client receives > > > a response to a "GetTGT", it has no way to verify the TGT > > and simply has to > > > send it over to the KDC. If the adversary wants to have a > > valid TGT, it can > > > get that as well - by snooping. > > > > > > Sasha. > > > > > > > > > > -----Original Message----- > > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > > Sent: Tuesday, January 23, 2001 5:40 PM > > > > To: Michael Thomas > > > > Cc: Medvinsky, Sasha (SD-EX); Jonathan Trostle; ietf-kink@vpnc.org > > > > Subject: Re: KINK user-user scenario > > > > > > > > > > > > Michael Thomas writes: > > > > > > > > > Derek Atkins writes: > > > > > > App-Client App-Server KDC > > > > > > <--- Inititate > > > > > > > > > > > > { if no ticket is cached ... > > > > > > > > > > > > { direct case: > > > > > > TGS_REQ ---------------------> > > > > > > <------------------------TGS_REP > > > > > > } > > > > > > { U2U case (or if direct case failed): > > > > > > GetTGT* ---------> > > > > > > <---------- U2U TGT > > > > > > TGS_REQ ---------------------> > > > > > > <------------------------TGS_REP > > > > > > } > > > > > > } > > > > > > > > > > > > AP_REQ* --------> > > > > > > <--------- AP_REP > > > > > > > > > > [snip] > > > > > How so? This looks the same to me as any other wakeup > > > > > scheme: a minimal amount of work by the attacker (the > > > > > "server" in your diagram) causes the attacked (client, > > > > > KDC) to generate a non-minimal amount of work and > > > > > traffic. This looks like the same old Zombie kind of > > > > > attack as before. > > > > > > > > It's a modification to the wakeup scheme. Honestly, I > > was thinking > > > > about it in terms of U2U, not regular mode. In the U2U mode, this > > > > does protect against the DoS attacks. But you're right, > > the regular > > > > case only protects the App Server, not the client or KDC (which I > > > > suppose implies an impact on the App Server in that the > > client will > > > > try to initiate connections with anyone). > > > > >