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